Ինչու resolv.conf-ը ցույց է տալիս ձեր VPN-ի DNS-ը, բայց որոնումները անտեսում են այն

Մատյաններում ոչինչ սխալ չի թվում. ինտերֆեյսը միացված է, լուծիչը հաղորդում է VPN-ի DNS սերվերը, և սկավառակի ֆայլը թվարկում է այն։ Այնուամենայնիվ, ներքին հոսթի անունը դեռ լուծվում է տեղական երթուղիչով։ Այս երեք պնդումները չեն հակասում միմյանց, որովհետև ֆայլը, յուրաքանչյուր կապի վիճակը և որոնման ուղին տարբեր օբյեկտներ են, որոնք պատահաբար կիսում են մեկ անուն։ Հետևյալը այն ուղին է, որ հարցումն իրականում անցնում է systemd-resolved ունեցող հոսթում։

Երեք օբյեկտ՝ resolv.conf անունով

resolved ունեցող հոսթում /etc/resolv.conf-ը սովորաբար խորհրդանշական հղում է դեպի /run/systemd/resolve/stub-resolv.conf։ Այդ նպատակակետը պարունակում է տեղական stub-լսողի հասցեն՝ 127.0.0.53, ինչպես նաև resolved-ի հաշվարկած որոնման տիրույթները։ Սա վիճակի տեսք է, ոչ թե ինքը վիճակը։

Վիճակն ապրում է resolved-ի՝ յուրաքանչյուր կապի կարգավորումներում, և դրա համար resolvectl status-ը կարող է հակասել ֆայլին և միևնույն ժամանակ ճիշտ լինել։ Յուրաքանչյուր կապ կրում է իր սերվերներն ու իր երթուղային տիրույթները, և stub-ը դիմում է այդ տվյալներին, երբ հարցում է գալիս։ systemd-resolved-ի ձեռնարկը նկարագրում է գեներացված ֆայլերը և յուրաքանչյուր կապի մոդելը. տեսքի ու վիճակի բաժանումը հիշելու արժանի մասն է։ Խորհրդանշական հղման նպատակակետը փոխելը փոխում է այն, ինչ կարդում են ավանդական հաճախորդները, ոչ թե այն, ինչ գիտի լուծիչը։

Երրորդ օբյեկտը՝ /run/systemd/resolve/resolv.conf, հարթեցնում է յուրաքանչյուր կապ մեկ սերվերների ցանկի մեջ։ Այդ ֆայլին ուղղված ծրագիրը հարցումներն ուղարկում է ուղիղ թվարկված սերվերներին և շրջանցում է stub-ը, ուստի յուրաքանչյուր կապի քաղաքականությունն այլևս չի տարածվում նրա վրա։ Այսպիսով, նույն մեքենայի երկու ծրագիր կարող են նույն անվանը տարբեր պատասխան տալ, և ոչ մեկը կոտրված չէ։

Հետևեք մեկ որոնման NSS-ի միջով

glibc-ն կարդում է /etc/nsswitch.conf-ը՝ որոշելու, թե ով է պատասխանում անվանը։ resolve պարունակող hosts տողը հարցն ուղղում է nss-resolve-ին, որը D-Bus-ի միջոցով հարցնում է resolved-ին և ստանում յուրաքանչյուր կապի պատասխանը։ Միայն files dns պարունակող տողը հարցումն ուղարկում է այն հասցեին, որը պահում է /etc/resolv.conf-ը։

Այդ մեկ տողը բացատրում է դիտարկիչի և dig-ի միջև եղած տարաձայնությունների մեծ մասը։ dig-ը ուղղակիորեն կարդում է resolv.conf-ը և երբեք չի դիպչում NSS-ին, ուստի փորձարկում է stub-ը կամ վերին սերվերը, այլ ոչ թե այն ուղին, որն օգտագործում է հավելվածը։ getent hosts internal.example-ը անցնում է NSS-ով, և նրա պատասխանը dig-ի պատասխանի հետ համեմատելը առաջին օգտակար չափումն է։

Ծրագրերը, որոնք իրենց լուծիչն են բերում կամ DNS-ով խոսում են HTTPS-ի վրայով ֆիքսված վերջնակետի հետ, շրջանցում են երկու ուղիներն էլ։ Ոչինչ resolv.conf-ում կամ resolved-ի վիճակում չի սահմանափակում նրանց։

Ստուգեք, թե ով է ֆայլի տերը և ուր է այն ուղղված

Կարդացեք հղումների շղթան նախքան որևէ բան փոխելը, որովհետև սեփականությունն է որոշում, թե որ ֆայլն է հեղինակավոր։ Ստորև բոլոր հրամանները միայն վիճակ են կարդում։

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Առաջին տողը միասին տպում է հղումը և դրա նպատակակետը, և VPN սկրիպտին պատկանող սովորական ֆայլը նշանակում է, որ լուծիչը երբեք այդ գրառումը որպես մուտք չի ընդունում։ Վիճակի ելքը թվարկում է յուրաքանչյուր կապի սերվերները՝ գումարած երթուղային տիրույթները, որոնք որոշում են, թե ուր է գնում յուրաքանչյուր հարցում։ nsswitch տողը ասում է՝ արդյոք stub-ին ընդհանրապես դիմում են, ուստի ֆայլում stub հասցե առանց resolve-ի նշանակում է, որ հարցումները հասնում են տեղական լսողին, մինչդեռ ոչինչ չի կառավարում բաժանումը։ Այդ վերջին ցանկը նույնպես կարևոր է, որովհետև առանց stub-resolv.conf-ի հոսթը չի գործարկում այստեղ նկարագրված կարգը։

Եթե շղթան ավարտվում է մեկ այլ փաթեթի կողմից կառավարվող ֆայլով, VPN հաճախորդը և այդ փաթեթը երկու տերերն են, որոնց պետք է համաձայնեցնել։ Հղումը փոխարինելը դեն է նետում մի տիրոջ աշխատանքը և թողնում մյուսինն իր տեղում։

Վերանորոգեք հղման տիրոջ մոտ

VPN միացումը պետք է գրանցի իր սերվերներն ու իր տիրույթները իր իսկ կապի վրա, ապա անջատվելիս հետ վերցնի դրանք։ NetworkManager-ի resolved ինտեգրումը և հաճախորդի սեփական օգնականը երկուսն էլ այդպես են աշխատում. սկրիպտը, որը միայն վերագրում է resolv.conf-ը, այդպես չի անում։

Արդեն գոյություն ունեցող կապի վրա մեխանիզմը ցույց են տալիս գործարկման պարամետրերը։ resolvectl dns tun0 10.40.0.53-ը կցում է սերվեր, և resolvectl domain tun0 '~corp.example'-ը կցում է երթուղային տիրույթ։ Տիլդան բեռ կրող նշանն է. այն այդ վերջածանցի հարցումները սահմանափակում է այս կապով և մնացած ամեն ինչ թողնում է հանգիստ, մինչդեռ առանց դրա նույն արժեքը դառնում է որոնման տիրույթ, և բաժանումը գոլորշիանում է։ Այդ հասցեները լաբորատոր օրինակներ են, ոչ թե մշտական կարգավորում։ Հաստատեք resolvectl query host.corp.example-ով և կարդացեք, թե որ կապն է պատասխանել։

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

Ինչպիսին է աշխատող վիճակը

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

Ապա անջատեք և կրկնեք երկու հարցումները։ Հաճախորդը, որը քանդումից հետո թողնում է իր տիրույթները գրանցված, ստեղծում է մեքենա, որը ժամեր անց ձախողվում է ներքին որոնումներում, առանց բաց թունելի և առանց ակնհայտ պատճառի։