Bakit bumabagsak ang VPN mo kapag nagbago ang Wi-Fi o nakasaksak ang Ethernet
'Ang bagong SSID, roaming sa pagitan ng mga access point at nakasaksak na kable ay nagbabali ng tunnel sa tatlong magkaibang lugar. Suriin ang source address, tapos ang ruta, tapos ang protocol.'
Dalawang bagay ang iniulat bilang isang kabiguan: lumipat ang laptop sa ibang Wi-Fi network, o may nakasaksak na kable habang tumatakbo pa ang Wi-Fi. Sinasabi pa rin ng client na konektado, mukhang malusog ang icon, at wala namang dinadala ang tunnel. Sa ilalim, tatlong piraso lang ng estado ang maaaring gumalaw - ang link, ang lokal na address, ang default na ruta - at kung alin ang gumalaw ang nagtatakda kung kusang babangon ang tunnel o kailangan ng muling pagkonekta. Sinusuri ko sila sa ganoong pagkakasunod-sunod, dahil wala pang naayos ang pagbabago ng mga setting ng account sa alinman sa kanila.
Hiwalay na gumagalaw ang link, address at ruta
Ang roaming sa pagitan ng mga access point sa parehong network ay karaniwang kaganapang L2. Nag-aassociate muli ang radyo, pinapanatili ng interface ang address at gateway nito, at walang nagbabago sa mga pinagkakatiwalaan ng tunnel, kaya may mga pagkakataong hindi napapansin ang paglalakad sa malaking opisina. Ang pagsali sa ibang SSID ay hindi iyon: maaaring bumagsak ang lumang interface, nagbibigay ang DHCP ng bagong address, bagong gateway at mga bagong resolver, at ang panlabas na daloy na ginamit ng tunnel ay wala na.
Nagdadagdag ang Ethernet ng ikatlong anyo. Hindi kailanman bumabagsak ang Wi-Fi, kaya walang kaganapang link na nangyayari, pero lumilitaw ang wired interface na may sariling address at madalas na pinapanalunan ang default na ruta sa metric. Patuloy na tumatakbo ang tunnel sa daang hindi na ginusto, o pinapanatili ng client na nakakabit ang socket nito sa wireless network kung saan ito nagsimula. Mula sa browser, magkapareho ang itsura ng dalawa: humihinto ang mga pahina sa sandaling pumasok ang kable.
Kaya ang unang tanong ay hindi kung nagbago ang Wi-Fi. Ito ay kung nagbago ang address na kinakabitan mo, o ang ruta patungo sa endpoint, habang buhay ang tunnel.
Nakapirmi ang panlabas na socket sa isang address na karara lang nawala
Ang bawat tunnel ay panlabas na daloy: isang lokal na address at port na kausap ang address at port ng server. Sa Linux iyon ay UDP socket na nakatali sa lumang source; kapag tinanggal ang interface na may address, ang mga pagpapadala ay nabigo sa EADDRNOTAVAIL o lumalabas sa bagong interface na may source na hindi pa nakita ng server.
Pinapanatili ng malayong panig ang sarili nitong pagkakapirmi. Ang SA ng IKEv2 na walang MOBIKE ay nakikilala sa pares ng address, at ang OpenVPN sesyon ay nakatali sa address ng kapares na natutunan nito, at ang NAT mapping ay pag-aari ng pribadong address, port at pampublikong address na lumikha nito. Lumipat ka sa likod ng ibang NAT at ang bawat sagot ay napupunta sa mapping na wala na. Walang mali ang pagkaka-configure sa makina mo; ang limang-tuple ay tumuturo sa network na iniwan mo.
Basahin ang estado bago magteorya:
ss -unpipinapakita ang lokal na address at port na talagang hawak ng bawat socket ng tunnel.ip route get 203.0.113.10ipiniprinta ang source address at device na gagamitin ng kernel para sa endpoint ngayon.wg show wg0 endpoints,swanctl --list-saso ipinapakita ng log ng client ang address ng kapares na inaakalang kausap ng malayong panig.
Kung hindi tugma ang address ng socket at ang paghahanap ng ruta, natagpuan mo ang pagkaputol, at walang pagbabago sa kredensyal ang makakaabot doon.
Ano ang ginagawa ng bawat protocol sa bagong source address
Iba-iba ang pag-absorb ng client sa pagbabago, at ang talahanayan ang inihahambing ko sa configuration ng client sa halip na manghula mula sa ugali ng muling pagkonekta.
| 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. |
Ang tuntunin ng roaming ng WireGuard ay gumagana sa isang direksyon lang: kailangan munang magpadala ng client mula sa bagong address. Ang socket na nakatali pa sa lumang interface ay hindi kailanman gumagawa niyon, kaya maaaring magmukhang buhay ang tunnel habang tumatanda ang handshake timer nito. paglalarawan ng protocol ay tiyak na nagsasaad ng kundisyon sa pag-update ng endpoint, at sulit itong basahin bago baguhin ang configuration.
Ang MOBIKE ay pinag-uusapan, hindi ipinagpapalagay. Kung hindi ito inaalok ng server, kailangang muling magtatag ng client, at iyon ay katotohanang pinapatunayan mo mula sa listahan ng SA o log, hindi hinihinuha mula sa umiikot na gulong.
Ang kagustuhan sa ruta ang nagtatakda ng daan, hindi ang icon ng Wi-Fi
Kapag nakataas ang dalawang interface, pumipili ang kernel ayon sa metric at haba ng prefix. ip route show default inililista ang mga kandidato at ip route get 203.0.113.10 nilulutas ang tunay na desisyon, kasama ang source address. Ang wired na default sa metric 100 at wireless sa 600 ay nangangahulugang gumagalaw ang endpoint sa sandaling kumapit ang kable, habang ang bawat application na nagbukas ng socket kanina ay pinapanatili ang lumang source nito.
Ganoon din ang ginagawa ng Windows gamit ang autometrik ng interface, na naimpluwensyahan ng bilis ng link. Get-NetRoute -DestinationPrefix 0.0.0.0/0 inaayos ang mga kandidato at Find-NetRoute -RemoteIPAddress 203.0.113.10 ibinabalik ang interface at source na pipiliin ng stack. Ang client na nagtatali ng panlabas na socket sa isang interface ay patuloy na gumagamit nito pagkatapos bumaliktad ang metric; desisyon iyon sa pagkakatali, hindi depektong routing.
Ginagawang nakikita ng Android ang paghahati: iniuulat ng ConnectivityManager ang mga available na network at hiwalay na default, at ang app na VPN na nagtatali ng socket sa isang object na Network ay pinapanatili ang pagkakataling iyon hanggang muling magtali. Sa macOS, scutil --nwi ipiniprinta ang pangunahing interface at ang pagkakasunod-sunod na gagamitin ng system.
Gumagalaw ang DNS, MTU at IPv6 kasama ng koneksyon
Nagdadala ng mga bagong resolver ang bagong koneksyon. Sa systemd-resolved, ang DNS ay kada link, resolvectl status ipinapakita kung aling link ang sumasagot sa isang pangalan, at ang guest network na namimigay ng sariling resolver ay maaaring mag-iwan sa DNS na itinulak ng tunnel na hindi ginagamit hanggang maging ginusto muli ang link. Pinapalala ito ng captive portal: ang unang kahilingang HTTPS ay sinasagot ng portal sa halip na ng endpoint, at itinatala ng client ang patay na server.
Nagbabago rin ang MTU ng daan. Karaniwang 1500 bytes ang dinadala ng Ethernet at Wi-Fi, 1492 ang PPPoE, at kadalasang mas kaunti ang mga mobile link. Ang tunnel na nagmamana ng mas maliit na MTU ay natigil sa malalaking packet habang dumadaan ang maliliit na kahilingan, na binabasa bilang koneksyong kalahating sira. ping -M do -s 1472 203.0.113.10 nagpapadala ng 1500-byte na packet na naka-DF; ang katahimikan ay nangangahulugang mas maliit ang daan kaysa inaasahan mo.
Ang IPv6 ang kabilang kalahati. Ang network na namimigay ng bagong prefix ay nagbabago ng source na gagamitin ng dual-stack na client, at ang tunnel na v4 lamang ay iniiwan sa labas ang trapikong v6 hanggang makahabol ang patakaran. ip -6 route show default at ip -6 addr show ay sumasagot kung may ruta mang v6 ang bagong link.
Kopyahin muli ang transisyon sa halip na ilarawan ito
Pumili ng isang hindi mapanganib na kahilingan at patakbuhin ang parehong tatlong utos sa magkabilang panig ng pagbabago: ip -br addr, ip route show default, ip route get 203.0.113.10. Pagkatapos, tingnan kung naglalabas pa ng packet ang tunnel - tcpdump -ni any udp port 51820 para sa WireGuard, ang katumbas na port para sa lahat ng iba pa. Ang mga packet na lumalabas mula sa lumang source ay nangangahulugang problema sa pagkakatali. Ang mga packet mula sa bagong source na walang sagot ay nangangahulugang ang malayong panig o ang NAT sa gitna.
Itala kung aling kaganapan ang kasabay ng unang kabiguan: pagbagsak ng link, pagbabago ng address, o pagbabago ng default na ruta. Itinuturo ng mga ito ang magkaibang may pananagutan - client na kailangang muling magtali, address na kailangang kunin muli, o rutang pag-aari ng file ng configuration at hindi ng permanenteng tuntunin sa paglampas.
Bago sabihing naayos na, tiyakin na hawak pa rin ang block ng direktang trapiko sa buong agwat at nalulutas ang mga pangalan sa bagong koneksyon. Kung hinahawakan pa rin ng client ang lumang endpoint pagkatapos ng paglipat, ayusin muna ang setting ng roaming o float. Kung tama ang roaming at wala pa ring sagot, tingnan ang pagkakakilanlan ng kapares sa server at ang NAT sa daan, at itago ang parehong konteksto ng network sa ulat para maikumpara ng susunod na tao.