AWS Site-to-Site VPN: direcciones externas, internas y el prefijo LAN

La mayoría de los errores de AWS Site-to-Site VPN son errores de direcciones, y se cometen antes de que se mueva ningún paquete. Las direcciones externas del túnel llegan a los pares IPsec, las internas forman el enlace de enrutamiento entre ellos, y los prefijos protegidos son para lo que sirve ese enlace. Copie un rol en otro y el túnel se levanta mientras no se enruta nada. Esta es la secuencia lee-comprueba-configura que uso en una puerta de enlace de cliente BGP, con los valores tomados de la configuración del dispositivo descargada, no de la memoria.

Tres roles de dirección, un túnel

Las direcciones externas son públicas y pertenecen a los pares IPsec: una por túnel en el lado de AWS, y la identidad alcanzable de la puerta de enlace de cliente en su lado, ajustada a la disposición de NAT que realmente tenga. Las direcciones internas son privadas y pertenecen al enlace lógico, que AWS documenta como un /30 extraído de 169.254.0.0/16. Los prefijos protegidos son las redes VPC, locales o de tránsito que enruta y anuncia por ese enlace.

Asignar un prefijo LAN como dirección de la interfaz del túnel es la versión clásica de este error. La interfaz parece configurada, la LAN no se anuncia y el lado opuesto no tiene ruta hacia ella. El túnel puede incluso pasar su propio ping interno mientras cada nombre de aplicación agota el tiempo. La referencia de opciones del túnel enumera las restricciones del CIDR interno, incluido el rango de direcciones del que debe provenir.

Lea los valores de la configuración descargada

Descargue la configuración de su modelo de dispositivo concreto desde la conexión y luego trate su tabla de direcciones como fuente de verdad. La consola muestra los mismos valores por túnel: IP externa, CIDR interno y la dirección del par BGP en el lado de AWS. Los dos túneles son objetos separados con extremos externos separados y /30 internos separados, aunque ambos transportan las mismas redes protegidas.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

Si el archivo descargado y la consola en vivo no coinciden, el archivo está desactualizado. Vuelva a descargarlo en lugar de editar direcciones a mano, porque una discrepancia entre el par interno y el vecino configurado del par es un fallo silencioso de BGP.

Construya el enlace con la dirección correcta

En una puerta de enlace Linux el túnel es una interfaz VTI o XFRM, y el /30 interno va en esa interfaz. Dos túneles significan dos interfaces y dos vecinos BGP, uno por punto de enlace de AWS. La convención que AWS imprime en la configuración del dispositivo descargada pone la puerta de enlace privada virtual en la primera dirección de cada /30 interno y su puerta de enlace de cliente en la segunda, así que toma la dirección más alta y hace peering con la más baja. Nada aquí necesita una dirección LAN.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

Si el archivo de su modelo de dispositivo imprime el emparejamiento opuesto, use sus números y mantenga la regla: la dirección de la interfaz es suya, la dirección del par pertenece a AWS. Hacerlo al revés produce un túnel que nunca alcanza Established, porque el vecino que configuró es la dirección que su propia interfaz ya tiene.

Mantenga la marca y la clave VTI alineadas con lo que usa el demonio IKE para vincular una SA hija a la interfaz, o el tráfico llega al túnel sin una interfaz donde aterrizar. Compruebe la MTU contra la ruta y contra los propios ajustes del demonio IKE en lugar de copiar un número de otro sitio.

Verifique BGP antes de verificar las rutas

Que IPsec se levante demuestra que los pares acuerdan una asociación de seguridad y nada más. La sesión BGP es una negociación aparte sobre el enlace interno, así que lea el estado del vecino y los contadores de prefijos, y luego compárelos con lo que pretendía anunciar.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

El estado Established con cero prefijos recibidos es un problema de política o de anuncio, no del túnel. Repita toda la comprobación en el segundo túnel; un primer túnel que funciona le dice que las direcciones son plausibles, no que el segundo túnel esté configurado.

Siga un paquete enrutado y luego deténgase

Una vez que la sesión transporta los prefijos, pruebe la ruta en ambos sentidos desde la puerta de enlace: dirección de origen, siguiente salto y la política de seguridad que permite el tráfico. Una sesión BGP puede estar activa mientras el prefijo concreto que necesita su aplicación está filtrado, resumido o apuntando a la interfaz equivocada.

Reachability Analyzer es la herramienta del lado de AWS que toma un origen, un destino y una ruta, e informa qué componente de una configuración compatible lo bloqueó. Úsela para probar la ruta de la VPC a la dirección de su puerta de enlace de cliente, no desde un host de aplicación. Analiza configuración y no envía un paquete por un cortafuegos local, así que mantenga su veredicto separado de sus propios contadores de interfaz y capturas de paquetes.

Registre el par externo, el /30 interno y los prefijos anunciados de cada túnel en una sola tabla. Esa tabla es lo que hace revisable el siguiente cambio.