VPN conectada pero la dirección IP no ha cambiado: por qué

Te conectas, el cliente dice conectado y la prueba de dirección sigue mostrando el mismo número que tenías antes. El indicador no tiene nada malo; algo entre el perfil y la aplicación mantuvo esa petición fuera del túnel. Decide cuál de tres cosas estás mirando antes de tocar cualquier configuración: una prueba que nunca midió la dirección pública, un túnel que solo cubre parte del tráfico o un segundo camino que gana la decisión de enrutamiento. Cada una tiene una comprobación que dura menos de un minuto.

Confirma qué midió realmente la prueba

La dirección que se muestra en el diálogo de Wi-Fi o Ethernet es la dirección de la interfaz en tu propio segmento, no la dirección que ve un sitio web, así que puede quedarse idéntica mientras el túnel funciona perfectamente. La ubicación vuelve a ser una señal aparte: una región de cuenta guardada o una lectura de geolocalización permitida no se mueven cuando cambias la salida, y un inicio de sesión que ya te reconoce tampoco.

Usa un eco de dirección pública y pregunta a cada familia por separado, porque el resultado de una prueba de doble pila esconde el caso interesante:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Ejecuta ambos antes y después de conectar. Si la respuesta IPv4 cambia a la dirección de salida y la IPv6 no, no tienes un túnel roto; tienes una familia que viaja fuera de él. Si ambas respuestas siguen iguales, la petición nunca llegó al túnel y el resto de esto se aplica.

El perfil puede cubrir solo parte del tráfico

Un perfil de túnel dividido es la respuesta habitual y no es un defecto. OpenVPN lo envía todo por el túnel solo cuando redirect-gateway está entre las opciones enviadas; sin él, el cliente recibe un puñado de rutas concretas y tu ruta predeterminada se queda en el enlace físico. En Windows el mismo conmutador aparece como «Usar puerta de enlace predeterminada en la red remota» en las propiedades IPv4 del adaptador, y desmarcarlo es una decisión deliberada que sobrevive a cada reconexión.

El alcance por aplicación es la segunda capa. El ajuste de VPN por aplicación de Android decide qué aplicaciones están incluidas, así que la llave VPN de la barra de estado no demuestra que el navegador esté dentro. Una extensión del navegador que hace de proxy de su propio tráfico crea la imagen espejo: el navegador muestra la dirección de salida mientras un cliente de correo o un juego en la misma máquina sigue mostrando la tuya. Compara la misma petición en dos aplicaciones. Si una cambia y la otra no, estás mirando el alcance, no un túnel que falla.

Una familia de direcciones todavía puede ir directa

La mayoría de los perfiles VPN se escribieron para IPv4, y muchos siguen así. En una red de doble pila el túnel toma 10.8.0.x para IPv4 mientras el enlace físico conserva una dirección IPv6 global y una ruta predeterminada, así que un sitio compatible con IPv6 se alcanza directamente y la dirección que informa es la de tu proveedor. Eso es una fuga con un túnel IPv4 que funciona, y es invisible para una prueba que solo habla IPv4.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Lee la interfaz en cada respuesta. Si la consulta IPv6 nombra tu dispositivo Ethernet o Wi-Fi mientras la consulta IPv4 nombra el túnel, la política de esa familia falta en lugar de estar rota. Apagar IPv6 en todo el dispositivo hace desaparecer el síntoma y esconde la decisión; prefiere arreglar la cobertura del perfil o desactivar la familia solo en esa conexión, y anota cuál de las dos elegiste.

Un segundo camino puede ganar la consulta

Un proxy competidor, un segundo cliente VPN, un adaptador virtual de un contenedor o de una herramienta de escritorio remoto, o una ruta extra para el prefijo exacto que estás probando pueden tomar precedencia. Una ruta específica siempre gana a una predeterminada, así que un /24 sobrante para el sitio que mides, apuntando a tu puerta de enlace LAN, sigue enviando ese tráfico fuera del túnel por muy sano que esté el túnel.

Haz un inventario antes de cambiar nada, con comandos de solo lectura:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Busca más de una ruta predeterminada con una métrica plausible, y una ruta específica que cubra el destino. En un navegador, comprueba también si una extensión de proxy o el ajuste de proxy del sistema posee la conexión; una extensión puede nombrar su propio origen y dejar intacta la salida del sistema operativo, lo que produce una dirección distinta en el navegador que en un terminal de la misma máquina.

Vuelve a medir con una petición nueva

Reconecta y luego repite la medición desde la misma aplicación con la que probaste la primera vez, porque una página en caché o una conexión reutilizada informa del estado antiguo. Observa el registro o la vista de eventos del cliente durante la conexión: un error al aplicar rutas después de la autenticación es una prueba más fuerte que cualquier indicador, y normalmente nombra la ruta o el adaptador que falló.

Mantén dos resultados separados. Si la dirección cambia pero un sitio sigue rechazándote, el túnel funciona y el sitio rechaza una dirección de centro de datos; ese es otro problema con otra respuesta. Si la dirección nunca cambia, recorre las cuatro preguntas en orden: qué dirección imprimió la prueba, qué familia era, qué aplicación hizo la petición y qué ruta siguió esa petición. La documentación de Microsoft sobre las decisiones de enrutamiento de VPN explica cómo un cliente de Windows elige entre el túnel y el adaptador físico cuando ambos tienen una ruta.