Simamisha huduma mbili za Linux zinazoshindania /etc/resolv.conf

DNS hurudi mara kwa mara kwenye hali ya awali, kuunganisha VPN upya hubatilisha marekebisho yako, na mwishowe mtu kwenye timu anapendekeza faili ifungwe. Mfululizo huo ni dalili, si suluhisho: vipengele viwili vyote vyote hudhani vinamiliki /etc/resolv.conf, na anayeshinda ni yule anayeandika mwisho. Kufunga faili hakutatui mgogoro wa umiliki, kunaificha tu na wakati huo huo kuvunja kipengele ulichokitaka kwa kweli. Fanya ukaguzi nne zifuatazo kwa mpangilio, na urekebishe mpangilio katika ngazi inayomiliki, si kwenye faili.

Ukaguzi 1: je, ni kiungo cha mfano, na kwa nini

Anza na faili yenyewe, kwa sababu njia unayohariri inaweza kuwa si faili hata kidogo. Kiungo cha mfano kinachoelekea saraka ya utekelezaji ya kisuluhishi hujiendesha tofauti kabisa na faili la kawaida ambalo hati ya mteja huandika upya:

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

Kiungo kuelekea njia ya stub ya systemd-resolved kinamaanisha maudhui ya faili yanazalishwa, na uhariri wa mikono utafunikwa katika tukio lijalo. Faili la kawaida lenye mistari ya nameserver kwa kawaida huandikwa na mteja au ndoano ya DHCP inayotekelezwa wakati wa kuunganisha. Zote mbili ni halali; jambo muhimu ni kujua unayo ipi kabla ya kubadilisha chochote.

Ukaguzi 2: ni daemon gani inaendesha

Gundua kinachofanya kazi kwa kweli, si kile kilichosakinishwa. Katika usambazaji wa kisasa kunaweza kuwa na visuluhishi kadhaa, na kile kinachoshikilia lango 53 kwenye kiolesura cha loopback ndicho kinachojibu:

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

Matokeo ya hali hutaja seva za DNS kwa kila kiungo na vikoa vya uelekezaji, na hiyo ni ramani unayohitaji kwa split DNS. Ikiwa majina ya ndani yanapaswa kwenda kwa seva ya ndani na kila kitu kingine kwa ya umma, sera hiyo inaishi katika vikoa vya kila kiungo, na kuifanya bapa katika orodha tuli ya nameserver ndani ya faili hupoteza tofauti hiyo kimya kimya.

Usanidi wa NetworkManager wenyewe huamua ni backend ipi kati ya hizi inatumiwa. Kipengele chake cha dns= katika faili kuu ya usanidi huchagua kati ya kisuluhishi chake cha ndani, dnsmasq, systemd-resolved na none, na usambazaji unaweza kuwa umechagua kwa niaba yako. Soma kipengele hicho kabla ya kuamua maana ya “kurekebisha DNS” kwenye mwenyeji huyu.

Ukaguzi 3: mteja wa VPN anaruhusiwa kuandika nini

Hapa ndipo mgogoro kwa kawaida huishi. Mteja wa VPN anayeandika upya faili la kisuluhishi moja kwa moja atapambana na huduma yoyote inayolihifadhi pia, na anayeshindwa ni yule anayeendeshwa kwanza. Matoleo mapya ya OpenVPN yanaweza kukabidhi mipangilio ya DNS kwa systemd-resolved badala ya kuandika upya faili, na hiyo ndiyo tabia ya ushirikiano unayoitaka; hati za zamani na ndoano zilizoandikwa kwa mkono mara nyingi huita kifaa cha usaidizi kilichopitwa na wakati au huhariri faili moja kwa moja.

Hali ya WireGuard inafanana kwa umbo: usanidi wa kiolesura wenyewe hausimamii DNS, zana zinazouzunguka ndizo zinazosimamia, kupitia msaidizi wa kisuluhishi au muunganisho wa resolved. Ikiwa msaidizi wawili kama hao wamesakinishwa, wote wawili watajaribu kutekeleza mtazamo wao wa dunia wakati wa kuunganisha.

Soma ndoano za juu na chini za mteja badala ya kukisia. Mistari michache ya shell katika /etc/openvpn/up.sh au saraka inayolingana hufafanua tabia ambayo vinginevyo inaonekana kuwa ya nasibu, na hapo ndipo panapoweza kumfanya mteja ashirikiane badala ya kushindana.

Ukaguzi 4: rekebisha kwa mmiliki, si kwenye faili

Mara unapomjua mmiliki, sanidi DNS kupitia kiolesura kinachoungwa mkono na mmiliki huyo. Kwa systemd-resolved hiyo inamaanisha mipangilio ya kila kiungo na vikoa vya uelekezaji badala ya faili tuli; kwa NetworkManager inamaanisha mipangilio ya DNS ya wasifu wa muunganisho na backend iliyochaguliwa; kwa usambazaji unaotumia muunganisho wa resolvconf inamaanisha kuandika kupitia msaidizi huyo.

Usilifanye faili lisilobadilika. Sifa ya kutobadilika huzuia uhuishaji halali wa DHCP na masasisho ya VPN pamoja na yale uliyokuwa ukipambana nayo, na huiacha mfumo katika hali ambayo uboreshaji ujao wa kifurushi au kuunganisha upya huzalisha kosa ambalo hakuna anayeweza kulieleza kutoka kwenye usanidi. Huficha mgogoro wa umiliki, ambao ni kitu ulichokuwa ukijaribu kutatua.

Ambapo vipengele viwili lazima kwa kweli viishi pamoja, wape kazi tofauti. Acha msimamizi wa mtandao amiliki usanidi wa ngazi ya kiolesura, acha mteja wa VPN achangie DNS na vikoa vya kila kiungo kupitia muunganisho huo huo, na uondoe hati ya tatu inayoandika faili moja kwa moja. Nyaraka za systemd-resolved zinaeleza hali inazounga mkono na kile kila moja inaonyesha katika /etc/resolv.conf. Chagua hali inayolingana na kiasi cha sera unachohitaji kuhifadhi. Ikiwa split DNS ni muhimu, mpangilio wa stub wenye vikoa vya kila kiungo huihifadhi, wakati hali inayonakili seva za juu kwenye faili huifanya bapa kimya kimya.

Thibitisha baada ya kuunganisha upya, si baada ya uhariri

Faili linaloonekana sahihi mara moja baada ya mabadiliko yako haliwezi kuthibitisha chochote, kwa sababu tukio lijalo bado halijatokea. Anzisha mfululizo uliokuwa ukiliharibu: teremsha na pandisha handaki, huisha leseni ya DHCP au badilisha kiolesura, kisha soma tena thamani zile zile.

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

Kisha thibitisha tofauti muhimu: jina la ndani hutatuliwa kupitia seva ya ndani wakati jina la umma bado linafanya kazi. Usanidi unaotuma kila kitu kwenye seva ya ndani huonekana sawa hadi mtu anapojaribu kufikia intaneti kupitia handaki, na usanidi unaotuma kila kitu kwa ile ya umma huvujisha majina ya ndani.

Rekodi mmiliki, backend na hali ya kiungo cha mfano katika maelezo ya uwekaji. Aya hiyo moja hubadilisha uboreshaji wa kifurushi ujao kutoka tukio hadi kipengele cha mapitio, na huzuia mtu anayefuata kugundua tena mgogoro huo huo kwa amri chattr.