503 Dienst nicht verfügbar – Proxy-Tunnel konnte nicht mit 403 erstellt werden

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 503 Service Unavailable mit dem Fehlercode protocol.http.ProxyTunnelCreationFailed als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 503 Service Unavailable

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

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

Weiterleitungsproxy und Tunneling

Mit Apigee Edge können Ihre API-Proxys über einen Proxy server mit Ihrem Backend-Server kommunizieren, wie unter Weiterleitungsproxy konfigurieren erläutert. Der Proxyserver öffnet je nach Proxyservertyp (angegeben durch die Eigenschaft HTTPClient.proxy.type) eine sichere (HTTPS) oder nicht sichere (HTTP) Verbindung zum Backend-Server und überträgt die Daten in beide Richtungen. Dies wird als Tunneling bezeichnet.

Standardmäßig verwendet Apigee Edge Tunneling für den gesamten Traffic. Wenn Sie Tunneling deaktivieren möchten, muss die Eigenschaft HTTPClient.use.tunneling auf false gesetzt werden.

Fehlercode: protocol.http.ProxyTunnelCreationFailed

Apigee Edge gibt den Fehlercode protocol.http.ProxyTunnelCreationFailed zurück, wenn der Proxyserver aufgrund von Problemen wie Firewall-, ACL- (Access Control List-)Einschränkungen, DNS-Problemen, Nichtverfügbarkeit des Backend-Servers, Zeitüberschreitungen usw. keinen Tunnel zwischen Apigee Edge und dem Backend-Server erstellen kann.

Der Statuscode im faultstring der Antwort von Apigee Edge gibt in der Regel eine mögliche Ursache auf hoher Ebene an, die zu diesem Fehler geführt hat.

Faultstring-Vorlage :

Proxy refused to create tunnel with response status STATUS_CODE

Mögliche Ursachen für einige der im Faultstring beobachteten Statuscodes :

In der folgenden Tabelle werden mögliche Ursachen je nach Statuscode im faultstring beschrieben:

Je nach Statuscode im faultstring müssen Sie geeignete Methoden zur Fehlerbehebung verwenden. In diesem Playbook wird erläutert, wie Sie das Problem beheben , wenn im faultstring für den Fehlercode protocol.http.ProxyTunnelCreationFailed der Statuscode 403 angezeigt wird.

Mögliche Ursachen

Dieser Fehler (Statuscode 403) tritt auf, wenn auf dem Backend-Server Firewall- oder ACL- (Access Control List-)Einschränkungen konfiguriert sind, die verhindern, dass der Proxyserver einen Tunnel zwischen Apigee Edge und dem Backend-Server erstellt.

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools/Verfahren, um diesen Fehler zu diagnostizieren:

Ursache: Proxy refused to create tunnel with response status 403

Diagnose

1. Ermitteln Sie den Fehlercode und die Fehlerquelle für 503 Service Unavailable mit dem Trace-Tool oder den NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte erläutert.
2. Prüfen Sie die Fehlermeldung und ermitteln Sie den Statuscode im faultstring für den Fehler bei der Erstellung des Tunnels.
3. In diesem Szenario ist der Statuscode 403, was Unzulässig bedeutet.
4. Das bedeutet, dass nicht genügend Rechte oder Berechtigungen zum Erstellen des Tunnels vorhanden sind. Dies kann in der Regel passieren, wenn Firewall- oder ACL- (Access Control List-)Einschränkungen die Erstellung des Tunnels verhindern.
5. Prüfen Sie alle Firewall- und/oder ACL-Einschränkungen, die auf Ihrem Backend-Server konfiguriert sind und die Erstellung des Tunnels verhindern können.
6. Je nach Art der Firewall- und/oder ACL-Einschränkungen müssen Sie das Problem entsprechend beheben.

7. Sehen wir uns eine Beispiel-Firewalleinschränkung an, um zu erklären, wie Sie dieses Problem beheben können:

   Szenario: Firewalleinschränkung auf dem Backend-Server erwartet, dass der Host-Header immer den Hostnamen des Backend-Servers enthält

   Sie können eine der folgenden Methoden verwenden, um den von Apigee Edge übergebenen Host-Header zu ermitteln:

   Trace

   So ermitteln Sie den Host-Header mit Trace:

   1. Achten Sie darauf, dass der faultstring Proxy refused to create tunnel with response status 403 enthält, wie unter Allgemeine Diagnoseschritte erläutert.
   2. Gehen Sie zur Phase Target Request Flow Started und prüfen Sie die Anfrageheader
   3. Prüfen Sie den Wert des Hostnamens im Host-Header im Abschnitt Anfrageheader.
   4. Wenn der Host-Header den Hostnamen des Proxys enthält, ist dies die Ursache für diesen Fehler.
   5. Das liegt daran, dass die Firewall auf dem Backend-Server so konfiguriert ist, dass Anfragen nur akzeptiert werden, wenn der Host-Header den Namen des Backend-Servers enthält.
   6. Wenn der Proxyserver also versucht, den Tunnel mit dem Backend-Server zu erstellen, schlägt dies mit dem Fehler

      Proxy refused to create tunnel with response status 403 fehl.

      Beispiel für einen Trace, in dem der Host-Header den Hostnamen des Proxys enthält

      ( größeres Bild ansehen)

      

      Im obigen Beispiel-Trace ist zu sehen, dass der Host-Header den Namen des Proxy-Hosts enthältwww.proxyserver.com. Da auf dem Backend-Server eine Firewalleinschränkung konfiguriert ist, die erwartet, dass nur der Hostname des Backend-Servers im Host-Header enthalten ist, erhalten Sie den Fehler Proxy refused to create tunnel with response status 403.

   tcpdump

   So ermitteln Sie den Host-Header mit tcpdump:

   1. Erfassen Sie einen tcpdump auf dem Proxyserver für die Anfragen, die von der Message Processor-Komponente von Apigee Edge stammen, mit dem folgenden Befehl:

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

      Weitere Informationen zur Verwendung des Befehls tcpdump finden Sie unter tcpdump.

   2. Analysieren Sie die tcpdump-Daten mit dem Wireshark-Tool oder einem ähnlichen Tool.

   3. Hier ist eine Beispielanalyse des `tcpdump` mit Wireshark:

      ( größeres Bild ansehen)

      
   4. Die Paketnummern 13, 14 und 15 zeigen, dass der Message Processor über einen dreifachen TCP-Handshake-Prozess eine Verbindung zum Proxyserver herstellt.
   5. In Paket 16 hat der Message Processor eine Verbindung zum Proxy-Host httpbin.org hergestellt (siehe oben).

   6. Wählen Sie Paket 16 aus und prüfen Sie den Inhalt des Pakets im Detail, insbesondere den Host-Header , der vom Message Processor an den Proxyserver übergeben wird.

      
   7. Das obige Beispiel zeigt den Host-Header httpin.org, der ist der Hostname des Proxyservers. Wenn der Proxyserver also versucht, den Tunnel mit dem Backend-Server zu erstellen, indem er den obigen Host-Header httpin.org übergibt, schlägt dies mit dem Fehler Proxy refused to create tunnel with response status 403 fehl.

Auflösung

Szenario: Firewalleinschränkung auf dem Proxyserver erwartet, dass der Host-Header immer den Hostnamen des Backend-Servers enthält

Wenn Sie festgestellt haben, dass dieser Fehler auftritt, weil die Firewall auf dem Backend-Server so konfiguriert ist, dass sie erwartet, dass der Host-Header immer den Hostnamen des Backend-Servers enthält, während der Message Processor den Hostnamen des Proxyservers sendet, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

1. Setzen Sie die Eigenschaft use.proxy.host.header.with.target.uri im TargetEndpoint auf „true“, wie im folgenden Beispiel gezeigt:

   Beispiel für eine TargetEndpoint-Konfiguration :

   <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. Achten Sie darauf, dass die anderen Eigenschaften im Zusammenhang mit dem Weiterleitungsproxy auf dem Message Processor wie folgt konfiguriert sind:

   1. Prüfen Sie die Datei /opt/apigee/customer/application/message-processor.properties auf jedem Message Processor.

   2. Achten Sie darauf, dass die folgenden Eigenschaften entsprechend Ihrem Anwendungsfall oder Ihren Anforderungen festgelegt sind:

      Beispielwerte für Eigenschaften :

      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

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

Wenn Sie Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
• Name der Umgebung
• API-Proxy-Bundle
• Trace-Datei für die API-Anfragen

• NGINX-Zugriffslogs

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

  Dabei werden: ORG, ENV und PORT# durch tatsächliche Werte ersetzt.

• Systemlogs des Message Processors

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

Verweise

• Weiterleitungsproxy konfigurieren
• SSL-Tunneling