Miksi resolv.conf näyttää VPN:n DNS:n mutta haut jättävät sen huomiotta

Lokeissa mikään ei näytä väärältä: liitäntä on ylhäällä, ratkaisija ilmoittaa VPN:n DNS-palvelimen ja levyllä oleva tiedosto luettelee sen. Silti sisäinen konenimi ratkeaa edelleen paikallisen reitittimen kautta. Nämä kolme väitettä eivät ole ristiriidassa, koska tiedosto, linkkikohtainen tila ja haun polku ovat eri objekteja, jotka sattuvat jakamaan nimen. Seuraavassa käydään läpi polku, jonka kysely todella kulkee systemd-resolved-koneessa.

Kolme objektia nimeltä resolv.conf

Resolved-koneessa /etc/resolv.conf on yleensä symbolinen linkki tiedostoon /run/systemd/resolve/stub-resolv.conf. Kohde sisältää paikallisen stub-kuuntelijan osoitteen, 127.0.0.53, sekä resolvedin laskemat hakudomainit. Se on näkymä tilasta, ei tila itse.

Tila elää resolvedin linkkikohtaisessa kokoonpanossa, minkä vuoksi resolvectl status voi olla eri mieltä tiedoston kanssa ja silti oikeassa. Jokainen linkki kantaa omat palvelimensa ja omat reititysdomaininsa, ja stub konsultoi näitä tietoja kyselyn saapuessa. systemd-resolvedin käsikirja kuvaa luodut tiedostot ja linkkikohtaisen mallin; näkymän ja tilan erottaminen on se osa, joka kannattaa muistaa. Symbolisen linkin kohteen muuttaminen muuttaa sitä, mitä perinteiset asiakkaat lukevat, ei sitä, mitä ratkaisija tietää.

Kolmas objekti, /run/systemd/resolve/resolv.conf, litistää jokaisen linkin yhdeksi palvelinluetteloksi. Siihen tiedostoon osoittava ohjelma lähettää kyselyt suoraan luetelluille palvelimille ja ohittaa stubin, joten linkkikohtainen käytäntö ei enää koske sitä. Siksi kaksi ohjelmaa samassa koneessa voivat vastata samaan nimeen eri tavoin, eikä kumpikaan ole rikki.

Seuraa yhtä hakua NSS:n läpi

glibc lukee tiedostoa /etc/nsswitch.conf päättääkseen, kuka nimeen vastaa. hosts-rivi, joka sisältää resolve, ohjaa kysymyksen nss-resolve:lle, joka kysyy resolvedilta D-Busin kautta ja saa linkkikohtaisen vastauksen. Rivi, jossa on vain files dns, lähettää kyselyn osoitteeseen, jonka /etc/resolv.conf sisältää.

Tämä yksi rivi selittää useimmat selaimen ja dig:n väliset erimielisyydet. dig lukee tiedoston resolv.conf suoraan eikä kosketa NSS:ään, joten se testaa stubia tai ylävirran palvelinta eikä sitä polkua, jota sovellus käyttää. getent hosts internal.example kulkee NSS:n läpi, ja sen vastauksen vertaaminen dig:n vastaukseen on ensimmäinen hyödyllinen mittaus.

Sovellukset, jotka sisältävät oman ratkaisijan tai puhuvat DNS:ää HTTPS:n yli kiinteään päätepisteeseen, ohittavat molemmat polut. Mikään resolv.conf:ssä tai resolvedin tilassa ei rajoita niitä.

Tarkista, kuka omistaa tiedoston ja mihin se osoittaa

Lue linkkiketju ennen kuin muutat mitään, koska omistajuus ratkaisee, mikä tiedosto on ratkaiseva. Jokainen alla oleva komento lukee vain tilaa.

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

Ensimmäinen rivi tulostaa linkin ja sen kohteen yhdessä, ja VPN-skriptin omistama tavallinen tiedosto tarkoittaa, ettei ratkaisija koskaan käsittele kirjoitusta syötteenä. Tilatuloste luettelee linkkikohtaiset palvelimet sekä reititysdomainit, jotka päättävät mihin kukin kysely menee. nsswitch-rivi kertoo, konsultoidaanko stubia ylipäätään, joten stub-osoite tiedostossa ilman resolve tarkoittaa, että kyselyt saavuttavat paikallisen kuuntelijan, kun mikään ei hallitse jakoa. Myös viimeinen luettelo on tärkeä, koska kone ilman stub-resolv.conf ei aja tässä kuvattua järjestelyä.

Jos ketju päättyy tiedostoon, jota toinen paketti hallitsee, VPN-asiakas ja tämä paketti ovat ne kaksi omistajaa, jotka on sovitettava yhteen. Linkin korvaaminen heittää pois toisen omistajan työn ja jättää toisen työn paikalleen.

Korjaa linkin omistajan luona

VPN-yhteyden tulisi rekisteröidä palvelimensa ja domaininsa omalle linkilleen ja sitten vetää ne pois yhteyden katketessa. NetworkManagerin resolved-integraatio ja asiakkaan oma apuri toimivat molemmat näin; skripti, joka vain kirjoittaa uudelleen resolv.conf, ei toimi.

Jo olemassa olevalla linkillä mekanismin näyttää ajonaikainen asetus. resolvectl dns tun0 10.40.0.53 liittää palvelimen ja resolvectl domain tun0 '~corp.example' liittää reititysdomainin. Tilde on kantava merkki: se rajaa kyseisen päätteen kyselyt tälle linkille ja jättää kaiken muun rauhaan, kun taas sama arvo ilman sitä muuttuu hakudomainiksi ja jako haihtuu. Nuo osoitteet ovat laboratorioesimerkkejä, eivät pysyvä kokoonpano. Vahvista komennolla resolvectl query host.corp.example ja lue, mikä linkki vastasi.

Rekisteröity palvelin tarvitsee silti reitin. Kun kysely saavuttaa oikean linkin ja aikakatkaisee, vika on tunnelin läpi kulkevassa tavoitettavuudessa, ei ratkaisijan omistuksessa.

Miltä toimiva tila näyttää

Terve tulos on johdonmukainen kaikissa kolmessa näkymässä: linkkikohtaiset palvelimet vastaavat sitä, mitä VPN jakoi, reititysdomainit kattavat vain sisäiset päätteet ja ratkaiseva sovellus ratkaisee sisäisen nimen, kun julkinen nimi seuraa edelleen paikallista polkua. Yksi onnistunut kysely todistaa vähemmän kuin tämä yhdenmukaisuus.

Katkaise sitten yhteys ja toista molemmat kyselyt. Asiakas, joka jättää domaininsa rekisteröidyiksi purkamisen jälkeen, tuottaa koneen, joka epäonnistuu sisäisissä hauissa tunteja myöhemmin, ilman avointa tunnelia ja ilman ilmeistä syytä.