VPN de IP privada de Azure sobre ExpressRoute sin una NVA

El mito dice que cifrar el tráfico sobre el emparejamiento privado de ExpressRoute requiere un dispositivo virtual de red. No es así. Azure admite una Site-to-Site VPN Gateway cuyo extremo del túnel es una dirección RFC1918 privada transportada por el circuito, y el dispositivo es opcional, no estructural. Lo que el mito del dispositivo oculta es la parte que realmente duele: habilitar el extremo privado en un objeto en lugar de dos, y dejar que una ruta de emparejamiento directo gane en silencio sobre la ruta cifrada.

De dónde vino el mito

La afirmación tiene un origen respetable. Durante años, la receta práctica para IPsec sobre emparejamiento privado era una NVA, porque la puerta de enlace administrada solo exponía extremos públicos. Eso cambió, y las respuestas escritas antes del cambio todavía se citan en hilos donde nadie comprueba la fecha. La corrección es estrecha: existe una puerta de enlace VPN con dirección privada, y cambia el extremo, no la lógica de enrutamiento a su alrededor.

Nada de esto jubila la NVA. Jubila la suposición de que un dispositivo es el único camino hacia el requisito.

Habilite el extremo privado en ambos niveles

Empiece por una conexión de emparejamiento privado de ExpressRoute que funcione y esté vinculada a la VNet que contiene la puerta de enlace VPN. El lado local ya debe alcanzar las direcciones privadas pertinentes a través de ese circuito, porque el túnel usará esas direcciones como transporte. Luego el requisito previo de la puerta de enlace: el procedimiento de Microsoft para VPN de IP privada exige una puerta de enlace construida sobre un recurso de IP pública Standard. El direccionamiento privado del túnel no elimina ese requisito, lo que sorprende a quienes suponen que «privado» significa «ninguna IP pública en ningún sitio».

Ahora habilite el indicador en ambos lugares. La configuración de la puerta de enlace tiene su propio conmutador para IP privadas, y la conexión Site-to-Site individual tiene un segundo que hace que esa conexión use la dirección privada. Poner uno y no el otro es la configuración incompleta más común; el túnel o no se establece o se establece contra el extremo equivocado.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Confirme los nombres de las propiedades con la versión de CLI que tenga instalada, porque las etiquetas del portal y las propiedades de la CLI no siempre comparten redacción. Una puerta de enlace activa-activa expone dos direcciones privadas de túnel, y el dispositivo local necesita ambos pares configurados si quiere que esa redundancia signifique algo. BGP no es necesario solo para levantar este túnel de dirección privada, aunque suele formar parte de cómo distribuye los prefijos.

El segundo mito: un túnel establecido cifra su tráfico

Dos caminos llegan ahora a la red de aplicaciones: el camino directo de emparejamiento privado y el camino a través de la VPN. Ambos funcionan. Solo uno aplica esta capa IPsec. Microsoft documenta que, cuando se anuncian prefijos idénticos por ExpressRoute y por la VPN, Azure prefiere el camino directo de ExpressRoute, así que un túnel sano con contadores sanos no demuestra nada sobre adónde fueron los paquetes de la aplicación.

Los métodos de direccionamiento documentados son un rango que cubre ExpressRoute con un rango protegido más específico en la VPN, o prefijos disjuntos en los dos caminos. Como ilustración, el emparejamiento privado podría llevar 10.40.0.0/16 mientras la VPN anuncia 10.40.12.0/24. El prefijo más específico gana y el resto del rango permanece directo.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Haga la misma comprobación en la dirección local, ya que la preferencia de su enrutador decide por dónde sale el tráfico saliente. Y mantenga el transporte propio del túnel en el camino de ExpressRoute; una ruta que arrastre el extremo privado de la puerta de enlace dentro del túnel hace que el túnel dependa de sí mismo.

Decida qué ocurre cuando el túnel cae

Una ruta VPN más específica desaparece cuando el túnel cae, mientras que la ruta directa más amplia permanece. El tráfico fluye entonces sin cifrar y todo parece sano, que es el peor modo de fallo para un requisito que existe para garantizar el cifrado. Si el requisito prohíbe esa caída, el enrutamiento y la política de acceso deben decirlo explícitamente en lugar de confiar en la disponibilidad del túnel.

Anote qué prefijos pueden seguir siendo accesibles directamente y cuáles deben detenerse cuando falta el camino cifrado. Luego pruebe el caso permitido con tráfico real y compare los contadores de conexión, porque la tabla de rutas por sí sola no le dirá si el requisito de cifrado sigue cumpliéndose.

Ese planteamiento también le permite evaluar una NVA por sus funciones reales, como varios túneles, rendimiento o inspección del proveedor, en lugar de comprar una porque el extremo sea privado.