Google HA VPN til en Cisco-router: planlæg modpartsressourcen først
Navngiv begge Googles grænseflader, modpartsressourcen, IKEv2-kontrakten og hver BGP-session, før du konfigurerer Cisco-routeren, og vælg derefter én modpart eller to.
Den første beslutning i en HA VPN fra Cisco til Google er ikke, hvilken kryptoprofil der skal bruges, men om én lokal enhed eller to skal afslutte tunnelerne. Googles HA VPN-gateway har to grænseflader, og hver især forventer en tilsvarende modpartstunnel. Det giver dig to tunneler, uanset om du har to routere eller ej, og forskellen er, om én enkelt strømforsyning eller softwareopgradering kan vælte hele designet.
Beslutningen er én modpartsenhed eller to
Vælg layoutet ud fra tre betingelser: om du kan acceptere et lokalt fejlpunkt, om begge cloud-grænseflader skal bruges, og hvor meget rekonvergens dine arbejdsbelastninger tolererer. Hvis nogen af de tre er et hårdt krav, er to modpartsenheder det ærlige svar.
Beslut det, før du åbner en konsol, fordi svaret ændrer, hvor mange tunneler og BGP-sessioner regnearket skal beskrive.
Skriv regnearket, før du giver nogen kommando
Regnearket har fem rækker, og hver især kræver en ejer:
| 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 |
Den eksterne modpartsressource beskriver dine grænseflader i Google Cloud, og oprettelsen af den konfigurerer ikke Cisco-routeren. Den asymmetri overrasker folk, der forventer, at cloud-konsollen er sandhedskilden for begge ender. Det er en erklæring om, hvad Google skal forvente, og routeren skal stadig matche den. Googles guide til modpartsgateway knytter den erklæring til det tunnel-, BGP-, firewall- og IKE-arbejde, du stadig skylder.
Hvis en række ikke har nogen ejer, bliver den udfyldt af den, der er på vagt under overgangen.
Hold de tre adresseroller adskilt
De offentlige modpartsadresser bærer den ydre IPsec-udveksling. Det indre BGP-par tilhører den beskyttede logiske forbindelse, der løber over den. De annoncerede LAN- og VPC-præfikser beskriver arbejdsbelastningerne bag den forbindelse. At kopiere en VMs interne adresse ind i det eksterne modpartsfelt blander de to første roller, og fejlen ligner et forhandlingsproblem snarere end en dataindtastningsfejl.
Planlæg to tilsvarende modpartstunneler, én til hver HA VPN-grænseflade. Brug af begge cloud-grænseflader fjerner ikke i sig selv det lokale fejlpunkt, fordi begge tunneler stadig kan lande på samme kabinet.
Skriv adresserollen ved siden af hver værdi i regnearket. Den ene vane forhindrer det meste af blandingen.
Oversæt regnearket til Cisco-udgivelsen
Start fra den understøttede modpartsdokumentation eller en passende Google-konfigurationsskabelon til din platform, og afstem derefter hver pladsholder med regnearket. Kontroller IKEv2-godkendelse, ESP-forslag, PFS og tunnel- og routingmodellen sammen, fordi en uoverensstemmelse i en af dem normalt viser sig som en uoverensstemmelse i en anden. Brug den faktiske platform og softwareudgivelse til at vælge, hvad der understøttes, da en Classic VPN-opskrift er et andet udgangspunkt.
Hold den delte hemmelighed ude af skærmbilleder, billetvedhæftninger og supportnotater. En foruddelt nøgle indsat i en sagskommentar er en afsløring af legitimationsoplysninger, ikke et fejlfindingsartefakt.
Hvis skabelonen og regnearket er uenige, så stop og løs det på papir. Enheden vil ikke mægle for dig.
Acceptér hver tunnel på sit eget bevis
HA VPN har brug for BGP-sessioner, og en vellykket IKE-forhandling etablerer kun den første fase. Den indre session skal komme op, de tilsigtede præfikser skal annonceres og accepteres, og brugbare ruter plus firewalltilladelser skal være på plads, før arbejdsbelastningstrafik flytter sig. At registrere det som ét grønt lys skjuler, hvilken fase der faktisk fejlede.
Registrér acceptbevis for hver tunnel: forhandlede sikkerhedsassociationer, BGP-nabotilstand, forventede lærte præfikser og den tilsigtede arbejdsbelastningsvej. Kør derefter et kontrolleret fejl- og genopretningstjek, fordi en tunnel, der aldrig har fejlet, er en tunnel, hvis genopretningsvej er utestet.
Den registrering kan genbruges næste gang, designet ændres, og det er forskellen mellem en interoperabilitet og et kommandofragment, hvis antagelser gik tabt.