Por qué Azure VPN de punto a sitio no cambia tu IP pública
Un túnel de punto a sitio solo transporta rutas de la red virtual, así que tu IP pública sigue siendo local hasta que el túnel forzado y el SNAT del cortafuegos muevan la salida a Azure.
Conecto el cliente de Azure VPN en un portátil Windows, abro una página de eco de dirección y veo la misma dirección pública que me dio mi router doméstico. Mientras tanto, el jump box en 10.20.0.4 responde y un nombre de punto de conexión privado se resuelve, así que el túnel no está roto. Una puerta de enlace de punto a sitio hace exactamente lo que dice su configuración predeterminada: transporta los prefijos privados y deja todo lo demás en el enlace local. Conseguir una dirección de salida propiedad de Azure es un cambio de diseño de enrutamiento, no una reparación.
Qué anuncia la puerta de enlace por defecto
La puerta de enlace inserta rutas para el espacio de direcciones de la red virtual, además de las redes emparejadas donde se permite el tránsito de puerta de enlace y los prefijos locales aprendidos por una conexión de sitio a sitio o BGP. No hay 0.0.0.0/0 en ese conjunto. Tu sistema operativo mantiene su ruta predeterminada en Wi-Fi o Ethernet, así que un paquete hacia una API pública nunca entra en el túnel.
La dirección que recibe un cliente dentro del túnel es un arrendamiento privado del grupo de punto a sitio. Identifica al cliente ante los recursos de la VNet; no es una dirección que internet pueda ver y nunca aparecerá como origen de una solicitud saliente hacia una API de SaaS. Una entrada de lista de permitidos construida alrededor de ese arrendamiento no puede funcionar, por mucho que esperes a que aparezca en los registros del proveedor.
Túnel dividido y túnel forzado, uno junto al otro
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Solo la segunda fila cambia la dirección que ve un servicio remoto. Todo lo demás en esa tabla es coste y superficie operativa que aceptas cuando la salida debe inspeccionarse o traducirse dentro de Azure. Si alguien te pide que cambie la IP pública, está pidiendo toda la columna derecha, no un retoque en el cliente.
Hay una opción intermedia que merece nombrarse antes de reconstruir nada. Una VM de proxy o puerta de enlace dentro de la VNet te da una dirección de origen controlada para las aplicaciones que puedan apuntar a ella, sin mover la ruta predeterminada del cliente. Eso mantiene la navegación normal en local y sigue satisfaciendo a un socio que solo necesita una llamada de API desde Azure. Falla cuando el requisito es realmente sobre todo el tráfico, porque cualquier cosa que ignore la configuración de proxy sigue saliendo localmente.
Haz que el túnel transporte la ruta predeterminada
En una puerta de enlace de red virtual, la forma compatible de dirigir todo el tráfico de internet del cliente al túnel es añadir rutas personalizadas a la configuración de punto a sitio. Dos mitades cubren todo el espacio IPv4, y cada una es más específica que la ruta predeterminada local, así que el cliente las prefiere sin borrar nada:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Esa línea es ilustrativa y no está completa para copiar y pegar: primero obtén el objeto de la puerta de enlace con Get-AzVirtualNetworkGateway y sustitúyelo por GWOBJ, y confirma que la SKU y el modelo de implementación aceptan rutas personalizadas antes de ejecutarlo. Los mismos prefijos aparecen en el portal en la página de configuración de punto a sitio, que es el lugar más seguro para fijarlos si aún no automatizas la puerta de enlace.
Cambiar esos prefijos invalida el paquete del cliente. Descarga de nuevo el paquete del cliente VPN y reinstálalo, porque las rutas viajan dentro del perfil. Un cliente que se reconecta con su perfil antiguo conserva el conjunto de rutas antiguo, y puedes perder una hora depurando un cambio que nunca le llegó.
En un centro de WAN virtual protegido, el equivalente es una ruta predeterminada en la tabla de rutas del centro asociada a la puerta de enlace de punto a sitio, con Azure Firewall en el centro tomando el tráfico. El cortafuegos traduce las conexiones hacia internet a sus propias direcciones IP públicas, y de esa traducción sale la nueva dirección de salida. Cuando un cortafuegos tiene varias IP públicas, cualquiera de ellas puede aparecer como origen, así que una lista de permitidos tiene que contenerlas todas.
Ambos diseños anteriores son IPv4. Los dos prefijos /1 no hacen nada por IPv6, y el soporte IPv6 de punto a sitio es lo bastante estrecho como para que pruebes la combinación antes de prometer paridad.
Comprueba la ruta y luego la salida
Tras reinstalar el paquete y reconectar, confirma que el cliente realmente instaló las mitades. En Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 y la misma consulta para 128.0.0.0/1 deberían nombrar la interfaz del túnel, y route print muestra ambas junto a tu ruta predeterminada original. En Linux, ip route show debe listar los dos prefijos; si no lo hace, el perfil nunca los transportó.
Luego vuelve a comprobar la dirección pública desde el cliente y lee el registro del cortafuegos para la misma conexión. El origen debería ser la IP pública del cortafuegos con un puerto traducido. Un cliente que sigue saliendo localmente mientras existen ambas rutas significa que los paquetes llegaron a Azure y salieron por otro camino: una ruta definida por el usuario en la subred de la puerta de enlace, un cortafuegos que a su vez está forzado a tunelizar hacia la red local, o una directiva que descarta el flujo antes de la traducción.
Vuelve a probar un destino privado en la misma sesión. Un host de salto que deja de responder tras el cambio es la señal habitual de que los nuevos prefijos han desplazado algo, ya sea una ruta local más estrecha que antes se anunciaba o la resolución de nombres que ahora va a un resolutor sin reenviador para tus zonas privadas.
Cuándo dejar el túnel dividido en paz
Si el objetivo es solo llegar a una API privada, un punto de conexión privado o una página de administración interna, el comportamiento predeterminado es más barato y más silencioso. El túnel forzado añade horas de cortafuegos y cargos de procesamiento de datos, una ruta más larga y un lugar más donde cada flujo de cliente puede fallar. También captura mucho más tráfico que el único destino que te importaba.
Recurre a él cuando el requisito se exprese en términos de salida: un socio debe ver una dirección Azure fija, seguridad quiere las conexiones registradas e inspeccionadas, o los datos tienen que salir por un punto controlado. Aun así, el diseño da a cada usuario una salida compartida, así que la responsabilidad por usuario debe venir de la identidad en la aplicación y no de la dirección de origen.
Antes de cerrar el cambio, confirma cuatro cosas: el paquete de cliente instalado es el nuevo, las dos rutas /1 están en la interfaz del túnel, un destino privado sigue respondiendo y el registro del servicio remoto muestra la dirección del cortafuegos.