ჰოსტის VPN სესიის გაზიარება VMware სტუმართან

გვირაბის ადაპტერი ხიდს არ უერთდება, და Windows 10 ქვექსელებს შორის მარშრუტიზაციას არ აკეთებს. NAT-იანი host-only სეგმენტი ატარებს სტუმარს.

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

ორი მიზეზი, რატომ ვერ იმუშავებს ხიდი

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

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

შექმენით სეგმენტი, რომელსაც ჰოსტი ფლობს

ვირტუალური ქსელის რედაქტორში დაამატეთ host-only ქსელი, მაგალითად VMnet3, იმ პრეფიქსზე, რომელსაც სხვაგან არ მარშრუტიზაციას უკეთებთ, მაგალითად 172.28.90.0/24. ჰოსტი იღებს 172.28.90.1-ს ამ ადაპტერზე და სტუმარი იმავე კომუტატორს უერთდება. გამორთეთ ჰიპერვიზორის DHCP ამ სეგმენტზე, რომ ერთი მისამართის სერვისი ფლობდეს მას.

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

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

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

თარგმნეთ სტუმრის პრეფიქსი

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

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

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

შეამოწმეთ პირველი ნახტომი, შემდეგ ფასი

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

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

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

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

დაკავშირებული სტატიები