A VPN não vazou o seu IP antigo: foi um valor memorizado

Ver o seu antigo endereço público no relatório de um serviço depois de a VPN arrancar não é, por si só, prova de uma fuga. A ligação ativa pode estar a usar a saída do túnel enquanto a aplicação envia um valor que aprendeu antes de o túnel existir. São duas provas diferentes, e só uma descreve o pacote atual. A outra é um valor que sobreviveu à reconexão porque nada no caminho de rede é seu dono.

As duas explicações por trás de um endereço

A sequência que as pessoas imaginam é um pacote a sair da interface física enquanto a VPN está supostamente ativa. A sequência que muitas vezes explica o relatório é mais curta e mais aborrecida: uma aplicação aprendeu um endereço antes e ainda o guarda. Ordenar os acontecimentos separa as duas.

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

Nada nessa ordem exige uma ligação ativa a partir do primeiro endereço. O valor memorizado viaja dentro da mensagem, enquanto o cabeçalho transporta a saída que a rota atual escolheu. Um serviço que registe ambos os campos vai mostrá-los lado a lado e parecer contraditório.

Isso é uma explicação possível, não uma acusação a um cliente específico. A reputação não é prova: um código que pode ler, uma marca em que confia ou uma saída diferente não dizem nada sobre o que um programa guardou ou enviou.

A memória da aplicação sobrevive à reconexão

Ligar uma VPN muda a rota que uma nova ligação toma. Deixa o estado da aplicação em paz e não pode retirar informação que um serviço remoto já armazenou. Um programa pode enviar um identificador de conta, uma localização guardada, um nome de dispositivo ou outro valor obtido antes, e a cifragem protege essa carga em trânsito sem retirar nada dela. A reconexão é um acontecimento de rede; o valor retido é um acontecimento da aplicação.

A distinção importa porque os dois vivem em lugares diferentes. O estado da aplicação pertence ao programa e sobrevive a reinícios, enquanto a rota pertence ao sistema operativo e é reconstruída a cada ligação. Limpar um não tem efeito sobre o outro.

Um serviço também pode guardar um valor que lhe entregou há meses, e nesse caso nenhuma mudança local o removerá. Isso é retenção, e fica completamente fora do túnel.

Leia primeiro o cabeçalho de origem, depois a carga

Comece por determinar onde o endereço apareceu. O registo de ligações de um servidor descreve a origem ativa, enquanto um campo de mensagem, um perfil de conta ou um ecrã de diagnóstico local podem descrever um valor enviado ou guardado muito antes. Essas observações respondem a perguntas diferentes.

Compare também os tempos. Se o endereço antigo aparecer num campo anterior à ligação VPN, a explicação da carga é mais forte. Se o servidor registar uma ligação direta a partir do endereço antigo enquanto o túnel está ativo, isso é uma questão de encaminhamento e precisa de outra investigação. Ordenar primeiro os tipos de observação impede que um endereço seja esticado até se tornar prova de três acontecimentos.

Mantenha-os separados nas suas notas: origem da ligação, campo da mensagem, ecrã da conta, diagnóstico local. Um endereço escrito em quatro lugares continua a ser um endereço.

A retenção é uma fase diferente do transporte

As orientações de privacidade em RFC 6973 tratam a recolha, o uso, a divulgação e a retenção como fases distintas, e avisam que identificadores reutilizados tornam a correlação fácil. Um novo caminho de rede muda a fase de transporte e nada mais. Os registos que o destinatário já tem não são tocados, e também não qualquer perfil que tenha guardado o valor à entrada. É por isso que uma reconexão pode parecer uma falha enquanto o transporte se comporta corretamente.

Nenhum filtro de pacotes pode apagar um valor dos registos de um destinatário, e reconectar outra vez não limpará o histórico guardado de cada programa. São problemas do proprietário dos dados, não do túnel, e precisam de outro tipo de solução. Pergunte ao serviço o que guarda e durante quanto tempo antes de pedir à rede que o esconda.

O que verificar antes de culpar o túnel

Reveja a recolha documentada da aplicação e os controlos da conta, e decida que campos pode enviar, quanto tempo o serviço os guarda e se a conta os pode apagar ou corrigir. Depois faça o teste que separa as explicações: uma conta nova ou um perfil de aplicação limpo. Se o valor antigo desaparecer, havia retenção ou estado em cache. Se sobreviver a um perfil limpo, examine o campo real do pedido antes de concluir que a VPN falhou.

Se existir realmente uma ligação direta, trate-a como uma descoberta do caminho de rede. Investigue o encaminhamento, o túnel dividido e a política do cliente nos seus próprios termos, e não misture esse resultado com um valor de carga que simplesmente sobreviveu à reconexão. As duas falhas parecem-se numa captura de ecrã e comportam-se de forma muito diferente numa captura de tráfego.