VPN-ի DNS-ը վերցնում է յուրաքանչյուր հարցում. ուղղեք dns-priority-ը NetworkManager-ում

Միացե՛ք գրասենյակի VPN-ին, և հանկարծ յուրաքանչյուր անվանման հարցում գնում է կորպորատիվ resolver-ին։ Հանրային անունները դեռ լուծվում են, ուստի ոչինչ կոտրված չի թվում, քանի դեռ տեղական տպիչի անունը չի ձախողվել կամ split-horizon գրառումը չի վերադարձրել գրասենյակի հասցեն։ Որոշ Fedora տեղադրումներում հակառակն է լինում. մատակարարի resolver-ը շարունակում է պատասխանել թունելը բարձրանալուց հետո։ Երկուսն էլ մեկ հարց են՝ ո՞ր resolver-ն է այս հարցման սեփականատերը, և NetworkManager համակարգերում պատասխանն ապրում է յուրաքանչյուր միացման DNS հատկություններում։

Երկու միացում, մեկ հաղթող resolver

Յուրաքանչյուր միացում հայտարարում է DNS առաջնահերթություն։ Սովորական միացումները լռելյայն 50 են, VPN միացումները՝ 0, և հաղթում է ավելի փոքր արժեքը։ Հենց այդ լռելյայնն է պատճառը, որ VPN միացումը լուռ գերազանցում է լարային կապին յուրաքանչյուր դոմենի համար, որին հավակնում է՝ զրոն հաղթում է հիսունին առանց որևէ մեկի ընտրության։

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

Առաջնահերթությունը որոշում է կարգը, որոնման ցանկը՝ սեփականությունը

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Որոնման ցանկը սեփականության հայտարարությունն է։ Մերկ դոմենը, ինչպիսին corp.example-ն է, դառնում է որոնման վերջածանց և երթուղային դոմեն։ Միայն երթուղման ձևը՝ ~corp.example, այդ վերջածանցի տակ գտնվող հարցումներն ուղարկում է այս միացմանը՝ առանց դոմենը կարճ անուններին ավելացնելու։ Այդ տիլդան տարբերությունն է «հարցրու այս սերվերին» և «հարցրու այս սերվերին ու ավարտիր իմ մուտքագրումը» արտահայտությունների միջև։

Օգտագործեք երկու ձևերն էլ, երբ օգտվողները մուտքագրում են կարճ հոսթի անուններ, և գրառումները հասցեագրվում են նաև ամբողջությամբ որակավորված անուններով։ Միայն երթուղման ձևն օգտագործեք, երբ բաժանում եք ուզում՝ չփոխելով, թե ինչպես է resolver-ը լրացնում մերկ անունը։

Ապա դարձրեք նախապատվությունը բացահայտ և վերաակտիվացրեք:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Բացասական առաջնահերթությունը փաստաթղթավորված ձևն է ասելու «նախապատվիրիր այս միացմանը», և երկու հասցեային ընտանիքներն էլ սահմանելը պահում է վարքը հետևողական IPv6 կապակցություն ունեցող հոսթում։ Հատկությունը փոխելն առանց միացումը վերաակտիվացնելու ոչինչ չի փոխում նրանից, ինչ հիմա աշխատում է, ուստի հաջորդականությունն ավարտվում է բացահայտ up-ով։

Թողեք systemd-resolved-ը պահի բաժանումը

Լռելյայն dnsmasq պլագինը հարցումները հավաքում է մեկ տեղական resolver-ի մեջ, ուստի կապի մակարդակով առանձնացումը կոպիտ է մնում։ systemd-resolved-ը բացահայտում է բաժանումը յուրաքանչյուր կապի համար, և resolvectl query-ը նշում է այն կապը, որը պատասխանել է։

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Դրանից հետո կորպորատիվ կապը կրում է corp.example-ը, իսկ հանրային resolver-ը սպասարկում է մնացածը։ Երբ հարցումը հասնում է սխալ կապին, հրամանը նշում է այն կապը, որը պատասխանել է դրան, և դա իմանալն ավելի լավ է, քան միայն հասցեն իմանալը։

Համապատասխանեցրեք DNS ձևավորումը թունելի տեսակին

Գաղտնիության ձևավորումները, որոնք ամեն ինչ ուղարկում են թունելով, չպետք է բաժանման ցանկ կրեն, որովհետև այն հանրային անունները կվերադարձնի տեղական resolver-ին և կչեղարկի մտադրությունը։ Բաժանված թունելի ձևավորումներին մեկը պետք է. առանց դրա կորպորատիվ resolver-ը տեսնում է յուրաքանչյուր հանրային հարցում, և կարգավորումը կոտրվում է այն պահին, երբ թունելը ընկնում է։

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

Պրոֆիլը, որը ինտերֆեյսի մեկնարկին վերագրում է resolver-ի կարգավորումները, գրեթե նույն կերպ է վարվում՝ հենց տեղական resolver-ն անհասանելի է, կլուծվեն միայն այն անունները, որոնք թունելը գիտի։ Ինչ մեխանիզմ էլ կիրառվի, գրեք, թե որ անունները պետք է աշխատեն յուրաքանչյուր վիճակում, և այդ ցանկը տվեք նրան, ով զբաղվում է հաշվետվություններով։

Ստուգեք յուրաքանչյուր կապով, ապա կրկին՝ վերամիացումից հետո

Հարցրեք մեկ ներքին և մեկ հանրային անուն, և տեսեք, թե ուր է իրականում գնում հարցումը։ Արտահոսքի ստուգման էջը ասում է, թե որ resolver-ն է պատասխանել, ոչ թե՝ որ կապն է ընտրել համակարգը, ուստի այն ոչինչ չի ասում հենց նոր կարգավորած հերթականության մասին։

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