Proč vám VPN spadne, když se změní Wi-Fi nebo se zapojí Ethernet
'Nové SSID, roaming mezi přístupovými body a zapojený kabel rozbíjí tunel na třech různých místech. Zkontrolujte zdrojovou adresu, pak trasu a pak protokol.'
Dvě věci se hlásí jako jedna závada: notebook přešel na jinou síť Wi-Fi, nebo se zapojil kabel, zatímco Wi-Fi zůstala běžet. Klient pořád tvrdí, že je připojený, ikona vypadá zdravě a tunelem nic neprochází. Pod povrchem se mohou posunout jen tři kusy stavu - spojení, lokální adresa, výchozí trasa - a to, který se posunul, rozhoduje, zda se tunel obnoví sám, nebo potřebuje nové připojení. Kontroluji je v tomto pořadí, protože změna nastavení účtu nikdy žádný z nich nespravila.
Spojení, adresa a trasa se posouvají nezávisle
Roaming mezi přístupovými body v téže síti je obvykle událost na L2. Rádio se znovu asociuje, rozhraní si ponechá adresu i bránu a nic, na čem tunel závisí, se nemění, a proto procházka velkou kanceláří někdy zůstane nepoznaná. Připojení k jinému SSID takové není: staré rozhraní může spadnout, DHCP přidělí novou adresu, novou bránu a nové resolvery a vnější tok, který tunel používal, přestane existovat.
Ethernet přidává třetí podobu. Wi-Fi nikdy nespadne, takže se nevyvolá žádná událost spojení, ale drátové rozhraní se objeví s vlastní adresou a často vyhraje výchozí trasu podle metriky. Tunel dál běží po cestě, která už není preferovaná, nebo klient drží svůj socket přikovaný k bezdrátové síti, na které začal. Z prohlížeče vypadají oba stejně: stránky se zaseknou v okamžiku, kdy kabel zaklapne.
První otázka tedy není, jestli se Wi-Fi změnila. Ale jestli se změnila adresa, na kterou jste vázáni, nebo trasa k cíli, zatímco tunel běžel.
Vnější socket je přikovaný k adrese, která právě zmizela
Každý tunel je vnější tok: lokální adresa a port, které mluví s adresou a portem serveru. Na Linuxu je to UDP socket vázaný na starý zdroj; když se rozhraní, které adresu drží, odebere, odeslání buď selžou s EADDRNOTAVAIL, nebo vyjdou novým rozhraním se zdrojem, který server nikdy neviděl.
Odvrácená strana si drží svou vlastní přikování. SA IKEv2 bez MOBIKE se identifikuje párem adres a OpenVPN relace je vázána na adresu protějšku, kterou se naučila, a mapování NAT patří privátní adrese, portu a veřejné adrese, které ho vytvořily. Přesuňte se za jiný NAT a každá odpověď se posílá na mapování, které už neexistuje. Nic na vašem stroji není špatně nastavené; pětice ukazuje na síť, kterou jste opustili.
Přečtěte stav dřív, než začnete teoretizovat:
ss -unpukazuje lokální adresu a port, které každý socket tunelu skutečně drží.ip route get 203.0.113.10vypíše zdrojovou adresu a zařízení, které by jádro právě teď použilo pro cíl.wg show wg0 endpoints,swanctl --list-sasnebo klientský log ukazuje adresu protějšku, se kterou si odvrácená strana myslí, že mluví.
Pokud se adresa socketu a hledání trasy rozcházejí, našli jste přerušení a žádná změna přihlašovacích údajů se ho nedotkne.
Co každý protokol dělá s novou zdrojovou adresou
Klienti změnu vstřebávají v různé míře a tabulka je to, s čím porovnávám konfiguraci klienta, místo abych hádal z chování při opětovném připojení.
| 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 jen jedním směrem: klient musí nejdřív odeslat z nové adresy. Socket stále vázaný ke starému rozhraní to nikdy neudělá, a proto může tunel vypadat živě, zatímco jeho časovač handshake stárne. popis protokolu přesně uvádí podmínku aktualizace cíle a stojí za přečtení, než změníte konfiguraci.
MOBIKE se vyjednává, nepředpokládá. Pokud ho server nenabídne, klient musí spojení obnovit, a to je fakt, který potvrdíte ze seznamu SA nebo z logu, ne který odvodíte z točícího se kolečka.
O cestě rozhoduje preference trasy, ne ikona Wi-Fi
Když jsou obě rozhraní nahoru, jádro vybírá podle metriky a délky prefixu. ip route show default vypíše kandidáty a ip route get 203.0.113.10 vyřeší skutečné rozhodnutí včetně zdrojové adresy. Drátová výchozí trasa s metrikou 100 a bezdrátová s 600 znamenají, že se cíl posune v okamžiku, kdy kabel dosedne, zatímco každá aplikace, která otevřela socket dřív, si drží svůj starý zdroj.
Windows dělá totéž s automatickými metrikami rozhraní, vychýlenými podle rychlosti spojení. Get-NetRoute -DestinationPrefix 0.0.0.0/0 seřadí kandidáty a Find-NetRoute -RemoteIPAddress 203.0.113.10 vrátí rozhraní a zdroj, které by zásobník vybral. Klient, který váže svůj vnější socket k jednomu rozhraní, ho používá dál i po překlopení metriky; to je rozhodnutí o vazbě, ne chyba směrování.
Android rozdělení zviditelňuje: ConnectivityManager hlásí dostupné sítě a samostatnou výchozí a aplikace VPN, která váže socket k objektu Network, drží tuto vazbu, dokud ji znovu neváže. Na macOS scutil --nwi vypíše primární rozhraní a pořadí, které by systém použil.
DNS, MTU a IPv6 se posouvají s připojením
Nové připojení přináší nové resolvery. Se systemd-resolved je DNS po spojení, resolvectl status ukazuje, které spojení odpovídá na jméno, a hostovská síť, která vydává vlastní resolver, může nechat DNS protlačené tunelem nevyužité, dokud se spojení znovu nestane preferovaným. Záchytný portál to zhoršuje: na první požadavek HTTPS odpovídá portál místo cíle a klient si zapíše mrtvý server.
MTU cesty se také mění. Ethernet a Wi-Fi obvykle nesou 1500 bajtů, PPPoE 1492 a mobilní spojení často méně. Tunel, který zdědí menší MTU, se zasekne na velkých paketech, zatímco malé požadavky procházejí, což se čte jako napůl rozbité spojení. ping -M do -s 1472 203.0.113.10 pošle paket o 1500 bajtech s nastaveným DF; ticho znamená, že cesta je menší, než jste předpokládali.
IPv6 je druhá polovina. Síť, která vydá nový prefix, mění zdroj, který by použil dual-stack klient, a tunel jen pro v4 nechává provoz v6 mimo sebe, dokud se politika nedohoní. ip -6 route show default a ip -6 addr show odpovídají, zda má nové spojení vůbec cestu v6.
Reprodukujte přechod, místo abyste ho popisovali
Vyberte jeden neškodný požadavek a spusťte stejné tři příkazy po obou stranách změny: ip -br addr, ip route show default, ip route get 203.0.113.10. Pak sledujte, zda tunel ještě vysílá pakety - tcpdump -ni any udp port 51820 pro WireGuard, odpovídající port pro cokoli jiného. Pakety odcházející ze starého zdroje znamenají problém s vazbou. Pakety z nového zdroje bez odpovědi znamenají odvrácenou stranu nebo NAT na cestě.
Poznamenejte si, která událost se kryla s první závadou: spadnutí spojení, změna adresy nebo změna výchozí trasy. Ty ukazují na různé vlastníky - klienta, který se musí znovu svázat, adresu, kterou je třeba znovu získat, nebo trasu, která patří konfiguračnímu souboru, a ne trvalému pravidlu obcházení.
Než to označíte za opravené, potvrďte, že blok přímého provozu během mezery stále drží a že se jména rozkládají přes nové připojení. Pokud klient po přepnutí drží starý cíl, opravte nejdřív nastavení roamingu nebo float. Pokud roamuje správně a stále nedostává odpověď, podívejte se na identitu protějšku na serveru a na NAT na cestě a ponechte oba síťové kontexty v zápisu, aby je příští člověk mohl porovnat.