Google HA VPN til en Cisco-ruter: planlegg partressursen først
Navngi begge Googles grensesnitt, partressursen, IKEv2-kontrakten og hver BGP-økt før du konfigurerer Cisco-ruteren, og velg deretter én part eller to.
Den første beslutningen i en HA VPN fra Cisco til Google er ikke hvilken kryptoprofil som brukes, men om én lokal enhet eller to skal avslutte tunnelene. Googles HA VPN-gateway har to grensesnitt, og hvert av dem forventer en tilsvarende partstunnel. Det gir deg to tunneler uansett om du har to rutere eller ikke, og forskjellen er om én enkelt strømforsyning eller en programvareoppdatering kan felle hele designet.
Beslutningen er én partenhet eller to
Velg oppsettet ut fra tre betingelser: om du kan akseptere et lokalt feilpunkt, om begge skygrensesnittene må brukes, og hvor mye rekonvergens arbeidsbelastningene dine tåler. Hvis noen av de tre er et hardt krav, er to partenheter det ærlige svaret.
Bestem det før du åpner en konsoll, fordi svaret endrer hvor mange tunneler og BGP-økter regnearket må beskrive.
Skriv regnearket før noen kommando
Regnearket har fem rader, og hver av dem trenger en eier:
| 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 partressursen beskriver grensesnittene dine i Google Cloud, og å opprette den konfigurerer ikke Cisco-ruteren. Den asymmetrien overrasker folk som forventer at skykonsollen er sannhetskilden for begge ender. Det er en erklæring om hva Google skal forvente, og ruteren må fortsatt samsvare med den. Googles veiledning for partgateway kobler den erklæringen til tunnel-, BGP-, brannmur- og IKE-arbeidet du fortsatt skylder.
Hvis en rad ikke har noen eier, blir den fylt ut av den som er på vakt under overgangen.
Hold de tre adresserollene fra hverandre
De offentlige partadressene bærer den ytre IPsec-utvekslingen. Det indre BGP-paret tilhører den beskyttede logiske forbindelsen som går over den. De annonserte LAN- og VPC-prefiksene beskriver arbeidsbelastningene bak den forbindelsen. Å kopiere en VMs interne adresse inn i det eksterne partfeltet blander de to første rollene, og feilen ser ut som et forhandlingsproblem snarere enn en datainntastingsfeil.
Planlegg to tilsvarende partstunneler, én for hvert HA VPN-grensesnitt. Bruk av begge skygrensesnittene fjerner ikke i seg selv det lokale feilpunktet, fordi begge tunnelene fortsatt kan lande på samme kabinett.
Skriv adresserollen ved siden av hver verdi i regnearket. Den ene vanen forhindrer det meste av blandingen.
Oversett regnearket til Cisco-utgivelsen
Start fra den støttede partdokumentasjonen eller en passende Google-konfigurasjonsmal for plattformen din, og avstem deretter hver plassholder mot regnearket. Kontroller IKEv2-autentisering, ESP-forslag, PFS og tunnel- og rutingsmodellen sammen, fordi en mismatch i én av dem vanligvis vises som en mismatch i en annen. Bruk den faktiske plattformen og programvareutgivelsen til å velge hva som støttes, siden en Classic VPN-oppskrift er et annet utgangspunkt.
Hold den delte hemmeligheten unna skjermbilder, vedlegg til saker og støttenotater. En forhåndsdelt nøkkel limt inn i en sakskommentar er en avsløring av påloggingsinformasjon, ikke et feilsøkingsartefakt.
Hvis malen og regnearket er uenige, stopper du og løser det på papir. Enheten vil ikke megle for deg.
Godta hver tunnel på sitt eget bevis
HA VPN trenger BGP-økter, og en vellykket IKE-forhandling etablerer bare den første fasen. Den indre økten må komme opp, de tiltenkte prefiksene må annonseres og godtas, og brukbare ruter samt brannmurrettigheter må finnes før arbeidsbelastningstrafikk beveger seg. Å registrere dette som ett grønt lys skjuler hvilken fase som faktisk feilet.
Registrer godkjenningsbevis per tunnel: forhandlede sikkerhetsassosiasjoner, BGP-nabotilstand, forventede lærte prefikser og den tiltenkte arbeidsbelastningsbanen. Kjør deretter en kontrollert feil- og gjenopprettingssjekk, fordi en tunnel som aldri har feilet, er en tunnel hvis gjenopprettingsbane er utestet.
Den registreringen kan gjenbrukes neste gang designet endres, og det er forskjellen mellom en interoperabilitet og et kommandofragment hvis antakelser gikk tapt.