Mortŝaltilo post transiro de Wi-Fi al la poŝa reto: kio rompiĝas

Unu momenton la tekokomputilo estas en la oficeja Wi-Fi, la sekvan ĝi estas konektita al telefono, kaj la tunela indikilo denove verdas antaŭ ol vi finas ŝanĝi fenestrojn. Verda lumo nur raportas, ke la tunelo rekonektiĝis; kion la enkursiga kaj bloka politiko faris dum la breĉo estas alia demando. Tiu politiko estas aro da kongruaj kondiĉoj kompilitaj kiam ĝi estis laste instalita, kaj ĝi nomas interfacon, adreson kaj adresfamilion, kiujn la transiro ĵus forigis. La sama ŝanĝo do produktas tri rezultojn, kiuj aspektas identaj: la blokado daŭras, la politiko blokas sian propran restaŭradon, aŭ malfermiĝas vojo, kiun nenio kovras.

Nenio sur la ekrano apartigas tiujn tri statojn, do demandu al kiuj identigiloj la reguloj estis fiksitaj anstataŭ kian koloron la indikilo montras. En Linux regulo povas nomi interfacon aŭ ipset plenigitan de ĝi; en Android oni povas diri al VpnService, kiujn subajn retojn sekvi per setUnderlyingNetworks. Ĉiu ligo montras al ligilo, kiu estas anstataŭigota, kaj ĉiu devas esti reevaluita poste.

Kion la transiro efektive reskribas

Kiam la malnova ligilo malaperas, la kerno forigas ĝiajn adresojn, retiras la vojojn, kiuj iris tra ĝi, kaj rekonstruas la elekton de fontadreso el tio, kio restas. La implicita vojo moviĝas al la nova enirejo, kaj la interfaca indekso, al kiu la malnovaj reguloj referencis, estas for aŭ reuzita por alia aparato. Solviloj por ĉiu ligilo ankaŭ refreŝiĝas, kvankam ne en la sama momento kiel la vojoj. Ĉio ĉi okazas sub la VPN-kliento, do kliento, kiu observas nur sian propran tunelan staton, vidas nenion el tio.

La problemo estas, ke regulo kodas specifan identigilon anstataŭ la intencon malantaŭ ĝi. Regulo, kiu forĵetas ĉion, kio ne eliras tra la tunela interfaco, kodas interfacan nomon; regulo, kiu permesas la finpunkton, kodas adreson, kiun la nova reto povas enkursigi aliloken. Kiam la identigilo malaperas, la regulo ne fariĝas videble malĝusta: ĝi aŭ ĉesas kongrui kun io ajn aŭ komencas kongrui kun la malĝusta afero.

Rekonstrui la eksteran tunelon sen bori truon

La ekstera transporto estis ligita al la malnova fontadreso, do ĝi devas malfermi novan soketon el la nova. Kiam la finpunkto estas gastigantnomo anstataŭ laŭlitera adreso, serĉo devas sukcesi dum la blokado ankoraŭ validas. Tio estas la kaptilo de la ordo: politiko sufiĉe strikta por forĵeti ĉion krom la finpunkto ankaŭ forĵetos la serĉon necesan por trovi ĝin, krom se la solvado okazas antaŭ ol levi la blokadon aŭ estas portata tra tunelo, kiu ankoraŭ vivas. Ambaŭ ordoj povas funkcii, sed nur se la kliento scias, en kiu ĝi estas.

Klientoj diferencas ĉi tie laŭ maniero, kiu gravas dum diagnozado. Iuj unue solvas kaj poste instalas la regulojn, do transiro kostas videblan interrompon kaj poste mem resaniĝas; aliaj tenas la blokadon kaj dependas de la postvivinta tunelo por porti la serĉon, kio tute malsukcesas kiam la tunelo mortis kun la ligilo. Aldoni larĝan rektan implicitan vojon por restarigi konektecon ĉiam igas la teston sukcesi kaj ĉiam lasas la likon, kiun vi malhelpis.

Vojo ankoraŭ montranta al la malnova enirejo donas la saman ŝtopitan restaŭron el alia kaŭzo, do legu la tabelon antaŭ ol kulpigi la klienton. La subaj komandoj nomas la interfacon kaj fontadreson, kiujn la kerno vere uzus, kaj tio decidas en unu linio, ĉu la malnova vojo ankoraŭ estas instalita.

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

Kiam la nova ligilo alportas IPv6 kaj la reguloj ne

Poŝaj kaj gastaj retoj ofte disdonas tutmondan IPv6-prefikson eĉ kiam la kabla LAN de la oficejo neniam faris tion. Politiko skribita nur kiel IPv4-reguloj, la implicita formo de la plej multaj permane faritaj iptables- kaj nftables-receptoj, kovras nenion el tio. La tunelo restas konektita, aplikaĵoj kun IPv6-atingebleco eliras eksteren, kaj la indikilo ne povas montri la diferencon, ĉar la tunelo vere estas supren. La spegula kazo estas same kutima: regularo nur por IPv6 faras nenion en reto, kiu ne ofertas v6.

Komparu, kion la ligilo ofertas, kun tio, kion la politiko mencias, ambaŭflanke de la transiro. Ĉi tiuj komandoj printas la samajn faktojn, kun kiuj la kliento laboras:

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

Se la dua komando printas implicitan vojon dum la tria redonas nulon, la nova ligilo povas elkonduki la maŝinon tra IPv6 sen ke iu ajn regulo observas ĝin. Rerunu ĉiujn tri post la ŝanĝo, ĉar la interesa nombro estas la diferenco inter la du runoj. Se la dua printas nenion, validas la inversa kazo kaj ajna v6-peza politiko tie estas nur ornamo.

La solvilo ŝanĝas manojn meze de la sesio

En modernaj sistemoj solviloj estas alligitaj al ligiloj, do nova ligilo alvenas kun nova solvilaro kaj eble kun alia split-DNS-vido. systemd-resolved tenas unu skopon por ligilo kaj elektas inter ili laŭ vojo, dum macOS legas skopajn solvilojn el la dinamika stokejo kaj respektas la ordon de interfacoj. Kliento, kiu instalas sian propran solvilon, konkurras kun tiu de la ligilo, kaj prioritataj reguloj, kiujn neniu observas, decidas la venkinton. Tiam nom-solvado povas rompiĝi dum paketa filtrado faras ĝuste tion, por kio ĝi estis skribita.

Legu la solvilon, kiu estas aktiva, anstataŭ tiun, kiu estas agordita. Sur systemd-gastiganto la subkomando status montras, de kiu ligilo ĉiu skopo venis kaj ĉu private-DNS-nomo validas:

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

Se la demando eliras tra la fizika ligilo anstataŭ tra la tunelo, la kliento perdis la prioritatkonkurson kaj neniu fajroŝirma agordado riparos la nomadon. Komparu la vojon de la demando ambaŭflanke de la transiro por vidi, kiu moviĝis. Nomo, kiu solviĝas al privata adreso, kiun la nova reto ne povas enkursigi, estas tria kazo, kaj ĝi aperas kiel tempolimo anstataŭ kiel eraro.

Ekzerĉu la transiron kaj konservu la protokolon

Reproduktu la ŝanĝon intence anstataŭ atendi ĝin. Levu la tunelon sur la unua ligilo, komencu longdaŭran transdonon kaj ripetan serĉon, poste ŝanĝu la ligilon kaj observu, kiu postvivas. Notu la intervalon inter la malapero de la malnova ligilo kaj la raporto de la tunelo, ke ĝi estas konektita, ĉar en tiu fenestro la politiko aŭ teniĝis aŭ ne. Rulu la sekvencon ankaŭ en la alia direkto, por ke la rezulto ne estu unuflanka.

Esceptoj bezonas sian propran trairon, ĉar ĉirkaŭiro pravigita en la malnova reto ne estas aŭtomate pravigita en la nova. Printilo, NAS aŭ captiva portalo en la hejma LAN havas neniun pandanton en la poŝa reto, kaj la escepto, kiu atingis ĝin, fariĝas regulo sen pandanto.

Notu la interfacajn nomojn, la ofertitajn familiojn, la validan solvilon kaj la longon de la interrompo por ĉiu direkto. Rekonekto pruvas, ke la transporto resaniĝis, ne ke la blokado teniĝis dum la breĉo, kaj tiuj estas apartaj asertoj por bileto. Kun tiu protokolo la sekva transiro estas komparata kun konata stato anstataŭ kun la memoro.