host-only VM ტრაფიკის მარშრუტიზაცია TUN OpenVPN სერვერის მეშვეობით

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

ორი ქსელი, ორი პრეფიქსი

მიეცით გვირაბის აუზს და host-only ქსელს სხვადასხვა პრეფიქსი და არასოდეს გამოიყენოთ ერთი მეორის ნაცვლად. ამ მაგალითში VPN აუზია 10.44.0.0/24, ხოლო host-only ქსელი 192.168.99.0/24; ჰოსტი 192.168.99.1-ზეა, სტუმარი კი 192.168.99.20-ზე. ერთი და იმავე პრეფიქსის მინიჭება როგორც TUN მოწყობილობას, ისე host-only ადაპტერს მათ არ აერთიანებს. ეს ერთ მისამართთა დიაპაზონზე ორ მოთხოვნას ქმნის და მარშრუტიზაციის ცხრილი შემდეგ პასუხობს იმ მოთხოვნის სასარგებლოდ, რომელიც შემთხვევით შემორჩა.

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

ჰოსტი უკვე ფლობს გზას

ნახეთ, რა არსებობს, სანამ რამეს დაამატებთ. ჰოსტს აქვს ინტერფეისი host-only ქსელში და მარშრუტი ამ პრეფიქსისთვის, ორივე შეიქმნა ადაპტერის აწევისას.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

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

გაუშვით მარშრუტი, შემდეგ გაფილტრეთ, რასაც ის აღწევს

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

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

სტუმარს დაბრუნების გზა სჭირდება

სტუმარს, რომელსაც 10.44.0.x-იდან მიმართავენ, პასუხები ჰოსტის host-only მისამართზე უნდა გააგზავნოს, ან ჰოსტმა უნდა თარგმნას წყარო. VirtualBox DHCP-დან მისამართის მიღება ამ ორი მოწყობიდან არც ერთზე არაფერს ამბობს.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

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

TUN მოწყობილობა IP პაკეტებს ატარებს, ამიტომ სტუმრის შიგნით ნაგულისხმევი კარიბჭის დამატება გვირაბს host-only ადაპტერთან Ethernet სეგმენტად არ აქცევს. TAP ხიდი განსხვავებული დიზაინია, საკუთარი კლიენტური მხარდაჭერით და მისამართების საკუთრებით, და ორი აღწერის შერევა იწვევს კონფიგურაციებს, რომლებიც არასოდეს იყრის თავს.

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

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

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

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