Stop twa Linux-tsjinsten dy't konkurrearje om /etc/resolv.conf

DNS falt hieltyd werom, de VPN-werferbining makket jo korreksje ûngedien, en úteinlik stelt immen yn it team foar om de triem te beskermjen. Dy sekwinsje is in symptoom, gjin oplossing: twa komponinten miene beide dat se /etc/resolv.conf besitte, en wa't it lêst skriuwt, wint. De triem beskermje lost it eigendomskonflikt net op; it ferberget it allinnich wylst it de komponint brekt dy't jo eins woe. Wurkje de fjouwer kontrôles hjirûnder yn oarder troch, en reparearje de regeling op it nivo dat it besit, net by de triem.

Kontrôle 1: is it in symlink, en nei wat

Begjin by de triem sels, want it paad dat jo bewurkje is miskien hielendal net de triem. In symlink nei de runtime-map fan in resolver hâldt him hiel oars as in gewoane triem dy't in kliïntskript werskriuwt:

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

In keppeling nei in stub-paad fan systemd-resolved betsjut dat de ynhâld fan de triem generearre wurdt, en hânmjittich bewurkjen sil by it folgjende barren oerskreaun wurde. In gewoane triem mei nameserver-rigels wurdt meastentiids skreaun troch de kliïnt of DHCP-hook dy't by ferbining rint. Beide binne legitime; wat fan belang is, is witte hokker fan de beide jo hawwe foardat jo wat feroarje.

Kontrôle 2: hokker daemon rint

Fyn út wat eins aktyf is, net wat ynstallearre is. Op in moderne distribúsje kinne ferskate resolvers oanwêzich wêze, en dejinge dy't poarte 53 op de loopback-ynterface hâldt, is dejinge dy't antwurdet:

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

De statusútfier neamt de DNS-tsjinners per keppeling en de routing-domeinen, dat is de kaart dy't jo nedich hawwe foar split DNS. As ynterne nammen nei in ynterne tsjinner moatte en al it oare nei in iepenbiere, dan libbet dat belied yn 'e domeinen per keppeling, en it flak meitsjen dêrfan yn in statyske nameserver-list yn 'e triem ferliest dat ûnderskie stil.

De eigen konfiguraasje fan NetworkManager bepaalt hokker fan dizze backends er brûkt. Syn dns=-ynstelling yn 'e haadkonfiguraasjetriem kiest tusken syn ynterne resolver, dnsmasq, systemd-resolved en none, en in distribúsje hat miskien foar jo keazen. Lês dy ynstelling foardat jo beslute wat “DNS reparearje” op dizze host betsjut.

Kontrôle 3: wat de VPN-kliïnt skriuwe mei

Hjir libbet it konflikt meastentiids. In VPN-kliïnt dy't de resolvertriem direkt werskriuwt, sil fjochtsje mei elke tsjinst dy't him ek ûnderhâldt, en de ferliezer is wa't it earst rint. Nijere OpenVPN-útjeften kinne de DNS-ynstellingen oan systemd-resolved jaan ynstee fan de triem wer te skriuwen, wat it gearwurkjende gedrach is dat jo wolle; âldere skripts en hânskreaune hooks roppe faak in ferâldere helpmiddel oan of oerskriuwe gewoan de triem.

De situaasje fan WireGuard is yn foarm gelyk: de ynterfacekonfiguraasje sels beheart gjin DNS, dat dogge de helpmiddelen deromhinne, fia in resolver-helper of de resolved-yngearing. As twa sokke helpers ynstallearre binne, sille beide by ferbining har wrâldbyld jilde litte wolle.

Lês de up- en down-hooks fan de kliïnt ynstee fan te rieden. In pear rigels shell yn /etc/openvpn/up.sh of in lykweardige map ferklearje gedrach dat oars willekeurich liket, en dêre kinne jo de kliïnt ek gearwurkje litte ynstee fan konkurrearje.

Kontrôle 4: reparearje it by de eigner, net yn 'e triem

As jo de eigner kenne, konfigurearje DNS fia de stipe-ynterface fan dy eigner. Foar systemd-resolved betsjut dat ynstellingen per keppeling en routing-domeinen ynstee fan in statyske triem; foar NetworkManager betsjut it de DNS-ynstellingen fan it ferbiningsprofyl en de keazen backend; foar in distribúsje mei resolvconf-yngearing betsjut it skriuwen fia dy helper.

Meitsje de triem net ûnferoarlik. It ûnferoarlikheidsattribút stopet legitime DHCP-ferhealingen en VPN-updates tegearre mei dy't jo befjochten, en it lit it systeem efter yn in steat wêryn't de folgjende pakketfernijing of werferbining in flater produsearret dy't nimmen út 'e konfiguraasje ferklearje kin. It ferberget it eigendomskonflikt, dat krekt is wat jo besochten op te lossen.

Wêr't twa komponinten echt njonkeninoar bestean moatte, jou har ferskillende taken. Lit de netwurkbehearder de konfiguraasje op ynterfacenivo besitte, lit de VPN-kliïnt DNS en domeinen per keppeling bydrage fia deselde yngearing, en ferwiderje it tredde skript dat de triem direkt skriuwt. De dokumintaasje fan systemd-resolved beskriuwt de modi dy't it stipet en wat elk dêrfan yn /etc/resolv.conf toant. Kies de modus dy't past by hoefolle belied jo behâlde moatte. As split DNS fan belang is, behâldt de stub-regeling mei domeinen per keppeling it, wylst de modus dy't upstream-tsjinners yn 'e triem kopiearret it stil flak makket.

Ferifiearje nei in werferbining, net nei it bewurkjen

In triem dy't fuortendaliks nei jo feroaring goed liket, bewiist neat, want it folgjende barren is noch net bard. Aktivearje de sekwinsje dy't him earder bruts: helje de tunnel del en wer omheech, ferfarskje de DHCP-liening of skeakelje de ynterface om, en lês dan deselde wearden wer.

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

Befêstigje dan it ûnderskie dat fan belang is: de ynterne namme wurdt fia de ynterne tsjinner oplost wylst de iepenbiere namme noch wurket. In konfiguraasje dy't alles nei de ynterne tsjinner stjoert, liket goed oant immen fia de tunnel it ynternet berikke wol, en in konfiguraasje dy't alles nei de iepenbiere stjoert, lekt ynterne nammen.

Notearje de eigner, de backend en de symlink-modus yn 'e deployment-notysjes. Dat iene paragraaf makket in takomstige pakketfernijing fan in ynsidint ta in kontrôlepunt, en it hâldt de folgjende persoan tsjin om itselde konflikt wer te ûntdekken mei in chattr-opdracht.