Hvorfor VPN-en din faller når Wi-Fi byttes eller Ethernet plugges inn

To ting rapporteres som én feil: maskinen har flyttet seg til et annet Wi-Fi-nett, eller en kabel ble satt i mens Wi-Fi fortsatt var oppe. Klienten sier fortsatt tilkoblet, ikonet ser friskt ut, og tunnelen frakter ingenting. Under overflaten kan bare tre biter tilstand flytte seg - forbindelsen, den lokale adressen, standardruten - og hvilken som flyttet seg avgjør om tunnelen kommer seg selv eller trenger ny tilkobling. Jeg sjekker dem i den rekkefølgen, fordi endrede kontoinnstillinger aldri har fikset noen av dem.

Forbindelse, adresse og rute flytter seg uavhengig

Roaming mellom aksesspunkter på samme nett er vanligvis en L2-hendelse. Radioen reassosierer, grensesnittet beholder adressen og gatewayen, og ingenting tunnelen avhenger av endres, og derfor går en tur gjennom et stort kontor noen ganger ubemerket hen. Å koble til et annet SSID er ikke det: det gamle grensesnittet kan gå ned, DHCP deler ut en ny adresse, en ny gateway og nye resolvere, og den ytre strømmen tunnelen brukte slutter å eksistere.

Ethernet legger til en tredje form. Wi-Fi faller aldri, så ingen forbindelseshendelse utløses i det hele tatt, men det kablede grensesnittet dukker opp med sin egen adresse og vinner ofte standardruten på metrikk. Tunnelen kjører videre over en vei som ikke lenger er foretrukket, eller klienten holder socketen sin festet til det trådløse nettet den startet på. Fra nettleseren ser begge like ut: sidene stopper i det øyeblikket kabelen klikker.

Så det første spørsmålet er ikke om Wi-Fi endret seg. Det er om adressen du er bundet til, eller ruten til endepunktet, endret seg mens tunnelen var oppe.

Den ytre socketen er festet til en adresse som nettopp forsvant

Hver tunnel er en ytre strøm: en lokal adresse og port som snakker med serverens adresse og port. På Linux er det en UDP-socket bundet til den gamle kilden; når grensesnittet som holder adressen fjernes, feiler sendinger enten med EADDRNOTAVAIL eller går ut gjennom det nye grensesnittet med en kilde serveren aldri har sett.

Den fjerne siden holder sin egen festing. En IKEv2-SA uten MOBIKE identifiseres av adresseparet, og en OpenVPN-sesjon er bundet til peer-adressen den lærte, og en NAT-mapping tilhører den private adressen, porten og den offentlige adressen som laget den. Flytt deg bak en annen NAT, og hvert svar sendes til en mapping som ikke finnes lenger. Ingenting på maskinen din er feil konfigurert; femtuppelen peker på et nett du forlot.

Les tilstanden før du teoretiserer:

• ss -unp viser den lokale adressen og porten som hver tunnel-socket faktisk holder.
• ip route get 203.0.113.10 skriver ut kildeadressen og enheten kjernen ville brukt for endepunktet akkurat nå.
• wg show wg0 endpoints, swanctl --list-sas eller klientloggen viser peer-adressen den fjerne siden tror den snakker med.

Hvis socket-adressen og ruteoppslaget er uenige, har du funnet bruddet, og ingen endring av påloggingsinformasjon vil røre det.

Hva hver protokoll gjør med en ny kildeadresse

Klienter tar opp endringen i ulik grad, og tabellen er det jeg sammenligner med klientkonfigurasjonen i stedet for å gjette ut fra gjenoppkoblingsatferden.

WireGuards roaming-regel virker bare i én retning: klienten må sende fra den nye adressen først. En socket som fortsatt er bundet til det gamle grensesnittet gjør det aldri, og derfor kan en tunnel se levende ut mens håndtrykkstimeren eldes. protokollbeskrivelsen angir nøyaktig betingelsen for oppdatering av endepunktet, og den er verdt å lese før du endrer en konfigurasjon.

MOBIKE forhandles, det antas ikke. Hvis serveren ikke tilbyr det, må klienten gjenopprette, og det er et faktum du bekrefter fra SA-listen eller loggen i stedet for å utlede det av et roterende hjul.

Rutepreferansen avgjør veien, ikke Wi-Fi-ikonet

Med begge grensesnittene oppe velger kjernen etter metrikk og prefikslengde. ip route show default lister kandidatene, og ip route get 203.0.113.10 avgjør den reelle beslutningen, inkludert kildeadressen. En kablet standardrute på metrikk 100 og en trådløs på 600 betyr at endepunktet flytter seg i det øyeblikket kabelen setter seg, mens hver applikasjon som åpnet en socket tidligere beholder sin gamle kilde.

Windows gjør det samme med automatiske grensesnittmetrikker, påvirket av lenkehastigheten. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sorterer kandidatene, og Find-NetRoute -RemoteIPAddress 203.0.113.10 returnerer grensesnittet og kilden som stakken ville velge. En klient som binder sin ytre socket til ett grensesnitt, bruker det videre etter at metrikken snur; det er en bindingsbeslutning, ikke en rutingsfeil.

Android gjør delingen synlig: ConnectivityManager rapporterer tilgjengelige nett og en egen standard, og en VPN-app som binder en socket til et Network-objekt, holder den bindingen til den binder på nytt. På macOS scutil --nwi skriver ut det primære grensesnittet og rekkefølgen systemet ville bruke.

DNS, MTU og IPv6 flytter seg med tilkoblingen

En ny tilkobling bringer nye resolvere. Med systemd-resolved er DNS per lenke, resolvectl status viser hvilken lenke som svarer på et navn, og et gjestenett som deler ut sin egen resolver, kan la DNS-en tunnelen har dyttet, stå ubrukt til lenken blir foretrukket igjen. En captiv portal gjør det verre: den første HTTPS-forespørselen besvares av portalen i stedet for endepunktet, og klienten registrerer en død server.

Stiens MTU endres også. Ethernet og Wi-Fi bærer vanligvis 1500 byte, PPPoE 1492, og mobile lenker ofte mindre. En tunnel som arver en mindre MTU, stopper på store pakker mens små forespørsler går gjennom, noe som leses som en halvbrutt forbindelse. ping -M do -s 1472 203.0.113.10 sender en pakke på 1500 byte med DF satt; stillhet betyr at veien er mindre enn du antok.

IPv6 er den andre halvdelen. Et nett som deler ut et nytt prefiks, endrer kilden en dual-stack-klient ville bruke, og en tunnel bare for v4 lar v6-trafikk stå utenfor til policyen følger etter. ip -6 route show default og ip -6 addr show svarer på om den nye lenken i det hele tatt har en v6-vei.

Gjenskap overgangen i stedet for å beskrive den

Velg én uskyldig forespørsel og kjør de samme tre kommandoene på begge sider av endringen: ip -br addr, ip route show default, ip route get 203.0.113.10. Se deretter om tunnelen fortsatt sender pakker - tcpdump -ni any udp port 51820 for WireGuard, den tilsvarende porten for alt annet. Pakker som forlater den gamle kilden, betyr et bindingsproblem. Pakker fra den nye kilden uten svar betyr den fjerne siden eller NAT-en underveis.

Noter hvilken hendelse som falt sammen med den første feilen: lenke nede, adresseendring eller endring av standardruten. De peker på forskjellige eiere - en klient som må bindes på nytt, en adresse som må skaffes på nytt, eller en rute som hører til en konfigurasjonsfil og ikke til en permanent omkjøringsregel.

Før du kaller det fikset, bekreft at blokken for direkte trafikk fortsatt holder i hullet og at navn løses gjennom den nye tilkoblingen. Hvis klienten beholder det gamle endepunktet etter byttet, fiks roaming- eller float-innstillingen først. Hvis den roamer riktig og fortsatt ikke får svar, se på serverens peer-identitet og NAT-en på veien, og behold begge nettverkskontekstene i skrivingen slik at neste person kan sammenligne dem.