Ձեր VPN դոմեյնը dnsmasq-ում գոտու փոխանցում չէ

Դուք փնտրում եք կորպորատիվ գոտին հաճախորդի dnsmasq կարգավորումներում, չեք գտնում այն և եզրակացնում, որ VPN-ը չի ուղարկել իր դոմեյնը։ Այն, ինչ ուղարկվել է, երթուղավորման հուշում է, ոչ թե գոտի։ Հաճախորդը գրանցում է դոմեյնը և resolver-ը, որը պետք է պատասխանի դրա համար, իսկ կառավարվող backend-ը դա վերածում է պայմանական փոխանցման։ Սխալ տեղում փնտրելը տալիս է վստահ և ամբողջովին կեղծ ախտորոշում։

Այն, ինչ հաճախորդը ընդունել է, այն չէ, ինչ առաջարկել է դարպասը

Դարպասը կարող է առաջարկել resolver, դոմեյն և այդ resolver-ին հասնելու համար անհրաժեշտ երթուղին, և հաճախորդը կարող է ընդունել բոլոր երեքը կամ ոչ մեկը։ Ներմուծված պրոֆիլը, օժանդակ սկրիպտը կամ ուղարկված ընտրանքներն անտեսող քաղաքականությունը կարող են ընդունված հավաքածուն դատարկ թողնել, մինչ սերվերի կողմը ճիշտ է թվում։ Սկսեք հաճախորդի գրանցված վիճակից, ոչ թե սերվերի կարգավորումից, որովհետև հենց այդ վիճակն է, որ resolver-ը փաստացի ստանում է։ Եթե ընդունված դոմեյնը բացակայում է, ավելի հեռու ոչինչ նշանակություն չի ունենա։ Ցանկացած քեշ ստուգելուց առաջ ստուգեք կապի DNS հատկությունները։

Այդ տարբերությունը բացատրում է երբևէ չժամանած դոմեյնի մասին հաղորդումների մեծ մասը։ Այն առաջարկվել է և չի կիրառվել։

Դոմեյնի գրառման երկու տեսակ

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

Մասնավոր անվանատարածքի համար սովորաբար ցանկանում եք միայն երթուղային ձևը։ Այն պահում է կորպորատիվ վերջածանցը ուղղված կորպորատիվ resolver-ին և մնացածը հանգիստ է թողնում։

localhost-ը resolv.conf-ում սխալ չէ

Երբ օգտագործվում է տեղական քեշային resolver, համակարգային ֆայլը ցույց է տալիս loopback հասցեն և ուրիշ ոչինչ։ Այդ գրառումը նույնականացնում է տեղական լսողին, ոչ թե վերին սերվերները, որոնք կառավարիչը տվել է նրան։ Կորպորատիվ հասցեն օրինականորեն բացակայելու է ֆայլից։

Այդ գրառումը հանրային resolver-ով փոխարինելը դասական սխալ ուղղումն է։ Այն վերականգնում է հանրային անվանալուծումը և նույն խմբագրությամբ դեն նետում պայմանական քաղաքականությունը։

Չշփոթեք backend-ները

Կառավարվող dnsmasq օրինակը և համակարգային resolver-ը տարբեր ծրագրեր են՝ տարբեր կարգավորումներով և տարբեր վիճակի տեսքերով։ Մեկի վիճակի հրամանը ոչինչ օգտակար չի ասում մյուսի մասին։

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

Փորձարկեք անվանատարածքը, ոչ միայն պատասխանը

Հարցրեք մեկ թույլատրված մասնավոր անուն և մեկ հանրային հսկիչ անուն հավելվածի սովորական ուղով։ Կորպորատիվ սերվերին ուղիղ հարցումը ապացուցում է, որ գրառումը գոյություն ունի. այն չի ապացուցում, որ հաճախորդն ընտրել է այդ սերվերը։ Երկրորդ հարցումն է, որ ստուգում է քաղաքականությունը։

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