NAT თუ ხიდიანი VM ქსელი: რომელი გადააქვს VPN ტრაფიკს?

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

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

NAT სტუმარს ჰიპერვიზორის კოდის მიღმა იჭერს, სადაც ჰოსტის მარშრუტები მოქმედებს

VirtualBox-ში NAT სტუმარი ზის 10.0.2.0/24-ზე, ვირტუალური კარიბჭე 10.0.2.2-ზე, DNS პროქსი 10.0.2.3-ზე და არ აქვს საკუთარი მარშრუტი ფიზიკურ ქსელში. გამავალ პაკეტებს იღებს NAT ძრავა, გადაწერს მათ ისე, რომ წყარო ჰოსტი იყოს და გადასცემს ჰოსტის IP დასტას. იქიდან სტუმრის ტრაფიკი ჰოსტის ნაკადია და მარშრუტის ძებნა დანიშნულების მიხედვით ხდება: სრული გვირაბის კლიენტი, რომელიც ჰოსტზე აყენებს 0.0.0.0/1 და 128.0.0.0/1-ს, იჭერს მას და არასდროს არ იცის, რომ VM არსებობს. Oracle-ის VirtualBox ქსელების თავი ჩამოთვლის ამ ნაგულისხმევ მნიშვნელობებს, თუ გსურთ მისამართების დადასტურება თქვენს აწყობაში.

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

ხიდი სტუმარს საკუთარ ადგილს აძლევს ფიზიკურ LAN-ზე

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

ეს ორივე მიმართულებით ჭრის. mDNS და SMB-ის დათვალიერება იწყებს მუშაობას, რადგან სტუმარი ხედავს LAN-ის მაუწყებლობის ტრაფიკს და სტუმარი ხდება ხელმისაწვდომი იმავე სეგმენტის სხვა მანქანებიდან ჰოსტის ფაიერვოლის გარეშე. ხიდი ასევე არ არის გზა სტუმრის არსებული გვირაბით გატარებისთვის: VM-ის მიბმა ჰოსტის WireGuard ან OpenVPN ინტერფეისზე არ არის ის, რასაც VirtualBox ან libvirt თქვენთვის გააკეთებს. თუ ხიდიანმა სტუმარმა გვირაბში უნდა გაიაროს, გვირაბი სადღაც იმავე LAN-ზე უნდა დასრულდეს.

ტესტი, რომელიც კამათს ამთავრებს

გაუშვით იგივე შემოწმებები ორივე რეჟიმში და ჩაწერეთ პასუხები.

  • ჰოსტზე curl -s https://ifconfig.me გაძლევთ საჯარო v4 მისამართს.
  • სტუმარში იგივე ბრძანება, დამატებით ip route Linux-ზე ან Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windows-ზე ნაგულისხმევი კარიბჭისთვის.
  • რეზოლვერის იდენტობა: resolvectl status ან cat /etc/resolv.conf სტუმარში, რომ ნახოთ, 10.0.2.3-ს მიუთითებს თუ LAN სერვერს.
  • მისამართების ოჯახი: ip -6 addr show scope global და ერთი v6 მოთხოვნა, რადგან v4 გვირაბი არაფერს ამბობს გლობალურ v6 მისამართზე, რომელიც სტუმარს შეიძლება ჰქონდეს.

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

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

რომელი რეჟიმი შეესაბამება სამუშაოს

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

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

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

ჩავარდნები, რომლებსაც VPN-ს აბრალებენ

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

Wi-Fi-ზე ხიდის გაკეთება მეორე კლასიკაა. წვდომის წერტილები იშვიათად გადასცემენ ჩარჩოებს უცხო წყარო MAC-ით, ამიტომ wlan0-ზე ხიდი ან სრულად ჩავარდება, ან იმუშავებს მანამ, სანამ AP-ზე კლიენტების იზოლაცია დაიწყებს მის ჩამოგდებას. VirtualBox მაინც შემოგთავაზებთ უსადენო ადაპტერს თავის სიაში. თუ ჰოსტი Wi-Fi-ზეა და სტუმარი უნდა იყოს ხიდიანი, დაგეგმეთ მისი შემოწმება და არა ვარაუდი.

MTU მესამეა. ხიდიანი სტუმარი ინარჩუნებს LAN-ის 1500 ბაიტიან MTU-ს და თუ ის საკუთარ WireGuard კლიენტს 1420-ზე უშვებს, დიდი TLS ხელის ჩამორთმევები ჩერდება, მაშინ როცა პატარა მოთხოვნები წარმატდება. NAT-ის ქვეშ ჰოსტის გვირაბის MTU ჰოსტის პრობლემაა, მაგრამ სტუმარი კვლავ 1500-ის სჯერა და UDP don't-fragment ბიტით იგივენაირად ქრება.

ჩაწერეთ რეჟიმი და ხელახლა შეამოწმეთ ყოველი ადაპტერის ცვლილების შემდეგ

ჩაწერეთ რეჟიმი, ჰოსტის ინტერფეისი, რომელსაც ხიდი იყენებს, სტუმრის ნაგულისხმევი კარიბჭე, მისი რეზოლვერი და მისი v4 და v6 გასასვლელი მისამართები. სწორედ ეს ჩანაწერი ხდის შემდეგ ჩავარდნას დაბალფასიანს: როცა ლეპტოპი დოკიდან Wi-Fi-ზე გადადის, ხიდიანი სტუმარი მიჰყვება ხიდს სხვა ფიზიკურ ადაპტერზე და შესაძლოა სხვა ქვექსელში ხელახლა იქირაოს, მაშინ როცა NAT სტუმარი ინარჩუნებს თავის 10.0.2.x მისამართს და ჩუმად მემკვიდრეობით იღებს სხვა ზედა კავშირს.

ბილეთის დახურვამდე დაადასტურეთ თითოეული ეს პუნქტი.

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

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