dnsmasq-ში თქვენი VPN დომენი ზონის გადატანა არ არის

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

რაც კლიენტმა მიიღო, არ არის ის, რაც კარიბჭემ შესთავაზა

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

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

ორი სახის დომენის ჩანაწერი

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

კერძო სახელთა სივრცისთვის ჩვეულებრივ გსურთ მხოლოდ მარშრუტის ფორმა. ის კორპორატიულ სუფიქსს კორპორატიული resolver-ისკენ მიმართავს და დანარჩენს მშვიდად ტოვებს.

localhost resolv.conf-ში შეცდომა არ არის

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

ამ ჩანაწერის საჯარო resolver-ით ჩანაცვლება კლასიკური არასწორი შესწორებაა. ის აღადგენს საჯარო სახელთა გარჩევას და იმავე რედაქტირებაში ყრის პირობით პოლიტიკას.

არ აურიოთ backend-ები

მართული dnsmasq ეგზემპლარი და სისტემური resolver სხვადასხვა პროგრამებია განსხვავებული კონფიგურაციითა და განსხვავებული მდგომარეობის ხედებით. ერთის მდგომარეობის ბრძანება მეორეზე არაფერ სასარგებლოს არ ამბობს.

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

შეამოწმეთ სახელთა სივრცე და არა მხოლოდ პასუხი

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

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