Առանց VPN-ի գաղտնագրված DNS-ը թաքցնում է հարցումը, ոչ թե ձեր հասցեն

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

Գրեք նպատակը նախքան որևէ թեստ գործարկելը։

Քայլ 1. անվանեք այն պաշտպանությունը, որն իրականում ուզում եք

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

VPN-ը ծառայում է երրորդին և, կախված մատակարարից, առաջինին։ Գործիքներից և ոչ մեկը մյուսի գերբազմությունը չէ։

Քայլ 2. ընտրեք լուծիչ և ստուգեք նրա ինքնությունը

DNS over TLS-ը հարցումը փաթաթում է լուծիչի հետ TLS սեսիայի մեջ, և DNS over HTTPS-ը այն փաթաթում է HTTP հարցման մեջ. RFC 7858-ը և RFC 8484-ը նկարագրում են երկուսն էլ, և ոչ մեկը թունել չի պահանջում։ Գործառնական առումով կարևոր է, որ վկայականը ստուգվի ձեր կարգավորած անվան դեմ, որովհետև սխալ կողմի հետ գաղտնագրված սեսիան ավելի վատ է, քան ճիշտ կողմի հետ բաց տեքստը։ Դա նշանակում է խիստ ռեժիմ այնտեղ, որտեղ հարթակը առաջարկում է այն, ոչ թե հնարավորությունների ռեժիմ, որը հետ է քաշվում, երբ ստուգումը ձախողվում է։ Ստուգեք սեսիան ուղղակիորեն նախքան կարգավորմանը վստահելը՝ openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief։

Ձեռքսեղմումը պետք է անվանի ձեր կարգավորած լուծիչը և վերադարձնի շղթա, որը կարող եք ստուգել։

Քայլ 3. որոշեք ձախողման վարքը

Յուրաքանչյուր իրականացում ունի քաղաքականություն անհասանելի գաղտնագրված լուծիչի համար, և այդ քաղաքականությունն է գաղտնիության որոշումը։ Խիստ ռեժիմը ձախողում է որոնումը, ինչը տեսանելի և նյարդայնացնող է։ Հնարավորությունների ռեժիմը նորից փորձում է բաց տեքստով, ինչը անտեսանելի է և չեղարկում է նպատակը հենց այն օրը, երբ դա կարևոր է։ Ընտրեք գիտակցաբար, ապա գրեք ընտրությունը պահանջի կողքին։

systemd-resolved-ում դա նշանակում է DNSOverTLS=yes ոչ opportunistic; Android-ում դա նշանակում է Private DNS-ի հոսթի անվան ռեժիմը՝ ավտոմատի փոխարեն։

Ստուգեք, թե իրականում ինչ է ուժի մեջ, այս հրամանով՝ resolvectl status | grep -i -A1 "dns over tls", որովհետև drop-in ֆայլը, որը երբեք չի վերաբեռնվել, ոչինչ չի փոխում։

Քայլ 4. ստուգեք, որ հավելվածները հետևում են համակարգի լուծիչին

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

Կազմակերպության մասնավոր անունները մնում են հաստատված ներքին լուծիչի վրա։ Դրանք հանրային ծառայություն ուղարկելը, որպեսզի թեստը կոկիկ երևա, միտումնավոր այլ խնդիր է ստեղծում։

Քայլ 5. կարդացեք արտահոսքի թեստը պահանջի դեմ

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

Եթե նպատակը հարցումները տեղական ցանցից հեռու պահելն էր, ապա ձեր սովորական լուծիչը ցույց տվող թեստը իրական հայտնություն է։ Եթե նպատակը զննարկման ընթացքում անանունությունն էր, ոչ մի DNS կարգավորում դա երբեք չէր տա։

Գրեք ընդունման տողը նպատակի լեզվով՝ այս որոնումները օգտագործում են այս ստուգված լուծիչը այս պայմաններում։ Ավելի լայն ամեն ինչ պնդում է, որը չեք կարող ստուգել։