Zakaj vaš vnos v /etc/hosts ne doseže DNS VPN

Dodali ste ime v /etc/hosts, se povezali z VPN in pričakovali, da bo zapis viden vsem. Tega ni, in presenečenje običajno pride z drugim simptomom: ime se razreši na vašem računalniku in ne uspe pri sodelavcu, kar je videti kot pokvarjena storitev DNS VPN, v resnici pa datoteka hosts počne natanko to, za kar je bila zasnovana. Datoteka hosts je lokalna konfiguracija razreševanja imen, ne posodobitev cone, in nič v običajni povezavi VPN je ne naloži.

Hosts je lokalna preglasitev, ne posodobitev cone

Datoteka je seznam preslikav, ki jih knjižnice imenske storitve pregledajo pred poizvedbo na strežnik DNS ali namesto nje. Vrstica, kot je 10.40.0.20 build.corp.example, spremeni, do česa pridejo aplikacije na tem enem računalniku. Ne ustvari zapisa, ne potuje skozi tunel in strežnik DNS, na katerega kaže tunel, sploh ne ve, da obstaja.

Zato je neuspeh asimetričen. Vaš odjemalec dobi odgovor iz datoteke. Drug odjemalec vpraša strežnik DNS VPN, ki ne vrne ničesar, in aplikacija sporoči, da ime ne obstaja. Oba računalnika se obnašata pravilno; le eden ima preglasitev, ki je drugi ni nikoli videl.

Dva ukaza, dve različni komponenti

Najhitrejši način, da ustavite razpravo, je pokazati razliko v dveh ukazih, oba izvedena na odjemalcu z vnosom hosts:

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

Prvi vpraša lastno pot iskanja sistema, ki na tipičnem sistemu glibc bere lokalne datoteke pred DNS. Drugi pošlje poizvedbo DNS neposredno strežniku na tem naslovu in lokalnih datotek sploh ne pregleda. Ko prvi vrne vaš vnos in drugi vrne NXDOMAIN, ste dokazali, da zapis v DNS ne obstaja in da vaš računalnik odgovarja iz lokalne preglasitve.

Vrstni red je mogoče nastaviti in vredno ga je preveriti, preden karkoli sklepate o določeni distribuciji. Poglejte vrstico hosts: v /etc/nsswitch.conf; hosts: files dns najprej pregleda datoteke. Tega primera ne kopirajte na delujočo konfiguracijo samo zato, da bi spremenili vrstni red, ker resnični sistemi pogosto navajajo dodatne vire in pogojne vnose storitev, ki jih primer ne vsebuje.

systemd-resolved zamegli test

V sistemu s systemd-resolved lokalni stub strežbe tudi imena iz zbirke hosts. Zato poizvedba na 127.0.0.53 ni neodvisen test oddaljenega strežnika, čeprav je videti kot poizvedba DNS in se tako obnaša. Kaj razreševalnik ve in katere strežnike bi vprašal, lahko potrdite s:

resolvectl query build.corp.example
resolvectl status

Izhod status navaja strežnike DNS za vsako povezavo in tako ugotovite, ali je povezava VPN sploh prejela razreševalnik. To vprašanje je ločeno od vnosa hosts in je tisto, ki se ga je vredno vprašati, ko zasebno ime ne uspe vsem uporabnikom in ne enemu.

Aplikacije lahko dodajo še eno plast. Brskalnik z lastno nastavitvijo DNS-over-HTTPS, vsebnik z lastno konfiguracijo razreševalnika ali izvajalno okolje, ki medpomni iskanja za celotno življenjsko dobo procesa, lahko vsak odgovori drugače kot sistem. Preizkusite aplikacijo, ki vam je pomembna, namesto da bi domnevali, da en ukaz opisuje vsak program na računalniku.

Kaj si ime res deli prek VPN

Če mora zasebno ime delovati za vse, potrebuje lastnika, do katerega doseže razreševalnik vseh. Čist odgovor je objaviti zapis v upravljani coni in to cono narediti razrešljivo po predvideni poti DNS v VPN. Takrat ima zapis en vir resnice, revizijsko sled in življenjski cikel, in nikomur ni treba pomniti, kateri prenosnik nosi lokalno preglasitev.

Razširjanje datotek hosts je legitimna alternativa in to je upravljanje končnih točk, ne imenska storitev. Če jo izberete, mora datoteko uvesti, različicati in odstraniti tisto, kar upravlja floto, in tako mora biti opisano v zasnovi. „VPN to ureja“ ni opis tega postopka.

Dinamična registracija DNS je tretji mehanizem z lastnimi dovoljenji, preverjanjem posodobitev in življenjsko dobo zapisa. Ne izhaja iz vnosa hosts in ne izhaja niti iz same povezave odjemalca, razen če sta strežnik in odjemalec oba konfigurirana za to. Zapis, ki se pojavi sam od sebe, je znak, da je nekdo omogočil varne posodobitve in odjemalca, ki se sam registrira, in ta konfiguracija sodi v zapis zasnove, ne v nit za odpravljanje težav. Če nihče ne more povedati, kdo je lastnik te nastavitve, obravnavajte samodejni zapis kot nepreverjen in ohranite upravljano cono kot vir resnice.

Razrešeno ime ni pot

Razreševanje imen in dosegljivost sta ločena, zastarela lokalna preslikava pa je klasičen način, da ju zamenjate. Vnos hosts, ki kaže na naslov, ki se je preselil, bo še dolgo po popravku DNS izbiral zastarelega gostitelja, simptom pa je videti kot napaka usmerjanja pri imenu, ki se dobro razreši.

Ko je torej poročilo „ime se razreši, a storitev ni dosegljiva“, primerjajte sistemsko iskanje z izrecno poizvedbo na strežnik DNS VPN in nato preverite prejeti naslov proti tistemu, ki ga storitev dejansko uporablja. Referenca systemd-resolved dokumentira lokalne vire, ki jih pregleda, in to je zemljevid, ki ga potrebujete za to primerjavo.

Nato preglasitev popravite prek njenega lastnika. Odstranitev vrstice iz vaše lastne datoteke hosts ne naredi ničesar za dvanajst prenosnikov, ki so isto vrstico prejeli iz namestitvene skripte, in to je različica te težave, ki jo ljudje v resnici imajo.