Stop twee Linux-dienste wat om /etc/resolv.conf meeding

DNS bly terugkeer, die VPN-herverbinding maak jou regstelling ongedaan, en iemand in die span stel uiteindelik voor om die lêer te sluit. Daardie reeks is 'n simptoom, nie 'n oplossing nie: twee komponente meen albei dat hulle /etc/resolv.conf besit, en die een wat laaste skryf, wen. Om die lêer te sluit los nie die eienaarskonflik op nie; dit verberg dit net terwyl dit die komponent breek wat jy eintlik wou hê. Werk die vier kontroles hieronder in volgorde deur, en regstel die reëling op die vlak wat dit besit, nie by die lêer nie.

Kontrole 1: is dit 'n simboliese skakel, en na wat

Begin by die lêer self, want die pad wat jy wysig is dalk glad nie die lêer nie. 'n Simboliese skakel na 'n resolver se looptyd-gids gedra hom heeltemal anders as 'n gewone lêer wat 'n kliëntskrip herskryf:

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

'n Skakel na 'n systemd-resolved-stubpad beteken die lêer se inhoud word gegenereer, en handmatige wysiging daarvan sal by die volgende gebeurtenis oorskryf word. 'n Gewone lêer met nameserver-lyne word gewoonlik geskryf deur watter kliënt- of DHCP-haak ook al by verbinding loop. Albei is wettig; wat saak maak, is om te weet watter een jy het voordat jy enigiets verander.

Kontrole 2: watter daemon loop

Vind uit wat werklik aktief is, nie wat geïnstalleer is nie. Verskeie resolvers kan op 'n moderne verspreiding teenwoordig wees, en die een wat poort 53 op die loopback-koppelvlak hou, is die een wat antwoord:

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

Die statusuitset noem die per-skakel-DNS-bediener en die roeteringsdomeine, wat die kaart is wat jy vir split-DNS nodig het. As interne name na 'n interne bediener moet gaan en alles anders na 'n publieke een, leef daardie beleid in die per-skakel-domeine, en om dit in 'n statiese nameserver-lys in die lêer plat te slaan, verloor die onderskeid stilweg.

NetworkManager se eie konfigurasie bepaal watter van hierdie backend(s) dit gebruik. Sy dns=-instelling in die hoofkonfigurasielêer kies tussen sy interne resolver, dnsmasq, systemd-resolved en geen, en 'n verspreiding het dalk vir jou gekies. Lees daardie instelling voordat jy besluit wat “DNS regmaak” op hierdie gasheer beteken.

Kontrole 3: wat die VPN-kliënt mag skryf

Dit is waar die konflik gewoonlik woon. 'n VPN-kliënt wat die resolver-lêer direk herskryf, sal met enige diens veg wat dit ook onderhou, en die verloorder is wie eerste hardloop. Onlangse OpenVPN-weergawes kan DNS-instellings aan systemd-resolved oorhandig in plaas van om die lêer te herskryf, wat die samewerkende gedrag is wat jy wil hê; ouer skripte en handgeskrewe hake roep dikwels 'n ou hulpprogram aan of oorskryf bloot die lêer.

WireGuard se situasie is soortgelyk van vorm: die koppelvlakkonfigurasie self bestuur nie DNS nie, en die gereedskap daaromheen doen dit, deur 'n resolver-hulpprogram of die resolved-integrasie. As twee sulke hulpprogramme geïnstalleer is, sal albei probeer om hul siening van die wêreld by verbindingstyd toe te pas.

Lees die kliënt se op- en af-hake eerder as om te raai. 'n Paar reëls shell in /etc/openvpn/up.sh of 'n ekwivalente gids verduidelik gedrag wat andersins willekeurig lyk, en dit is ook die plek om die kliënt te laat saamwerk in plaas van meeding.

Kontrole 4: regstel dit by die eienaar, nie by die lêer nie

Sodra jy die eienaar ken, konfigureer DNS deur daardie eienaar se ondersteunde koppelvlak. Vir systemd-resolved beteken dit per-skakel-instellings en roeteringsdomeine eerder as 'n statiese lêer; vir NetworkManager beteken dit die verbindingsprofiel se DNS-instellings en die gekose backend; vir 'n verspreiding wat 'n resolvconf-integrasie gebruik, beteken dit om deur daardie hulpprogram te skryf.

Moenie die lêer onveranderlik maak nie. Die onveranderlike attribuut stop wettige DHCP-hernuwings en VPN-opdaterings saam met die een waarmee jy geveg het, en dit laat die stelsel in 'n toestand waar die volgende pakketopgradering of herverbinding 'n fout veroorsaak wat niemand uit die konfigurasie kan verduidelik nie. Dit verberg die eienaarskonflik, wat juis die ding is wat jy probeer oplos het.

Waar twee komponente werklik saam moet bestaan, gee hulle verskillende take. Laat die netwerkbestuurder die koppelvlakvlak-konfigurasie besit, laat die VPN-kliënt per-skakel-DNS en -domeine deur dieselfde integrasie bydra, en verwyder die derde skrip wat die lêer direk skryf. Die systemd-resolved-dokumentasie uiteensit die modusse wat dit ondersteun en wat elkeen in /etc/resolv.conf blootlê. Kies die modus wat pas by hoeveel beleid jy moet behou. As split-DNS saak maak, behou die stub-reëling met per-skakel-domeine dit, terwyl die modus wat opstroom-bediener in die lêer kopieer dit stilweg plat slaan.

Verifieer ná 'n herverbinding, nie ná die wysiging nie

'n Lêer wat dadelik ná jou verandering korrek lyk, bewys niks, want die volgende gebeurtenis het nog nie plaasgevind nie. Aktiveer die reeks wat dit vantevore gebreek het: bring die tonnel af en op, hernu die DHCP-huurkontrak of skakel die koppelvlak om, en lees dan weer dieselfde waardes.

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

Bevestig dan die onderskeid wat saak maak: die interne naam los op deur die interne bediener terwyl die publieke naam steeds werk. 'n Konfigurasie wat alles na die interne bediener stuur, lyk reg totdat iemand die internet deur die tonnel probeer bereik, en 'n konfigurasie wat alles na die publieke een stuur, lek interne name.

Teken die eienaar, die backend en die simboliese-skakel-modus in die ontplooiingsnotas aan. Daardie enkele paragraaf verander 'n toekomstige pakketopgradering van 'n voorval in 'n nasienitem, en dit keer dat die volgende persoon dieselfde konflik met 'n chattr-opdrag herontdek.