Թույլատրել DNS-ը միայն ձեր VPN լուծիչով․ քայլ առ քայլ ուղեցույց
Հետևեք մեկ անվանման որոնմանը զննարկիչից մինչև պատասխանը։ Տեսեք, թե որտեղ է ընտրվում լուծիչը, որտեղ է այն պարտադրում հրաշորմը և ինչը երբեք չի ծածկում 53 պորտի կանոնը։
Հետևեք մեկ անվանման որոնմանը այն պահից, երբ մուտքագրում եք այն։ Զննարկիչը հարցնում է օպերացիոն համակարգին, օպերացիոն համակարգը հարցնում է այն լուծիչին, որն ընտրում է իր քաղաքականությունը, և հարցումը դուրս է գալիս սարքից ինչ-որ ինտերֆեյսով և ինչ-որ տրանսպորտով։ Ձեր VPN նախագիծն ասում է, որ պատասխանը պետք է գա որոշակի լուծիչից որոշակի ուղով։ Այս երկու պնդումների միջև եղած բացը հենց այն է, ինչ դուք կարգավորում եք, ապա պարտադրում։
Քայլ 1․ անվանեք լուծիչը և ուղին
Գրեք երեք բան նախքան հրաշորմին դիպչելը․ լուծիչի հասցեն, այն արձանագրությունը և պորտը, որոնք սպասում եք, և այն ինտերֆեյսը, որով հարցումը պետք է դուրս գա։ Առանց այդ ցանկի կանոնը ենթադրություն է տրաֆիկի մասին, ոչ թե որոշման կատարում։ VPN-ը կարող է կրել հավելվածների տվյալներ, մինչ DNS-ը հետևում է առանձին կարգի, և դա ինքնին սխալ չէ։ Դա այն է, ինչ տեղի է ունենում, երբ ոչ ոք հաճախորդին այլ բան չի ասել։
Ուղին բացահայտ անվանելը նախագծի և պատահականության տարբերությունն է։ Դա նաև ձեզ ինչ-որ բան է տալիս ավելի ուշ ստուգելու համար, որովհետև յուրաքանչյուր դիտարկում կարելի է համեմատել գրավոր սպասման հետ։ Պահեք այդ ցանկը փոփոխության տոմսում, ոչ թե ինչ-որ մեկի գլխում։
Քայլ 2․ քաղաքականությունը դրեք այնտեղ, որտեղ այն իրոք ապրում է
Լուծիչի ընտրությունը հաճախորդինն է․ օպերացիոն համակարգի ցանցային կարգավորումը, VPN հաճախորդի սեփական կարգավորումները կամ կառավարվող զննարկիչի քաղաքականությունը։ Նախ դրեք այնտեղ, այն մեխանիզմով, որին աջակցում է հարթակը, որովհետև հրաշորմը չի կարող ստիպել հաճախորդին ընտրել լուծիչ, որի մասին նրան երբեք չեն ասել։ Բաժանված թունելով հաճախորդի վրա բացահայտ ասեք, թե որ տիրույթներն են գնում ներքին լուծիչին։ Կառավարվող պարկում զննարկիչի քաղաքականությունը հաճախ DoH-ի միակ լծակն է, որովհետև զննարկիչը կարող է ընտրել իր գաղտնագրված լուծիչը՝ անկախ համակարգի կարգավորումից։
Եթե բաց թողնեք սա և ուղիղ գնաք հրաշորմին, կստանաք կանոն, որը թույլ է տալիս ճիշտ լուծիչին, և հաճախորդ, որը երբեք չի օգտագործում այն։ Կանոնը ճիշտ է թվում, իսկ լուծիչի մատյանները մնում են դատարկ, ինչը շփոթեցնող զույգ է վրիպազերծման համար։ Նախ կարգավորեք ընտրությունը, ապա պարտադրեք այն։
Քայլ 3․ պարտադրեք ուղին նեղ շրջանակում
Այժմ ավելացրեք ցանցային թույլտվությունը թույլատրված ուղու համար․ լուծիչի հասցեն, արձանագրությունը և պորտը, և այն ինտերֆեյսը, որով այն պետք է դուրս գա։ Պահեք կանոնը սահմանափակ այդ լուծիչով՝ փոխարենը թույլատրելու ամբողջ ելքային DNS-ը։ Ստորև երեք ուղիներն այն են, որոնք կարող է անցնել ժամանակակից հաճախորդը, և միայն առաջինն է ծածկվում 53 պորտի կանոնով։
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
DoH-ը և DoT-ը արգելափակելը օրինաչափ է․ ենթադրել, որ 53 պորտի կանոնն արդեն արգելափակել է դրանք, այդպես չէ։ DoH օգտագործող զննարկիչը լուծում է անունները մի ուղով, որը ձեր կանոնը երբեք չի նկարագրել, և սեփական լուծիչով հավելվածը նույնն է անում։ Գրեք յուրաքանչյուր ուղին, որը պատրաստվում եք թույլատրել, և յուրաքանչյուրը, որը պատրաստվում եք մերժել։ Կանոնը, որը ուղի չի անվանում, դրա մասին որոշում չի կայացրել։
Քայլ 4․ հետևեք մասնավոր և հանրային անուններին
Բաժանված DNS-ը դիտավորյալ միայն մասնավոր անվանատարածքներն է ուղարկում ներքին լուծիչին, մինչ հանրային անունները գնում են այլ տեղ, ուստի նախագծում մեկից ավելի լուծիչ ունենալը արտահոսք չէ։ Արտահոսքն այն հարցումն է, որը պետք է գնար ձեր լուծիչին և հայտնվում է այլ տեղ, կամ անհասանելի նախատեսված ուղի, որը հաճախորդին լուռ հետ է գցում։ Այդ երկու դեպքերն են, որ պետք է փնտրել։ Հետևեք մեկ ներքին և մեկ հանրային անվանը նախատեսված քաղաքականության ներքո և նշեք, թե որ լուծիչը պատասխանեց յուրաքանչյուրին։
Ձեր լուծիչը հաղորդող փորձարկման կայքը ակնարկ է, ոչ ապացույց, որովհետև այն տեսնում է միայն իրեն հասած հարցումները։ Երբ պետք է իմանաք, թե հարցումն իրականում որ ուղին է անցել, գրավեք այն հաճախորդի կողմում, ապա համեմատեք երկու դիտարկումները։ Երբ դրանք չեն համընկնում, դուք գտել եք անկում, որը ոչ ոք չի փաստագրել։
Եթե լուծիչի հասցեն ճիշտ է, բայց անհասանելի, խնդիրը երթուղորդման կամ զտման մեջ է, ոչ թե քաղաքականության։ Հետևեք հարցմանը այդ հասցեով և հաստատեք, որ պատասխանը վերադառնում է սպասվող ինտերֆեյսով, նախքան լուծիչի որևէ կարգավորում փոխելը։
Քայլ 5․ պահեք հետադարձ ուղի
Նախքան դարպասի DNS հասանելիությունը խստացնելը, հաստատեք վերականգնման եղանակ, որը կախված չէ անունների լուծումից։ Կոտրված լուծիչը դժվարացնում է հասնել վերանորոգման բոլոր գործիքներին, ներառյալ նրանք, որոնցով կչեղարկեիք փոփոխությունը։ Պահեք տեղական կոնսոլ կամ գոտուց դուրս ուղի բաց, մինչև նոր քաղաքականությունը ապացուցվի։ Հեռացրեք այն միայն այն բանից հետո, երբ քաղաքականությունը դիմացել է վերամիացմանը։
Վերամիացումից կամ զննարկիչի քաղաքականության թարմացումից հետո կրկին ստուգեք փաստացի վիճակը, որովհետև երկուսն էլ կարող են փոխել լուծիչը՝ առանց ձեր կանոնը փոխելու։ Պահանջը հարցումների համար հայտնի ստացող և պաշտպանված ուղի է, ոչ թե մեկ սքրինշոթի վրա հանգստացնող լուծիչի պիտակ։ RFC 8484 DNS over HTTPS ճշգրտումը հղումն է այն գաղտնագրված ուղու, որը ձեր պորտի կանոնը չի տեսնում։