Zašto vam VPN padne kad se promijeni Wi-Fi ili uključi Ethernet
'Novi SSID, preromanje između pristupnih točaka i uključen kabel prekidaju tunel na tri različita mjesta. Provjerite izvornu adresu, pa rutu, pa protokol.'
Dvije stvari se prijavljuju kao jedan kvar: laptop je prešao na drugu Wi-Fi mrežu ili je kabel uključen dok je Wi-Fi ostao aktivan. Klijent i dalje kaže da je povezan, ikona izgleda zdravo, a tunel ne prenosi ništa. Ispod toga mogu se pomjeriti samo tri dijela stanja - veza, lokalna adresa, zadata ruta - i to koji se pomjerio odlučuje hoće li se tunel sam oporaviti ili mu treba ponovno povezivanje. Provjeravam ih tim redom, jer promjena postavki računa nikad nije popravila nijednu od njih.
Veza, adresa i ruta pomjeraju se neovisno
Preromanje između pristupnih točaka na istoj mreži obično je događaj na L2. Radio se ponovno asocira, sučelje zadržava svoju adresu i gateway, i ništa o čemu tunel ovisi se ne mijenja, zato šetnja kroz veliki ured ponekad prođe neprimijećeno. Pridruživanje drugom SSID-u nije to: staro sučelje može pasti, DHCP daje novu adresu, novi gateway i nove resolvere, a vanjski tok koji je tunel koristio prestaje postojati.
Ethernet dodaje treći oblik. Wi-Fi nikad ne pada, pa se ne dogodi nikakav događaj veze, ali žičano sučelje pojavljuje se s vlastitom adresom i često osvaja zadanu rutu po metrici. Tunel nastavlja raditi putem koji više nije preferiran, ili klijent drži svoj socket prikvačen za bežičnu mrežu na kojoj je počeo. Iz browsera oboje izgleda isto: stranice se zakoče u trenutku kad kabel sjedne.
Dakle prvo pitanje nije je li se Wi-Fi promijenio. Nego je li se adresa na koju ste vezani, ili ruta do odredišta, promijenila dok je tunel bio aktivan.
Vanjski socket prikvačen je za adresu koja je upravo nestala
Svaki tunel je vanjski tok: lokalna adresa i port koji razgovaraju s adresom i portom servera. Na Linuxu je to UDP socket vezan za stari izvor; kad se sučelje koje drži adresu ukloni, slanja ili padaju s EADDRNOTAVAIL ili izlaze kroz novo sučelje s izvorom koji server nikad nije vidio.
Druga strana čuva svoju kopču. SA IKEv2 bez MOBIKE-a identificira se parom adresa, a OpenVPN sesija je vezana za peer adresu koju je naučila, a NAT mapping pripada privatnoj adresi, portu i javnoj adresi koje su ga stvorile. Pomaknite se iza drugog NAT-a i svaki odgovor ide na mapping koji više ne postoji. Ništa na vašem stroju nije pogrešno konfigurirano; petorka pokazuje na mrežu koju ste napustili.
Pročitajte stanje prije teoretiziranja:
ss -unppokazuje lokalnu adresu i port koje svaki socket tunela stvarno drži.ip route get 203.0.113.10ispisuje izvornu adresu i uređaj koje bi kernel sada upotrijebio za odredište.wg show wg0 endpoints,swanctl --list-sasili klijentski log pokazuje peer adresu s kojom druga strana misli da razgovara.
Ako se adresa socketa i pretraga rute ne slažu, pronašli ste prekid i nikakva promjena vjerodajnica ga neće dotaknuti.
Što svaki protokol radi s novom izvornom adresom
Klijenti upijaju promjenu u različitoj mjeri, a tablica je ono s čime uspoređujem konfiguraciju klijenta umjesto da nagađam iz ponašanja ponovnog povezivanja.
| 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. |
WireGuardovo pravilo preromanja radi samo u jednom smjeru: klijent mora prvo poslati s nove adrese. Socket još vezan za staro sučelje to nikad ne čini, zato tunel može izgledati živ dok mu mjerač rukovanja stari. opis protokola precizno navodi uvjet ažuriranja odredišta i vrijedi ga pročitati prije promjene konfiguracije.
MOBIKE se pregovara, ne pretpostavlja. Ako ga server ne nudi, klijent mora ponovno uspostaviti vezu, a to je činjenica koju potvrđujete iz popisa SA ili loga, a ne zaključujete iz vrtećeg kotačića.
Prednost rute odlučuje put, ne ikona Wi-Fi
Kad su oba sučelja podignuta, kernel bira po metrici i duljini prefiksa. ip route show default navodi kandidate, a ip route get 203.0.113.10 rješava stvarnu odluku, uključujući izvornu adresu. Žičana zadana ruta s metrikom 100 i bežična sa 600 znače da se odredište pomiče u trenutku kad kabel sjedne, dok svaka aplikacija koja je ranije otvorila socket čuva svoj stari izvor.
Windows radi isto s automatskim metrikama sučelja, pristranim prema brzini veze. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sortira kandidate, a Find-NetRoute -RemoteIPAddress 203.0.113.10 vraća sučelje i izvor koje bi stog odabrao. Klijent koji veže svoj vanjski socket za jedno sučelje nastavlja ga koristiti i nakon što se metrika preokrene; to je odluka o vezanju, ne greška usmjeravanja.
Android čini podjelu vidljivom: ConnectivityManager prijavljuje dostupne mreže i zasebnu zadanu, a VPN aplikacija koja veže socket za objekt Network drži to vezanje dok ga ponovno ne veže. Na macOS-u, scutil --nwi ispisuje primarno sučelje i redoslijed koji bi sustav upotrijebio.
DNS, MTU i IPv6 pomiču se s priključkom
Novi priključak donosi nove resolvere. Uz systemd-resolved DNS je po vezi, resolvectl status pokazuje koja veza odgovara na ime, a gostujuća mreža koja daje vlastiti resolver može ostaviti DNS koji je tunel gurnuo neiskorištenim dok veza ponovno ne postane preferirana. Captive portal pogoršava stvar: na prvi HTTPS zahtjev odgovara portal, a ne odredište, i klijent bilježi mrtav server.
MTU puta se također mijenja. Ethernet i Wi-Fi obično nose 1500 bajtova, PPPoE 1492, a mobilne veze često manje. Tunel koji naslijedi manji MTU zapne na velikim paketima dok mali zahtjevi prolaze, što se čita kao napola pokvarena veza. ping -M do -s 1472 203.0.113.10 šalje paket od 1500 bajtova s postavljenim DF-om; tišina znači da je put manji nego što ste pretpostavili.
IPv6 je druga polovica. Mreža koja daje novi prefiks mijenja izvor koji bi dual-stack klijent upotrijebio, a tunel samo za v4 ostavlja v6 promet izvan sebe dok politika ne sustigne. ip -6 route show default i ip -6 addr show odgovaraju ima li nova veza uopće v6 put.
Reproducirajte prijelaz umjesto da ga opisujete
Odaberite jedan bezopasan zahtjev i pokrenite iste tri naredbe s obje strane promjene: ip -br addr, ip route show default, ip route get 203.0.113.10. Zatim gledajte emitira li tunel još pakete - tcpdump -ni any udp port 51820 za WireGuard, odgovarajući port za sve ostalo. Paketi koji izlaze sa starog izvora znače problem s vezanjem. Paketi s novog izvora bez odgovora znače drugu stranu ili NAT na putu.
Zabilježite koji se događaj poklopio s prvim kvarom: pad veze, promjena adrese ili promjena zadane rute. Oni pokazuju na različite vlasnike - klijenta koji se mora ponovno vezati, adresu koja se mora ponovno dobiti ili rutu koja pripada konfiguracijskoj datoteci, a ne trajnom pravilu zaobilaženja.
Prije nego to nazovete popravljenim, potvrdite da blok za izravni promet još drži tijekom prekida i da se imena razrješuju kroz novi priključak. Ako klijent nakon prebacivanja drži staro odredište, prvo popravite postavku preromanja ili float. Ako se ispravno preroma i još ne dobiva odgovor, pogledajte identitet peera na serveru i NAT na putu, i zadržite oba mrežna konteksta u zapisu da ih sljedeća osoba može usporediti.