VMware-ის ხიდური სტუმარი OpenVPN-ის შემდეგ ქსელი დაკარგა

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

სტუმარი არ შეიცვალა, ხიდი შეიცვალა

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

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

დაამაგრეთ ხიდი ან დაამარშრუტეთ სტუმარი

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

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

პირველი ტოტისთვის გახსენით Virtual Network Editor ჰოსტზე, აირჩიეთ VMnet0 და ავტომატური შეცვალეთ ფიზიკური ადაპტერით. თუ რამდენიმე ადაპტერია, გამოიყენეთ ავტომატური პარამეტრების სია და მოხსენით ნიშანი ყველაფერზე, რაც არასდროს უნდა ატარებდეს სტუმრის ტრაფიკს: OpenVPN TAP ან Wintun მოწყობილობა, ასევე Hyper-V, WSL, Docker და loopback ადაპტერები. ნოუთბუქზე ნიშნით დატოვეთ როგორც სადენიანი, ისე უსადენო ფიზიკური ადაპტერი, თორემ სტუმარი ხიდს დაკარგავს შემდეგ ჯერზე, როცა მომხმარებელი დოკზე შეაერთებს.

სამი პირობა, რომელიც განსაზღვრავს არჩევანს

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

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

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

წაიკითხეთ შედეგი სტუმრის შიგნიდან

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

ipconfig /all
ip addr
ip route

წაიკითხეთ ორი ველი ამ გამოსავალში და დანარჩენი ჯერ არ გაითვალისწინოთ. კარიბჭე LAN-ის მარშრუტიზატორი უნდა იყოს, ხოლო ადაპტერის აღწერაში VMware Ethernet მოწყობილობა უნდა იყოს დასახელებული და არა გვირაბი. 169.254.0.0/16-ში თვითმინიჭებული მისამართი ნიშნავს, რომ არცერთ DHCP სერვერს არ უპასუხია, და სწორედ ასე გამოიყურება გვირაბურ ადაპტერზე ხიდი სტუმრის მხრიდან.

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