Stoppa två Linux-tjänster som slåss om /etc/resolv.conf

DNS faller hela tiden tillbaka, VPN-återanslutningen ångrar din rättelse, och till slut föreslår någon i teamet att låsa filen. Den sekvensen är ett symptom, inte en lösning: två komponenter anser båda att de äger /etc/resolv.conf, och den som skriver sist vinner. Att låsa filen löser inte ägarkonflikten, det döljer den bara och bryter samtidigt komponenten du egentligen ville ha. Gå igenom de fyra kontrollerna nedan i ordning och rätta till ordningen på den nivå som äger den, inte på filen.

Kontroll 1: är det en symbolisk länk, och till vad

Börja med själva filen, för sökvägen du redigerar är kanske inte filen alls. En symbolisk länk in i en resolvers runtime-katalog beter sig helt annorlunda än en vanlig fil som ett klientskript skriver om:

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

En länk till en stub-sökväg hos systemd-resolved betyder att filens innehåll genereras, och manuell redigering skrivs över vid nästa händelse. En vanlig fil med nameserver-rader skrivs oftast av den klient eller DHCP-krok som körs vid anslutning. Båda är legitima; det viktiga är att veta vilken du har innan du ändrar något.

Kontroll 2: vilken daemon som körs

Ta reda på vad som faktiskt är aktivt, inte vad som är installerat. Det kan finnas flera resolvers på en modern distribution, och den som håller port 53 på loopback-gränssnittet är den som svarar:

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

Statusutdata namnger DNS-servrarna per länk och routingdomänerna, vilket är kartan du behöver för delad DNS. Om interna namn måste gå till en intern server och allt annat till en offentlig, lever den policyn i domänerna per länk, och att platta till den i en statisk nameserver-lista i filen tappar den distinktionen tyst.

NetworkManagers egen konfiguration avgör vilken av dessa backends den använder. Inställningen dns= i huvudkonfigurationsfilen väljer mellan dess interna resolver, dnsmasq, systemd-resolved och none, och en distribution kan ha valt åt dig. Läs den inställningen innan du bestämmer vad ”att reparera DNS” innebär på den här värden.

Kontroll 3: vad VPN-klienten får skriva

Det är här konflikten oftast bor. En VPN-klient som skriver om resolverfilen direkt kommer att slåss mot varje tjänst som också underhåller den, och förloraren är den som körs först. Nyare OpenVPN-versioner kan lämna DNS-inställningarna till systemd-resolved i stället för att skriva om filen, vilket är det samarbetande beteende du vill ha; äldre skript och handskrivna krokar anropar ofta ett föråldrat hjälpverktyg eller skriver helt enkelt över filen.

WireGuards situation liknar till formen: själva gränssnittskonfigurationen hanterar inte DNS, det gör verktygen runt den, via en resolver-hjälpare eller resolved-integrationen. Om två sådana hjälpare är installerade kommer båda att försöka genomdriva sin världsbild vid anslutning.

Läs klientens up- och down-krokar i stället för att gissa. Några rader shell i /etc/openvpn/up.sh eller en motsvarande katalog förklarar ett beteende som annars verkar slumpmässigt, och det är också där du kan få klienten att samarbeta i stället för att konkurrera.

Kontroll 4: rätta det hos ägaren, inte i filen

När du känner ägaren konfigurerar du DNS via det gränssnitt som ägaren stöder. För systemd-resolved innebär det inställningar per länk och routingdomäner i stället för en statisk fil; för NetworkManager innebär det anslutningsprofilens DNS-inställningar och den valda backenden; för en distribution med resolvconf-integration innebär det att skriva genom den hjälparen.

Gör inte filen oföränderlig. Det oföränderliga attributet stoppar legitima DHCP-förnyelser och VPN-uppdateringar tillsammans med dem du kämpade mot, och det lämnar systemet i ett tillstånd där nästa paketuppgradering eller återanslutning ger ett fel som ingen kan förklara utifrån konfigurationen. Det döljer ägarkonflikten, vilket är precis det du försökte lösa.

Där två komponenter verkligen måste samexistera, ge dem olika uppgifter. Låt nätverkshanteraren äga konfigurationen på gränssnittsnivå, låt VPN-klienten bidra med DNS och domäner per länk genom samma integration, och ta bort det tredje skriptet som skriver filen direkt. systemd-resolved-dokumentationen beskriver de lägen den stöder och vad var och en av dem visar i /etc/resolv.conf. Välj det läge som passar hur mycket policy du behöver behålla. Om delad DNS är viktigt bevarar stub-uppsättningen med domäner per länk det, medan läget som kopierar uppströmservrar till filen tyst plattar till det.

Verifiera efter en återanslutning, inte efter redigeringen

En fil som ser korrekt ut direkt efter din ändring bevisar ingenting, för nästa händelse har inte inträffat ännu. Utlös sekvensen som brukade bryta den: ta ner och upp tunneln, förnya DHCP-lånet eller växla gränssnittet, och läs sedan samma värden igen.

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

Bekräfta sedan den skillnad som spelar roll: det interna namnet löses via den interna servern medan det publika namnet fortfarande fungerar. En konfiguration som skickar allt till den interna servern ser bra ut tills någon försöker nå internet genom tunneln, och en konfiguration som skickar allt till den publika läcker interna namn.

Anteckna ägaren, backenden och symlink-läget i driftsättningsanteckningarna. Det enda stycket gör en framtida paketuppgradering från en incident till en granskningspost, och det hindrar nästa person från att återupptäcka samma konflikt med ett chattr-kommando.