Der Tunnel fällt in dem Moment aus, in dem die beiden Enden sich über den Pre-Shared Key uneinig sind, und er bleibt unten, bis beide Seiten den neuen Wert tragen. Dieser Teil ist zu erwarten: AWS behandelt die Änderung als Unterbrechung des ausgewählten Tunnels, und der Peer wird IKE nicht abschließen, solange die Schlüssel abweichen. Was die Leute überrascht, ist die zweite Hälfte. Der andere Tunnel übernimmt den Verkehr nicht von selbst, es sei denn, Sie haben geprüft, dass er ihn tragen kann. Rotieren Sie in dieser Reihenfolge, und die Unterbrechung bleibt in einem Tunnel.

Was tatsächlich passiert, wenn der Schlüssel wechselt

ModifyVpnTunnelOptions schreibt die Optionen für einen Tunnel neu, der durch seine externe IP-Adresse identifiziert wird. Der Tunnel wird abgebaut und neu aufgebaut, sodass IKE und IPsec mit dem neuen Schlüssel von Grund auf verhandeln. AWS gibt an, dass die Unterbrechung mehrere Minuten dauern kann, was lange genug ist, damit ein Routing-Protokoll es bemerkt. Der andere Tunnel in derselben Verbindung wird durch den Aufruf nicht berührt.

Es gibt einen zweiten Effekt, den man kennen sollte, bevor man etwas sendet. Der Änderungsvorgang übernimmt den vollständigen Satz von Tunneloptionen, sodass ein ausgelassenes Feld mit seinem Standardwert zurückgeschrieben wird. Wenn Sie die Lebensdauern von Phase 1 oder Phase 2 oder die Einstellungen zur Erkennung toter Peers angepasst haben, übergeben Sie die aktuellen Werte in derselben Anfrage oder planen Sie, sie danach wiederherzustellen.

Lesen Sie zuerst die aktuellen Werte und ändern Sie dann ein Feld. Diese Reihenfolge ist die ganze Disziplin dieser Aufgabe.

Ordnen Sie den AWS-Tunnel zuerst dem richtigen Peer zu

Die Konsole kennzeichnet Tunnel nach der Reihenfolge, und Ihr Gerät verwendet diese Kennzeichnung nicht. Identifizieren Sie den Tunnel anhand seiner externen IP-Adresse und ordnen Sie ihn dem Peer-Abschnitt am Kundengateway zu. Tunnel 1 in einer lokalen Konfiguration ist kein Beweis dafür, dass Sie den Tunnel bearbeiten, den AWS Tunnel 1 nennt.

Beginnen Sie bei der Verbindung selbst, die beide Tunnel und den Schlüssel auflistet, den jeder gerade hält:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

Der zurückgegebene Schlüssel ist der gerade verwendete. Vergleichen Sie ihn mit der Peer-Konfiguration, bevor Sie etwas ändern, denn eine bereits bestehende Abweichung erklärt einen Tunnel, der nie stabil war.

Lassen Sie zuerst den anderen Tunnel den Verkehr tragen

Zwei Tunnel in einer Verbindung beweisen nicht, dass Ihr Gerät beide konfiguriert hat, dass beide die benötigten Präfixe ankündigen oder dass Verkehr zwischen ihnen fließt. Prüfen Sie die Aushandlung des alternativen Tunnels, seine Routen und einen echten Anwendungsfluss in beide Richtungen. Bei BGP ist eine aktive Nachbarschaft ein nützlicher Beweis, aber nicht dasselbe wie die Bestätigung der Präfixe. Bei statischem Routing bestätigen Sie, wie das Gateway den Pfad wählt und was es tut, wenn der bevorzugte verschwindet.

Wenn der alternative Tunnel die Last nicht tragen kann, planen Sie die Unterbrechung oder reparieren Sie den alternativen Tunnel, bevor Sie den Schlüssel anfassen. Ein Statuslicht auf einer Konsolenseite ist kein Versprechen unterbrechungsfreien Dienstes.

Rotieren Sie einen Tunnel und prüfen Sie dann mit echtem Verkehr

Wenn der alternative Pfad bewiesen ist, ist die Reihenfolge kurz. Notieren Sie die Tunneladresse, ihren Peer und die nicht geheimen Einstellungen, und halten Sie einen Verwaltungspfad zum Gateway, der nicht von dem Tunnel abhängt, den Sie gleich brechen.

  1. Aktualisieren Sie den Peer des Kundengateways für die ausgewählte externe Adresse, oder bereiten Sie die Änderung so vor, dass sie Sekunden nach dem API-Aufruf greift.
  2. Senden Sie den Änderungsaufruf mit dem neuen Schlüssel plus den aktuellen Lebensdauern und DPD-Werten.
  3. Warten Sie, bis IKE und IPsec zurückkommen, und bestätigen Sie dann die Routen und die erforderlichen Präfixe.
  4. Schicken Sie einen repräsentativen Anwendungsfluss durch diesen Tunnel und beobachten Sie beide Richtungen.

Der Tunnel ist unbrauchbar, solange die Enden uneinig sind und solange AWS die Änderung anwendet, daher muss die Peer-Aktualisierung sofort folgen und nicht nach dem Mittagessen. Erst wenn der geänderte Tunnel echten Verkehr trägt, sollten Sie das Verfahren am anderen wiederholen.

Stoppen Sie, wenn Wiederherstellung oder Routing nach dem ersten Tunnel noch unsicher sind. Zwei halb funktionierende Tunnel sind schlechter als einer, von dem Sie wissen, dass er funktioniert.

Wenn die Wiederherstellung stockt, lesen Sie die IKE-Seite

Ein Tunnel, der unten bleibt, nachdem beide Enden den neuen Schlüssel haben, ist normalerweise eine Richtlinienabweichung, die die Rotation aufgedeckt und nicht verursacht hat. Die Vorschläge, die Identität, die der Peer sendet, und die Traffic-Selektoren müssen alle mit der AWS-Seite übereinstimmen, und ein Wert, der einen etablierten Tunnel überstanden hat, kann während einer neuen Aushandlung dennoch abgelehnt werden. Lesen Sie den Aushandlungsstatus und die daran angehängte Meldung, bevor Sie den Schlüssel ein zweites Mal ändern.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Wenn die Änderung rückgängig gemacht werden muss, stellen Sie den alten Schlüssel nicht nur deshalb wieder her, weil er früher funktioniert hat. Behandeln Sie einen kompromittierten Schlüssel als kompromittiert und reparieren Sie stattdessen die Aushandlung. Schließen Sie mit verifizierten beiden Tunneln und aktualisiertem Geheimnisinventar ab, damit jeder Peer festhält, welchen Wert er hält, und halten Sie die AWS-Dokumentation zu den Tunneloptionen neben dem Runbook.

Ähnliche Artikel