Google HA VPN naar een Cisco-router: plan eerst de peer-resource
Benoem beide Google-interfaces, de peer-resource, het IKEv2-contract en elke BGP-sessie voordat u de Cisco-router configureert, en kies daarna één peer of twee.
De eerste beslissing in een HA VPN van Cisco naar Google is niet welk cryptoprofiel u gebruikt, maar of één on-premises apparaat of twee de tunnels beëindigt. De HA VPN-gateway van Google heeft twee interfaces, en elk verwacht een bijbehorende peertunnel. Dat geeft u twee tunnels of u nu twee routers hebt of niet, en het verschil is of één enkele voeding of een software-upgrade het hele ontwerp kan omverwerpen.
De beslissing is één peer-apparaat of twee
Kies de opzet op basis van drie voorwaarden: of u een lokaal storingspunt kunt accepteren, of beide cloudinterfaces moeten worden gebruikt, en hoeveel reconvergentie uw workloads verdragen. Als een van de drie een harde eis is, zijn twee peer-apparaten het eerlijke antwoord.
Bepaal dat voordat u een console opent, want het antwoord verandert hoeveel tunnels en BGP-sessies het werkblad moet beschrijven.
Schrijf het werkblad voordat u een opdracht geeft
Het werkblad heeft vijf rijen, en elke rij heeft een eigenaar nodig:
| 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 |
De externe peer-resource beschrijft uw interfaces binnen Google Cloud, en het aanmaken ervan configureert de Cisco-router niet. Die asymmetrie verrast mensen die verwachten dat de cloudconsole de bron van waarheid is voor beide uiteinden. Het is een verklaring van wat Google mag verwachten, en de router moet er nog steeds bij passen. De handleiding voor de peergateway van Google koppelt die verklaring aan het tunnel-, BGP-, firewall- en IKE-werk dat u nog verschuldigd bent.
Als een rij geen eigenaar heeft, wordt die ingevuld door wie tijdens de overgang dienst heeft.
Houd de drie adresrollen gescheiden
De openbare peeradressen dragen de buitenste IPsec-uitwisseling. Het interne BGP-paar hoort bij de beschermde logische verbinding die eroverheen loopt. De aangekondigde LAN- en VPC-prefixen beschrijven de workloads achter die verbinding. Het interne adres van een VM naar het externe peerveld kopiëren mengt de eerste twee rollen, en de storing lijkt op een onderhandelingsprobleem in plaats van een invoerfout.
Plan twee bijbehorende peertunnels, één voor elke HA VPN-interface. Het gebruik van beide cloudinterfaces neemt het lokale storingspunt niet op zichzelf weg, omdat beide tunnels nog steeds op dezelfde behuizing kunnen landen.
Schrijf de adresrol naast elke waarde in het werkblad. Die ene gewoonte voorkomt het grootste deel van de vermenging.
Vertaal het werkblad naar de Cisco-release
Begin bij de ondersteunde peerdocumentatie of een passende Google-configuratiesjabloon voor uw platform, en stem daarna elke plaatsaanduiding af op het werkblad. Controleer IKEv2-authenticatie, ESP-voorstellen, PFS en het tunnel- en routeringsmodel samen, omdat een mismatch in een ervan zich meestal voordoet als een mismatch in een ander. Gebruik het werkelijke platform en de software-release om te kiezen wat wordt ondersteund, aangezien een Classic VPN-recept een ander startpunt is.
Houd het gedeelde geheim buiten schermafbeeldingen, ticketbijlagen en supportnotities. Een vooraf gedeelde sleutel die in een casecommentaar wordt geplakt, is een onthulling van inloggegevens, geen hulpmiddel bij probleemoplossing.
Als het sjabloon en het werkblad het niet eens zijn, stop dan en los het op papier op. Het apparaat zal niet voor u arbitreren.
Accepteer elke tunnel op zijn eigen bewijs
HA VPN heeft BGP-sessies nodig, en een geslaagde IKE-onderhandeling brengt alleen de eerste fase tot stand. De interne sessie moet omhoogkomen, de bedoelde prefixen moeten worden aangekondigd en geaccepteerd, en bruikbare routes plus firewallrechten moeten bestaan voordat werkbelastingverkeer beweegt. Dat als één groen licht vastleggen verbergt welke fase werkelijk is mislukt.
Leg acceptatiebewijs per tunnel vast: onderhandelde beveiligingsassociaties, BGP-buurstatus, verwachte geleerde prefixen en het bedoelde werkbelastingpad. Voer daarna een gecontroleerde fout- en hersteltest uit, want een tunnel die nooit is uitgevallen, is een tunnel waarvan het herstelpad niet is getest.
Die registratie is herbruikbaar de volgende keer dat het ontwerp verandert, en het is het verschil tussen een interoperabiliteit en een commandofragment waarvan de aannames verloren zijn gegaan.