Դադարեցրեք Linux-ի երկու ծառայությունների մրցակցությունը /etc/resolv.conf-ի համար

DNS-ը անընդհատ վերադառնում է նախկին վիճակին, VPN-ի վերակապակցումը չեղարկում է ձեր ուղղումը, և ի վերջո թիմից ինչ-որ մեկը առաջարկում է կողպել ֆայլը։ Այդ հաջորդականությունը ախտանիշ է, ոչ լուծում՝ երկու բաղադրիչներն էլ կարծում են, որ իրենցն է /etc/resolv.conf-ը, և հաղթում է նա, ով վերջինն է գրում։ Ֆայլը կողպելը չի լուծում սեփականության հակամարտությունը, այն միայն թաքցնում է այն՝ միաժամանակ կոտրելով այն բաղադրիչը, որն իրականում ձեզ պետք էր։ Կատարեք ստորև նշված չորս ստուգումները հերթով և ուղղեք դասավորությունը այն մակարդակում, որին այն պատկանում է, ոչ թե ֆայլում։

Ստուգում 1՝ արդյոք դա սիմվոլիկ հղում է, և ուր

Սկսեք հենց ֆայլից, որովհետև այն ուղին, որը խմբագրում եք, գուցե ամենևին ֆայլ չէ։ Լուծիչի գործարկման պանակին տանող սիմվոլիկ հղումն իրեն պահում է բոլորովին այլ կերպ, քան սովորական ֆայլը, որը հաճախորդի սկրիպտը վերագրում է՝

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

systemd-resolved-ի stub ուղուն տանող հղումը նշանակում է, որ ֆայլի բովանդակությունը գեներացվում է, և ձեռքով խմբագրումը կվերագրվի հաջորդ իրադարձության ժամանակ։ nameserver տողերով սովորական ֆայլը սովորաբար գրում է այն հաճախորդը կամ DHCP-ի կեռիկը, որն աշխատում է միանալիս։ Երկուսն էլ օրինական են․ կարևորը իմանալն է, թե որն ունեք, նախքան որևէ բան փոխելը։

Ստուգում 2՝ որ դեմոնն է աշխատում

Պարզեք, թե ինչն է իրականում ակտիվ, ոչ թե ինչն է տեղադրված։ Ժամանակակից դիստրիբուտիվում կարող են լինել մի քանի լուծիչներ, և պատասխանում է նա, ով loopback միջերեսում զբաղեցնում է 53 պորտը՝

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

Կարգավիճակի ելքը նշում է կապին կցված DNS սերվերները և երթուղման դոմենները, ինչը քարտեզն է, որն անհրաժեշտ է split DNS-ի համար։ Եթե ներքին անունները պետք է գնան ներքին սերվեր, իսկ մնացած ամեն ինչ՝ հանրային, ապա այդ քաղաքականությունը ապրում է կապին կցված դոմեններում, և այն ֆայլում ստատիկ nameserver ցանկի վերածելը լուռ կորցնում է այդ տարբերությունը։

NetworkManager-ի սեփական կազմաձևը որոշում է, թե այդ backend-ներից որն է օգտագործում։ Հիմնական կազմաձևի ֆայլում նրա dns= պարամետրը ընտրում է նրա ներքին լուծիչի, dnsmasq-ի, systemd-resolved-ի և none-ի միջև, և հնարավոր է՝ դիստրիբուտիվն ընտրել է ձեր փոխարեն։ Կարդացեք այդ պարամետրը, նախքան որոշելը, թե ինչ է նշանակում «DNS-ը ուղղել» այս հոսթում։

Ստուգում 3՝ ինչ է թույլատրվում VPN հաճախորդին գրել

Այստեղ սովորաբար ապրում է հակամարտությունը։ VPN հաճախորդը, որը ուղղակիորեն վերագրում է լուծիչի ֆայլը, կպայքարի ցանկացած ծառայության հետ, որը նույնպես սպասարկում է այն, և պարտվում է նա, ով առաջինն է աշխատում։ OpenVPN-ի վերջին թողարկումները կարող են DNS կարգավորումները հանձնել systemd-resolved-ին՝ ֆայլը վերագրելու փոխարեն, ինչը հենց այն համագործակցային վարքն է, որ ցանկանում եք․ հին սկրիպտներն ու ձեռքով գրված կեռիկները հաճախ կանչում են հնացած օժանդակ գործիք կամ պարզապես վերագրում են ֆայլը։

WireGuard-ի իրավիճակը ձևով նման է՝ միջերեսի կազմաձևն ինքը չի կառավարում DNS-ը, դա անում են նրա շուրջ գտնվող գործիքները՝ լուծիչի օժանդակի կամ resolved-ի ինտեգրման միջոցով։ Եթե տեղադրված են երկու այդպիսի օժանդակ, երկուսն էլ միանալու պահին կփորձեն պարտադրել աշխարհի իրենց պատկերացումը։

Կարդացեք հաճախորդի up և down կեռիկները՝ գուշակելու փոխարեն։ Մի քանի տող shell /etc/openvpn/up.sh-ում կամ համարժեք պանակում բացատրում են վարք, որն այլապես պատահական է թվում, և հենց այնտեղ կարող եք ստիպել հաճախորդին համագործակցել՝ մրցակցելու փոխարեն։

Ստուգում 4՝ ուղղեք այն սեփականատիրոջ մոտ, ոչ թե ֆայլում

Երբ իմանաք սեփականատիրոջը, կարգավորեք DNS-ը այդ սեփականատիրոջ աջակցած միջերեսով։ systemd-resolved-ի համար դա նշանակում է կապին կցված կարգավորումներ և երթուղման դոմեններ՝ ստատիկ ֆայլի փոխարեն․ NetworkManager-ի համար՝ կապի պրոֆիլի DNS կարգավորումներ և ընտրված backend․ resolvconf ինտեգրումով դիստրիբուտիվի համար՝ գրել այդ օժանդակի միջոցով։

Ֆայլը անփոփոխելի մի դարձրեք։ Անփոփոխելիության ատրիբուտը դադարեցնում է օրինական DHCP նորացումները և VPN թարմացումները՝ նրանց հետ միասին, որոնց դեմ պայքարում էիք, և համակարգը թողնում է վիճակում, երբ հաջորդ փաթեթի թարմացումը կամ վերակապակցումը ստեղծում է խափանում, որը ոչ ոք չի կարող բացատրել կազմաձևից։ Այն թաքցնում է սեփականության հակամարտությունը, ինչն էլ հենց այն էր, ինչ փորձում էիք լուծել։

Այնտեղ, որտեղ երկու բաղադրիչ իսկապես պետք է գոյատևեն միասին, տվեք նրանց տարբեր աշխատանքներ։ Թող ցանցի կառավարիչը տիրապետի միջերեսի մակարդակի կազմաձևին, թող VPN հաճախորդը նույն ինտեգրման միջոցով նպաստի կապին կցված DNS-ին և դոմեններին, և հեռացրեք երրորդ սկրիպտը, որն ուղղակիորեն գրում է ֆայլը։ systemd-resolved-ի փաստաթղթերը նկարագրում են, թե որ ռեժիմներն է աջակցում և ինչ է ցույց տալիս դրանցից յուրաքանչյուրը /etc/resolv.conf-ում։ Ընտրեք այն ռեժիմը, որը համապատասխանում է պահպանվող քաղաքականության ծավալին։ Եթե split DNS-ը կարևոր է, stub դասավորությունը՝ կապին կցված դոմեններով, պահպանում է այն, մինչդեռ upstream սերվերները ֆայլում պատճենող ռեժիմը լուռ հարթեցնում է այն։

Ստուգեք վերակապակցումից հետո, ոչ թե խմբագրումից հետո

Ֆայլը, որը ձեր փոփոխությունից անմիջապես հետո ճիշտ է թվում, ոչինչ չի ապացուցում, որովհետև հաջորդ իրադարձությունը դեռ չի եղել։ Գործարկեք այն հաջորդականությունը, որ նախկինում կոտրում էր այն՝ իջեցրեք և բարձրացրեք թունելը, նորացրեք DHCP վարձակալությունը կամ փոխարկեք միջերեսը, ապա նորից կարդացեք նույն արժեքները։

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

Ապա հաստատեք կարևոր տարբերությունը՝ ներքին անունը լուծվում է ներքին սերվերի միջոցով, մինչդեռ հանրային անունը դեռ աշխատում է։ Կազմաձևը, որն ամեն ինչ ուղարկում է ներքին սերվեր, լավ է թվում, մինչև ինչ-որ մեկը փորձի թունելով հասնել ինտերնետ, իսկ կազմաձևը, որն ամեն ինչ ուղարկում է հանրային, արտահոսում է ներքին անունները։

Գրանցեք սեփականատիրոջը, backend-ը և սիմվոլիկ հղման ռեժիմը տեղակայման նշումներում։ Այդ մեկ պարբերությունը ապագա փաթեթի թարմացումը միջադեպից վերածում է վերանայման կետի, և խանգարում է հաջորդ մարդուն նույն հակամարտությունը կրկին հայտնաբերել chattr հրամանով։