Google HA VPN al Cisco-route: unue planu la kunulan rimedon
Nomu ambaŭ Google-interfacojn, la kunulan rimedon, la IKEv2-kontrakton kaj ĉiun BGP-sesion antaŭ ol agordi la Cisco-routon, poste elektu unu kunulon aŭ du.
La unua decido en HA VPN de Cisco al Google ne estas, kiun kriptan profilon uzi, sed ĉu unu loka aparato aŭ du finos la tunelojn. La HA VPN-pordego de Google havas du interfacojn, kaj ĉiu atendas respondan kunulan tunelon. Tio donas al vi du tunelojn sendepende de tio, ĉu vi havas du routojn aŭ ne, kaj la diferenco estas, ĉu ununura elektroprovizo aŭ programara ĝisdatigo povas faligi la tutan dezajnon.
La decido estas unu kunula aparato aŭ du
Elektu la aranĝon laŭ tri kondiĉoj: ĉu vi povas akcepti lokan fiaskopunkton, ĉu ambaŭ nubaj interfacoj devas esti uzataj, kaj kiom da rekunkonverĝo viaj laborŝarĝoj toleras. Se iu el la tri estas malmola postulo, du kunulaj aparatoj estas la honesta respondo.
Decidu tion antaŭ ol malfermi konzolon, ĉar la respondo ŝanĝas kiom da tuneloj kaj BGP-sesioj la laborfolio devas priskribi.
Skribu la laborfolion antaŭ iu ajn komando
La laborfolio havas kvin vicojn, kaj ĉiu bezonas posedanton:
| 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 |
La ekstera kunula rimedo priskribas viajn interfacojn ene de Google Cloud, kaj ĝia kreado ne agordas la Cisco-routon. Tiu asimetrio surprizas homojn, kiuj atendas, ke la nuba konzolo estu la fonto de vero por ambaŭ finoj. Ĝi estas deklaro pri tio, kion Google devus atendi, kaj la routo ankoraŭ devas kongrui kun ĝi. La gvidilo pri kunula pordego de Google mapas tiun deklaron al la tunela, BGP, fajroŝirma kaj IKE-laboro, kiun vi ankoraŭ ŝuldas.
Se vico ne havas posedanton, ĝin plenigos tiu, kiu estas deĵore dum la transiro.
Tenu la tri adresajn rolojn apartaj
La publikaj kunulaj adresoj portas la eksteran IPsec-interŝanĝon. La interna BGP-paro apartenas al la protektita logika konekto, kiu iras super ĝi. La anoncitaj LAN- kaj VPC-prefiksoj priskribas la laborŝarĝojn malantaŭ tiu konekto. Kopii la internan adreson de VM en la eksteran kunulan kampon miksas la unuajn du rolojn, kaj la fiasko aspektas kiel intertrakta problemo anstataŭ kiel datum-eniga eraro.
Planu du respondajn kunulajn tunelojn, unu por ĉiu HA VPN-interfaco. Uzi ambaŭ nubajn interfacojn per si mem ne forigas la lokan fiaskopunkton, ĉar ambaŭ tuneloj ankoraŭ povas alteriĝi sur la sama ĉasio.
Skribu la adresan rolon apud ĉiu valoro en la laborfolio. Tiu unu kutimo malhelpas la plejmulton de la miksado.
Traduku la laborfolion al la Cisco-eldono
Komencu de la subtenata kunula dokumentaro aŭ de taŭga Google-agorda ŝablono por via platformo, poste kongruigu ĉiun lokokupon kun la laborfolio. Kontrolu la IKEv2-aŭtentikigon, la ESP-proponojn, PFS kaj la tunelan kaj vojigan modelon kune, ĉar malkongruo en unu el ili kutime prezentiĝas kiel malkongruo en alia. Uzu la faktan platformon kaj programaran eldonon por elekti, kio estas subtenata, ĉar Classic VPN-recepto estas malsama komencpunkto.
Tenu la komunan sekreton ekster ekrankopioj, biletenaj aldonaĵoj kaj subtenaj notoj. Antaŭe dividita ŝlosilo algluita en kazokomenton estas malkaŝo de akreditaĵoj, ne artefakto por solvado de problemoj.
Se la ŝablono kaj la laborfolio malkongruas, haltu kaj solvu tion surpaperigante. La aparato ne arbitros por vi.
Akceptu ĉiun tunelon laŭ sia propra pruvo
HA VPN bezonas BGP-sesiojn, kaj sukcesa IKE-intertrakto establas nur la unuan etapon. La interna sesio devas ekfunkcii, la celitaj prefiksoj devas esti anoncitaj kaj akceptitaj, kaj utilaj vojoj kaj fajroŝirmaj permesoj devas ekzisti antaŭ ol laborŝarĝa trafiko moviĝas. Registri tion kiel unu verdan lumon kaŝas, kiu etapo efektive fiaskis.
Registru akceptpruvon por ĉiu tunelo: intertraktitaj sekurecaj asocioj, BGP-najbara stato, atenditaj lernitaj prefiksoj kaj la celita laborŝarĝa vojo. Poste faru kontrolitan fiaskan kaj reakiran teston, ĉar tunelo, kiu neniam fiaskis, estas tunelo, kies reakira vojo ne estas provita.
Tiu registro estas reuzebla la venontan fojon, kiam la dezajno ŝanĝiĝos, kaj ĝi estas la diferenco inter interagado kaj komanda fragmento, kies supozoj perdiĝis.