VPN დაკავშირებულია, მაგრამ სახელები ვერ იხსნება: სად ტყდება DNS სინამდვილეში

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

რა სჭირდება ძიებას სინამდვილეში

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

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

Linux და macOS ერთსა და იმავე კითხვას სხვადასხვა ბრძანებით პასუხობენ და პასუხი იმავე წაკითხვას იმსახურებს: resolvectl status და scutil --dns ორივე ინტერფეისების მიხედვით ჩამოთვლის სერვერებს. შეადარეთ ეს სია იმ მისამართს, რომელსაც პროფილი აცხადებს, თითქოს აგზავნის. აქაური შეუსაბამობა ხსნის ყველაფერს ქვემოთ, ამიტომ მოაგვარეთ იგი სახელების გამოცდამდე.

სცადეთ ერთი საჯარო და ერთი კერძო სახელი

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

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

nslookup ბეჭდავს როგორც სერვერს, რომელსაც ჰკითხა, ისე მიღებულ პასუხს, და ეს ზუსტად ის წყვილია, რომელიც გჭირდებათ. გაუშვით ორჯერ იმავე გარსში და დაწერეთ პასუხის მიმცემი მისამართი ყოველი პასუხის გვერდით.

nslookup example.com
nslookup host.corp.example 10.20.30.53

დაადასტურეთ, რომ კლიენტი ნამდვილად აღწევს ამ სერვერამდე

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

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

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

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

გახსოვდეთ, რომ ბრაუზერებს შეუძლიათ სისტემური გამხსნელის გვერდის ავლა

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

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

გაასუფთავეთ ქეში და თავიდან სცადეთ რეალური ამოცანა

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

შემდეგ გაიმეორეთ თავდაპირველი ამოცანა და არა სინთეტიკური ძიება, რადგან ამოცანაა ის, რაც მომხმარებლისთვის მნიშვნელოვანია. ერთხელ ხელახლა დაუკავშირდით, რომ განმეორებითი ტესტი დაფაროს ის მდგომარეობა, რომელშიც მომხმარებელი ნამდვილად იქნება. Microsoft-ის nslookup-ის საცნობარო არის გვერდი, რომელიც ღირს შეინარჩუნოთ მოთხოვნის არგუმენტებისთვის.

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