Hoekom jou VPN val wanneer Wi-Fi verander of Ethernet ingeprop word

Twee dinge word as een fout aangemeld: die skootrekenaar het na ’n ander Wi-Fi-netwerk geskuif, of ’n kabel is ingeprop terwyl Wi-Fi aan die gang gebly het. Die kliënt sê steeds verbind, die ikoon lyk gesond, en die tonnel dra niks. Onder die oppervlak kan net drie stukke toestand beweeg - die skakel, die plaaslike adres, die verstekroete - en watter een beweeg het, bepaal of die tonnel vanself herstel of ’n herverbinding nodig het. Ek kyk in daardie volgorde daarna, want die verandering van rekeninginstellings het nog nooit enige van hulle reggemaak nie.

Skakel, adres en roete beweeg onafhanklik

Swerm tussen toegangspunte op dieselfde netwerk is gewoonlik ’n L2-gebeurtenis. Die radio herassosieer, die koppelvlak hou sy adres en gateway, en niks waarvan die tonnel afhanklik is verander nie, en daarom gaan ’n wandeling deur ’n groot kantoor soms ongemerk verby. Om by ’n ander SSID aan te sluit is nie dieselfde nie: die ou koppelvlak kan afgaan, DHCP deel ’n nuwe adres, ’n nuwe gateway en nuwe oplossers uit, en die buitenste vloei wat die tonnel gebruik het, hou op bestaan.

Ethernet voeg ’n derde vorm by. Wi-Fi val nooit uit nie, dus vuur geen skakelgebeurtenis nie, tog verskyn die bedrade koppelvlak met sy eie adres en wen dikwels die verstekroete op metriek. Die tonnel hou aan loop oor ’n pad wat nie meer verkies word nie, of die kliënt hou sy socket vasgepen aan die draadlose netwerk waarop dit begin het. Beide lyk dieselfde in die blaaier: bladsye stol die oomblik wanneer die kabel klik.

Die eerste vraag is dus nie of Wi-Fi verander het nie. Dit is of die adres waaraan jy gebind is, of die roete na die eindpunt, verander het terwyl die tonnel aan die gang was.

Die buitenste socket is vasgepen aan ’n adres wat pas verdwyn het

Elke tonnel is ’n buitenste vloei: ’n plaaslike adres en poort wat met die bediener se adres en poort praat. Op Linux is dit ’n UDP-socket wat aan die ou bron gebind is; wanneer die koppelvlak wat die adres hou verwyder word, misluk stuur óf met EADDRNOTAVAIL óf dit verlaat deur die nuwe koppelvlak met ’n bron wat die bediener nog nooit gesien het nie.

Die verre kant hou sy eie pen. ’n IKEv2-SA sonder MOBIKE word deur die adrespaar geïdentifiseer, en ’n OpenVPN-sessie is gebind aan die eweknie-adres wat dit geleer het, en ’n NAT-kaart behoort aan die private adres, poort en openbare adres wat dit geskep het. Skuif agter ’n ander NAT en elke antwoord word na ’n kaart gestuur wat nie meer bestaan nie. Niks op jou masjien is verkeerd opgestel nie; die vyf-tupel wys na ’n netwerk wat jy verlaat het.

Lees die toestand voordat jy teoretiseer:

• ss -unp wys die plaaslike adres en poort wat elke tonnel-socket werklik hou.
• ip route get 203.0.113.10 druk die bronadres en toestel wat die kernel nou vir die eindpunt sou gebruik.
• wg show wg0 endpoints, swanctl --list-sas of die kliëntlog wys die eweknie-adres waarvan die verre kant dink hy praat.

As die socket-adres en die roete-opsoek nie ooreenstem nie, het jy die breuk gevind, en geen verandering aan geloofsbriewe sal dit raak nie.

Wat elke protokol met ’n nuwe bronadres doen

Kliënte absorbeer die verandering in verskillende mate, en die tabel is waarmee ek die kliëntkonfigurasie vergelyk in plaas daarvan om uit die herverbindingsgedrag te raai.

WireGuard se swerm-reël werk net in een rigting: die kliënt moet eerste vanaf die nuwe adres stuur. ’n Socket wat nog aan die ou koppelvlak gebind is, doen dit nooit, en daarom kan ’n tonnel opkyk terwyl sy handskud-timer aanhou verouder. Die protokolbeskrywing stel die voorwaarde vir die bywerking van die eindpunt presies, en dit is die moeite werd om dit te lees voordat jy ’n konfigurasie verander.

MOBIKE word beding, nie aangeneem nie. As die bediener dit nie bied nie, moet die kliënt weer opstel, en dit is ’n feit wat jy uit die SA-lys of die log bevestig eerder as om dit uit ’n spinner af te lei.

Roetevoorkeur bepaal die pad, nie die Wi-Fi-ikoon nie

Met albei koppelvlakke op kies die kernel volgens metriek en voorvoegsellengte. ip route show default lys die kandidate en ip route get 203.0.113.10 los die werklike besluit op, insluitend die bronadres. ’n Bedrade verstek op metriek 100 en ’n draadlose een op 600 beteken die eindpunt skuif die oomblik wanneer die kabel sit, terwyl elke toepassing wat vroeër ’n socket oopgemaak het, sy ou bron hou.

Windows doen dieselfde met outomatiese koppelvlak-metrieke, bevooroordeel deur skakelspoed. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sorteer die kandidate en Find-NetRoute -RemoteIPAddress 203.0.113.10 gee die koppelvlak en bron terug wat die stapel sou kies. ’n Kliënt wat sy buitenste socket aan een koppelvlak bind, hou aan om dit te gebruik nadat die metriek omgeswaai het; dit is ’n bindingsbesluit, nie ’n roetefout nie.

Android maak die skeiding sigbaar: ConnectivityManager rapporteer beskikbare netwerke en ’n aparte verstek, en ’n VPN-program wat ’n socket aan ’n Network-objek bind, hou daardie binding totdat dit weer bind. Op macOS, scutil --nwi druk die primêre koppelvlak en die volgorde wat die stelsel sou gebruik.

DNS, MTU en IPv6 beweeg saam met die aansluiting

’n Nuwe aansluiting bring nuwe oplossers. Met systemd-resolved is DNS per-skakel, resolvectl status wys watter skakel ’n naam antwoord, en ’n gasnetwerk wat sy eie oplosser uitdeel, kan die tonnel se gestuurde DNS ongebruik laat totdat die skakel weer voorkeur kry. ’n Vasgevangde portaal maak dit erger: die eerste HTTPS-versoek word deur die portaal antwoord eerder as die eindpunt, en die kliënt teken ’n dooie bediener aan.

Pad-MTU verander ook. Ethernet en Wi-Fi dra gewoonlik 1500 grepe, PPPoE 1492, en mobiele skakels dikwels minder. ’n Tonnel wat ’n kleiner MTU erf, stol op groot pakkette terwyl klein versoeke slaag, wat as ’n halfgebroke verbinding lees. ping -M do -s 1472 203.0.113.10 stuur ’n pakket van 1500 grepe met DF gestel; stilte beteken die pad is kleiner as wat jy aanvaar het.

IPv6 is die ander helfte. ’n Netwerk wat ’n nuwe voorvoegsel uitdeel, verander die bron wat ’n dual-stack-kliënt sou gebruik, en ’n slegs-v4-tonnel laat v6-verkeer buite dit totdat beleid bykom. ip -6 route show default en ip -6 addr show antwoord of die nuwe skakel hoegenaamd ’n v6-pad het.

Reproduseer die oorgang eerder as om dit te beskryf

Kies een onskadelike versoek en hardloop dieselfde drie opdragte weerskante van die verandering: ip -br addr, ip route show default, ip route get 203.0.113.10. Kyk dan of die tonnel nog pakkette uitstuur - tcpdump -ni any udp port 51820 vir WireGuard, die ooreenstemmende poort vir enigiets anders. Pakkette wat van die ou bron vertrek, beteken ’n bindingsprobleem. Pakkette wat van die nuwe bron vertrek sonder antwoord, beteken die verre kant of die NAT tussenin.

Let op watter gebeurtenis met die eerste fout saamgeval het: skakel af, adresverandering, of verandering van die verstekroete. Dit wys na verskillende eienaars - ’n kliënt wat weer moet bind, ’n adres wat weer verkry moet word, of ’n roete wat aan ’n konfigurasielêer behoort en nie aan ’n permanente omseilreël nie.

Voordat jy dit reg noem, bevestig dat die blok vir direkte verkeer steeds tydens die gaping hou en dat name deur die nuwe aansluiting opgelos word. As die kliënt die ou eindpunt ná die omskakeling hou, maak eers die swerm- of float-instelling reg. As dit korrek swerm en steeds geen antwoord kry nie, kyk na die bediener se eweknie-identiteit en die NAT op die pad, en hou albei netwerkkontekste in die verslag sodat die volgende persoon hulle kan vergelyk.