Ինչու ձեր /etc/hosts գրառումը չի հասնում VPN-ի DNS-ին

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

Hosts-ը տեղական վերագրում է, ոչ գոտու թարմացում

Ֆայլը քարտեզագրումների ցանկ է, որոնց անվանման ծառայության գրադարանները դիմում են DNS սերվերին հարցնելուց առաջ կամ փոխարենը։ 10.40.0.20 build.corp.example-ի նման տողը փոխում է այն, ինչ եզրակացնում են հենց այդ մեկ մեքենայի հավելվածները։ Այն գրառում չի ստեղծում, չի անցնում թունելով, և այն DNS սերվերը, որին մատնանշում է թունելը, տեղյակ չէ դրա գոյության մասին։

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

Երկու հրաման, երկու տարբեր բաղադրիչ

Այս վեճը դադարեցնելու ամենաարագ ճանապարհը տարբերությունը երկու հրամաններում տեսանելի դարձնելն է, երկուսն էլ կատարվում են այն հաճախորդում, որտեղ կա hosts գրառումը՝

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

Հերթականությունը կարգավորելի է, և արժե ստուգել այն նախքան որևէ եզրակացություն անել կոնկրետ բաշխման մասին։ Նայեք hosts: տողին /etc/nsswitch.conf-ում, hosts: files dns նախ ֆայլերին է դիմում։ Չպատճենեք այդ օրինակը աշխատող կոնֆիգուրացիայի վրա միայն հերթականությունը փոխելու համար, որովհետև իրական համակարգերը հաճախ թվարկում են լրացուցիչ աղբյուրներ և պայմանական ծառայության գրառումներ, որոնք օրինակում չկան։

systemd-resolved-ը մշուշում է փորձարկումը

systemd-resolved օգտագործող համակարգում տեղական stub-ը նաև անուններ է մատուցում hosts տվյալների բազայից։ Ուստի 127.0.0.53-ին հարցում անելը հեռավոր սերվերի անկախ փորձարկում չէ, թեև այն նման է DNS հարցման և այդպես էլ վարվում է։ Կարող եք հաստատել, թե ինչ գիտի resolver-ը և որ սերվերներին կհարցնի՝

resolvectl query build.corp.example
resolvectl status

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

Հավելվածները կարող են ևս մեկ շերտ ավելացնել։ Սեփական DNS-over-HTTPS կարգավորում ունեցող բրաուզերը, սեփական resolver կոնֆիգուրացիա ունեցող կոնտեյները կամ պրոցեսի ողջ կյանքի ընթացքում որոնումները քեշավորող գործարկման միջավայրը կարող են յուրաքանչյուրը պատասխանել համակարգից տարբեր։ Փորձարկեք այն հավելվածը, որը ձեզ համար կարևոր է, փոխանակ ենթադրելու, որ մեկ հրամանը նկարագրում է մեքենայի բոլոր ծրագրերը։

Ինչն է իրականում անունը կիսում VPN-ի միջով

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

Hosts ֆայլերի տարածումը օրինական այլընտրանք է, և դա վերջնակետերի կառավարում է, ոչ անվանման ծառայություն։ Եթե ընտրեք այն, ֆայլը պետք է տեղակայվի, տարբերակվի և հեռացվի նավատորմը կառավարողի կողմից, և դիզայնում հենց այդպես պետք է նկարագրվի։ «VPN-ը դա կարգավորում է» այդ գործընթացի նկարագրությունը չէ։

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

Լուծված անունը երթուղի չէ

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

Ուստի երբ հաշվետվությունն ասում է «անունը լուծվում է, բայց ծառայությունը հասանելի չէ», համեմատեք համակարգի որոնումը VPN-ի DNS սերվերին ուղղված բացահայտ հարցման հետ, ապա ստուգեք ստացած հասցեն այն հասցեի հետ, որն իրականում օգտագործում է ծառայությունը։ systemd-resolved-ի տեղեկանքը փաստագրում է այն տեղական աղբյուրները, որոնց նա դիմում է, և դա այն քարտեզն է, որն անհրաժեշտ է այդ համեմատության համար։

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