Waarom resolv.conf jou VPN se DNS wys maar opsoeke dit ignoreer

Niks in die logs lyk verkeerd nie: die koppelvlak is op, die oplosser rapporteer die VPN se DNS-bediener, en die lêer op skyf lys dit. Tog los 'n interne gasheernaam steeds deur die plaaslike router op. Die drie stellings weerspreek mekaar nie, want die lêer, die toestand per skakel en die opsoekpad is verskillende objekte wat toevallig dieselfde naam deel. Wat volg, is die pad wat 'n navraag werklik volg op 'n stelsel met systemd-resolved.

Drie objekte met die naam resolv.conf

Op 'n stelsel met resolved is /etc/resolv.conf gewoonlik 'n simboolskakel na /run/systemd/resolve/stub-resolv.conf. Daardie teiken hou die adres van 'n plaaslike stub-luisteraar, 127.0.0.53, plus die soekdomeine wat resolved bereken het. Dit is 'n aansig van die toestand, nie die toestand self nie.

Die toestand woon in resolved se konfigurasie per skakel, en daarom kan resolvectl status van die lêer verskil en tog reg wees. 'n Skakel dra sy eie bedieners en sy eie roetendomeine, en die stub raadpleeg daardie data per skakel wanneer 'n navraag opdaag. Die handleiding vir systemd-resolved beskryf die gegenereerde lêers en die model per skakel; die skeiding tussen aansig en toestand is die deel wat die moeite werd is om te onthou. Om die simboolskakel se teiken te wysig, verander wat tradisionele kliënte lees, nie wat die oplosser weet nie.

'n Derde objek, /run/systemd/resolve/resolv.conf, plat elke skakel tot een bedienerlys. 'n Program wat na daardie lêer wys, stuur navrae reguit na die gelyste bedieners en slaan die stub oor, so die beleid per skakel geld nie meer vir hom nie. Twee programme op dieselfde masjien kan dus dieselfde naam verskillend beantwoord, en nie een is stukkend nie.

Volg een opsoek deur NSS

glibc lees /etc/nsswitch.conf om te besluit wie 'n naam beantwoord. 'n Hosts-reël met resolve stuur die vraag na nss-resolve, wat resolved oor D-Bus vra en die antwoord per skakel kry. 'n Reël met net files dns stuur die navraag na watter adres /etc/resolv.conf ook al hou.

Daardie een reël verduidelik die meeste meningsverskille tussen 'n blaaier en dig. dig lees resolv.conf direk en raak nooit aan NSS nie, so dit toets die stub of 'n opstroom-bediener eerder as die pad wat die toepassing gebruik. getent hosts internal.example gaan deur NSS, en om sy antwoord met dig s'n te vergelyk is die eerste nuttige meting.

Toepassings wat 'n oplosser saambring, of DNS oor HTTPS praat met 'n vaste eindpunt, omseil albei paaie. Niks in resolv.conf of in die resolved-toestand bind hulle nie.

Kyk wie die lêer besit en waarheen dit wys

Lees die skakelketting voordat jy iets verander, want eienaarskap besluit watter lêer gesag het. Elke opdrag hieronder lees net toestand.

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

Die eerste reël druk die skakel en sy teiken saam, en 'n gewone lêer wat deur 'n VPN-skrip besit word, beteken die oplosser behandel nooit daardie skryf as invoer nie. Die status-uitset lys bedieners per skakel plus die roetendomeine wat besluit waar elke navraag heen gaan. Die nsswitch-reël sê of die stub hoegenaamd geraadpleeg word, so 'n stub-adres in die lêer sonder resolve daar beteken navrae bereik die plaaslike luisteraar terwyl niks die splitsing bestuur nie. Daardie laaste lys maak ook saak, want 'n stelsel sonder stub-resolv.conf hardloop nie die reëling wat hier beskryf word nie.

As die ketting by 'n lêer eindig wat 'n ander pakket bestuur, is die VPN-kliënt en daardie pakket die twee eienaars wat versoen moet word. Om die skakel te vervang gooi een eienaar se werk weg en laat die ander s'n in plek.

Herstel by die eienaar van die skakel

'n VPN-verbinding behoort sy bedieners en sy domeine op sy eie skakel te registreer en dit dan by ontkoppeling terug te trek. NetworkManager se integrasie met resolved en 'n kliënt se eie helper werk albei so; 'n skrip wat net resolv.conf herskryf, doen dit nie.

Op 'n skakel wat reeds bestaan, wys die tydkonfigurasie die meganisme. resolvectl dns tun0 10.40.0.53 heg 'n bediener, en resolvectl domain tun0 '~corp.example' heg 'n roetendomein. Die tilde is die draende karakter: dit beperk navrae vir daardie agtervoegsel tot hierdie skakel en laat alles anders met rus, terwyl dieselfde waarde sonder dit 'n soekdomein word en die splitsing verdamp. Daardie adresse is laboratoriumvoorbeelde, nie 'n blywende konfigurasie nie. Bevestig met resolvectl query host.corp.example en lees watter skakel geantwoord het.

'n Geregistreerde bediener het steeds 'n roete nodig. Wanneer die navraag die regte skakel bereik en tyd uitloop, is die fout bereikbaarheid deur die tonnel eerder as eienaarskap van die oplosser.

Hoe 'n werkende toestand lyk

'n Gesonde resultaat is konsekwent oor al drie aansigte: die bedieners per skakel stem ooreen met wat die VPN uitgedeel het, die roetendomeine dek net interne agtervoegsels, en die toepassing wat saak maak, los 'n interne naam op terwyl 'n openbare naam steeds die plaaslike pad volg. Een suksesvolle navraag bewys minder as daardie ooreenkoms.

Ontkoppel dan en herhaal albei navrae. 'n Kliënt wat sy domeine ná afbreek geregistreer laat, lewer 'n masjien wat ure later interne opsoeke faal, met geen tonnel oop en geen ooglopende oorsaak nie.