503 Usługa jest niedostępna – nie udało się utworzyć tunelu proxy z błędem 403

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 503 Service Unavailable z kodem błędu protocol.http.ProxyTunnelCreationFailed w odpowiedzi na wywołania interfejsu API.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 503 Service Unavailable

Może też pojawić się ten komunikat o błędzie:

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

Serwer proxy przekierowania i tunelowanie

Apigee Edge umożliwia proxy interfejsu API komunikowanie się z serwerem backendu za pomocą serwera proxy , jak opisano w artykule Konfigurowanie serwera proxy przekierowania. Serwer proxy otwiera bezpieczne (HTTPS) lub niezabezpieczone (HTTP) połączenie z serwerem backendu w zależności od typu serwera proxy (wskazywanego przez właściwość HTTPClient.proxy.type) używanego i przesyła dane w obu kierunkach. Nazywamy to tunelowaniem.

Domyślnie Apigee Edge używa tunelowania w przypadku całego ruchu. Aby wyłączyć tunelowanie, właściwość HTTPClient.use.tunneling należy ustawić na false.

Kod błędu: protocol.http.ProxyTunnelCreationFailed

Apigee Edge zwraca kod błędu protocol.http.ProxyTunnelCreationFailed, jeśli serwer proxy nie może utworzyć tunelu między Apigee Edge a serwerem backendu z powodu problemów takich jak zapora sieciowa, ograniczenia listy kontroli dostępu (ACL), problemy z DNS, niedostępność serwera backendu, przekroczenie limitu czasu itp.

Kod stanu w faultstring odpowiedzi z Apigee Edge zwykle wskazuje możliwą przyczynę wyższego poziomu, która doprowadziła do tego błędu.

Szablon faultstring:

Proxy refused to create tunnel with response status STATUS_CODE

Możliwe przyczyny niektórych kodów stanu obserwowanych w faultstring:

W tabeli poniżej opisano możliwe przyczyny w zależności od kodu stanu wskazanego w faultstring:

W zależności od kodu stanu obserwowanego w faultstring musisz użyć odpowiednich metod rozwiązywania problemu. Ten przewodnik wyjaśnia, jak rozwiązać problem, jeśli w faultstring dla kodu błędu protocol.http.ProxyTunnelCreationFailed występuje kod stanu 403 .

Możliwe przyczyny

Ten błąd (kod stanu 403) występuje, jeśli na serwerze backendu są skonfigurowane ograniczenia zapory sieciowej lub listy ACL (Access Control List), które uniemożliwiają serwerowi proxy utworzenie tunelu między Apigee Edge a serwerem backendu.

Typowe czynności diagnostyczne

Aby zdiagnozować ten błąd, użyj jednego z tych narzędzi lub metod:

Przyczyna: Proxy refused to create tunnel with response status 403

Diagnostyka

1. Określ kod błędu i źródło błędu dla 503 Service Unavailable za pomocą narzędzia Trace lub logów dostępu NGINX, jak opisano w sekcji Typowe czynności diagnostyczne.
2. Sprawdź komunikat o błędzie i określ kod stanu wskazany w faultstring w przypadku niepowodzenia utworzenia tunelu.
3. W tym przypadku kod stanu to 403, co oznacza Dostęp zabroniony.
4. Oznacza to, że nie masz wystarczających praw ani uprawnień do utworzenia tunelu. Zwykle może się tak zdarzyć, jeśli istnieją ograniczenia zapory sieciowej lub listy kontroli dostępu (ACL), które uniemożliwiają utworzenie tunelu.
5. Sprawdź ograniczenia zapory sieciowej lub listy ACL skonfigurowane na serwerze backendu, które mogą uniemożliwiać utworzenie tunelu.
6. W zależności od typu zapory sieciowej lub ograniczeń listy ACL musisz odpowiednio rozwiązać problem.

7. Aby wyjaśnić, jak rozwiązać ten problem, weźmy na przykład ograniczenie zapory sieciowej:

   Scenariusz: ograniczenie zapory sieciowej na serwerze backendu wymaga, aby nagłówek Host zawsze zawierał nazwę hosta serwera backendu

   Aby określić nagłówek Host przekazywany przez Apigee Edge, możesz użyć jednej z tych metod:

   Śledzenie

   Aby określić nagłówek Host za pomocą śledzenia:

   1. Upewnij się, że faultstring zawiera Proxy refused to create tunnel with response status 403 za pomocą śledzenia, jak opisano w Typowe czynności diagnostyczne.
   2. Otwórz etap Target Request Flow Started (Rozpoczęcie przepływu żądania do celu) i sprawdź Request Headers(Nagłówki żądania).
   3. Sprawdź wartość nazwy hosta podaną w nagłówku Host w sekcji Request Headers (Nagłówki żądania).
   4. Jeśli nagłówek Host zawiera nazwę hosta serwera proxy, jest to przyczyna tego błędu.
   5. Dzieje się tak, ponieważ zapora sieciowa jest skonfigurowana na serwerze backendu tak, aby akceptować żądania tylko wtedy, gdy nagłówek Host zawiera nazwę serwera backendu.
   6. Gdy serwer proxy próbuje utworzyć tunel z serwerem backendu, kończy się to niepowodzeniem z powodu błędu

      Proxy refused to create tunnel with response status 403.

      Przykładowy ślad pokazujący nagłówek Host z nazwą hosta serwera proxy

      ( powiększ obraz)

      

      W powyższym przykładowym śladzie widać, że nagłówek Host zawiera nazwę hosta serwera proxy www.proxyserver.com. Ponieważ na serwerze backendu jest skonfigurowane ograniczenie zapory sieciowej, które wymaga, aby nagłówek Host zawierał tylko nazwę hosta serwera backendu, występuje błąd Proxy refused to create tunnel with response status 403.

   tcpdump

   Aby określić nagłówek Host za pomocą tcpdump:

   1. Przechwyć tcpdump na serwerze proxy w przypadku żądań pochodzących z komponentu procesora komunikatów Apigee Edge za pomocą tego polecenia:

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

      Więcej informacji o używaniu polecenia tcpdump znajdziesz w artykule tcpdump.

   2. Przeanalizuj dane tcpdump za pomocą narzędzia Wireshark lub podobnego narzędzia.

   3. Oto przykładowa analiza `tcpdump` za pomocą Wireshark:

      ( powiększ obraz)

      
   4. Numery pakietów 13, 14 i 15 wskazują, że procesor wiadomości nawiązuje połączenie z serwerem proxy za pomocą trójstronnego uzgadniania TCP.
   5. W pakiecie 16 procesor komunikatów połączył się z hostem serwera proxy httpbin.org (pokazanym w przykładzie powyżej).

   6. Wybierz pakiet 16 i szczegółowo sprawdź jego zawartość, a zwłaszcza nagłówek Host przekazywany do serwera proxy przez procesor wiadomości.

      
   7. W powyższym przykładzie widać nagłówek Host httpin.org, który jest nazwą hosta serwera proxy. Gdy serwer proxy próbuje utworzyć tunel z serwerem backendu, przekazując powyższy nagłówek Host httpin.org, kończy się to niepowodzeniem z powodu błędu Proxy refused to create tunnel with response status 403.

Rozwiązanie

Scenariusz: ograniczenie zapory sieciowej na serwerze proxy wymaga, aby nagłówek Host zawsze zawierał nazwę hosta serwera backendu

Jeśli stwierdzisz, że ten błąd jest spowodowany tym, że zapora sieciowa na serwerze backendu jest skonfigurowana tak, aby wymagała, aby nagłówek Host zawsze zawierał nazwę hosta serwera backendu, a procesor komunikatów wysyła nazwę hosta serwera proxy, wykonaj te czynności, aby rozwiązać problem:

1. Ustaw właściwość use.proxy.host.header.with.target.uri na true w TargetEndpoint, jak pokazano w tym przykładzie:

   Przykładowa konfiguracja 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. Upewnij się, że inne właściwości związane z serwerem proxy przekierowania są skonfigurowane w procesorze komunikatów w ten sposób:

   1. Sprawdź plik /opt/apigee/customer/application/message-processor.properties na każdym procesorze wiadomości.

   2. Upewnij się, że te właściwości są ustawione zgodnie z Twoim przypadkiem użycia lub wymaganiami:

      Przykładowe wartości właściwości:

      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

Informacje diagnostyczne, które musisz zebrać

Jeśli problem będzie nadal występował nawet po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge:

Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:

• Pełny komunikat o błędzie obserwowany w przypadku nieudanych żądań.
• Nazwa środowiska.
• Pakiet proxy interfejsu API.
• Plik śledzenia żądań do interfejsu API.

• Logi dostępu NGINX.

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

  Gdzie: ORG, ENV i PORT# są zastępowane rzeczywistymi wartościami.

• Logi systemowe procesora komunikatów.

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

Odniesienia

• Konfigurowanie serwera proxy przekierowania
• Tunelowanie SSL