Kāpēc jūsu VPN pārtrūkst, kad mainās Wi-Fi vai tiek iesprausts Ethernet
'Jauns SSID, pārvietošanās starp piekļuves punktiem un iesprausts kabelis pārtrauc tuneli trijās dažādās vietās. Pārbaudiet avota adresi, tad maršrutu, tad protokolu.'
Divas lietas tiek ziņotas kā viens bojājums: klēpjdators pārcēlās uz citu Wi-Fi tīklu, vai arī tika iesprausts kabelis, kamēr Wi-Fi turpināja darboties. Klients joprojām saka, ka ir savienots, ikona izskatās vesela, un tunelis neko nepārvieto. Zem virsmas var pārvietoties tikai trīs stāvokļa daļas - savienojums, vietējā adrese, noklusējuma maršruts - un tas, kura pārvietojās, nosaka, vai tunelis atjaunosies pats vai būs nepieciešams pārsevienoties. Es tos pārbaudu šajā secībā, jo konta iestatījumu maiņa nekad nav salabojusi nevienu no tiem.
Savienojums, adrese un maršruts pārvietojas neatkarīgi
Pārvietošanās starp viena tīkla piekļuves punktiem parasti ir L2 notikums. Radio pārassoķējas, saskarne saglabā savu adresi un vārteju, un nekas, no kā tunelis atkarīgs, nemainās, tāpēc pastaiga pa lielu biroju dažreiz paliek nepamanīta. Pievienošanās citam SSID nav tas: vecā saskarne var nokrist, DHCP izsniedz jaunu adresi, jaunu vārteju un jaunus atrisinātājus, un ārējā plūsma, ko tunelis izmantoja, pārstāj pastāvēt.
Ethernet pievieno trešo formu. Wi-Fi nekad nenokrīt, tāpēc savienojuma notikums vispār neizraisās, taču vadu saskarne parādās ar savu adresi un bieži vien uzvar noklusējuma maršrutu pēc metrikas. Tunelis turpina iet pa ceļu, kas vairs nav vēlamais, vai klients tur savu ligzdu piesaistītu bezvadu tīklam, kurā sāka. Pārlūkā abi izskatās vienādi: lapas apstājas tajā mirklī, kad kabelis iekļūst.
Tātad pirmais jautājums nav, vai Wi-Fi mainījās. Tas ir, vai mainījās adrese, pie kuras esat piesaistīti, vai maršruts līdz galapunktam, kamēr tunelis bija aktīvs.
Ārējā ligzda ir piesaistīta adresei, kas tikko pazuda
Katrs tunelis ir ārēja plūsma: vietējā adrese un ports sarunājas ar servera adresi un portu. Linux tas ir UDP ligzda, kas saistīta ar veco avotu; kad saskarne, kurai pieder adrese, tiek noņemta, sūtījumi vai nu neizdodas ar EADDRNOTAVAIL, vai iziet pa jauno saskarni ar avotu, ko serveris nekad nav redzējis.
Tālā puse tur savu piesaisti. IKEv2 SA bez MOBIKE tiek identificēta pēc adrešu pāra, un OpenVPN sesija ir saistīta ar vienaudža adresi, ko tā iemācījās, un NAT kartējums pieder privātajai adresei, portam un publiskajai adresei, kas to izveidoja. Pārvietojieties aiz cita NAT, un katra atbilde tiek sūtīta uz kartējumu, kura vairs nav. Jūsu mašīnā nekas nav nepareizi konfigurēts; piecinieks norāda uz tīklu, kuru atstājāt.
Izlasi stāvokli, pirms teoretizē:
ss -unpparāda vietējo adresi un portu, ko katrs tuneļa ligzda patiešām tur.ip route get 203.0.113.10izdrukā avota adresi un ierīci, ko kodols tagad izmantotu galapunktam.wg show wg0 endpoints,swanctl --list-sasvai klienta žurnāls parāda vienaudža adresi, ar kuru tālā puse domā, ka runā.
Ja ligzdas adrese un maršruta meklēšana nesakrīt, jūs esat atradis pārrāvumu, un nekāda akreditācijas datu maiņa to neskars.
Ko katrs protokols dara ar jaunu avota adresi
Klienti izmaiņu uzņem dažādi, un tabula ir tas, ar ko es salīdzinu klienta konfigurāciju, nevis minu no atkārtotas savienošanās uzvedības.
| 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. |
WireGuard klejošanas noteikums darbojas tikai vienā virzienā: klientam vispirms jāsūta no jaunās adreses. Ligzda, kas joprojām saistīta ar veco saskarni, to nekad nedara, tāpēc tunelis var izskatīties dzīvs, kamēr tā rokas paspiešanas taimeris noveco. protokola apraksts precīzi norāda galapunkta atjaunināšanas nosacījumu, un to ir vērts izlasīt pirms konfigurācijas maiņas.
MOBIKE tiek apspriests, nevis pieņemts. Ja serveris to nepiedāvā, klientam jāatjauno savienojums, un tas ir fakts, ko apstiprina no SA saraksta vai žurnāla, nevis izsecina no rotējoša ritenīša.
Ceļu nosaka maršruta prioritāte, nevis Wi-Fi ikona
Kad abas saskarnes ir augšā, kodols izvēlas pēc metrikas un prefiksa garuma. ip route show default uzskaita kandidātus, un ip route get 203.0.113.10 atrisina īsto lēmumu, tostarp avota adresi. Vadu noklusējums ar metriku 100 un bezvadu ar 600 nozīmē, ka galapunkts pārvietojas tajā mirklī, kad kabelis iekārtojas, kamēr katra programma, kas agrāk atvēra ligzdu, saglabā savu veco avotu.
Windows dara to pašu ar automātiskām saskarnes metrikām, ko ietekmē saites ātrums. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sakārto kandidātus, un Find-NetRoute -RemoteIPAddress 203.0.113.10 atgriež saskarni un avotu, ko izvēlētos steks. Klients, kas savu ārējo ligzdu piesaista vienai saskarnei, turpina to lietot arī pēc metrikas apvēršanās; tas ir piesaistes lēmums, nevis maršrutēšanas defekts.
Android padara sadalījumu redzamu: ConnectivityManager ziņo par pieejamajiem tīkliem un atsevišķu noklusējumu, un VPN lietotne, kas piesaista ligzdu Network objektam, tur šo piesaisti, līdz piesaista no jauna. macOS, scutil --nwi izdrukā primāro saskarni un secību, ko sistēma izmantotu.
DNS, MTU un IPv6 pārvietojas kopā ar pievienojumu
Jauns pievienojums nes jaunus atrisinātājus. Ar systemd-resolved DNS ir pa saitei, resolvectl status parāda, kura saite atbild uz vārdu, un viesu tīkls, kas izsniedz savu atrisinātāju, var atstāt tuneļa iespiesto DNS neizmantotu, līdz saite atkal kļūst vēlamā. Uzglūnēšanas portāls to pasliktina: uz pirmo HTTPS pieprasījumu atbild portāls, nevis galapunkts, un klients reģistrē mirušu serveri.
Arī ceļa MTU mainās. Ethernet un Wi-Fi parasti pārvadā 1500 baitus, PPPoE 1492, un mobilās saites bieži mazāk. Tunelis, kas manto mazāku MTU, iestrēgst pie lieliem paketēm, kamēr mazi pieprasījumi iziet, un to lasa kā puslīdz salauztu savienojumu. ping -M do -s 1472 203.0.113.10 sūta 1500 baitu paketi ar iestatītu DF; klusums nozīmē, ka ceļš ir mazāks, nekā jūs pieņēmāt.
IPv6 ir otra puse. Tīkls, kas izsniedz jaunu prefiksu, maina avotu, ko izmantotu dubultsteka klients, un tunelis tikai ar v4 atstāj v6 satiksmi ārpus tā, līdz politika paspēj līdzi. ip -6 route show default un ip -6 addr show atbild, vai jaunajai saitei vispār ir v6 ceļš.
Atveido pāreju, nevis apraksti to
Izvēlies vienu nekaitīgu pieprasījumu un palaid tos pašus trīs komandas abās pārmaiņas pusēs: ip -br addr, ip route show default, ip route get 203.0.113.10. Pēc tam vēro, vai tunelis vēl izsūta paketes - tcpdump -ni any udp port 51820 WireGuard gadījumā, atbilstošo portu visam citam. Paketes, kas iznāk no vecā avota, nozīmē piesaistes problēmu. Paketes no jaunā avota bez atbildes nozīmē tālo pusi vai starpā esošo NAT.
Pieraksti, kurš notikums sakrita ar pirmo bojājumu: saites zudums, adreses maiņa vai noklusējuma maršruta maiņa. Tie norāda uz dažādiem atbildīgajiem - klientu, kas jāpiesaista no jauna, adresi, kas jāiegūst no jauna, vai maršrutu, kas pieder konfigurācijas failam, nevis pastāvīgam apiešanas noteikumam.
Pirms nosaukt to par salabotu, apstiprini, ka tiešās satiksmes bloks joprojām turas pārrāvuma laikā un ka vārdi tiek atrisināti caur jauno pievienojumu. Ja klients pēc pārslēgšanās tur veco galapunktu, vispirms salabo klejošanas vai float iestatījumu. Ja tas klejo pareizi un joprojām nesaņem atbildi, paskaties uz servera vienaudža identitāti un NAT ceļā, un saglabā abus tīkla kontekstus aprakstā, lai nākamais cilvēks varētu tos salīdzināt.