Google HA VPN k routeru Cisco: nejprve naplánujte prostředek protistrany
Pojmenujte obě rozhraní Google, prostředek protistrany, smlouvu IKEv2 a každou relaci BGP dříve, než nakonfigurujete router Cisco, a poté zvolte jednu protistranu nebo dvě.
První rozhodnutí u HA VPN z Cisco do Google není, který kryptografický profil použít, ale zda tunely ukončí jedno místní zařízení, nebo dvě. Brána HA VPN od Google má dvě rozhraní a každé očekává odpovídající tunel protistrany. To vám dá dva tunely bez ohledu na to, zda máte dva routery, a rozdíl je v tom, zda jeden napájecí zdroj nebo aktualizace softwaru mohou shodit celý návrh.
Rozhodnutí je jedno zařízení protistrany, nebo dvě
Vyberte uspořádání podle tří podmínek: zda můžete přijmout místní bod selhání, zda musí být použita obě cloudová rozhraní a jakou rekonvergenci vaše úlohy snesou. Pokud je některá ze tří tvrdým požadavkem, dvě zařízení protistrany jsou poctivá odpověď.
Rozhodněte o tom dříve, než otevřete konzoli, protože odpověď mění, kolik tunelů a relací BGP musí pracovní list popsat.
Napište pracovní list před jakýmkoli příkazem
Pracovní list má pět řádků a každý potřebuje 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í prostředek protistrany popisuje vaše rozhraní v Google Cloud a jeho vytvoření nenakonfiguruje router Cisco. Tato asymetrie překvapuje lidi, kteří očekávají, že cloudová konzole bude zdrojem pravdy pro oba konce. Je to prohlášení o tom, co má Google očekávat, a router se tomu stále musí přizpůsobit. Průvodce bránou protistrany od Google mapuje toto prohlášení na práci s tunelem, BGP, firewallem a IKE, kterou ještě dlužíte.
Pokud řádek nemá vlastníka, doplní ho ten, kdo bude během přechodu ve službě.
Držte tři role adres oddělené
Veřejné adresy protistrany nesou vnější výměnu IPsec. Vnitřní pár BGP patří chráněnému logickému spojení, které přes něj běží. Inzerované prefixy LAN a VPC popisují úlohy za tímto spojením. Kopírování interní adresy virtuálního počítače do pole externí protistrany míchá první dvě role a selhání vypadá jako problém vyjednávání, nikoli jako chyba zadání dat.
Naplánujte dva odpovídající tunely protistrany, jeden pro každé rozhraní HA VPN. Použití obou cloudových rozhraní samo o sobě neodstraňuje místní bod selhání, protože oba tunely mohou stále skončit na stejném šasi.
K každé hodnotě v pracovním listu napište roli adresy. Tento jediný zvyk zabrání většině míchání.
Převeďte pracovní list do vydání Cisco
Začněte podporovanou dokumentací protistrany nebo odpovídající šablonou konfigurace Google pro vaši platformu a poté každý zástupný údaj slaďte s pracovním listem. Zkontrolujte autentizaci IKEv2, návrhy ESP, PFS a model tunelu a směrování společně, protože neshoda v jednom z nich se obvykle projeví jako neshoda v jiném. K výběru toho, co je podporováno, použijte skutečnou platformu a verzi softwaru, protože recept Classic VPN je jiný výchozí bod.
Udržujte sdílené tajemství mimo snímky obrazovky, přílohy tiketů a poznámky podpory. Předsdílený klíč vložený do komentáře případu je únik přihlašovacích údajů, ne artefakt pro řešení problémů.
Pokud se šablona a pracovní list rozcházejí, zastavte se a vyřešte to na papíře. Zařízení za vás nerozhodne.
Přijměte každý tunel na základě jeho vlastních důkazů
HA VPN potřebuje relace BGP a úspěšné vyjednávání IKE naváže pouze první fázi. Vnitřní relace musí naskočit, zamýšlené prefixy musí být inzerovány a přijaty a před přesunem provozu úloh musí existovat užitečné trasy a oprávnění firewallu. Zaznamenat to jako jedno zelené světlo skrývá, která fáze skutečně selhala.
Zaznamenejte důkazy o přijetí pro každý tunel: vyjednaná bezpečnostní přidružení, stav souseda BGP, očekávané naučené prefixy a zamýšlenou cestu úlohy. Poté proveďte řízenou kontrolu selhání a obnovy, protože tunel, který nikdy neselhal, je tunel, jehož cesta obnovy nebyla otestována.
Tento záznam lze znovu použít při příští změně návrhu a je rozdílem mezi interoperabilitou a fragmentem příkazu, jehož předpoklady se ztratily.