Kvifor VPN-en din fell når Wi-Fi blir bytt eller Ethernet blir plugga inn

To ting blir rapporterte som éin feil: maskinen har flytta seg til eit anna Wi-Fi-nett, eller ein kabel vart sett i medan Wi-Fi framleis var oppe. Klienten seier framleis tilkopla, ikonet ser friskt ut, og tunnelen fraktar ingenting. Under overflata kan berre tre bitar tilstand flytta seg - sambandet, den lokale adressa, standardruta - og kva for ein som flytta seg avgjer om tunnelen kjem seg sjølv eller treng ny tilkopling. Eg sjekkar dei i den rekkjefølgja, fordi endra kontoinnstillingar aldri har retta nokon av dei.

Samband, adresse og rute flyttar seg uavhengig

Roaming mellom aksesspunkt på same nett er vanlegvis ein L2-hending. Radioen reassosierer, grensesnittet held på adressa og gatewayen, og ingenting tunnelen er avhengig av blir endra, og difor går ein tur gjennom eit stort kontor nokre gonger føre seg utan at nokon legg merke til det. Å kople til eit anna SSID er ikkje det: det gamle grensesnittet kan gå ned, DHCP deler ut ei ny adresse, ein ny gateway og nye resolverar, og den ytre straumen tunnelen brukte sluttar å eksistere.

Ethernet legg til ein tredje form. Wi-Fi fell aldri, så ingen sambandshending blir utløyst i det heile, men det kabelbundne grensesnittet dukkar opp med si eiga adresse og vinn ofte standardruta på metrikk. Tunnelen køyrer vidare over ein veg som ikkje lenger er føretrekt, eller klienten held socketen sin festa til det trådlause nettet han starta på. Frå nettlesaren ser begge like ut: sidene stoppar i det augneblunken kabelen klikkar.

Så det første spørsmålet er ikkje om Wi-Fi endra seg. Det er om adressa du er bunden til, eller ruta til endepunktet, endra seg medan tunnelen var oppe.

Den ytre socketen er festa til ei adresse som nettopp forsvann

Kvar tunnel er ein ytre straum: ei lokal adresse og port som snakkar med adressa og porten til serveren. På Linux er det ein UDP-socket bunden til den gamle kjelda; når grensesnittet som held adressa blir fjerna, feilar sendingar anten med EADDRNOTAVAIL eller går ut gjennom det nye grensesnittet med ei kjelde serveren aldri har sett.

Den fjerne sida held si eiga festing. Ein IKEv2-SA utan MOBIKE blir identifisert av adresseparet, og ein OpenVPN-sesjon er bunden til peer-adressa han lærde, og ein NAT-mapping høyrer til den private adressa, porten og den offentlege adressa som laga han. Flytt deg bak ein annan NAT, og kvart svar blir sendt til ein mapping som ikkje finst lenger. Ingenting på maskinen din er feil konfigurert; femtuppelen peikar på eit nett du forlét.

Les tilstanden før du teoretiserer:

• ss -unp viser den lokale adressa og porten som kvar tunnel-socket faktisk held.
• ip route get 203.0.113.10 skriv ut kjeldeadressa og eininga kjernen ville brukt for endepunktet akkurat no.
• wg show wg0 endpoints, swanctl --list-sas eller klientloggen viser peer-adressa den fjerne sida trur han snakkar med.

Viss socket-adressa og ruteoppslaget er usamde, har du funne brotet, og inga endring av påloggingsinformasjon vil røre det.

Kva kvar protokoll gjer med ei ny kjeldeadresse

Klientar tek opp endringa i ulik grad, og tabellen er det eg samanliknar med klientkonfigurasjonen i staden for å gjette ut frå gjenoppkoplingsåtferda.

Roaming-regelen til WireGuard verkar berre i éi retning: klienten må senda frå den nye adressa først. Ein socket som framleis er bunden til det gamle grensesnittet gjer det aldri, og difor kan ein tunnel sjå levande ut medan handtrykkstimeren eldast. protokollskildringa angir nøyaktig vilkåret for oppdatering av endepunktet, og ho er verdt å lese før du endrar ein konfigurasjon.

MOBIKE blir forhandla, det blir ikkje antatt. Viss serveren ikkje tilbyr det, må klienten gjenopprette, og det er eit faktum du stadfester frå SA-lista eller loggen i staden for å utleie det av eit roterande hjul.

Rutepreferansen avgjer vegen, ikkje Wi-Fi-ikonet

Med begge grensesnitta oppe vel kjernen etter metrikk og prefikslengd. ip route show default listar kandidatane, og ip route get 203.0.113.10 avgjer den reelle avgjerda, inkludert kjeldeadressa. Ei kabelbunde standardrute på metrikk 100 og ei trådlaus på 600 betyr at endepunktet flyttar seg i det augneblunken kabelen set seg, medan kvar applikasjon som opna ein socket tidlegare held på si gamle kjelde.

Windows gjer det same med automatiske grensesnittmetrikkar, påverka av lenkefarten. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sorterer kandidatane, og Find-NetRoute -RemoteIPAddress 203.0.113.10 returnerer grensesnittet og kjelda som stakken ville velje. Ein klient som bind sin ytre socket til eitt grensesnitt, brukar det vidare etter at metrikken snur; det er ei bindingsavgjerd, ikkje ein rutefeil.

Android gjer delinga synleg: ConnectivityManager rapporterer tilgjengelege nett og ein eigen standard, og ein VPN-app som bind ein socket til eit Network-objekt, held den bindinga til han bind på nytt. På macOS scutil --nwi skriv ut det primære grensesnittet og rekkjefølgja systemet ville bruke.

DNS, MTU og IPv6 flyttar seg med tilkoplinga

Ei ny tilkopling bringar nye resolverar. Med systemd-resolved er DNS per lenkje, resolvectl status viser kva lenkje som svarar på eit namn, og eit gjestenett som deler ut sin eigen resolver, kan la DNS-en tunnelen har dytta, stå ubrukt til lenkja blir føretrekt igjen. Ein captiv portal gjer det verre: den første HTTPS-førespurnaden blir svara av portalen i staden for endepunktet, og klienten registrerer ein daud server.

MTU-en til vegen endrar seg òg. Ethernet og Wi-Fi ber vanlegvis 1500 byte, PPPoE 1492, og mobile lenkjer ofte mindre. Ein tunnel som arvar ein mindre MTU, stoppar på store pakkar medan små førespurnader går gjennom, noko som blir lese som eit halvbroten samband. ping -M do -s 1472 203.0.113.10 sender ein pakke på 1500 byte med DF sett; stille betyr at vegen er mindre enn du antok.

IPv6 er den andre halvdelen. Eit nett som deler ut eit nytt prefiks, endrar kjelda ein dual-stack-klient ville bruke, og ein tunnel berre for v4 lèt v6-trafikk stå utanfor til politikken følgjer etter. ip -6 route show default og ip -6 addr show svarar på om den nye lenkja i det heile har ein v6-veg.

Gjenskap overgangen i staden for å skildre han

Vel éin uskuldig førespurnad og køyr dei same tre kommandoane på båe sider av endringa: ip -br addr, ip route show default, ip route get 203.0.113.10. Sjå deretter om tunnelen framleis sender pakkar - tcpdump -ni any udp port 51820 for WireGuard, den tilsvarande porten for alt anna. Pakkar som forlèt den gamle kjelda, betyr eit bindingsproblem. Pakkar frå den nye kjelda utan svar betyr den fjerne sida eller NAT-en undervegs.

Noter kva hending som fall saman med den første feilen: lenkje nede, adresseendring eller endring av standardruta. Dei peikar på ulike eigarar - ein klient som må bindast på nytt, ei adresse som må skaffast på nytt, eller ei rute som høyrer til ei konfigurasjonsfil og ikkje til ein permanent omkøyringsregel.

Før du kallar det retta, stadfest at blokka for direkte trafikk framleis held i holet og at namn blir løyste gjennom den nye tilkoplinga. Viss klienten held på det gamle endepunktet etter byttet, rett roaming- eller float-innstillinga først. Viss han roamar rett og framleis ikkje får svar, sjå på peer-identiteten til serveren og NAT-en på vegen, og hald på båe nettverkskontekstane i skrivinga slik at neste person kan samanlikne dei.