Google HA VPN verso un router Cisco: pianificate prima la risorsa peer
Nominate entrambe le interfacce Google, la risorsa peer, il contratto IKEv2 e ogni sessione BGP prima di configurare il router Cisco, poi scegliete un peer o due.
La prima decisione in una HA VPN da Cisco a Google non è quale profilo crittografico usare, ma se a terminare i tunnel sarà un dispositivo locale o due. Il gateway HA VPN di Google ha due interfacce, e ciascuna si aspetta un tunnel peer corrispondente. Questo vi dà due tunnel indipendentemente dal fatto che abbiate due router, e la differenza è se un singolo alimentatore o un aggiornamento software possa far cadere l’intera progettazione.
La decisione è un dispositivo peer o due
Scegliete la disposizione in base a tre condizioni: se potete accettare un punto di guasto locale, se entrambe le interfacce cloud devono essere usate e quanta riconvergenza tollerano i vostri carichi di lavoro. Se una delle tre è un requisito rigido, due dispositivi peer è la risposta onesta.
Decidetelo prima di aprire una console, perché la risposta cambia quanti tunnel e sessioni BGP deve descrivere il foglio di lavoro.
Scrivete il foglio di lavoro prima di qualsiasi comando
Il foglio di lavoro ha cinque righe, e ciascuna richiede un responsabile:
| 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 risorsa peer esterna descrive le vostre interfacce dentro Google Cloud, e crearla non configura il router Cisco. Questa asimmetria sorprende chi si aspetta che la console cloud sia la fonte di verità per entrambe le estremità. È una dichiarazione di ciò che Google dovrebbe aspettarsi, e il router deve ancora corrispondervi. La guida al gateway peer di Google mappa quella dichiarazione sul lavoro di tunnel, BGP, firewall e IKE che dovete ancora fare.
Se una riga non ha un responsabile, la compilerà chi è di turno durante il passaggio.
Tenete separati i tre ruoli dell’indirizzo
Gli indirizzi peer pubblici trasportano lo scambio IPsec esterno. La coppia BGP interna appartiene alla connessione logica protetta che vi scorre sopra. I prefissi LAN e VPC annunciati descrivono i carichi di lavoro dietro quella connessione. Copiare l’indirizzo interno di una VM nel campo peer esterno mescola i primi due ruoli, e il guasto sembra un problema di negoziazione anziché un errore di inserimento dati.
Pianificate due tunnel peer corrispondenti, uno per ogni interfaccia HA VPN. Usare entrambe le interfacce cloud non elimina da solo il punto di guasto locale, perché entrambi i tunnel possono ancora finire sullo stesso chassis.
Scrivete il ruolo dell’indirizzo accanto a ogni valore del foglio di lavoro. Questa sola abitudine evita la maggior parte della mescolanza.
Traducete il foglio di lavoro nella release Cisco
Partite dalla documentazione peer supportata o da un modello di configurazione Google adatto alla vostra piattaforma, poi riconciliate ogni segnaposto con il foglio di lavoro. Controllate insieme l’autenticazione IKEv2, le proposte ESP, il PFS e il modello di tunnel e routing, perché una discrepanza in uno di essi di solito si presenta come una discrepanza in un altro. Usate la piattaforma e la release software reali per scegliere ciò che è supportato, poiché una ricetta Classic VPN è un punto di partenza diverso.
Tenete il segreto condiviso fuori da schermate, allegati dei ticket e note di supporto. Una chiave precondivisa incollata in un commento di un caso è una divulgazione di credenziali, non un artefatto di risoluzione dei problemi.
Se il modello e il foglio di lavoro non concordano, fermatevi e risolvetelo sulla carta. Il dispositivo non farà da arbitro per voi.
Accettate ogni tunnel sulle sue prove
La HA VPN richiede sessioni BGP, e una negoziazione IKE riuscita stabilisce solo la prima fase. La sessione interna deve salire, i prefissi previsti devono essere annunciati e accettati, e devono esistere route utili e autorizzazioni del firewall prima che il traffico dei carichi di lavoro si muova. Registrare ciò come un’unica luce verde nasconde quale fase ha effettivamente fallito.
Registrate le prove di accettazione per tunnel: associazioni di sicurezza negoziate, stato del vicino BGP, prefissi appresi attesi e percorso del carico di lavoro previsto. Poi eseguite una verifica controllata di guasto e ripristino, perché un tunnel che non ha mai fallito è un tunnel il cui percorso di ripristino non è stato testato.
Quel registro è riutilizzabile la prossima volta che la progettazione cambia, ed è la differenza tra un’interoperabilità e un frammento di comando le cui ipotesi sono andate perse.