Rofrofi eftir skipti úr Wi-Fi yfir á farsímanet: hvað brotnar

Eitt augnablik er fartölvan á Wi-Fi skrifstofunnar, það næsta er hún tengd síma, og vísir göngunnar er orðinn grænn aftur áður en þú klárar að skipta um glugga. Grænt ljós segir aðeins að gangurinn hafi tengst aftur; hvað beitingar- og lokunarstefnan gerði á meðan á bilinu stóð er önnur spurning. Sú stefna er safn samsvörunarskilyrða sem voru þýdd þegar hún var síðast sett upp, og nefnir tengiviðmót, vistfang og vistfangafjölskyldu sem yfirfærslan hefur rétt verið að fjarlægja. Sama skiptin skila því þremur niðurstöðum sem líta eins út: lokunin heldur áfram, stefnan lokar fyrir eigin endurheimt, eða leið opnast sem ekkert hylur.

Ekkert á skjánum greinir þessi þrjú ástand, svo spurðu hvaða auðkennum reglurnar voru festar við frekar en hvaða lit vísirinn sýnir. Á Linux getur regla nefnt tengiviðmót eða ipset sem fyllt er úr því; á Android er hægt að segja VpnService hvaða undirliggjandi netum eigi að fylgja með setUnderlyingNetworks. Hver binding bendir á tengil sem er um það bil að verða skipt út, og hverja þarf að meta aftur á eftir.

Hvað yfirfærslan endurskrifar í raun

Þegar gamli tengillinn hverfur fjarlægir kjarninn vistföng hans, dregur til baka leiðirnar sem lágu í gegnum hann og byggir upp val á upprunavistfangi úr því sem eftir er. Sjálfgefna leiðin færist á nýju gáttina, og tengiviðmótsvísirinn sem gömlu reglurnar vísuðu í er farinn eða endurnýttur fyrir annað tæki. Leysar á hverjum tengli eru líka uppfærðir, þótt ekki á sama augnabliki og leiðirnar. Allt þetta gerist fyrir neðan VPN-biðlarann, svo biðlari sem fylgist aðeins með ástandi eigin göngu sér ekkert af því.

Vandinn er sá að regla kóðar tiltekið auðkenni í stað ætlunarinnar sem liggur að baki. Regla sem sleppir öllu sem fer ekki út um tengiviðmót gangunnar kóðar tengiviðmótsheiti; regla sem leyfir endapunktinn kóðar vistfang sem nýja netið gæti beint annað. Þegar auðkennið hverfur verður reglan ekki sýnilega röng: hún hættir annaðhvort að passa við hvað sem er eða byrjar að passa við rangt fyrirbæri.

Endurbyggja ytri gönguna án þess að bora gat

Ytri flutningurinn var bundinn við gamla upprunavistfangið, svo hann verður að opna nýja sokk frá hinu nýja. Þegar endapunkturinn er hýsilnafn en ekki bókstaflegt vistfang verður uppfletting að takast meðan lokunin er enn í gildi. Þetta er röðargildran: stefna sem er nógu ströng til að sleppa öllu nema endapunktinum sleppir líka uppflettingunni sem þarf til að finna hann, nema leysingin eigi sér stað áður en lokunin er lyft eða sé borin í gegnum göngu sem er enn á lífi. Báðar raðir geta virkað, en aðeins ef biðlarinn veit í hvorri hann er.

Biðlarar eru ólíkir hér á þann hátt sem skiptir máli við greiningu. Sumir leysa fyrst og setja reglurnar upp á eftir, svo yfirfærsla kostar sýnilegt niðurfall og jafnar sig svo sjálf; aðrir halda lokuninni uppi og treysta á gönguna sem lifir af til að bera uppflettinguna, sem mistekst algjörlega þegar gangan dó með tenglinum. Að bæta við breiðri beinni sjálfgefinni leið til að endurheimta tengingu lætur prófið alltaf standast og skilur alltaf eftir lekan sem þú varst að koma í veg fyrir.

Leið sem bendir enn á gömlu gáttina gefur sama fasta endurheimt vegna annarrar orsakar, svo lestu töfluna áður en þú kennir biðlaranum um. Skipanirnar hér fyrir neðan nefna tengiviðmótið og upprunavistfangið sem kjarninn myndi raunverulega nota, og það ræður í einni línu hvort gamla leiðin sé enn uppsett.

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

Þegar nýi tengillinn kemur með IPv6 en reglurnar ekki

Farsíma- og gestanet úthluta oft alþjóðlegu IPv6 forskeyti jafnvel þótt snúruð LAN skrifstofunnar hafi aldrei gert það. Stefna sem er skrifuð eingöngu sem IPv4-reglur, venjulegt form flestra handgerðra iptables- og nftables-uppskrifta, hylur ekkert af því. Gangurinn helst tengdur, forrit með IPv6-nálg má fara út fyrir hann, og vísirinn getur ekki sýnt muninn því gangurinn er virkilega uppi. Spegilmyndin er jafn algeng: reglusett eingöngu fyrir IPv6 gerir ekkert á neti sem býður ekki v6.

Berðu saman það sem tengillinn býður og það sem stefnan nefnir, á báðum hliðum yfirfærslunnar. Þessar skipanir prenta sömu staðreyndir og biðlarinn vinnur með:

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

Ef önnur skipunin prentar sjálfgefna leið á meðan sú þriðja skilar núlli getur nýi tengillinn leitt vélina út um IPv6 án þess að nokkur regla gæti hennar. Keyrðu allar þrjár aftur eftir skiptin, því áhugaverða talan er munurinn á keyrslunum tveimur. Ef önnur prentar ekkert gildir öfuga tilfellið og hvaða v6-þunga stefna sem er þar er bara skraut.

Leysirinn skiptir um hendur um miðja lotu

Á nútíma kerfum eru leysar tengdir tenglum, svo nýr tengill kemur með nýju leysasetti og ef til vill annarri split-DNS sýn. systemd-resolved heldur einu sviði á hvern tengil og velur á milli þeirra eftir leið, en macOS les sviðssettar leysa úr kviku geymslunni og virðir röð tengiviðmóta. Biðlari sem setur upp sinn eigin leysi keppir við leysi tengilsins, og forgangsreglur sem enginn fylgist með ákveða sigurvegara. Þá getur nafnaleysing brotnað á meðan pakkasíun gerir nákvæmlega það sem hún var skrifuð fyrir.

Lestu leysinn sem er virkur en ekki þann sem er stilltur. Á systemd-hýsli sýnir undirskipunin status frá hvaða tengli hvert svið kom og hvort private-DNS nafn sé í gildi:

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

Ef fyrirspurnin fer út um líkamlega tengilinn en ekki gönguna tapaði biðlarinn forgangskeppninni og engin eldveggsstilling lagar nafngiftina. Berðu saman leið fyrirspurnarinnar á báðum hliðum yfirfærslunnar til að sjá hvor færðist. Nafn sem leysist í einkavistfang sem nýja netið getur ekki beint er þriðja tilfellið, og það birtist sem tímamörk en ekki villa.

Æfðu yfirfærsluna og geymdu skráninguna

Endurgerðu breytinguna viljandi í stað þess að bíða eftir henni. Reistu gönguna á fyrsta tenglinum, byrjaðu langa flutning og endurtekna uppflettingu, skiptu svo um tengil og fylgstu með hvor lifir. Skráðu bilið milli þess að gamli tengillinn hverfur og tilkynningar gangunnar um tengingu, því í þeim glugga stóðst stefnan eða stóðst ekki. Keyrðu röðina líka í hina áttina, svo niðurstaðan sé ekki einhliða.

Undantekningar þurfa sína eigin umferð, því rás sem var réttlætanleg á gamla netinu er ekki sjálfkrafa réttlætanleg á því nýja. Prentari, NAS eða captive portal á heimilis-LAN hefur ekki hliðstæðu í farsímanetinu, og undantekningin sem náði til þeirra verður regla án hliðstæðu.

Skráðu tengiviðmótsheitin, fjölskyldurnar sem eru boðnar, gildandi leysi og lengd niðurfallsins fyrir hverja átt. Endurtenging sannar að flutningurinn kom sig, ekki að lokunin hafi staðist á bilinu, og það eru aðskildar fullyrðingar fyrir mál. Með þeirri skráningu er næsta yfirfærsla borin saman við þekkt ástand í stað minnis.