VirtualBox NAT-ის სტუმრის DNS წყდება, როცა ჰოსტი VPN-ს უერთდება

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

მიადევნეთ ერთ მოძიებას NAT ადაპტერის გავლით

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

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

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

პირველი ბრძანება აჩვენებს ადაპტერის რეჟიმს და მასზე მიმაგრებულ ნებისმიერ NAT ქსელს. Ubuntu სტუმრის შიგნით მეორე ჩამოთვლის კავშირზე დამოკიდებულ DNS პარამეტრებს, ხოლო მესამე ხშირად მხოლოდ ლოკალურ stub მისამართს ამჟღავნებს, რაც ნიშნავს, რომ ნამდვილი upstream სხვაგანაა.

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

პროქსი რეჟიმი და ჰოსტის გადამწყვეტის რეჟიმი სხვადასხვა მექანიზმია

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

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

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

შეცვალეთ ადაპტერი, შემდეგ შეამოწმეთ, რას იღებს სტუმარი

ჯერ ჩაწერეთ VM-ის ქსელისა და DNS პარამეტრები, შემდეგ გამორთეთ მანქანა, რათა მუდმივი კონფიგურაცია შეასწოროთ. work-ubuntu სახელის VM-ისთვის, რომლის პირველი ადაპტერი NAT-ს ატარებს, ადაპტერისეული არჩევანი ჰოსტიდან დგინდება, როცა VM გამორთულია. შემდეგ ხელახლა გაუშვით და შეამოწმეთ შედეგი, ნაცვლად გამოსვლის სტატუსისადმი ნდობისა.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

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

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

გამოსცადეთ VPN-ის მთელი სასიცოცხლო ციკლის განმავლობაში, და არა მხოლოდ ერთხელ

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

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

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