O VPN reconecta ao dirigir: mudança de rádio ou mudança de IP?

A chamada cai quando você passa pela borda da cidade, e o ícone do VPN desaparece no mesmo instante. É tentador registrar isso como “a troca de torre matou o túnel”. Aconteceram duas coisas diferentes, e só uma delas tem a ver com torres. Uma transferência de rádio pode deixar o seu endereço IP, a rota padrão e a sessão completamente intactos, enquanto uma mudança de endereço real quebrará qualquer túnel que não consiga se mover com ela. Comparar como os clientes tratam esse segundo caso é o exercício útil, porque diz se você está vendo um comportamento projetado ou um bug.

Uma troca de torre não é necessariamente uma troca de endereço

As redes móveis mantêm a sessão de pacotes viva durante as transferências enquanto a âncora de mobilidade da operadora continuar a mesma. O enlace de rádio muda, o túnel não percebe e nenhuma reconexão deveria aparecer em log algum. Este é o caso comum para deslocamentos dentro de uma cidade.

O que muda o endereço é um deslocamento entre âncoras, uma troca de Wi-Fi para celular ou um restabelecimento do túnel do lado da operadora após uma pausa longa. Esses eventos substituem o endereço de origem que os seus pacotes carregam, e um par do VPN vê um par que se moveu.

A consequência prática é que o deslocamento não é prova. Um aparelho que percorreu quarenta quilômetros pode ter mantido um único endereço o caminho inteiro, e um aparelho parado pode ter mudado de endereço duas vezes porque a rede decidiu assim. Registrar o evento é a única forma de distingui-los.

Dois projetos: mover o túnel ou reconstruí-lo

Os clientes diferem em quanto se importam que a fonte externa tenha mudado. Alguns amarram o túnel ao endereço sobre o qual foi construído e exigem um restabelecimento completo. Outros autenticam cada pacote de forma independente e apenas atualizam para onde enviam as respostas.

A linha de cima explica muitos relatórios confusos. O WireGuard não tem sessão para quebrar: cada pacote carrega o índice do par e é autenticado, então um pacote válido que chega de um endereço novo é, por definição, daquele par, e o endpoint registrado o segue. Um cliente que mostra “conectado” continuamente durante um percurso está dizendo a verdade.

A linha de baixo também não é um defeito. Reconstruir a sessão executa a autenticação novamente contra o endereço atual, que é exatamente o que você quer quando o endereço antigo agora pode pertencer a outra pessoa.

Observe o evento em vez do deslocamento

No Android, o subsistema de conectividade relata mudanças de rede como eventos, e são esses que você deve correlacionar com o comportamento do cliente. O despejo é extenso, mas as partes relevantes são a rede padrão e o endereço dela:

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

Do lado do servidor há uma medição direta para o caso de roaming. O WireGuard guarda o último endpoint autenticado por par, então uma mudança de endereço aparece como um valor alterado em vez de uma reconexão:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Compare o endpoint antes e depois do percurso. Se o endereço e a porta não mudaram, o túnel nunca precisou fazer nada e a reconexão veio de outro lugar, normalmente do aplicativo. Se o endpoint mudou enquanto o carimbo de tempo do handshake se manteve perto do intervalo normal de renovação de chave, o túnel se moveu em vez de reiniciar.

Um reinício parece diferente: o carimbo de tempo do handshake é redefinido para o momento da reconexão, e o cliente registra uma sequência de inicialização em vez de uma continuação silenciosa.

Quando a reconexão é o comportamento correto

Tratar toda reconexão como falha leva a configurações que mantêm sessões mortas vivas. Um par cujo endereço mudou porque a rede o realocou não deveria continuar recebendo tráfego para o mapeamento antigo, e um cliente que continua em silêncio pode acabar enviando para um buraco negro enquanto o ícone permanece verde.

Compare as duas falhas do ponto de vista do usuário. Uma reconexão custa alguns segundos e uma nova autenticação. Um túnel obsoleto custa um aplicativo que trava sem erro, o que é muito mais difícil de explicar e muito mais provável de ser relatado como “a internet quebrou”.

Há também uma questão de política escondida por baixo. Durante o intervalo entre perder um caminho e estabelecer outro, alguns clientes voltam a enviar tráfego diretamente. Evitar isso é um controle separado da recuperação automática, e um cliente pode ser bom em um e ruim no outro. Decida de qual você precisa antes de ajustar qualquer um dos dois.

Anote a sequência observada

Um relatório útil nomeia a fonte do evento: uma mudança de rede padrão com um novo endereço, uma troca de Wi-Fi para celular ou uma transferência sem nenhuma mudança de endereço. Depois informa o que o cliente fez, com o carimbo de tempo do lado do servidor em vez da memória.

Se o túnel se moveu, diga isso e anote a nova família de endpoints. Se foi restabelecido, anote se a autenticação teve sucesso na primeira tentativa e quanto durou o intervalo. Esses três fatos distinguem um projeto móvel saudável de um cliente que oscila entre redes.

E evite a frase “troca de torre” a menos que o log do dispositivo realmente a comprove. A documentação de conectividade do Android descreve os callbacks que distinguem disponibilidade de uma mudança de rede padrão, e é essa distinção que o seu relatório precisa. Todo o resto é uma história sobre dirigir.