VPN-ի DNS-ը աշխատում է, բայց .local անունները դեռ ձախողվում են. ո՞վ է դրանք լուծում։

Նույն VPN-ում երկու մեքենա, նույն հոսթի անունը, և դրանցից միայն մեկն է լուծում այն. տարբերությունը սովորաբար ոչ թունելն է, այլ այն, թե որ լուծիչը պատասխանեց։ Linux-ի աշխատասեղանին այդ անունը կարող է անցնել անունների ծառայության անջատիչով, systemd-resolved-ի stub-ով կամ լուծիչով, որը հավելվածը բերել է իր հետ, և դրանցից յուրաքանչյուրը կիրառում է իր կանոնը նույն վերջածանցի նկատմամբ։ Հենց վերջածանցում են կանոնները տարանջատվում, որովհետև .local չեզոք պիտակ չէ։ Պարզեք, թե ձախողվող ծրագիրն իրականում որ ուղին է գնում, նախքան կփոխեք այն հերթականությունը, որով ինչ-որ բան է աշխատում։

Երկու լուծիչ, երկու տարբեր պատասխան

Ավանդական glibc որոնումն անցնում է nsswitch.conf-ի hosts: տողով և հերթով հարցնում յուրաքանչյուր մոդուլին, մինչև մեկը պատասխանի։ Stub լսողի միջոցով systemd-resolved-ի հետ խոսող հաճախորդը փոխարենը հարցնում է մեկ գործընթացի, և այդ գործընթացը կիրառում է կապի համար սահմանված քաղաքականությունն ու իր իսկ հատուկ դեպքերը։ Հավելվածը, որն իր լուծիչն է բերում կամ համարժեք գրադարան է կապում, կարող է շրջանցել երկուսին։ Այսպիսով մեկ հոսթի անունը կարող է երեք սեփականատեր ունենալ մեկ մեքենայում, և նրանցից միայն մեկը գիտի, թե ինչ նկատի ուներ VPN-ը։

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

Ո՞ր հրամանն իրականում հարցրեց ձեր լուծիչին

Երկու միայն-ընթերցվող հրամաններ պատասխանում են հարակից հարցերին, և դրանց համեմատությունը խնդիրն ավելի արագ է տեղորոշում, քան կարգավորումը կարդալը։ Օգտագործեք իրական ներքին անուն և ելքը պահեք գաղտնի, որովհետև ներքին գրառումները մնում են ներքին։ Երկուսն էլ գործարկեք այն նույն նստաշրջանում, որտեղ աշխատում է ձախողվող ծրագիրը.

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

Ինչու է .local-ը շրջանցում ձեր unicast գոտին

systemd-resolved-ի հղումը նշում է, որ .local-ով ավարտվող բազմապիտակ անունները, երբ mDNS-ը միացված է, սովորաբար գնում են multicast DNS, այլ ոչ սովորական unicast DNS։ RFC 6762-ը այդ անվանատարածքը առանձնացնում է link-local multicast-ի համար, այնպես որ կորպորատիվ գոտին կարող է պահել ճիշտ գրառում, որի մասին այդ վերջածանցի համար երբեք չեն հարցնում։ Թունելը կարող է լուծիչը կատարյալ երթուղավորել և այնուամենայնիվ պարտվել մրցավազքում։ Քեշից հաջողված ping-ը ոչինչ չի ասում հենց նոր տեղի ունեցած որոնման մասին։

Կա փաստաթղթավորված բացառություն, և այն լուծում է այս դեպքերի մեծ մասը. երբ կապը հայտարարում է այդ վերջածանցը որպես որոնման տիրույթ կամ երթուղավորման տիրույթ, դեմոնը պահում է այն unicast ուղու վրա և բաց թողնում multicast-ի հատուկ դեպքը։ Սա յուրաքանչյուր կապի քաղաքականություն է, ոչ գլոբալ նախապատվություն։ Նույն VPN սերվերով երկու մեքենա կարող են տարբեր վարվել, երբ ցանցի մի պրոֆիլը հայտարարում է տիրույթը, իսկ մյուսը՝ ոչ, ուստի կարդացեք ակտիվ պրոֆիլը, այլ ոչ այն, որը հիշում եք, թե խմբագրել եք։

Նեղ բացառությունը հաղթում է գլոբալ վերադասավորմանը

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

Այն նաև գոյատևում է անջատումից, որովհետև կապի քաղաքականությունը կրկին կիրառվում է, երբ կապը վերադառնում է։ Համատեղ nsswitch.conf-ը խմբագրելը գայթակղիչ և ավելի թանկ այլընտրանքն է, որովհետև այն փոխում է որոնման վարքը մեքենայի բոլոր անունների համար՝ ներառյալ լոկալ հայտնաբերումը։ Multicast դեմոնն անջատելը նույնպես համարժեք չէ. այն հեռացնում է լոկալ վարքը՝ առանց որևէ լուծիչի սովորեցնելու կորպորատիվ գոտու մասին։ Եթե ծառայությունը նոր է, ոչ ժառանգված, դրեք այն ենթատիրույթում, որը վերահսկում է ձեր կազմակերպությունը, և ընդհանրապես բաց թողեք մրցակցությունը։ Ընտրեք նեղ բացառությունը, երբ անունը ամրագրված է firmware-ում կամ տպված է պիտակի վրա, և ընտրեք նոր ենթատիրույթ, երբ դեռ վերահսկում եք հաճախորդը։

Ինչ ապացուցել փոփոխությունից հետո

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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