VirtualBox-ის სტუმრის DNS ფუჭდება მას შემდეგ, რაც ჰოსტი VPN-ს უერთდება

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

დაადასტურეთ, რომელი ადაპტერის რეჟიმს ამუშავებთ

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

ერთ ვირტუალურ მანქანას შეუძლია ატაროს ორი ადაპტერი სხვადასხვა რეჟიმში, და დაზარალებული ყოველთვის პირველი არ არის.

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

მიჰყევით ერთ სახელს სტუმრის გამხსნელში

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

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

resolvectl status
resolvectl query app.internal.example

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

სცადეთ ჰოსტის გამხსნელის რეჟიმი ამ ადაპტერზე

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

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

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

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

გაიმეორეთ იგივე ტესტები VPN-ის ხელახალი მიერთების დროს

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

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

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