დაშიფრული DNS VPN-ის გარეშე მალავს მოთხოვნას და არა თქვენს მისამართს

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 პარამეტრი ვერ მოგცემდა ამას.

დაწერეთ მიღების ხაზი მიზნის ენაზე: ეს ძიებები იყენებენ ამ გადამოწმებულ გადამწყვეტს ამ პირობებში. ყველაფერი უფრო ფართო არის მტკიცება, რომლის შემოწმებაც არ შეგიძლიათ.