Du dalykai pranešami kaip vienas gedimas: nešiojamasis kompiuteris persikėlė į kitą Wi-Fi tinklą arba buvo įjungtas kabelis, kol Wi-Fi liko veikti. Klientas vis dar sako prisijungęs, piktograma atrodo sveika, o tunelis nieko neperduoda. Po paviršiumi gali pasislinkti tik trys būsenos dalys - ryšys, vietinis adresas, numatytasis maršrutas - ir kuri pasislinko, lemia, ar tunelis atsistatys pats, ar reikės jungtis iš naujo. Tikrinu juos ta tvarka, nes paskyros nustatymų keitimas niekada neištaisė nė vieno.

Ryšys, adresas ir maršrutas juda nepriklausomai

Roamingas tarp to paties tinklo prieigos taškų dažniausiai yra L2 įvykis. Radijas prisijungia iš naujo, sąsaja išlaiko savo adresą ir šliuzą, ir niekas, nuo ko priklauso tunelis, nesikeičia, todėl pasivaikščiojimas dideliame biure kartais lieka nepastebėtas. Prisijungimas prie kito SSID nėra tai: sena sąsaja gali nukristi, DHCP išduoda naują adresą, naują šliuzą ir naujus resolverius, o išorinis srautas, kurį naudojo tunelis, nustoja egzistuoti.

Ethernet prideda trečią formą. Wi-Fi niekada nenukrenta, todėl ryšio įvykis apskritai neįvyksta, tačiau laidinė sąsaja atsiranda su savo adresu ir dažnai laimi numatytąjį maršrutą pagal metriką. Tunelis toliau eina keliu, kuris nebėra pageidaujamas, arba klientas laiko savo lizdą prisegtą prie belaidžio tinklo, kuriame pradėjo. Naršyklėje abu atrodo vienodai: puslapiai sustoja tą akimirką, kai kabelis įsistato.

Taigi pirmas klausimas ne ar pasikeitė Wi-Fi. O ar pasikeitė adresas, prie kurio esate prisirišę, arba maršrutas iki galinio taško, kol tunelis veikė.

Išorinis lizdas prisegtas prie adreso, kuris ką tik dingo

Kiekvienas tunelis yra išorinis srautas: vietinis adresas ir prievadas, kalbantys su serverio adresu ir prievadu. Linux tai UDP lizdas, susietas su senu šaltiniu; kai sąsaja, laikanti adresą, pašalinama, siuntimai arba nepavyksta su EADDRNOTAVAIL, arba išeina per naują sąsają su šaltiniu, kurio serveris niekada nematė.

Tolimoji pusė laiko savo prisegimą. IKEv2 SA be MOBIKE identifikuojama adresų pora, o OpenVPN sesija susieta su bendraamžio adresu, kurį išmoko, o NAT susiejimas priklauso privačiam adresui, prievadui ir viešajam adresui, kurie jį sukūrė. Persikėlus už kito NAT, kiekvienas atsakymas siunčiamas į susiejimą, kurio nebėra. Jūsų mašinoje niekas neteisingai nesukonfigūruota; penketukas rodo į tinklą, kurį palikote.

Paskaitykite būseną prieš teoretizuodami:

  • ss -unp parodo vietinį adresą ir prievadą, kuriuos iš tikrųjų laiko kiekvienas tunelio lizdas.
  • ip route get 203.0.113.10 išspausdina šaltinio adresą ir įrenginį, kurį branduolys dabar naudotų galiniam taškui.
  • wg show wg0 endpoints, swanctl --list-sas arba kliento žurnalas parodo bendraamžio adresą, su kuriuo tolimoji pusė mano kalbanti.

Jei lizdo adresas ir maršruto paieška nesutampa, radote trūkį, ir joks prisijungimo duomenų keitimas jo nepalies.

Ką kiekvienas protokolas daro su nauju šaltinio adresu

Klientai pokytį sugeria įvairiai, o lentelė yra tai, su kuo lyginu kliento konfigūraciją, o ne spėlioju iš prisijungimo iš naujo elgsenos.

TunnelRecovery behaviourFailure signature
WireGuardUpdates 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/IPsecMOBIKE (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 TCPThe tunnel is a byte stream, so a changed source address breaks it outright.Immediate reset and a new connection attempt.

WireGuard roamingo taisyklė veikia tik viena kryptimi: klientas pirmiausia turi siųsti iš naujo adreso. Lizdas, vis dar susietas su sena sąsaja, to niekada nepadaro, todėl tunelis gali atrodyti gyvas, kol jo rankos paspaudimo laikmatis sensta. protokolo aprašymas tiksliai nurodo galinio taško atnaujinimo sąlygą, ir verta jį perskaityti prieš keičiant konfigūraciją.

MOBIKE deramasi, o ne numatoma. Jei serveris jo nesiūlo, klientas turi iš naujo nustatyti, ir tai yra faktas, kurį patvirtinate iš SA sąrašo ar žurnalo, o ne darote išvadą iš besisukančio ratuko.

Kelią lemia maršruto pirmenybė, o ne Wi-Fi piktograma

Kai abi sąsajos pakeltos, branduolys renkasi pagal metriką ir prefikso ilgį. ip route show default išvardija kandidatus, o ip route get 203.0.113.10 išsprendžia tikrąjį sprendimą, įskaitant šaltinio adresą. Laidinis numatytasis su metrika 100 ir belaidis su 600 reiškia, kad galinis taškas pasislenka tą akimirką, kai kabelis įsistato, o kiekviena programa, anksčiau atidariusi lizdą, išlaiko savo seną šaltinį.

Windows daro tą patį su automatinėmis sąsajos metrikomis, paveiktomis ryšio greičio. Get-NetRoute -DestinationPrefix 0.0.0.0/0 surikiuoja kandidatus, o Find-NetRoute -RemoteIPAddress 203.0.113.10 grąžina sąsają ir šaltinį, kuriuos pasirinktų stekas. Klientas, susiejantis savo išorinį lizdą su viena sąsaja, toliau ją naudoja po to, kai metrika apsiverčia; tai susiejimo sprendimas, o ne maršrutizavimo gedimas.

Android padaro atskyrimą matomą: ConnectivityManager praneša apie prieinamus tinklus ir atskirą numatytąjį, o VPN programa, susiejanti lizdą su Network objektu, laiko tą susiejimą, kol vėl susieja. macOS, scutil --nwi išspausdina pagrindinę sąsają ir tvarką, kurią naudotų sistema.

DNS, MTU ir IPv6 juda kartu su prisijungimu

Naujas prisijungimas atneša naujus resolverius. Su systemd-resolved DNS yra pagal ryšį, resolvectl status parodo, kuri sąsaja atsako į vardą, o svečių tinklas, išduodantis savo resolverį, gali palikti tunelio stumiamą DNS nenaudojamą, kol ryšys vėl taps pageidaujamas. Užgrobiamasis portalas tai pablogina: į pirmą HTTPS užklausą atsako portalas, o ne galinis taškas, ir klientas užfiksuoja negyvą serverį.

Kelio MTU taip pat keičiasi. Ethernet ir Wi-Fi paprastai neša 1500 baitų, PPPoE 1492, o mobilieji ryšiai dažnai mažiau. Tunelis, paveldėjęs mažesnį MTU, stringa ties dideliais paketais, o mažos užklausos praeina, ir tai skaitoma kaip pusiau sulaužytas ryšys. ping -M do -s 1472 203.0.113.10 siunčia 1500 baitų paketą su nustatytu DF; tyla reiškia, kad kelias mažesnis, nei manėte.

IPv6 yra kita pusė. Tinklas, išduodantis naują prefiksą, keičia šaltinį, kurį naudotų dvigubo steko klientas, o tik v4 tunelis palieka v6 srautą už jo ribų, kol politika pasiveja. ip -6 route show default ir ip -6 addr show atsako, ar naujasis ryšys apskritai turi v6 kelią.

Atkurkite perėjimą, o ne aprašykite jį

Pasirinkite vieną nekenksmingą užklausą ir paleiskite tuos pačius tris įsakymus abiejose pokyčio pusėse: ip -br addr, ip route show default, ip route get 203.0.113.10. Tada stebėkite, ar tunelis dar siunčia paketus - tcpdump -ni any udp port 51820 WireGuard atveju, atitinkamą prievadą viskam kitam. Paketai, išeinantys iš seno šaltinio, reiškia susiejimo problemą. Paketai iš naujo šaltinio be atsakymo reiškia tolimąją pusę arba tarpinį NAT.

Pažymėkite, kuris įvykis sutapo su pirmuoju gedimu: ryšio nutrūkimas, adreso pasikeitimas ar numatytojo maršruto pasikeitimas. Jie rodo skirtingus atsakinguosius - klientą, kurį reikia iš naujo susieti, adresą, kurį reikia iš naujo gauti, ar maršrutą, kuris priklauso konfigūracijos failui, o ne nuolatinei apėjimo taisyklei.

Prieš pavadindami tai ištaisyta, patvirtinkite, kad tiesioginio srauto blokas vis dar laikosi per tarpą ir kad vardai sprendžiami per naują prisijungimą. Jei klientas po perjungimo laiko seną galinį tašką, pirmiausia sutvarkykite roamingo arba float nustatymą. Jei jis roamingą atlieka teisingai ir vis dar negauna atsakymo, pažiūrėkite į serverio bendraamžio tapatybę ir NAT kelyje, ir išsaugokite abu tinklo kontekstus apraše, kad kitas žmogus galėtų juos palyginti.

Susiję straipsniai