Cloud VPN-Grenzen, die Sie nicht tunen können: IKE-Lebensdauer und Peer-NAT

Geben Sie dem entfernten Gerät eine Phase-1-Lebensdauer von 24 Stunden, und der Cloud VPN-Tunnel bleibt unten, obwohl auf Google-Seite alles korrekt konfiguriert ist. Der Peer schlägt einen Wert vor, den der Responder nicht akzeptiert, also scheitert die Verhandlung entweder ganz oder startet endlos neu. Cloud VPN begrenzt Phase 1 auf 36,000 Sekunden, also zehn Stunden, und diese Obergrenze ist keine Einstellung, die Sie anheben können. Die Änderung gehört auf das entfernte Gerät.

Der Peer fragt, der Responder entscheidet

IKE ist eine Abgleichsübung zwischen zwei Vorschlagsmengen. Der Tunnel entsteht nur dort, wo sich die Mengen innerhalb der Grenzen überschneiden, die der Responder akzeptiert, weshalb eine Lebensdauer außerhalb des Bereichs gar keinen teilweisen Tunnel erzeugt. Der übliche Fehler ist, die Konfiguration des Peers als Wunschliste statt als Vorschlag zu behandeln. Eine leere Schnittmenge lässt den Tunnel unten, so korrekt Routing und Selektoren auch sind.

Lesen Sie den eigenen Zustand des Tunnels, bevor Sie einen Fall eröffnen, denn der detaillierte Status nennt meist die Phase, die fehlgeschlagen ist:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Vergleichen Sie die Rückgabe mit der unterstützten Menge für Ihren Gateway-Typ und Ihre IKE-Version und notieren Sie beide Traffic-Selektoren, während Sie dort sind. Eine Selektor-Abweichung erzeugt dasselbe Symptom eines liegenden Tunnels wie eine Algorithmus-Abweichung, und anders als beim Algorithmus ist diese Ihre Baustelle.

36,000 Sekunden sind die Obergrenze

Phase 1 endet bei 36,000 Sekunden. Ein Gerät, das auf 86,400 gesetzt ist, verlangt etwas, dem der Responder nie zustimmen wird, und ein erneuter Versuch ändert seine Meinung nicht. Drehen Sie den entfernten Vorschlag in den Bereich zurück, und dieselbe Konfiguration kommt zustande; die Asymmetrie ist die ganze Lektion, denn Sie dürfen Ihren Wert senken und Googles nicht anheben.

Schreiben Sie den gewählten Wert in die Designnotizen. Sonst wiederholt der nächste Ingenieur das 24-Stunden-Experiment und stößt an dieselbe Wand.

Die unterstützte Menge wird pro Gateway-Typ und IKE-Version veröffentlicht in der Cloud VPN-Übersicht, lesen Sie also den Abschnitt für Ihre Topologie statt eines allgemeinen IKE-Leitfadens.

Ein Tunnel, der nach Plan fällt

Phase 2 verhält sich anders: Wenn sich die beiden Enden nicht einig sind, folgt die Schlüsselerneuerung dem kürzeren Intervall. Ein Peer, der die Abweichung für fatal hält, lässt den Tunnel stattdessen fallen, sodass eine Abweichung wie zwei unabhängige Fehler aussehen kann. Achten Sie auf den Rhythmus der Schlüsselerneuerung, nicht nur auf die erste Verbindung. Ein Tunnel, der hochkommt und dann im regelmäßigen Takt umfällt, ist häufiger eine Lebensdauer-Abweichung als ein Routing-Defekt.

Korrelieren Sie diese Ausfall-Zeitstempel mit den eigenen Logs des Peers, bevor Sie etwas ändern, denn eine Selektor- oder Routenänderung kann denselben Rhythmus nachahmen. Passt der Takt zum Phase-2-Timer, ist die Ursache gefunden, ohne einen Vorschlag anzufassen.

Die Suiten kommen vom Gateway-Typ

Cipher- und Integritätssuiten sind kein Profil pro Tunnel, das Sie bearbeiten, wie strongSwan es erlaubt. Sie wählen sie nach Gateway-Typ und IKE-Version, und die Suche nach einem Profil, das es nicht gibt, kostet einen Nachmittag.

Ein Altgerät, das nichts innerhalb der unterstützten Menge anbietet, lässt zwei ehrliche Wege: das Gerät ersetzen oder auf einem Software-Gateway terminieren, das Sie kontrollieren, und von dort in die VPC routen. Alles andere ist ein Workaround, der das nächste Review nicht besteht.

Eine externe Adresse pro Gerät

Die externe Adresse des Peers muss eins zu eins auf seine interne Adresse abgebildet werden. Ein überlasteter PAT-Pool kann nicht funktionieren, weil mehrere Hosts hinter einer einzigen öffentlichen Adresse dem Responder keine Möglichkeit geben, sie zu demultiplexen. Wo mehrere Hosts sich eine Adresse teilen müssen, muss der Tunnel dort enden, wo man sie unterscheiden kann.

Halten Sie diese externe Adresse auch stabil. Verschieben Sie das Gerät hinter ein anderes NAT, und die Zuordnung bricht, obwohl jeder Vorschlag noch passt. Es lohnt sich, aufzuschreiben, welche Werte Googles sind und welche Ihre: Lebensdauern, Suiten und Eins-zu-eins-NAT sind auf ihrer Seite fest, während Vorschläge, Selektoren, Routing und BGP-Prioritäten Ihre sind.