503 서비스를 사용할 수 없음 - 403으로 인해 프록시 터널 생성이 실패함

Apigee Edge 문서입니다.
Go to the Apigee X 문서로 이동합니다. info

증상

클라이언트 애플리케이션에 API 호출의 응답으로 오류 코드 protocol.http.ProxyTunnelCreationFailed과 함께 HTTP 상태 코드 503 Service Unavailable이 발생합니다.

오류 메시지

클라이언트 애플리케이션에 다음 응답 코드가 발생합니다.

HTTP/1.1 503 Service Unavailable

또한 다음 오류 메시지가 표시될 수 있습니다.

{
   "fault":{
      "faultstring":"Proxy refused to create tunnel with response status 403",
      "detail":{
         "errorcode":"protocol.http.ProxyTunnelCreationFailed"
      }
   }
}

전달 프록시 및 터널링

Apigee Edge를 사용하면 API 프록시가 프록시 서버를 통해 백엔드 서버와 통신할 수 있습니다. 전달 프록시 구성에 설명된 대로 프록시 서버는 사용된 프록시 유형 (속성 HTTPClient.proxy.type)에 따라 백엔드 서버에 보안(HTTPS) 또는 비보안 (HTTP) 연결을 열고 양방향으로 데이터를 전송합니다. 이를 터널링 이라고 합니다.

기본적으로 Apigee Edge는 모든 트래픽에 터널링을 사용합니다. 터널링을 사용 중지하려면 속성 HTTPClient.use.tunneling을 false로 설정해야 합니다.

오류 코드: protocol.http.ProxyTunnelCreationFailed

프록시 서버가 방화벽, ACL (액세스 제어 목록) 제한, DNS 문제, 백엔드 서버 사용 불가, 제한 시간 등과 같은 문제로 인해 Apigee Edge와 백엔드 서버 간에 터널을 만들 수 없는 경우 Apigee Edge는 오류 코드 protocol.http.ProxyTunnelCreationFailed를 반환합니다.

Apigee Edge의 응답에 있는 faultstring의 상태 코드는 일반적으로 이 오류를 일으킨 가능한 상위 수준 원인을 나타냅니다.

Faultstring 템플릿:

Proxy refused to create tunnel with response status STATUS_CODE

faultstring에 표시된 일부 상태 코드의 가능한 원인:

다음 표에서는 faultstring에 표시된 상태 코드에 따라 가능한 원인을 설명합니다.

faultstring에 표시된 상태 코드에 따라 적절한 기법을 사용하여 문제를 해결해야 합니다. 이 플레이북에서는 오류 코드 protocol.http.ProxyTunnelCreationFailed의 faultstring에 상태 코드 403 이 표시되는 경우 문제를 해결하는 방법을 설명합니다.

가능한 원인

이 오류 (상태 코드 403)는 프록시 서버가 Apigee Edge와 백엔드 서버 간에 터널을 만들지 못하도록 하는 방화벽 또는 ACL (액세스 제어 목록) 제한이 백엔드 서버에 구성되어 있는 경우 발생합니다.

일반적인 진단 단계

다음 도구/기법 중 하나를 사용하여 이 오류를 진단합니다.

원인: 프록시가 응답 상태 403으로 터널 만들기를 거부함

진단

1. 일반적인 진단 단계에 설명된 대로 Trace 도구 또는 NGINX 액세스 로그를 사용하여 503 Service Unavailable의 오류 코드 및 오류 소스 를 확인합니다.
2. 오류 메시지를 검토하고 터널 생성 실패에 대해 faultstring에 표시된 상태 코드 를 확인합니다.
3. 이 시나리오에서 상태 코드는 403이며 이는 Forbidden 을 의미합니다.
4. 즉, 터널을 만들 권한이 부족합니다. 이는 일반적으로 터널 생성을 방지하는 방화벽 또는 ACL (액세스 제어 목록) 제한이 있는 경우 발생할 수 있습니다.
5. 터널 생성을 방지할 수 있는 백엔드 서버에 구성된 방화벽 또는 ACL 제한을 검토합니다.
6. 방화벽 또는 ACL 제한 유형에 따라 문제를 적절하게 해결해야 합니다.

7. 방화벽 제한을 예로 들어 이 문제를 해결하는 방법을 설명하겠습니다.

   시나리오: 백엔드 서버의 방화벽 제한으로 인해 호스트 헤더에 항상 백엔드 서버 호스트 이름이 포함되어야 함

   다음 방법 중 하나를 사용하여 Apigee Edge에서 전달된 호스트 헤더를 확인할 수 있습니다.

   Trace

   Trace를 사용하여 호스트 헤더를 확인하려면 다음 단계를 따르세요.

   1. 일반적인 진단 단계에 설명된 대로 트레이스를 사용하여 faultstring에 Proxy refused to create tunnel with response status 403이 포함되어 있는지 확인합니다.
   2. 대상 요청 흐름 시작 단계로 이동하여 요청 헤더를 검토합니다.
   3. 요청 헤더 섹션의 호스트 헤더에 지정된 호스트 이름 값을 확인합니다.
   4. 호스트 헤더에 프록시 호스트 이름이 포함되어 있으면 이 오류의 원인입니다.
   5. 이는 백엔드 서버에 방화벽이 구성되어 있기 때문에 요청을 수락하는 경우에만 호스트 헤더에 백엔드 서버 이름이 포함됩니다.
   6. 따라서 프록시 서버가 백엔드 서버와 터널을 만들려고 하면 다음 오류가 발생하면서 실패합니다.

      Proxy refused to create tunnel with response status 403.

      프록시 호스트 이름이 있는 호스트 헤더를 보여주는 샘플 트레이스

      ( 이미지 크게 보기)

      

      위에 표시된 샘플 트레이스에는 호스트 헤더에 프록시 호스트 이름이 포함되어 있습니다. www.proxyserver.com. 백엔드 서버에 호스트 헤더에 백엔드 서버 호스트 이름만 포함되도록 방화벽 제한이 구성되어 있으므로 Proxy refused to create tunnel with response status 403 오류가 발생합니다.

   tcpdump

   tcpdump를 사용하여 호스트 헤더를 확인하려면 다음 단계를 따르세요.

   1. 다음 명령어를 사용하여 Apigee Edge의 메시지 프로세서 구성요소에서 수신되는 요청에 대해 프록시 서버에서 tcpdump를 캡처합니다.

      tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
      

      tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump를 참조하세요.

   2. tcpdump 데이터를 Wireshark 도구 또는 유사한 도구를 사용하여 분석합니다.

   3. 다음은 Wireshark를 사용한 tcpdump 분석 샘플입니다.

      ( 이미지 크게 보기)

      
   4. 패킷 번호 13, 14, 15는 메시지 프로세서가 3방향 TCP 핸드셰이크 프로세스를 통해 프록시 서버에 연결을 설정하고 있음을 보여줍니다.
   5. 패킷 16에서 메시지 프로세서가 프록시 호스트 httpbin.org (위 예에 표시됨)에 연결되었습니다.

   6. 패킷 16 을 선택하고 패킷의 콘텐츠, 특히 메시지 프로세서에서 프록시 서버로 전달되는 호스트 헤더 를 자세히 검사합니다.

      
   7. 위 샘플에는 프록시 서버의 호스트 이름인 호스트 헤더 httpin.org가 표시되어 있습니다. 따라서 프록시 서버가 위 호스트 헤더 httpin.org를 전달하여 백엔드 서버와 터널을 만들려고 하면 Proxy refused to create tunnel with response status 403 오류가 발생하면서 실패합니다.

해결 방법

시나리오: 프록시 서버의 방화벽 제한으로 인해 호스트 헤더에 항상 백엔드 서버 호스트 이름이 포함되어야 함

백엔드 서버의 방화벽이 호스트 헤더 에 항상 백엔드 서버 호스트 이름이 포함되도록 구성되어 있는 반면 메시지 프로세서가 프록시 서버 호스트 이름을 전송하기 때문에 이 오류가 발생한 것으로 확인된 경우 다음 단계를 수행하여 문제를 해결합니다.

1. 다음 예와 같이 TargetEndpoint에서 use.proxy.host.header.with.target.uri 속성을 true로 설정합니다.

   샘플 TargetEndpoint 구성:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="use.proxy.host.header.with.target.uri">true</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

2. 전달 프록시와 관련된 다른 속성이 메시지 프로세서에 다음과 같이 구성되어 있는지 확인합니다.

   1. 각 메시지 프로세서에서 /opt/apigee/customer/application/message-processor.properties 파일을 검토합니다.

   2. 다음 속성이 사용 사례 또는 요구사항에 따라 설정되어 있는지 확인합니다.

      속성의 샘플 값:

      conf_http_HTTPClient.use.proxy=true
      conf/http.properties+HTTPClient.proxy.type=HTTP
      conf/http.properties+HTTPClient.proxy.host=PROXY_SERVER_HOST_NAME
      conf/http.properties+HTTPClient.proxy.port=PORT_#
      conf/http.properties+HTTPClient.proxy.user=USERNAME
      conf/http.properties+HTTPClient.proxy.password=PASSWORD

진단 정보 수집 필요

위 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집한 후 Apigee Edge 지원팀에 문의하세요.

Private Cloud 사용자인 경우 다음 정보를 제공하세요.

• 실패한 요청에 대해 관찰된 전체 오류 메시지
• 환경 이름
• API 프록시 번들
• API 요청의 트레이스 파일

• NGINX 액세스 로그

  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  여기서: ORG, ENV 및 PORT#는 실제 값으로 대체됩니다.

• 메시지 프로세서 시스템 로그

  /opt/apigee/var/log/edge-message-processor/logs/system.log

참조

• 전달 프록시 구성
• SSL 터널링