VPN conectada pero o enderezo IP non cambiou: por que

Conectas, o cliente di conectado e a proba de enderezo segue amosando o mesmo número que tiñas antes. O indicador non ten nada malo; algo entre o perfil e a aplicación mantivo esa petición fóra do túnel. Decide cal de tres cousas estás mirando antes de tocar calquera configuración: unha proba que nunca mediu o enderezo público, un túnel que só cobre parte do tráfico ou un segundo camiño que gaña a decisión de encamiñamento. Cada unha ten unha comprobación que dura menos dun minuto.

Confirma que mediu realmente a proba

O enderezo que se mostra no diálogo de Wi-Fi ou Ethernet é o enderezo da interface no teu propio segmento, non o enderezo que ve un sitio web, así que pode quedar idéntico mentres o túnel funciona perfectamente. A localización volve ser un sinal aparte: unha rexión de conta gardada ou unha lectura de xeolocalización permitida non se move cando cambias a saída, e un inicio de sesión que xa te recoñece tampouco.

Usa un eco de enderezo público e pregunta a cada familia por separado, porque o resultado dunha proba de dobre pila esconde o caso interesante:

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

Executa ambos antes e despois de conectar. Se a resposta IPv4 cambia ao enderezo de saída e a IPv6 non, non tes un túnel roto; tes unha familia que viaxa fóra del. Se ambas respostas seguen iguais, a petición nunca chegou ao túnel e o resto disto aplícase.

O perfil pode cubrir só parte do tráfico

Un perfil de túnel dividido é a resposta habitual e non é un defecto. OpenVPN envíao todo polo túnel só cando redirect-gateway está entre as opcións enviadas; sen el, o cliente recibe un puñado de rutas concretas e a túa ruta predeterminada queda na ligazón física. En Windows o mesmo conmutador aparece como «Usar pasarela predeterminada na rede remota» nas propiedades IPv4 do adaptador, e desmarcalo é unha decisión deliberada que sobrevive a cada reconexión.

O alcance por aplicación é a segunda capa. O axuste de VPN por aplicación de Android decide que aplicacións están incluídas, así que a chave VPN da barra de estado non demostra que o navegador estea dentro. Unha extensión do navegador que fai de proxy do seu propio tráfico crea a imaxe espello: o navegador mostra o enderezo de saída mentres un cliente de correo ou un xogo na mesma máquina segue mostrando o teu. Compara a mesma petición en dúas aplicacións. Se unha cambia e a outra non, estás mirando o alcance, non un túnel que falla.

Unha familia de enderezos aínda pode ir directa

A maioría dos perfís VPN escribíronse para IPv4, e moitos seguen así. Nunha rede de dobre pila o túnel toma 10.8.0.x para IPv4 mentres a ligazón física conserva un enderezo IPv6 global e unha ruta predeterminada, así que un sitio compatible con IPv6 alcánzase directamente e o enderezo que informa é o do teu provedor. Iso é unha fuga cun túnel IPv4 que funciona, e é invisible para unha proba que só fala IPv4.

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

Le a interface en cada resposta. Se a consulta IPv6 nomea o teu dispositivo Ethernet ou Wi-Fi mentres a consulta IPv4 nomea o túnel, falta a política desa familia en lugar de estar rota. Apagar IPv6 en todo o dispositivo fai desaparecer o síntoma e esconde a decisión; prefire arranxar a cobertura do perfil ou desactivar a familia só nesa conexión, e anota cal das dúas escolliches.

Un segundo camiño pode gañar a consulta

Un proxy competidor, un segundo cliente VPN, un adaptador virtual dun contedor ou dunha ferramenta de escritorio remoto, ou unha ruta extra para o prefixo exacto que estás probando poden tomar precedencia. Unha ruta específica sempre gaña a unha predeterminada, así que un /24 sobrante para o sitio que mides, apuntando á túa pasarela LAN, segue enviando ese tráfico fóra do túnel por moi san que estea o túnel.

Fai un inventario antes de cambiar nada, con ordes só de lectura:

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

Busca máis dunha ruta predeterminada cunha métrica plausible, e unha ruta específica que cubra o destino. Nun navegador, comproba tamén se unha extensión de proxy ou o axuste de proxy do sistema posúe a conexión; unha extensión pode nomear o seu propio orixe e deixar intacta a saída do sistema operativo, o que produce un enderezo distinto no navegador que nun terminal da mesma máquina.

Volve medir cunha petición nova

Reconecta e despois repite a medición desde a mesma aplicación coa que probaches a primeira vez, porque unha páxina en caché ou unha conexión reutilizada informa do estado antigo. Observa o rexistro ou a vista de eventos do cliente durante a conexión: un erro ao aplicar rutas despois da autenticación é unha proba máis forte que calquera indicador, e normalmente nomea a ruta ou o adaptador que fallou.

Mantén dous resultados separados. Se o enderezo cambia pero un sitio segue rexeitándote, o túnel funciona e o sitio rexeita un enderezo de centro de datos; ese é outro problema con outra resposta. Se o enderezo nunca cambia, percorre as catro preguntas en orde: que enderezo imprimiu a proba, que familia era, que aplicación fixo a petición e que ruta seguiu esa petición. A documentación de Microsoft sobre as decisións de encamiñamento de VPN explica como un cliente de Windows escolle entre o túnel e o adaptador físico cando ambos teñen unha ruta.