Porque é que a sua VPN cai quando o Wi-Fi muda ou o Ethernet é ligado

Duas coisas são reportadas como uma única falha: o portátil passou para outra rede Wi-Fi, ou foi ligado um cabo enquanto o Wi-Fi continuava ativo. O cliente continua a dizer ligado, o ícone parece saudável e o túnel não transporta nada. Por baixo, só três peças de estado podem mover-se - a ligação, o endereço local, a rota predefinida - e qual delas se moveu decide se o túnel recupera sozinho ou precisa de nova ligação. Verifico-as nessa ordem, porque mudar definições da conta nunca corrigiu nenhuma.

Ligação, endereço e rota movem-se de forma independente

A itinerância entre pontos de acesso da mesma rede é normalmente um evento de L2. O rádio reassocia, a interface mantém o endereço e o gateway, e nada de que o túnel dependa muda, e é por isso que atravessar um escritório grande às vezes passa despercebido. Juntar-se a outro SSID não é isso: a interface antiga pode cair, o DHCP entrega um novo endereço, um novo gateway e novos resolvedores, e o fluxo exterior que o túnel usava deixa de existir.

O Ethernet acrescenta uma terceira forma. O Wi-Fi nunca cai, por isso não é disparado nenhum evento de ligação, mas a interface com cabo aparece com o seu próprio endereço e muitas vezes ganha a rota predefinida pela métrica. O túnel continua por um caminho que já não é preferido, ou o cliente mantém o socket preso à rede sem fios onde começou. Do browser ambos parecem iguais: as páginas bloqueiam no momento em que o cabo encaixa.

Portanto a primeira pergunta não é se o Wi-Fi mudou. É se o endereço a que está ligado, ou a rota até ao ponto final, mudou enquanto o túnel estava ativo.

O socket exterior está preso a um endereço que acabou de desaparecer

Cada túnel é um fluxo exterior: um endereço e uma porta locais a falar com o endereço e a porta do servidor. No Linux é um socket UDP ligado à origem antiga; quando a interface que tem o endereço é removida, os envios ou falham com EADDRNOTAVAIL ou saem pela interface nova com uma origem que o servidor nunca viu.

O lado remoto guarda a sua própria fixação. Uma SA de IKEv2 sem MOBIKE é identificada pelo par de endereços, e uma OpenVPN sessão está ligada ao endereço do par que aprendeu, e um mapeamento NAT pertence ao endereço privado, à porta e ao endereço público que o criaram. Mude para trás de outro NAT e cada resposta vai para um mapeamento que já não existe. Nada na sua máquina está mal configurado; o quíntuplo aponta para uma rede que abandonou.

Leia o estado antes de teorizar:

• ss -unp mostra o endereço e a porta locais que cada socket de túnel realmente tem.
• ip route get 203.0.113.10 imprime o endereço de origem e o dispositivo que o kernel usaria agora para o ponto final.
• wg show wg0 endpoints, swanctl --list-sas ou o registo do cliente mostra o endereço do par com que o lado remoto pensa estar a falar.

Se o endereço do socket e a consulta de rota não concordarem, encontrou a rutura, e nenhuma mudança de credenciais lhe tocará.

O que cada protocolo faz com um novo endereço de origem

Os clientes absorvem a mudança em graus diferentes, e a tabela é o que comparo com a configuração do cliente em vez de adivinhar pelo comportamento de reconexão.

A regra de itinerância do WireGuard funciona só numa direção: o cliente tem de enviar primeiro a partir do endereço novo. Um socket ainda ligado à interface antiga nunca o faz, e é por isso que um túnel pode parecer vivo enquanto o temporizador de handshake envelhece. descrição do protocolo estabelece com precisão a condição de atualização do ponto final, e vale a pena lê-la antes de alterar uma configuração.

O MOBIKE é negociado, não assumido. Se o servidor não o oferecer, o cliente tem de restabelecer, e isso é um facto que confirma a partir da lista de SA ou do registo, e não que deduz de um indicador a girar.

A preferência de rota decide o caminho, não o ícone do Wi-Fi

Com as duas interfaces ativas, o kernel escolhe por métrica e comprimento de prefixo. ip route show default lista os candidatos e ip route get 203.0.113.10 resolve a decisão real, incluindo o endereço de origem. Uma rota predefinida com cabo na métrica 100 e uma sem fios em 600 significam que o ponto final se desloca no instante em que o cabo assenta, enquanto cada aplicação que abriu um socket antes mantém a sua origem antiga.

O Windows faz o mesmo com métricas de interface automáticas, influenciadas pela velocidade da ligação. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ordena os candidatos e Find-NetRoute -RemoteIPAddress 203.0.113.10 devolve a interface e a origem que a pilha escolheria. Um cliente que liga o seu socket exterior a uma interface continua a usá-la depois de a métrica se inverter; isso é uma decisão de ligação, não uma falha de encaminhamento.

O Android torna a divisão visível: o ConnectivityManager comunica as redes disponíveis e uma predefinição separada, e uma aplicação VPN que liga um socket a um objeto Network mantém essa ligação até a refazer. No macOS, scutil --nwi imprime a interface principal e a ordem que o sistema usaria.

DNS, MTU e IPv6 movem-se com a ligação

Uma nova ligação traz novos resolvedores. Com systemd-resolved o DNS é por ligação, resolvectl status mostra qual ligação responde a um nome, e uma rede de convidados que distribui o seu próprio resolvedor pode deixar o DNS empurrado pelo túnel sem uso até a ligação voltar a ser preferida. Um portal cativo piora isto: o primeiro pedido HTTPS é respondido pelo portal em vez do ponto final, e o cliente regista um servidor morto.

O MTU do caminho também muda. Ethernet e Wi-Fi transportam normalmente 1500 bytes, PPPoE 1492, e as ligações móveis muitas vezes menos. Um túnel que herda um MTU menor bloqueia em pacotes grandes enquanto os pedidos pequenos passam, o que se lê como uma ligação meio quebrada. ping -M do -s 1472 203.0.113.10 envia um pacote de 1500 bytes com DF definido; o silêncio significa que o caminho é menor do que supunha.

O IPv6 é a outra metade. Uma rede que distribui um novo prefixo muda a origem que um cliente de dupla pilha usaria, e um túnel só v4 deixa o tráfego v6 de fora até a política acompanhar. ip -6 route show default e ip -6 addr show respondem se a nova ligação tem algum caminho v6.

Reproduza a transição em vez de a descrever

Escolha um pedido inofensivo e execute os mesmos três comandos dos dois lados da mudança: ip -br addr, ip route show default, ip route get 203.0.113.10. Depois observe se o túnel ainda emite pacotes - tcpdump -ni any udp port 51820 para o WireGuard, a porta correspondente para tudo o resto. Pacotes a sair da origem antiga significam um problema de ligação do socket. Pacotes da origem nova sem resposta significam o lado remoto ou o NAT pelo meio.

Anote que evento coincidiu com a primeira falha: queda da ligação, mudança de endereço ou mudança da rota predefinida. Apontam para responsáveis diferentes - um cliente que tem de se voltar a ligar, um endereço que tem de ser obtido de novo, ou uma rota que pertence a um ficheiro de configuração e não a uma regra de desvio permanente.

Antes de o declarar corrigido, confirme que o bloco de tráfego direto ainda se mantém durante o intervalo e que os nomes se resolvem pela nova ligação. Se o cliente mantiver o ponto final antigo depois da troca, corrija primeiro a definição de itinerância ou de float. Se fizer itinerância corretamente e continuar sem resposta, olhe para a identidade do par no servidor e para o NAT no caminho, e guarde os dois contextos de rede no relatório para que a próxima pessoa os possa comparar.