Google HA VPN cara a un router Cisco: planifique primeiro o recurso de par
Nomee as dúas interfaces de Google, o recurso de par, o contrato IKEv2 e cada sesión BGP antes de configurar o router Cisco, e despois escolla un par ou dous.
A primeira decisión nunha HA VPN de Cisco a Google non é que perfil criptográfico usar, senón se un dispositivo local ou dous van terminar os túneles. A pasarela HA VPN de Google ten dúas interfaces, e cada unha espera un túnel de par correspondente. Iso dálle dous túneles tanto se ten dous routers como se non, e a diferenza é se unha soa fonte de alimentación ou unha actualización de software poden derrubar todo o deseño.
A decisión é un dispositivo de par ou dous
Escolla o deseño a partir de tres condicións: se pode aceptar un punto de fallo local, se deben usarse ambas as interfaces de nube e canta reconverxencia toleran as súas cargas de traballo. Se calquera das tres é un requisito estrito, dous dispositivos de par é a resposta honesta.
Decídao antes de abrir unha consola, porque a resposta cambia cantos túneles e sesións BGP debe describir a folla de traballo.
Escriba a folla de traballo antes de calquera orde
A folla de traballo ten cinco filas, e cada unha necesita 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 |
O recurso de par externo describe as súas interfaces dentro de Google Cloud, e crealo non configura o router Cisco. Esa asimetría sorprende a quen espera que a consola da nube sexa a fonte de verdade para ambos os extremos. É unha declaración do que Google debería esperar, e o router aínda ten que coincidir con ela. A guía de pasarela de par de Google asigna esa declaración ao traballo de túnel, BGP, cortafuegos e IKE que aínda debe.
Se unha fila non ten responsable, completaraa quen estea de quenda durante a migración.
Manteña separados os tres roles de enderezo
Os enderezos públicos de par transportan o intercambio IPsec exterior. O par BGP interno pertence á conexión lóxica protexida que corre por riba. Os prefixos LAN e VPC anunciados describen as cargas de traballo detrás desa conexión. Copiar o enderezo interno dunha VM no campo de par externo mestura os dous primeiros roles, e o fallo parece un problema de negociación en lugar dun erro de entrada de datos.
Planifique dous túneles de par correspondentes, un por cada interface HA VPN. Usar ambas as interfaces de nube non elimina por si só o punto de fallo local, porque ambos os túneles aínda poden aterrar no mesmo chasis.
Escriba o rol do enderezo xunto a cada valor da folla de traballo. Ese único hábito evita a maior parte da mestura.
Traduza a folla de traballo á versión de Cisco
Parta da documentación de par admitida ou dun modelo de configuración de Google axeitado para a súa plataforma, e despois reconcilie cada marcador coa folla de traballo. Comprobe a autenticación IKEv2, as propostas ESP, o PFS e o modelo de túnel e encamiñamento en conxunto, porque un desaxuste nun deles adoita presentarse como un desaxuste noutro. Use a plataforma e a versión de software reais para escoller o que se admite, xa que unha receita de Classic VPN é un punto de partida distinto.
Manteña o segredo compartido fóra de capturas de pantalla, anexos de tickets e notas de soporte. Unha clave precompartida pegada nun comentario de caso é unha revelación de credenciais, non un artefacto de resolución de problemas.
Se o modelo e a folla de traballo non coinciden, detéñase e resólvao sobre papel. O dispositivo non arbitrará por vostede.
Acepte cada túnel coas súas propias probas
A HA VPN necesita sesións BGP, e unha negociación IKE correcta só establece a primeira etapa. A sesión interna debe levantarse, os prefixos previstos deben anunciarse e aceptarse, e deben existir rutas útiles e permisos de cortafuegos antes de que se mova o tráfico das cargas de traballo. Rexistrar iso como unha soa luz verde oculta que etapa fallou realmente.
Rexiste probas de aceptación por túnel: asociacións de seguridade negociadas, estado do veciño BGP, prefixos aprendidos esperados e a ruta de carga de traballo prevista. Despois execute unha comprobación controlada de fallo e recuperación, porque un túnel que nunca fallou é un túnel cuxa ruta de recuperación non se probou.
Ese rexistro é reutilizable a próxima vez que cambie o deseño, e é a diferenza entre unha interoperación e un fragmento de orde cuxas suposicións se perderon.