Google HA VPN till en Cisco-router: planera peer-resursen först
Namnge båda Googles gränssnitt, peer-resursen, IKEv2-avtalet och varje BGP-session innan du konfigurerar Cisco-routern och välj sedan en peer eller två.
Det första beslutet i en HA VPN mellan Cisco och Google är inte vilken kryptoprofil som ska användas, utan om en lokal enhet eller två ska avsluta tunnlarna. Googles HA VPN-gateway har två gränssnitt och varje gränssnitt förväntar sig en motsvarande peer-tunnel. Det ger dig två tunnlar oavsett om du har två routrar eller inte, och skillnaden är om ett enda nätaggregat eller en mjukvaruuppgradering kan fälla hela designen.
Beslutet är en peer-enhet eller två
Välj upplägget utifrån tre villkor: om du kan acceptera en lokal felpunkt, om båda molngränssnitten måste användas och hur mycket återkonvergens dina arbetslaster tolererar. Om något av de tre är ett hårt krav är två peer-enheter det ärliga svaret.
Bestäm det innan du öppnar en konsol, eftersom svaret ändrar hur många tunnlar och BGP-sessioner arbetsbladet måste beskriva.
Skriv arbetsbladet före varje kommando
Arbetsbladet har fem rader och varje rad behöver en ägare:
| 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 externa peer-resursen beskriver dina gränssnitt inuti Google Cloud, och att skapa den konfigurerar inte Cisco-routern. Den asymmetrin förvånar människor som förväntar sig att molnkonsolen ska vara källan till sanning för båda ändarna. Det är en deklaration om vad Google bör förvänta sig, och routern måste fortfarande matcha den. Googles guide för peer-gatewayen mappar den deklarationen till arbetet med tunnel, BGP, brandvägg och IKE som du fortfarande är skyldig.
Om en rad saknar ägare fylls den i av den som är i tjänst under övergången.
Håll de tre adressrollerna åtskilda
De offentliga peer-adresserna bär det yttre IPsec-utbytet. Det inre BGP-paret tillhör den skyddade logiska förbindelsen som löper över det. De annonserade LAN- och VPC-prefixen beskriver arbetslasterna bakom den förbindelsen. Att kopiera en VM:s interna adress till fältet för extern peer blandar de två första rollerna, och felet ser ut som ett förhandlingsproblem i stället för ett inmatningsfel.
Planera två motsvarande peer-tunnlar, en för varje HA VPN-gränssnitt. Att använda båda molngränssnitten tar inte i sig bort den lokala felpunkten, eftersom båda tunnlarna fortfarande kan landa på samma chassi.
Skriv adressrollen bredvid varje värde i arbetsbladet. Den enda vanan förhindrar det mesta av blandningen.
Översätt arbetsbladet till Cisco-versionen
Börja med den peer-dokumentation som stöds eller en matchande Google-konfigurationsmall för din plattform och stäm sedan av varje platshållare mot arbetsbladet. Kontrollera IKEv2-autentisering, ESP-förslag, PFS och tunnel- och routningsmodellen tillsammans, eftersom en avvikelse i en av dem vanligtvis visar sig som en avvikelse i en annan. Använd den faktiska plattformen och mjukvaruversionen för att välja vad som stöds, eftersom ett Classic VPN-recept är en annan utgångspunkt.
Håll den delade hemligheten borta från skärmbilder, bilagor till ärenden och supportanteckningar. En fördelad nyckel som klistras in i en ärendekommentar är ett avslöjande av autentiseringsuppgifter, inte en felsökningsartefakt.
Om mallen och arbetsbladet inte stämmer överens, stanna och lös det på papper. Enheten avgör inte åt dig.
Acceptera varje tunnel på dess egna bevis
HA VPN behöver BGP-sessioner, och en lyckad IKE-förhandling etablerar bara det första steget. Den inre sessionen måste komma upp, de avsedda prefixen måste annonseras och accepteras, och användbara rutter plus brandväggsbehörigheter måste finnas innan arbetslasttrafiken flyttas. Att registrera allt detta som ett enda grönt ljus döljer vilket steg som faktiskt misslyckades.
Registrera acceptansbevis per tunnel: förhandlade säkerhetsassociationer, BGP-grannens tillstånd, förväntade inlärda prefix och den avsedda arbetslastvägen. Kör sedan ett kontrollerat fel- och återhämtningstest, eftersom en tunnel som aldrig har fallerat är en tunnel vars återhämtningsväg är otestad.
Den registreringen kan återanvändas nästa gång designen ändras, och det är skillnaden mellan ett samspel och ett kommandofragment vars antaganden gick förlorade.