Prečo resolv.conf zobrazuje DNS vášho VPN, ale dopytom je ignorovaný

V protokoloch nič nevyzerá zle: rozhranie je aktívne, resolver hlási DNS server VPN a súbor na disku ho uvádza. Napriek tomu sa interný názov hostiteľa stále prekladá cez miestny router. Tieto tri tvrdenia si neodporujú, pretože súbor, stav jednotlivého spojenia a cesta dopytu sú rôzne objekty, ktoré náhodou zdieľajú názov. Nasleduje cesta, ktorou dopyt skutočne prechádza na hostiteľovi so systemd-resolved.

Tri objekty s názvom resolv.conf

Na hostiteľovi s resolved je /etc/resolv.conf zvyčajne symbolický odkaz na /run/systemd/resolve/stub-resolv.conf. Tento cieľ obsahuje adresu miestneho stub poslucháča, 127.0.0.53, a tiež vyhľadávacie domény, ktoré resolved vypočítal. Je to pohľad na stav, nie stav sám.

Stav žije v konfigurácii resolved pre jednotlivé spojenia, a preto sa resolvectl status môže rozchádzať so súborom a napriek tomu mať pravdu. Každé spojenie nesie vlastné servery a vlastné smerovacie domény a stub tieto údaje konzultuje, keď príde dopyt. Manuál systemd-resolved opisuje generované súbory a model jednotlivých spojení; rozdelenie na pohľad a stav je časť, ktorú stojí za to si zapamätať. Úprava cieľa symbolického odkazu mení to, čo čítajú tradiční klienti, nie to, čo resolver vie.

Tretí objekt, /run/systemd/resolve/resolv.conf, splošťuje každé spojenie do jedného zoznamu serverov. Program nasmerovaný na tento súbor posiela dopyty priamo na uvedené servery a obchádza stub, takže sa naň už politika jednotlivých spojení nevzťahuje. Dva programy na rovnakom stroji preto môžu na rovnaký názov odpovedať rôzne a ani jeden nie je pokazený.

Sledujte jeden dopyt cez NSS

glibc číta /etc/nsswitch.conf, aby rozhodol, kto na názov odpovie. Riadok hosts obsahujúci resolve smeruje otázku na nss-resolve, ktorý sa pýta resolved cez D-Bus a dostane odpoveď pre dané spojenie. Riadok len s files dns posiela dopyt na adresu, ktorú drží /etc/resolv.conf.

Tento jediný riadok vysvetľuje väčšinu nezhôd medzi prehliadačom a dig. dig číta resolv.conf priamo a NSS sa nikdy nedotkne, takže testuje stub alebo nadradený server, nie cestu, ktorú aplikácia používa. getent hosts internal.example prechádza cez NSS a porovnanie jeho odpovede s odpoveďou dig je prvé užitočné meranie.

Aplikácie, ktoré si nesú vlastný resolver alebo hovoria DNS cez HTTPS s pevným koncovým bodom, obchádzajú obe cesty. Nič v resolv.conf ani v stave resolved ich neobmedzuje.

Skontrolujte, kto súbor vlastní a kam ukazuje

Prečítajte reťazec odkazov, kým čokoľvek zmeníte, pretože vlastníctvo rozhoduje, ktorý súbor je smerodajný. Každý príkaz nižšie iba číta stav.

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

Prvý riadok vypíše odkaz aj jeho cieľ spolu a obyčajný súbor vlastnený skriptom VPN znamená, že resolver tento zápis nikdy nepovažuje za vstup. Výstup stavu uvádza servery jednotlivých spojení a smerovacie domény, ktoré rozhodujú, kam každý dopyt ide. Riadok nsswitch hovorí, či sa stub vôbec konzultuje, takže adresa stub v súbore bez resolve znamená, že dopyty dorazia k miestnemu poslucháču, zatiaľ čo rozdelenie nikto neriadi. Aj posledný výpis je dôležitý, pretože hostiteľ bez stub-resolv.conf neprevádzkuje tu opísané usporiadanie.

Ak reťazec končí v súbore, ktorý spravuje iný balík, sú klient VPN a tento balík dvaja vlastníci, ktorých treba zladiť. Nahradenie odkazu zahodí prácu jedného vlastníka a prácu druhého ponechá na mieste.

Opravte u vlastníka odkazu

Pripojenie VPN by malo registrovať svoje servery a domény na vlastnom spojení a pri odpojení ich zase stiahnuť. Integrácia resolved v NetworkManageri aj vlastný pomocník klienta fungujú práve tak; skript, ktorý iba prepisuje resolv.conf, nie.

Na spojení, ktoré už existuje, ukazuje mechanizmus behové nastavenie. resolvectl dns tun0 10.40.0.53 pripája server a resolvectl domain tun0 '~corp.example' pripája smerovaciu doménu. Vlnovka je nosný znak: obmedzuje dopyty pre túto príponu na toto spojenie a zvyšok necháva tak, pričom rovnaká hodnota bez nej sa stane vyhľadávacou doménou a rozdelenie sa vyparí. Tie adresy sú laboratórne príklady, nie trvalá konfigurácia. Potvrďte pomocou resolvectl query host.corp.example a prečítajte, ktoré spojenie odpovedalo.

Registrovaný server stále potrebuje trasu. Keď dopyt dorazí na správne spojenie a vyprší časový limit, závada je v dostupnosti tunelom, nie vo vlastníctve resolvera.

Ako vyzerá funkčný stav

Zdravý výsledok je konzistentný vo všetkých troch pohľadoch: servery jednotlivých spojení zodpovedajú tomu, čo VPN pridelila, smerovacie domény pokrývajú len interné prípony a aplikácia, na ktorej záleží, preloží interný názov, zatiaľ čo verejný názov stále sleduje miestnu cestu. Jeden úspešný dopyt dokazuje menej než táto zhoda.

Potom sa odpojte a oba dopyty zopakujte. Klient, ktorý po ukončení ponechá svoje domény registrované, vytvorí stroj, ktorému interné preklady zlyhajú až o hodiny, bez otvoreného tunela a bez zjavnej príčiny.