Pam mae eich VPN yn cwympo pan fydd Wi-Fi yn newid neu Ethernet yn cael ei blygio i mewn

Adroddir dau beth fel un methiant: mae’r gliniadur wedi symud i rwydwaith Wi-Fi arall, neu mae cebl wedi’i blygio i mewn tra bo Wi-Fi yn dal i godi. Mae’r cleient yn dal i ddweud ei fod wedi cysylltu, mae’r eicon yn edrych yn iach, ac nid yw’r twnnel yn cario dim. O dan yr wyneb, dim ond tri darn o gyflwr all symud - y cyswllt, y cyfeiriad lleol, y llwybr diofyn - a’r un a symudodd sy’n penderfynu a yw’r twnnel yn adfer ei hun neu angen ailgysylltu. Rwy’n eu gwirio yn y drefn honno, oherwydd nid yw newid gosodiadau cyfrif erioed wedi trwsio’r un ohonynt.

Mae cyswllt, cyfeiriad a llwybr yn symud yn annibynnol

Mae crwydro rhwng pwyntiau mynediad ar yr un rhwydwaith fel arfer yn ddigwyddiad L2. Mae’r radio’n ailgysylltu, mae’r rhyngwyneb yn cadw ei gyfeiriad a’i giât, ac nid oes dim y mae’r twnnel yn dibynnu arno yn newid, a dyna pam mae cerdded ar draws swyddfa fawr weithiau’n mynd heb ei sylwi. Nid yw ymuno â SSID gwahanol yr un peth: gall yr hen ryngwyneb fynd i lawr, mae DHCP yn rhoi cyfeiriad newydd, giât newydd a datryswyr newydd, ac mae’r llif allanol yr oedd y twnnel yn ei ddefnyddio yn peidio â bodoli.

Mae Ethernet yn ychwanegu trydydd siâp. Nid yw Wi-Fi byth yn cwympo, felly nid oes digwyddiad cyswllt yn tanio o gwbl, ond mae’r rhyngwyneb â gwifren yn ymddangos gyda’i gyfeiriad ei hun ac yn aml yn ennill y llwybr diofyn ar fetrig. Mae’r twnnel yn parhau i redeg dros lwybr nad yw’n well bellach, neu mae’r cleient yn cadw ei soced wedi’i binio i’r rhwydwaith di-wifr y dechreuodd arno. O’r porwr mae’r ddau’n edrych yr un fath: mae tudalennau’n oedi’r eiliad y bydd y cebl yn clicio.

Felly nid y cwestiwn cyntaf yw a newidiodd Wi-Fi. Y cwestiwn yw a newidiodd y cyfeiriad rydych wedi’ch rhwymo iddo, neu’r llwybr i’r pen draw, tra oedd y twnnel i fyny.

Mae’r soced allanol wedi’i binio i gyfeiriad sydd newydd ddiflannu

Mae pob twnnel yn llif allanol: cyfeiriad a phorth lleol yn siarad â chyfeiriad a phorth y gweinydd. Ar Linux soced UDP yw hwnnw wedi’i rwymo i’r hen ffynhonnell; pan fydd y rhyngwyneb sy’n dal y cyfeiriad yn cael ei symud, mae anfoniadau naill ai’n methu ag EADDRNOTAVAIL neu’n gadael trwy’r rhyngwyneb newydd gyda ffynhonnell nad yw’r gweinydd wedi’i gweld erioed.

Mae’r ochr bell yn cadw ei phin ei hun. Mae SA IKEv2 heb MOBIKE yn cael ei adnabod gan y pâr cyfeiriadau, ac mae OpenVPN sesiwn wedi’i chlymu i gyfeiriad y cymar a ddysgodd, ac mae mapiad NAT yn perthyn i’r cyfeiriad preifat, y porth a’r cyfeiriad cyhoeddus a’i creodd. Symudwch y tu ôl i NAT gwahanol ac mae pob ateb yn cael ei anfon i fapiad nad yw’n bodoli mwyach. Nid oes dim o’i le ar eich peiriant; mae’r pum-twr yn pwyntio at rwydwaith y gwnaethoch ei gadael.

Darllenwch y cyflwr cyn damcaniaethu:

• ss -unp yn dangos y cyfeiriad a’r porth lleol y mae pob soced twnnel yn eu dal mewn gwirionedd.
• ip route get 203.0.113.10 yn argraffu’r cyfeiriad ffynhonnell a’r ddyfais y byddai’r cnewyllyn yn eu defnyddio ar gyfer y pen draw ar hyn o bryd.
• wg show wg0 endpoints, swanctl --list-sas neu mae log y cleient yn dangos cyfeiriad y cymar y mae’r ochr bell yn credu ei fod yn siarad ag ef.

Os yw cyfeiriad y soced a’r chwiliad llwybr yn anghytuno, rydych wedi dod o hyd i’r toriad, ac ni fydd unrhyw newid i gymwysterau yn ei gyffwrdd.

Beth mae pob protocol yn ei wneud â chyfeiriad ffynhonnell newydd

Mae cleientiaid yn amsugno’r newid i wahanol raddau, a’r tabl yw’r peth rwy’n ei gymharu â chyfluniad y cleient yn lle dyfalu o’r ymddygiad ailgysylltu.

Nid yw rheol grwydro WireGuard yn gweithio ond i un cyfeiriad: rhaid i’r cleient anfon o’r cyfeiriad newydd yn gyntaf. Nid yw soced sydd wedi’i rwymo i’r hen ryngwyneb byth yn gwneud hynny, a dyna pam y gall twnnel edrych yn fyw tra bo ei amserydd ysgwyd llaw yn heneiddio. disgrifiad y protocol yn nodi’r amod diweddaru pen draw yn fanwl, ac mae’n werth ei ddarllen cyn newid unrhyw gyfluniad.

Mae MOBIKE yn cael ei drafod, nid ei dybio. Os na fydd y gweinydd yn ei gynnig, rhaid i’r cleient ailsefydlu, ac mae hynny’n ffaith rydych yn ei chadarnhau o’r rhestr SA neu’r log yn hytrach na’i chasglu o olwyn sy’n troi.

Mae ffafriaeth llwybr yn penderfynu’r llwybr, nid eicon Wi-Fi

Gyda’r ddau ryngwyneb i fyny, mae’r cnewyllyn yn dewis yn ôl metrig a hyd y rhagddodiad. ip route show default yn rhestru’r ymgeiswyr a ip route get 203.0.113.10 yn datrys y penderfyniad go iawn, gan gynnwys y cyfeiriad ffynhonnell. Mae llwybr diofyn â gwifren ar fetrig 100 a llwybr di-wifr ar 600 yn golygu bod y pen draw yn symud yr eiliad y bydd y cebl yn eistedd, tra bo pob rhaglen a agorodd soced yn gynharach yn cadw ei hen ffynhonnell.

Mae Windows yn gwneud yr un peth â metrigau rhyngwyneb awtomatig, wedi’u tueddu gan gyflymder y cyswllt. Get-NetRoute -DestinationPrefix 0.0.0.0/0 yn trefnu’r ymgeiswyr a Find-NetRoute -RemoteIPAddress 203.0.113.10 yn dychwelyd y rhyngwyneb a’r ffynhonnell y byddai’r stac yn eu dewis. Mae cleient sy’n rhwymo ei soced allanol i un rhyngwyneb yn parhau i’w ddefnyddio ar ôl i’r metrig droi; penderfyniad rhwymo yw hwnnw, nid nam llwybro.

Mae Android yn gwneud y rhaniad yn weladwy: mae ConnectivityManager yn adrodd y rhwydweithiau sydd ar gael ac un diofyn ar wahân, ac mae rhaglen VPN sy’n rhwymo soced i wrthrych Network yn cadw’r rhwymiad hwnnw nes iddi ail-rywmo. Ar macOS, scutil --nwi yn argraffu’r prif ryngwyneb a’r drefn y byddai’r system yn ei defnyddio.

Mae DNS, MTU ac IPv6 yn symud gyda’r atodiad

Mae atodiad newydd yn dod â datryswyr newydd. Gyda systemd-resolved mae DNS fesul cyswllt, resolvectl status yn dangos pa gyswllt sy’n ateb enw, a gall rhwydwaith gwestai sy’n dosbarthu ei ddatryswr ei hun adael y DNS a wthiwyd gan y twnnel yn ddiarffordd nes bod y cyswllt yn cael ei ffafrio eto. Mae portal caeth yn gwaethygu pethau: y portal sy’n ateb y cais HTTPS cyntaf yn hytrach na’r pen draw, ac mae’r cleient yn cofnodi gweinydd marw.

Mae MTU’r llwybr yn newid hefyd. Mae Ethernet a Wi-Fi fel arfer yn cario 1500 o feitiau, PPPoE 1492, a chysylltiadau symudol yn aml yn llai. Mae twnnel sy’n etifeddu MTU llai yn oedi ar becynnau mawr tra bo ceisiadau bach yn llwyddo, ac mae hynny’n darllen fel cysylltiad sydd wedi torri’n rhannol. ping -M do -s 1472 203.0.113.10 yn anfon pecyn 1500 beit gyda DF wedi’i osod; mae distawrwydd yn golygu bod y llwybr yn llai nag y tybiwyd gennych.

IPv6 yw’r hanner arall. Mae rhwydwaith sy’n dosbarthu rhagddodiad newydd yn newid y ffynhonnell y byddai cleient deu-stac yn ei defnyddio, ac mae twnnel v4 yn unig yn gadael traffig v6 y tu allan iddo nes i’r polisi ddal i fyny. ip -6 route show default a ip -6 addr show yn ateb a oes gan y cyswllt newydd lwybr v6 o gwbl.

Atgynhyrchwch y newid yn lle ei ddisgrifio

Dewiswch un cais diniwed a rhedwch yr un tri gorchymyn ar ddwy ochr y newid: ip -br addr, ip route show default, ip route get 203.0.113.10. Yna gwyliwch a yw’r twnnel yn dal i ollwng pecynnau - tcpdump -ni any udp port 51820 ar gyfer WireGuard, y porth cyfatebol ar gyfer unrhyw beth arall. Mae pecynnau’n gadael o’r hen ffynhonnell yn golygu problem rhwymo. Mae pecynnau’n gadael o’r ffynhonnell newydd heb ateb yn golygu’r ochr bell neu’r NAT yn y canol.

Nodwch pa ddigwyddiad a gyd-ddigwyddodd â’r methiant cyntaf: cyswllt i lawr, newid cyfeiriad, neu newid llwybr diofyn. Mae’r rhain yn pwyntio at berchnogion gwahanol - cleient y mae’n rhaid iddo ail-rywmo, cyfeiriad y mae’n rhaid ei ail-gyrchu, neu lwybr sy’n perthyn i ffeil gyfluniad ac nid i reol osgoi barhaol.

Cyn ei alw’n drwsiad, cadarnhewch fod bloc y traffig uniongyrchol yn dal yn ystod y bwlch a bod enwau’n datrys trwy’r atodiad newydd. Os yw’r cleient yn cadw’r hen ben draw ar ôl y newid, trwsiwch osodiad crwydro neu float yn gyntaf. Os yw’n crwydro’n gywir ac yn dal heb ateb, edrychwch ar hunaniaeth cymar y gweinydd a’r NAT ar y llwybr, a chadwch y ddau gyd-destun rhwydwaith yn yr ysgrif fel y gall y person nesaf eu cymharu.