დაუშვით 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 სპეციფიკაცია არის მითითება იმ დაშიფრული გზისთვის, რომელსაც თქვენი პორტის წესი ვერ ხედავს.