Wêrom’t dyn VPN falt as Wi-Fi feroaret of Ethernet ynstutsen wurdt
'In nij SSID, in roaming tusken tagongspunten en in ynstutsen kabel brekke in tunnel op trije ferskate plakken. Kontrolearje it boarneadres, dan de rûte, dan it protokol.'
Twa dingen wurde as ien flater rapportearre: de laptop is nei in oar Wi-Fi-netwurk ferhuze, of der is in kabel ynstutsen wylst Wi-Fi oan bleau. De klient seit noch hieltyd ferbûn, it byldsje liket sûn, en de tunnel ferfiert neat. Under de oerflakte kinne mar trije stikken steat bewege - de keppeling, it lokale adres, de standertrûte - en hokker beweegde beslút oft de tunnel himsels werstelt of opnij ferbine moat. Ik kontrolearje se yn dy folchoarder, want it feroarjen fan akkountynstellingen hat noch nea ien fan harren reparearre.
Keppeling, adres en rûte bewege ûnôfhinklik
Roaming tusken tagongspunten yn itselde netwurk is meastentiids in L2-evenemint. De radio ferbynt opnij, de ynterface hâldt syn adres en gateway, en neat dêr’t de tunnel fan ôfhinget feroaret, dêrom giet in kuier troch in grut kantoar soms ûngemurken foarby. By in oar SSID komme is dat net: de âlde ynterface kin delgean, DHCP jout in nij adres, in nije gateway en nije resolvers, en de bûtenstream dy’t de tunnel brûkte hâldt op te bestean.
Ethernet foeget in tredde foarm ta. Wi-Fi falt nea, dus der wurdt hielendal gjin keppelingsevenemint ôffierd, mar de bedrade ynterface ferskynt mei syn eigen adres en wint faak de standertrûte op metryk. De tunnel bliuwt rinnen oer in paad dat net mear foarkar hat, of de klient hâldt syn socket fêstset oan it draadleaze netwurk dêr’t er op begûn. Fan de browser ôf sjogge beide der itselde út: siden stûkje op it momint dat de kabel klikt.
Dat de earste fraach is net oft Wi-Fi feroare is. It is oft it adres dêr’t jo oan fêstbûn binne, of de rûte nei it einpunt, feroare wylst de tunnel oan wie.
De bûtenste socket is fêstset oan in adres dat krekt ferdwûn is
Elke tunnel is in bûtenstream: in lokaal adres en poarte dy’t prate mei it adres en de poarte fan de tsjinner. Op Linux is dat in UDP-socket bûn oan de âlde boarne; as de ynterface dy’t it adres hat fuorthelle wurdt, mislearje ferstjoerings mei EADDRNOTAVAIL of geane se troch de nije ynterface mei in boarne dy’t de tsjinner nea sjoen hat.
De fiere kant hâldt syn eigen fêstsetting. In IKEv2-SA sûnder MOBIKE wurdt identifisearre troch it adrespear, en in OpenVPN-sesje is bûn oan it peeradres dat er leard hat, en in NAT-mapping heart by it privee-adres, de poarte en it iepenbiere adres dy’t it makke hawwe. Ferpleats jo efter in oare NAT en elk antwurd wurdt stjoerd nei in mapping dy’t net mear bestiet. Neat op jo masine is ferkeard konfigurearre; de fyftupel wiist nei in netwurk dat jo ferlitten hawwe.
Lês de steat foardat jo teoretisearje:
ss -unptoant it lokale adres en de poarte dy’t elke tunnelsocket wier hat.ip route get 203.0.113.10prints it boarneadres en it apparaat dat de kernel no foar it einpunt brûke soe.wg show wg0 endpoints,swanctl --list-sasof it kliïntloch toant it peeradres dêr’t de fiere kant fan tinkt dat er mei praat.
As it socketadres en de rûtesykoarte opfreage net oerienkomme, hawwe jo it brek fûn, en gjin feroaring fan bewizen sil it oanreitsje.
Wat elk protokol mei in nij boarneadres docht
Klanten absorbearje de feroaring yn ferskate mjitten, en de tabel is wat ik mei de kliïntkonfiguraasje ferlykje ynstee fan te rieden út it opnij-ferbinen-gedrach.
| 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. |
De roamingregel fan WireGuard wurket mar ien kant út: de klient moat earst fan it nije adres stjoere. In socket dy’t noch oan de âlde ynterface bûn is docht dat nea, dêrom kin in tunnel libjend lykje wylst syn hânskoddingstimer ferâldet. protokolbeskriuwing stelt de betingst foar it bywurkjen fan it einpunt krekt, en it is de muoite wurdich om te lêzen foardat jo in konfiguraasje feroarje.
MOBIKE wurdt ûnderhannele, net oannommen. As de tsjinner it net biedt, moat de klient opnij opsette, en dat is in feit dat jo út ’e SA-list of it loch befêstigje ynstee fan it út in draaiend tsjil ôf te lieden.
Rûtefoarkar beslút it paad, net it Wi-Fi-byldsje
Mei beide ynterfaces oan kiest de kernel op metryk en foarheakselelingte. ip route show default listet de kandidaten en ip route get 203.0.113.10 lost it wiere beslút op, ynklusyf it boarneadres. In bedrade standert op metryk 100 en in draadleaze op 600 betsjutte dat it einpunt ferpleatst op it momint dat de kabel sit, wylst elke applikaasje dy’t earder in socket iepene syn âlde boarne hâldt.
Windows docht itselde mei automatyske ynterfacemetryken, foaroardiele troch keppelingsfaasje. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sortearret de kandidaten en Find-NetRoute -RemoteIPAddress 203.0.113.10 jout de ynterface en boarne werom dy’t de stapel kieze soe. In klient dy’t syn bûtenste socket oan ien ynterface bynt, brûkt it troch nei’t de metryk omkeard is; dat is in biningsbeslút, gjin rûteflater.
Android makket de splitsing sichtber: ConnectivityManager rapportearret beskikbere netwurken en in aparte standert, en in VPN-app dy’t in socket oan in Network-objekt bynt hâldt dy bining oant er wer bynt. Op macOS, scutil --nwi prints de primêre ynterface en de folchoarder dy’t it systeem brûke soe.
DNS, MTU en IPv6 bewege mei de oansluting
In nije oansluting bringt nije resolvers. Mei systemd-resolved is DNS per keppeling, resolvectl status toant hokker keppeling in namme beantwurdet, en in gastnetwurk dat syn eigen resolver jout kin de DNS dy’t de tunnel stjoerd hat ûnbrûkt litte oant de keppeling wer foarkar krijt. In finzen portaal makket it slimmer: it earste HTTPS-fersyk wurdt troch it portaal beantwurde ynstee fan it einpunt, en de klient registrearret in deade tsjinner.
De MTU fan it paad feroaret ek. Ethernet en Wi-Fi drage meastentiids 1500 byte, PPPoE 1492, en mobile keppelingen faak minder. In tunnel dy’t in lytsere MTU erft stûket op grutte pakketten wylst lytse fersiken slagje, wat lêzen wurdt as in heal brutsen ferbining. ping -M do -s 1472 203.0.113.10 stjoert in pakket fan 1500 byte mei DF oan; stilte betsjutte dat it paad lytser is as jo oannommen hawwe.
IPv6 is de oare helte. In netwurk dat in nij foarheaksel jout feroaret de boarne dy’t in dual-stack-klient brûke soe, en in tunnel allinnich foar v4 lit v6-ferkear der bûten oant belied bykomt. ip -6 route show default en ip -6 addr show beantwurdzje oft de nije keppeling hielendal in v6-paad hat.
Reprodusearje de oergong ynstee fan him te beskriuwen
Kies ien ûnskeeplik fersyk en rin deselde trije opdrachten oan beide kanten fan ’e feroaring: ip -br addr, ip route show default, ip route get 203.0.113.10. Sjoch dan oft de tunnel noch pakketten útstjoert - tcpdump -ni any udp port 51820 foar WireGuard, de oerienkommende poarte foar al it oare. Pakketten dy’t fan ’e âlde boarne fuortgeane betsjutte in biningsprobleem. Pakketten fan ’e nije boarne sûnder antwurd betsjutte de fiere kant of de NAT der tuskenyn.
Notearje hokker evenemint gearfoel mei de earste flater: keppeling del, adresferoaring of feroaring fan ’e standertrûte. Dy wize nei ferskillende eigners - in klient dy’t wer bynt, in adres dat wer helle wurde moat, of in rûte dy’t by in konfiguraasjebestân heart en net by in permaninte bypass-regel.
Foardat jo it reparearre neame, befêstigje dat it blok foar direkte ferkear him noch hâldt yn ’e gat en dat nammen troch de nije oansluting oplost wurde. As de klient nei de omskeakeling it âlde einpunt hâldt, reparearje earst de roaming- of float-ynstelling. As er korrekt roamet en noch hieltyd gjin antwurd krijt, sjoch dan nei de identiteit fan ’e peer op ’e tsjinner en de NAT op it paad, en hâld beide netwurk-konteksten yn it ferslach sadat de folgjende persoan se ferlykje kin.