Pse VPN-ja juaj bie kur Wi-Fi ndryshon ose lidhet Ethernet
'Një SSID i re, roaming midis pikave të aksesit dhe një kabllo e lidhur e thyejnë tunelin në tre vende të ndryshme. Kontrolloni adresën e burimit, pastaj rrugën, pastaj protokollin.'
Dy gjëra raportohen si një defekt i vetëm: laptopi kaloi në një rrjet tjetër Wi-Fi, ose u lidh një kabllo ndërsa Wi-Fi vazhdonte të punonte. Klienti vazhdon të thotë i lidhur, ikona duket e shëndetshme dhe tuneli nuk transporton asgjë. Poshtë sipërfaqes mund të lëvizin vetëm tre pjesë gjendjeje - lidhja, adresa lokale, rruga e paracaktuar - dhe cila lëvizi vendos nëse tuneli rikuperohet vetë ose kërkon rilidhje. I kontrolloj në atë rend, sepse ndryshimi i cilësimeve të llogarisë nuk ka rregulluar kurrë asnjë prej tyre.
Lidhja, adresa dhe rruga lëvizin në mënyrë të pavarur
Roaming-u midis pikave të aksesit të të njëjtit rrjet është zakonisht një ngjarje L2. Radioja rilidhet, ndërfaqja mban adresën dhe gateway-in, dhe asgjë nga e cila varet tuneli nuk ndryshon, prandaj një shëtitje nëpër një zyrë të madhe ndonjëherë kalon pa u vënë re. Lidhja me një SSID tjetër nuk është kjo: ndërfaqja e vjetër mund të bjerë, DHCP jep një adresë të re, një gateway të re dhe zgjidhës të re, dhe rrjedha e jashtme që përdorte tuneli nuk ekziston më.
Ethernet shton një formë të tretë. Wi-Fi nuk bie kurrë, kështu që nuk aktivizohet asnjë ngjarje lidhjeje, por ndërfaqja me kabllo shfaqet me adresën e vet dhe shpesh fiton rrugën e paracaktuar sipas metrikës. Tuneli vazhdon në një rrugë që nuk preferohet më, ose klienti e mban soketin të gozhduar në rrjetin pa tel ku filloi. Nga shfletuesi të dy duken njësoj: faqet ngecin në çastin kur kablloja futet.
Pra pyetja e parë nuk është nëse Wi-Fi ndryshoi. Është nëse adresa me të cilën jeni lidhur, ose rruga deri në pikën fundore, ndryshoi ndërsa tuneli ishte aktiv.
Soketi i jashtëm është gozhduar në një adresë që sapo u zhduk
Çdo tunel është një rrjedhë e jashtme: një adresë dhe port lokal që flasin me adresën dhe portin e serverit. Në Linux ky është një soket UDP i lidhur me burimin e vjetër; kur ndërfaqja që mban adresën hiqet, dërgimet ose dështojnë me EADDRNOTAVAIL ose dalin përmes ndërfaqes së re me një burim që serveri nuk e ka parë kurrë.
Ana e largët mban gozhdën e vet. Një SA IKEv2 pa MOBIKE identifikohet nga çifti i adresave, dhe një OpenVPN sesion lidhet me adresën e homologut që mësoi, dhe një hartëzim NAT i përket adresës private, portit dhe adresës publike që e krijuan. Kaloni pas një NAT tjetër dhe çdo përgjigje shkon në një hartëzim që nuk ekziston më. Asgjë në makinën tuaj nuk është konfiguruar gabimisht; pesëfishi tregon një rrjet që e keni lënë.
Lexoni gjendjen para se të teoretizoni:
ss -unptregon adresën dhe portin lokal që çdo soket tuneli mban vërtet.ip route get 203.0.113.10shtyp adresën e burimit dhe pajisjen që bërthama do të përdorte tani për pikën fundore.wg show wg0 endpoints,swanctl --list-sasose regjistri i klientit tregon adresën e homologut me të cilin ana e largët mendon se po flet.
Nëse adresa e soketit dhe kërkimi i rrugës nuk përputhen, keni gjetur thyerjen, dhe asnjë ndryshim kredenciale nuk do t’i prekë.
Çfarë bën çdo protokoll me një adresë të re burimi
Klientët e thithin ndryshimin në shkallë të ndryshme, dhe tabela është ajo me të cilën krahasoj konfigurimin e klientit në vend që të hamendësoj nga sjellja e rilidhjes.
| 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. |
Rregulli i roaming-ut të WireGuard funksionon vetëm në një drejtim: klienti duhet të dërgojë së pari nga adresa e re. Një soket i lidhur ende me ndërfaqen e vjetër nuk e bën kurrë këtë, prandaj tuneli mund të duket i gjallë ndërsa kohëmatësi i shtrëngimit të duarve plaket. përshkrimi i protokollit e saktëson kushtin e përditësimit të pikës fundore, dhe ia vlen të lexohet para se të ndryshoni një konfigurim.
MOBIKE negociohet, nuk supozohet. Nëse serveri nuk e ofron, klienti duhet të rivendosë, dhe ky është një fakt që e konfirmoni nga lista e SA ose regjistri, jo që e nxirrni nga një rrotë që rrotullohet.
Rruga vendoset nga preferenca e rrugës, jo nga ikona e Wi-Fi
Kur të dyja ndërfaqet janë lart, bërthama zgjedh sipas metrikës dhe gjatësisë së prefiksit. ip route show default liston kandidatët dhe ip route get 203.0.113.10 zgjidh vendimin e vërtetë, përfshirë adresën e burimit. Një rrugë e paracaktuar me kabllo në metrikën 100 dhe një pa tel në 600 nënkuptojnë që pika fundore zhvendoset në çastin kur kablloja ulet, ndërsa çdo aplikacion që hapi një soket më parë mban burimin e vet të vjetër.
Windows bën të njëjtën gjë me metrika ndërfaqeje automatike, të anuara nga shpejtësia e lidhjes. Get-NetRoute -DestinationPrefix 0.0.0.0/0 rendit kandidatët dhe Find-NetRoute -RemoteIPAddress 203.0.113.10 kthen ndërfaqen dhe burimin që do të zgjidhte stivi. Një klient që lidh soketin e jashtëm me një ndërfaqe vazhdon ta përdorë atë edhe pasi metrika kthehet mbrapsht; ky është një vendim lidhjeje, jo një defekt rrugëtimi.
Android e bën ndarjen të dukshme: ConnectivityManager raporton rrjetet e disponueshme dhe një të paracaktuar të veçantë, dhe një aplikacion VPN që lidh një soket me një objekt Network e mban atë lidhje derisa ta lidhë përsëri. Në macOS, scutil --nwi shtyp ndërfaqen kryesore dhe rendin që do të përdorte sistemi.
DNS, MTU dhe IPv6 lëvizin me lidhjen
Një lidhje e re sjell zgjidhës të re. Me systemd-resolved DNS është për çdo lidhje, resolvectl status tregon cila lidhje përgjigjet për një emër, dhe një rrjet mysafirësh që shpërndan zgjidhësin e vet mund ta lërë DNS-në e shtyrë nga tuneli të papërdorur derisa lidhja të preferohet përsëri. Një portal robërues e përkeqëson: kërkesës së parë HTTPS i përgjigjet portali në vend të pikës fundore, dhe klienti regjistron një server të vdekur.
Edhe MTU-ja e rrugës ndryshon. Ethernet dhe Wi-Fi zakonisht mbajnë 1500 bajt, PPPoE 1492, dhe lidhjet mobile shpesh më pak. Një tunel që trashëgon një MTU më të vogël ngec në paketa të mëdha ndërsa kërkesat e vogla kalojnë, gjë që lexohet si një lidhje gjysmë e thyer. ping -M do -s 1472 203.0.113.10 dërgon një paketë prej 1500 bajtësh me DF të vendosur; heshtja do të thotë që rruga është më e vogël se sa supozuat.
IPv6 është gjysma tjetër. Një rrjet që shpërndan një prefiks të re ndryshon burimin që do të përdorte një klient me dy stiva, dhe një tunel vetëm v4 e lë trafikun v6 jashtë derisa politika ta arrijë. ip -6 route show default dhe ip -6 addr show përgjigjen nëse lidhja e re ka fare rrugë v6.
Riprodhoni tranzicionin në vend që ta përshkruani
Zgjidhni një kërkesë të padëmshme dhe ekzekutoni të njëjtat tre komanda në të dyja anët e ndryshimit: ip -br addr, ip route show default, ip route get 203.0.113.10. Pastaj vëzhgoni nëse tuneli ende lëshon paketa - tcpdump -ni any udp port 51820 për WireGuard, portin përkatës për çdo gjë tjetër. Paketat që dalin nga burimi i vjetër nënkuptojnë një problem lidhjeje. Paketat nga burimi i re pa përgjigje nënkuptojnë anën e largët ose NAT-in në mes.
Vini re cila ngjarje përkoi me defektin e parë: rënia e lidhjes, ndryshimi i adresës ose ndryshimi i rrugës së paracaktuar. Këto tregojnë përgjegjës të ndryshëm - një klient që duhet rilidhur, një adresë që duhet rifituar, ose një rrugë që i përket një skedari konfigurimi dhe jo një rregulli të përhershëm anashkalimi.
Para se ta shpallni të rregulluar, konfirmoni që blloku i trafikut të drejtpërdrejtë ende qëndron gjatë boshllëkut dhe që emrat zgjidhen përmes lidhjes së re. Nëse klienti mban pikën fundore të vjetër pas ndërrimit, rregulloni së pari cilësimin e roaming-ut ose float. Nëse bën roaming saktë dhe ende nuk merr përgjigje, shikoni identitetin e homologut në server dhe NAT-in në rrugë, dhe mbani të dy kontekstet e rrjetit në raport që personi tjetër t’i krahasojë.