VPN de sitio a sitio entre AWS y Azure: escriba primero la ruta de vuelta
Un túnel conectado entre nubes no demuestra nada hasta que cada subred de carga enruta hacia el prefijo remoto. Ejecute el plan en orden y luego pruebe el servicio.
El túnel subirá. Suele hacerlo, porque IKE solo necesita propuestas coincidentes y una dirección de par accesible. Lo que falla después es el camino de vuelta: la carga de AWS envía paquetes a un túnel, pero nada del lado de Azure sabe cómo responder a 10.10.0.0/16, o la ruta de Azure existe en una tabla que la subred de carga no usa. Escriba el plan de rutas antes de tocar cualquier consola y el túnel se convertirá en la parte menos interesante del trabajo.
Paso 1: congele el plan de direcciones
Trabaje con valores concretos. Una carga de AWS está en 10.10.1.20 dentro de 10.10.0.0/16 y necesita TCP 443 hacia un servicio de Azure en 10.20.1.30 dentro de 10.20.0.0/16. Los dos rangos no deben solaparse, y la prueba de aceptación es el par de servicios, no el túnel.
Anote esos cuatro hechos antes que cualquier otra cosa, porque cada paso posterior se comprueba contra ellos.
Paso 2: nombre la puerta de enlace que posee cada extremo
AWS Site-to-Site VPN puede terminar en una puerta de enlace privada virtual o en una puerta de enlace de tránsito, y son propietarios de enrutamiento distintos. Azure ofrece su VPN Gateway administrada y, por separado, dispositivos basados en VM que los clientes ejecutan ellos mismos. Registre qué par tiene, porque el siguiente salto difiere en cada combinación.
Para una puerta de enlace administrada, no copie una ruta que apunte a una dirección supuesta de dispositivo privado. Para un dispositivo, no suponga que la propagación de rutas en la nube configura el sistema operativo invitado, porque no lo hace.
Equivocarse aquí produce un plan que parece completo y envía paquetes a una dirección que nunca responde.
Paso 3: escriba la ruta que cada carga realmente usa
Cada límite de abajo es una consulta separada, y una ruta en uno de ellos no es una ruta para el paquete. Rellene la tabla con sus propios valores antes de que el túnel entre en servicio.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
En AWS, la tabla de rutas de la subred de carga es suya para actualizarla incluso después de que BGP o un túnel estén sanos; la descripción general del enrutamiento lo considera parte de la conexión. En Azure, una tabla de rutas definidas por el usuario se asocia a una subred en lugar de vincularse a la red virtual, así que compruebe la ruta efectiva en la NIC de la carga y no en la hoja de VNet.
Una puerta de enlace de Azure administrada puede aprender el prefijo remoto mediante la propagación de la puerta de enlace, y una UDR puede anular esa decisión. Añada la UDR cuando tenga un motivo, no por reflejo. Si la añade, apúntela al siguiente salto que la puerta de enlace publica para el camino VPN en lugar de inventar una dirección de dispositivo. Luego vuelva a leer las rutas efectivas en la NIC, porque la NIC es donde realmente se toma la decisión.
Paso 4: reconcilie el alcance
Para BGP, compare lo que anuncia cada lado con lo que el otro lado aprendió realmente, prefijo por prefijo. Para el enrutamiento estático, compare los rangos remotos configurados con las rutas de carga que escribió en el paso 3.
Una relación IKE que coincide en criptografía no es prueba de que algún lado haya aprendido 10.10.0.0/16 o 10.20.0.0/16. Dos túneles pueden estar activos mientras un lado anuncia un solo /24 en lugar del /16 que planeó. Compruebe el prefijo en la tabla de enrutamiento, no en el estado del túnel. La discrepancia aparece después como una subred que funciona y otra que nunca responde.
Paso 5: pruebe el servicio, desde la fuente real
Permita el flujo previsto en los grupos de seguridad y las ACL de red de AWS, en los NSG de Azure y en cualquier filtro de dispositivo del camino. Luego abra una conexión desde 10.10.1.20 a la dirección y el puerto aprobados del servicio y confirme que la respuesta vuelve a la misma fuente.
Tanto los grupos de seguridad de la nube como los NSG son stateful, así que un paquete de vuelta denegado es un síntoma de enrutamiento, no una regla que olvidó escribir al revés.
Un ping desde cualquier puerta de enlace no resuelve nada. ICMP a la dirección de una puerta de enlace ejercita el camino del plano de control, no el servicio TCP reenviado que la carga necesita.
Reversión y registros
Registre los propietarios de rutas junto a los identificadores del túnel y conserve las tablas de rutas anteriores al cambio. Si el cambio tiene que salir, elimine las rutas de carga antes de desmontar el túnel, para que ninguna subred quede apuntando a un siguiente salto que ya no existe.
Así, un traslado posterior de subred o una conexión spoke tiene un lugar definido donde actualizar, en lugar de un túnel que funciona y carga la culpa de una ruta que nunca poseyó.