Miks sinu VPN katkeb, kui Wi-Fi muutub või Ethernet sisestatakse
'Uus SSID, rändlus juurdepääsupunktide vahel ja sisestatud kaabel katkestavad tunnelit kolmes eri kohas. Kontrolli lähteaadressi, siis marsruuti ja siis protokolli.'
Kahte asja raporteeritakse ühe rikkena: sülearvuti liikus teise Wi-Fi-võrku või pisteti kaabel sisse, samal ajal kui Wi-Fi jäi tööle. Klient ütleb endiselt ühendatud, ikoon näeb terve välja ja tunnel ei kanna midagi. Pinna all saab liikuda ainult kolm olekuriba - ühendus, kohalik aadress, vaikimisi marsruut - ja see, milline liikus, otsustab, kas tunnel taastub ise või vajab uuesti ühendamist. Kontrollin neid selles järjekorras, sest konto seadete muutmine pole kunagi ühtegi neist parandanud.
Ühendus, aadress ja marsruut liiguvad iseseisvalt
Rändlus sama võrgu juurdepääsupunktide vahel on tavaliselt L2-sündmus. Raadio seostub uuesti, liides säilitab oma aadressi ja lüüsi ning miski, millest tunnel sõltub, ei muutu, mistõttu suures kontoris ringi kõndimine jääb mõnikord märkamata. Teise SSID-ga liitumine pole see: vana liides võib maha minna, DHCP annab uue aadressi, uue lüüsi ja uued resolverid ning välisvoog, mida tunnel kasutas, lakkab olemast.
Ethernet lisab kolmanda kuju. Wi-Fi ei katke kunagi, seega ühtki ühendussündmust ei sünni, kuid juhtmega liides ilmub oma aadressiga ja võidab sageli meetrika järgi vaikimisi marsruudi. Tunnel jätkab tööd teel, mis pole enam eelistatud, või hoiab klient oma socketit kinni traadita võrgus, kus alustas. Brauserist näevad mõlemad ühesugused välja: lehed takerduvad hetkel, kui kaabel klõpsatab.
Nii et esimene küsimus pole, kas Wi-Fi muutus. See on, kas aadress, millega oled seotud, või marsruut lõpp-punktini muutus tunnelitöö ajal.
Väline socket on kinnitatud aadressi külge, mis just kadus
Iga tunnel on väline voog: kohalik aadress ja port, mis räägivad serveri aadressi ja pordiga. Linuxis on see UDP-socket, mis on seotud vana lähtega; kui aadressi hoidnud liides eemaldatakse, siis saatmised kas ebaõnnestuvad EADDRNOTAVAIL-iga või väljuvad uue liidese kaudu lähtega, mida server pole kunagi näinud.
Kaugpool hoiab oma kinnitust. IKEv2 SA ilma MOBIKE-ta tuvastatakse aadressipaari järgi ja OpenVPN sessioon on seotud partneri aadressiga, mille see õppis, ja NAT-vastendus kuulub selle loonud privaatsele aadressile, pordile ja avalikule aadressile. Liigu teise NAT-i taha ja iga vastus saadetakse vastendusele, mida enam pole. Sinu masinas pole miski valesti seadistatud; viisik osutab võrgule, mille jätsid.
Loe olekut enne teoretiseerimist:
ss -unpnäitab kohalikku aadressi ja porti, mida iga tunnelisocket tegelikult hoiab.ip route get 203.0.113.10prindib lähteaadressi ja seadme, mida kernel praegu lõpp-punkti jaoks kasutaks.wg show wg0 endpoints,swanctl --list-sasvõi kliendi logi näitab partneri aadressi, millega kaugpool arvab rääkivat.
Kui socketi aadress ja marsruudiotsing ei klapi, oled katkestuse leidnud ja ükski mandaadi muudatus ei puuduta seda.
Mida iga protokoll uue lähteaadressiga teeb
Kliendid võtavad muutust vastu erineval määral ja tabel on see, millega ma klientrakenduse seadistust võrdlen, selle asemel et uuestiühendumise käitumisest oletada.
| 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. |
WireGuardi rändlusreegel töötab ainult ühes suunas: klient peab saatma kõigepealt uuelt aadressilt. Vana liidesega seotud socket ei tee seda kunagi, mistõttu tunnel võib tunduda elus, samal ajal kui selle kätlusetaimer vananeb. protokolli kirjeldus täpsustab lõpp-punkti värskendamise tingimust ja seda tasub lugeda enne seadistuse muutmist.
MOBIKE-d läbiräägitakse, seda ei eeldata. Kui server ei paku seda, peab klient uuesti üles seadma, ja see on fakt, mida kinnitad SA-loendist või logist, mitte järeldad pöörlevast rattast.
Marsruudi eelistus otsustab tee, mitte Wi-Fi ikoon
Kui mõlemad liidesed on üleval, valib kernel meetrika ja eesliite pikkuse järgi. ip route show default loetleb kandidaadid ja ip route get 203.0.113.10 lahendab tegeliku otsuse, sealhulgas lähteaadressi. Juhtmega vaikimisi marsruut meetrikaga 100 ja traadita oma 600 tähendavad, et lõpp-punkt liigub hetkel, kui kaabel kinnitub, samal ajal kui iga rakendus, mis avas socketi varem, hoiab oma vana lähte.
Windows teeb sama automaatsete liidese meetrikatega, mida kallutab lingi kiirus. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sorteerib kandidaadid ja Find-NetRoute -RemoteIPAddress 203.0.113.10 tagastab liidese ja lähte, mille virn valiks. Klient, kes seob oma välise socketi ühe liidesega, jätkab selle kasutamist ka pärast meetrika pöördumist; see on sidumisotsus, mitte marsruutimisviga.
Android teeb jaotuse nähtavaks: ConnectivityManager teatab saadaolevad võrgud ja eraldi vaikimisi ning VPN-rakendus, mis seob socketi Network-objektiga, hoiab seda sidet, kuni seob uuesti. macOS-is scutil --nwi prindib primaarse liidese ja järjekorra, mida süsteem kasutaks.
DNS, MTU ja IPv6 liiguvad koos ühendusega
Uus ühendus toob uued resolverid. systemd-resolvediga on DNS lingipõhine, resolvectl status näitab, milline link vastab nimele, ja külalisvõrk, mis jagab oma resolverit, võib jätta tunneli lükatud DNS-i kasutamata, kuni link taas eelistatuks saab. Kinnipüüdev portaal teeb asja hullemaks: esimesele HTTPS-päringule vastab portaal, mitte lõpp-punkt, ja klient märgib surnud serveri.
Ka tee MTU muutub. Ethernet ja Wi-Fi kannavad tavaliselt 1500 baiti, PPPoE 1492 ja mobiililingid sageli vähem. Tunnel, mis pärb väiksema MTU, takerdub suurte pakettide juures, samal ajal kui väikesed päringud õnnestuvad, mis loetakse pooleldi katkise ühendusena. ping -M do -s 1472 203.0.113.10 saadab 1500-baidise paketi DF-iga; vaikus tähendab, et tee on väiksem, kui eeldasid.
IPv6 on teine pool. Võrk, mis jagab uue eesliite, muudab lähte, mida kahekihiline klient kasutaks, ja ainult v4 tunnel jätab v6-liikluse väljapoole, kuni poliitika järele jõuab. ip -6 route show default ja ip -6 addr show vastavad, kas uuel lingil on üldse v6-tee.
Taasta üleminek, selle asemel et seda kirjeldada
Vali üks kahjutu päring ja käivita samad kolm käsku muudatuse mõlemal pool: ip -br addr, ip route show default, ip route get 203.0.113.10. Seejärel jälgi, kas tunnel saadab endiselt pakette - tcpdump -ni any udp port 51820 WireGuardi jaoks, mis tahes muu jaoks vastav port. Vanast lähtest väljuvad paketid tähendavad sidumisprobleemi. Uuest lähtest väljuvad vastuseta paketid tähendavad kaugpoolt või vahepealset NAT-i.
Pane kirja, milline sündmus langes kokku esimese rikkega: lingi kadumine, aadressi muutus või vaikimisi marsruudi muutus. Need osutavad eri omanikele - klient, mis tuleb uuesti siduda, aadress, mis tuleb uuesti hankida, või marsruut, mis kuulub seadistusfailile, mitte püsivale möödasõidureeglile.
Enne kui nimetad selle parandatuks, kinnita, et otseliikluse blokk püsib vahe ajal ja et nimed lahenevad uue ühenduse kaudu. Kui klient hoiab pärast lülitust vana lõpp-punkti, paranda kõigepealt rändlus- või float-seade. Kui see rändleb õigesti ja vastust ikka ei tule, vaata serveri partneri identiteeti ja teel olevat NAT-i ning hoia mõlemad võrgukontekstid kirjas, et järgmine inimene saaks neid võrrelda.