Rotar una PSK de AWS VPN: qué túnel cae y cuándo

El túnel cae en el momento en que los dos extremos no coinciden sobre la clave precompartida, y sigue caído hasta que ambos lados lleven el valor nuevo. Esa parte es esperable: AWS trata el cambio como una interrupción del túnel seleccionado, y el par no terminará IKE mientras las claves difieran. Lo que sorprende a la gente es la segunda mitad. El otro túnel no absorbe el tráfico por sí solo a menos que haya comprobado que puede llevarlo. Rote en este orden y la interrupción se queda dentro de un túnel.

Qué ocurre realmente cuando cambia la clave

ModifyVpnTunnelOptions reescribe las opciones de un túnel, identificado por su dirección IP exterior. El túnel se derriba y se reconstruye, así que IKE e IPsec negocian desde cero con la clave nueva. AWS indica que la interrupción puede durar varios minutos, lo bastante como para que un protocolo de enrutamiento lo note. El otro túnel de la misma conexión no se ve afectado por la llamada.

Hay un segundo efecto que conviene conocer antes de enviar nada. La operación de modificación toma el conjunto completo de opciones del túnel, así que un campo que omita se reescribe con su valor predeterminado. Si había ajustado las vidas útiles de la fase 1 o la fase 2, o los ajustes de detección de par muerto, pase los valores actuales en la misma solicitud o planifique restaurarlos después.

Lea primero los valores actuales y luego cambie un solo campo. Esa secuencia es toda la disciplina de esta tarea.

Empareje primero el túnel de AWS con el par correcto

La consola etiqueta los túneles por orden, y su dispositivo no usa esa etiqueta. Identifique el túnel por su dirección IP exterior y haga que coincida con la sección de par en la puerta de enlace del cliente. El túnel 1 en una configuración local no es prueba de que esté editando el túnel que AWS llama túnel 1.

Empiece por la propia conexión, que enumera ambos túneles y la clave que cada uno tiene ahora:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

La clave que devuelve es la que se usa ahora mismo. Compárela con la configuración del par antes de cambiar nada, porque una discrepancia que ya existe explica un túnel que nunca fue estable.

Haga primero que el otro túnel lleve el tráfico

Dos túneles en una conexión no demuestran que su dispositivo tenga ambos configurados, que ambos anuncien los prefijos que necesita o que el tráfico se mueva entre ellos. Compruebe la negociación del túnel alternativo, sus rutas y un flujo de aplicación real en ambos sentidos. Con BGP, una adyacencia activa es una prueba útil, pero no es lo mismo que confirmar los prefijos. Con enrutamiento estático, confirme cómo elige la ruta la puerta de enlace y qué hace cuando desaparece la preferida.

Si el alternativo no puede llevar la carga de trabajo, programe la interrupción o repare el túnel alternativo antes de tocar la clave. Una luz de estado en una página de la consola no es una promesa de servicio ininterrumpido.

Rote un túnel y luego verifique con tráfico real

Con la ruta alternativa demostrada, la secuencia es corta. Anote la dirección del túnel, su par y los ajustes no secretos, y mantenga una ruta de gestión hacia la puerta de enlace que no dependa del túnel que está a punto de romper.

1. Actualice el par de la puerta de enlace del cliente para la dirección exterior seleccionada, o prepare el cambio para que llegue segundos después de la llamada a la API.
2. Envíe la llamada de modificación con la clave nueva más las vidas útiles y los valores DPD actuales.
3. Espere a que vuelvan IKE e IPsec y luego confirme las rutas y los prefijos necesarios.
4. Pase un flujo de aplicación representativo por ese túnel y observe ambos sentidos.

El túnel no es utilizable mientras los extremos no coinciden y mientras AWS aplica la modificación, así que la actualización del par debe seguir de inmediato y no después de comer. Solo cuando el túnel cambiado lleve tráfico real debería repetir el procedimiento en el otro.

Deténgase si la recuperación o el enrutamiento siguen siendo inciertos tras el primer túnel. Dos túneles a medio funcionar son peores que uno que sabe que funciona.

Cuando la recuperación se atasca, lea el lado IKE

Un túnel que sigue caído después de que ambos extremos tengan la clave nueva suele ser una discrepancia de política que la rotación expuso, no creó. Las propuestas, la identidad que envía el par y los selectores de tráfico deben coincidir con el lado de AWS, y un valor que sobrevivió a un túnel establecido aún puede rechazarse durante una negociación nueva. Lea el estado de la negociación y el mensaje adjunto antes de cambiar la clave por segunda vez.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Si hay que deshacer el cambio, no restaure la clave antigua solo porque antes funcionaba. Trate una clave comprometida como comprometida y arregle la negociación en su lugar. Termine con ambos túneles verificados y el inventario de secretos actualizado para que cada par registre qué valor tiene, y mantenga la documentación de opciones de túnel de AWS junto al runbook.