VirtualBox NAT თუ ხიდი: სად მთავრდება VM-ის VPN

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

ვინ ასრულებს სინამდვილეში დაშიფრულ სესიას

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

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

NAT სტუმარს გადაწერს, სანამ ის ჰოსტს დაემსგავსება

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

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

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

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

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

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

რატომ არ შეიძლება სტუმარი იყოს ჰოსტის კარიბჭე

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

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

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

ამომხსნელები და მარშრუტები საზღვარს არ გადაკვეთენ

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

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

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