DNS არ იხსნება, როცა VPN-ის kill switch პორტ 53-ს ბლოკავს
Kill switch-ს DNS განზრახ შეუძლია დაბლოკოს. შეადარეთ მხოლოდ გვირაბში გადაწყვეტა ლოკალური resolver-ის გამონაკლისს, შემდეგ კი დაადგინეთ, რომელი შრე რეალურად ჩავარდა.
როცა kill switch გვირაბს ჩამოგდებს, ის DNS-ის გზასაც თან წაიღებს, და დარჩენილი resolver იშვიათად ის არის, რასაც ელოდებით. ორი დიზაინი ამ მომენტს სრულიად განსხვავებულად ეკიდება: დაბლოკოს ყველა DNS პაკეტი, რომელიც გვირაბში არ არის, ანდატოვოს ერთი resolver გამონაკლისად. ორივე დასაცავია. ბრაუზერის ჩანართიდან სიმპტომები თითქმის იდენტურად გამოიყურება, ამიტომ პირველი ამოცანაა გაარკვიოთ, რომელი დიზაინი გაქვთ რეალურად გაშვებული.
ამ განსხვავებას თვალწინ ვინახავ, რადგან შესწორება ორივე შემთხვევაში საპირისპიროა. ერთ დიზაინს უფრო ფართო გამონაკლისი სჭირდება, მეორეს უფრო ვიწრო. გამოცნობა ან პრივატულობა დაგიჯდებათ, ან ნახევარი დღე.
ორი DNS დიზაინი ერთი და იმავე გათიშვისთვის
დიზაინი A resolver-ს გვირაბის უკან მდგომ ჩვეულებრივ სერვისად განიხილავს. Firewall-ის წესები UDP და TCP 53-ს მხოლოდ გვირაბის ინტერფეისზე უშვებს, და კლიენტისთვის მიცემული მისამართი გვირაბში მყოფი resolver-ია. როცა გვირაბი ვარდება, ძიებები ჩერდება, და ეს მოსალოდნელი შედეგია, არა ხარვეზი.
დიზაინი B resolver-ს ლოკალურ ქსელში ხელმისაწვდომად ტოვებს, ჩვეულებრივ როუტერს 192.168.1.1-ზე ან ოპერაციული სისტემის stub-ს 127.0.0.53-ზე, იმ მოსაზრებით, რომ სახელების გადაწყვეტა გვირაბთან ერთად არ უნდა მოკვდეს. ეს მოხერხებულია სახლის LAN-ში, სადაც როუტერი მთელი სახლისთვის წყვეტს. სასტუმროს ან აეროპორტის Wi-Fi-ზე იგივე გამონაკლისი სხვის სერვერზე მიუთითებს, და თქვენ მიერ აკრეფილი ყოველი სახელი ცხადდება, თუმცა თქვენი ვებ-ტრაფიკი დაბლოკილი რჩება.
საზღვარი ის არის, ვის ეკუთვნის resolver. თუ ლოკალურს ენდობით, გამონაკლისი პატარა და პატიოსანი ხვრელია. თუ არა, მხოლოდ გვირაბის დიზაინი ძლებს, და ფასი ის არის, რომ ჩავარდნილი გვირაბი ყველა სახელს თან წაიღებს.
რატომ მუშაობს ჯერ კიდევ თავად VPN კლიენტის ძიება
კლიენტმა კარიბჭის ჰოსტის სახელი უნდა გადაწყვიტოს გვირაბის არსებობამდე, ამიტომ მკაცრი ბლოკი არ უნდა ფარავდეს კლიენტის ჩატვირთვის გზას. კლიენტების უმეტესობა ან ქეშავს საბოლოო წერტილის მისამართს, ან აწვდის დოკუმენტირებულ გამონაკლისს სწორედ იმ ერთი ჰოსტისთვის. თუ თქვენი წესების ნაკრები ამ ძიებას ბლოკავს, გვირაბი არასოდეს დაბრუნდება და ჟურნალები აჩვენებენ კლიენტს, რომელიც საკუთარ სერვერს ვერ აღწევს; ეს პოლიტიკის ხარვეზია, არა DNS-ის.
გაყოფილი DNS მეორე ადგილია, სადაც ეს ჩნდება. კლიენტი შიდა ზონას კერძო resolver-ზე უბიძგებს და დანარჩენს სისტემის resolver-ს უტოვებს. ვარდნის შემდეგ საჯარო სახელები შეიძლება კვლავ იხსნას, ხოლო შიდა დროში იწურება, რადგან კერძო ზონას მარშრუტი აღარ აქვს. მომხმარებლისთვის ეს "VPN-მა ინტერნეტი გატეხა" არის; resolver-ის ჟურნალისთვის ეს ის მოთხოვნაა, რომელიც არასოდეს მოსულა.
systemd-resolved-ის ქვეშ გაყოფას პირდაპირ ხედავთ.resolvectl statusჩამოთვლის თითოეული ბმულის DNS სერვერებს და მარშრუტიზაციის დომენებს, და გვირაბის ჩავარდნის შემდეგ შიდა დომენი კვლავ მიუთითებს სერვერზე ბმულზე, რომელიც აღარ არსებობს. 127.0.0.53-ის stub კვლავ იღებს მოთხოვნას, შემდეგ ელოდება ზედა დინებას, რომელიც არ უპასუხებს, და ამიტომ ხარვეზი წამებს იკავებს ნაცვლად მყისიერი დაბრუნებისა.
დაშიფრული DNS პაკეტურ ფილტრს არ გვერდს უვლის
DNS over HTTPS და DNS over TLS 443 და 853 პორტებზე მოძრაობენ, ამიტომ 53-ე პორტის ბლოკირებადი წესი მათ შესახებ არაფერს ამბობს. "DNS"-ის პორტით დაბლოკვა პორტზეა პოლიტიკა, არა სახელების გადაწყვეტაზე. თუ თქვენი kill switch გვირაბის გარეთ მთელ ტრაფიკს ბლოკავს, DoH შემთხვევით დაფარულია. თუ captive portal-ის ან საჯარო resolver-ისთვის ნებართვა გამოყავით, არ არის დაფარული.
კლიენტის მხარეს კონტროლი იაფი ბერკეტია. Firefox თავის DoH resolver-ს თმობს, როცა კანარის სახელიuse-application-dns.netარ იხსნება, და ამიტომ მართული ქსელები ამ დომენს NXDOMAIN-ად აქვეყნებენ; საწარმო პოლიტიკას შეუძლია ის გამორთულად დაამაგროს. Android Private DNS-ს და Chrome-ის უსაფრთხო DNS-ს საკუთარი გადამრთველები და საკუთარი ნაგულისხმევები აქვთ. მათი გამორთვა უფრო საიმედოა, ვიდრე resolver-ის მისამართების დევნა, რადგან მისამართების სია იცვლება, თქვენი წესები კი არა.
ამის ისეთი ვერსიაც არსებობს, რომელიც საერთოდ არ ეხება გაჟონვას. მიმაგრებული resolver-ის მქონე აპლიკაციას მაინც სჭირდება ქსელური გზა იქ მისასვლელად. დაშიფვრა ცვლის, ვის შეუძლია მოთხოვნის წაკითხვა, და არა იმას, შეუძლია თუ არა პაკეტს მანქანის დატოვება, ამიტომ მთელი მოწყობილობის ბლოკი ამარცხებს პარამეტრს შეხების გარეშე.
შეუსაბამეთ სიმპტომი შრეს
მოხსენებების უმეტესობა ერთი წინადადებით მოდის, და ეს წინადადება ჩვეულებრივ უკვე ასახელებს შრეს. ქვემოთ მოცემული ცხრილი ის არის, რასაც გადავდივარ წესის შეხებამდე; მიზანია გადაწყვიტო, დაიბლოკა მოთხოვნა, არასწორად გაიგზავნა თუ საერთოდ არ გაიგზავნა.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
პირველი ორი სტრიქონი ის არის, რასაც ადამიანები არასწორად დიაგნოსტირებენ. ჩუმი ვარდნა და უარი ბრაუზერში ერთნაირად გამოიყურება, "DNS გატყდა", მაგრამ მათგან მხოლოდ ერთი ნიშნავს, რომ თქვენი kill switch თავის საქმეს აკეთებს. უარი ნიშნავს, რომ რაღაცამ უპასუხა, ამიტომ ბლოკი იქ არ არის, სადაც ფიქრობთ.
აღადგინეთ resolver-ის პოლიტიკა და შემდეგ დაამტკიცეთ
შეასწორეთ დიზაინი და არა სიმპტომი. მხოლოდ გვირაბში გადაწყვეტისთვის დაუშვით 53 გვირაბის ინტერფეისზე, გაუშვით შიდა resolver გვირაბის კონფიგურაციასთან ერთად და დატოვეთ ფიზიკური ბმული ყოველგვარი DNS ნებართვის გარეშე. wg-quick-ში ხაზიDNS =არის ის, რომელიც resolver-ს ინტერფეისის კონფიგურაციაში წერს, ამიტომ მისი გამოტოვებით გვირაბი ძველ resolver-ს ადგილზე ტოვებს და ყოველი მოთხოვნა არასწორ გზაზეა.wg-quick-ის სახელმძღვანელოამ ქცევას პლატფორმების მიხედვით აღწერს.
შემდეგ შეამოწმეთ ამ თანმიმდევრობით. Linux-ზეresolvectl statusაქტიურ ბმულს აჩვენებს,dig +short example.comსაჯარო სახელს ამოწმებს,dig @10.8.0.1 internal.example.comკერძოს ამოწმებს, დაsudo tcpdump -ni any port 53აჩვენებს, რომელ ინტერფეისს იყენებენ პაკეტები, სანამ ორივეს უშვებთ. Windows-ზეGet-DnsClientServerAddress -AddressFamily IPv4დაResolve-DnsName example.comიმავე ორ ფაქტს გვაძლევს: ვინ არის კონფიგურირებული და ვინ პასუხობს.
დაასრულეთ უარყოფითი ტესტით. გათიშეთ გვირაბი, დაადასტურეთ, რომ ახალი საჯარო სახელი ვერ იხსნება, დაადასტურეთ, რომ კერძო სახელი ვერ იხსნება, დადაადასტურეთ, რომ არც ერთი 53-ე პორტის პაკეტი არ გასულა ფიზიკური ადაპტერიდან. ბლოკი, რომელიც მხოლოდ ქეშირებული პასუხებისთვის ძლებს, საერთოდ არ ძლებს.
ჩამონათვალი ბილეთის დახურვამდე:
- ხარვეზის დროს გამოყენებული resolver არის ის, რაც პოლიტიკას გულისხმობს.
- კლიენტის საკუთარი საბოლოო წერტილის ძიება კვლავ ნებადართულია, ქეშით ან გამონაკლისით.
- DoH და DoT ან ბლოკით არიან დაფარული, ან პოლიტიკით გამორთული.
- კერძო ზონები ჩავარდება დახურულად და არა ღიად, როცა გვირაბი გაქრება.