შეცვალა თუ არა VPN-მა ჩემი DNS? შეადარეთ ჩართვამდე და შემდეგ
პროფილს შეუძლია განზრახ გადაიტანოს თქვენი მოთხოვნები. შეადარეთ რეზოლვერის პოლიტიკა და ფაქტობრივი პასუხი VPN-ის დაკავშირებამდე და შემდეგ, ერთი ცვლადის შენარჩუნებით.
თქვენ უერთებთ გვირაბს, ხსნით პირად დაფას და სახელი იხსნება მისამართზე, რომელიც არასდროს გინახავთ. ან პირიქით ხდება: ბრაუზერი აგრძელებს მუშაობას, მაშინ როცა ბრძანების ხაზის ინსტრუმენტი უცებ არაფერს ხსნის. ორივე შედეგი ერთი და იმავე ცვლილებიდან მოდის და ადამიანები ჩვეულებრივ ამას ერთი წინადადებით ხსნიან VPN-ის შესახებ, რომელიც „საკუთარ DNS-ს იყენებს“, და ეს საკმარისად ზუსტი არ არის გამართვისთვის ან გადამოწმებისთვის. ამ წინადადებაში ორი კითხვა იმალება: რომელი მოთხოვნები უნდა აიღოს ამ პროფილმა და გაგზავნა თუ არა თქვენმა მოწყობილობამ ისინი რეალურად იმ რეზოლვერთან, რომელიც მას მისცეს? მათი განცალკევებით შენარჩუნება მთელი მეთოდია, რადგან მათი შემრევი ტესტი ორივე მიმართულებით თავდაჯერებულ არასწორ პასუხს იძლევა.
რატომ აძლევს პროფილი საერთოდ რეზოლვერს
გვირაბის შიგნით, შორეული ბოლოს მიღმა არსებული სახელები ჩვეულებრივ იხსნება მისამართებზე, რომლებიც მხოლოდ ამ ქსელში არსებობს. კერძო ზონას, როგორიცაა corp.internal, არ აქვს საჯარო დელეგირება, ამიტომ მისი მომსახურე რეზოლვერი ხელმისაწვდომი უნდა იყოს გვირაბის შიგნიდან. იგივე მექანიზმი მეორე მიზანსაც ემსახურება: როცა მოთხოვნები სხვაგვარად თქვენი პროვაიდერის გავლით გავიდოდა, შორეული მხარის რეზოლვერი მოთხოვნას დაშიფრული გზის შიგნით ინახავს. ამიტომ DNS სერვერის მისამართი კავშირის პოლიტიკის ნაწილად მოდის და არა როგორც გლობალური პარამეტრი, რომელიც ერთხელ აირჩიეთ მოწყობილობისთვის.
მისამართი თავისთავად არაფერს წყვეტს. რეზოლვერს შეუძლია პასუხის გაცემა მხოლოდ მაშინ, თუ მასთან გზა არსებობს, და ყველაზე გავრცელებული ხარვეზია რეზოლვერი, რომელიც ხელმისაწვდომია მხოლოდ მანამ, სანამ გვირაბი აწეულია. როცა გვირაბი ვარდება და პოლიტიკა რჩება, მოთხოვნები მიდის მისამართზე გზის გარეშე, და სიმპტომი დროის ამოწურვაა და არა სუფთა შეცდომა. ეს განსხვავება მნიშვნელოვანია, როცა კითხულობთ შემდეგ ტესტის შედეგს, რადგან დროის ამოწურვა ადამიანებს იმ ტრანსპორტის პარამეტრებში აგზავნის, რომლებიც საერთოდ არ მონაწილეობდნენ.
შეადარეთ ორი კონსტრუქცია პასუხების შედარებამდე
სრული გვირაბი და გაყოფილი DNS საწინააღმდეგო მოლოდინებს ქმნის და არც ერთი მათგანი ხარვეზი არ არის. სრული გვირაბის დროს ყოველი მოთხოვნა შეიძლება გადავიდეს პროვაიდერთან ან კორპორატიულ რეზოლვერთან, ამიტომ საჯარო სახელების განსხვავებული პასუხი დაკავშირების შემდეგ მოსალოდნელია. გაყოფილი DNS-ის დროს მხოლოდ სიაში მოცემული დომენები მიდის კერძო რეზოლვერთან, დანარჩენი კი ლოკალური რჩება; Windows-ში დომენების სია Name Resolution Policy Table-ში ცხოვრობს, macOS-ში DNS პარამეტრების შესაბამის დომენებში, ხოლო systemd-resolved ჰოსტზე თითოეული კავშირის მარშრუტიზაციის დომენებში.
ეს არის ის შედარება, რომელიც პირველად უნდა გაკეთდეს, რადგან ის წყვეტს, რა ითვლება ხარვეზად. გაყოფილი DNS-ის დროს, საჯარო სახელი, რომელიც ახალი რეზოლვერიდან პასუხობს, არის ის, რაც გამოკვლევას ღირს, ხოლო სწორად პასუხობს შიდა სახელი ნიშნავს, რომ სისტემა თავის საქმეს აკეთებს. სრული გვირაბის დროს ანომალიაა საჯარო სახელი, რომელიც ჯერ კიდევ თქვენი პროვაიდერის რეზოლვერიდან პასუხობს. Microsoft-ის დოკუმენტაცია VPN სახელების ამოხსნის შესახებ აღწერს ამ წესების Windows თანმიმდევრობას, მათ შორის იმას, თუ როგორ განიხილება შესაბამისი პოლიტიკის ჩანაწერი ადაპტერის საკუთარ სერვერებამდე.
ოთახში მესამე რეზოლვერიც არის, რომლის დავიწყებაც ადვილია. ბრაუზერის უსაფრთხო DNS დამოუკიდებლად ხსნის სახელებს და შეუძლია პასუხის გაცემა გააგრძელოს მას შემდეგ, რაც გვირაბმა ოპერაციული სისტემის პოლიტიკა შეცვალა, ამიტომ ჩატვირთული გვერდი ამტკიცებს, რომ ბრაუზერის რეზოლვერმა იმუშავა და არა ის, რომ პროფილი გამოყენებულია. თუ მხოლოდ ბრაუზერის ნაჩვენებს ადარებთ, დროის ნახევარში არასწორ ფენას ამოწმებთ.
ჩაწერეთ საწყისი მდგომარეობა მხოლოდ ერთი ცვლადით
შეცვალეთ გვირაბი. ამავე ნაბიჯში არ შეცვალოთ ასევე სახელი, ინსტრუმენტი ან ძიების სუფიქსი. აირჩიეთ სახელი, რომელზეც შეკითხვის უფლება გაქვთ, ჩაიწერეთ რომელი აპლიკაცია გამოიყენეთ და დაწერეთ ან დაბრუნებული მისამართი, ან ზუსტი შეცდომა. Windows-ში Get-DnsClientServerAddress -AddressFamily IPv4 ბეჭდავს სერვერებს თითოეული ადაპტერისთვის, ხოლო Get-DnsClientNrptPolicy პოლიტიკის ჩანაწერებს; systemd-resolved-ით Linux-ში resolvectl status აჩვენებს თითოეული კავშირის DNS სერვერებსა და მარშრუტიზაციის დომენებს; macOS-ში scutil --dns ბეჭდავს რეზოლვერების იმ თანმიმდევრობას, რომელსაც სისტემა რეალურად მიჰყვება.
შემდეგ დაუკავშირდით კლიენტის ჩვეულებრივი ელემენტებით და გაიმეორეთ ზუსტად იგივე ბრძანებები. შეინახეთ პირველი გამონატანი და არა მისი გახსენება, რადგან შედარება მთელი აზრია და ქეშის გასუფთავების შემდეგ აღებული მეორე კითხვა უკვე სხვა გაზომვაა. თუ საწყისი მდგომარეობა ბრაუზერის წინა პლანზე ყოფნით აიღეთ და დაკავშირების შემდეგ გაშვება ტერმინალში ხდება, თქვენ ორ რეზოლვერს ადარებთ და არა ერთი რეზოლვერის ორ მდგომარეობას.
გამოკვეთილი მოთხოვნა და აპლიკაციის ძიება სხვადასხვა ტესტია
ერთი კონკრეტული სერვერისთვის კითხვა, nslookup name 10.20.0.1-ით ან dig @10.20.0.1 name-ით, ერთ რამეს ამტკიცებს: რომ თქვენ მიერ დასახელებული სერვერი პასუხობს, როცა მისი მიღწევა შესაძლებელია. ეს მთლიანად გვერდს უვლის არჩევანის ლოგიკას, ამიტომ ვერ გეტყვით, აირჩევდა თუ არა სისტემა ამ სერვერს ამ სახელისთვის. გამოიყენეთ იგი იმის შესამოწმებლად, მისაწვდომია თუ არა მინიჭებული რეზოლვერი, და ნუ გამოიყენებთ პოლიტიკის შესამოწმებლად.
ლოკალური რეზოლვერის გავლით ძიება ნამდვილად იყენებს არჩევანს. resolvectl query name გადის იმავე მარშრუტიზაციის დომენების წესებს და იტყობინება, რომელმა პროტოკოლმა უპასუხა, Windows-ში Resolve-DnsName გადის პოლიტიკის ცხრილსა და კლიენტის ქეშში, ხოლო scutil --dns აჩვენებს თანმიმდევრობას, რომელსაც ძიება მიჰყვებოდა. გაუშვით ორივე სახე და შეინახეთ ისინი თქვენი ჩანაწერების ცალკე სვეტებში. წარმატებული გამოკვეთილი მოთხოვნა წარუმატებელი აპლიკაციის ძიების გვერდით მარშრუტიზაციის ან არჩევანის პრობლემაა და არა რეზოლვერი, რომელიც მუშაობაზე უარს ამბობს.
ქეში თქვენსა და პასუხს შორის დგას. ოპერაციული სისტემა, ლოკალური stub რეზოლვერი, ბრაუზერი და უარყოფითი ქეში ყველა ინახავს შედეგებს, ამიტომ ძიებამ შეიძლება წარმატებით დასრულდეს მოწყობილობიდან ერთი პაკეტის გაუსვლელად. ჩაწერეთ შედეგი სანამ რამეს გაასუფთავებთ: ipconfig /flushdns, resolvectl flush-caches ან sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOS-ში. გამოტოვეთ ქსელის ფართო გადატვირთვა ამ ეტაპზე, რადგან ის ანადგურებს იმ მტკიცებულებებს, რომლებსაც ჯერ კიდევ აგროვებთ.
რას ნიშნავს განსხვავება
შეადარეთ ჩაწერილი ორი სტრიქონი და დაახარისხეთ ცვლილება სანამ ერთ პარამეტრსაც კი შეეხებით.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
ერთი სტრიქონი ყურადღებას იმსახურებს. სახელი, რომელიც იხსნება, მომუშავე სერვისი არ არის, და DNS-ის წარმატება მხოლოდ იმას ამბობს, რომ მისამართი მოიძებნა. ის არაფერს ამბობს გადამისამართებაზე, ცეცხლის კედლის წესებზე ან იმაზე, შეუძლია თუ არა თქვენს ანგარიშს საერთოდ ამ სერვისის გამოყენება, ამიტომ დაასრულეთ რეალური აპლიკაციის გამოცდით და არა იმ დაშვებით, რომ ხარვეზი თავისით გაქრა.
აღადგინეთ საწყისი მდგომარეობა და გადაამოწმეთ
გათიშეთ კლიენტის საკუთარი ელემენტებით და არა პროცესის მოკვლით, შემდეგ ხელახლა წაიკითხეთ იგივე სამი ბრძანება. თითოეული კავშირის სერვერები, პოლიტიკის ჩანაწერები და თქვენი საცდელი სახელის პასუხი უნდა დაუბრუნდეს ადრე ჩაწერილ საწყის მდგომარეობას. სუფთა გათიშვის შემდეგ დარჩენილი პოლიტიკის ჩანაწერი რეალური ხარვეზია, რომლის ჩაწერაც ღირს, და სწორედ ამიტომ გენერირებული რეზოლვერის ფაილის ხელით რედაქტირება ცუდი ჩვევაა: ფაილი ხელახლა იწერება და რედაქტირება ქრება, ან რედაქტირება რჩება და ამაგრებს რეზოლვერს, რომელსაც გზა აღარ აქვს.
გაიარეთ ეს სია ერთხელ, თანმიმდევრობით. გადაწყვიტეთ, რომელ კონსტრუქციას ახორციელებს პროფილი, სანამ რომელიმე შედეგს შეაფასებთ. შეინარჩუნეთ სახელი, ინსტრუმენტი და სუფიქსი ფიქსირებული ორივე გაშვებაში. გამოყავით გამოკვეთილი მოთხოვნა აპლიკაციის ძიებისგან. წაიკითხეთ მოქმედი პოლიტიკა და არა მხოლოდ პასუხი. გაასუფთავეთ ქეშები ბოლოს, შედარების ჩაწერის შემდეგ. გადაამოწმეთ რეალური აპლიკაციით, შემდეგ ერთხელ გადატვირთეთ და დაადასტურეთ, რომ გათიშული მდგომარეობა ჯერ კიდევ სუფთაა.