Zakaj resolv.conf prikazuje DNS vašega VPN, poizvedbe pa ga ignorirajo

V dnevnikih nič ne izgleda narobe: vmesnik je aktiven, razreševalnik poroča strežnik DNS VPN, in datoteka na disku ga našteva. Kljub temu se notranje ime gostitelja še vedno razrešuje prek lokalnega usmerjevalnika. Te tri trditve si ne nasprotujejo, ker so datoteka, stanje posamezne povezave in pot poizvedbe različni objekti, ki si po naključju delijo ime. Sledi pot, ki jo poizvedba v resnici prehodi na gostitelju s systemd-resolved.

Trije objekti z imenom resolv.conf

Na gostitelju z resolved je /etc/resolv.conf običajno simbolna povezava na /run/systemd/resolve/stub-resolv.conf. Ta cilj vsebuje naslov lokalnega stub poslušalca, 127.0.0.53, in iskalne domene, ki jih je izračunal resolved. To je pogled na stanje, ne stanje samo.

Stanje živi v konfiguraciji resolved za posamezno povezavo, zato se resolvectl status lahko razhaja z datoteko in ima še vedno prav. Vsaka povezava nosi svoje strežnike in svoje usmerjevalne domene, stub pa te podatke pregleda, ko prispe poizvedba. Priročnik systemd-resolved opisuje ustvarjene datoteke in model posamezne povezave; ločitev pogleda in stanja je del, ki si ga velja zapomniti. Spreminjanje cilja simbolne povezave spremeni, kaj berejo tradicionalni odjemalci, ne tega, kar ve razreševalnik.

Tretji objekt, /run/systemd/resolve/resolv.conf, splošči vsako povezavo v en seznam strežnikov. Program, usmerjen na to datoteko, pošilja poizvedbe neposredno navedenim strežnikom in obide stub, zato zanj politika posamezne povezave ne velja več. Zato lahko dva programa na istem stroju na isto ime odgovorita različno, in noben ni pokvarjen.

Sledite eni poizvedbi skozi NSS

glibc prebere /etc/nsswitch.conf, da odloči, kdo odgovori na ime. Vrstica hosts, ki vsebuje resolve, usmeri vprašanje v nss-resolve, ki vpraša resolved prek D-Bus in prejme odgovor za povezavo. Vrstica samo z files dns pošlje poizvedbo na naslov, ki ga ima /etc/resolv.conf.

Ta ena vrstica pojasni večino nesoglasij med brskalnikom in dig. dig bere resolv.conf neposredno in se NSS nikoli ne dotakne, zato preizkusi stub ali nadrejeni strežnik namesto poti, ki jo uporablja aplikacija. getent hosts internal.example gre skozi NSS, in primerjava njegovega odgovora z odgovorom dig je prva koristna meritev.

Aplikacije, ki prinesejo svoj razreševalnik ali govorijo DNS prek HTTPS s fiksno končno točko, obidejo obe poti. Nič v resolv.conf ali v stanju resolved jih ne omejuje.

Preverite, kdo ima datoteko in kam kaže

Preberite verigo povezav, preden karkoli spremenite, ker lastništvo odloča, katera datoteka je merodajna. Vsak ukaz spodaj samo bere stanje.

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

Prva vrstica izpiše povezavo in njen cilj skupaj, običajna datoteka v lasti skripta VPN pa pomeni, da razreševalnik tega zapisa nikoli ne obravnava kot vhod. Izpis stanja navaja strežnike posamezne povezave in usmerjevalne domene, ki odločajo, kam gre vsaka poizvedba. Vrstica nsswitch pove, ali se stub sploh upošteva, zato naslov stub v datoteki brez resolve pomeni, da poizvedbe dosežejo lokalnega poslušalca, medtem ko razdelitve ne upravlja nič. Tudi zadnji seznam je pomemben, ker gostitelj brez stub-resolv.conf ne izvaja tukaj opisane ureditve.

Če se veriga konča v datoteki, ki jo upravlja drug paket, sta odjemalec VPN in ta paket dva lastnika, ki ju je treba uskladiti. Zamenjava povezave zavrže delo enega lastnika in pusti delo drugega na mestu.

Popravite pri lastniku povezave

Povezava VPN bi morala svoje strežnike in svoje domene registrirati na svoji povezavi in jih nato ob prekinitvi umakniti. Integracija resolved v NetworkManagerju in lastni pomočnik odjemalca delujeta prav tako; skript, ki samo prepisuje resolv.conf, ne.

Na povezavi, ki že obstaja, mehanizem pokažejo nastavitve med izvajanjem. resolvectl dns tun0 10.40.0.53 pripne strežnik, resolvectl domain tun0 '~corp.example' pa pripne usmerjevalno domeno. Tilda je nosni znak: omeji poizvedbe za to pripono na to povezavo in pusti vse drugo pri miru, medtem ko ista vrednost brez nje postane iskalna domena in razdelitev izhlapi. Ti naslovi so laboratorijski primeri, ne trajna konfiguracija. Potrdite z resolvectl query host.corp.example in preberite, katera povezava je odgovorila.

Registriran strežnik še vedno potrebuje pot. Ko poizvedba doseže pravo povezavo in poteče čas, je napaka v dosegljivosti skozi tunel, ne v lastništvu razreševalnika.

Kako izgleda delujoče stanje

Zdrava rezultat je skladen v vseh treh pogledih: strežniki posamezne povezave se ujemajo s tem, kar je razdelil VPN, usmerjevalne domene pokrivajo le notranje pripone, pomembna aplikacija pa razreši notranje ime, medtem ko javno ime še vedno sledi lokalni poti. Ena uspešna poizvedba dokaže manj kot ta skladnost.

Nato prekinite povezavo in ponovite obe poizvedbi. Odjemalec, ki po razgradnji pusti svoje domene registrirane, ustvari stroj, ki ure pozneje ne uspe pri notranjih poizvedbah, brez odprtega tunela in brez očitnega vzroka.