Zakaj vam VPN pade, ko se zamenja Wi-Fi ali priklopi Ethernet
'Nov SSID, gostovanje med dostopovnimi točkami in priklopljen kabel prekinejo tunel na treh različnih mestih. Preverite izvorni naslov, nato pot, nato protokol.'
Dve stvari se sporočata kot ena okvara: prenosnik se je preselil v drugo omrežje Wi-Fi ali pa je bil priklopljen kabel, medtem ko je Wi-Fi še deloval. Odjemalec še vedno pravi, da je povezan, ikona je videti zdrava, tunel pa ne prenaša ničesar. Pod površjem se lahko premaknejo le trije deli stanja - povezava, lokalni naslov, privzeta pot - in kateri se je premaknil, odloči, ali si bo tunel opomogel sam ali potrebuje ponovno povezavo. Preverjam jih v tem vrstnem redu, ker sprememba nastavitev računa še nikoli ni popravila nobenega od njih.
Povezava, naslov in pot se premikajo neodvisno
Gostovanje med dostopovnimi točkami v istem omrežju je običajno dogodek L2. Radio se znova pridruži, vmesnik obdrži naslov in prehod, in nič, od česar je odvisen tunel, se ne spremeni, zato sprehod po veliki pisarni včasih ostane neopažen. Pridružitev drugemu SSID ni to: stari vmesnik lahko pade, DHCP dodeli nov naslov, nov prehod in nove razreševalnike, zunanji tok, ki ga je tunel uporabljal, pa preneha obstajati.
Ethernet doda tretjo obliko. Wi-Fi nikoli ne pade, zato se dogodek povezave sploh ne sproži, a žični vmesnik se pojavi z lastnim naslovom in pogosto zmaga privzeto pot po metriki. Tunel teče naprej po poti, ki ni več prednostna, ali odjemalec drži svojo vtičnico pripeto na brezžično omrežje, v katerem je začel. Iz brskalnika sta oba videti enako: strani se ustavijo v trenutku, ko se kabel zaskoči.
Prvo vprašanje torej ni, ali se je Wi-Fi spremenil. Je, ali se je naslov, na katerega ste vezani, ali pot do končne točke spremenila, medtem ko je tunel deloval.
Zunanja vtičnica je pripeta na naslov, ki je pravkar izginil
Vsak tunel je zunanji tok: lokalni naslov in vrata se pogovarjata z naslovom in vrati strežnika. V Linuxu je to vtičnica UDP, vezana na stari vir; ko je vmesnik, ki drži naslov, odstranjen, pošiljanja bodisi spodletijo z EADDRNOTAVAIL bodisi gredo skozi novi vmesnik z virom, ki ga strežnik še ni videl.
Nasprotna stran drži svojo pripetost. SA IKEv2 brez MOBIKE se prepozna po paru naslovov, in OpenVPN seja je vezana na naslov partnerja, ki se ga je naučila, preslikava NAT pa pripada zasebnemu naslovu, vratom in javnemu naslovu, ki so jo ustvarili. Premaknite se za drug NAT in vsak odgovor gre na preslikavo, ki ne obstaja več. Na vašem stroju ni nič napačno nastavljeno; peterka kaže na omrežje, ki ste ga zapustili.
Preberite stanje, preden začnete teoretizirati:
ss -unpprikaže lokalni naslov in vrata, ki jih vsaka vtičnica tunela zares drži.ip route get 203.0.113.10izpiše izvorni naslov in napravo, ki bi jo jedro zdaj uporabilo za končno točko.wg show wg0 endpoints,swanctl --list-sasali dnevnik odjemalca prikaže naslov partnerja, s katerim nasprotna stran misli, da govori.
Če se naslov vtičnice in iskanje poti ne ujemata, ste našli prekinitev, in nobena sprememba poverilnic se je ne bo dotaknila.
Kaj vsak protokol naredi z novim izvornim naslovom
Odjemalci spremembo vsrkajo v različni meri, tabela pa je tisto, s čimer primerjam konfiguracijo odjemalca, namesto da bi ugibal iz vedenja pri ponovnem povezovanju.
| 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. |
Pravilo gostovanja WireGuard deluje samo v eno smer: odjemalec mora najprej poslati z novega naslova. Vtičnica, ki je še vedno vezana na stari vmesnik, tega nikoli ne stori, zato je tunel lahko videti živ, medtem ko se njegov časovnik rokovanja stara. opis protokola natančno navaja pogoj za posodobitev končne točke, in vredno ga je prebrati pred spremembo konfiguracije.
MOBIKE se dogovarja, ne predpostavlja. Če ga strežnik ne ponudi, mora odjemalec znova vzpostaviti, in to je dejstvo, ki ga potrdite s seznama SA ali iz dnevnika, ne pa sklepate iz vrtljivega kolesca.
Pot odloča prednost poti, ne ikona Wi-Fi
Ko sta oba vmesnika dvignjena, jedro izbere po metriki in dolžini predpone. ip route show default navede kandidate in ip route get 203.0.113.10 razreši dejansko odločitev, vključno z izvornim naslovom. Žična privzeta pot z metriko 100 in brezžična s 600 pomenita, da se končna točka premakne v trenutku, ko se kabel usede, medtem ko vsaka aplikacija, ki je vtičnico odprla prej, obdrži svoj stari vir.
Windows naredi isto z samodejnimi metrikami vmesnikov, pristranskimi glede na hitrost povezave. Get-NetRoute -DestinationPrefix 0.0.0.0/0 razvrsti kandidate in Find-NetRoute -RemoteIPAddress 203.0.113.10 vrne vmesnik in vir, ki bi ju izbral sklad. Odjemalec, ki svojo zunanjo vtičnico veže na en vmesnik, ga uporablja naprej tudi po prevrnitvi metrike; to je odločitev o vezavi, ne napaka pri usmerjanju.
Android naredi delitev vidno: ConnectivityManager sporoča razpoložljiva omrežja in ločeno privzeto, aplikacija VPN, ki veže vtičnico na objekt Network, pa to vezavo drži, dokler je ne veže znova. V macOS scutil --nwi izpiše primarni vmesnik in vrstni red, ki bi ga sistem uporabil.
DNS, MTU in IPv6 se premikajo s priklopom
Nova povezava prinese nove razreševalnike. S systemd-resolved je DNS na povezavo, resolvectl status pokaže, katera povezava odgovori na ime, in gostujoče omrežje, ki razdeli svoj razreševalnik, lahko pusti DNS, ki ga je potisnil tunel, neuporabljen, dokler povezava spet ne postane prednostna. Ujemni portal poslabša stvar: na prvo zahtevo HTTPS odgovori portal namesto končne točke, in odjemalec zabeleži mrtev strežnik.
Tudi MTU poti se spremeni. Ethernet in Wi-Fi običajno prenašata 1500 bajtov, PPPoE 1492, mobilne povezave pa pogosto manj. Tunel, ki podeduje manjši MTU, se ustavi na velikih paketih, medtem ko majhne zahteve gredo skozi, kar se bere kot na pol pokvarjena povezava. ping -M do -s 1472 203.0.113.10 pošlje paket s 1500 bajti z nastavljenim DF; tišina pomeni, da je pot manjša, kot ste domnevali.
IPv6 je druga polovica. Omrežje, ki razdeli nov predpono, spremeni vir, ki bi ga uporabil odjemalec z dvojnim skladom, in tunel samo za v4 pusti promet v6 zunaj, dokler se politika ne uskladi. ip -6 route show default in ip -6 addr show odgovorita, ali ima nova povezava sploh pot v6.
Ponovno ustvarite prehod, namesto da bi ga opisovali
Izberite eno neškodljivo zahtevo in poženite iste tri ukaze na obeh straneh spremembe: ip -br addr, ip route show default, ip route get 203.0.113.10. Nato opazujte, ali tunel še oddaja pakete - tcpdump -ni any udp port 51820 za WireGuard, ustrezna vrata za vse drugo. Paketi, ki odhajajo iz starega vira, pomenijo težavo z vezavo. Paketi z novega vira brez odgovora pomenijo nasprotno stran ali NAT vmes.
Zabeležite, kateri dogodek se je ujemal s prvo okvaro: padec povezave, sprememba naslova ali sprememba privzete poti. Ti kažejo na različne odgovorne - odjemalca, ki ga je treba znova vezati, naslov, ki ga je treba znova pridobiti, ali pot, ki pripada konfiguracijski datoteki in ne trajnemu pravilu zaobida.
Preden to razglasite za popravljeno, potrdite, da blok neposrednega prometa med vrzeljo še drži in da se imena razrešujejo skozi novo povezavo. Če odjemalec po preklopu obdrži staro končno točko, najprej popravite nastavitev gostovanja ali float. Če pravilno gostuje in še vedno ne prejme odgovora, poglejte identiteto partnerja na strežniku in NAT na poti ter oba omrežna konteksta obdržite v zapisu, da jih bo naslednja oseba lahko primerjala.