შიდა სახელები VPN-ზე არ იხსნება, საჯარო საიტები კი ნორმალურად იხსნება

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

ორი სიმპტომი, რომლებიც ერთი ხარვეზი არ არის

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

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

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

რომელი ადაპტერის რეზოლვერი იღებს კითხვას

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

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

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

მოკლე სახელს სუფიქსი მარშრუტზე ადრე სჭირდება

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

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

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

ჰკითხე რეზოლვერს პირდაპირ, შემდეგ — სახელს

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

Linux-ზე VPN კლიენტი, რომელიც გადაწერს /etc/resolv.conf მთლიანად ცვლის ლოკალურ რეზოლვერებს. vpnc ავლენს DNSUpdate no ამის შესაჩერებლად, ხოლო systemd-resolved მხოლოდ ჩამოთვლილ დომენებს შეუძლია გვირაბის ბმულზე მიმართოს. ორივე მიდგომა საჯარო სახელებს ლოკალურ რეზოლვერზე ტოვებს და შიდა სახელებს ოფისში აგზავნის.

გაჟონვა წესია და არა მოსანიშნი უჯრა

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

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

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

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