თქვენი VPN სამ DNS სერვერს აგზავნის: რომელი პასუხობს?
დამატებითი ჩანაწერები შეიძლება იყოს სარეზერვო ვარიანტი, დომენის მიხედვით მარშრუტი ან ფიზიკური ბმის ნაშთი. თითოეული დაუკავშირეთ თავის სფეროს, სანამ სიას გაჟონვას უწოდებთ.
დაკავშირების შემდეგ გახსენით პარამეტრების გვერდი და სამი DNS მისამართი იქნება ჩამოთვლილი; აუდიტის კითხვაა, რომელი მათგანმა მოემსახურა თქვენს ბოლო მოთხოვნას. მხოლოდ რიცხვი არაფერს პასუხობს, რადგან კლიენტის გაგზავნა, ფიზიკური ინტერფეისი და დომენის მიხედვით პოლიტიკა ყველა ერთსა და იმავე ხედში წერენ. ამ ჩანაწერებს სხვადასხვა სფერო აქვთ და პასუხისმგებელს სფერო წყვეტს, არა პოზიცია. დაიწყეთ წყაროების გამოყოფით, შემდეგ შეამოწმეთ ის, რომელსაც ეკუთვნის თქვენთვის მნიშვნელოვანი სახელი.
რატომ არის სია თქვენს პროფილზე გრძელი
VPN კლიენტი გამხსნელის მისამართებს აგზავნის გვირაბის ბმისთვის, ხოლო ოპერაციული სისტემა მათ ფიზიკური ინტერფეისის უკვე არსებული მისამართების გვერდით ინახავს. მარშრუტიზატორი, კორპორატიული DHCP იჯარა, მეორე VPN და დომენის მიხედვით პოლიტიკა თითოეული საკუთარ ჩანაწერს ამატებს. ამიტომ გვერდზე სამი მისამართი შეიძლება ნიშნავდეს სამ სფეროს და არა სამ კანდიდატს ერთი სამუშაოსთვის. რიცხვის გაჟონვის მტკიცებულებად წაკითხვა ამ აუდიტის პირველი შეცდომაა.
ერთი ინტერფეისის შიგნით კლიენტი ნამდვილად რიგრიგობით ცდის თავის სერვერებს, ამიტომ დალაგებული სია უაზრო არ არის. რაც რიგი არ არის, არის გაერთიანებული ხედი, სადაც პროფილის, ფიზიკური ბმისა და დომენის წესების ჩანაწერები ერთი რანჟირების გარეშე გვერდიგვერდ დგას. სწორედ ეს განსხვავება წყვეტს, რას შეამოწმებთ: რიგი ხსნის ქცევას ერთი სფეროს შიგნით, ხოლო სფერო — ყველაფერ დანარჩენს.
დაშიფრული DNS სურათს აპლიკაციის შიგნიდან ამტვრევს. ბრაუზერი ან ჩატის კლიენტი საკუთარი DNS-over-HTTPS გამხსნელით მოთხოვნებს ოპერაციული სისტემის სიის სრულად გვერდის ავლით აგზავნის, ამიტომ პარამეტრების გვერდის მისამართები აღწერს ტრაფიკს, რომელიც აპლიკაციას არასოდეს შეუქმნია. შეამოწმეთ აპლიკაციის საკუთარი გამხსნელის პარამეტრი, სანამ პროფილს დაადანაშაულებთ არასწორად მიღებულ სახელში.
რას ამბობს სამი შემოწმებიდან თითოეული
ყოველი წყარო თავის კვალს სხვა ადგილას ტოვებს და არც ერთი ბრძანება არ აჩვენებს ყველას. ეს არის ის რუკა, რომლის შენახვაც პარამეტრების გვერდის გვერდით ღირს:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved-ის გამოყენებულ სისტემაზე resolvectl status ავტორიტეტულია, რადგან ის DNS-ს თითოეული ბმისთვის მარშრუტიზაციის დომენებთან ერთად იუწყება. macOS პასუხობს scutil --dns-ის მეშვეობით, რომელიც სფეროს მქონე გამხსნელებს ცდის რიგით ჩამოთვლის. Windows ორ ნახევრად ყოფს: Get-DnsClientServerAddress ინტერფეისის მიხედვით სერვერებისთვის და Get-DnsClientNrptPolicy სუფიქსის წესებისთვის. გაუშვით ის ბრძანება, რომელიც რეალურად გამოყენებულ გამხსნელს ეკუთვნის, რადგან კონტეინერის გაშვების გარემოსა და სამუშაო მაგიდის გამხსნელის მქონე მანქანაში ერთზე მეტი შეიძლება იყოს დაყენებული.
სარეზერვო გამხსნელი, რომელიც თქვენს ზონას ვერ პასუხობს
მეორე ჩანაწერი ჩვეულებრივ ხელმისაწვდომობისთვის არსებობს და ხელმისაწვდომობა მხოლოდ მაშინ მუშაობს, როცა სარეზერვო სახელებს იცის. ჰკითხეთ საჯარო გამხსნელს შიდა ჰოსტის სახელი და ის NXDOMAIN-ს დააბრუნებს, ან ველური ბარათის პასუხს საძიებო დომენიდან, რომელსაც თქვენთან არაფერი აქვს საერთო. შემდეგ არავის მიერ შეუმოწმებელი სარეზერვო გადასვლა წარმოქმნის შეწყვეტას ზუსტად იმ მომენტში, როცა ის საჭიროა.
Split DNS ამის თავიდან ასაცილებლად არსებობს: კომპანიის სუფიქსები მიდის ზონის მფლობელ გამხსნელთან, ხოლო საჯარო სახელები ნაგულისხმევ გზაზე რჩება. დიზაინი მყარია და ის სუფიქსების სიის სისრულეზეა დამოკიდებული. Microsoft ადოკუმენტირებს თითოეული სუფიქსის გამხსნელის პოლიტიკას, რომელიც ამას Windows-ზე მართავს, და იგივე იდეა ჩნდება მარშრუტიზაციის დომენებად systemd-resolved-ში და სფეროს მქონე გამხსნელებად macOS-ში.
შეადარეთ ის ზონები, რომლებზეც სარეზერვო პასუხის გაცემა შეიძლება, პოლიტიკაში არსებულ სუფიქსებს. ეს შედარება ხარვეზს პოულობს მანამ, სანამ მომხმარებელი შეატყობინებს, რომ ერთი შიდა საიტი გვირაბის შეცვლის შემდეგ გადაწყვეტას შეწყვიტა.
იკითხეთ პოლიტიკის შიგნით, და არა მის გარშემო
იკითხეთ ოპერაციული სისტემის გამხსნელის მეშვეობით, რადგან სერვერზე პირდაპირი მოთხოვნა პოლიტიკას გვერდს უვლის და იუწყება მხოლოდ იმას, რასაც ეს სერვერი იტყოდა. ორ პასუხს შორის არსებული უფსკრული მთელი აზრია:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53თუ სისტემის მოთხოვნა კერძო მისამართს აბრუნებს, ხოლო პირდაპირი მოთხოვნა NXDOMAIN-ს, პოლიტიკა მუშაობს და სუსტი წერტილი სარეზერვოა. თუ ორივე ერთსა და იმავე საჯარო პასუხს აბრუნებს, სახელი თქვენ მიერ განზრახული სფეროს გარეთ წყდება და სუფიქსების სიაა საძებარი ადგილი. შეინახეთ ორივე გამოსავალი, რადგან გამხსნელზე კამათი ორი სტრიქონით უფრო სწრაფად წყდება, ვიდრე პარამეტრების გვერდის ეკრანის ანაბეჭდით.
შემდეგ ივარჯიშეთ წარუმატებლობის გზაზე, რადგან არავის მიერ გამოუცდელი სარეზერვო მხოლოდ ვარაუდია. ერთი მოთხოვნისთვის სასურველი გამხსნელი შავ ხვრელად აქციეთ და ნახეთ, რომელი მისამართი ბრუნდება:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32წაშალეთ ეს მარშრუტი მოთხოვნის დასრულებისთანავე, თორემ შემდეგი ადამიანი გამოცანას მიიღებს მემკვიდრეობით. თუ შიდა სახელები იმ ფანჯარაში ჯერ კიდევ წყდება, მათზე განზრახული სფეროს გარეთ რაღაცამ უპასუხა. თუ ნაცვლად დრო ამოიწურა, სარეზერვო არ არსებობს ან სწორად შემოსაზღვრულია, და გამხსნელის საკუთარი ჟურნალი გეტყვით, რომელი იყო ორიდან.
გადაწყვიტეთ: შეინარჩუნოთ, შემოსაზღვროთ თუ წაშალოთ
შეინარჩუნეთ მეორე გამხსნელი, როცა ის პასუხობს თქვენთვის საჭირო სახელთა სივრცეს და პროფილის ქვეშ ხელმისაწვდომი რჩება. შემოსაზღვრეთ ის სფეროთი, როცა მან მხოლოდ ერთი სუფიქსი უნდა დაინახოს და სხვა არაფერი, და წაშალეთ, როცა მას არც სფერო აქვს და არც დოკუმენტირებული მიზანი. სამუშაოს გარეშე ჩანაწერი მომავალი გაჟონვაა სარგებლის გარეშე, და მომწოდებლის ნაგულისხმევი მნიშვნელობა მიზანი არ არის.
ჩაწერეთ შედეგი ოთხ სვეტად: სუფიქსი, გამხსნელი, ინტერფეისი და მფლობელი. ეს სტრიქონი შემდეგ აუდიტის კითხვას უფრო სწრაფად პასუხობს, ვიდრე ნებისმიერი ეკრანის ანაბეჭდი, და გადაურჩება კლიენტის განახლებას, რომელიც სიას ჩუმად გადააწყობს.