Apturiet divus Linux pakalpojumus, kas sacenšas par /etc/resolv.conf

DNS pastāvīgi atgriežas iepriekšējā stāvoklī, VPN atkārtots savienojums atceļ jūsu labojumu, un galu galā kāds komandā ierosina failu aizslēgt. Šī secība ir simptoms, nevis risinājums: divi komponenti abi uzskata, ka tiem pieder /etc/resolv.conf, un uzvar tas, kurš raksta pēdējais. Faila aizslēgšana neatrisina īpašumtiesību konfliktu, tā tikai to slēpj un tajā pašā laikā salauž komponentu, kuru jūs patiesībā gribējāt. Veiciet četras pārbaudes zemāk pēc kārtas un izlabojiet izkārtojumu tajā līmenī, kuram tas pieder, nevis pašā failā.

Pārbaude 1: vai tas ir simboliskais saits, un uz ko

Sāciet ar pašu failu, jo ceļš, kuru rediģējat, var nemaz nebūt fails. Simboliskais saits uz atrisinātāja izpildes direktoriju uzvedas pilnīgi citādi nekā parasts fails, kuru pārraksta klienta skripts:

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

Saite uz systemd-resolved stub ceļu nozīmē, ka faila saturs tiek ģenerēts, un manuāla rediģēšana tiks pārrakstīta nākamajā notikumā. Parastu failu ar nameserver rindām parasti raksta tas klients vai DHCP āķis, kas darbojas savienojuma laikā. Abi ir likumīgi; svarīgi ir zināt, kurš jums ir, pirms kaut ko maināt.

Pārbaude 2: kurš dēmons darbojas

Noskaidrojiet, kas patiesībā ir aktīvs, nevis kas ir instalēts. Mūsdienīgā distribūcijā var būt vairāki atrisinātāji, un atbild tas, kurš loopback saskarnē tur 53. portu:

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

Statusa izvade nosauc DNS serverus katram savienojumam un maršrutēšanas domēnus, un tas ir kartē, kas jums nepieciešama split DNS. Ja iekšējiem nosaukumiem jāiet uz iekšējo serveri un visam pārējam uz publisko, šī politika dzīvo domēnos katram savienojumam, un tās saplacināšana statiskā nameserver sarakstā failā klusi zaudē šo atšķirību.

NetworkManager paša konfigurācija izlemj, kuru no šiem backendiem tas izmanto. Tā dns= iestatījums galvenajā konfigurācijas failā izvēlas starp tā iekšējo atrisinātāju, dnsmasq, systemd-resolved un none, un distribūcija var būt izvēlējusies jūsu vietā. Izlasiet šo iestatījumu, pirms lemjat, ko “DNS labošana” nozīmē šajā resursdatorā.

Pārbaude 3: ko VPN klientam atļauts rakstīt

Šeit parasti dzīvo konflikts. VPN klients, kas tieši pārraksta atrisinātāja failu, cīnīsies ar jebkuru pakalpojumu, kas to arī uztur, un zaudētājs ir tas, kurš darbojas pirmais. Jaunākās OpenVPN versijas var nodot DNS iestatījumus systemd-resolved, nevis pārrakstīt failu — tā ir sadarbības uzvedība, kuru vēlaties; vecāki skripti un ar roku rakstīti āķi bieži izsauc novecojušu palīgrīku vai vienkārši pārraksta failu.

WireGuard situācija formā ir līdzīga: pati saskarnes konfigurācija DNS nepārvalda, to dara rīki tai apkārt, izmantojot atrisinātāja palīgu vai resolved integrāciju. Ja ir instalēti divi šādi palīgi, abi savienojuma laikā mēģinās īstenot savu pasaules redzējumu.

Lasiet klienta up un down āķus, nevis miniet. Dažas shell rindas /etc/openvpn/up.sh vai līdzvērtīgā direktorijā izskaidro uzvedību, kas citādi šķiet nejauša, un tā ir arī vieta, kur var panākt, lai klients sadarbojas, nevis sacenšas.

Pārbaude 4: labojiet to pie īpašnieka, nevis failā

Kad zināt īpašnieku, konfigurējiet DNS caur šī īpašnieka atbalstīto saskarni. systemd-resolved gadījumā tas nozīmē iestatījumus katram savienojumam un maršrutēšanas domēnus statiska faila vietā; NetworkManager gadījumā — savienojuma profila DNS iestatījumus un izvēlēto backendu; distribūcijai ar resolvconf integrāciju — rakstīšanu caur šo palīgu.

Neveidojiet failu nemaināmu. Nemaināmības atribūts aptur likumīgus DHCP atjaunojumus un VPN atjauninājumus kopā ar tiem, ar kuriem jūs cīnījāties, un atstāj sistēmu stāvoklī, kad nākamā pakotnes atjaunināšana vai atkārtots savienojums rada kļūmi, ko neviens nevar izskaidrot no konfigurācijas. Tas slēpj īpašumtiesību konfliktu, kas ir tieši tas, ko jūs mēģinājāt atrisināt.

Kur diviem komponentiem patiešām jāsadzīvo kopā, dodiet tiem dažādus darbus. Ļaujiet tīkla pārvaldniekam piederēt saskarnes līmeņa konfigurāciju, ļaujiet VPN klientam caur to pašu integrāciju sniegt DNS un domēnus katram savienojumam, un noņemiet trešo skriptu, kas tieši raksta failu. systemd-resolved dokumentācija apraksta atbalstītos režīmus un to, ko katrs no tiem atklāj /etc/resolv.conf. Izvēlieties režīmu, kas atbilst politikas apjomam, kas jums jāsaglabā. Ja split DNS ir svarīgs, stub izkārtojums ar domēniem katram savienojumam to saglabā, savukārt režīms, kas kopē upstream serverus failā, to klusi saplacina.

Pārbaudiet pēc atkārtota savienojuma, nevis pēc rediģēšanas

Fails, kas izskatās pareizi uzreiz pēc jūsu izmaiņām, neko nepierāda, jo nākamais notikums vēl nav noticis. Ierosiniet secību, kas agrāk to salauza: nolaidiet un atkal paceliet tuneli, atjaunojiet DHCP nomu vai pārslēdziet saskarni, pēc tam vēlreiz nolasiet tās pašas vērtības.

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

Pēc tam apstipriniet svarīgo atšķirību: iekšējais nosaukums tiek atrisināts caur iekšējo serveri, kamēr publiskais nosaukums joprojām darbojas. Konfigurācija, kas visu sūta uz iekšējo serveri, izskatās labi, līdz kāds mēģina sasniegt internetu caur tuneli, un konfigurācija, kas visu sūta uz publisko, noplūdina iekšējos nosaukumus.

Ierakstiet īpašnieku, backendu un simboliskā saita režīmu izvietošanas piezīmēs. Šī viena rindkopa pārvērš nākotnes pakotnes atjauninājumu no incidenta par pārskatīšanas punktu, un tā neļauj nākamajam cilvēkam no jauna atklāt to pašu konfliktu ar chattr komandu.