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

პირველი მითი: ნიშანი თქვენს გადამწყვეტს ასახელებს

გაჟონვის ტესტი საცდელ სახელს ხსნის და აცნობებს იმ მისამართს, რომელმაც უპასუხა. ის არ აცნობებს იმ პოლიტიკას, რომელმაც ეს გადამწყვეტი აირჩია, ხოლო როცა მოთხოვნა DNS-ით HTTPS-ის გავლითაა გახვეული, გზაზე მდგომი შუამავალი ყუთი სახელს საერთოდ ვერ ხედავს. ორი სრულიად განსხვავებული მანქანა ერთსა და იმავე დამამშვიდებელ ნიშანს იძლევა: ერთში VPN-მა გაგზავნა 10.8.0.1 და ბრაუზერი მას იყენებს, მეორეში კი ბრაუზერმა სისტემის სია უგულებელყო და სახელი გვირაბით თავის დაშიფრულ პროვაიდერთან გაგზავნა.

განსხვავებას მნიშვნელობა აქვს იმ მომენტში, როცა პირადი სახელი ვერ იხსნება. პირველ განწყობაში VPN-ის გადამწყვეტი კორპორატიულ ზონაზე პასუხობს; მეორეში ბრაუზერს არასდროს უკითხავს, ამიტომ მოკლე ჰოსტის სახელი არ იხსნება და ხარვეზი გატეხილ VPN-ს ჰგავს. ეს შემოწმება კიდევ ერთი გაჟონვის ტესტი არ არის, ეს არის ძებნა სახელზე, რომელიც მხოლოდ ერთმა გადამწყვეტმა იცის.

მეორე მითი: ბრაუზერი გვირაბს ტოვებს

DNS მისამართს ირჩევს, მარშრუტიზაცია კავშირს ატარებს და ეს ორი ცალკე ფენაა. საჯარო DoH პროვაიდერთან გაგზავნილი მოთხოვნა კვლავ TCP 443 პორტია მარშრუტიზებადი მისამართისკენ. თუ თქვენი მარშრუტების ცხრილი ნაგულისხმევ მარშრუტს გვირაბში აგზავნის, ეს მოთხოვნაც გვირაბში გადის. გადამწყვეტის ბრენდი გზას არ განსაზღვრავს.

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

მესამე მითი: ყოველი VPN ყოველ ბრაუზერს სძლევს

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

ამავდროულად, VPN კლიენტების უმეტესობა კავშირის აწევისას სისტემის გადამწყვეტს აყენებს და ჩამოვარდნისას წინას აღადგენს. მორგებული დაშიფრული გადამწყვეტის მქონე ბრაუზერი ამ აღდგენას საერთოდ ვერ ამჩნევს. ამიტომ ერთი და იგივე პროფილი ორ ლეპტოპზე სხვადასხვაგვარად იქცევა და ამიტომ resolv.conf სწორად გამოიყურება, მაშინ როცა ბრაუზერი ჯერ კიდევ სხვას ეკითხება.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

გაუშვით ეს კავშირის დროს, დააკვირდით, რომელ დომენებს ითხოვს ყოველი გადამწყვეტი, და შეადარეთ იმას, რასაც ბრაუზერი თავისი რეჟიმის შესახებ იტყობინება. Mozilla-ს DoH დოკუმენტაცია გონივრული აღწერაა იმისა, როგორ უნდა იმუშაოს ბრაუზერის ნაგულისხმევმა და სარეზერვო ქცევამ.

გადაწყვეტილებას სამი შესავალი აქვს და არა ერთი

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

ConditionWhat it forces
Internal names must resolveSplit DNS: private suffixes to the VPN resolver, the rest to your chosen default
Queries must stay with one operatorPin both the system resolver and the browser mode, and disable fallback
Resolver only reachable through the tunnelKeep the pushed resolver; do not point DoH at an endpoint your routes exclude

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

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

შეამოწმეთ პოლიტიკა, რომელიც გგონიათ, რომ დააკონფიგურირეთ

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

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

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

დაკავშირებული სტატიები