ჰოსტის ტრაფიკის მარშრუტიზაცია VPN-ით VM-ში: ექვსი შემოწმება

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

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

შემოწმება 1: ჰოსტს სჭირდება კავშირი, რომელსაც მისამართს მისცემს

ჰოსტს უნდა ჰქონდეს ინტერფეისი სტუმრის მეორე ადაპტერის იმავე პრეფიქსში. host-only VirtualBox-ში, host-only ან მორგებული VMnet VMware Workstation-ში, შიდა ხიდი ან tap მოწყობილობა QEMU/KVM-ში და Internal კომუტატორი Hyper-V-ში ყველა ვარგისია. სტუმარი 192.168.56.2, ჰოსტი 192.168.56.1, პრეფიქსი 192.168.56.0/24 არის განლაგება, რომელსაც ლაბორატორიებში ვიყენებ.

QEMU-ის მომხმარებლის რეჟიმის ქსელი (-netdev user, ნაგულისხმევი SLIRP backend) და VirtualBox-ის NAT ამ შემოწმებას სრულიად ვერ გადიან. სტუმრის პაკეტები ჰოსტზე პროქსი პროცესამდე აღწევს, ამიტომ ჰოსტი ვერასდროს ხედავს მოწყობილობას, რომელიც სტუმრის მისამართებს ატარებს და არც აქვს რამე, საითაც მარშრუტს მიმართავს. Hyper-V-ის Default Switch იგივე ამბავია. თუ ჰოსტიდან ping 192.168.56.2 ვერ გაიარა, გაჩერდით: მოგვიანებით დამატებული არც ერთი მარშრუტი ამას არ გამოასწორებს.

შემოწმება 2: სტუმარი გადასცემს და თარგმნის

ჰოსტიდან მომავალი პაკეტები მოდიან host-only წყაროს მისამართით და შიდა დანიშნულებით, ამიტომ სტუმარმა უნდა გადასცეს ისინი და შემდეგ დამალოს საკუთარი გვირაბის მისამართის უკან. Linux სტუმარზე ეს ნიშნავს გადაგზავნას, FORWARD accept წყვილს და source NAT-ს გვირაბისკენ:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE წესი ის ნაწილია, რომელსაც ხალხი გამოტოვებს. კორპორატიულმა როუტერებმა იშვიათად იციან, რომ 192.168.56.0/24 არსებობს; წესით, შიდა სერვერები ხედავენ სტუმრის გვირაბის მისამართს და პასუხობენ მას, და პასუხი უკან სტუმრამდე გზას პოულობს.

Windows სტუმარი უფრო მოუქნელია. IPEnableRouter=1 SYSTEM\CurrentControlSet\Services\Tcpip\Parameters-ის ქვეშ რთავს გადაგზავნას თარგმანის გარეშე, ამიტომ ის მუშაობს მხოლოდ იქ, სადაც კორპორატიული მარშრუტიზაცია უკვე უკან თქვენს host-only პრეფიქსზე მიუთითებს. Internet Connection Sharing თარგმნის, მაგრამ საერთო ადაპტერს გადაანომრავს 192.168.137.1-ზე, ამიტომ წაიკითხეთ მისამართი, რომელიც მან რეალურად აიღო, სანამ ჰოსტის მარშრუტებს დაწერთ.

შემოწმება 3: ჰოსტის მარშრუტები ასახელებენ სტუმარს და არა გვირაბს

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

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows-ზე ეკვივალენტია route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. ტესტირებისას გამოტოვეთ -p, რომ ცუდი მარშრუტი გადატვირთვისას მოკვდეს, და დაამატეთ, როცა გზა იმუშავებს. არ წაშალოთ ჰოსტის ნაგულისხმევი მარშრუტი, თუ ჰოსტის ყველა აპლიკაცია გვირაბით არ უნდა გადიოდეს; თუ ნამდვილად სრული გვირაბია მოთხოვნა, დაამატეთ ორი /1 მარშრუტი და შეინარჩუნეთ პირდაპირი მარშრუტი ჰიპერვაიზორის ქსელზე:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

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

შემოწმება 4: DNS მიჰყვება მარშრუტს და არა გვირაბის ნაგულისხმევს

მარშრუტები პაკეტებს მოძრაობენ; ამომხსნელი წყვეტს, რომელი სახელები ქმნიან პაკეტებს. შეზღუდეთ კორპორატიული ამომხსნელი კორპორატიული ზონით, ნაცვლად ჰოსტის ამომხსნელის ჩანაცვლებისა, და მიუთითეთ ის DNS სერვერზე, რომელსაც ახალი მარშრუტი უკვე აღწევს. ჰოსტზე systemd-resolved-ით:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows-ზე სახელების ამოხსნის პოლიტიკის ცხრილის ჩანაწერი იგივეს აკეთებს: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. თუ სტუმარი საკუთარ ამომხსნელს host-only მისამართზე ამუშავებს, გამოიყენეთ ის მისამართი, მაგრამ მხოლოდ მას შემდეგ, რაც დაადასტურებთ, რომ ის 192.168.56.2-ზე პასუხობს და არა loopback-ზე.

შემდეგ შეამოწმეთ MTU, სანამ DNS-ს ნელი გვერდებისთვის დასდებთ ბრალს. გვირაბის ინტერფეისი პატარაა ჰოსტის 1500-ბაიტიან ინტერფეისზე, ამიტომ DF ბიტით სავსე ზომის სეგმენტების გამგზავნი ჰოსტი მათ სტუმრის შიგნით სადღაც კარგავს. კლასიკური სიმპტომია მომუშავე ping და შიდა ვებ აპლიკაცია, რომელიც TLS ხელის ჩამორთმევის შემდეგ ჩერდება. შეკუმშეთ MSS სტუმრის გადაგზავნის გზაზე:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

შემოწმება 5: გადაამოწმეთ ორივე ბოლოდან

ჰოსტიდან traceroute ან tracert შიდა მისამართამდე პირველ hop-ად უნდა აჩვენოს 192.168.56.2 და არა ფიზიკური კარიბჭე. სტუმარში დააკვირდით, როგორ გადის იგივე მცდელობა: tcpdump -ni any host 10.20.30.40 აჩვენებს გადაცემულ მოთხოვნას host-only მხარეს და თარგმნილს გვირაბზე. მოთხოვნა, რომელიც გადის, ბრუნდება და მაინც ჩუმად ტოვებს ჰოსტს, უკანა გზაზე მიუთითებს.

ორი მარცხი ხსნის ამის უმეტეს ნაწილს. ან სტუმრის გვირაბს არ აქვს უკანა მარშრუტი host-only პრეფიქსისთვის, რადგან NAT წესი აკლია, ან ჰოსტის მარშრუტი მიუთითებს მისამართზე, რომელიც სტუმარს გადატვირთვის შემდეგ აღარ აქვს. ხელახლა წაიკითხეთ მისამართები ip -br addr-ით და ip route get-ით, წინა სესიის ჩანაწერების ნდობის ნაცვლად.

შემოწმება 6: გახადეთ ის გამძლე გადატვირთვისა და ჰიპერვაიზორის განახლების მიმართ

შეინახეთ ორივე ნახევარი: netplan ან NetworkManager მარშრუტის კონფიგურაცია ჰოსტზე, route add ... -p Windows-ზე, და net.ipv4.ip_forward=1 /etc/sysctl.d/-ში, პლუს firewall-ის წესების ნაკრები, რომელიც სტუმარში ხელახლა იტვირთება. გააკეთეთ სტუმრის snapshot, როგორც კი კონფიგურაცია დადასტურდება, სანამ კორპორატიული კლიენტის შემდეგი განახლება მოვა.

host-only ქსელები გადანომრდება, როცა ჰიპერვაიზორი თავის ადაპტერებს ხელახლა ქმნის, რაც ჩუმად ბათილებს 192.168.56.0/24-ზე აგებულ ყოველ მარშრუტსა და NAT წესს. განახლების შემდეგ გაიმეორეთ პირველი სამი შემოწმება თანმიმდევრობით; ეს ერთი წუთი გრძელდება და იჭერს იმ შემთხვევას, როცა ჰოსტს ჯერ კიდევ აქვს თავისი მარშრუტი, სტუმარი კი ახალ ქვექსელზე გადავიდა.

IPv6-ს საკუთარი გავლა სჭირდება. ip6tables წესები, AAAA ჩანაწერები და ჰოსტის მარშრუტების მეორე ოჯახი IPv4-ის კონფიგურაციას არ მიჰყვება, და IPv6-ით ხელმისაწვდომი კორპორატიული სერვისი მუდამ დაზიანებულად გამოიყურება, სანამ IPv4 მუშაობს.

გავიდა თუ არა, თანმიმდევრობით: ჰოსტს შეუძლია სტუმრის host-only მისამართის პინგი; სტუმარი გადასცემს და აკეთებს MASQUERADE-ს გვირაბისკენ; ip route get აბრუნებს სტუმარს როგორც კარიბჭეს შიდა პრეფიქსისთვის; კორპორატიული სახელები იხსნება შეზღუდული ამომხსნელით; traceroute პირველად სტუმარს აჩვენებს; და იგივე ექვსი პასუხი გადატვირთვას გადაურჩება.