რატომ ამისამართებს ჰოტსპოტი DNS-ს VPN-ის დაკავშირებამდე?
ჰოტსპოტი საკუთარ ქსელში გადაწერს მოთხოვნებს, და ჰოსტის სახელის საბოლოო წერტილი წყდება მანამ, სანამ რაიმე გვირაბი არსებობს. თვალი ადევნეთ, რომელმა გადამწყვეტმა უპასუხა თითოეულ მოთხოვნას.
სასტუმროს ქსელში შეერთება თქვენ წინაშე ორ DNS გადაწყვეტილებას აყენებს სხვადასხვა მომენტში: მოთხოვნები, რომლებსაც მოწყობილობა შესვლისას აკეთებს, და მოთხოვნები, რომლებიც გვირაბის აწევის შემდეგ კეთდება. ჰოტსპოტს შეუძლია პირველზე გავლენა მოახდინოს იმ ქსელის მეშვეობით, რომელსაც აკონტროლებს. მეორე დამოკიდებულია თავად კლიენტის პოლიტიკაზე, რაც ცალკე შესამოწმებელი საკითხია.
თანმიმდევრულად გაიარეთ კავშირი, პირველი DHCP იჯარიდან იმ მოთხოვნამდე, რომელმაც კერძო სახელი გადაწყვიტა. მაშინ ორი ხარვეზი, რომლებიც დახმარების ბილეთში იდენტურად გამოიყურება, მკაფიოდ იყოფა: ერთი მოხდა გვირაბამდე, მეორე — მის შიგნით.
რას შეიძლება შეეხოს ჰოტსპოტმა და რას არა
წვდომის ქსელი DHCP-ში გასცემს გადამწყვეტის მისამართს და შეუძლია 53 პორტის ჩარევა ამ მისამართისკენ. ეს საკმარისია ყველა დაუცველ მოთხოვნაზე პორტალის მისამართით ან ბლოკირების გვერდით პასუხის გასაცემად. ასევე საკმარისია VPN კლიენტის გასატეხად, რომლის საბოლოო წერტილიც ჰოსტის სახელად არის დაწერილი.
რაც ჰოტსპოტს არ შეუძლია, არის მოთხოვნის წაკითხვა ან გადაწერა მას შემდეგ, რაც ის დამყარებული გვირაბის შიგნით მოძრაობს, თუ, რა თქმა უნდა, გვირაბი ნამდვილად ატარებს მას. ჩარევა დამოკიდებულია კითხვის ღია ტექსტში დანახვაზე.
მოთხოვნები მაინც ტოვებენ გვირაბს ჰოტსპოტთან დაუკავშირებელი მიზეზებით: ბრაუზერის უსაფრთხო DNS პარამეტრი, split-DNS წესი, რომელიც კორპორატიულ სუფიქსს ლოკალურ გადამწყვეტზე ტოვებს, ან კლიენტი, რომელიც DNS-ის გვირაბიდან გამოყოფაზეა კონფიგურირებული. თითოეული კლიენტის მხრიდან არჩევანია და თითოეული გარედან ჰოტსპოტის ჩარევად გამოიყურება.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
საწყისი მოთხოვნა ხდება გვირაბის არსებობამდე
ჰოსტის სახელის მიმღებ კლიენტს ჯერ ის უნდა გადაწყვიტოს, და იმ მომენტში არც ერთი გვირაბი არ იცავს მოთხოვნას. თუ ჰოტსპოტი პორტალის მისამართით პასუხობს, მოლაპარაკება იშლება ან იკიდება. თუ არაფრით პასუხობს, კლიენტი სახელის შეცდომას აცნობს და გვირაბი არასდროს იწყება. ორივე შედეგი ხსნის ცარიელ გვირაბის ჟურნალს, რომელიც სხვაგვარად უწყინარად გამოიყურება.
ოპერაციული სისტემები ასევე უშვებენ საკუთარ კავშირის შემოწმებებს და პორტალის აღმოჩენას, რომლებიც აღწერილია RFC 8910-ში და RFC 8952-ში, და ეს მოთხოვნები გადიან ნებისმიერი VPN-ის აწევამდე. მათი დანახვა პროქსის ჟურნალში მოსალოდნელი ქცევაა და არა გაჟონვის მტკიცებულება.
პრაქტიკული გამოსავალია კლიენტს მივცეთ საბოლოო წერტილი, რომელსაც გადაწყვეტა არ სჭირდება. როცა ეს შეუძლებელია, ჯერ შესვლა დაასრულეთ და შემდეგ დაუკავშირდით.
გაარკვიეთ, რომელმა გადამწყვეტმა უპასუხა
ჰკითხეთ სისტემას და არა ბრაუზერს, და გაუშვით მოთხოვნა ორჯერ: ერთხელ იმ გადამწყვეტის მეშვეობით, რომელსაც მოწყობილობა ახლა იყენებს, ერთხელ — ფიქსირებულ მისამართზე.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
პირველი ბრძანების პასუხი, რომელიც მესამისგან განსხვავდება, გეუბნებათ, რომ ლოკალური გადამწყვეტი სხვა რამეს აბრუნებს, და სწორედ ამას აკეთებს გადამისამართებელი ჰოტსპოტი. მესამის ხარვეზი პირველის წარმატებასთან ერთად პორტალზე მიუთითებს: ლოკალურმა გადამწყვეტმა შესვლის მისამართი მოგვცა, მაშინ როცა გამავალი 53 პორტი ჩამოგდებული იყო. ორივეზე დროის ამოწურვა ნიშნავს, რომ ქსელი DNS-ს აგდებს ავთენტიფიკაციის დასრულებამდე.
გაიმეორეთ დაკავშირების შემდეგ და შეადარეთ. ქეშირებული პასუხი გადასვლას გადაურჩება, ამიტომ გაასუფთავეთ ქეში ან მეორე დაკვირვებისთვის ახალი სახელი იკითხეთ.
შემდგომი მოთხოვნები დატოვეთ იმ გზაზე, რომელიც გინდოდათ
სრული გვირაბის პროფილი, რომელიც DNS-საც იჭერს, ყველაზე მარტივი მოწყობაა: ყოველი აპლიკაციის ყოველი მოთხოვნა მიდის იმ გადამწყვეტთან, რომელსაც გვირაბი უბიძგებს, და ლოკალური ქსელი მხოლოდ დაშიფრულ ტრაფიკს ხედავს. დაამტკიცეთ ეს დაკავშირების შემდეგ შიდა და საჯარო სახელის გადაწყვეტით და შემდეგ ორივე პასუხის იმასთან შედარებით, რასაც გვირაბის გადამწყვეტი მარტო აბრუნებს.
Split-DNS-ს სჭირდება განზრახ დაწერილი დომენების სია: კორპორატიული სუფიქსები გვირაბით, დანარჩენი ყველაფერი ლოკალურად, და ორივეს შორის გადაფარვა არ არის.
ბრაუზერის უსაფრთხო DNS ამ პოლიტიკის გარეთაა, ამიტომ თუ ის გამორთული უნდა იყოს იმისთვის, რომ პროფილი პროგნოზირებად მოიქცეს, გამორთეთ ის ამ პროფილისთვის და არა მანქანისთვის. ეს გააკეთეთ ბრაუზერის პარამეტრებში და არა სისტემის გადამწყვეტის რედაქტირებით, რომ ცვლილება შემდეგ ჯერზე ჩანდეს. ჩაწერეთ პასუხი, გადამწყვეტი და კავშირის ეტაპი ერთ ხაზში თითო ტესტზე. მოხსენება, რომელიც ამბობს, რომ DNS ვერ შესრულდა სასტუმროს Wi-Fi-ში, აღწერს სიმპტომს მინიმუმ სამი სხვადასხვა მიზეზით.