Stop to Linux-tjenester der kæmper om /etc/resolv.conf

DNS falder hele tiden tilbage, VPN-genopkoblingen annullerer din rettelse, og til sidst foreslår nogen i teamet at låse filen. Den sekvens er et symptom, ikke en løsning: to komponenter mener begge, at de ejer /etc/resolv.conf, og den, der skriver sidst, vinder. At låse filen løser ikke ejerskabskonflikten; det skjuler den bare, mens det ødelægger den komponent, du faktisk ville have. Gå de fire kontroller nedenfor igennem i rækkefølge, og ret indretningen på det niveau, der ejer den, ikke på filen.

Kontrol 1: er det et symbolsk link, og til hvad

Begynd med selve filen, for den sti, du redigerer, er måske slet ikke filen. Et symbolsk link ind i en resolvers runtime-mappe opfører sig helt anderledes end en almindelig fil, som et klientscript skriver igen:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Et link til en stub-sti under systemd-resolved betyder, at filens indhold genereres, og manuel redigering vil blive overskrevet ved næste hændelse. En almindelig fil med nameserver-linjer skrives normalt af den klient- eller DHCP-hook, der kører ved forbindelse. Begge er legitime; det vigtige er at vide, hvilken du har, før du ændrer noget.

Kontrol 2: hvilken daemon kører

Find ud af, hvad der faktisk er aktivt, ikke hvad der er installeret. Der kan være flere resolvere på en moderne distribution, og den, der holder port 53 på loopback-interfacet, er den, der svarer:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Statusoutputtet navngiver DNS-serverne pr. link og routing-domænerne, hvilket er det kort, du har brug for til split DNS. Hvis interne navne skal gå til en intern server og alt andet til en offentlig, lever den politik i domænerne pr. link, og hvis du flader den ud til en statisk nameserver-liste i filen, mister du lydløst forskellen.

NetworkManagers egen konfiguration afgør, hvilken af disse backends den bruger. Dens dns=-indstilling i hovedkonfigurationsfilen vælger mellem dens interne resolver, dnsmasq, systemd-resolved og ingen, og en distribution kan have valgt for dig. Læs den indstilling, før du beslutter, hvad “at rette DNS” betyder på denne vært.

Kontrol 3: hvad VPN-klienten må skrive

Det er her, konflikten normalt bor. En VPN-klient, der skriver resolverfilen direkte igen, vil kæmpe med enhver tjeneste, der også vedligeholder den, og taberen er den, der kører først. Nyere OpenVPN-udgivelser kan give DNS-indstillingerne til systemd-resolved i stedet for at skrive filen igen, hvilket er den samarbejdende adfærd, du ønsker; ældre scripts og håndskrevne hooks kalder ofte et forældet hjælpeværktøj eller overskriver bare filen.

WireGuards situation ligner i form: selve interface-konfigurationen styrer ikke DNS, det gør værktøjerne omkring den, via en resolver-hjælper eller resolved-integrationen. Hvis to sådanne hjælpere er installeret, vil begge forsøge at gennemtvinge deres verdenssyn ved forbindelse.

Læs klientens up- og down-hooks i stedet for at gætte. Et par linjer shell i /etc/openvpn/up.sh eller en tilsvarende mappe forklarer adfærd, der ellers ser tilfældig ud, og de er også stedet, hvor du kan få klienten til at samarbejde i stedet for at konkurrere.

Kontrol 4: ret det hos ejeren, ikke i filen

Når du kender ejeren, konfigurerer du DNS gennem den ejers understøttede interface. For systemd-resolved betyder det indstillinger pr. link og routing-domæner i stedet for en statisk fil; for NetworkManager betyder det forbindelsesprofilens DNS-indstillinger og den valgte backend; for en distribution med resolvconf-integration betyder det at skrive gennem den hjælper.

Gør ikke filen uforanderlig. Det uforanderlige attribut stopper legitime DHCP-fornyelser og VPN-opdateringer sammen med dem, du kæmpede imod, og det efterlader systemet i en tilstand, hvor den næste pakkeopgradering eller genopkobling giver en fejl, som ingen kan forklare ud fra konfigurationen. Det skjuler ejerskabskonflikten, som netop er det, du prøvede at løse.

Hvor to komponenter virkelig skal sameksistere, giv dem forskellige opgaver. Lad netværksadministratoren eje konfigurationen på interface-niveau, lad VPN-klienten bidrage med DNS og domæner pr. link gennem den samme integration, og fjern det tredje script, der skriver filen direkte. systemd-resolved-dokumentationen beskriver de tilstande, den understøtter, og hvad hver af dem viser i /etc/resolv.conf. Vælg den tilstand, der passer til, hvor meget politik du skal beholde. Hvis split DNS er vigtigt, bevarer stub-indretningen med domæner pr. link det, mens den tilstand, der kopierer upstream-servere ind i filen, lydløst flader det ud.

Bekræft efter en genopkobling, ikke efter redigeringen

En fil, der ser rigtig ud lige efter din ændring, beviser intet, for den næste hændelse er ikke sket endnu. Udløs den sekvens, der plejede at ødelægge den: tag tunnelen ned og op, forny DHCP-leasen eller skift interface, og læs derefter de samme værdier igen.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Bekræft så den forskel, der betyder noget: det interne navn slås op via den interne server, mens det offentlige navn stadig virker. En konfiguration, der sender alt til den interne server, ser fin ud, indtil nogen prøver at nå internettet gennem tunnelen, og en konfiguration, der sender alt til den offentlige, lækker interne navne.

Notér ejeren, backenden og symlink-tilstanden i udrulningsnoterne. Det ene afsnit gør en fremtidig pakkeopgradering fra en hændelse til et gennemgangspunkt, og det forhindrer den næste person i at genopdage den samme konflikt med en chattr-kommando.