Doodskakelaar ná ’n oorskakeling van Wi-Fi na selfoon: wat breek

Op een oomblik is die skootrekenaar op kantoor se Wi-Fi, die volgende is dit aan ’n selfoon gekoppel, en die tonnelaanwyser is weer groen voordat jy klaar tussen vensters wissel. ’n Groen liggie sê net dat die tonnel weer verbind het; wat die roetering- en blokkeringsbeleid tydens die onderbreking gedoen het, is ’n ander vraag. Daardie beleid is ’n stel passingsvoorwaardes wat saamgestel is toe dit laas geïnstalleer is, en noem ’n koppelvlak, ’n adres en ’n adresfamilie wat die oorgang pas verwyder het. Dieselfde oorskakeling lewer dus drie uitkomste wat identies lyk: die blokkering hou aan, die beleid blokkeer sy eie herstel, of ’n pad oopgaan wat niks dek nie.

Niks op die skerm onderskei daardie drie toestande nie, so vra eerder aan watter identifiseerders die reëls vasgepen is as watter kleur die aanwyser wys. Op Linux kan ’n reël ’n koppelvlak noem of ’n ipset wat van een gevul word; op Android kan ’n VpnService vertel word watter onderliggende netwerke om te volg deur setUnderlyingNetworks. Elke binding wys na ’n skakel wat binnekort vervang gaan word, en elkeen moet daarna herwaardeer word.

Wat die oorgang werklik herskryf

Wanneer die ou skakel verdwyn, verwyder die kernel sy adresse, trek die roetes terug wat daardeur gewys het en bou die bronadreskeuse weer op uit wat oorbly. Die verstekroete skuif na die nuwe gateway, en die koppelvlakindeks waarna die ou reëls verwys het, is weg of word vir ’n ander toestel hergebruik. Resolvers per skakel word ook verfris, maar nie op dieselfde oomblik as die roetes nie. Dit alles gebeur onder die VPN-kliënt, so ’n kliënt wat net sy eie tonneltoestand dophou, sien niks daarvan nie.

Die probleem is dat ’n reël ’n spesifieke identifiseerder vasvang in plaas van die bedoeling daaragter. ’n Reël wat alles laat val wat nie deur die tonnelkoppelvlak vertrek nie, vang ’n koppelvlaknaam vas; ’n reël wat die eindpunt toelaat, vang ’n adres vas wat die nuwe netwerk dalk elders heen stuur. Wanneer die identifiseerder verdwyn, word die reël nie sigbaar verkeerd nie; dit hou óf op om enigiets te pas óf begin die verkeerde ding pas.

Bou die buitenste tonnel oor sonder om ’n gat te maak

Die buitenste transport was aan die ou bronadres gebind, so dit moet ’n nuwe socket vanaf die nuwe een oopmaak. Wanneer die eindpunt ’n gasheernaam eerder as ’n letterlike adres is, moet ’n opsoektog slaag terwyl die blokkering nog in werking is. Dít is die volgorde-valstrik: ’n beleid wat streng genoeg is om alles behalwe die eindpunt te laat val, sal ook die opsoektog laat val wat nodig is om dit te vind, tensy die oplossing gebeur voordat die blokkering opgelig word of deur ’n tonnel gedra word wat nog leef. Enige van die twee volgordes kan werk, maar net as die kliënt weet in watter volgorde hy is.

Kliënte verskil hier op ’n manier wat saak maak wanneer jy diagnostiseer. Sommige los eers op en installeer daarna die reëls, so ’n oorgang kos ’n sigbare onderbreking en herstel dan vanself; ander hou die blokkering op en maak staat op die tonnel wat oorleef het om die opsoektog te dra, wat heeltemal misluk wanneer die tonnel saam met die skakel dood is. Om ’n breë direkte verstek by te voeg om konnektiwiteit te herstel, laat die toets altyd slaag en laat altyd die lek wat jy wou verhoed.

’n Roete wat nog na die ou gateway wys, gee dieselfde vasgehaakte herstel uit ’n ander oorsaak, so lees die tabel voordat jy die kliënt blameer. Die opdragte hieronder noem die koppelvlak en bronadres wat die kernel werklik sou gebruik, wat in een reël beslis of die ou pad nog geïnstalleer is.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Wanneer die nuwe skakel IPv6 bring en die reëls nie

Selulêre en gasnetwerke deel dikwels ’n globale IPv6-voorvoegsel uit, selfs wanneer die kantoor se bedrade LAN dit nooit gedoen het nie. ’n Beleid wat net as IPv4-reëls geskryf is — die verstekvorm van die meeste selfgemaakte iptables- en nftables-resepte — dek niks daarvan nie. Die tonnel bly verbind, programme met IPv6-bereikbaarheid verlaat dit buite, en die aanwyser kan nie die verskil wys nie want die tonnel is regtig op. Die spieëlgeval is net so algemeen: ’n stel reëls wat net vir IPv6 is, doen heeltemal niks op ’n netwerk wat geen v6 bied nie.

Vergelyk wat die skakel bied met wat die beleid noem, aan beide kante van die oorgang. Hierdie opdragte druk dieselfde feite as waarmee die kliënt werk:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

As die tweede opdrag ’n verstekroete druk terwyl die derde nul teruggee, kan die nuwe skakel die masjien oor IPv6 verlaat sonder dat enige reël daarop let. Hardloop al drie weer ná die oorskakeling, want die interessante syfer is die verskil tussen die twee lopies. As die tweede niks druk nie, geld die omgekeerde geval, en enige v6-swaar beleid is daar bloot versiering.

Die resolver wissel van hande midde-in die sessie

Resolvers is op moderne stelsels aan skakels gekoppel, so ’n nuwe skakel kom met ’n nuwe resolver-stel en moontlik ’n ander split-DNS-aansig. systemd-resolved hou ’n scope per skakel en kies tussen hulle op grond van die roete, terwyl macOS geskoopte resolvers uit die dinamiese stoor lees en koppelvlakorde respekteer. ’n Kliënt wat sy eie resolver installeer, ding mee met dié van die skakel, en prioriteitsreëls waarna niemand kyk nie, beslis die wenner. Naamoplossing kan dan breek terwyl pakkiefiltering presies doen waarvoor dit geskryf is.

Lees die resolver wat aktief is eerder as dié wat opgestel is. Op ’n systemd-gasheer wys die status-subopdrag van watter skakel elke scope kom en of ’n private-DNS-naam van krag is:

resolvectl status --no-pager
resolvectl query intranet.example.com

As die navraag deur die fisiese skakel eerder as die tonnel vertrek, het die kliënt die prioriteitswedstryd verloor en geen firewall-aanpassing sal naamgewing regmaak nie. Vergelyk die navraagpad aan beide kante van die oorgang om te sien watter een geskuif het. ’n Naam wat na ’n private adres oplos wat die nuwe netwerk nie kan roeteer nie, is ’n derde geval, en dit wys as ’n tydsverloop eerder as ’n fout.

Oefen die oorgang en hou die rekord

Herhaal die verandering doelbewus in plaas daarvan om daarvoor te wag. Bring die tonnel op die eerste skakel op, begin ’n langdurige oordrag en ’n herhaalde opsoektog, wissel dan die skakel en kyk watter een oorleef. Let op die tussenpose tussen die verdwyning van die ou skakel en die tonnel se rapportering dat dit verbind is, want daardie venster is waar die beleid óf gehou het óf nie. Voer die reeks ook in die ander rigting uit, sodat die resultaat nie eensydig is nie.

Uitsonderings het hul eie deurloop nodig, want ’n omseiling wat op die ou netwerk geregverdig was, is nie outomaties op die nuwe een geregverdig nie. ’n Drukker, ’n NAS of ’n captive portal op die tuis-LAN het geen eweknie op sellulêr nie, en die uitsondering wat dit bereik het, word ’n reël sonder ’n eweknie.

Skryf die koppelvlakname, die families wat gebied word, die resolver wat van krag is en die lengte van die onderbreking vir elke rigting neer. ’n Herverbinding bewys dat die transport herstel het, nie dat die blokkering tydens die onderbreking gehou het nie, en dit is aparte bewerings om in ’n kaartjie te sit. Met daardie rekord word die volgende oorgang teen ’n bekende toestand vergelyk in plaas van teen die geheue.