Google HA VPN til ein Cisco-ruter: planlegg partressursen først

Den første avgjerda i ein HA VPN frå Cisco til Google er ikkje kva kryptoprofil som blir brukt, men om éi lokal eining eller to skal avslutte tunnelane. Googles HA VPN-gateway har to grensesnitt, og kvart av dei ventar ein tilsvarande partstunnel. Det gir deg to tunnelar uansett om du har to rutarar eller ikkje, og skilnaden er om éi enkel straumforsyning eller ei programvareoppdatering kan felle heile designet.

Avgjerda er éi parteining eller to

Vel oppsettet ut frå tre vilkår: om du kan godta eit lokalt feilpunkt, om begge skygrensesnitta må brukast, og kor mykje rekonvergens arbeidslastene dine toler. Viss noko av dei tre er eit hardt krav, er to parteiningar det ærlege svaret.

Bestem det før du opnar ein konsoll, fordi svaret endrar kor mange tunnelar og BGP-økter arbeidsarket må skildre.

Skriv arbeidsarket før nokon kommando

Arbeidsarket har fem rader, og kvar av dei treng ein eigar:

Den eksterne partressursen skildrar grensesnitta dine i Google Cloud, og å opprette han konfigurerer ikkje Cisco-ruteren. Den asymmetrien overraskar folk som ventar at skykonsollen er sanninga si kjelde for begge endar. Det er ei erklæring om kva Google skal vente, og ruteren må framleis samsvare med ho. Googles rettleiing for partgateway knyter den erklæringa til tunnel-, BGP-, brannmur- og IKE-arbeidet du framleis skuldar.

Viss ei rad ikkje har nokon eigar, blir ho fylt ut av den som er på vakt under overgangen.

Hald dei tre adresserollene frå kvarandre

Dei offentlege partadressene ber den ytre IPsec-utvekslinga. Det indre BGP-paret høyrer til den verna logiske sambindinga som går over han. Dei annonserte LAN- og VPC-prefiksa skildrar arbeidslastene bak den sambindinga. Å kopiere den interne adressa til ein VM inn i det eksterne partfeltet blandar dei to første rollene, og feilen ser ut som eit forhandlingsproblem snarare enn ein datainnskrivingsfeil.

Planlegg to tilsvarande partstunnelar, éin for kvart HA VPN-grensesnitt. Bruk av begge skygrensesnitta fjernar ikkje i seg sjølv det lokale feilpunktet, fordi begge tunnelane framleis kan lande på same kabinett.

Skriv adresserolla ved sida av kvar verdi i arbeidsarket. Den eine vanen hindrar det meste av blandinga.

Omset arbeidsarket til Cisco-utgåva

Start frå den støtta partdokumentasjonen eller ein passande Google-konfigurasjonsmal for plattformen din, og avstem deretter kvar plasshaldar mot arbeidsarket. Kontroller IKEv2-autentisering, ESP-forslag, PFS og tunnel- og rutingsmodellen saman, fordi ein mismatch i éin av dei vanlegvis viser seg som ein mismatch i ein annan. Bruk den faktiske plattformen og programvareutgåva til å velje kva som er støtta, sidan ei Classic VPN-oppskrift er eit anna utgangspunkt.

Hald den delte hemmelegheita unna skjermbilete, vedlegg til saker og støttenotat. Ein førehandsdelt nøkkel limt inn i ein sakskommentar er ei avsløring av påloggingsinformasjon, ikkje eit feilsøkingsartefakt.

Viss malen og arbeidsarket er usamde, stoppar du og løyser det på papir. Eininga vil ikkje megle for deg.

Godta kvar tunnel på sitt eige bevis

HA VPN treng BGP-økter, og ei vellukka IKE-forhandling etablerer berre den første fasen. Den indre økta må kome opp, dei tiltenkte prefiksa må annonserast og godtakast, og brukbare ruter samt brannmurrettar må finnast før arbeidslasttrafikk flyttar seg. Å registrere dette som eitt grønt lys skjuler kva fase som faktisk feila.

Registrer godkjenningsbevis per tunnel: forhandla tryggleiksassosiasjonar, BGP-nabostatus, venta lærte prefiks og den tiltenkte arbeidslastbana. Køyr deretter ein kontrollert feil- og gjenopprettingssjekk, fordi ein tunnel som aldri har feila, er ein tunnel der gjenopprettingsbana er utesta.

Den registreringa kan gjenbrukast neste gong designet blir endra, og det er skilnaden mellom ein interoperabilitet og eit kommandofragment der føresetnadene gjekk tapt.