VPN-ko DNSak funtzionatzen du, baina .local izenek huts egiten dute oraindik: nork ebazten ditu?

Bi makina VPN berean, host izen bera, eta horietako batek soilik ebazten du: aldea normalean ez da tunela, baizik eta zein ebazlek erantzun zuen. Linux mahaigainean izen hori izen zerbitzuen etengailutik, systemd-resolved-en stub-etik edo aplikazioak berarekin ekarri zuen ebazle batetik pasa daiteke, eta horietako bakoitzak bere araua aplikatzen dio sufixo berari. Sufixoa da arauak dibergitzen diren tokia, zeren .local ez baita etiketa neutroa. Jakin ezazu huts egiten duen programak benetan zein bide hartzen duen ezer exekutatzen den ordena aldatu aurretik.

Bi ebazle, bi erantzun desberdin

glibc bilaketa tradizionalak nsswitch.conf-ren hosts: lerroa zeharkatzen du eta modulu bakoitzari txandaka galdetzen dio, batek erantzun arte. Stub entzulearen bidez systemd-resolved-ekin hitz egiten duen bezeroak prozesu bakarrari galdetzen dio ordez, eta prozesu horrek esteka bakoitzeko politika gehi bere kasu bereziak aplikatzen ditu. Bere ebazlea ekartzen duen edo hori egiten duen liburutegi bat lotzen duen aplikazio batek biak saihets ditzake. Beraz, host izen batek hiru jabe izan ditzake makina batean, eta horietako batek soilik daki zer nahi zuen VPNak.

Identifikatu jabea ezer aldatu aurretik, zeren konponbidea desberdina baita hiruretako bakoitzarentzat. Mahaigain berean nabigatzaile batek eta komando lerroko tresna batek legitoki desadostasun izan dezakete, eta desadostasun hori arrastoa da, ez akatsa. Nabigatzaileak izena ebazten badu eta tresnak ez, ebazlearen bidea ari zara arazten, ez VPNaren bidea. Berretsi bidea bereizita, bideratze akatsa izen zerbitzuaren akatsarekin nahas ez dadin. Biek bat egiten dutenean, akatsa hostaren gainetik dago eta hemengo ebazlearen konfigurazioak ez du beste aldaketa bat merezi.

Zein komandok galdetu zion benetan zure ebazleari

Irakurtzeko soilik diren bi komandok erlazionatutako galderei erantzuten diete, eta haiek alderatzeak arazoa azkarrago lokalizatzen du konfigurazioa irakurtzeak baino. Erabili benetako barne izen bat eta mantendu irteera pribatu, barne erregistroak barne dira eta. Exekutatu biak huts egiten duen programa exekutatzen den saio berean:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Lehenak konfiguratutako moduluen bidez galdetzen du, programa tipiko batek bizi duena. Bigarrenak systemd-resolved-i zuzenean galdetzen dio eta erantzun zuen esteka, protokoloa eta zerbitzaria jakinarazten ditu. Korporazio zerbitzariari helbidearen bidez galdetzeak zerbitzariak erregistroa duela baino ez du frogatzen, zeren ez baitu ezer esaten aplikazioak inoiz galdetu zion ala ez. Irakurri VPNa daraman esteka eta aldarrikatzen dituen domeinuak, eta gero alderatu zerrenda hori huts egiten duen izeneko sufixoarekin.

Zergatik saihesten du .local-ek zure unicast zona

systemd-resolved-en erreferentzia dio .local-n amaitzen diren etiketa anitzeko izenek multicast DNSra joaten direla normalean mDNS gaitua dagoenean, ohiko unicast DNSra joan beharrean. RFC 6762-k nomenklatura hori link-local multicast-entzat gordetzen du, beraz korporazio zona batek sufixo horretarako inoiz kontsultatzen ez den erregistro zuzena eduki dezake. Tunelak ebazlea primeran bidera dezake eta hala ere lasterketa galdu. Cachetik arrakastatsua den ping batek ez du ezer esaten oraintxe gertatu den bilaketari buruz.

Salbuespen dokumentatu bat dago, eta horrek kasu horietako gehienak konpontzen ditu: estekak sufixo hori bilaketa domeinu edo bideratze domeinu gisa deklaratzen duenean, daemonak unicast bidean mantentzen du eta multicast kasu berezia saihesten du. Hori estekak dakarren politika da, ez lehentasun globala. VPN zerbitzari bera duten bi makinek desberdin joka dezakete sare profil batek domeinua deklaratzen duenean eta besteak ez, beraz irakurri aktibo dagoen profila, uste duzun editatu duzuna ordez.

Salbuespen estuak berrordenatze globala gainditzen du

Ezin duzun berridatzi zona existente batentzat, egin ebazlearen eta VPNaren jabeei domeinua daraman konexioan deklara dezaten. Sufixo bakar horretarako bideratze domeinu sarrera bat gehi aurreikusitako zerbitzari helbidea aldaketa txikia da jabe izendatuarekin, eta estekarekin bizi da, eskuz editatu den fitxategi batean ordez.

Deskonexio bat ere gainditzen du, esteka itzultzean estekak politika berriro aplikatzen baita. Partekatutako nsswitch.conf editatzea alternatiba tentagarria eta garestiena da, zeren makinako izen bakoitzarentzat bilaketa portaera aldatzen baitu, tokiko aurkikuntza barne. Multicast daemona desgaitzea ere ez da baliokidea: tokiko portaera kentzen du inongo ebazleri korporazio zona irakatsi gabe. Zerbitzua berria bada eta ez heredatua, jarri zure erakundeak kontrolatzen duen azpidomeinu baten azpian eta saltatu lehiaketa erabat. Aukeratu salbuespen estua izena firmwarian finkatuta edo etiketa batean inprimatuta dagoenean, eta aukeratu azpidomeinu berri bat bezeroa oraindik kontrolatzen duzunean.

Zer frogatu aldaketaren ondoren

Froga ezazu konponbidea aplikazioaren beraren bilaketarekin, probatzeko instalatu duzun tresna batekin ordez, eta garbitu haren ordez erantzun dezakeen cache oro. Gero berretsi ebazlearen bidea eta erantzuna eman zuen esteka. Azkenik egiaztatu tokiko aurkikuntzak aldaketaren aurretik bezala jokatzen duela, zeren agertzeari uzten dion inprimagailua baita jendeak azkenik nabaritzen duen zatia. Hiru komando hauek izena, bidea eta TLS identitatea egiaztatzen dituzte ordena horretan:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Helbide zuzenak ziurtagiri okerrarekin bezero zorrotzak huts eragiten du oraindik, beraz egiaztatu aplikazioak espero duen izena ebazpenak funtzionatzen duenean. Berretsi zerbitzuak VPN helbidetik onartzen dituela konexioak, eta ez bulegoko barrutitik soilik. Idatzi domeinuaren irismena, zerbitzaria eta jabea konexioaren dokumentazioan. Bestela, huts honetaz ohartzen den hurrengo pertsonak zuri oraintxe saihestu duzun aldaketa global beraren bila joango da.