VPN-ის DNS მუშაობს, მაგრამ .local სახელები მაინც ვერ იხსნება: ვინ ხსნის მათ?

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

ორი გადამწყვეტი, ორი განსხვავებული პასუხი

ტრადიციული glibc ძიება გადის nsswitch.conf-ის hosts: სტრიქონზე და რიგრიგობით ეკითხება ყველა მოდულს, სანამ ერთი უპასუხებს. კლიენტი, რომელიც stub-მსმენელის მეშვეობით systemd-resolved-ს ელაპარაკება, სამაგიეროდ ერთ პროცესს ეკითხება, და ეს პროცესი ყოველი კავშირისთვის განსაზღვრულ პოლიტიკას და საკუთარ განსაკუთრებულ შემთხვევებს იყენებს. აპლიკაციას, რომელიც საკუთარ გადამწყვეტს მოაქვს ან ამის მაკეთებელ ბიბლიოთეკას აკავშირებს, შეუძლია ორივეს გვერდი აუაროს. ასე რომ, ერთ ჰოსტის სახელს ერთ მანქანაზე სამი მფლობელი შეიძლება ჰყავდეს, და მათგან მხოლოდ ერთმა იცის, რა ჰქონდა VPN-ს გულისხმაში.

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

რომელმა ბრძანებამ მართლაც ჰკითხა თქვენს გადამწყვეტს

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

რატომ უგულებელყოფს .local თქვენს unicast ზონას

systemd-resolved-ის ცნობარი ამბობს, რომ .local-ით დამთავრებული მრავალნიშნული სახელები, როცა mDNS ჩართულია, ჩვეულებრივ multicast DNS-ზე გადადის და არა ჩვეულებრივ unicast DNS-ზე. RFC 6762 იმ სახელთა სივრცეს link-local multicast-ისთვის იტოვებს, ამიტომ კორპორატიულ ზონას შეიძლება ჰქონდეს სწორი ჩანაწერი, რომელზეც ამ სუფიქსისთვის არასოდეს იკითხება. გვირაბს შეუძლია გადამწყვეტის სრულყოფილად მარშრუტიზაცია და მაინც წააგოს რბოლა. წარმატებული ping ქეშიდან არაფერს ამბობს ახლახან მომხდარ ძიებაზე.

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

ვიწრო გამონაკლისი იმარჯვებს გლობალურ გადალაგებაზე

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

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

რა უნდა დაამტკიცოთ ცვლილების შემდეგ

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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