VPN connectat però l'adreça IP no ha canviat: per què

Et connectes, el client diu que està connectat i la prova d'adreça encara mostra el mateix número que tenies abans. L'indicador no té cap problema; alguna cosa entre el perfil i l'aplicació va mantenir aquella petició fora del túnel. Decideix a quina de tres coses estàs mirant abans de tocar cap configuració: una prova que mai va mesurar l'adreça pública, un túnel que només cobreix part del trànsit o un segon camí que guanya la decisió d'encaminament. Cadascuna té una comprovació que dura menys d'un minut.

Confirma què va mesurar realment la prova

L'adreça que es mostra al diàleg de Wi-Fi o Ethernet és l'adreça de la interfície del teu propi segment, no l'adreça que veu un lloc web, així que pot quedar idèntica mentre el túnel funciona perfectament. La ubicació torna a ser un senyal a part: una regió de compte desada o una lectura de geolocalització permesa no es mou quan canvies la sortida, i un inici de sessió que ja et reconeix tampoc.

Fes servir un ressò d'adreça pública i pregunta cada família per separat, perquè el resultat d'una prova de doble pila amaga el cas interessant:

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

Executa tots dos abans i després de connectar-te. Si la resposta IPv4 canvia a l'adreça de sortida i la IPv6 no, no tens un túnel trencat; tens una família que viatja fora d'ell. Si totes dues respostes es queden igual, la petició no va arribar mai al túnel i la resta d'això s'aplica.

El perfil pot cobrir només part del trànsit

Un perfil de túnel dividit és la resposta habitual i no és cap defecte. OpenVPN ho envia tot pel túnel només quan redirect-gateway és a les opcions enviades; sense això el client rep un grapat de rutes concretes i la teva ruta per defecte es queda a l'enllaç físic. A Windows el mateix commutador apareix com «Utilitza la passarel·la predeterminada a la xarxa remota» a les propietats IPv4 de l'adaptador, i desmarcar-lo és una decisió deliberada que sobreviu a cada reconnexió.

L'abast per aplicació és la segona capa. El paràmetre VPN per aplicació d'Android decideix quines aplicacions hi són incloses, així que la clau VPN de la barra d'estat no demostra que el navegador hi sigui dins. Una extensió del navegador que fa de proxy del seu propi trànsit crea la imatge mirall: el navegador mostra l'adreça de sortida mentre un client de correu o un joc a la mateixa màquina encara mostra la teva. Compara la mateixa petició en dues aplicacions. Si una canvia i l'altra no, estàs mirant l'abast, no un túnel que falla.

Una família d'adreces encara pot anar directa

La majoria de perfils VPN es van escriure per a IPv4, i molts encara ho són. En una xarxa de doble pila el túnel pren 10.8.0.x per a IPv4 mentre l'enllaç físic conserva una adreça IPv6 global i una ruta per defecte, així que un lloc compatible amb IPv6 s'assoleix directament i l'adreça que informa és la del teu proveïdor. Això és una fuita amb un túnel IPv4 que funciona, i és invisible per a una prova que només parla IPv4.

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

Llegeix la interfície de cada resposta. Si la consulta IPv6 anomena el teu dispositiu Ethernet o Wi-Fi mentre la consulta IPv4 anomena el túnel, la política d'aquella família falta en lloc d'estar trencada. Apagar IPv6 a tot el dispositiu fa desaparèixer el símptoma i amaga la decisió; prefereix arreglar la cobertura del perfil o desactivar la família només en aquella connexió, i anota quina de les dues has triat.

Un segon camí pot guanyar la consulta

Un proxy competidor, un segon client VPN, un adaptador virtual d'un contenidor o d'una eina d'escriptori remot, o una ruta extra per al prefix exacte que estàs provant poden prendre precedència. Una ruta específica sempre guanya una ruta per defecte, així que un /24 residual per al lloc que mesures, apuntant a la teva passarel·la LAN, continua enviant aquell trànsit fora del túnel per molt sa que estigui el túnel.

Fes un inventari abans de canviar res, amb ordres només de lectura:

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

Busca més d'una ruta per defecte amb una mètrica plausible, i una ruta específica que cobreixi la destinació. Al navegador, comprova també si una extensió de proxy o el paràmetre de proxy del sistema posseeix la connexió; una extensió pot nomenar el seu propi upstream i deixar la sortida del sistema operatiu intacta, cosa que produeix una adreça diferent al navegador que en un terminal a la mateixa màquina.

Torna a mesurar amb una petició nova

Reconnecta't i després repeteix la mesura des de la mateixa aplicació amb què vas provar el primer cop, perquè una pàgina en memòria cau o una connexió reutilitzada informa de l'estat antic. Observa el registre o la vista d'esdeveniments del client durant la connexió: un error en aplicar rutes després de l'autenticació és una prova més forta que qualsevol indicador, i normalment nomena la ruta o l'adaptador que ha fallat.

Mantén dos resultats separats. Si l'adreça canvia però un lloc encara et rebutja, el túnel funciona i el lloc rebutja una adreça de centre de dades; és un altre problema amb una altra resposta. Si l'adreça no canvia mai, passa les quatre preguntes en ordre: quina adreça va imprimir la prova, quina família era, quina aplicació va fer la petició i quina ruta va seguir aquella petició. La documentació de Microsoft sobre les decisions d'encaminament de VPN explica com un client de Windows tria entre el túnel i l'adaptador físic quan tots dos tenen una ruta.