Por que cae a túa VPN cando cambia o Wi-Fi ou se conecta o Ethernet

Dúas cousas notifícanse como unha soa falla: o portátil pasou a outra rede Wi-Fi, ou conectouse un cable mentres o Wi-Fi seguía activo. O cliente segue dicindo conectado, a icona parece san e o túnel non transporta nada. Por debaixo, só tres pezas de estado poden moverse - a ligazón, o enderezo local, a ruta por defecto - e cal se moveu decide se o túnel se recupera só ou necesita reconectar. Revísoas nesa orde, porque cambiar os axustes da conta nunca arranxou ningunha.

Ligazón, enderezo e ruta móvense por separado

A itinerancia entre puntos de acceso da mesma rede adoita ser un evento de L2. A radio reasóciase, a interface conserva o seu enderezo e a súa pasarela, e nada do que depende o túnel cambia, por iso cruzar unha oficina grande ás veces pasa desapercibido. Unirse a un SSID distinto non é iso: a interface antiga pode caer, DHCP reparte un enderezo novo, unha pasarela nova e resolvedores novos, e o fluxo exterior que usaba o túnel deixa de existir.

O Ethernet engade unha terceira forma. O Wi-Fi nunca cae, así que non se dispara ningún evento de ligazón, pero a interface cableada aparece co seu propio enderezo e a miúdo gaña a ruta por defecto pola métrica. O túnel segue funcionando por un camiño que xa non é preferido, ou o cliente mantén o seu socket pegado á rede sen fíos na que comezou. Desde o navegador ambos se ven igual: as páxinas atascan no momento en que o cable encaixa.

Así que a primeira pregunta non é se cambiou o Wi-Fi. É se cambiou o enderezo ao que estás ligado, ou a ruta ata o punto final, mentres o túnel estaba activo.

O socket exterior está pegado a un enderezo que acaba de desaparecer

Cada túnel é un fluxo exterior: un enderezo e un porto locais que falan co enderezo e o porto do servidor. En Linux iso é un socket UDP ligado á orixe antiga; cando se elimina a interface que ten o enderezo, os envíos ou fallan con EADDRNOTAVAIL ou saen pola interface nova cunha orixe que o servidor nunca viu.

O lado remoto garda a súa propia fixación. Unha SA de IKEv2 sen MOBIKE identifícase polo par de enderezos, e unha OpenVPN sesión está ligada ao enderezo do par que aprendeu, e unha mapaxe NAT pertence ao enderezo privado, ao porto e ao enderezo público que a crearon. Móvete detrás doutro NAT e cada resposta envíase a unha mapaxe que xa non existe. Nada na túa máquina está mal configurado; a quíntupla apunta a unha rede que deixaches.

Le o estado antes de teorizar:

• ss -unp mostra o enderezo e o porto locais que cada socket de túnel ten de verdade.
• ip route get 203.0.113.10 imprime o enderezo de orixe e o dispositivo que o núcleo usaría para o punto final agora mesmo.
• wg show wg0 endpoints, swanctl --list-sas ou o rexistro do cliente mostra o enderezo do par co que o lado remoto cre que fala.

Se o enderezo do socket e a consulta de ruta non coinciden, atopaches a rotura, e ningún cambio de credenciais a tocará.

Que fai cada protocolo cun enderezo de orixe novo

Os clientes absorben o cambio en distinto grao, e a táboa é o que comparo coa configuración do cliente en lugar de adiviñar polo comportamento de reconexión.

A regra de itinerancia de WireGuard só funciona nunha dirección: o cliente ten que enviar primeiro desde o enderezo novo. Un socket aínda ligado á interface antiga nunca o fai, por iso un túnel pode parecer vivo mentres o seu temporizador de aperto de man envellece. descrición do protocolo precisa a condición de actualización do punto final, e paga a pena lela antes de cambiar unha configuración.

MOBIKE négase, non se supón. Se o servidor non o ofrece, o cliente debe restablecer, e iso é un feito que confirmas desde a lista de SA ou o rexistro e non que deduces dun indicador que xira.

A preferencia de ruta decide o camiño, non a icona do Wi-Fi

Coas dúas interfaces arriba, o núcleo elixe por métrica e lonxitude de prefixo. ip route show default lista os candidatos e ip route get 203.0.113.10 resolve a decisión real, incluído o enderezo de orixe. Unha ruta por defecto cableada con métrica 100 e unha sen fíos con 600 significan que o punto final se move no momento en que o cable asenta, mentres que cada aplicación que abriu un socket antes conserva a súa orixe antiga.

Windows fai o mesmo con métricas de interface automáticas, sesgadas pola velocidade da ligazón. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ordena os candidatos e Find-NetRoute -RemoteIPAddress 203.0.113.10 devolve a interface e a orixe que elixiría a pila. Un cliente que liga o seu socket exterior a unha interface segue usándoa despois de que a métrica se invirta; iso é unha decisión de ligazón, non unha falla de encamiñamento.

Android fai visible a división: ConnectivityManager informa das redes dispoñibles e dun valor por defecto aparte, e unha aplicación VPN que liga un socket a un obxecto Network mantén esa ligazón ata que a volve facer. En macOS, scutil --nwi imprime a interface principal e a orde que usaría o sistema.

DNS, MTU e IPv6 móvense coa conexión

Unha conexión nova trae resolvedores novos. Con systemd-resolved o DNS é por ligazón, resolvectl status mostra que ligazón responde a un nome, e unha rede de convidados que reparte o seu propio resolvedor pode deixar sen usar o DNS empurrado polo túnel ata que a ligazón volva ser preferida. Un portal cativo empeórao: a primeira petición HTTPS respóndea o portal en lugar do punto final, e o cliente rexistra un servidor morto.

A MTU do camiño tamén cambia. Ethernet e Wi-Fi adoitan levar 1500 bytes, PPPoE 1492, e as ligazóns móbiles a miúdo menos. Un túnel que herda unha MTU menor atasca en paquetes grandes mentres as peticións pequenas pasan, o que se le como unha conexión medio rota. ping -M do -s 1472 203.0.113.10 envía un paquete de 1500 bytes con DF activado; o silencio significa que o camiño é máis pequeno do que supuxeches.

IPv6 é a outra metade. Unha rede que reparte un prefixo novo cambia a orixe que usaría un cliente de dobre pila, e un túnel só v4 deixa o tráfico v6 fóra ata que a política se poña ao día. ip -6 route show default e ip -6 addr show responden se a ligazón nova ten algún camiño v6.

Reproduce a transición en lugar de describila

Escolle unha petición inofensiva e executa os mesmos tres comandos a ambos os dous lados do cambio: ip -br addr, ip route show default, ip route get 203.0.113.10. Despois observa se o túnel segue emitindo paquetes - tcpdump -ni any udp port 51820 para WireGuard, o porto correspondente para calquera outra cousa. Os paquetes que saen da orixe antiga significan un problema de ligazón. Os paquetes que saen da orixe nova sen resposta significan o lado remoto ou o NAT polo medio.

Anota que evento coincidiu coa primeira falla: caída da ligazón, cambio de enderezo ou cambio da ruta por defecto. Apuntan a responsables distintos - un cliente que debe volver ligarse, un enderezo que debe volver obterse ou unha ruta que pertence a un ficheiro de configuración e non a unha regra de evitación permanente.

Antes de dalo por arranxado, confirma que o bloque de tráfico directo segue aguantando durante o oco e que os nomes se resolven pola conexión nova. Se o cliente conserva o punto final antigo tras o cambio, arranxa primeiro o axuste de itinerancia ou de float. Se fai a itinerancia ben e aínda non recibe resposta, mira a identidade do par no servidor e o NAT do camiño, e garda os dous contextos de rede no informe para que a seguinte persoa poida comparalos.