Stop twee Linux-services die om /etc/resolv.conf strijden

DNS valt steeds terug, de VPN-herverbinding maakt uw correctie ongedaan, en uiteindelijk stelt iemand in het team voor om het bestand te vergrendelen. Die reeks is een symptoom, geen oplossing: twee componenten menen beide dat /etc/resolv.conf van hen is, en wie het laatst schrijft, wint. Het bestand vergrendelen lost het eigenaarsconflict niet op; het verbergt het alleen en breekt tegelijk de component die u eigenlijk wilde. Werk de vier controles hieronder in volgorde af en herstel de inrichting op het niveau dat haar bezit, niet bij het bestand.

Controle 1: is het een symlink, en waarnaar

Begin bij het bestand zelf, want het pad dat u bewerkt is misschien helemaal niet het bestand. Een symlink naar de runtime-map van een resolver gedraagt zich heel anders dan een gewoon bestand dat een clientscript herschrijft:

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

Een link naar een stub-pad van systemd-resolved betekent dat de inhoud van het bestand wordt gegenereerd, en handmatige bewerking wordt bij de volgende gebeurtenis overschreven. Een gewoon bestand met nameserver-regels wordt meestal geschreven door de client of DHCP-hook die bij verbinding draait. Beide zijn legitiem; wat telt is weten welke u hebt voordat u iets verandert.

Controle 2: welke daemon draait er

Zoek uit wat werkelijk actief is, niet wat geïnstalleerd is. Op een moderne distributie kunnen meerdere resolvers aanwezig zijn, en degene die poort 53 op de loopback-interface vasthoudt, is degene die antwoordt:

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

De statusuitvoer noemt de DNS-servers per koppeling en de routeringsdomeinen, en dat is de kaart die u nodig hebt voor split DNS. Als interne namen naar een interne server moeten en al het andere naar een publieke, leeft dat beleid in de domeinen per koppeling, en het afvlakken daarvan naar een statische nameserver-lijst in het bestand verliest dat onderscheid stilzwijgend.

De eigen configuratie van NetworkManager bepaalt welke van deze backends hij gebruikt. De instelling dns= in het hoofdconfiguratiebestand kiest tussen zijn interne resolver, dnsmasq, systemd-resolved en none, en een distributie heeft misschien voor u gekozen. Lees die instelling voordat u beslist wat “DNS repareren” op deze host betekent.

Controle 3: wat de VPN-client mag schrijven

Hier leeft het conflict meestal. Een VPN-client die het resolverbestand rechtstreeks herschrijft, vecht met elke service die het ook onderhoudt, en de verliezer is degene die als eerste draait. Recente OpenVPN-versies kunnen de DNS-instellingen aan systemd-resolved geven in plaats van het bestand te herschrijven, en dat is het samenwerkende gedrag dat u wilt; oudere scripts en handgeschreven hooks roepen vaak een verouderd hulpprogramma aan of overschrijven simpelweg het bestand.

De situatie van WireGuard is qua vorm vergelijkbaar: de interfaceconfiguratie zelf beheert geen DNS, de hulpmiddelen eromheen doen dat, via een resolver-helper of de resolved-integratie. Als twee zulke helpers zijn geïnstalleerd, proberen beide bij verbinding hun wereldbeeld toe te passen.

Lees de up- en down-hooks van de client in plaats van te gissen. Een paar regels shell in /etc/openvpn/up.sh of een gelijkwaardige map verklaren gedrag dat er anders willekeurig uitziet, en daar kunt u de client ook laten samenwerken in plaats van concurreren.

Controle 4: herstel het bij de eigenaar, niet in het bestand

Zodra u de eigenaar kent, configureert u DNS via de door die eigenaar ondersteunde interface. Voor systemd-resolved betekent dat instellingen per koppeling en routeringsdomeinen in plaats van een statisch bestand; voor NetworkManager de DNS-instellingen van het verbindingsprofiel en de gekozen backend; voor een distributie met resolvconf-integratie het schrijven via die helper.

Maak het bestand niet onveranderlijk. Het onveranderlijkheidsattribuut stopt legitieme DHCP-vernieuwingen en VPN-updates samen met degene waartegen u streed, en het laat het systeem achter in een toestand waarin de volgende pakketupgrade of herverbinding een storing veroorzaakt die niemand uit de configuratie kan verklaren. Het verbergt het eigenaarsconflict, precies hetgeen u probeerde op te lossen.

Waar twee componenten echt moeten samengaan, geef ze verschillende taken. Laat de netwerkbeheerder de configuratie op interfaceniveau bezitten, laat de VPN-client DNS en domeinen per koppeling bijdragen via dezelfde integratie, en verwijder het derde script dat het bestand rechtstreeks schrijft. De systemd-resolved-documentatie beschrijft de modi die hij ondersteunt en wat elk daarvan in /etc/resolv.conf zichtbaar maakt. Kies de modus die past bij hoeveel beleid u moet behouden. Als split DNS belangrijk is, behoudt de stub-opzet met domeinen per koppeling dat, terwijl de modus die upstream-servers in het bestand kopieert het stilzwijgend afvlakt.

Controleer na een herverbinding, niet na de bewerking

Een bestand dat direct na uw wijziging correct lijkt, bewijst niets, want de volgende gebeurtenis heeft nog niet plaatsgevonden. Activeer de reeks die het vroeger brak: haal de tunnel neer en weer op, vernieuw de DHCP-lease of wissel de interface, en lees daarna dezelfde waarden opnieuw.

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

Bevestig dan het onderscheid dat ertoe doet: de interne naam wordt via de interne server opgelost terwijl de publieke naam nog werkt. Een configuratie die alles naar de interne server stuurt, ziet er goed uit tot iemand via de tunnel het internet probeert te bereiken, en een configuratie die alles naar de publieke stuurt, lekt interne namen.

Noteer de eigenaar, de backend en de symlink-modus in de implementatienotities. Die ene alinea maakt van een toekomstige pakketupgrade een controlepunt in plaats van een incident, en voorkomt dat de volgende persoon hetzelfde conflict opnieuw ontdekt met een chattr-commando.