Zašto resolv.conf prikazuje VPN-ov DNS, a pretrage ga ignoriraju

U zapisima ništa ne izgleda pogrešno: interfejs je aktivan, resolver prijavljuje VPN-ov DNS server, a datoteka na disku ga navodi. Ipak se interno ime hosta i dalje razrješava preko lokalnog rutera. Te tri tvrdnje nisu protivrječne, jer su datoteka, stanje pojedine veze i putanja pretrage različiti objekti koji slučajno dijele ime. Slijedi putanja koju upit zaista prolazi na hostu sa systemd-resolvedom.

Tri objekta zvana resolv.conf

Na hostu s resolvedom /etc/resolv.conf je obično simbolička veza na /run/systemd/resolve/stub-resolv.conf. Taj cilj drži adresu lokalnog stub slušača, 127.0.0.53, plus domene pretrage koje je resolved izračunao. To je prikaz stanja, a ne samo stanje.

Stanje živi u resolvedovoj konfiguraciji po vezi, zato se resolvectl status može razlikovati od datoteke i opet biti u pravu. Veza nosi vlastite servere i vlastite domene usmjeravanja, a stub konsultuje te podatke kad upit stigne. Priručnik za systemd-resolved opisuje generisane datoteke i model po vezi; podjela na prikaz i stanje je dio koji vrijedi zapamtiti. Mijenjanje cilja simboličke veze mijenja ono što čitaju tradicionalni klijenti, ne ono što resolver zna.

Treći objekat, /run/systemd/resolve/resolv.conf, spljošti svaku vezu u jednu listu servera. Program usmjeren na tu datoteku šalje upite pravo na navedene servere i preskače stub, pa se politika po vezi više ne odnosi na njega. Zato dva programa na istom računaru mogu dati različite odgovore na isto ime, a nijedan nije pokvaren.

Pratite jednu pretragu kroz NSS

glibc čita /etc/nsswitch.conf da odluči ko odgovara na ime. Linija hosts koja sadrži resolve usmjerava pitanje na nss-resolve, koji pita resolved preko D-Busa i dobija odgovor po vezi. Linija samo sa files dns šalje upit na adresu koju drži /etc/resolv.conf.

Ta jedna linija objašnjava većinu neslaganja između preglednika i dig. dig čita resolv.conf direktno i nikad ne dira NSS, pa testira stub ili uzvodni server, a ne putanju koju aplikacija koristi. getent hosts internal.example prolazi kroz NSS, a poređenje njegovog odgovora sa odgovorom dig prvo je korisno mjerenje.

Aplikacije koje nose vlastiti resolver ili govore DNS preko HTTPS-a s fiksnom krajnjom tačkom zaobilaze oba puta. Ništa u resolv.conf ni u resolvedovom stanju ih ne ograničava.

Provjerite ko posjeduje datoteku i kuda pokazuje

Pročitajte lanac veza prije nego što bilo šta promijenite, jer vlasništvo odlučuje koja je datoteka mjerodavna. Svaka komanda ispod samo čita stanje.

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

Prva linija ispisuje vezu i njen cilj zajedno, a obična datoteka u vlasništvu VPN skripte znači da resolver taj upis nikad ne tretira kao ulaz. Statusni izlaz navodi servere po vezi plus domene usmjeravanja koji odlučuju kuda ide svaki upit. nsswitch linija kaže da li se stub uopšte konsultuje, pa stub adresa u datoteci bez resolve tamo znači da upiti stižu do lokalnog slušača dok ništa ne upravlja podjelom. I taj posljednji spisak je važan, jer host bez stub-resolv.conf ne pokreće ovdje opisani raspored.

Ako lanac završava na datoteci kojom upravlja drugi paket, VPN klijent i taj paket su dva vlasnika koja treba uskladiti. Zamjena veze odbacuje rad jednog vlasnika i ostavlja rad drugog na mjestu.

Popravka kod vlasnika veze

VPN veza treba registrovati svoje servere i svoje domene na vlastitoj vezi, pa ih povući pri odspajanju. NetworkManagerova resolved integracija i klijentov vlastiti pomoćnik rade upravo tako; skripta koja samo prepisuje resolv.conf ne radi to.

Na vezi koja već postoji, mehanizam pokazuju postavke u radu. resolvectl dns tun0 10.40.0.53 priključuje server, a resolvectl domain tun0 '~corp.example' priključuje domen usmjeravanja. Tilda je nosivi znak: ona ograničava upite za taj sufiks na ovu vezu i ostavlja sve ostalo na miru, dok ista vrijednost bez nje postaje domen pretrage i podjela ispari. Te adrese su laboratorijski primjeri, a ne trajna konfiguracija. Potvrdite sa resolvectl query host.corp.example i pročitajte koja je veza odgovorila.

Registrovani server ipak treba rutu. Kada upit stigne do prave veze i istekne, kvar je u dostupnosti kroz tunel, a ne u vlasništvu resolvera.

Kako izgleda radno stanje

Zdrav rezultat je dosljedan u sva tri prikaza: serveri po vezi se poklapaju s onim što je VPN dodijelio, domene usmjeravanja pokrivaju samo interne sufikse, a aplikacija koja je važna razrješava interno ime dok javno ime i dalje slijedi lokalnu putanju. Jedan uspješan upit dokazuje manje od te usklađenosti.

Zatim se odspojite i ponovite oba upita. Klijent koji svoje domene ostavi registrovane nakon raskida proizvodi mašinu koja satima kasnije ne uspijeva u internim pretragama, bez otvorenog tunela i bez očiglednog uzroka.