Ձեր VPN-ը գաղտնագրո՞ւմ է DNS-ը, թե՞ միայն հաջորդ թռիչքը։

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

Գրի առեք, թե ով է ստանում հարցումը յուրաքանչյուր փուլում, նախքան կարգավորման ֆայլին դիպչելը։

Երկու դասավորություն նույն տեսքն ունեն կարգավորումների էջում

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

Տարբերությունը չափելի է, ոչ թե փիլիսոփայական։ Փնտրեք TLS սեսիան հաճախորդի կամ սերվերի վրա, և կիմանաք, թե որ դասավորությունն ունեք իրականում։

Քարտեզագրեք լուծիչների շղթան նախքան այն փոխելը

Հաշվեք ուղու լուծիչները և անվանեք յուրաքանչյուրի դերը։ Փոխանցող բաղադրիչը հարցումը հանձնում է մեկ այլ լուծիչի, մինչդեռ ռեկուրսիվ լուծիչը կատարում է պատասխանը գտնելու աշխատանքը և կարող է ուղղակիորեն խոսել հեղինակավոր սերվերների հետ։ Այդ դերերը առանձին են սահմանված հենց այդ պատճառով, և RFC 9076-ի լուծիչի սահմանումները արժե կարդալ նախքան ենթադրելը, որ գոյություն ունի մեկ վերին նպատակակետ։ Հոսթը, որն ինքն է վարում իր ռեկուրսիվ լուծիչը, չունի մեկ "վերին" հասցե՝ գաղտնագրելու, ինչը անվավեր է դարձնում ողջ ծրագիրը։

Ապա հարցրեք, թե որ բաղադրիչն է հաճախորդը կարգավորված օգտագործելու։ VPN պրոֆիլի կողմից ուղարկված DNS հասցեն ասում է, թե ուր են գնում հարցումները, ոչ թե որ գործընթացն է պատասխանում դրանց։

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

Ստուգեք, թե որ թռիչքն է գաղտնագրված

Սկսեք հաճախորդից և հաստատեք՝ արդյոք այն ունի TLS սեսիա դեպի 853 պորտ։ 53 պորտով ճիշտ լուծվող հարցումը ոչինչ չի ապացուցում գաղտնագրման մասին։

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

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

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

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

Գրանցեք սեփականատիրոջը և ձախողման վարքը

Սեփականությունը որոշում է, թե ինչ կարող եք խոստանալ։ Սարքի սեփականատերը վերահսկում է հաճախորդի կողմի գաղտնագրված միացումը, մինչդեռ VPN ադմինիստրատորը վերահսկում է հաջորդ միացումը, որը ստեղծում է իր փոխանցիչը։ Ով ոչ մեկը չի կառավարում, կարող է միայն նկարագրել ուղին։

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

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