Cloud VPN-Status: zuerst den Ressourcenzustand, dann das IKE-Log lesen

Ein Cloud VPN-Tunnel durchläuft zwei Lebenszyklen gleichzeitig, und sie laufen nicht auf derselben Uhr. Die Ressource muss zugewiesen und konfiguriert sein, bevor sie verhandeln kann, und danach hat das Protokoll seine eigene Abfolge von IKE-Nachrichten. Ein Statusfeld kann den ersten melden und dabei nichts Nützliches über den zweiten sagen. Beides als eines zu lesen ist der Weg, auf dem eine Schlüsselabweichung die Schuld an einer Bereitstellungsverzögerung bekommt.

Beginnen Sie mit einem Tunnelobjekt und einem Zeitfenster.

Zwei Lebenszyklen, ein Tunnelobjekt

Der Lebenszyklus der Ressource ist die Vorbereitung des Tunnels durch den Anbieter: Adressen, Konfiguration, Kapazität. Der Lebenszyklus des Protokolls beginnt, sobald beide Seiten genug Konfiguration haben, um IKE_SA_INIT auszutauschen, dann IKE_AUTH, dann untergeordnete Sicherheitsassoziationen. Ein Tunnel, der noch in der ersten Phase ist, ist nicht an der Authentifizierung gescheitert, weil die Authentifizierung noch nicht versucht wurde.

Diese Unterscheidung ist das ganze Problem. Alles andere ist die Frage, wie man sie beobachtet, ohne unzusammenhängende Meldungen zu verschmelzen.

Lesen Sie das Objekt, nicht die Konsolenzusammenfassung

Fragen Sie die API nach den beiden Feldern, auf die es ankommt, und nach nichts anderem, damit die Antwort klein genug bleibt, um sie um drei Uhr morgens zu lesen: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Das Feld status benennt die Lebenszyklusphase, und detailedStatus trägt den lesbaren Grund, der daran hängt. Ein vollständiger Konfigurationsauszug beantwortet andere Fragen und lässt sich schlechter in ein Ticket einfügen. Solche reinen Leseaufrufe können den Tunnel nicht ändern, was zählt, solange der Vorfall noch läuft.

Notieren Sie den Zeitstempel des Aufrufs neben den Werten, weil sich beide Felder bewegen.

ALLOCATING_RESOURCES ist keine Schlüsselabweichung

Wenn der Tunnel ALLOCATING_RESOURCES meldet, setzt der Anbieter das Objekt noch zusammen. Eine Abweichung des vorab geteilten Schlüssels ist in dieser Phase nicht zu beobachten, und ein blockierter Peer-Port ist ebenso unbewiesen. Prüfen können Sie die detaillierte Meldung, ob Projekt und Dienst gesund aussehen und ob die Tunnelkonfiguration vollständig genug ist, damit der Peer überhaupt kontaktiert werden kann. Das Geheimnis jetzt zu ersetzen ändert einen Wert, der nie getestet wurde.

Warten Sie, bis sich der Zustand bewegt, bevor Sie einen Schluss über die Konfiguration ziehen.

ESTABLISHED ist der Beginn der Zugriffsprüfungen

Ein etablierter Tunnel bedeutet, dass IKE abgeschlossen ist, nicht dass Verkehr fließt. Bestätigen Sie die Routen, die der Tunnel trägt, und wo ein Cloud Router beteiligt ist, bestätigen Sie die BGP-Sitzung und die Präfixe, die sie gelernt hat. Testen Sie dann einen erlaubten Anwendungsaustausch, denn eine Firewallregel oder eine fehlende Route kann Verkehr durch einen völlig gesunden Tunnel blockieren. Jedes davon ist eine eigene Beobachtung mit einer eigenen Korrektur.

Der Status sagt Ihnen, welche Frage als Nächstes zu stellen ist. Er beantwortet die Zugriffsfrage nie für Sie.

Ein Objekt und ein Zeitfenster korrelieren

Ein alter Authentifizierungsfehler im Log gehört zu einem früheren Versuch, es sei denn, sein Zeitstempel fällt in das Fenster, das Sie untersuchen. Ziehen Sie die Logs für die Tunnelressource für dieselben Minuten wie den aufgezeichneten Status und halten Sie die Bezeichner zusammen. Ein späteres IKE-Ereignis kann zeigen, dass die Verhandlung begonnen hat, während die Konsolenmeldung, auf die Sie starren, bereits veraltet ist.

Wenn sich der Tunnel erholt, bevor Sie etwas sammeln, sagen Sie das. Eine unbestimmte Ursache ist ein besserer Eintrag als eine selbstsichere Geschichte aus unzusammenhängenden Zeilen.

Der nächste Schritt hat immer dieselbe Form: ein Objekt, ein Fenster, eine Phase. Alles Breitere ist eine Zusammenfassung, keine Diagnose.