Google HA VPN către un router Cisco: planificați mai întâi resursa de peer
Numiți ambele interfețe Google, resursa de peer, contractul IKEv2 și fiecare sesiune BGP înainte de a configura routerul Cisco, apoi alegeți un peer sau doi.
Prima decizie într-un HA VPN de la Cisco la Google nu este ce profil criptografic să folosiți, ci dacă un singur echipament local sau două vor termina tunelurile. Gateway-ul HA VPN al Google are două interfețe, iar fiecare așteaptă un tunel de peer corespunzător. Asta vă oferă două tuneluri indiferent dacă aveți două routere sau nu, iar diferența este dacă o singură sursă de alimentare sau un upgrade de software poate dărâma întregul design.
Decizia este un echipament de peer sau două
Alegeți configurația pe baza a trei condiții: dacă puteți accepta un punct local de eșec, dacă ambele interfețe cloud trebuie folosite și câtă reconvergență tolerează sarcinile dvs. de lucru. Dacă oricare dintre cele trei este o cerință strictă, două echipamente de peer este răspunsul onest.
Decideți asta înainte de a deschide o consolă, pentru că răspunsul schimbă câte tuneluri și sesiuni BGP trebuie să descrie foaia de lucru.
Scrieți foaia de lucru înainte de orice comandă
Foaia de lucru are cinci rânduri, iar fiecare are nevoie de un responsabil:
| 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 |
Resursa externă de peer descrie interfețele dvs. din interiorul Google Cloud, iar crearea ei nu configurează routerul Cisco. Această asimetrie surprinde oamenii care se așteaptă ca consola cloud să fie sursa de adevăr pentru ambele capete. Este o declarație despre ce ar trebui să aștepte Google, iar routerul tot trebuie să corespundă. ghidul gateway-ului de peer Google mapează această declarație pe munca de tunel, BGP, firewall și IKE pe care încă o datorați.
Dacă un rând nu are responsabil, îl va completa cine este de serviciu în timpul tranziției.
Țineți separate cele trei roluri de adresă
Adresele publice de peer transportă schimbul IPsec extern. Perechea BGP internă aparține conexiunii logice protejate care rulează peste ea. Prefixele LAN și VPC anunțate descriu sarcinile de lucru din spatele acelei conexiuni. Copierea adresei interne a unui VM în câmpul de peer extern amestecă primele două roluri, iar defecțiunea arată ca o problemă de negociere, nu ca o eroare de introducere a datelor.
Planificați două tuneluri de peer corespunzătoare, unul pentru fiecare interfață HA VPN. Folosirea ambelor interfețe cloud nu elimină de la sine punctul local de eșec, deoarece ambele tuneluri pot ateriza în continuare pe același șasiu.
Scrieți rolul adresei lângă fiecare valoare din foaia de lucru. Acel singur obicei previne cea mai mare parte a amestecului.
Traduceți foaia de lucru în versiunea Cisco
Porniți de la documentația de peer acceptată sau de la un șablon de configurare Google potrivit pentru platforma dvs., apoi reconciliați fiecare substituent cu foaia de lucru. Verificați împreună autentificarea IKEv2, propunerile ESP, PFS și modelul de tunel și rutare, pentru că o nepotrivire într-unul dintre ele apare de obicei ca o nepotrivire în altul. Folosiți platforma și versiunea reală de software pentru a alege ce este acceptat, deoarece o rețetă Classic VPN este un punct de plecare diferit.
Țineți secretul partajat departe de capturi de ecran, atașamente ale tichetelor și note de asistență. O cheie prepartajată lipită într-un comentariu de caz este o divulgare de credențiale, nu un artefact de depanare.
Dacă șablonul și foaia de lucru nu sunt de acord, opriți-vă și rezolvați pe hârtie. Echipamentul nu va arbitra pentru dumneavoastră.
Acceptați fiecare tunel pe baza propriilor dovezi
HA VPN are nevoie de sesiuni BGP, iar o negociere IKE reușită stabilește doar prima etapă. Sesiunea internă trebuie să urce, prefixele dorite trebuie anunțate și acceptate, iar rutele utile plus permisiunile de firewall trebuie să existe înainte ca traficul sarcinilor de lucru să se miște. Înregistrarea acestora ca o singură lumină verde ascunde care etapă a eșuat de fapt.
Înregistrați dovezi de acceptare pentru fiecare tunel: asocieri de securitate negociate, starea vecinului BGP, prefixele învățate așteptate și calea dorită a sarcinii de lucru. Apoi rulați o verificare controlată de eșec și recuperare, pentru că un tunel care nu a eșuat niciodată este un tunel a cărui cale de recuperare nu a fost testată.
Această înregistrare poate fi refolosită la următoarea schimbare de design, și este diferența dintre o interoperabilitate și un fragment de comandă ale cărui ipoteze s-au pierdut.