Hyper-V-ის სტუმარი კარგავს DNS-ს, როცა ჰოსტის VPN უკავშირდება

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

რა შეუძლია სტუმარს ჯერ კიდევ დაინახოს

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

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

რომელ გასასვლელს იყენებს სტუმარი

Hyper-V ამას ორი ბრძანებით პასუხობს: Get-VMSwitch ჩამოთვლის გადამრთველებს, და Get-VMNetworkAdapter -VMName TestVM აჩვენებს იმას, რომელზეც სტუმარია მიერთებული. Default Switch არის Windows-ის მიერ მართული NAT ქსელი; გარე გადამრთველი ტრაფიკს ფიზიკურ ადაპტერს გადასცემს; შიდა გადამრთველი არაფერს ატარებს, სანამ ვინმე NAT-ს ან მარშრუტიზატორს დაამატებს. VirtualBox იგივე სამ იდეას NAT, NAT Network და bridged სახით წარმოადგენს.

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

ჰოსტის გვირაბის გაზიარება Hyper-V-თან

თუ სტუმარს გვირაბი სჭირდება და საკუთარ კლიენტს ვერ უშვებს, Windows-ს შეუძლია VPN კავშირის გაზიარება. გახსენით VPN ადაპტერის თვისებები, გადადით გაზიარებაზე და მისცით სხვა ქსელის მომხმარებლებს მისი მეშვეობით დაკავშირების უფლება. მიმართეთ სახლის ქსელის კავშირი Hyper-V ადაპტერზე, vEthernet (Default Switch), შემდეგ შეამოწმეთ ახალი მოთხოვნა სტუმრის შიგნიდან.

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

Hyper-V ფუნქციის ხელახალი დაყენება რამდენიმე ჯიუტ სტუმარს გადაარჩინა. ეს ბოლოსთვის შეინახეთ და ჯერ სტუმრის მდგომარეობა ჩაწერეთ.

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

ჰოსტის VPN, რომელიც სტუმრის NAT ქვექსელს ფილტრავს, პირდაპირ წვდომას ამტვრევს და არა სახელების გარჩევას. VM მუშაობს, თუმცა ssh [email protected] იკიდება, მაშინ როცა ჰიპერვიზორის თარგმნა ჯერ კიდევ მუშაობს. გადაამისამართეთ სამუშაოსთვის საჭირო პორტები და ნაცვლად ამისა ჰოსტის მისამართს დაუკავშირდით. ქვემოთ მოცემული Vagrantfile სტრიქონები მოიცავს SSH-ს და ერთ HTTPS სერვისს; ორივე გადატვირთვამდე ემატება.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

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

შემოწმება, რომელიც გეტყვით, რომ იმუშავა

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

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

ჩაწერეთ ყოველი გადამრთველის ან დრაივერის ცვლილება მისი გაუქმების ნაბიჯით. Microsoft-ის Hyper-V NAT სახელმძღვანელო განმარტავს, რა არის სინამდვილეში Default Switch, და ღირს მისი წაკითხვა, სანამ შექმნით მეორე NAT ქსელს, რომელიც მას ეწინააღმდეგება.