Cómo hacer que AWS inicie un túnel Site-to-Site VPN
La acción de inicio y la acción de tiempo de espera DPD responden a preguntas distintas. Configure la que hace que AWS inicie y después compruebe la dirección del par y la ruta de la aplicación.
De forma predeterminada, una VPN Site-to-Site de AWS espera a que el customer gateway inicie la negociación. Ese valor predeterminado es un ajuste, no una ley, y el ajuste se llama Startup action. Antes de recurrir a él, separe dos preguntas que se mezclan constantemente: quién establece el túnel y si los paquetes que le importan tienen una ruta a través de él. Solo la primera vive en las opciones del túnel.
Separe la acción de inicio de la acción de tiempo de espera DPD
Dos opciones por túnel gobiernan dos eventos distintos, y configurar una no dice nada de la otra.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
Si AWS debe levantar un túnel nuevo o modificado, elija start. Si AWS además debe reiniciar la negociación tras un tiempo de espera DPD, configure restart para ese evento por separado. Ninguna de las dos es una política de reintentos de la aplicación, y ninguna es un intervalo de recambio de claves: DPD comprueba si el par está vivo, mientras que el recambio de claves sustituye las security associations de un túnel activo.
Una aplicación que agota el tiempo mientras el túnel sigue informando up tiene un problema de ruta de datos. Acortar el temporizador DPD no lo arreglará y puede añadir agitación que luego tendrá que explicar.
Compruebe que AWS tiene dónde enviar la negociación
La iniciación desde el lado de AWS solo funciona con IKEv2, y AWS necesita la dirección pública del customer gateway para saber dónde enviar la propuesta. El caso que duele es un recurso customer gateway autenticado con certificado creado sin dirección: la documentación de AWS describe crear un recurso customer gateway nuevo con la dirección y después modificar la conexión VPN para que apunte a él.
Un certificado demuestra quién es el par. No le dice a AWS dónde está el par, y son dos requisitos distintos. Por eso la solución es un recurso customer gateway nuevo y no un certificado nuevo. Cambiar el certificado deja a AWS con el mismo destino ausente.
Si el customer gateway está detrás de NAT, AWS también necesita un responder identity configurado, IDr, para que la identidad del par coincida con lo que espera el dispositivo. Confirme ese valor y la ruta de cortafuegos que admite tráfico IKE antes de culpar a la opción que acaba de cambiar. Elegir start no puede hacer que un par inalcanzable o mal identificado acepte una propuesta.
Aplique el cambio a un túnel y espere una interrupción
Una conexión VPN tiene dos túneles con opciones independientes, así que confirme cuál está editando por su dirección exterior. AWS permite modificar un túnel a la vez, y la conectividad por el túnel seleccionado puede interrumpirse durante varios minutos.
- Seleccione la conexión Site-to-Site VPN y abra Modify VPN tunnel options.
- Elija el túnel por la dirección IP exterior y confirme su versión de IKE y el recurso customer gateway.
- Establezca las acciones de inicio y DPD que realmente quiere y luego guarde en una ventana que controle.
- Confirme que el túnel modificado se establece y revise el otro túnel y el enrutamiento antes del siguiente cambio.
Un comportamiento merece atención antes del mantenimiento. Con la iniciación de AWS activada no hay tiempo de espera: AWS sigue intentándolo hasta que el túnel sube, y reinicia cuando el customer gateway envía un mensaje delete-SA. Si baja el par a propósito, AWS seguirá llamando y los registros del par lo mostrarán.
Verifique la ruta de la aplicación, no solo el estado del túnel
Un túnel que informa up no es lo mismo que una solicitud que funciona. Una función Lambda conectada a una VPC sigue necesitando una ruta de subnet hacia el prefijo del cliente, reglas de security group y network ACL que permitan el tráfico, resolución de nombres que devuelva la dirección correcta y una ruta de vuelta en el lado del cliente.
Pruebe una vez con una solicitud real desde el contexto de la aplicación y luego lea los flow logs si falla. El tráfico keepalive es una opción legítima cuando la iniciación de AWS está desactivada y un túnel inactivo necesita paquetes para mantenerse, pero debería ser una decisión de monitorización que pueda nombrar, no un bucle de ping sin explicación atornillado a una función.
Elija primero quién establece el túnel y luego diagnostique el fallo restante en su propia capa. La documentación de AWS sobre la iniciación cubre los requisitos de dirección, identidad y reintentos con más detalle que las pistas de la consola.