LAN-ის ჰოსტის სახელი VPN-ზე არ მუშაობს: სუფიქსი, mDNS თუ ზონა?

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

დაიწყეთ იმის დადგენით, რომელ მექანიზმზეა დამოკიდებული სახელი.

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

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

.local-ით დამთავრებული სახელი ჩვეულებრივ იხსნება multicast DNS-ით ლოკალურ ბმულზე, როგორც RFC 6762 აღწერს. Multicast არ გადაკვეთს მარშრუტიზებულ გვირაბს, თუ რაღაც განზრახ არ ხიდავს ან არ პროქსირებს მას, ამიტომ სახელი წყვეტს ამოხსნას იმ მომენტში, როცა სეგმენტს ტოვებთ.

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

წაიკითხეთ გადამწყვეტი მარშრუტის შეცვლამდე

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

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

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

მიიტანეთ სწორი სახელი კლიენტთან

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

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

შეინარჩუნეთ სერთიფიკატის იდენტურობა

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

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