Google HA VPN k smerovaču Cisco: najprv naplánujte partnerský zdroj
Pomenujte obe rozhrania Google, partnerský zdroj, zmluvu IKEv2 a každú reláciu BGP pred konfiguráciou smerovača Cisco, potom vyberte jedného partnera alebo dvoch.
Prvé rozhodnutie v HA VPN medzi Cisco a Google nie je, ktorý kryptoprofil použiť, ale či tunely ukončí jedno lokálne zariadenie alebo dve. Brána HA VPN od Google má dve rozhrania a každé očakáva zodpovedajúci partnerský tunel. To vám dáva dva tunely bez ohľadu na to, či máte dva smerovače, a rozdiel je v tom, či jeden napájací zdroj alebo softvérová aktualizácia môže zložiť celý návrh.
Rozhodnutie je jedno partnerské zariadenie alebo dve
Vyberte usporiadanie podľa troch podmienok: či môžete prijať lokálny bod zlyhania, či sa musia použiť obe cloudové rozhrania a akú rekonvergenciu vaše úlohy znesú. Ak je niektorá z troch tvrdou požiadavkou, dve partnerské zariadenia sú úprimná odpoveď.
Rozhodnite o tom predtým, než otvoríte konzolu, pretože odpoveď mení, koľko tunelov a relácií BGP musí pracovný list opísať.
Napíšte pracovný list pred akýmkoľvek príkazom
Pracovný list má päť riadkov a každý z nich potrebuje vlastníka:
| 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 |
Externý partnerský zdroj opisuje vaše rozhrania v Google Cloud a jeho vytvorenie nenakonfiguruje smerovač Cisco. Táto asymetria prekvapuje ľudí, ktorí očakávajú, že cloudová konzola bude zdrojom pravdy pre oba konce. Je to vyhlásenie o tom, čo má Google očakávať, a smerovač tomu stále musí zodpovedať. Sprievodca partnerskou bránou od Google mapuje toto vyhlásenie na prácu s tunelom, BGP, firewallom a IKE, ktorú vám ešte dlhuje.
Ak riadok nemá vlastníka, vyplní ho ten, kto bude počas prepnutia v službe.
Držte tri role adries oddelene
Verejné partnerské adresy nesú vonkajšiu výmenu IPsec. Vnútorný pár BGP patrí chránenému logickému spojeniu, ktoré cez neho beží. Inzerované prefixy LAN a VPC opisujú úlohy za týmto spojením. Kopírovanie internej adresy virtuálneho stroja do poľa externého partnera mieša prvé dve role a zlyhanie vyzerá ako problém vyjednávania, nie ako chyba zadania údajov.
Naplánujte dva zodpovedajúce partnerské tunely, jeden pre každé rozhranie HA VPN. Použitie oboch cloudových rozhraní samo o sebe neodstráni lokálny bod zlyhania, pretože oba tunely môžu stále pristáť na rovnakom šasi.
Napíšte rolu adresy vedľa každej hodnoty v pracovnom liste. Tento jediný zvyk zabráni väčšine miešania.
Preložte pracovný list do vydania Cisco
Začnite od podporovanej partnerskej dokumentácie alebo od zodpovedajúcej šablóny konfigurácie Google pre vašu platformu, potom zosúlaďte každý zástupný prvok s pracovným listom. Skontrolujte overovanie IKEv2, návrhy ESP, PFS a model tunela a smerovania spoločne, pretože nezhoda v jednom z nich sa zvyčajne prejaví ako nezhoda v inom. Použite skutočnú platformu a vydanie softvéru na výber toho, čo je podporované, keďže recept Classic VPN je iný východiskový bod.
Držte zdieľané tajomstvo mimo snímok obrazovky, príloh tiketov a poznámok podpory. Vopred zdieľaný kľúč vložený do komentára prípadu je prezradenie prihlasovacích údajov, nie artefakt na riešenie problémov.
Ak sa šablóna a pracovný list nezhodujú, zastavte sa a vyriešte to na papieri. Zariadenie nebude rozhodovať za vás.
Prijmite každý tunel na základe jeho vlastných dôkazov
HA VPN potrebuje relácie BGP a úspešné vyjednávanie IKE stanovuje iba prvú fázu. Vnútorná relácia musí nabehnúť, zamýšľané prefixy musia byť inzerované a prijaté a pred presunom prevádzky úloh musia existovať užitočné trasy a povolenia firewallu. Zaznamenanie toho všetkého ako jedného zeleného svetla skrýva, ktorá fáza skutočne zlyhala.
Zaznamenajte dôkazy o prijatí pre každý tunel: vyjednané bezpečnostné asociácie, stav suseda BGP, očakávané naučené prefixy a zamýšľanú cestu úlohy. Potom vykonajte kontrolovanú skúšku zlyhania a obnovy, pretože tunel, ktorý nikdy nezlyhal, je tunel s neotestovanou cestou obnovy.
Tento záznam sa dá znova použiť pri ďalšej zmene návrhu a to je rozdiel medzi interoperabilitou a fragmentom príkazu, ktorého predpoklady sa stratili.