UDR de Azure a una puerta de enlace VPN: un destino, no toda la salida

Añade una ruta definida por el usuario para un prefijo externo, la apunta a la puerta de enlace VPN y el tráfico sigue saliendo por la ruta de internet de Azure. O sale correctamente y la respuesta nunca vuelve. Ambos resultados vienen del mismo error: tratar el siguiente salto de Azure como todo el diseño. La tabla de rutas solo decide qué salida toma un paquete dentro de Azure. Lo que ocurre después del túnel y cómo vuelve la respuesta es una segunda mitad que hay que construir.

El siguiente salto es una puerta de enlace, no la IP de un dispositivo

Una UDR envía un prefijo coincidente a un tipo de siguiente salto, y VirtualNetworkGateway es un tipo, no una dirección. La gente pega la IP privada de la puerta de enlace en una ruta VirtualAppliance y luego se pregunta por qué nada coincide, porque ese tipo espera una NIC o un balanceador de carga interno. La documentación de enrutamiento de Microsoft también limita el siguiente salto de puerta de enlace a una red virtual cuya puerta de enlace sea una puerta de enlace VPN. ExpressRoute, Route Server y un concentrador de Virtual WAN no se direccionan con esa opción.

Compruebe qué tiene realmente la red virtual antes de escribir la ruta. Si el diseño enruta a través de un concentrador, la ruta pertenece al propietario del enrutamiento del concentrador y no a la rama que está editando.

Lea la ruta efectiva antes de modificar nada

Azure combina rutas del sistema, prefijos aprendidos por BGP y UDR en una tabla de rutas efectiva por NIC, y gana el prefijo coincidente más largo venga de donde venga. Para el mismo prefijo, una UDR gana a una ruta BGP. Ese orden es la razón por la que una UDR antigua de un experimento anterior puede superar en silencio el prefijo que acaba de aprender por el túnel.

Mire primero la tabla efectiva y luego decida si añade una ruta o la sustituye:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Lea también la columna de origen, no solo el prefijo. Una ruta con el prefijo correcto y el origen equivocado le dice qué objeto editar y le evita añadir una segunda ruta que pierde contra la primera.

Escriba la ruta con el prefijo y la subred reales

Use el prefijo real del destino, tomado del servicio al que llega de verdad, en lugar de un rango público copiado de un mensaje de foro. Empiece con un servicio aprobado antes de plantear una ruta predeterminada que mueva toda la salida. Después asocie la tabla de rutas a la subred de la carga de trabajo. La subred de puerta de enlace tiene sus propios requisitos, y asociar su tabla allí rompe la puerta de enlace en lugar de dirigir la carga.

Cree la ruta y luego asocie la tabla a la subred que aloja la carga:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

La propagación también importa. Con la propagación BGP activada en esa tabla, los prefijos aprendidos aparecen junto a los que escribió, y un prefijo aprendido más específico puede ganar a una UDR más amplia. Desactive la propagación solo cuando quiera que el conjunto de UDR sea autoritativo para esa subred.

Complete la mitad local o el flujo muere allí

La puerta de enlace local debe aceptar el origen de Azure, reenviarlo al destino y permitir la aplicación. Su camino posterior puede ser una salida a internet u otro salto privado, pero esa decisión pertenece al plan y no a la tabla de rutas de Azure. El fallo habitual es la vuelta. Un destino de internet no enrutará un origen privado de Azure de vuelta hacia usted, así que la respuesta va a su propia puerta de enlace predeterminada y muere, o no sale nunca.

Dos diseños lo resuelven y no son intercambiables. Traduzca el origen en la salida, de modo que el destino responda a una dirección pública que posee la red local. O conserve el origen y construya una relación de retorno enrutada para que las respuestas vuelvan por el túnel. Elija uno y anote qué dirección verá la aplicación.

Los selectores y las listas de permitidos son algo aparte de todo esto. Elegir un siguiente salto de Azure no amplía los selectores de tráfico de la VPN ni cambia la lista de orígenes permitidos de un servicio externo.

Verifique con el origen que observa el destino

Envíe la petición desde la carga real en lugar de desde un host de salto en otra subred, y luego lea la dirección de origen que observó el destino. Ese único valor le dice cuál de los dos diseños de retorno está en marcha. Revise después la ruta de respuesta y confirme que el tráfico normal de administración hacia la máquina virtual sigue funcionando, porque una ruta predeterminada añadida por accidente se muestra como una sesión SSH rota mucho antes que como una aplicación rota.

Un tránsito por un prefijo seleccionado es un cambio mucho más estrecho que el túnel forzado. Manténgalo estrecho y la reversión es borrar una ruta.