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

რად იშლება DNS ხაზი

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

DNS = 10.24.8.53, lab.internal.example

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

Apple-ის ორი ველი, ორი განსხვავებული საქმე

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

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

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

რატომ აღწევს ყოველი სახელი მაინც გვირაბის ამომხსნელს

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

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

რა დასჭირდებოდა სინამდვილეში გაყოფილ DNS-ს

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

მართულ Apple მოწყობილობებზე ეს ჩვეულებრივ მიეწოდება კონფიგურაციის პროფილით, რომელიც ატარებს დომენისთვის სპეციფიკურ DNS პარამეტრებს. ეს განსხვავებული მექანიზმია WireGuard-ის კონფიგურაციის ფაილისგან და ორივე ერთად შეიძლება არსებობდეს მხოლოდ მაშინ, თუ კლიენტი პროფილს პატივს სცემს. შეამოწმეთ, რას უწოდებს თქვენი კლიენტი ამ ველს სინამდვილეში, სანამ ჩათვლით, რომ ორი პროდუქტი ერთნაირად იქცევა. Mac-ზე wg-quick სკრიპტი და iPhone-ზე WireGuard აპლიკაცია მსგავს ხაზებს კითხულობს და მათ სხვადასხვა ფენის გავლით აყენებს.

წაიკითხეთ დაყენებული პარამეტრები და არა კონფიგურაცია

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

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

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

დაკავშირებული სტატიები