როგორ შევამოწმოთ DNS რეზოლვერები, რომლებსაც თქვენი Mac VPN-ში იყენებს

scutil --dns ბეჭდავს რეზოლვერის იმ კონფიგურაციას, რომელსაც macOS ნამდვილად მიმართავს, და არა იმ ერთ DNS სერვერს, რომელიც თქვენ პარამეტრების პანელში შეიყვანეთ. გამოტანილი ტექსტი უფრო გრძელია, ვიდრე უმეტესობა მოელის, რადგან სისტემა ცალკეულ რეზოლვერის ბლოკებს ინახავს ნაგულისხმევი გზისთვის, შემოსაზღვრული ინტერფეისებისთვის და დომენის სპეციფიკური გადამისამართებისთვის. გამოტანის თავში მდგომი ბლოკი სულაც არ არის ის, რომელიც კითხვას პასუხობს. თუ კერძო სახელი ოფისში იხსნება და ფუჭდება იმ მომენტში, როცა VPN ადის, შეუსაბამობა შეხამების წესებსა და მარშრუტებშია, არა სერვერის მისამართში. ჯერ წაიკითხეთ თანმიმდევრობა, შემდეგ დაამტკიცეთ პასუხი რეალური ძიებით.

წაიკითხეთ ბლოკების თანმიმდევრობა მისამართებამდე

ყოველი ჩანაწერი იხსნება resolver #N-ით და ჩამოთვლის nameserver[0]-ს, ზოგჯერ if_index-ს, ხაზს flags, reach-ს და, როცა ბლოკი ჩვეულებრივი ნაგულისხმევი არ არის, domain-სა და search domain-ის სიას. დომენის გარეშე 1-ლი რეზოლვერი არის ნაგულისხმევი, რომელიც საჯარო სახელებს ემსახურება. ყველაფერი, რაც თავის დროშებში Scoped-ს ატარებს, მიბმულია იმ ინტერფეისზე, რომელსაც if_index ასახელებს, და Supplemental-ით მონიშნული ყველაფერი მხოლოდ მის ქვეშ ჩამოთვლილ დომენებზე ვრცელდება.

არჩევა სუფიქსის შეხამებაა. intranet.corp.example-ის მსგავსი სახელისთვის macOS უპირატესობას ანიჭებს იმ რეზოლვერს, რომლის domain ჩანაწერი ყველაზე გრძელი დამთხვეული სუფიქსია, ამიტომ domain : corp.example-ის მქონე ბლოკი ნაგულისხმევს სძლევს მაშინაც, როცა გამოტანაში ძალიან ქვემოთ დგას. order წყვეტს თანაბარობას ერთი და იმავე სიგრძის დომენებს შორის. პირველ შეხედვას იშვიათად სჭირდება მეტი: მთელი გამოტანა, როცა ერთი ბლოკის დასაწყისიდან ბოლომდე წაკითხვა გსურთ, საწყისი ხაზები ბლოკების თანმიმდევრობის შესასწავლად და გაფილტრული გავლა, რომელიც ბლოკების სათაურებს ველების ხაზების გვერდით ბეჭდავს. შემოსაზღვრული ბლოკები საკუთარი სათაურის ქვეშ ჩნდება და ზემოთ მდებარე სიის გაგრძელებას ჰგავს, ამიტომ გამოტანის ციტირებისას ყოველთვის თვალწინ გქონდეთ სათაური.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

დააკავშირეთ if_index გვირაბის ინტერფეისთან

ინდექსი სასარგებლოა მხოლოდ მაშინ, როცა მის უკან მდგარ ინტერფეისს დაასახელებთ. scutil --nwi ჩამოთვლის იმ ქსელურ ინფორმაციას, რომელსაც სისტემა ინახავს, მათ შორის ძირითად ინტერფეისსა და ხელმისაწვდომობას, ხოლო ifconfig -l გაძლევთ სახელებს, სადაც utun0-იდან utun9-მდე ის გვირაბის კანდიდატებია, რომლებსაც კლიენტი ჩვეულებრივ ქმნის. Apple scutil --dns-ს იყენებს საკუთარი შემოწმების მაგალითად განლაგების სახელმძღვანელოში, და ადოკუმენტირებს, როგორ შეუძლია Network Extension-ს შერჩეული დომენები შერჩეულ რეზოლვერებზე გადაამისამართოს, რაც სწორედ ის მექანიზმია, რომელსაც ის შემოსაზღვრული ბლოკები ამჟღავნებს.

კითხვას წყვეტს ის შემოწმება, ზის თუ არა რეზოლვერი იმ გზაზე, რომელიც გვირაბმა დააყენა:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

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

ჰკითხეთ სისტემის რეზოლვერს, შემდეგ სერვერს

სამი ხელსაწყო სამ სხვადასხვა კითხვას პასუხობს და მათი არევა ამ დარგში არასწორი დასკვნების უმეტესობას წარმოშობს. dscacheutil -q host -a name გადის იმავე სისტემურ რეზოლვერზე, რომელსაც ჩვეულებრივი აპლიკაციები იყენებენ, ამიტომ შემოსაზღვრული და დამატებითი ბლოკები მოქმედებს. სერვერის არგუმენტის გარეშე dig კითხულობს /etc/resolv.conf-ს, რომელიც macOS-ზე შემოსაზღვრული გადაწყვეტის სიმართლის წყარო არ არის, და სრულად გამოტოვებს დომენების ცალკეულ წესებს. dig @address ზუსტად ერთ სერვერს აღწევს და არჩევანზე არაფერს ამბობს.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

როცა პირველი ბრძანება პასუხობს და მეორე NXDOMAIN-ს აბრუნებს, თქვენ იპოვეთ სასურველი გაყოფა და არაფერია გატეხილი. როცა პირველი დროში იწურება, სანამ dig @10.20.0.53 პასუხობს, რეზოლვერი მუშაობს, მაგრამ მიუწვდომელია გვირაბის მიერ არჩეულ გზაზე, ამიტომ შემდეგი ნაბიჯი route -n get-ია და არა DNS პარამეტრების შეცვლა. კერძო სახელები მოშორებით დაიჭირეთ ყველაფრისგან, რასაც ბილეთში ან საერთო ჩანაწერში აკრავთ.

რასაც გამოტანა ვერ გაჩვენებთ

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

მოძველებული პასუხები ყველაზე იაფია გამოსარიცხავი და ყველაზე ხშირად გამოტოვებული:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

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

მოკლე სახელმძღვანელო წინ და შემდეგ

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

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

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

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

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