VPN conectada mas o endereço IP não mudou: por quê

Você se conecta, o cliente diz conectado e o teste de endereço ainda mostra o mesmo número de antes. Não há nada errado com o indicador; algo entre o perfil e o aplicativo manteve essa requisição fora do túnel. Decida qual de três coisas você está vendo antes de tocar em qualquer configuração: um teste que nunca mediu o endereço público, um túnel que cobre apenas parte do tráfego ou um segundo caminho que vence a decisão de roteamento. Cada um tem uma verificação que dura menos de um minuto.

Confirme o que o teste realmente mediu

O endereço mostrado na caixa de diálogo Wi-Fi ou Ethernet é o endereço da interface no seu próprio segmento, não o endereço que um site vê, então ele pode continuar idêntico enquanto o túnel funciona perfeitamente. A localização é novamente um sinal separado: uma região de conta salva ou uma leitura de geolocalização permitida não se move quando você troca a saída, e um login que já reconhece você também não.

Use um eco de endereço público e pergunte a cada família separadamente, porque o resultado de um teste de pilha dupla esconde o caso interessante:

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

Execute ambos antes e depois de conectar. Se a resposta IPv4 muda para o endereço de saída e a resposta IPv6 não, você não tem um túnel quebrado; tem uma família viajando fora dele. Se ambas as respostas continuarem iguais, a requisição nunca chegou ao túnel e o resto disto se aplica.

O perfil pode cobrir apenas parte do tráfego

Um perfil de túnel dividido é a resposta comum e não é um defeito. OpenVPN envia tudo pelo túnel apenas quando redirect-gateway está entre as opções enviadas; sem ele, o cliente recebe um punhado de rotas específicas e a sua rota padrão fica no link físico. No Windows o mesmo comutador aparece como «Usar gateway padrão na rede remota» nas propriedades IPv4 do adaptador, e desmarcá-lo é uma escolha deliberada que sobrevive a cada reconexão.

O escopo por aplicativo é a segunda camada. A configuração de VPN por aplicativo do Android decide quais aplicativos estão incluídos, então a chave VPN na barra de status não prova que o navegador esteja dentro. Uma extensão de navegador que faz proxy do próprio tráfego cria a imagem espelhada: o navegador mostra o endereço de saída enquanto um cliente de e-mail ou jogo na mesma máquina ainda mostra o seu. Compare a mesma requisição em dois aplicativos. Se um muda e o outro não, você está olhando o escopo, não um túnel falhando.

Uma família de endereços ainda pode ir direto

A maioria dos perfis VPN foi escrita para IPv4, e muitos ainda são. Numa rede de pilha dupla o túnel pega 10.8.0.x para IPv4 enquanto o link físico mantém um endereço IPv6 global e uma rota padrão, então um site compatível com IPv6 é alcançado diretamente e o endereço que ele informa é o do seu provedor. Isso é um vazamento com um túnel IPv4 funcionando, e é invisível para um teste que só fala IPv4.

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

Leia a interface em cada resposta. Se a consulta IPv6 nomeia o seu dispositivo Ethernet ou Wi-Fi enquanto a consulta IPv4 nomeia o túnel, a política para essa família falta em vez de estar quebrada. Desligar IPv6 no dispositivo inteiro faz o sintoma desaparecer e esconde a decisão; prefira corrigir a cobertura do perfil ou desativar a família apenas naquela conexão, e anote qual das duas você escolheu.

Um segundo caminho pode vencer a consulta

Um proxy concorrente, um segundo cliente VPN, um adaptador virtual de um contêiner ou de uma ferramenta de desktop remoto, ou uma rota extra para o prefixo exato que você testa podem todos ter precedência. Uma rota específica sempre vence uma rota padrão, então um /24 restante para o site que você mede, apontando para o seu gateway LAN, continua enviando esse tráfego para fora do túnel por mais saudável que o túnel esteja.

Faça um inventário antes de mudar qualquer coisa, com comandos somente de leitura:

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

Procure mais de uma rota padrão com uma métrica plausível, e uma rota específica que cubra o destino. No navegador, verifique também se uma extensão de proxy ou a configuração de proxy do sistema possui a conexão; uma extensão pode nomear o seu próprio upstream e deixar a saída do sistema operacional intacta, o que produz um endereço diferente no navegador do que num terminal na mesma máquina.

Meça de novo com uma requisição nova

Reconecte e depois repita a medição do mesmo aplicativo com que você testou na primeira vez, porque uma página em cache ou uma conexão reutilizada relata o estado antigo. Observe o log ou a visão de eventos do cliente durante a conexão: um erro ao aplicar rotas após a autenticação é uma prova mais forte que qualquer indicador, e geralmente nomeia a rota ou o adaptador que falhou.

Mantenha dois resultados separados. Se o endereço muda mas um site ainda recusa você, o túnel funciona e o site rejeita um endereço de datacenter; esse é outro problema com outra resposta. Se o endereço nunca muda, percorra as quatro perguntas em ordem: qual endereço o teste imprimiu, qual família era, qual aplicativo fez a requisição e qual rota essa requisição seguiu. A documentação da Microsoft sobre decisões de roteamento de VPN explica como um cliente Windows escolhe entre o túnel e o adaptador físico quando ambos têm uma rota.