Stopp to Linux-tenester som kjempar om /etc/resolv.conf

DNS fell stadig tilbake, VPN-attilkoplinga angrar rettinga di, og til slutt føreslår nokon på laget å låse fila. Den sekvensen er eit symptom, ikkje ei løysing: to komponentar meiner begge at dei eig /etc/resolv.conf, og den som skriv sist, vinn. Å låse fila løyser ikkje eigarskapskonflikten; det skjuler han berre og øydelegg samstundes komponenten du eigentleg ville ha. Gå gjennom dei fire kontrollane nedanfor i rekkjefølgje, og rett opp ordninga på nivået som eig henne, ikkje på fila.

Kontroll 1: er det ei symbolsk lenkje, og til kva

Byrja med sjølve fila, for stien du redigerer er kanskje ikkje fila i det heile. Ei symbolsk lenkje inn i runtime-katalogen til ein resolver oppfører seg heilt annleis enn ei vanleg fil som eit klientskript skriv på nytt:

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

Ei lenkje til ein stub-sti hos systemd-resolved betyr at innhaldet i fila vert generert, og manuell redigering vil verte overstyrt ved neste hending. Ei vanleg fil med nameserver-linjer vert vanlegvis skriven av den klienten eller DHCP-kroken som køyrer ved tilkopling. Begge er legitime; det viktige er å vite kva du har før du endrar noko.

Kontroll 2: kva daemon som køyrer

Finn ut kva som faktisk er aktivt, ikkje kva som er installert. Det kan vere fleire resolverar på ein moderne distribusjon, og den som held port 53 på loopback-grensesnittet, er den som svarar:

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

Statusutdataa namngjev DNS-tenarane per lenkje og rutingsdomena, som er kartet du treng for delt DNS. Viss interne namn må gå til ein intern tenar og alt anna til ein offentleg, lever den policyen i domena per lenkje, og å flate henne ut til ei statisk nameserver-liste i fila mistar denne skilnaden lydlaust.

NetworkManagers eigen konfigurasjon avgjer kva av desse backenda han brukar. Innstillinga dns= i hovudkonfigurasjonsfila vel mellom den interne resolveren hans, dnsmasq, systemd-resolved og none, og ein distribusjon kan ha valt for deg. Les den innstillinga før du avgjer kva «å reparere DNS» tyder på denne verten.

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

Det er her konflikten vanlegvis bur. Ein VPN-klient som skriv resolverfila direkte på nytt, vil kjempe mot kvar teneste som også vedlikeheld henne, og taparen er den som køyrer først. Nyare OpenVPN-utgåver kan gje DNS-innstillingane til systemd-resolved i staden for å skrive fila på nytt, og det er den samarbeidande åtferda du vil ha; eldre skript og handskrivne krokar kallar ofte eit utdatert hjelpeverktøy eller overskriv rett og slett fila.

Situasjonen til WireGuard liknar i forma: sjølve grensesnittkonfigurasjonen styrer ikkje DNS, det gjer verktøya rundt henne, via ein resolver-hjelpar eller resolved-integreringa. Viss to slike hjelparar er installerte, vil begge prøve å handheve sitt verdsbilete ved tilkopling.

Les up- og down-krokane til klienten i staden for å gisse. Nokre linjer shell i /etc/openvpn/up.sh eller ein tilsvarande katalog forklarar åtferd som elles verkar tilfeldig, og det er også staden der du kan få klienten til å samarbeide i staden for å konkurrere.

Kontroll 4: rett det hos eigaren, ikkje i fila

Når du kjenner eigaren, konfigurerer du DNS gjennom grensesnittet til den eigaren. For systemd-resolved tyder det innstillingar per lenkje og rutingsdomen, i staden for ei statisk fil; for NetworkManager tyder det DNS-innstillingane til tilkoplingsprofilen og den valde backenden; for ein distribusjon med resolvconf-integrering tyder det å skrive gjennom den hjelparen.

Ikkje gjer fila uforanderleg. Det uforanderlege attributtet stoppar legitime DHCP-fornyingar og VPN-oppdateringar saman med dei du kjempa mot, og det lèt systemet att i ein tilstand der den neste pakkeoppgraderinga eller attilkoplinga gjev ein feil ingen kan forklare ut frå konfigurasjonen. Det skjuler eigarskapskonflikten, som nettopp er det du prøvde å løyse.

Der to komponentar verkeleg må eksistere side om side, gje dei ulike oppgåver. Lat nettverksadministratoren eige konfigurasjonen på grensesnittnivå, lat VPN-klienten bidra med DNS og domen per lenkje gjennom den same integreringa, og fjern det tredje skriptet som skriv fila direkte. systemd-resolved-dokumentasjonen skildrar modusane han støttar og kva kvar av dei viser i /etc/resolv.conf. Vel modusen som passar til kor mykje policy du må halde på. Viss delt DNS er viktig, bevarer stub-ordninga med domen per lenkje han, medan modusen som kopierer oppstraums-tenarar inn i fila, lydlaust flatar han ut.

Stadfest etter ei attilkopling, ikkje etter redigeringa

Ei fil som ser rett ut rett etter endringa di, beviser ingenting, for den neste hendinga har ikkje skjedd enno. Utløys sekvensen som pleidde å øydeleggje henne: ta tunnelen ned og opp, forny DHCP-leasa eller byt grensesnitt, og les deretter dei same verdiane på nytt.

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

Stadfest så skilnaden som betyr noko: det interne namnet vert slått opp via den interne tenaren medan det offentlege namnet framleis verkar. Ein konfigurasjon som sender alt til den interne tenaren, ser fin ut heilt til nokon prøver å nå internett gjennom tunnelen, og ein konfigurasjon som sender alt til den offentlege, lek interne namn.

Noter eigaren, backenden og symlink-modusen i distribusjonsnotata. Det eine avsnittet gjer ei framtidig pakkeoppgradering frå ei hending til eit gjennomgangspunkt, og det hindrar den neste personen i å oppdage den same konflikten på nytt med ein chattr-kommando.