Google HA VPN hacia un router Cisco: planifique primero el recurso de par
Nombre las dos interfaces de Google, el recurso de par, el contrato IKEv2 y cada sesión BGP antes de configurar el router Cisco, y luego elija un par o dos.
La primera decisión en una HA VPN de Cisco a Google no es qué perfil criptográfico usar, sino si un dispositivo local o dos terminarán los túneles. La puerta de enlace HA VPN de Google tiene dos interfaces, y cada una espera un túnel de par correspondiente. Eso le da dos túneles tenga o no dos routers, y la diferencia es si una sola fuente de alimentación o una actualización de software pueden tumbar todo el diseño.
La decisión es un dispositivo de par o dos
Elija el diseño a partir de tres condiciones: si puede aceptar un punto de fallo local, si deben usarse ambas interfaces de nube y cuánta reconvergencia toleran sus cargas de trabajo. Si cualquiera de las tres es un requisito estricto, dos dispositivos de par es la respuesta honesta.
Decídalo antes de abrir una consola, porque la respuesta cambia cuántos túneles y sesiones BGP debe describir la hoja de trabajo.
Escriba la hoja de trabajo antes de cualquier comando
La hoja de trabajo tiene cinco filas, y cada una 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 |
El recurso de par externo describe sus interfaces dentro de Google Cloud, y crearlo no configura el router Cisco. Esa asimetría sorprende a quienes esperan que la consola de la nube sea la fuente de verdad para ambos extremos. Es una declaración de lo que Google debería esperar, y el router todavía tiene que coincidir con ella. La guía de puerta de enlace de par de Google asigna esa declaración al trabajo de túnel, BGP, cortafuegos e IKE que aún debe.
Si una fila no tiene responsable, la completará quien esté de turno durante la migración.
Mantenga separados los tres roles de dirección
Las direcciones públicas de par transportan el intercambio IPsec exterior. El par BGP interno pertenece a la conexión lógica protegida que corre por encima. Los prefijos LAN y VPC anunciados describen las cargas de trabajo detrás de esa conexión. Copiar la dirección interna de una VM en el campo de par externo mezcla los dos primeros roles, y el fallo parece un problema de negociación en lugar de un error de entrada de datos.
Planifique dos túneles de par correspondientes, uno por cada interfaz HA VPN. Usar ambas interfaces de nube no elimina por sí solo el punto de fallo local, porque ambos túneles aún pueden aterrizar en el mismo chasis.
Escriba el rol de la dirección junto a cada valor de la hoja de trabajo. Ese único hábito evita la mayor parte de la mezcla.
Traduzca la hoja de trabajo a la versión de Cisco
Parta de la documentación de par admitida o de una plantilla de configuración de Google adecuada para su plataforma, y luego concilie cada marcador con la hoja de trabajo. Compruebe la autenticación IKEv2, las propuestas ESP, el PFS y el modelo de túnel y enrutamiento en conjunto, porque un desajuste en uno de ellos suele presentarse como un desajuste en otro. Use la plataforma y la versión de software reales para elegir qué se admite, ya que una receta de Classic VPN es un punto de partida distinto.
Mantenga el secreto compartido fuera de capturas de pantalla, adjuntos de tickets y notas de soporte. Una clave precompartida pegada en un comentario de caso es una revelación de credenciales, no un artefacto de resolución de problemas.
Si la plantilla y la hoja de trabajo no coinciden, deténgase y resuélvalo sobre papel. El dispositivo no arbitrará por usted.
Acepte cada túnel con sus propias pruebas
La HA VPN necesita sesiones BGP, y una negociación IKE correcta solo establece la primera etapa. La sesión interna debe levantarse, los prefijos previstos deben anunciarse y aceptarse, y deben existir rutas útiles y permisos de cortafuegos antes de que se mueva el tráfico de las cargas de trabajo. Registrar eso como una sola luz verde oculta qué etapa falló realmente.
Registre pruebas de aceptación por túnel: asociaciones de seguridad negociadas, estado del vecino BGP, prefijos aprendidos esperados y la ruta de carga de trabajo prevista. Después ejecute una comprobación controlada de fallo y recuperación, porque un túnel que nunca ha fallado es un túnel cuya ruta de recuperación no se ha probado.
Ese registro es reutilizable la próxima vez que cambie el diseño, y es la diferencia entre una interoperación y un fragmento de comando cuyas suposiciones se perdieron.