Zergatik erakusten duen resolv.conf fitxategiak zure VPNaren DNSa baina bilaketek alde batera uzten duten

Erregistroetan ezer ez dirudi oker: interfazea aktibo dago, ebazleak VPNaren DNS zerbitzaria jakinarazten du, eta diskoan dagoen fitxategiak hura zerrendatzen du. Hala ere, barneko ostalari-izen bat tokiko router bidez ebazten da oraindik. Hiru baieztapen horiek ez dira kontraesankorrak, fitxategia, esteka bakoitzeko egoera eta bilaketaren bidea izen bera partekatzen duten objektu desberdinak direlako. Jarraian, systemd-resolved duen ostalari batean kontsulta batek benetan egiten duen bidea deskribatzen da.

resolv.conf izeneko hiru objektu

resolved duen ostalari batean, /etc/resolv.conf normalean /run/systemd/resolve/stub-resolv.conf-rako esteka sinbolikoa da. Helmuga horrek tokiko stub entzule baten helbidea du, 127.0.0.53, eta resolvedek kalkulatutako bilaketa-domainak. Egoeraren ikuspegia da, ez egoera bera.

Egoera resolveden esteka bakoitzeko konfigurazioan bizi da, eta horregatik resolvectl status fitxategiarekin bat ez etorri eta arrazoi izaten jarrai dezake. Esteka bakoitzak bere zerbitzariak eta bere bideratze-domainak daramatza, eta stub-ak datu horiek kontsultatzen ditu kontsulta bat iristean. systemd-resolved eskuliburuak sortutako fitxategiak eta esteka bakoitzeko eredua deskribatzen ditu; ikuspegiaren eta egoeraren arteko bereizketa da gordetzea merezi duen zatia. Esteka sinbolikoaren helmuga aldatzeak bezero tradizionalek irakurtzen dutena aldatzen du, ez ebazleak dakiena.

Hirugarren objektu batek, /run/systemd/resolve/resolv.conf, esteka bakoitza zerbitzari-zerrenda bakarrean zapaltzen du. Fitxategi horretara zuzendutako programak kontsultak zerrendatutako zerbitzarietara zuzenean bidaltzen ditu eta stub-a saihesten du, beraz esteka bakoitzeko politikak ez dio jada aplikatzen. Horregatik, makina bereko bi programak modu desberdinean erantzun diezaiokete izen berari, eta bat ere ez dago hondatuta.

Jarraitu bilaketa bat NSS bidez

glibc-ek /etc/nsswitch.conf irakurtzen du nor den izen bati erantzuten erabakitzeko. resolve daukan hosts lerroak galdera nss-resolve-ra bideratzen du, eta hark resolved-i D-Bus bidez galdetzen dio eta esteka bakoitzeko erantzuna jasotzen du. files dns soilik duen lerroak kontsulta /etc/resolv.conf-k duen helbidera bidaltzen du.

Lerro bakar horrek azaltzen ditu nabigatzailearen eta dig-ren arteko desadostasun gehienak. dig-k resolv.conf zuzenean irakurtzen du eta ez dio NSS-ri inoiz ukitzen, beraz stub-a edo goi-korronteko zerbitzari bat probatzen du, aplikazioak erabiltzen duen bidea beharrean. getent hosts internal.example NSS-tik igarotzen da, eta haren erantzuna dig-renarekin alderatzea da lehen neurketa baliagarria.

Beren ebazlea gehitzen duten edo HTTPS bidez DNS finko batekin hitz egiten duten aplikazioek bi bideak saihesten dituzte. resolv.conf-en edo resolveden egoeran ezerk ez ditu mugatzen.

Egiaztatu noren jabetzakoa den fitxategia eta norantz apuntatzen duen

Irakurri esteken katea ezer aldatu aurretik, jabetzak erabakitzen baitu zein fitxategi den autoritarioa. Beheko komandu bakoitzak egoera baino ez du irakurtzen.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Lehen lerroak esteka eta haren helmuga elkarrekin inprimatzen ditu, eta VPN script baten jabetzako fitxategi arrunt batek esan nahi du ebazleak ez duela inoiz idazketa hori sarrera gisa tratatzen. Egoera-irteerak esteka bakoitzeko zerbitzariak zerrendatzen ditu, eta kontsulta bakoitza norantz doan erabakitzen duten bideratze-domainak. nsswitch lerroak esaten du stub-a batere kontsultatzen den, beraz fitxategian stub helbide bat egoteak resolve han gabe esan nahi du kontsultak tokiko entzulera iristen direla, bitartean ezerk banaketa kudeatzen ez duela. Azken zerrenda horrek ere garrantzia du, stub-resolv.conf gabe ostalari batek ez baitu hemen deskribatutako antolamendua exekutatzen.

Kateak beste pakete batek kudeatutako fitxategi batean amaitzen bada, VPN bezeroa eta pakete hori dira adostu beharreko bi jabeak. Esteka ordezkatzeak jabe baten lana botatzen du eta bestearena lekuan uzten du.

Konpondu estekaren jabean

VPN konexio batek bere zerbitzariak eta domeinak bere estekan erregistratu beharko lituzke, eta gero deskonexioan erretiratu. NetworkManagerren resolved integrazioak eta bezero baten laguntzaile propioak horrela egiten dute; resolv.conf baino berridazten ez duen script batek ez.

Dagoeneko baden esteka batean, exekuzio-denborako ezarpenek erakusten dute mekanismoa. resolvectl dns tun0 10.40.0.53-k zerbitzari bat eransten du, eta resolvectl domain tun0 '~corp.example'-k bideratze-domeinu bat. Tildea da karga daraman karakterea: sufijo horretarako kontsultak esteka honetara mugatzen ditu eta gainerako guztia bakean uzten du, eta balio berak hura gabe bilaketa-domeinu bihurtzen dira eta banaketa lurruntzen da. Helbide horiek laborategiko adibideak dira, ez konfigurazio iraunkorra. Egiaztatu resolvectl query host.corp.example-rekin eta irakurri zein estekak erantzun duen.

Erregistratutako zerbitzari batek oraindik ibilbide bat behar du. Kontsulta esteka egokira iritsi eta denbora agortzen denean, hutsegitea tunelaren bidezko irisgarritasunean dago, ez ebazlearen jabetzan.

Nola itxura duen funtzionatzen duen egoerak

Emaitza osasuntsua hiru ikuspegietan koherentea da: esteka bakoitzeko zerbitzariek VPNak banatutakoarekin bat egiten dute, bideratze-domeinuek barne-sufijoak baino ez dituzte estaltzen, eta garrantzitsua den aplikazioak barne-izen bat ebazten du, izen publikoak tokiko bidea jarraitzen duen bitartean. Kontsulta arrakastatsu batek adostasun horrek baino gutxiago frogatzen du.

Ondoren deskonektatu eta errepikatu bi kontsultak. Desmuntaketaren ondoren bere domeinak erregistratuta uzten dituen bezero batek ordu batzuk geroago barne-bilaketek huts egiten duen makina sortzen du, tunelik ireki gabe eta arrazoi nabarmenik gabe.