Google HA VPN zu einem Cisco-Router: Planen Sie zuerst die Peer-Ressource
Benennen Sie beide Google-Schnittstellen, die Peer-Ressource, den IKEv2-Vertrag und jede BGP-Sitzung, bevor Sie den Cisco-Router konfigurieren, und wählen Sie dann einen Peer oder zwei.
Die erste Entscheidung bei einem HA VPN von Cisco zu Google ist nicht, welches Kryptoprofil verwendet wird, sondern ob ein lokales Gerät oder zwei die Tunnel terminieren. Das HA VPN Gateway von Google hat zwei Schnittstellen, und jede erwartet einen entsprechenden Peer-Tunnel. Das ergibt zwei Tunnel, unabhängig davon, ob Sie zwei Router haben, und der Unterschied ist, ob ein einziges Netzteil oder ein Software-Upgrade das gesamte Design umwerfen kann.
Die Entscheidung lautet ein Peer-Gerät oder zwei
Wählen Sie das Layout anhand von drei Bedingungen: ob Sie einen lokalen Fehlerpunkt akzeptieren können, ob beide Cloud-Schnittstellen genutzt werden müssen und wie viel Rekonvergenz Ihre Workloads tolerieren. Wenn eine der drei eine harte Anforderung ist, sind zwei Peer-Geräte die ehrliche Antwort.
Entscheiden Sie das, bevor Sie eine Konsole öffnen, denn die Antwort ändert, wie viele Tunnel und BGP-Sitzungen das Arbeitsblatt beschreiben muss.
Schreiben Sie das Arbeitsblatt, bevor Sie einen Befehl eingeben
Das Arbeitsblatt hat fünf Zeilen, und jede braucht einen Verantwortlichen:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Die externe Peer-Ressource beschreibt Ihre Schnittstellen in Google Cloud, und ihr Anlegen konfiguriert nicht den Cisco-Router. Diese Asymmetrie überrascht Leute, die erwarten, dass die Cloud-Konsole die Wahrheitsquelle für beide Enden ist. Sie ist eine Erklärung dessen, was Google erwarten soll, und der Router muss weiterhin dazu passen. Googles Leitfaden für Peer-Gateways ordnet diese Erklärung der Tunnel-, BGP-, Firewall- und IKE-Arbeit zu, die Sie noch schulden.
Hat eine Zeile keinen Verantwortlichen, wird sie von demjenigen ausgefüllt, der während der Umstellung Dienst hat.
Halten Sie die drei Adressrollen auseinander
Die öffentlichen Peer-Adressen tragen den äußeren IPsec-Austausch. Das innere BGP-Paar gehört zu der geschützten logischen Verbindung, die darüber läuft. Die angekündigten LAN- und VPC-Präfixe beschreiben die Workloads hinter dieser Verbindung. Eine interne VM-Adresse in das externe Peer-Feld zu kopieren vermischt die ersten beiden Rollen, und der Fehler sieht wie ein Aushandlungsproblem aus statt wie ein Eingabefehler.
Planen Sie zwei entsprechende Peer-Tunnel, einen für jede HA VPN-Schnittstelle. Die Nutzung beider Cloud-Schnittstellen beseitigt den lokalen Fehlerpunkt nicht von selbst, denn beide Tunnel können immer noch auf demselben Gehäuse landen.
Schreiben Sie die Adressrolle neben jeden Wert im Arbeitsblatt. Diese eine Gewohnheit verhindert die meiste Vermischung.
Übersetzen Sie das Arbeitsblatt in die Cisco-Version
Beginnen Sie mit der unterstützten Peer-Dokumentation oder einer passenden Google-Konfigurationsvorlage für Ihre Plattform und gleichen Sie dann jeden Platzhalter mit dem Arbeitsblatt ab. Prüfen Sie IKEv2-Authentifizierung, ESP-Vorschläge, PFS sowie das Tunnel- und Routingmodell gemeinsam, denn eine Abweichung bei einem von ihnen zeigt sich meist als Abweichung bei einem anderen. Wählen Sie anhand der tatsächlichen Plattform und Softwareversion aus, was unterstützt wird, da ein Classic VPN-Rezept ein anderer Ausgangspunkt ist.
Halten Sie das gemeinsame Geheimnis aus Screenshots, Ticket-Anhängen und Support-Notizen heraus. Ein in einen Fallkommentar eingefügter vorab geteilter Schlüssel ist eine Offenlegung von Anmeldedaten, kein Fehlerbehebungsartefakt.
Wenn Vorlage und Arbeitsblatt nicht übereinstimmen, halten Sie an und klären Sie es auf dem Papier. Das Gerät wird nicht für Sie schlichten.
Akzeptieren Sie jeden Tunnel anhand seines eigenen Nachweises
HA VPN braucht BGP-Sitzungen, und eine erfolgreiche IKE-Aushandlung stellt nur die erste Phase her. Die innere Sitzung muss hochkommen, die vorgesehenen Präfixe müssen angekündigt und akzeptiert werden, und nutzbare Routen sowie Firewall-Berechtigungen müssen existieren, bevor Workload-Verkehr fließt. Dies als ein einziges grünes Licht zu erfassen, verbirgt, welche Phase tatsächlich versagt hat.
Erfassen Sie Abnahmenachweise pro Tunnel: ausgehandelte Sicherheitsassoziationen, BGP-Nachbarzustand, erwartete gelernte Präfixe und den vorgesehenen Workload-Pfad. Führen Sie dann eine kontrollierte Fehler- und Wiederherstellungsprüfung durch, denn ein Tunnel, der nie ausgefallen ist, ist ein Tunnel, dessen Wiederherstellungspfad ungetestet ist.
Dieser Nachweis lässt sich beim nächsten Designwechsel wiederverwenden und ist der Unterschied zwischen einer Interoperabilität und einem Befehlsschnipsel, dessen Annahmen verloren gingen.