Af hverju VPN-ið þitt dettur þegar Wi-Fi breytist eða Ethernet er stingið í

Tveir hlutir eru tilkynntir sem ein bilun: fartölvan færðist á annað Wi-Fi-net, eða kaðall var stingið í á meðan Wi-Fi var áfram virkt. Biðlarinn segir enn tengt, táknið lítur heilbrigt út, og göngin flytja ekkert. Undir yfirborðinu geta aðeins þrír stykki af stöðu hreyfst - tengingin, staðarfangið, sjálfgefna leiðin - og hvert þeirra hreyfðist ræður því hvort göngin jafni sig sjálf eða þurfi endurtengingu. Ég athuga þau í þeirri röð, því að breyta reikningsstillingum hefur aldrei lagað nokkurt þeirra.

Tenging, fang og leið hreyfast óháð

Reiki milli aðgangsstaða á sama neti er yfirleitt L2-atburður. Loftnetið tengist aftur, viðmótið heldur fangi sínu og gátt, og ekkert sem göngin byggja á breytist, og þess vegna fer ganga um stórt skrifstofuherbergi stundum óséð. Að ganga í annað SSID er ekki það: gamla viðmótið getur farið niður, DHCP úthlutar nýju fangi, nýrri gátt og nýjum leysum, og ytra flæðið sem göngin notuðu hættir að vera til.

Ethernet bætir við þriðju myndinni. Wi-Fi dettur aldrei, svo ekkert tengingaratburður kviknar, en snúruviðmótið birtist með eigið fang og vinnur oft sjálfgefnu leiðina á metrík. Göngin halda áfram á slóð sem er ekki lengur valin, eða biðlarinn heldur sokknum festum við þráðlausa netið sem hann byrjaði á. Frá vafranum líta bæði eins út: síður stöðvast á þeirri sekúndu sem kaðallinn smellir.

Fyrsta spurningin er því ekki hvort Wi-Fi breyttist. Hún er hvort fangið sem þú ert bundin við, eða leiðin að endapunktinum, breyttist meðan göngin voru uppi.

Ytri sokkurinn er festur við fang sem hvarf rétt í þessu

Hvert göng eru ytra flæði: staðarfang og port sem tala við fang og port netþjónsins. Á Linux er það UDP-sokkur bundinn við gamla upprunann; þegar viðmótið sem heldur fanginu er fjarlægt, mistakast sendingar með EADDRNOTAVAIL eða fara út um nýja viðmótið með uppruna sem netþjónninn hefur aldrei séð.

Fjarlæga hliðin heldur sínu festi. IKEv2-SA án MOBIKE er auðkennt af fangaparinu, og OpenVPN lota er bundin við jafningjafangið sem hún lærði, og NAT-kortlagning tilheyrir einkafanginu, portinu og opinbera fanginu sem bjuggu hana til. Færðu þig bak við annað NAT og hvert svar er sent á kortlagningu sem er ekki lengur til. Ekkert á vélinni þinni er rangt stillt; fimmbúið bendir á net sem þú yfirgafst.

Lestu stöðuna áður en þú ferð í kenningarnar:

• ss -unp sýnir staðarfangið og portið sem hver gangasokkur hefur í raun.
• ip route get 203.0.113.10 prentar upprunafangið og tækið sem kjarninn myndi nota fyrir endapunktinn núna.
• wg show wg0 endpoints, swanctl --list-sas eða biðlaraloggið sýnir jafningjafangið sem fjarlæga hliðin heldur að hún tali við.

Ef fang sokkanna og leiðarleitin stemma ekki, hefur þú fundið brotið, og engin breyting á skírteinum mun snerta það.

Hvað hver samskiptaregla gerir við nýtt upprunafang

Biðlarar melta breytinguna misvel, og taflan er það sem ég ber saman við stillingar biðlarans í stað þess að giska út frá hegðun endurtengingar.

Reikiregla WireGuard virkar aðeins í eina átt: biðlarinn verður fyrst að senda frá nýja fanginu. Sokkur sem er enn bundinn við gamla viðmótið gerir það aldrei, og þess vegna geta göng litið lifandi út á meðan handabandstiminninn eldist. lýsing samskiptareglunnar tilgreinir nákvæmlega skilyrðið fyrir uppfærslu endapunktsins, og það er þess virði að lesa hana áður en þú breytir stillingu.

MOBIKE er samið um, ekki gert ráð fyrir. Ef netþjónninn býður það ekki verður biðlarinn að endurreisa, og það er staðreynd sem þú staðfestir úr SA-listanum eða logginu frekar en að draga af snúningshjóli.

Leiðarval ræður slóðinni, ekki Wi-Fi-táknið

Með bæði viðmót upp velur kjarninn eftir metrík og lengd forskeytis. ip route show default listar frambjóðendurna og ip route get 203.0.113.10 leysir raunverulegu ákvörðunina, þar á meðal upprunafangið. Snúruleg sjálfgefin leið á metrík 100 og þráðlaus á 600 þýða að endapunkturinn færist á þeirri stundu sem kaðallinn sest, á meðan hvert forrit sem opnaði sokk fyrr heldur gamla upprunanum sínum.

Windows gerir það sama með sjálfvirkum viðmótsmetríkum, hlutdrægum af hraða tengingarinnar. Get-NetRoute -DestinationPrefix 0.0.0.0/0 raðar frambjóðendunum og Find-NetRoute -RemoteIPAddress 203.0.113.10 skilar viðmótinu og upprunanum sem staflinn myndi velja. Biðlari sem bindur ytri sokkinn sinn við eitt viðmót heldur áfram að nota það eftir að metríkin snýst við; það er bindandi ákvörðun, ekki leiðarvilla.

Android gerir skiptinguna sýnilega: ConnectivityManager tilkynnir fáanleg net og sérstakt sjálfgefið, og VPN-forrit sem bindur sokk við Network-hlut heldur þeirri bindingu þangað til það bindur aftur. Á macOS scutil --nwi prentar aðalviðmótið og þá röð sem kerfið myndi nota.

DNS, MTU og IPv6 hreyfast með tengingunni

Ný tenging færir nýja leysa. Með systemd-resolved er DNS eftir tengingu, resolvectl status sýnir hvaða tenging svarar nafni, og gestanet sem úthlutar sínum eigin leysi getur látið DNS-ið sem göngin ýta á ónotað þangað til tengingin verður aftur valin. Fangaportal gerir það verra: fyrsta HTTPS-beiðninni svarar portalinn í stað endapunktsins, og biðlarinn skráir dauðan netþjón.

MTU slóðarinnar breytist líka. Ethernet og Wi-Fi flytja venjulega 1500 bæti, PPPoE 1492, og farsímatengingar oft minna. Göng sem erfa minna MTU stöðvast á stórum pakkum á meðan smábeiðnir ganga, sem lesið er sem hálf brotin tenging. ping -M do -s 1472 203.0.113.10 sendir 1500 bæta pakka með DF settu; þögn þýðir að slóðin er minni en þú gerðir ráð fyrir.

IPv6 er hinn helmingurinn. Net sem úthlutar nýju forskeyti breytir upprunanum sem tvístafla biðlari myndi nota, og göng sem eru aðeins v4 láta v6-umferð vera utan við sig þangað til stefnan nær í þau. ip -6 route show default og ip -6 addr show svara hvort nýja tengingin hafi yfirhöfuð v6-slóð.

Endurskapaðu umskiptin í stað þess að lýsa þeim

Veldu eina meinlausa beiðni og keyrðu sömu þrjár skipanir beggja vegna breytingarinnar: ip -br addr, ip route show default, ip route get 203.0.113.10. Fylgstu svo með hvort göngin senda enn pakka - tcpdump -ni any udp port 51820 fyrir WireGuard, samsvarandi port fyrir hvað annað. Pakkar sem fara frá gamla upprunanum þýða bindivandamál. Pakkar frá nýja upprunanum án svars þýða fjarlægu hliðina eða NAT-ið á milli.

Taktu eftir hvaða atburður féll saman við fyrstu bilunina: tenging niður, fangbreyting eða breyting á sjálfgefinni leið. Þau benda á mismunandi eigendur - biðlara sem verður að binda aftur, fang sem verður að afla aftur, eða leið sem tilheyrir stillingaskrá en ekki varanlegri framhjáhlaupareglu.

Áður en þú kallar það lagað skaltu staðfesta að blokkun beinnar umferðar haldi enn á meðan á bilinu stendur og að nöfn leysist í gegnum nýju tenginguna. Ef biðlarinn heldur gamla endapunktinum eftir skiptinguna skaltu laga reiki- eða float-stillinguna fyrst. Ef hann reikir rétt og fær samt ekkert svar skaltu skoða jafningjaauðkenni netþjónsins og NAT-ið á slóðinni, og hafðu bæði netssamhengin með í skrifunum svo næsta manneskja geti borið þau saman.