Pritunl-ի մասնավոր DNS-ը ձախողվու՞մ է. ավելացրեք նեղ resolver-ուղի

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

Համոզվեք, որ resolver-ը մերժում է ձեր client pool-ը

Սկսեք ապացուցելով, որ ձախողումը աղբյուրի մասին է, ոչ թե հասանելիության։ Միացված client-ից ուղղակիորեն հարցրեք մասնավոր resolver-ին և դիտեք՝ հարցումը ժամկետը լրանու՞մ է, թե՞ վերադառնում է որպես մերժում։ dig @10.40.0.53 intranet.example.net +time=2 +tries=1-ի ժամկետի լրանալը, մինչ դարպասից նույն հարցումը հաջողվում է, մատնանշում է resolver-ի վրա մուտքի քաղաքականություն։ SERVFAIL պատասխանը մատնանշում է բոլորովին այլ տեղ՝ սովորաբար գոտին կամ վերին հոսքի փոխանցիչը։

Փորձարկումից առաջ գրանցեք client-ի հասցեն։ Client-ի վրա ip -4 addr show tun0-ը կամ վահանակում ցուցադրված լիզինգը ասում է, թե որ pool-ն է տեսնում resolver-ը։

Այնուհետև համոզվեք, որ ուղին ընդհանրապես գոյություն ունի։ Այն ուղին, որը resolver-ի հասցեն ուղարկում է թունել, նախապայման է, ոչ լուծում. եթե փաթեթները երբեք չեն հասնում, աղբյուրի քաղաքականությունը ընդհանրապես չի դիտարկվում։ Ստուգեք այն client-ի վրա ip route get 10.40.0.53-ով։

Ավելացրեք մեկ host-ուղի՝ ամեն ինչ թարգմանելու փոխարեն

Pritunl-ի մասնավոր DNS ուղեցույցը նկարագրում է նեղ լուծումը՝ NAT-ով /32 ուղի resolver-ի հասցեի համար, այդ հասցեն ընտրված որպես client-ների DNS սերվեր։ Ուղին փոխում է resolver-ի տեսած աղբյուրը միայն DNS երթևեկության համար։ Հավելվածների երթևեկությունը պահպանում է աղբյուրը պահող դիզայնը, որը դուք ընտրել եք դրա համար։

Կարգավորեք այն սերվերի աջակցվող ուղու սեփականատիրոջ միջոցով՝ նախ ստուգելով գոյություն ունեցող ուղիները համընկնումների համար։ Վերևի օրինակում նշանակակետը NAT-ով 10.40.0.53/32-ն է, և client pool-ը մնում է 10.90.0.0/24։ Մի թարգմանեք ամբողջ մասնավոր տիրույթը մեկ ծառայություն շտկելու համար, որովհետև client-ի իրական հասցեի վրա հիմնված յուրաքանչյուր ներքևի քաղաքականություն կսկսի փոխարենը տեսնել դարպասը։ Հաստատեք այն հասցեն, որը resolver-ը փաստացի ստանում է՝ փորձնական որոնման ընթացքում դիտելով նրա հարցումների մատյանը։ Մեկ host-ուղին ինքնին ոչինչ չի ապացուցում թարգմանության կամ թույլտվության մասին։

Resolver-ը դեռ պետք է թույլատրի թարգմանված աղբյուրը UDP-ով և TCP-ով, և նրա պատասխանները պետք է կարողանան վերադառնալ։ Աղբյուրը փոխելը չի կարող ստեղծել բացակայող գոտի կամ գրառում։

Որոշեք՝ սերվերն է ուղարկում հարցումը, թե client-ը

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

Որոշեք, թե որ մոդելն է ակտիվ, նախքան որևէ բան ավելացնելը։ Երեք համընկնող վերանորոգում, փոխանորդ, client-ի resolver-ի փոխարինում և ձեռքով NAT սկրիպտ սովորաբար նշանակում են, որ ոչ ոք չի հաստատել՝ որ բաղադրիչը պետք է ուղարկի հարցումը։ Ստուգեք նաև bootstrap-ը. միայն մասնավոր resolver-ը չի կարող լինել վերջնակետը գտնելու միակ միջոցը մինչև թունելի գոյությունը, և resolver-ի մշտական փոփոխությունը չպետք է ապրի կապից ավելի։

Փորձարկեք մասնավոր որոնում, ոչ թե հանրային վեբ էջ

Փոփոխությունը կիրառելուց և նորից միանալուց հետո ստուգեք client-ի գործող resolver կարգավորումը, ապա լուծեք մի անուն, որը գիտեք, որ գոյություն ունի միայն մասնավոր գոտում։ dig intranet.example.net-ը առանց հստակ սերվերի ցույց է տալիս, թե client-ը իրականում ինչ է օգտագործում։ Դրան հետևեք հարցումով դեպի այն հասցեն, որը վերադարձրել է այդ որոնումը, որովհետև լուծումը և ծառայության հասանելիությունը առանձին քայլեր են։ Բրաուզերը, որը հանրային կայքեր է բեռնում DNS-over-HTTPS-ով, ոչինչ չի ապացուցում օպերացիոն համակարգի մասնավոր resolver-ուղու մասին։ Հանրային երկրորդային resolver-ը նույնպես իշխանություն չէ ներքին գոտու համար։

Գրանցեք resolver-ի հասցեն, /32 ուղին և client-ի DNS կարգավորումը միասին սերվերի գրառումներում։ Այդ կարգավորման կեսը միայնակ վերականգնելը վերարտադրում է սկզբնական ձախողումը։

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