Zergatik zure /etc/hosts sarrerak ez du VPNaren DNSra iristen

Izen bat gehitu zenion /etc/hosts fitxategiari, VPNera konektatu eta erregistroa denontzat agertzea espero zenuen. Ez da gertatzen, eta sorpresa bigarren sintoma batekin etorri ohi da: izena zure makinan ebazten da eta lankidearenean huts egiten du, eta hori VPNaren DNS zerbitzu hautsia dirudi, baina benetan hosts fitxategia diseinatu zeneko zeregina egiten ari da. Hosts fitxategia izenen ebazpenaren konfigurazio lokala da, ez zona eguneratzea, eta VPN konexio arrunt batean ezerk ez du hura igotzen.

Hosts tokiko gainidazketa da, ez zona eguneratzea

Fitxategia izen zerbitzuko liburutegiek DNS zerbitzari bat galdetu aurretik edo haren ordez kontsultatzen duten mapen zerrenda da. 10.40.0.20 build.corp.example bezalako lerro batek makina horretako aplikazioek ondorioztatzen dutena aldatzen du. Ez du erregistrorik sortzen, ez da tunelatik bidaiatzen, eta tunelak seinalatzen duen DNS zerbitzariak ez daki existitzen denik ere.

Horregatik da huts egitea asimetrikoa. Zure bezeroak erantzuna fitxategitik lortzen du. Beste bezero batek VPNaren DNS zerbitzariari galdetzen dio, eta hark ez du ezer itzultzen, eta aplikazioak izena ez dela existitzen jakinarazten du. Bi makinak zuzen ari dira jokatzen; bakarra da besteak inoiz ikusi ez duen gainidazketa bat duena.

Bi komando, bi osagai ezberdin

Eztabaida gelditzeko modurik azkarrena aldea bi komandotan ikusgarri egitea da, biak hosts sarrera duen bezeroan exekutatuta:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Lehenak sistemaren beraren bilaketa bideak galdetzen du, eta glibc sistema tipiko batean tokiko fitxategiak irakurtzen ditu DNS aurretik. Bigarrenak DNS kontsulta zuzenean bidaltzen dio helbide horretako zerbitzariari eta ez du tokiko fitxategirik kontsultatzen. Lehenak zure sarrera itzultzen duenean eta bigarrenak NXDOMAIN itzultzen duenean, erregistroa DNSan ez dela existitzen eta zure makina tokiko gainidazketa batetik erantzuten ari dela frogatu duzu.

Ordena konfigura daiteke, eta merezi du hura egiaztatzea distribuzio jakin bati buruz ezer ondorioztatu aurretik. Begiratu /etc/nsswitch.conf fitxategiko hosts: lerroa; hosts: files dns fitxategiak kontsultatzen ditu lehenengo. Ez kopiatu adibide hori funtzionatzen duen konfigurazio baten gainean ordena aldatzeko soilik, sistema errealek sarritan adibideak ez dituen iturri gehigarriak eta zerbitzu sarrera baldintzatuak zerrendatzen dituztelako.

systemd-resolved-ek proba lausotzen du

systemd-resolved erabiltzen duen sistema batean, tokiko stub-ak hosts datu-basetik ere zerbitzatzen ditu izenak. Beraz, 127.0.0.53 kontsultatzea ez da urruneko zerbitzariaren proba independentea, DNS kontsulta bat dirudi eta hala jokatzen badu ere. Resolver-ak zer dakien eta zein zerbitzariri galdetuko liokeen hauekin egiazta dezakezu:

resolvectl query build.corp.example
resolvectl status

Status irteerak esteka bakoitzeko DNS zerbitzariak izendatzen ditu, eta horrela jakiten duzu VPN estekak resolver bat jaso duen ala ez. Galdera hori hosts sarreratik bereizia da, eta erabiltzaile guztientzat huts egiten duenean eta ez bakar batentzat, egitea merezi duen galdera da.

Aplikazioek beste geruza bat gehi dezakete. Bere DNS-over-HTTPS ezarpena duen nabigatzaile batek, bere resolver konfigurazioa duen edukiontzi batek edo prozesuaren bizitza osoan bilaketak cachean gordetzen dituen exekuzio ingurune batek sistema ezberdin erantzun dezakete. Probatu axola dizun aplikazioa, makinako programa guztiak komando bakar batek deskribatzen dituela suposatu beharrean.

Zerk partekatzen du izen bat VPNan zehar benetan

Izen pribatu batek guztiontzat funtzionatu behar badu, guztien resolver-ak irits dezakeen jabedun bat behar du. Erantzun garbia erregistroa kudeatutako zona batean argitaratzea eta zona hori VPNaren DNS bide jasangarrian zehar ebazgarri egitea da. Orduan erregistroak egia iturri bakarra, auditoretza arrastoa eta bizi-zikloa ditu, eta inork ez du gogoratu behar zein eramangarrik daraman tokiko gainidazketa.

Hosts fitxategiak banatzea alternatiba zilegia da, eta amaierako puntuen kudeaketa da, ez izen zerbitzua. Hura aukeratzen baduzu, fitxategia flota kudeatzen duenak inplementatu, bertsionatu eta kendu behar du, eta horrela deskribatu behar da diseinuan. «VPNak hori kudeatzen du» ez da prozesu horren deskribapena.

DNS erregistro dinamikoa hirugarren mekanismoa da, bere baimenak, eguneratzeen autentifikazioa eta erregistroaren bizitza dituena. Ez da hosts sarrera batetik eratorritakoa, eta ez da bezero bat besterik gabe konektatzeagatik ere, zerbitzaria eta bezeroa biak horretarako konfiguratuta egon ezean. Berez agertzen den erregistro bat seinale da norbaitek eguneratze seguruak gaitu dituela eta bezero batek bere burua erregistratzen duela, eta konfigurazio hori diseinu erregistroan dagokio, ez arazoak konpontzeko harian. Inork ez badaki ezarpen horren jabea nor den, tratatu erregistro automatikoa egiaztatu gabeko gisa eta eduki kudeatutako zona egia iturri gisa.

Ebatzitako izen bat ez da ibilbide bat

Izenen ebazpena eta irisgarritasuna bereiziak dira, eta tokiko mapaketa zaharkitua da horiek nahasteko modu klasikoa. Mugitu den helbide batera seinalatzen duen hosts sarrera batek ostalari zaharkitua hautatzen jarraituko du DNS zuzendu ondoren ere, eta sintoma ondo ebazten den izen bateko bideratze hutsegitea dirudi.

Beraz, txostena «izena ebazten da baina zerbitzua ez da irisgarria» denean, alderatu sistemaren bilaketa VPNaren DNS zerbitzariari egindako kontsulta esplizitu batekin, eta gero egiaztatu lortu duzun helbidea zerbitzuak benetan erabiltzen duenarekin. systemd-resolved erreferentzia kontsultatzen dituen tokiko iturriak dokumentatzen ditu, eta hori da alderaketa horretarako behar duzun mapa.

Gero zuzendu gainidazketa bere jabearen bidez. Zure hosts fitxategitik lerro bat kentzeak ez die ezer egiten inplementazio script batekin lerro bera jaso zuten hamabi eramangarriei, eta hori da jendeak benetan duen arazo honen bertsioa.