De ce îți cade VPN-ul când se schimbă Wi-Fi-ul sau se conectează Ethernet

Două lucruri sunt raportate ca o singură defecțiune: laptopul a trecut pe altă rețea Wi-Fi, sau a fost conectat un cablu în timp ce Wi-Fi-ul rămânea activ. Clientul spune în continuare conectat, pictograma arată sănătoasă, iar tunelul nu transportă nimic. Dedesubt, doar trei bucăți de stare se pot mișca - legătura, adresa locală, ruta implicită - și care s-a mișcat decide dacă tunelul se reface singur sau are nevoie de reconectare. Le verific în această ordine, pentru că modificarea setărilor contului nu a reparat niciodată vreuna.

Legătura, adresa și ruta se mișcă independent

Roamingul între punctele de acces ale aceleiași rețele este de obicei un eveniment L2. Radioul se reasociază, interfața își păstrează adresa și gateway-ul, și nimic din ce depinde tunelul nu se schimbă, motiv pentru care o plimbare printr-un birou mare trece uneori neobservată. Alăturarea la alt SSID nu este asta: interfața veche poate cădea, DHCP oferă o adresă nouă, un gateway nou și resolveri noi, iar fluxul exterior pe care îl folosea tunelul încetează să existe.

Ethernet adaugă o a treia formă. Wi-Fi-ul nu cade niciodată, deci nu se declanșează niciun eveniment de legătură, dar interfața cu cablu apare cu propria adresă și câștigă adesea ruta implicită pe metrică. Tunelul continuă pe un drum care nu mai este preferat, sau clientul își ține socketul fixat pe rețeaua fără fir pe care a început. Din browser ambele arată la fel: paginile se blochează în momentul în care cablul se cuplează.

Deci prima întrebare nu este dacă s-a schimbat Wi-Fi-ul. Este dacă adresa de care ești legat, sau ruta până la punctul final, s-a schimbat în timp ce tunelul era activ.

Socketul exterior este fixat de o adresă care tocmai a dispărut

Fiecare tunel este un flux exterior: o adresă și un port locale care vorbesc cu adresa și portul serverului. Pe Linux este un socket UDP legat de sursa veche; când interfața care ține adresa este eliminată, trimiterile fie eșuează cu EADDRNOTAVAIL, fie ies prin interfața nouă cu o sursă pe care serverul nu a văzut-o niciodată.

Partea îndepărtată își păstrează propria fixare. O SA IKEv2 fără MOBIKE este identificată prin perechea de adrese, iar o OpenVPN sesiune este legată de adresa peerului pe care a învățat-o, iar o mapare NAT aparține adresei private, portului și adresei publice care au creat-o. Mută-te în spatele altui NAT și fiecare răspuns merge către o mapare care nu mai există. Nimic de pe mașina ta nu este configurat greșit; cvintuplul indică o rețea pe care ai părăsit-o.

Citește starea înainte de a teoretiza:

• ss -unp arată adresa și portul locale pe care le ține într-adevăr fiecare socket de tunel.
• ip route get 203.0.113.10 afișează adresa sursă și dispozitivul pe care nucleul le-ar folosi acum pentru punctul final.
• wg show wg0 endpoints, swanctl --list-sas sau jurnalul clientului arată adresa peerului cu care partea îndepărtată crede că vorbește.

Dacă adresa socketului și căutarea rutei nu sunt de acord, ai găsit ruptura, și nicio schimbare de credențiale nu o va atinge.

Ce face fiecare protocol cu o adresă sursă nouă

Clienții absorb schimbarea în grade diferite, iar tabelul este ceea ce compar cu configurația clientului în loc să ghicesc din comportamentul de reconectare.

Regula de roaming a WireGuard funcționează doar într-o direcție: clientul trebuie să trimită mai întâi din adresa nouă. Un socket încă legat de interfața veche nu face niciodată asta, motiv pentru care un tunel poate părea viu în timp ce temporizatorul de handshake îmbătrânește. descrierea protocolului precizează condiția de actualizare a punctului final, și merită citită înainte de a schimba o configurație.

MOBIKE se negociază, nu se presupune. Dacă serverul nu îl oferă, clientul trebuie să restabilească, iar asta este un fapt pe care îl confirmi din lista SA sau din jurnal, nu pe care îl deduci dintr-o roată care se învârte.

Preferința de rută decide drumul, nu pictograma Wi-Fi

Când ambele interfețe sunt sus, nucleul alege după metrică și lungimea prefixului. ip route show default listează candidații, iar ip route get 203.0.113.10 rezolvă decizia reală, inclusiv adresa sursă. O rută implicită cu cablu la metrica 100 și una fără fir la 600 înseamnă că punctul final se mută în momentul în care cablul se așază, în timp ce fiecare aplicație care a deschis un socket mai devreme își păstrează sursa veche.

Windows face la fel cu metrici de interfață automate, influențate de viteza legăturii. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sortează candidații, iar Find-NetRoute -RemoteIPAddress 203.0.113.10 returnează interfața și sursa pe care le-ar alege stiva. Un client care își leagă socketul exterior de o interfață continuă să o folosească după ce metrica se răstoarnă; asta este o decizie de legare, nu o defecțiune de rutare.

Android face divizarea vizibilă: ConnectivityManager raportează rețelele disponibile și o implicită separată, iar o aplicație VPN care leagă un socket de un obiect Network păstrează acea legare până o reface. Pe macOS, scutil --nwi afișează interfața principală și ordinea pe care ar folosi-o sistemul.

DNS, MTU și IPv6 se mișcă împreună cu conectarea

O conectare nouă aduce resolveri noi. Cu systemd-resolved DNS este pe legătură, resolvectl status arată ce legătură răspunde la un nume, iar o rețea de oaspeți care distribuie propriul resolver poate lăsa DNS-ul împins de tunel nefolosit până când legătura devine din nou preferată. Un portal captiv înrăutățește situația: prima cerere HTTPS este răspunsă de portal în locul punctului final, iar clientul înregistrează un server mort.

Și MTU-ul drumului se schimbă. Ethernet și Wi-Fi transportă de obicei 1500 de octeți, PPPoE 1492, iar legăturile mobile adesea mai puțin. Un tunel care moștenește un MTU mai mic se blochează la pachete mari în timp ce cererile mici trec, ceea ce se citește ca o conexiune pe jumătate ruptă. ping -M do -s 1472 203.0.113.10 trimite un pachet de 1500 de octeți cu DF setat; liniștea înseamnă că drumul este mai mic decât ai presupus.

IPv6 este cealaltă jumătate. O rețea care distribuie un prefix nou schimbă sursa pe care ar folosi-o un client cu dublu stivă, iar un tunel doar v4 lasă traficul v6 în afara lui până când politica recuperează. ip -6 route show default și ip -6 addr show răspund dacă noua legătură are deloc un drum v6.

Reproduce tranziția în loc să o descrii

Alege o cerere inofensivă și rulează aceleași trei comenzi de ambele părți ale schimbării: ip -br addr, ip route show default, ip route get 203.0.113.10. Apoi observă dacă tunelul mai emite pachete - tcpdump -ni any udp port 51820 pentru WireGuard, portul corespunzător pentru orice altceva. Pachetele care pleacă din sursa veche înseamnă o problemă de legare. Pachetele din sursa nouă fără răspuns înseamnă partea îndepărtată sau NAT-ul dintre ele.

Notează ce eveniment a coincis cu prima defecțiune: căderea legăturii, schimbarea adresei sau schimbarea rutei implicite. Acestea indică responsabili diferiți - un client care trebuie legat din nou, o adresă care trebuie obținută din nou, sau o rută care aparține unui fișier de configurare și nu unei reguli permanente de ocolire.

Înainte să o declari reparată, confirmă că blocul de trafic direct încă rezistă în timpul întreruperii și că numele se rezolvă prin conectarea nouă. Dacă clientul păstrează punctul final vechi după comutare, repară mai întâi setarea de roaming sau float. Dacă face roaming corect și tot nu primește răspuns, uită-te la identitatea peerului pe server și la NAT-ul de pe drum, și păstrează ambele contexte de rețea în raport ca următoarea persoană să le poată compara.