Wêrom't resolv.conf dyn VPN-DNS sjen lit, mar sykjen it negearret

Yn 'e logs liket neat ferkeard: de ynterface is oan, de resolver meldt de DNS-server fan 'e VPN, en it bestân op skiif neamt him. Dochs wurdt in ynterne hostnamme noch altyd fia de lokale router oplost. Dy trije bewearings sprekke elkoar net tsjin, om't it bestân, de tastân per keppeling en it sykpaad ferskate objekten binne dy't tafallich deselde namme diele. Hjirnei folget it paad dat in fraach eins nimt op in host mei systemd-resolved.

Trije objekten mei de namme resolv.conf

Op in host mei resolved is /etc/resolv.conf meastentiids in symboalyske keppeling nei /run/systemd/resolve/stub-resolv.conf. Dat doel hâldt it adres fan in lokale stub-harker, 127.0.0.53, plus de sykdomeinen dy't resolved berekkene hat. It is in byld fan 'e tastân, net de tastân sels.

De tastân libbet yn 'e konfiguraasje fan resolved per keppeling, en dêrom kin resolvectl status fan it bestân ferskille en dochs gelyk hawwe. In keppeling draacht syn eigen servers en syn eigen routingdomeinen, en de stub rieplachtet dy gegevens as in fraach binnenkomt. De hânlieding foar systemd-resolved beskriuwt de generearre bestannen en it model per keppeling; de skieding tusken byld en tastân is it part dat it ûnthâlden wurdich is. It doel fan 'e symboalyske keppeling feroarje feroaret wat tradisjonele kliïnten lêze, net wat de resolver wit.

In tredde objekt, /run/systemd/resolve/resolv.conf, flakket elke keppeling ta ien serverlist. In programma dat nei dat bestân wiist, stjoert fragen streekrjocht nei de neamde servers en slacht de stub oer, sadat it belied per keppeling net mear foar him jildt. Twa programma's op deselde masine kinne dus itselde namme ferskillend beäntwurdzje, en gjinien is stikken.

Folgje ien sykjen troch NSS

glibc lêst /etc/nsswitch.conf om te besluten wa't in namme beäntwurdet. In hosts-rigel mei resolve stjoert de fraach nei nss-resolve, dy't resolved oer D-Bus freget en it antwurd per keppeling krijt. In rigel mei allinnich files dns stjoert de fraach nei it adres dat /etc/resolv.conf hâldt.

Dizze iene rigel ferklearret de measte meningsferskillen tusken in browser en dig. dig lêst resolv.conf streekrjocht en rekket NSS nea oan, dus testet it de stub of in boppesteande server yn stee fan it paad dat de applikaasje brûkt. getent hosts internal.example giet troch NSS, en it antwurd dêrfan fergelykje mei dat fan dig is de earste nuttige mjitting.

Applikaasjes dy't in eigen resolver meinimme, of DNS oer HTTPS prate mei in fêst einpunt, geane beide paden foarby. Neat yn resolv.conf of yn 'e tastân fan resolved beheint har.

Kontrolearje wa't it bestân besit en wêr't it hinne wiist

Lês de keppelingkeatling foardat jo eat feroarje, om't eigendom beslút hokker bestân autoritatyf is. Elk kommando hjirûnder lêst allinnich tastân.

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

De earste rigel printsje de keppeling en syn doel tegearre, en in gewoan bestân dat eigendom is fan in VPN-skript betsjut dat de resolver dy skriuwing nea as ynfier behannelet. De statusútfier neamt servers per keppeling plus de routingdomeinen dy't beslute wêr't elke fraach hinne giet. De nsswitch-rigel seit oft de stub hielendal rieplachte wurdt, dus in stub-adres yn it bestân sûnder resolve dêr betsjut dat fragen de lokale harker berikke wylst neat de splitsing beheart. Dy lêste list is ek wichtich, om't in host sûnder stub-resolv.conf de hjir beskreaune regeling net draait.

As de keatling einiget by in bestân dat in oar pakket beheart, binne de VPN-kliïnt en dat pakket de twa eigners dy't ferienige wurde moatte. De keppeling ferfange smyt it wurk fan 'e iene eigner fuort en lit dat fan 'e oare stean.

Reparearje by de eigner fan 'e keppeling

In VPN-ferbining heart har servers en har domeinen op har eigen keppeling te registrearjen en se dan by it ôfbrekken werom te lûken. De resolved-ynbou fan NetworkManager en de eigen helper fan in kliïnt wurkje beide sa; in skript dat allinnich resolv.conf oerskriuwt, docht dat net.

Op in keppeling dy't al bestiet, lit de runtime-ynstelling it meganisme sjen. resolvectl dns tun0 10.40.0.53 ferbynt in server, en resolvectl domain tun0 '~corp.example' ferbynt in routingdomein. De tilde is it dragende teken: it beheint fragen foar dat efterheaksel ta dizze keppeling en lit al it oare gewurde, wylst deselde wearde sûnder it in sykdomein wurdt en de splitsing ferdampt. Dy adressen binne laboratoariumfoarbylden, net in bliuwende konfiguraasje. Befêstigje mei resolvectl query host.corp.example en lês hokker keppeling antwurde.

In registrearre server hat noch altyd in rûte nedich. As de fraach de juste keppeling berikt en tiid útrint, leit de flater yn berikberens troch de tunnel en net yn eigendom fan 'e resolver.

Hoe't in wurkjende tastân der útsjocht

In sûn resultaat is konsekwint oer alle trije bylden: de servers per keppeling komme oerien mei wat de VPN útjûn hat, de routingdomeinen dekke allinnich ynterne efterheaksels, en de applikaasje dy't fan belang is lost in ynterne namme op wylst in iepenbiere namme noch it lokale paad folget. Ien suksesfolle fraach bewiist minder as dy oerienkomst.

Briek dan ôf en werhelje beide fragen. In kliïnt dy't syn domeinen nei it ôfbrekken registrearre lit, produsearret in masine dy't oeren letter ynterne sykjen misse, sûnder iepen tunnel en sûnder dúdlike oarsaak.