Prečo vám VPN padne, keď sa zmení Wi-Fi alebo zapojí Ethernet
'Nové SSID, roaming medzi prístupovými bodmi a zapojený kábel lámu tunel na troch rôznych miestach. Skontrolujte zdrojovú adresu, potom trasu a potom protokol.'
Dve veci sa hlásia ako jedna porucha: notebook prešiel na inú Wi-Fi sieť alebo sa zapojil kábel, kým Wi-Fi ďalej bežala. Klient stále tvrdí, že je pripojený, ikona vyzerá zdravo a tunel nič neprenáša. Pod povrchom sa môžu posunúť len tri kusy stavu - spojenie, lokálna adresa, predvolená trasa - a to, ktorý sa posunul, rozhoduje, či sa tunel obnoví sám, alebo potrebuje nové pripojenie. Kontrolujem ich v tomto poradí, pretože zmena nastavení účtu nikdy nespravila ani jeden z nich.
Spojenie, adresa a trasa sa posúvajú nezávisle
Roaming medzi prístupovými bodmi v tej istej sieti je zvyčajne udalosť L2. Rádio sa znovu asociuje, rozhranie si ponechá adresu aj bránu a nič, na čom tunel závisí, sa nemení, preto prechádzka veľkou kanceláriou niekedy zostane nepovšimnutá. Pripojenie k inému SSID také nie je: staré rozhranie môže padnúť, DHCP pridelí novú adresu, novú bránu a nové resolvery a vonkajší tok, ktorý tunel používal, prestane existovať.
Ethernet pridáva tretiu podobu. Wi-Fi nikdy nepadne, takže sa nevyvolá žiadna udalosť spojenia, ale drôtové rozhranie sa objaví s vlastnou adresou a často vyhrá predvolenú trasu podľa metriky. Tunel ďalej beží po ceste, ktorá už nie je preferovaná, alebo klient drží svoj socket pripnutý k bezdrôtovej sieti, v ktorej začal. Z prehliadača vyzerajú oba rovnako: stránky sa zaseknú v okamihu, keď kábel zapadne.
Prvá otázka teda nie je, či sa Wi-Fi zmenila. Ale či sa zmenila adresa, na ktorú ste viazaní, alebo trasa k cieľu, kým tunel bežal.
Vonkajší socket je pripnutý k adrese, ktorá práve zmizla
Každý tunel je vonkajší tok: lokálna adresa a port, ktoré hovoria s adresou a portom servera. Na Linuxe je to UDP socket viazaný na starý zdroj; keď sa rozhranie, ktoré adresu drží, odoberie, odoslania buď zlyhajú s EADDRNOTAVAIL, alebo vyjdú novým rozhraním so zdrojom, ktorý server nikdy nevidel.
Opačná strana si drží svoje pripnutie. SA IKEv2 bez MOBIKE sa identifikuje párom adries a OpenVPN relácia je viazaná na adresu partnera, ktorú sa naučila, a mapovanie NAT patrí privátnej adrese, portu a verejnej adrese, ktoré ho vytvorili. Presuňte sa za iný NAT a každá odpoveď ide na mapovanie, ktoré už neexistuje. Na vašom stroji nie je nič zle nastavené; pätica ukazuje na sieť, ktorú ste opustili.
Prečítajte si stav skôr, než začnete teoretizovať:
ss -unpukazuje lokálnu adresu a port, ktoré každý socket tunela skutočne drží.ip route get 203.0.113.10vypíše zdrojovú adresu a zariadenie, ktoré by jadro práve teraz použilo pre cieľ.wg show wg0 endpoints,swanctl --list-sasalebo klientsky log ukazuje adresu partnera, s ktorou si opačná strana myslí, že hovorí.
Ak sa adresa socketu a hľadanie trasy rozchádzajú, našli ste prerušenie a žiadna zmena prihlasovacích údajov sa ho nedotkne.
Čo robí každý protokol s novou zdrojovou adresou
Klienti vstrebávajú zmenu v rôznej miere a tabuľka je to, s čím porovnávam konfiguráciu klienta, namiesto toho aby som hádal zo správania pri opätovnom pripájaní.
| 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. |
Pravidlo roamingu WireGuard funguje len jedným smerom: klient musí najprv odoslať z novej adresy. Socket stále viazaný na staré rozhranie to nikdy neurobí, a preto môže tunel vyzerať živý, kým jeho časovač handshake starne. popis protokolu presne uvádza podmienku aktualizácie cieľa a stojí za prečítanie pred zmenou konfigurácie.
MOBIKE sa vyjednáva, nepredpokladá sa. Ak ho server neponúka, klient musí obnoviť spojenie, a to je fakt, ktorý potvrdíte zo zoznamu SA alebo z logu, nie ktorý odvodíte z točiaceho sa kolieska.
O ceste rozhoduje preferencia trasy, nie ikona Wi-Fi
Keď sú obe rozhrania hore, jadro vyberá podľa metriky a dĺžky prefixu. ip route show default vypíše kandidátov a ip route get 203.0.113.10 vyrieši skutočné rozhodnutie vrátane zdrojovej adresy. Drôtová predvolená trasa s metrikou 100 a bezdrôtová so 600 znamenajú, že sa cieľ posunie v okamihu, keď kábel dosadne, kým každá aplikácia, ktorá otvorila socket skôr, si drží svoj starý zdroj.
Windows robí to isté s automatickými metrikami rozhraní, ovplyvnenými rýchlosťou spojenia. Get-NetRoute -DestinationPrefix 0.0.0.0/0 zoradí kandidátov a Find-NetRoute -RemoteIPAddress 203.0.113.10 vráti rozhranie a zdroj, ktoré by zásobník vybral. Klient, ktorý viaže svoj vonkajší socket k jednému rozhraniu, ho používa ďalej aj po prevrátení metriky; to je rozhodnutie o viazaní, nie chyba smerovania.
Android robí rozdelenie viditeľným: ConnectivityManager hlási dostupné siete a samostatnú predvolenú a aplikácia VPN, ktorá viaže socket k objektu Network, drží toto viazanie, kým ho znova neviaže. Na macOS scutil --nwi vypíše primárne rozhranie a poradie, ktoré by systém použil.
DNS, MTU a IPv6 sa posúvajú so pripojením
Nové pripojenie prináša nové resolvery. So systemd-resolved je DNS po spojení, resolvectl status ukazuje, ktoré spojenie odpovedá na meno, a hosťovská sieť, ktorá vydáva vlastný resolver, môže nechať DNS pretlačený tunelom nevyužitý, kým sa spojenie znova nestane preferovaným. Zachytávací portál to zhoršuje: na prvú požiadavku HTTPS odpovedá portál namiesto cieľa a klient si zapíše mŕtvy server.
MTU cesty sa tiež mení. Ethernet a Wi-Fi zvyčajne nesú 1500 bajtov, PPPoE 1492 a mobilné spojenia často menej. Tunel, ktorý zdedí menšie MTU, sa zasekne na veľkých paketoch, kým malé požiadavky prechádzajú, čo sa číta ako napoly pokazené spojenie. ping -M do -s 1472 203.0.113.10 pošle paket s 1500 bajtmi s nastaveným DF; ticho znamená, že cesta je menšia, než ste predpokladali.
IPv6 je druhá polovica. Sieť, ktorá vydá nový prefix, mení zdroj, ktorý by použil klient s dvoma zásobníkmi, a tunel len pre v4 necháva prevádzku v6 mimo seba, kým sa politika nedohoní. ip -6 route show default a ip -6 addr show odpovedajú, či má nové spojenie vôbec cestu v6.
Reprodukujte prechod, namiesto toho aby ste ho opisovali
Vyberte jednu neškodnú požiadavku a spustite tie isté tri príkazy na oboch stranách zmeny: ip -br addr, ip route show default, ip route get 203.0.113.10. Potom sledujte, či tunel ešte vysiela pakety - tcpdump -ni any udp port 51820 pre WireGuard, zodpovedajúci port pre všetko ostatné. Pakety odchádzajúce zo starého zdroja znamenajú problém s viazaním. Pakety z nového zdroja bez odpovede znamenajú opačnú stranu alebo NAT na ceste.
Poznamenajte si, ktorá udalosť sa zhodovala s prvou poruchou: spadnutie spojenia, zmena adresy alebo zmena predvolenej trasy. Ukazujú na rôznych zodpovedných - klienta, ktorého treba znova viazať, adresu, ktorú treba znova získať, alebo trasu, ktorá patrí konfiguračnému súboru a nie trvalému pravidlu obchádzania.
Skôr než to označíte za opravené, potvrďte, že blok priamej prevádzky počas medzery stále drží a že sa mená rozkladajú cez nové pripojenie. Ak klient po prepnutí drží starý cieľ, opravte najprv nastavenie roamingu alebo float. Ak roamuje správne a stále nedostáva odpoveď, pozrite sa na identitu partnera na serveri a na NAT na ceste, a ponechajte oba sieťové kontexty v zápise, aby ich ďalší človek mohol porovnať.