VirtualBox VPN ლაბორატორია: კარიბჭის VM თუ მხოლოდ ჰოსტის ქსელი
აირჩიეთ მარშრუტიზებულ კარიბჭის VM-სა და მხოლოდ ჰოსტის სეგმენტს შორის VirtualBox VPN ლაბორატორიისთვის, შემდეგ კი აიძულეთ სტუმარი დახურულად ჩავარდეს, როცა გვირაბი ვარდება.
თქვენ უნდა გადაწყვიტოთ, რამდენ მექანიზმს იმსახურებს თქვენი VPN ლაბორატორია. ორ VirtualBox სეგმენტს შორის მარშრუტიზებული კარიბჭის VM ამრავლებს მისამართების თარგმნას, დაბრუნების გზას და იმ firewall-ის პოზიციას, რომლის უკანაც ნამდვილი კლიენტი ზის. ერთი მხოლოდ ჰოსტის სეგმენტი გაძლევთ ერთ კონტროლირებად კარს და მეტს არაფერს. კარიბჭის ვერსია ღირს სამი სტუმარი და ერთი მარშრუტიზაციის ცხრილი, რომელსაც თქვენ ინახავთ; მხოლოდ ჰოსტის ვერსია ღირს ერთი სტუმარი და ერთი პოლიტიკა. სამი კითხვა ჰყოფს მათ, და მესამე წყვეტს, შეიძლება თუ არა თქვენი ტესტი საერთოდ გავიდეს.
უპასუხეთ სამ კითხვას, სანამ რამეს კლონირებთ
დაიწყეთ იმით, რა უნდა დააკვირდეს VPN სერვერმა. თუ სერვერმა უნდა დაინახოს წყაროს მისამართი, რომელიც ტესტის სტუმრის არ არის, მათ შორის რაღაც უნდა თარგმნოს, და ეს რაღაც უნდა იყოს თქვენ მიერ კონტროლირებული მარშრუტიზატორი. მხოლოდ ჰოსტის ქსელი ჰოსტს აძლევს ადაპტერს სტუმრის სეგმენტზე, არა მთარგმნელს. როცა სტუმარს შემდეგ გარეთ რაღაცამდე მისვლა სჭირდება, თქვენ უერთებთ NAT ადაპტერს, და VirtualBox-ის საკუთარი NAT ძრავა ხელახლა წერს წყაროს თქვენი კითხვის გარეშე.
შემდეგ ჰკითხეთ, შეიძლება თუ არა სტუმარი რაღაცამდე მივიდეს გვირაბის გარდა. ეს პასუხი ირჩევს შიდა ან მხოლოდ ჰოსტის ვარიანტს, და სწორედ ეს არის კითხვა, რომელსაც ლაბორატორიის აღწერების უმეტესობა გამოტოვებს. ბოლოს ჰკითხეთ, რა უნდა მოხდეს, როცა გვირაბი ვარდება, რადგან ეს პოლიტიკას წყვეტს და არა ტოპოლოგიას, და ლაბორატორიამ, რომელიც მხოლოდ ბედნიერ გზას ამტკიცებს, თითქმის არაფერი გამოსცადა.
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
დააკავშირეთ სამი როლი შიდა ქსელებით
გამოიყენეთ სამი სტუმარი და ორი დასახელებული სეგმენტი, კარიბჭე კი ერთადერთი მანქანა იყოს, რომელსაც ორივეზე ადაპტერი აქვს:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANშიდა ქსელისთვის ცალკე შექმნის ნაბიჯი არ არსებობს. --intnet1-ში მოცემული სტრიქონი სწორედ სეგმენტია: ორი მანქანა მას მხოლოდ მაშინ იზიარებს, როცა სახელი ზუსტად ემთხვევა, და ჰოსტზე არაფერია მასზე მიბმული. სწორედ ეს უკანასკნელი თვისებაა ლაბორატორიის სუფთა გამეორების მიზეზი, რადგან ჰოსტის მარშრუტები, მისი საკუთარი VPN კლიენტი და მისი firewall არ შეიძლება შემთხვევით მივიდეს სტუმრებამდე. შიდა სეგმენტს DHCP სერვერიც არ აქვს, თუ თქვენ არ დაამატებთ ერთს, ამიტომ სტატიკური მისამართები ყველაზე მოკლე გზაა.
მიეცით კლიენტს მხოლოდ მისი WAN მისამართი, ნაგულისხმევი კარიბჭე კი კარიბჭის WAN მისამართზე მიუთითებდეს. სერვერი იღებს LAN მისამართს და იყენებს კარიბჭის LAN მისამართს როგორც თავის ნაგულისხმევ კარიბჭეს. სტუმარს, რომელიც ერთ სეგმენტზე ორ მისამართს ინახავს, ან სხვა სეგმენტისკენ დაკარგული მარშრუტი აქვს, მარშრუტიზატორის გვერდის ავლის გზა აქვს, და ქვემოთ მოცემული ტესტები თქვენ მოგატყუებენ.
VM-ების სახელების გვერდით ტექსტურ ფაილს ვინახავ ოთხი მისამართით და ორი სეგმენტის სახელით, და ყველა shell-ში ვაკოპირებ მას. კვირების შემდეგ, როცა პროფილის ცვლილება რაღაცას ამტვრევს, ეს ფაილია განსხვავება პროფილის გამართვასა და საკუთარი მეხსიერების გამართვას შორის.
სეგმენტისთვის, რომელიც არ უნდა გაჟონოს, აირჩიეთ შიდა ან მხოლოდ ჰოსტის
მხოლოდ ჰოსტის რეჟიმი ქმნის ვირტუალურ ადაპტერს თავად ჰოსტზე, ჩვეულებრივ vboxnet0, და ჰოსტს აძლევს მისამართს სტუმრის სეგმენტზე. ეს მოსახერხებელია ადმინისტრირებისთვის და საბედისწერო იზოლაციის ტესტისთვის, რადგან ჰოსტს ახლა შეუძლია სტუმრამდე პირდაპირ მივიდეს და ჰოსტის მხარეს ყველა სერვისი შესაძლო გზად იქცევა. შიდა რეჟიმს ჰოსტის ადაპტერი საერთოდ არ აქვს. ორი რეჟიმი ადვილად ირევა ქსელის პარამეტრების პანელში, ამიტომ შეამოწმეთ დოკუმენტირებული განსხვავება და არა იარლიყი (იხილეთ VirtualBox ქსელის დეტალები გვერდი).
სტუმრისთვის, რომელმაც აუცილებლად უნდა გამოიყენოს გვირაბი, შიდა უფრო უსაფრთხო ნაგულისხმევია, კარიბჭე კი ერთადერთი გასასვლელი. თუ მხოლოდ ჰოსტის რეჟიმს ინახავთ, მოეპყარით ჰოსტის ადაპტერს როგორც მართვის გზას და ხმამაღლა თქვით ეს: ჰოსტს შეუძლია სტუმრამდე მისვლა, ხოლო სტუმარს არ უნდა შეეძლოს ჰოსტის გამოყენება გასასვლელად.
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0იზოლაცია, რომლის დამტკიცებაც შეგიძლიათ, არის იზოლაცია, რომელიც თქვენ დააკონფიგურირეთ. სტუმარს ერთი შიდა ადაპტერით, კარიბჭეზე ნაგულისხმევი მარშრუტით და NAT ადაპტერის გარეშე არ აქვს კარიბჭის გვერდის ავლის გზა. სტუმარს მხოლოდ ჰოსტის ადაპტერით და NAT ადაპტერით ორი გზა აქვს, და მათგან მხოლოდ ერთია ის, რისი გამოცდაც გსურდათ.
მარშრუტიზაცია და თარგმნა გააკეთეთ კარიბჭეზე, შემდეგ კი დააფიქსირეთ დახურული მარცხი
VirtualBox სეგმენტებს შორის არ გადასცემს; ამას სტუმარი აკეთებს. როცა VPN სერვერის VM კარიბჭის უკანაა, ჩართეთ გადაცემა და თარგმნეთ კლიენტის ტრაფიკი, როცა ის სერვერისკენ გადის:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEამ წესით სერვერი ხედავს კარიბჭის LAN მისამართს კლიენტის ნაცვლად, და სწორედ ასე გამოიყურება ოპერატორის NAT-ის უკან მყოფი ნამდვილი კლიენტი ქსელის თავისთვის. შეინახეთ sysctl მნიშვნელობა /etc/sysctl.d/-ში, ხოლო წესი იმ firewall სერვისში, რომელსაც დისტრიბუტივი იყენებს, თორემ გადატვირთვა ჩუმად დააბრუნებს ლაბორატორიას მარშრუტიზებულ, მაგრამ აუთარგმნელ მდგომარეობაში.
გადაცემა ავტორიზაცია არ არის. ACCEPT-ის ნაგულისხმევი FORWARD პოლიტიკის ქვეშ, სტუმარი, რომლის ნაგულისხმევი მარშრუტიც კარიბჭეზე მიუთითებს, გადის იმ ინტერფეისიდან, რომელსაც მარშრუტიზაციის ცხრილი აირჩევს, გვირაბით ან მის გარეშე. თუ კარიბჭეს პაკეტების ინსტალაციისთვის NAT ადაპტერიც აქვს, ის ადაპტერი მუშა დაშიფრვის გარეშე გასასვლელია იმ წუთას, როცა გვირაბი ვარდება, და თქვენი მხოლოდ-VPN ტესტი არასდროს ყოფილა მხოლოდ-VPN ტესტი.
როცა სერვერი შორს არის და გვირაბს თავად კარიბჭე ამთავრებს, იგივე გადაწყვეტილება გვირაბის ინტერფეისზე მიუთითებს და არა ინტერნეტამდე მიმავალ NIC-ზე:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTგვირაბის საკუთარი გარე ტრანსპორტი და ზოლის გარეთა მართვის მარშრუტი გამოყავით გადაცემული ტრაფიკისგან. თუ კარიბჭის შეკეთების ერთადერთი გზა იმ გვირაბში გადის, რომელსაც თქვენ ამუშავებთ, ლაბორატორია ჩაკეტვის ვარჯიშად იქცევა. სერიული კონსოლი, მხოლოდ ჰოსტის მართვის ადაპტერი ან ცნობილი კარგი მდგომარეობის სურათი უფრო იაფია, ვიდრე გატეხილი მარშრუტიზატორის ხელით აღდგენა.
შეამოწმეთ გზა სტუმრიდან და არა ჰოსტიდან
იმუშავეთ გარეთკენ. დაადასტურეთ, რომ კლიენტი აღწევს კარიბჭის WAN მისამართამდე, შემდეგ სერვერამდე კარიბჭის გავლით, შემდეგ რომ VPN პორტამდე კავშირი გადის და ბრუნდება. ჩაწერა კარიბჭის ორივე ინტერფეისზე აჩვენებს, მოდის თუ არა პასუხი და ხომ არ იგდება იგი დაბრუნების გზაზე, რასაც მხოლოდ კლიენტზე გაკეთებული ჩაწერა ვერ გაარჩევს:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194შემდეგ დაამტკიცეთ გასასვლელი. ჰკითხეთ სტუმრიდან მისამართების ასახვის სერვისს, რომელ წყაროს ხედავს, და შეადარეთ ის კარიბჭის საკუთარ გასასვლელ მისამართს; თუ პასუხი ჰოსტის მისამართს ემთხვევა, გვირაბის გვერდის ავლის გზა არსებობს. შეამოწმეთ, რომელ გადამწყვეტს იყენებს სტუმარი სინამდვილეში, და IPv6 ცალკე შეამოწმეთ, რადგან სეგმენტი, სადაც IPv6 ჩართულია, მაშინ როცა გვირაბი მხოლოდ IPv4-ს ატარებს, დიზაინით ჟონავს და არა შემთხვევით.
ბოლოს, გაიტეხეთ ის განზრახ. გააჩერეთ გვირაბი ან დაბლოკეთ მისი გარე პორტი, და გახსენით ახალი კავშირი სტუმრიდან. ის უნდა ჩავარდეს, და მიზეზი უნდა იყოს ისეთი, რომელსაც დაასახელებთ: მარშრუტი არ არის, უარის წესია, ან გადამწყვეტი მკვდარია. გადატვირთეთ გვირაბი და დაადასტურეთ, რომ სტუმარი ჯანმრთელდება ქსელის ხელახალი აშენების გარეშე. თუ Hamachi-ს ან ZeroTier-ის მსგავსი mesh VPN ლაბორატორიას იზიარებს, დაიმახსოვრეთ, რომ ხიდზე მყოფი ადაპტერი ადაპტერის სახელს მიჰყვება და არა mesh-ს, ამიტომ ხიდი ხელახლა უნდა მიმართოს მას შემდეგ, რაც კლიენტი დააყენებს საკუთარ ვირტუალურ ადაპტერს.
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>სტუმრის გვირაბის ჰოსტთან გაზიარება ასახავს პრობლემას. ჰოსტის ნაგულისხმევი მარშრუტის სტუმრისკენ მიმართვა მუშაობს, ისევე როგორც proxy სტუმრის შიგნით; NAT ჰოსტის გავლით არ ატარებს სტუმრის გვირაბს ჰოსტის მიერ დაწყებული ტრაფიკისთვის. შეინახეთ სეგმენტების სახელები და firewall-ის წესები ერთ ადგილას, გადაიღეთ მომუშავე მდგომარეობის სურათი და ჩაწერეთ წყაროს მისამართი, რომელიც სერვერმა დააკვირდა. მაშინ შემდეგი პროფილის ცვლილება ერთი სკრიპტის გაშვება ეღირება და არა ხელახლა აშენებული ლაბორატორია.