Wi-Fi-tik mobilera pasatzean kill-switch: zer hausten den

Une batean ordenagailu eramangarria bulegoko Wi-Fi sarean dago, hurrengoan telefono batera konektatuta, eta tunelaren adierazlea berriro berde dago leihoak aldatzen amaitu baino lehen. Argi berdeak tunela berriro konektatu dela baino ez du adierazten; tartean bideratze- eta blokeo-politikak zer egin zuen beste galdera bat da. Politika hori azken instalazioan konpilatutako bat-etortze baldintzen multzo bat da, eta pasatzeak kendu berri dituen interfaze bat, helbide bat eta helbide-familia bat izendatzen ditu. Beraz, aldaketa berak berdinak diruditen hiru emaitza ematen ditu: blokeoak jarraitzen du, politikak bere berreskuratzea blokeatzen du, edo ezerk estaltzen ez duen bide bat irekitzen da.

Pantailan ezerk ez ditu hiru egoera horiek bereizten, beraz galdetu zein identifikatzaileri zeuden arauak lotuta adierazleak zein kolore erakusten duen baino. Linuxen arau batek interfaze bat edo harekin betetako ipset bat izan dezake izena; Androiden VpnService bati esan dakioke zein azpiko sare jarraitu setUnderlyingNetworks bidez. Lotura bakoitzak ordezkatzear dagoen esteka bat seinalatzen du, eta bakoitza berriro ebaluatu behar da ondoren.

Zer berridazten duen pasatzeak benetan

Esteka zaharra desagertzen denean, kernelak haren helbideak kentzen ditu, haren bidez zihoazen bideak atzera botatzen ditu eta iturri-helbidearen hautaketa geratzen denetik berreraikitzen du. Bide lehenetsia ate berrira mugitzen da, eta arau zaharrek erreferentziatzen zuten interfaze-indizea desagertu da edo beste gailu batentzat birziklatu da. Estekako resolverrak ere freskatzen dira, baina ez bideekin une berean. Hori guztia VPN bezeroaren azpitik gertatzen da, beraz bere tunelaren egoera baino begiratzen ez duen bezeroak ez du ezer ikusten.

Arazoa da arau batek identifikatzaile zehatz bat kodetzen duela, haren atzean dagoen asmoa beharrean. Tunelaren interfazetik irteten ez den guztia botatzen duen arauak interfaze-izen bat kodetzen du; amaiera-puntua uzten duen arauak sare berriak beste nonbait bidera dezakeen helbide bat kodetzen du. Identifikatzailea desagertzen denean, araua ez da bistako oker bihurtzen: edo ezerrekin bat etzeari uzten dio edo gauza okerrarekin bat etortzen hasten da.

Kanpoko tunela zulorik egin gabe berreraikitzea

Kanpoko garraioa iturri-helbide zaharrarekin lotuta zegoen, beraz socket berri bat ireki behar du berritik. Amaiera-puntua helbide literala ez bada host-izena baizik, bilaketa batek arrakasta izan behar du blokeoa indarrean dagoen bitartean. Hori da ordenaren tranpa: amaiera-puntua izan ezik guztia botatzeko bezain politika zorrotzak hura aurkitzeko behar den bilaketa ere botako du, ebazpena blokeoa altxatu aurretik gertatzen ez bada edo oraindik bizirik dagoen tunel batetik eramaten ez bada. Bi ordenek funtziona dezakete, baina bezeroak badaki zeinetan dagoen soilik.

Bezeroak desberdinak dira hemen, diagnostikatzean garrantzitsua den moduan. Batzuek lehenik ebazten dute eta gero arauak instalatzen dituzte, beraz pasatzeak etenaldi ikusgai bat dakar eta gero bere kabuz berreskuratzen da; beste batzuek blokeoa mantentzen dute eta bizirik atera den tunelaren mende uzten dute bilaketa eramatea, eta hori erabat huts egiten du tunela estekarekin batera hil bada. Konektibitatea berreskuratzeko bide zuzen lehenetsi zabal bat gehitzeak proba beti pasatzen du eta saihesten ari zinen ihesa beti uzten du.

Ate zaharrera oraindik seinalatzen duen bide batek berreskuratze itsatsi bera ematen du beste arrazoi batengatik, beraz irakurri taula bezeroa errudun egin aurretik. Beheko komanduek kernelak benetan erabiliko lituzkeen interfazea eta iturri-helbidea izendatzen dituzte, eta horrek lerro bakarrean erabakitzen du bide zaharra oraindik instalatuta ote dagoen.

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

Esteka berriak IPv6 ekartzen duenean eta arauek ez

Sare mugikorrek eta gonbidatu-sareek IPv6 aurrizki globala banatzen dute sarritan, bulegoko kablezko LANak inoiz egin ez zuen arren. IPv4 arau gisa soilik idatzitako politika, eskuz egindako iptables eta nftables errezeta gehienen forma lehenetsia, ez du horren ezer estaltzen. Tunela konektatuta geratzen da, IPv6 irisgarritasuna duten aplikazioak kanpora irteten dira, eta adierazleak ezin du aldea erakutsi tunela benetan aktibo dagoelako. Ispilu-kasua bezain ohikoa da: IPv6 soilik hartzen duen arau-multzoak ez du ezer egiten v6 eskaintzen ez duen sare batean.

Alderatu estekak eskaintzen duena politikak aipatzen duenarekin, pasatzearen bi aldeetan. Komandu hauek bezeroak erabiltzen dituen datu berberak inprimatzen dituzte:

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

Bigarren komanduak bide lehenetsi bat inprimatzen badu eta hirugarrenak zero ematen badu, esteka berriak makina IPv6 bidez atera dezake inongo arauk zaindu gabe. Exekutatu hirurak berriro aldaketaren ondoren, zenbaki interesgarria bi exekuzioen arteko aldea baita. Bigarrenak ezer inprimatzen ez badu, alderantzizko kasua aplikatzen da eta v6-karga handiko edozein politika apaingarri hutsa da han.

Resolverrak eskuak aldatzen ditu saioaren erdian

Sistema modernoetan resolverrak estekei lotuta daude, beraz esteka berria resolver-multzo berri batekin eta beharbada split-DNS ikuspegi ezberdin batekin iristen da. systemd-resolved-ek esteka bakoitzeko scope bat mantentzen du eta haien artean bidearen arabera aukeratzen du, macOS-ek berriz scoped resolverrak biltegi dinamikotik irakurtzen ditu eta interfazeen ordena errespetatzen du. Bere resolver propioa instalatzen duen bezeroak estekarekin lehiatzen du, eta inork begiratzen ez dituen lehentasun-arauak dira irabazlea erabakitzen dutenak. Orduan izenen ebazpena hauts daiteke pakete-iragazketak idatzi zeneko lana egiten duen bitartean.

Irakurri aktibo dagoen resolverra eta ez konfiguratuta dagoena. systemd ostalari batean status azpikomandoak erakusten du zein estekatatik etorri zen scope bakoitza eta private-DNS izen bat indarrean dagoen ala ez:

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

Galderak esteka fisikoan zehar irteten badu tunelaren ordez, bezeroak lehentasun-lehiaketa galdu du eta suebakiko edozein doirapenek ez du izena konponduko. Alderatu galderaren bidea pasatzearen bi aldeetan zein mugitu zen ikusteko. Sare berriak bidera ezin duen helbide pribatu batera ebazten den izena hirugarren kasua da, eta itxarote-denbora gisa agertzen da, errore gisa ez.

Praktikatu pasatzea eta gorde erregistroa

Erreproduzitu aldaketa nahita, hura zain egon beharrean. Altxa ezazu tunela lehen estekan, hasi transferentzia luze bat eta bilaketa errepikatu bat, gero aldatu esteka eta ikusi zein bizirik irauten duen. Idatzi esteka zaharra desagertu eta tunelek konektatuta dagoela jakinarazteko arteko tartea, leiho horretan politikak eutsi egin zuelako edo ez zuelako. Exekutatu segida beste norabidean ere, emaitza aldebakarrekoa izan ez dadin.

Salbuespenek beren igarobidea behar dute, sare zaharrean justifikatutako saihesbide bat ez baita automatikoki justifikatuta berrian. Etxeko LANeko inprimagailu batek, NAS batek edo captive portal batek ez du baliokiderik sare mugikorrean, eta hara iristen zen salbuespena baliokiderik gabeko arau bihurtzen da.

Idatzi interfaze-izenak, eskaintzen diren familiak, indarrean dagoen resolverra eta etenduraren iraupena norabide bakoitzerako. Berriz konektatzeak frogatzen du garraioak berreskuratu duela, ez tartean blokeoak eutsi zuenik, eta txartel batean jartzeko baieztapen bereiziak dira. Erregistro horrekin hurrengo pasatzea ezagutzen den egoera batekin alderatzen da, memoriarekin beharrean.