So bringen Sie AWS dazu, einen Site-to-Site VPN-Tunnel zu starten
Startaktion und DPD-Timeout-Aktion beantworten unterschiedliche Fragen. Setzen Sie diejenige, die AWS initiieren lässt, und prüfen Sie dann die Peer-Adresse und die Route der Anwendung.
Standardmäßig wartet ein AWS Site-to-Site VPN darauf, dass das customer gateway die Aushandlung beginnt. Dieser Standard ist eine Einstellung und kein Gesetz, und die Einstellung heißt Startup action. Bevor Sie danach greifen, trennen Sie zwei Fragen, die ständig vermischt werden: Wer baut den Tunnel auf, und haben die Pakete, die Sie interessieren, eine Route hindurch. Nur die erste Frage steckt in den Tunneloptionen.
Trennen Sie die Startaktion von der DPD-Timeout-Aktion
Zwei Optionen pro Tunnel steuern zwei verschiedene Ereignisse, und die eine zu setzen sagt nichts über die andere aus.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
Soll AWS einen neuen oder geänderten Tunnel aufbauen, wählen Sie start. Soll AWS die Aushandlung auch nach einem DPD-Timeout neu starten, konfigurieren Sie restart für dieses Ereignis separat. Keine der Optionen ist eine Wiederholungsrichtlinie der Anwendung, und keine ist ein Rekey-Intervall: DPD prüft, ob der Peer lebt, während Rekeying die security associations auf einem laufenden Tunnel ersetzt.
Eine Anwendung, die in einen Timeout läuft, während der Tunnel noch up meldet, hat ein Problem im Datenpfad. Ein kürzerer DPD-Timer behebt das nicht und kann Unruhe erzeugen, die Sie später erklären müssen.
Prüfen Sie, ob AWS überhaupt ein Ziel für die Aushandlung hat
Die Initiierung von AWS-Seite geht nur mit IKEv2, und AWS braucht die öffentliche Adresse des customer gateway, um zu wissen, wohin der Vorschlag gehen soll. Der Fall, der weh tut, ist eine zertifikatsauthentifizierte customer gateway-Ressource, die ohne Adresse erstellt wurde: Die AWS-Dokumentation beschreibt, eine neue customer gateway-Ressource mit der Adresse anzulegen und dann die VPN-Verbindung darauf zu ändern.
Ein Zertifikat beweist, wer der Peer ist. Es sagt AWS nicht, wo der Peer ist, und das sind zwei verschiedene Anforderungen. Deshalb ist die Lösung eine neue customer gateway-Ressource und kein neues Zertifikat. Ein Zertifikatstausch lässt AWS mit demselben fehlenden Ziel zurück.
Wenn das customer gateway hinter NAT sitzt, braucht AWS außerdem eine konfigurierte responder identity, IDr, damit die Identität des Peers zu dem passt, was das Gerät erwartet. Bestätigen Sie diesen Wert und den Firewallpfad, der IKE-Verkehr zulässt, bevor Sie die Option beschuldigen, die Sie gerade geändert haben. Die Wahl von start kann einen nicht erreichbaren oder falsch identifizierten Peer nicht dazu bringen, einen Vorschlag zu akzeptieren.
Wenden Sie die Änderung auf einen Tunnel an und rechnen Sie mit einer Unterbrechung
Eine VPN-Verbindung hat zwei Tunnel mit unabhängigen Optionen, prüfen Sie also anhand der Außenadresse, welchen Sie bearbeiten. AWS erlaubt, jeweils einen Tunnel zu ändern, und die Konnektivität über den gewählten Tunnel kann mehrere Minuten unterbrochen sein.
- Wählen Sie die Site-to-Site VPN-Verbindung und öffnen Sie Modify VPN tunnel options.
- Wählen Sie den Tunnel über die Außen-IP-Adresse und bestätigen Sie seine IKE-Version und die customer gateway-Ressource.
- Setzen Sie die Start- und DPD-Aktionen, die Sie wirklich wollen, und speichern Sie in einem Fenster, das Sie kontrollieren.
- Bestätigen Sie, dass der geänderte Tunnel aufgebaut wird, und prüfen Sie den anderen Tunnel und das Routing vor der nächsten Änderung.
Ein Verhalten verdient vor der Wartung Aufmerksamkeit. Mit aktivierter AWS-Initiierung gibt es kein Timeout: AWS versucht es weiter, bis der Tunnel steht, und initiiert erneut, wenn das customer gateway eine delete-SA-Nachricht sendet. Nehmen Sie den Peer absichtlich herunter, klopft AWS weiter an, und die Logs des Peers werden es zeigen.
Prüfen Sie den Pfad der Anwendung, nicht nur den Tunnelzustand
Ein Tunnel, der up meldet, ist nicht dasselbe wie eine funktionierende Anfrage. Eine an eine VPC angebundene Lambda-Funktion braucht weiterhin eine Subnet-Route zum Präfix des Kunden, Security-Group- und Network-ACL-Regeln, die den Verkehr zulassen, Namensauflösung, die die richtige Adresse zurückgibt, und einen Rückweg auf der Kundenseite.
Testen Sie einmal mit einer echten Anfrage aus dem Kontext der Anwendung und lesen Sie dann die flow logs, wenn es fehlschlägt. Keepalive-Verkehr ist eine legitime Option, wenn die AWS-Initiierung aus ist und ein ruhender Tunnel Pakete braucht, um oben zu bleiben, aber es sollte eine Monitoring-Entscheidung sein, die Sie benennen können, keine unerklärte Ping-Schleife, die an eine Funktion geschraubt ist.
Wählen Sie zuerst, wer den Tunnel aufbaut, und diagnostizieren Sie dann den verbleibenden Fehler in seiner eigenen Schicht. Die AWS-Dokumentation zur Initiierung deckt die Anforderungen an Adresse, Identität und Wiederholung ausführlicher ab als die Hinweise in der Konsole.