Fehler „VPC-Peering 503-Dienst nicht verfügbar“ mit TARGET_CONNECT_TIMEOUT

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.

Symptom

Dieses Problem wird in API Monitoring, Debugging oder anderen Tools als Fehler des Typs „503 – Dienst nicht verfügbar“ angezeigt. Der Grund „TARGET_CONNECT_TIMEOUT” gibt ein Zeitlimit für die Verbindung zwischen der Apigee-Instanz und dem Ziel an, wenn VPC-Peering verwendet wird.

Der Fehler sollte nicht mit anderen Zeitüberschreitungsfehlern verwechselt werden, z. B. „504 Gateway Zeitüberschreitung“.

Fehlermeldung

Dies ist der typische Fehler in der Debugging-Sitzung oder in der Antwortnutzlast. Beachten Sie den Grund: TARGET_CONNECT_TIMEOUT.

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

Mögliche Ursachen

Beachten Sie, dass diese Ursachen spezifisch für Apigee-Einrichtungen mit VPC-Peering sind. Siehe Apigee-Netzwerkoptionen. Wenn das Ziel PSC (Endpunktanhang) ist, finden Sie weitere Informationen im PSC-Playbook.

Ursache	Beschreibung
Fehlerhafte Konfiguration der Routen	Zielrouten werden nicht in das Peering mit der Apigee-Instanz exportiert.
Verbindungsproblem am Ziel	Das Ziel kann eine TCP-Verbindung nicht immer akzeptieren.
IP-Zulassungsliste am Ziel mit einigen oder allen nicht hinzugefügten Apigee NAT-IP-Adressen	Nicht alle Apigee NAT-IP-Adressen sind am Ziel auf die Zulassungsliste gesetzt.
NAT-IP-Port erschöpft	Nicht genügend NAT-Ports für den Traffic.
connect.timeout.millis-Wert ist zu niedrig	Die Einstellung für das Zeitlimit der Verbindung ist auf Apigee-Seite zu niedrig.

Allgemeine Diagnoseschritte

Debug ist ein wichtiges Tool zum Erfassen und Bewerten der folgenden Details zum Problem:

Gesamtdauer der Anfrage. Normalerweise dauert es drei Sekunden (Standard connect.timeout.millis), bis eine Verbindungszeitüberschreitung auftritt. Wenn Sie eine kürzere Dauer feststellen, prüfen Sie die Konfiguration des Zielendpunkts.
Der Zielhostname und die IP-Adresse. Wenn die falsche IP-Adresse angezeigt wird, kann das auf ein DNS-Problem hinweisen. Möglicherweise stellen Sie auch einen Zusammenhang zwischen verschiedenen Ziel-IP-Adressen und dem Problem fest.
Häufigkeit. Je nachdem, ob das Problem zeitweise oder dauerhaft besteht, sind unterschiedliche Ansätze erforderlich.

Ursache: Fehlkonfiguration der Route

Diagnose

Wenn das Problem dauerhaft besteht, kann es durch eine fehlerhafte Konfiguration der Route verursacht werden, auch wenn es kürzlich begonnen hat.

Dies kann sowohl interne (weitergeleitet innerhalb Peering-VPC) als auch externe (Internet-)Ziele betreffen.

Identifizieren Sie zuerst die IP-Adresse des Ziels, die aus der Apigee-Instanz aufgelöst wurde. Eine der Methoden ist die Verwendung einer Debugging-Sitzung. Rufen Sie unter Debug auf AnalyticsPublisher (oder AX im klassischen Debugging) auf:

Suchen Sie rechts auf dem Bildschirm nach dem Wert target.ip.

In diesem Beispiel lautet die IP 10.2.0.1. Da dieser Bereich privat ist, müssen bestimmte Routingmaßnahmen eingerichtet werden, damit Apigee das Ziel erreichen kann.

Wenn sich das Ziel im Internet befindet, müssen Sie diesen Schritt ausführen, wenn VPC Service Controls für Apigee aktiviert sind, da dadurch die Internetverbindung verhindert wird.
Notieren Sie sich die Region, in der die betroffene Apigee-Instanz bereitgestellt wird. Klicken Sie in der https://console.cloud.google.com/apigee auf Instanzen. Im Feld Standort sehen Sie die genaue Region der Instanz.
Wechseln Sie in dem Projekt, das mit Apigee verbunden ist, zum Abschnitt VPC-Netzwerk -> VPC-Netzwerk-Peering in der Benutzeroberfläche. Hinweis: Wenn Sie freigegebene VPC verwenden, müssen diese Schritte im Hostprojekt und nicht im Apigee-Projekt ausgeführt werden.
Klicken Sie auf servicenetworking-googleapis-com, wählen Sie den Tab EXPORTIERTE ROUTEN aus und filtern Sie nach der Region aus Schritt 2.

Dieses Beispiel zeigt die exportierte Route 10.2.0.0/24 und enthält die Beispiel-Ziel-IP-Adresse 10.2.0.1. Wenn Sie keine Ihrem Ziel entsprechende Route sehen, ist dies die Ursache des Problems.
Hinweis: Wenn das Ziel extern ist, sind Routen normalerweise nicht in den Exportierten Routen vorhanden und Apigee-Anfragen werden direkt auf das Internet übertragen. Dies ist möglicherweise nicht immer der Fall. Achten Sie daher darauf, die gewünschte Netzwerktopologie zu klären. Wenn beispielsweise VPC Service Controls aktiviert ist, müssen Sie auch Standard- oder andere Routen exportieren, um externe Ziele zu erreichen.

Lösung

Prüfen Sie Ihre Netzwerkarchitektur und achten Sie darauf, dass Routen mit Apigee in das VPC-Peering exportiert werden. Höchstwahrscheinlich ist die fehlende Route entweder statisch oder dynamisch. Wenn keine erforderlichen dynamischen Routen vorhanden sind, weist dies auf ein Problem mit dem entsprechenden Feature (z. B. Cloud Interconnect) hin.

Hinweis: Transitives Peering wird nicht unterstützt. Wenn also das VPC-Netzwerk N1 mit N2 und N3 verbunden ist, aber N2 und N3 nicht direkt miteinander verbunden sind, kann das VPC-Netzwerk N2 nicht per VPC-Netzwerk-Peering mit dem VPC-Netzwerk N3 kommunizieren.

Weitere Informationen finden Sie unter Southbound-Netzwerkmuster.

Ursache: Konnektivitätsproblem am Ziel

Diagnose

Das Ziel ist möglicherweise nicht von der VPC aus erreichbar oder kann eine Verbindung nicht akzeptieren. Es gibt zwei Möglichkeiten, das Problem zu diagnostizieren.

Konnektivitätstest (private Ziel-IP-Adressen)

Wenn sich das Ziel in einem privaten Netzwerk befindet, können Sie mit dem Feature Konnektivitätstest häufige Ursachen diagnostizieren.

Ermitteln Sie die IP-Adresse des Ziels, die aus der Apigee-Instanz aufgelöst wurde. Eine der Methoden ist die Verwendung einer Debugging-Sitzung.

Rufen Sie unter "Debugging" AnalyticsPublisher (oder AX im klassischen Debugging) auf. Suchen Sie rechts auf dem Bildschirm nach dem Wert target.ip.

In diesem Beispiel lautet die IP 10.2.0.1. Dies ist eine private IP-Adresse, das heißt, wir können den Konnektivitätstest verwenden.
Notieren Sie sich die IP-Adresse der Apigee-Instanz, die keine Verbindung zum Ziel herstellen kann. Suchen Sie unter Instanzen in der Apigee Console die IP-Adresse der Apigee-Instanz im Feld IP-Adresse.
Wechseln Sie zu Konnektivitätstests und klicken Sie auf Konnektivitätstest erstellen. Geben Sie die folgenden Informationen an:
1. Quell-IP-Adresse: Verwenden Sie die IP-Adresse der Apigee-Instanz, die Sie in Schritt 2 oben abgerufen haben. Beachten Sie, dass dies nicht genau die Quell-IP ist, die von Apigee zum Senden einer Anfrage an das Ziel verwendet wird. Es reicht jedoch für den Test aus, da sie sich im selben Subnetz befindet.
2. Dies ist eine IP-Adresse, die in Google Cloud verwendet wird: Klicken Sie das Kästchen nicht an, es sei denn, die Adresse befindet sich in einem Ihrer Google Cloud-Projekte. Wenn Sie diesen Wert prüfen, geben Sie auch das Projekt und das Netzwerk an.
3. Geben Sie die Zieladresse (Schritt 1) und den Port als Ziel-IP-Adresse bzw. Zielport an.
Klicken Sie auf Erstellen und warten Sie, bis der Test die erste Ausführung abgeschlossen hat.
Klicken Sie in der Liste der Konnektivitätstests auf Ansehen, um die Ergebnisse der Ausführung aufzurufen.
Wenn das Ergebnis "Nicht erreichbar" lautet, liegt ein Problem mit der Konfiguration vor. Das Tool sollte Sie zur Dokumentation zu Konnektivitätstests-Status weiterleiten, um fortzufahren. Wenn der Status „Erreichbar“ lautet, sind viele Konfigurationsprobleme ausgeschlossen. Dies ist jedoch keine Garantie dafür, dass das Ziel erreichbar ist. Es wurde nicht versucht, eine TCP-Verbindung zum Ziel herzustellen. Nur mit der nächsten Diagnose unten lässt sich dies testen.

VM-Konnektivitätstest (alle Ziele)

Erstellen Sie in derselben VPC, die per Peering mit Apigee verbunden ist, unter Linux eine VM-Instanz.
Führen Sie Konnektivitätstests von der VM aus, vorzugsweise in dem Moment, in dem das Problem von Apigee reproduzierbar ist. Zum Herstellen einer Verbindung können Sie Telnet, curl und andere Dienstprogramme verwenden. Dieses curl-Beispiel wird in einer Schleife mit einem Zeitlimit von drei Sekunden ausgeführt. Wenn curl keine TCP-Verbindung innerhalb von drei Sekunden herstellen kann, schlägt der Vorgang fehl.
```
for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done
```
Prüfen Sie die vollständige Ausgabe und suchen Sie nach diesem Fehler:
```
* Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds
```
Das Vorhandensein dieses Fehlers bestätigt, dass das Problem außerhalb von Apigee reproduzierbar ist.

Bitte beachten Sie bei anderen Fehlern, z. B. TLS-Fehler oder fehlerhafte Statuscodes, dass sie die Zeitüberschreitung der Verbindung nicht bestätigen und in keinem Zusammenhang mit diesem Problem stehen.
Wenn für das Ziel eine IP-Zulassungsliste erforderlich ist, können Sie es möglicherweise nicht von einer VM aus testen, es sei denn, Sie lassen auch die IP-Adresse der VM-Instanz zu.

Lösung

Wenn Sie ein Problem auf Grundlage der Konnektivitätstests festgestellt haben, fahren Sie mit den dokumentierten Lösungsschritten fort.

Wenn die Zeitüberschreitung von einer VM reproduziert wird, gibt es keine klare Anleitung zur Behebung des Problems auf der Zielseite. Sobald das Zeitlimit für die Verbindung außerhalb von Apigee reproduzierbar ist, verfolgen Sie das Problem weiter von der VPC aus. Testen Sie die Konnektivität so nah wie möglich am Ziel.

Wenn sich das Ziel hinter einer VPN-Verbindung befindet, können Sie es möglicherweise auch über das lokale Netzwerk testen.

Wenn sich das Ziel im Internet befindet, können Sie versuchen, das Problem außerhalb der Google Cloud Console zu reproduzieren.

Wenn das Problem zu Spitzenzeiten auftritt, ist das Ziel möglicherweise mit Verbindungen überlastet.

Wenn Sie in dieser Phase einen Google Cloud-Supportfall auslösen müssen, müssen Sie die Apigee-Komponente nicht mehr auswählen, da das Problem jetzt direkt aus der VPC reproduzierbar ist.

Ursache: IP-Zulassungsliste am Ziel mit einigen oder allen Apigee-NAT-IP-Adressen, die nicht hinzugefügt wurden

Diagnose

Dies betrifft externe Ziele (das Internet), für die eine IP-Zulassungsliste aktiviert ist. Achten Sie darauf, dass alle Apigee NAT-IP-Adressen auf der betroffenen Zielseite hinzugefügt werden. Wenn am Ziel keine Zulassungsliste vorhanden ist, können Sie diesen Abschnitt überspringen.

Bei gelegentlichen Fehlern lässt sich das Problem leichter erkennen, da Sie in diesem Fall möglicherweise eine Korrelation zwischen bestimmten NAT-IP-Adressen und den Fehlern finden.

Wenn das Problem dauerhaft ist (alle Aufrufe schlagen fehl), achten Sie darauf, dass NAT-IP-Adressen in Apigee aktiviert sind, und rufen Sie sie mit den folgenden Schritten ab:

Listen Sie die NAT-IP-Adressen für eine Instanz auf:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Beispielantwort:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Wenn Sie in der Ausgabe keine Adressen erhalten, dann werden NAT-IP-Adressen auf Apigee-Seite nicht hinzugefügt. Wenn Sie Adressen erhalten, aber keine davon AKTIV ist, erlaubt keine der verwendeten Adressen den Zugriff auf das Internet. Dies ist ebenfalls ein Problem.

Wenn Sie mindestens eine AKTIVE Adresse haben, kann diese am Ziel auf die Zulassungsliste gesetzt werden, sodass auf Apigee-Seite keine Fehlkonfiguration vorliegt. In diesem Fall fehlt die Adresse möglicherweise in der Zulassungsliste am Ziel.

Wenn das Problem zeitweise auftritt, kann dies darauf hindeuten, dass nur ein Teil der NAT-IP-Adressen am Ziel zugelassen wurde. So erkennen Sie dies:

Erstellen Sie einen neuen Reverse-Proxy, bei dem das betroffene Ziel im TargetEndpoint angegeben ist. Sie können auch den vorhandenen Proxy wiederverwenden und mit dem nächsten Schritt fortfahren:
Fügen Sie dem Anfrage-PreFlow eine ServiceCallout-Richtlinie hinzu. Der ServiceCallout sollte "https://icanhazip.com", "https://mocktarget.apigee.net/ip" oder einen anderen öffentlichen Endpunkt aufrufen, der die IP-Adresse des Aufrufers in der Antwort zurückgibt. Speichern Sie die Antwort in der Variable „response“, damit der Inhalt in Debug sichtbar ist. Hier ist ein Beispiel für die Konfiguration einer ServiceCallout-Richtlinie:
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Service Callout-1</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>response</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://icanhazip.com</URL>
    </HTTPTargetConnection>
</ServiceCallout>
```
Sie können die Antwort auch in einer benutzerdefinierten Variablen speichern. Sie müssen jedoch den „.content“ dieser Variable mit der AssignMessage-Richtlinie lesen, um sie im Debug-Tool anzuzeigen.

Achten Sie darauf, dass das Ziel genau auf die gleiche Weise wie im betroffenen Proxy konfiguriert ist.

Hinweis: Die ServiceCallout-Anfrage und die Zielanfrage sollten in einer einzigen Transaktion erfolgen. Dadurch wird sichergestellt, dass derselbe Server eine Anfrage verarbeitet, sodass die NAT-IP-Adresse der betroffenen Anfrage mit der NAT-IP-Adresse übereinstimmt, die vom ServiceCallout abgerufen wurde.
Führen Sie eine Debug-Sitzung aus und klicken Sie auf den ServiceCallout-Schritt:
Rechts unten sollte der Abschnitt Antwortinhalt angezeigt werden, der die NAT-IP-Adresse (im Text) der Apigee-Instanz enthält, von der die Anfrage stammt. Wenn Sie die ServiceCallout-Antwort auch an einem anderen Ort speichern, sollte sie dort angezeigt werden.

Beachten Sie, dass der Proxy später im Ablauf das Ziel aufruft und der Antwortinhalt mit dem Fehler oder einer Antwort vom Ziel überschrieben wird.
Versuchen Sie, die NAT-IP-Adressen mit dem Problem zu korrelieren. Wenn nur bestimmte IP-Adressen fehlschlagen, ist dies ein Zeichen dafür, dass einige, aber nicht alle IP-Adressen am Ziel zugelassen sind.
Wenn Sie keine Korrelation zwischen NAT-IP-Adressen und den Fehlern sehen, z. B. wenn dieselbe IP-Adresse in einer Anfrage fehlschlägt, aber in einer anderen nicht, ist dies höchstwahrscheinlich kein Problem mit der Zulassungsliste. Dies kann an einer NAT-Erschöpfung liegen. Siehe Ursache: Erschöpfung des NAT-IP-Ports.

Lösung

Achten Sie darauf, dass NAT-IP-Adressen bereitgestellt und aktiviert sind und dass alle auf der Zielseite hinzugefügt werden.

Ursache: Erschöpfung des NAT-IP-Ports

Diagnose

Wenn das Problem nur von Apigee aus reproduzierbar ist und NAT-IP-Adressen für Ihr Unternehmen bereitgestellt werden und Sie sehen, dass es bei verschiedenen Zielen gleichzeitig auftritt, gehen Ihnen möglicherweise die NAT-Quellports aus:

Geben Sie den Zeitraum des Problems an. Beispiel: Täglich zwischen 17:58 und 18:08 Uhr.
Prüfen Sie, ob im selben Zeitraum auch ein anderes Ziel von dem Problem betroffen ist. Das andere Ziel muss über das Internet zugänglich sein und darf nicht am selben Standort wie das ursprünglich betroffene Ziel gehostet werden.
Stellen Sie fest, wenn Fehler nur über einem bestimmten Trafficvolumen in TPS auftreten. Notieren Sie sich dazu den Zeitraum des Problems und rufen Sie das Dashboard für die Proxy-Leistung auf.
Versuchen Sie, das Fehlerzeitfenster mit dem Anstieg der durchschnittlichen Transaktionen pro Sekunde (tps) zu korrelieren.

In diesem Beispiel steigt die tps um 17:58 Uhr auf 1000 an. Angenommen, in diesem Beispiel tritt das Problem genau um 17:58 Uhr auf und betrifft zwei oder mehr nicht miteinander in Verbindung stehende Ziele, dann ist dies ein Hinweis auf ein Problem mit der NAT-Erschöpfung.

Lösung

Berechnen Sie die NAT-IP-Anforderungen neu. Folgen Sie dazu der Anleitung unter Anforderungen für statische NAT-IP-Adressen berechnen.

Sie können auch weitere NAT-IP-Adressen hinzufügen und prüfen, ob das Problem dadurch behoben wird. Wenn Sie weitere IP-Adressen hinzufügen, müssen diese möglicherweise zuerst in allen Zielen auf die Zulassungsliste gesetzt werden.

Ursache: connect.timeout.millis-Wert zu niedrig

Diagnose

Möglicherweise ist der Wert für die Zeitüberschreitung im Proxy falsch konfiguriert.

Rufen Sie dazu den betroffenen Proxy auf und prüfen Sie den betreffenden TargetEndpoint. Beachten Sie das Attribut "connect.timeout.millis" und seinen Wert. In diesem Beispiel beträgt der Wert 50, also 50 Millisekunden. Er ist normalerweise zu niedrig, um eine TCP-Verbindung garantieren zu können. Wenn Sie einen Wert unter 1.000 sehen, ist dies wahrscheinlich die Ursache des Problems. Wenn Sie das Attribut "connect.timeout.millis" nicht sehen, ist der Standardwert festgelegt und die Ursache wurde nicht bestätigt.

Proxy mit Zeitüberschreitung

Lösung

Korrigieren Sie den Wert "connect.timeout.millis" und beachten Sie dabei, dass die Zeiteinheiten in Millisekunden angegeben werden. Der Standardwert ist 3.000, also 3.000 Millisekunden. Weitere Informationen finden Sie in der Referenz zu Endpoints-Attributen.

Wenden Sie sich an den Support, um weitere Unterstützung zu erhalten.

Wenn das Problem nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen für den Google Cloud-Support:

Projekt-ID und Name der Apigee-Organisation
Proxyname(n) und die Umgebung.
Zeitraum des Problems.
Häufigkeit des Problems
Ziel-Hostname
Fehlerbehebungssitzung mit dem Problem.
Ergebnis der Überprüfungen, die für die oben genannten möglichen Ursachen durchgeführt wurden. Beispielsweise die Ausgabe des Befehls curl von einer VM.