Hvorfor din VPN falder, når Wi-Fi skifter, eller Ethernet sættes i

To ting rapporteres som én fejl: computeren er flyttet til et andet Wi-Fi-netværk, eller et kabel blev sat i, mens Wi-Fi blev ved med at køre. Klienten siger stadig forbundet, ikonet ser sundt ud, og tunnelen bærer intet. Under overfladen kan kun tre stykker tilstand flytte sig - forbindelsen, den lokale adresse, standardruten - og hvilket stykke der flyttede sig afgør, om tunnelen kommer sig selv, eller om den skal genoprettes. Jeg tjekker dem i den rækkefølge, fordi ændrede kontoindstillinger aldrig har rettet nogen af dem.

Forbindelse, adresse og rute flytter sig uafhængigt

Roaming mellem accesspunkter på samme netværk er normalt en L2-hændelse. Radioen reassocierer, interfacet beholder sin adresse og gateway, og intet, som tunnelen afhænger af, ændrer sig, og derfor går en tur gennem et stort kontor nogle gange ubemærket hen. At skifte til et andet SSID er ikke det: det gamle interface kan gå ned, DHCP uddeler en ny adresse, en ny gateway og nye resolvere, og den ydre strøm, som tunnelen brugte, holder op med at eksistere.

Ethernet tilføjer en tredje form. Wi-Fi falder aldrig, så der udløses slet ingen forbindelseshændelse, men det kablede interface dukker op med sin egen adresse og vinder ofte standardruten på metrik. Tunnelen kører videre ad en vej, der ikke længere er foretrukket, eller klienten holder sin socket fastgjort til det trådløse netværk, den startede på. Fra browseren ser begge ens ud: siderne går i stå i det øjeblik, kablet klikker.

Så det første spørgsmål er ikke, om Wi-Fi skiftede. Det er, om adressen, du er bundet til, eller ruten til slutpunktet, skiftede, mens tunnelen var oppe.

Den ydre socket er fastgjort til en adresse, der netop er forsvundet

Enhver tunnel er en ydre strøm: en lokal adresse og port, der taler med serverens adresse og port. På Linux er det en UDP-socket bundet til den gamle kilde; når interfacet, der holder adressen, fjernes, fejler afsendelser enten med EADDRNOTAVAIL eller forlader gennem det nye interface med en kilde, som serveren aldrig har set.

Den fjerne side holder sin egen fastgørelse. En IKEv2-SA uden MOBIKE identificeres af adresseparret, og en OpenVPN-session er bundet til den peer-adresse, den lærte, og en NAT-mapping tilhører den private adresse, port og offentlige adresse, der skabte den. Flyt dig bag en anden NAT, og hvert svar sendes til en mapping, der ikke findes længere. Intet på din maskine er forkert konfigureret; fem-tuple peger på et netværk, du har forladt.

Læs tilstanden, før du teoretiserer:

• ss -unp viser den lokale adresse og port, som hver tunnel-socket faktisk holder.
• ip route get 203.0.113.10 udskriver kildeadressen og den enhed, som kernen ville bruge til slutpunktet lige nu.
• wg show wg0 endpoints, swanctl --list-sas eller klientloggen viser den peer-adresse, som den fjerne side tror, den taler med.

Hvis socket-adressen og ruteopslaget er uenige, har du fundet bruddet, og ingen ændring af legitimationsoplysninger rører ved det.

Hvad hver protokol gør med en ny kildeadresse

Klienter optager ændringen i forskellig grad, og tabellen er det, jeg sammenligner med klientkonfigurationen i stedet for at gætte ud fra genopretningsadfærden.

WireGuards roaming-regel virker kun i én retning: klienten skal sende fra den nye adresse først. En socket, der stadig er bundet til det gamle interface, gør det aldrig, og derfor kan en tunnel se levende ud, mens dens håndtrykstimer ældes. protokolbeskrivelse angiver præcist betingelsen for opdatering af slutpunktet, og den er værd at læse, før du ændrer en konfiguration.

MOBIKE forhandles, det antages ikke. Hvis serveren ikke tilbyder det, skal klienten genetablere, og det er et faktum, du bekræfter ud fra SA-listen eller loggen i stedet for at udlede det af et roterende hjul.

Rutepræference afgør vejen, ikke Wi-Fi-ikonet

Med begge interfaces oppe vælger kernen efter metrik og præfikslængde. ip route show default lister kandidaterne, og ip route get 203.0.113.10 afgør den reelle beslutning, inklusive kildeadressen. En kablet standardrute på metrik 100 og en trådløs på 600 betyder, at slutpunktet flytter sig i det øjeblik, kablet sætter sig, mens hver applikation, der åbnede en socket tidligere, beholder sin gamle kilde.

Windows gør det samme med automatiske interface-metrikker, påvirket af linkhastigheden. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sorterer kandidaterne, og Find-NetRoute -RemoteIPAddress 203.0.113.10 returnerer det interface og den kilde, som stakken ville vælge. En klient, der binder sin ydre socket til ét interface, bruger det videre, efter metrikken vender; det er en bindingsbeslutning, ikke en rutningsfejl.

Android gør opdelingen synlig: ConnectivityManager rapporterer tilgængelige netværk og en separat standard, og en VPN-app, der binder en socket til et Network-objekt, holder den binding, indtil den binder igen. På macOS scutil --nwi udskriver det primære interface og den rækkefølge, systemet ville bruge.

DNS, MTU og IPv6 flytter med tilslutningen

En ny tilslutning bringer nye resolvere. Med systemd-resolved er DNS per forbindelse, resolvectl status viser, hvilken forbindelse der svarer på et navn, og et gæstenetværk, der uddeler sin egen resolver, kan efterlade den DNS, tunnelen har skubbet, ubrugt, indtil forbindelsen igen bliver foretrukket. En captive portal gør det værre: det første HTTPS-kald besvares af portalen i stedet for slutpunktet, og klienten registrerer en død server.

Stiens MTU ændrer sig også. Ethernet og Wi-Fi bærer normalt 1500 byte, PPPoE 1492, og mobile forbindelser ofte mindre. En tunnel, der arver en mindre MTU, går i stå på store pakker, mens små kald lykkes, hvilket læses som en halvt brudt forbindelse. ping -M do -s 1472 203.0.113.10 sender en pakke på 1500 byte med DF sat; tavshed betyder, at vejen er mindre, end du antog.

IPv6 er den anden halvdel. Et netværk, der uddeler et nyt præfiks, ændrer den kilde, en dual-stack-klient ville bruge, og en tunnel, der kun er v4, lader v6-trafik stå udenfor, indtil politikken følger med. ip -6 route show default og ip -6 addr show svarer på, om den nye forbindelse overhovedet har en v6-vej.

Genskab overgangen i stedet for at beskrive den

Vælg ét harmløst kald, og kør de samme tre kommandoer på begge sider af ændringen: ip -br addr, ip route show default, ip route get 203.0.113.10. Se derefter, om tunnelen stadig sender pakker - tcpdump -ni any udp port 51820 for WireGuard, den tilsvarende port for alt andet. Pakker, der forlader den gamle kilde, betyder et bindingsproblem. Pakker, der forlader den nye kilde uden svar, betyder den fjerne side eller NAT undervejs.

Bemærk, hvilken hændelse der faldt sammen med den første fejl: forbindelse nede, adresseændring eller ændring af standardruten. De peger på forskellige ejere - en klient, der skal bindes igen, en adresse, der skal erhverves igen, eller en rute, der hører til en konfigurationsfil og ikke til en permanent bypass-regel.

Før du kalder det rettet, skal du bekræfte, at blokken for direkte trafik stadig holder i hullet, og at navne opløses gennem den nye tilslutning. Hvis klienten holder det gamle slutpunkt efter skiftet, så ret roaming- eller float-indstillingen først. Hvis den roamer korrekt og stadig ikke får svar, så se på serverens peer-identitet og NAT på vejen, og behold begge netværkskontekster i skrivelsen, så den næste person kan sammenligne dem.