Per què cau la VPN quan canvia el Wi-Fi o s’endolla l’Ethernet
'Un SSID nou, una itinerància entre punts d’accés i un cable endollat trenquen el túnel en tres llocs diferents. Comproveu l’adreça d’origen, després la ruta i després el protocol.'
Dues coses es reporten com una sola fallada: l’ordinador portàtil s’ha mogut a una altra xarxa Wi-Fi, o s’ha endollat un cable mentre el Wi-Fi seguia actiu. El client encara diu que està connectat, la icona sembla saludable i el túnel no transporta res. A sota, només tres peces d’estat poden moure’s - l’enllaç, l’adreça local, la ruta per defecte - i quina s’ha mogut decideix si el túnel es recupera sol o necessita una reconnexió. Les comprovo en aquest ordre, perquè canviar la configuració del compte no n’ha arreglat mai cap.
Enllaç, adreça i ruta es mouen independentment
La itinerància entre punts d’accés de la mateixa xarxa sol ser un esdeveniment L2. La ràdio es reassocia, la interfície conserva la seva adreça i la seva passarel·la, i res del que depèn el túnel canvia, i per això travessar una oficina gran de vegades passa desapercebut. Unir-se a un SSID diferent no és això: la interfície antiga pot caure, el DHCP reparteix una adreça nova, una passarel·la nova i resolutors nous, i el flux exterior que feia servir el túnel deixa d’existir.
L’Ethernet afegeix una tercera forma. El Wi-Fi no cau mai, així que no es dispara cap esdeveniment d’enllaç, però la interfície cablejada apareix amb la seva pròpia adreça i sovint guanya la ruta per defecte per mètrica. El túnel continua funcionant per un camí que ja no és preferit, o el client manté el seu sòcol fixat a la xarxa sense fils on va començar. Des del navegador tots dos es veuen igual: les pàgines s’encallen en el moment que el cable encaixa.
Així doncs, la primera pregunta no és si el Wi-Fi ha canviat. És si l’adreça a la qual esteu vinculats, o la ruta fins al punt final, ha canviat mentre el túnel era actiu.
El sòcol exterior està fixat a una adreça que acaba de desaparèixer
Cada túnel és un flux exterior: una adreça i un port locals que parlen amb l’adreça i el port del servidor. A Linux això és un sòcol UDP vinculat a l’origen antic; quan s’elimina la interfície que té l’adreça, els enviaments o fallen amb EADDRNOTAVAIL o surten per la interfície nova amb un origen que el servidor no ha vist mai.
El costat llunyà guarda la seva pròpia fixació. Una SA d’IKEv2 sense MOBIKE s’identifica per la parella d’adreces, i una OpenVPN sessió està lligada a l’adreça del parell que ha après, i un mapatge NAT pertany a l’adreça privada, el port i l’adreça pública que l’han creat. Moveu-vos darrere d’un altre NAT i cada resposta s’envia a un mapatge que ja no existeix. No hi ha res mal configurat a la vostra màquina; la quíntuple apunta a una xarxa que heu deixat.
Llegiu l’estat abans de teoritzar:
ss -unpmostra l’adreça i el port locals que cada sòcol de túnel té realment.ip route get 203.0.113.10imprimeix l’adreça d’origen i el dispositiu que el nucli faria servir ara per al punt final.wg show wg0 endpoints,swanctl --list-saso el registre del client mostra l’adreça del parell amb qui el costat llunyà creu que parla.
Si l’adreça del sòcol i la consulta de ruta no coincideixen, heu trobat el trencament, i cap canvi de credencials el tocarà.
Què fa cada protocol amb una adreça d’origen nova
Els clients absorbeixen el canvi en graus diferents, i la taula és el que comparo amb la configuració del client en lloc d’endevinar-ho pel comportament de reconnexió.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
La regla d’itinerància de WireGuard només funciona en una direcció: el client ha d’enviar primer des de l’adreça nova. Un sòcol encara vinculat a la interfície antiga no ho fa mai, i per això un túnel pot semblar viu mentre el seu temporitzador d’encaixada de mans envelleix. descripció del protocol estableix amb precisió la condició d’actualització del punt final, i val la pena llegir-la abans de canviar una configuració.
MOBIKE es negocia, no se suposa. Si el servidor no l’ofereix, el client ha de restablir la connexió, i això és un fet que confirmeu des de la llista d’SA o el registre, no que inferiu d’un indicador que gira.
La preferència de ruta decideix el camí, no la icona del Wi-Fi
Amb totes dues interfícies aixecades, el nucli tria per mètrica i longitud de prefix. ip route show default llista els candidats i ip route get 203.0.113.10 resol la decisió real, inclosa l’adreça d’origen. Una ruta per defecte cablejada amb mètrica 100 i una sense fils amb 600 volen dir que el punt final es mou en el moment que el cable s’assenta, mentre que cada aplicació que va obrir un sòcol abans conserva el seu origen antic.
Windows fa el mateix amb mètriques d’interfície automàtiques, esbiaixades per la velocitat de l’enllaç. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ordena els candidats i Find-NetRoute -RemoteIPAddress 203.0.113.10 retorna la interfície i l’origen que la pila triaria. Un client que vincula el seu sòcol exterior a una interfície continua fent-lo servir després que la mètrica es capgiri; això és una decisió de vinculació, no una fallada d’encaminament.
Android fa visible la divisió: ConnectivityManager informa de les xarxes disponibles i d’un defecte a part, i una aplicació VPN que vincula un sòcol a un objecte Network manté aquesta vinculació fins que la torna a fer. A macOS, scutil --nwi imprimeix la interfície primària i l’ordre que el sistema faria servir.
DNS, MTU i IPv6 es mouen amb l’adjunció
Una adjunció nova porta resolutors nous. Amb systemd-resolved el DNS és per enllaç, resolvectl status mostra quin enllaç respon a un nom, i una xarxa de convidats que reparteix el seu propi resolutor pot deixar el DNS empès pel túnel sense usar fins que l’enllaç torni a ser preferit. Un portal captiu ho empitjora: la primera petició HTTPS la respon el portal en lloc del punt final, i el client enregistra un servidor mort.
L’MTU del camí també canvia. L’Ethernet i el Wi-Fi solen portar 1500 bytes, el PPPoE 1492, i els enllaços mòbils sovint menys. Un túnel que hereta un MTU més petit s’encalla en paquets grans mentre les peticions petites tenen èxit, cosa que es llegeix com una connexió mig trencada. ping -M do -s 1472 203.0.113.10 envia un paquet de 1500 bytes amb DF activat; el silenci vol dir que el camí és més petit del que suposàveu.
IPv6 és l’altra meitat. Una xarxa que reparteix un prefix nou canvia l’origen que faria servir un client de doble pila, i un túnel només v4 deixa el trànsit v6 fora fins que la política s’hi posa al dia. ip -6 route show default i ip -6 addr show responen si l’enllaç nou té algun camí v6.
Reproduïu la transició en lloc de descriure-la
Trieu una petició inofensiva i executeu les mateixes tres ordres a banda i banda del canvi: ip -br addr, ip route show default, ip route get 203.0.113.10. Després observeu si el túnel encara emet paquets - tcpdump -ni any udp port 51820 per a WireGuard, el port corresponent per a qualsevol altra cosa. Els paquets que surten de l’origen antic volen dir un problema de vinculació. Els paquets que surten de l’origen nou sense resposta volen dir el costat llunyà o el NAT pel mig.
Anoteu quin esdeveniment va coincidir amb la primera fallada: caiguda de l’enllaç, canvi d’adreça o canvi de ruta per defecte. Aquests assenyalen responsables diferents - un client que s’ha de tornar a vincular, una adreça que s’ha de tornar a obtenir o una ruta que pertany a un fitxer de configuració i no a una regla de bypass permanent.
Abans de donar-ho per arreglat, confirmeu que el bloc de trànsit directe encara aguanta durant el buit i que els noms es resolen per l’adjunció nova. Si el client manté el punt final antic després del canvi, arregleu primer la configuració d’itinerància o de float. Si fa la itinerància correctament i encara no rep resposta, mireu la identitat del parell al servidor i el NAT del camí, i conserveu tots dos contextos de xarxa a l’escrit perquè la propera persona els pugui comparar.