Google HA VPN cap a un encaminador Cisco: planifiqueu primer el recurs de parell
Anomeneu les dues interfícies de Google, el recurs de parell, el contracte IKEv2 i cada sessió BGP abans de configurar l'encaminador Cisco, i després trieu un parell o dos.
La primera decisió en una HA VPN de Cisco a Google no és quin perfil criptogràfic fer servir, sinó si un dispositiu local o dos acabaran els túnels. La passarel·la HA VPN de Google té dues interfícies i cadascuna espera un túnel de parell corresponent. Això us dona dos túnels tant si teniu dos encaminadors com si no, i la diferència és si una sola font d'alimentació o una actualització de programari poden fer caure tot el disseny.
La decisió és un dispositiu de parell o dos
Trieu el disseny a partir de tres condicions: si podeu acceptar un punt de fallada local, si s'han d'utilitzar les dues interfícies de núvol i quanta reconvergència toleren les vostres càrregues de treball. Si qualsevol de les tres és un requisit dur, dos dispositius de parell és la resposta honesta.
Decidiu-ho abans d'obrir una consola, perquè la resposta canvia quants túnels i sessions BGP ha de descriure el full de treball.
Escriviu el full de treball abans de qualsevol ordre
El full de treball té cinc files i cadascuna necessita un responsable:
| 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 |
El recurs de parell extern descriu les vostres interfícies dins de Google Cloud, i crear-lo no configura l'encaminador Cisco. Aquesta asimetria sorprèn qui espera que la consola del núvol sigui la font de veritat per als dos extrems. És una declaració del que Google ha d'esperar, i l'encaminador encara s'hi ha d'ajustar. La guia de passarel·la de parell de Google assigna aquesta declaració a la feina de túnel, BGP, tallafoc i IKE que encara deveu.
Si una fila no té responsable, la completarà qui estigui de tornada durant la migració.
Manteniu separats els tres papers de les adreces
Les adreces públiques de parell porten l'intercanvi IPsec exterior. La parella BGP interna pertany a la connexió lògica protegida que hi passa per sobre. Els prefixos LAN i VPC anunciats descriuen les càrregues de treball darrere d'aquesta connexió. Copiar l'adreça interna d'una VM al camp de parell extern barreja els dos primers papers, i la fallada sembla un problema de negociació en lloc d'un error d'entrada de dades.
Planifiqueu dos túnels de parell corresponents, un per a cada interfície HA VPN. Utilitzar les dues interfícies de núvol no elimina per si sol el punt de fallada local, perquè tots dos túnels poden acabar al mateix xassís.
Escriviu el paper de l'adreça al costat de cada valor del full de treball. Aquest sol hàbit evita la major part de la barreja.
Traduïu el full de treball a la versió de Cisco
Partiu de la documentació de parell compatible o d'una plantilla de configuració de Google adequada per a la vostra plataforma, i després reconcileu cada marcador amb el full de treball. Comproveu l'autenticació IKEv2, les propostes ESP, el PFS i el model de túnel i encaminament alhora, perquè una discrepància en un d'ells normalment es presenta com una discrepància en un altre. Utilitzeu la plataforma i la versió de programari reals per triar què és compatible, ja que una recepta de Classic VPN és un punt de partida diferent.
Manteniu el secret compartit fora de captures de pantalla, adjunts de tiquets i notes de suport. Una clau prèviament compartida enganxada en un comentari de cas és una revelació de credencials, no un artefacte de resolució de problemes.
Si la plantilla i el full de treball no coincideixen, atureu-vos i resoleu-ho sobre paper. El dispositiu no arbitrarà per vosaltres.
Accepteu cada túnel amb les seves pròpies proves
La HA VPN necessita sessions BGP, i una negociació IKE correcta només estableix la primera etapa. La sessió interna ha d'aixecar-se, els prefixos previstos s'han d'anunciar i acceptar, i han d'existir rutes útils i permisos de tallafoc abans que es mogui el trànsit de les càrregues de treball. Enregistrar-ho com una sola llum verda amaga quina etapa ha fallat realment.
Enregistreu proves d'acceptació per túnel: associacions de seguretat negociades, estat del veí BGP, prefixos après esperats i el camí de càrrega de treball previst. Després feu una comprovació controlada de fallada i recuperació, perquè un túnel que mai no ha fallat és un túnel la ruta de recuperació del qual no s'ha provat.
Aquest registre és reutilitzable la propera vegada que canviï el disseny, i és la diferència entre una interoperació i un fragment d'ordre les suposicions del qual s'han perdut.