Sollten Sie AWS-VPN-Tunnelprotokolle auf einem laufenden Tunnel aktivieren?

Das Einschalten von Tunnel-Aktivitätsprotokollen für ein Site-to-Site-VPN ist eine kleine Änderung, die den Tunnel, den sie misst, ausfallen lassen kann. AWS warnt, dass das Aktivieren der Protokollierung auf einem bestehenden Tunnel ihn mehrere Minuten lang unterbrechen kann, die interessante Frage ist also nicht, wie man das Flag umlegt, sondern auf welchem Tunnel und wann. Drei Bedingungen bestimmen die Reihenfolge: ob der andere Tunnel die Routen wirklich trägt, ob Sie Dienstereignisse oder BGP-Ereignisse brauchen und ob die Änderung über die Konsole oder über die Tunneloptions-API läuft. Machen Sie das falsch, enden Sie entweder mit einem Ausfall oder mit einer Protokollgruppe voller Nichts.

Drei Bedingungen bestimmen die Reihenfolge

Beginnen Sie mit der Identität der Sache, die Sie ändern. Sie brauchen die VPN-Verbindungs-ID, die Region und die externe IP-Adresse des jeweiligen Tunnels, denn jede Protokolleinstellung in diesem Feature gilt pro Tunnel und nicht pro Verbindung. Eine Änderung, die auf die falsche externe Adresse angewendet wird, ist eine Änderung an einem Tunnel, den niemand debuggt hat.

Das Ziel ist eine CloudWatch-Protokollgruppe in derselben Region mit der Aufbewahrung und Zugriffsrichtlinie, die Sie tatsächlich wollen. AWS empfiehlt das Präfix /aws/vendedlogs/ für diese Gruppen, weil es die Größenbeschränkungen von Ressourcenrichtlinien vermeidet, an die einfache Namen stoßen können. Ein Name wie /aws/vendedlogs/vpn/branch-a-activity ist nur illustrativ; entscheidend ist, dass die Gruppe existiert, dass die Zustellrolle hineinschreiben kann und dass beides von dem verwaltet wird, dem die VPN-Konfiguration gehört. Der Name erteilt keine Berechtigungen, und eine ohne die Zustellrichtlinie erstellte Gruppe erzeugt Stille statt eines Fehlers.

Bedingung eins: ein redundanter Tunnel, der wirklich Verkehr trägt

Diese Bedingung überspringen Teams. Zwei konfigurierte Tunnel sind kein Beweis dafür, dass die Anwendung einen nutzbaren alternativen Pfad hat.

Bevor Sie einen Tunnel anfassen, bestätigen Sie, dass der andere die wichtigen Routen trägt: Prüfen Sie die Routentabelle auf der Seite des Kundengateways und bestätigen Sie, dass die Anwendung tatsächlich ausweichen kann. Das Unterbrechungsfenster von AWS beträgt Minuten, nicht Sekunden, und ein Tunnel, der nur auf dem Papier existiert, macht aus einer Diagnoseänderung einen Ausfall. Ist der redundante Pfad nicht nachgewiesen, planen Sie die Änderung mit derselben Sorgfalt wie jede andere Routingänderung, statt die Protokollierung als passiv zu behandeln. Instrumentieren Sie den Tunnel, dessen Verhalten Sie erklären wollen, nicht den, der leichter zu erreichen ist.

Bedingung zwei: Aktivitätsprotokoll oder BGP-Protokoll

Diese entscheidet, was Sie tatsächlich werden lesen können. Aktivitätsdatensätze decken Dienstereignisse wie IKE- und IPsec-Zustandsübergänge und DPD-Nachrichten ab, was Sie wollen, wenn der Tunnel nicht hochkommt oder ständig Schlüssel erneuert. BGP-Datensätze sind ein separater Strom mit eigenen Steuerungsmöglichkeiten, und sie beantworten eine andere Frage: ob Routen wie erwartet ausgetauscht und zurückgezogen wurden.

Das Aktivieren des Aktivitätsflags ist keine Anfrage für jeden Strom, den der Dienst aussenden kann. Wenn der Verdacht Routing ist, aktivieren Sie beides; wenn der Verdacht die Aushandlung von Phase 1 oder Phase 2 ist, ist der Aktivitätsstrom derjenige, der es zeigt.

Keiner der Ströme ist ein Paketmitschnitt, und dieser Unterschied entscheidet mehr Tickets, als er sollte. Aktivitäts- und BGP-Datensätze sagen Ihnen, was der Dienst mit dem Tunnel und der Sitzung getan hat, nicht was Ihre Anwendung durch ihn gesendet hat. Zu Tunnelprotokollen zu greifen, um einen Anwendungs-Timeout zu debuggen, ist ein Kategorienfehler, und er kostet meist ein Unterbrechungsfenster, bevor es jemand merkt. Wählen Sie zuerst die Frage, dann den Strom, der sie beantworten kann.

Bedingung drei: Konsolenänderung oder Tunneloptions-API

Wenn ein Mensch eine einmalige Änderung vornimmt, ist der Konsolenweg in Ordnung: VPC console, Site-to-Site VPN connections, Verbindung auswählen, Actions, Modify VPN tunnel options, externe IP wählen, Tunnel activity log aktivieren, Gruppe und Ausgabeformat wählen, innerhalb des Fensters speichern. Wird das VPN als Code verwaltet, ist derselbe Klick Drift, den Sie später abgleichen.

Für die Automatisierung hat der Aktivitätsprotokoll-Teil der Tunneloptionen eine feste Form: LogOptions enthält CloudWatchLogOptions mit LogEnabled, LogGroupArn und LogOutputFormat. Dieser Block ist ein Fragment, keine Anfrage; modify-vpn-tunnel-options braucht weiterhin die Verbindungs-ID und die externe IP des Tunnels, und die übrigen Tunneleinstellungen muss bewahren, wer die Vorlage besitzt. Die BGP-Protokollierung verwendet ihre eigenen Schlüssel BgpLogEnabled, BgpLogGroupArn und BgpLogOutputFormat in derselben Struktur. Lesen Sie die Änderung mit describe-vpn-connections zurück, statt darauf zu vertrauen, dass der Aufruf angewendet wurde.

Was die Datensätze Ihnen sagen können und was nicht

Wenn der erste Tunnel erledigt ist und der beabsichtigte Pfad verfügbar ist, wiederholen Sie dieselbe kontrollierte Sequenz für den zweiten Tunnel, wenn Sie dessen Protokolle ebenfalls brauchen. Ein Tunnel nach dem anderen ist der ganze Punkt.

Datensätze kommen in Strömen an, die durch die Verbindung und die externe Adresse des Tunnels identifiziert werden, korrelieren Sie also mit dieser Identität, statt zu erwarten, dass Verlauf rückwirkend erscheint. Nichts vor der Änderung existiert, und kein Warten füllt die Lücke. Wenn Sie eine Grundlinie brauchen, erfassen Sie den aktuellen Tunnelzustand und die Routentabelle vor der Änderung, damit es etwas zu vergleichen gibt.

Halten Sie die Protokollgruppe, ihre Aufbewahrung, ihre Zustellberechtigungen und den Tunneloptionsblock im selben Inventar wie das VPN selbst, denn sie sind eine Konfiguration, die auf vier Orte verteilt ist. Das AWS-Verfahren zum Aktivieren von Protokollen dokumentiert den Ablauf pro Tunnel und seine Unterbrechungswarnung, und es lohnt sich, es vor der Änderung zu lesen statt danach. Prüfen Sie dann der Reihe nach: Der Tunnel ist zurück, Datensätze erscheinen im erwarteten Strom, und die Datensätze beantworten die Frage, für die Sie das Ticket geöffnet haben. Wenn das dritte scheitert, war die Wahl des Stroms das Problem und nicht die Protokollierung.