mDNS VPN-ის შიგნით: რატომ არ იხსნება .local სახელები

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

შეამოწმეთ რა იხსნება დღეს და რა მხოლოდ გადაწყვეტილად გამოიყურება

ჯერ ორი კითხვა გამოყავით: ჰოსტის სახელის unicast მოთხოვნა რეზოლვერს ეკითხება, ხოლო _ipp._tcp-ის ძებნა ლოკალურ ბმულს. Linux-ზე avahi-browse -a აჩვენებს რას ხედავს multicast DNS, და resolvectl query name.local აჩვენებს რას აკეთებს რეზოლვერის სტეკი ამ სახელთან. macOS-ზე dns-sd -B _ipp._tcp ჩამოთვლის აღმოჩენილ სერვისებს წინასწარი მისამართის გარეშე.

თუ მისამართი პასუხობს და სახელი არა, მარშრუტიზაცია მუშაობს და აღმოჩენა არა. .local სახელს თავად ჰოსტზეც შეიძლება უპასუხოს nss-mdns-ის მეშვეობით avahi-browse-ის დაყენების გარეშე, ამიტომ ამ სახელზე წარმატებული getent ან ping არ არის მტკიცებულება იმისა, რომ აღმოჩენამ გვირაბი გადაკვეთა; ძების შედეგი და რეზოლვერის შედეგი სხვადასხვა მტკიცებულებაა. აპლიკაციები ქეშში ინახავს იმას, რაც აღმოაჩინეს, ამიტომ ხარვეზი ხშირად კავშირიდან საათების შემდეგ ჩნდება და არა კავშირის დროს. დახურეთ და ხელახლა გახსენით აპლიკაცია, შემდეგ შეამოწმეთ ქეშირებული ჩანაწერი სახელს შეიცავს თუ მისამართს, რადგან მისამართი კვლავ მუშაობს აღმოჩენის შეწყვეტიდან დიდი ხნის შემდეგ.

რატომ არ კვეთს მოთხოვნა გვირაბს

Multicast DNS მოთხოვნებს აგზავნის 224.0.0.251-ზე, ლოკალური ქსელის მართვის ბლოკის შიგნით, UDP პორტ 5353-ზე. მარშრუტიზატორები ამ ბლოკის მისამართებს არ გადასცემენ, ამიტომ მოთხოვნა რჩება იმ ბმულზე, სადაც გაიგზავნა. გამგზავნები ასევე აყენებენ IP TTL-ს, ან IPv6 ჰოპის ლიმიტს, 255-ზე, რათა მიმღებმა შეძლოს უკვე მარშრუტიზატორის გავლილი პაკეტის უარყოფა; ასე ამოიცნობს პროტოკოლი ბმულის გარეთ გაყალბებას, და არა ასე რჩება ის ლოკალურად. ლოკალურობა სამიზნე მისამართიდან მოდის და არა ერთი ჰოპის TTL-დან.

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

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

აირჩიეთ სახელების დიზაინი, რომელსაც შეძლებთ შენარჩუნებას

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

აღმოჩენის პროქსი ან mDNS ამრეკლავი შეიძლება ამ ნაპრალის გადაბმა და ეს რეალური დიზაინია თავისი ჰოსტით, თავისი გამოვლენით და თავისი კლიენტის მოთხოვნებით. ის არ ჩნდება იმიტომ, რომ მარშრუტი დაამატეთ. არასდროს გადასცეთ .local მოთხოვნები საჯარო რეზოლვერს: დომენი დაცულია ლოკალური multicast გამოყენებისთვის RFC 6762-ით და მისი გარეთ გაგზავნა ნელ ხარვეზებს და არასაჭირო მონაცემთა გამჟღავნებას იწვევს.

გადაამოწმეთ სერვისი და არა სახელი

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

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