Stopp to Linux-tjenester som kjemper om /etc/resolv.conf

DNS faller stadig tilbake, VPN-gjenoppkoblingen angrer rettelsen din, og til slutt foreslår noen på teamet å låse filen. Den sekvensen er et symptom, ikke en løsning: to komponenter mener begge at de eier /etc/resolv.conf, og den som skriver sist, vinner. Å låse filen løser ikke eierskapskonflikten; det skjuler den bare og ødelegger samtidig komponenten du egentlig ville ha. Gå gjennom de fire kontrollene nedenfor i rekkefølge, og rett opp ordningen på nivået som eier den, ikke på filen.

Kontroll 1: er det en symbolsk lenke, og til hva

Begynn med selve filen, for stien du redigerer er kanskje ikke filen i det hele tatt. En symbolsk lenke inn i en resolvers runtime-katalog oppfører seg helt annerledes enn en vanlig fil som et klientskript skriver på nytt:

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

En lenke til en stub-sti hos systemd-resolved betyr at innholdet i filen genereres, og manuell redigering vil bli overskrevet ved neste hendelse. En vanlig fil med nameserver-linjer skrives vanligvis av den klienten eller DHCP-kroken som kjører ved tilkobling. Begge er legitime; det viktige er å vite hvilken du har før du endrer noe.

Kontroll 2: hvilken daemon som kjører

Finn ut hva som faktisk er aktivt, ikke hva som er installert. Det kan være flere resolvere på en moderne distribusjon, og den som holder port 53 på loopback-grensesnittet, er den som svarer:

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

Statusutdataene navngir DNS-serverne per lenke og rutingsdomenene, som er kartet du trenger for delt DNS. Hvis interne navn må gå til en intern server og alt annet til en offentlig, lever den policyen i domenene per lenke, og å flate den ut til en statisk nameserver-liste i filen mister denne forskjellen lydløst.

NetworkManagers egen konfigurasjon avgjør hvilken av disse backendene den bruker. Innstillingen dns= i hovedkonfigurasjonsfilen velger mellom dens interne resolver, dnsmasq, systemd-resolved og none, og en distribusjon kan ha valgt for deg. Les den innstillingen før du bestemmer hva «å reparere DNS» betyr på denne verten.

Kontroll 3: hva VPN-klienten har lov til å skrive

Det er her konflikten vanligvis bor. En VPN-klient som skriver resolverfilen direkte på nytt, vil kjempe mot enhver tjeneste som også vedlikeholder den, og taperen er den som kjører først. Nyere OpenVPN-utgivelser kan gi DNS-innstillingene til systemd-resolved i stedet for å skrive filen på nytt, og det er den samarbeidende oppførselen du vil ha; eldre skript og håndskrevne kroker kaller ofte et utdatert hjelpeverktøy eller overskriver rett og slett filen.

WireGuards situasjon ligner i formen: selve grensesnittkonfigurasjonen styrer ikke DNS, det gjør verktøyene rundt den, via en resolver-hjelper eller resolved-integrasjonen. Hvis to slike hjelpere er installert, vil begge prøve å håndheve sitt verdensbilde ved tilkobling.

Les klientens up- og down-kroker i stedet for å gjette. Noen linjer shell i /etc/openvpn/up.sh eller en tilsvarende katalog forklarer atferd som ellers virker tilfeldig, og det er også stedet der du kan få klienten til å samarbeide i stedet for å konkurrere.

Kontroll 4: rett det hos eieren, ikke i filen

Når du kjenner eieren, konfigurerer du DNS gjennom den eierens støttede grensesnitt. For systemd-resolved betyr det innstillinger per lenke og rutingsdomener i stedet for en statisk fil; for NetworkManager betyr det tilkoblingsprofilens DNS-innstillinger og den valgte backenden; for en distribusjon med resolvconf-integrasjon betyr det å skrive gjennom den hjelperen.

Ikke gjør filen uforanderlig. Det uforanderlige attributtet stopper legitime DHCP-fornyelser og VPN-oppdateringer sammen med dem du kjempet mot, og det etterlater systemet i en tilstand der den neste pakkeoppgraderingen eller gjenoppkoblingen gir en feil ingen kan forklare ut fra konfigurasjonen. Det skjuler eierskapskonflikten, som nettopp er det du prøvde å løse.

Der to komponenter virkelig må eksistere side om side, gi dem forskjellige oppgaver. La nettverksadministratoren eie konfigurasjonen på grensesnittnivå, la VPN-klienten bidra med DNS og domener per lenke gjennom den samme integrasjonen, og fjern det tredje skriptet som skriver filen direkte. systemd-resolved-dokumentasjonen beskriver modusene den støtter og hva hver av dem viser i /etc/resolv.conf. Velg modusen som passer til hvor mye policy du må beholde. Hvis delt DNS er viktig, bevarer stub-ordningen med domener per lenke den, mens modusen som kopierer oppstrøms-servere inn i filen, lydløst flater den ut.

Verifiser etter en gjenoppkobling, ikke etter redigeringen

En fil som ser riktig ut rett etter endringen din, beviser ingenting, for den neste hendelsen har ikke skjedd ennå. Utløs sekvensen som pleide å ødelegge den: ta tunnelen ned og opp, forny DHCP-leasen eller bytt grensesnitt, og les deretter de samme verdiene på nytt.

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

Bekreft så forskjellen som betyr noe: det interne navnet slås opp via den interne serveren mens det offentlige navnet fortsatt virker. En konfigurasjon som sender alt til den interne serveren, ser fin ut helt til noen prøver å nå internett gjennom tunnelen, og en konfigurasjon som sender alt til den offentlige, lekker interne navn.

Noter eieren, backenden og symlink-modusen i distribusjonsnotatene. Det ene avsnittet gjør en fremtidig pakkeoppgradering fra en hendelse til et gjennomgangspunkt, og det hindrer den neste personen i å gjenoppdage den samme konflikten med en chattr-kommando.