macOS-ის resolver ფაილი ლოკალური დომენისთვის VPN-ის გვერდით
ერთ ვიწრო resolver ფაილს შეუძლია ერთი ლოკალური დომენი საკუთარ DNS სერვერზე გაგზავნოს Mac-ზე, სამუშაო VPN-ის resolver-ის შეცვლისა და რაიმე მარშრუტის შექმნის გარეშე.
თქვენი სამუშაო VPN კომპანიის სახელებს იდეალურად წყვეტს, ხოლო სახლის პრინტერი სახელით მაინც მიუწვდომელი რჩება, და ჩვეულებრივი გამოსავალი, რომელსაც ხალხი მიმართავს, მთელი Mac-ის სახლის როუტერზე მითითებაა. ეს გაცილებით დიდი ცვლილებაა, ვიდრე პრობლემა მოითხოვს. macOS-ს შეუძლია ერთი DNS სუფიქსი საკუთარ სერვერზე გაგზავნოს პატარა resolver ფაილის მეშვეობით და ყველა სხვა ძიება ზუსტად იქ დატოვოს, სადაც იყო.
ნებართვის საზღვარი პირველ ადგილზეა: ეს ეხება დომენს, რომელსაც თქვენ მართავთ ან რომლის კონფიგურაციის უფლებაც გაქვთ. ეს არ არის ორგანიზაციის დაწესებული DNS პოლიტიკის ან ლოკალური ქსელის შეზღუდვების გვერდის ავლის გზა.
ერთი ფაილი ვიწრო დავალებით
დავუშვათ, ლოკალური ზონაა lab.example.org და მისი სერვერი პასუხობს 192.168.55.1-ზე. Mac-ზე, სადაც ცვლილების გაკეთება ნებადართულია, ადმინისტრატორი ქმნის ჩვეულებრივ ტექსტურ ფაილს, რომლის სახელიც თავად დომენია, /etc/resolver/lab.example.org, და რომელიც შეიცავს ერთ ხაზს nameserver 192.168.55.1. საქაღალდე შეიძლება არ არსებობდეს ახალ სისტემაზე, ამიტომ შექმენით ის ადმინისტრატორის უფლებებით და ჩაწერამდე შეხედეთ, ხომ არ გააჩნია მართვის პროგრამას უკვე ფაილი იქ.
Apple-ის resolver კონფიგურაციის დოკუმენტაცია აღწერს კონვენციას, რომ ფაილის სახელი აწვდის დომენს, როცა ფაილის შიგნით ცალკე დომენის პარამეტრი არ ჩანს. სწორედ ეს დასახელების წესია მთელი ხერხი და ამიტომ ფაილი ზონის სახელზე უნდა დასახელდეს და არა სერვერის.
როგორ ირჩევს macOS resolver-ებს შორის
ერთზე მეტი resolver კლიენტი შეიძლება იყოს აქტიური და ყველაზე კონკრეტული დამთხვეული დომენი იმარჯვებს. ამიტომ lab.example.org-ის resolver-ს განსხვავებული არეალი აქვს ნაგულისხმევ resolver-თან შედარებით და უფრო კონკრეტულ ქვედომენს საკუთარი ფაილით შეუძლია კვლავ უპირატესობა მოიპოვოს. სწორედ ეს აძლევს სამუშაო VPN-ს საშუალებას შეინარჩუნოს საკუთარი სუფიქსი, სანამ თქვენი ლაბორატორიის ზონა სხვაგან მიდის. ამ მოწყობაში არაფერია გლობალური და სწორედ ეს არის დასამახსოვრებელი.
/etc/resolv.conf-ს ხელი არ ახლოთ. macOS თავად წერს ამ ფაილს და მას დომენის სპეციფიკური წყვეტის სრული სურათი არასდროს ჰქონია. კონფიგურაცია შეიძლება მოვიდეს სისტემის კონფიგურაციის მონაცემთა ბაზიდანაც და არა ამ საქაღალდის ფაილებიდან და სწორედ ამიტომ მართვის პროფილს შეუძლია გადაფაროს ის, რაც თქვენ დაწერეთ.
სამი რამ, რასაც ფაილი ვერ უზრუნველყოფს
სერვერი უნდა იყოს მისაწვდომი. თუ VPN ბლოკავს ლოკალურ ქსელს, ან კორპორატიული მარშრუტი იჭერს სერვერის მისამართების დიაპაზონს, სრულიად სწორი სუფიქსის ფაილი მაინც ვერ მიაწვდის მოთხოვნას. ეს ქსელის მფლობელს მიაწოდეთ და ნუ გააფართოებთ ლოკალურ გამონაკლისებს თავად.
ზონა უნდა შეიცავდეს სწორ პასუხს და ამის შემოწმება საუკეთესოდ ხდება სრულად კვალიფიციური სახელით, როგორიცაა printer.lab.example.org. მოკლე სახელმა შეიძლება გამოიწვიოს საძიებო დომენის ქცევა და საბოლოოდ სხვა კითხვა დასვას, ვიდრე გქონდათ გულისხმეული.
დაბოლოს, აპლიკაციამ უნდა შეძლოს პასუხის გამოყენება. პრინტერის სახელის წყვეტა არ იძლევა მის მისამართზე წვდომას და არ ხსნის მის უკან არსებულ სერვისს. დაბრუნებულ მისამართს მაინც სჭირდება დაშვებული მარშრუტი და წვდომის პოლიტიკა, რომელიც დაკავშირებას უშვებს. resolver ფაილი ცვლის იმას, თუ სად იძებნება სახელი; ის არ იტოვებს გზას შედეგისთვის.
შეამოწმეთ არჩევანი და ნუ ჩაანაცვლებთ DNS-ს
შეამოწმეთ, რას იყენებს macOS ახლა რეალურად და მოითხოვეთ სრულად კვალიფიციური სახელი თავად აპლიკაციის შიგნიდან ან ხელსაწყოსგან, რომელიც აპლიკაციების მსგავსად წყვეტს. პირდაპირი მოთხოვნა 192.168.55.1-ზე ამტკიცებს, რომ სერვერი პასუხობს; ის არ ამტკიცებს, რომ macOS არჩია ის სერვერი ჩვეულებრივი ძიებებისთვის. ეს სხვადასხვა ფაქტია და მხოლოდ მეორე აღწერს იმას, რასაც თქვენი ბრაუზერი განიცდის.
თუ სხვა resolver უკვე იჩემებს იმავე სუფიქსს, გაარკვიეთ, ვის ეკუთვნის ის, სანამ პრიორიტეტის მინიშნებებს დაამატებდეთ. დოკუმენტირებული search_order პარამეტრი ალაგებს კლიენტებს, რომლებიც იზიარებენ დომენს; ის არ არის გლობალური უპირატესობის გადამრთველი, რომელიც ზოგად resolver-ს ყოველ მოთხოვნაში ამარჯვებს.
დაადასტურეთ, რომ კომპანიის სახელები კვლავ წყდება VPN-ის ჩართული მდგომარეობით, შემდეგ ჩაინიშნეთ ფაილი და მისი დანიშნულება თქვენს ლოკალურ ჩანაწერებში. როცა მოწყობას გააუქმებთ, წაშალეთ მხოლოდ ის ფაილი და გადაამოწმეთ ორივე სახელთა სივრცე, ნაცვლად იმისა, რომ ქსელის ყველა DNS პარამეტრი გადააყენოთ.