El NAT de Azure VPN no corrige direcciones VNet superpuestas

Ambas VNet usan 10.40.1.0/24, los túneles se levantan y nada funciona. Añadir una segunda puerta de enlace VPN no lo cambia, ni una métrica de ruta más baja, porque el problema no es la selección de ruta. Dos cargas de trabajo que responden a la misma dirección privada dejan cada paquete con un destino ambiguo y una ruta de retorno no verificable. Antes de planificar cualquier traducción, averigüe qué tipo de conexión creó realmente, porque esa única elección decide si la función NAT de Azure está disponible o no.

Qué le está diciendo realmente el síntoma

Cuando un host de la VNet A envía a 10.40.1.10, la tabla de enrutamiento solo puede apuntarlo a algún sitio. Si la VNet B también contiene 10.40.1.10, esa dirección no es un destino que la ruta pueda distinguir; es una dirección con dos propietarios.

La segunda puerta de enlace que suele desplegarse no ayuda. Le da otro túnel, no otra dirección, y el rango duplicado viaja intacto dentro del túnel. Además duplica la configuración que debe mantener coherente. Lo que no puede hacer es que una dirección signifique dos hosts.

Cambiar las direcciones públicas de los pares VPN tampoco hace nada. Esas direcciones identifican los extremos del túnel, mientras que la colisión está en el rango privado que se transporta dentro.

El tipo de conexión decide si NAT está disponible

Azure VPN Gateway sí tiene una capacidad NAT, y está documentada para conexiones IPsec entre instalaciones basadas en rutas en SKU de puerta de enlace concretos. Esa misma documentación excluye las conexiones VNet-to-VNet y de punto a sitio, así que la función no es una casilla que aparezca en todas las relaciones de puerta de enlace.

La VNet-to-VNet nativa también exige que los rangos de VNet y de red local no se superpongan desde el principio, lo que concuerda con la exclusión. El emparejamiento de VNet no es una solución para la superposición por el mismo motivo.

Existe una alternativa admitida que la gente confunde con el tipo nativo: modelar la otra VNet como red local y conectarla como conexión de sitio a sitio. Es otro recurso y otro diseño, así que trate una conexión reetiquetada como un cambio que hay que validar, no como un simple cambio de nombre.

Renumere, o traduzca con algo que posea el alias

Si ambas VNet son suyas, compare una renumeración planificada con el costo continuo de la traducción. La renumeración toca la configuración de aplicaciones, los registros DNS, las reglas de seguridad y cada conexión existente, pero deja una red que después se lee con normalidad. Hágalo una subred a la vez, con el cambio de DNS al final. Un rango a medio renumerar es peor que cualquiera de las dos opciones, porque entonces ambos prefijos parecen autoritativos para quien lea la tabla después.

Donde la renumeración no sea práctica, use un diseño traducido con un propietario real del alias. Quienes llaman desde la VNet A pueden llegar a 10.40.1.10 de la VNet B como 10.140.1.10, pero ese alias necesita un dispositivo que traduzca, una ruta hacia él y un comportamiento equivalente para la respuesta. Una dirección añadida solo al DNS no es una traducción.

Registre ambos rangos en ambas direcciones: qué marca quien llama, qué ve el destino como origen y qué lado puede iniciar. Las propias reglas NAT de Azure incluyen la traducción inversa para sus asignaciones SNAT, así que no se escribe a mano una regla DNAT equivalente, pero esa comodidad termina en los tipos de conexión que admite la función.

Lo que no funcionará

Una ruta definida por el usuario o una métrica de ruta no pueden crear una distinción de direcciones que falta. Ambas operan sobre un destino que sigue siendo ambiguo, y el paquete llega al siguiente salto que la tabla prefiera.

Añadir el rango duplicado a una tabla de rutas como prefijo más específico solo mueve la ambigüedad un paso. También suele romper la otra dirección, donde la respuesta ahora tiene dos orígenes plausibles.

Acepte el diseño con tráfico en ambas direcciones

Demuestre el diseño con una operación permitida nueva desde cada lado, no con el estado del túnel. Un túnel IPsec conectado dice que los pares coinciden en criptografía; no dice nada sobre si los destinos se volvieron distinguibles.

Después ejecute las rutas denegadas: una dirección que debe seguir inalcanzable y un servicio que la política debe bloquear. Si ambas siguen teniendo éxito, la traducción es más amplia de lo que pretendía el diseño.

Cierre con los hechos que explican la configuración más adelante: el rango original, el rango presentado, el dispositivo que traduce y la dirección en la que cada lado puede iniciar. Si falta alguno de ellos, el siguiente ingeniero hereda una red donde dos hosts comparten nombre y nadie recuerda por qué uno de ellos responde.