Лабараторыя VPN у VirtualBox: шлюзавая ВМ супраць сеткі толькі для хоста

Вам трэба вырашыць, колькі механізмаў заслугоўвае ваша лабараторыя VPN. Маршрутызаваная шлюзавая ВМ паміж двума сегментамі VirtualBox узнаўляе трансляцыю адрасоў, зваротны шлях і пазіцыю файрвола, за якой сядзіць рэальны кліент. Адзіны сегмент «толькі для хоста» дае вам адны кантраляваныя дзверы і больш нічога. Версія са шлюзам каштуе тры госці і табліцу маршрутызацыі, якую вы падтрымліваеце; версія «толькі для хоста» каштуе адзін госць і адну палітыку. Тры пытанні аддзяляюць іх, і трэцяе вырашае, ці можа ваш тэст наогул прайсці.

Адказвайце на тры пытанні, перш чым нешта кланаваць

Пачніце з таго, што павінен назіраць сервер VPN. Калі сервер павінен бачыць адрас крыніцы, які не належыць тэставаму госцю, нешта павінна трансляваць паміж імі, і гэта нешта павінна быць маршрутызатарам, які вы кантралюеце. Сетка «толькі для хоста» дае хосту адаптар у сегменце госця, а не транслятар. Калі потым госцю трэба дабрацца да чаго-небудзь звонку, вы далучаеце адаптар NAT, і ўласны рухавік NAT у VirtualBox перапісвае крыніцу, не пытаючыся ў вас.

Затым спытайце, ці можа госць дабрацца да чаго-небудзь інакш як праз тунель. Гэты адказ выбірае ўнутраны або «толькі для хоста», і менавіта гэтае пытанне большасць апісанняў лабараторый прапускае. Нарэшце, спытайце, што павінна адбыцца, калі тунель падае, бо гэта вызначае палітыку, а не тапалогію, а лабараторыя, якая даказвае толькі шчаслівы шлях, не праверыла амаль нічога.

Злучыце тры ролі ўнутранымі сеткамі

Выкарыстайце тры госці і два названыя сегменты, прычым шлюз — адзіная машына, якая трымае адаптар на абодвух:

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 і яго файрвол не могуць выпадкова дабрацца да гасцей. Унутраны сегмент таксама не мае сервера DHCP, пакуль вы яго не дадасце, таму статычныя адрасы — самы кароткі шлях.

Дайце кліенту толькі яго адрас WAN, а шлюз па змаўчанні павінен паказваць на адрас WAN шлюза. Сервер атрымлівае адрас LAN і выкарыстоўвае адрас LAN шлюза як свой шлюз па змаўчанні. Госць, які трымае два адрасы ў адным сегменце або мае лішні маршрут у другі сегмент, мае шлях вакол маршрутызатара, і тэсты ніжэй будуць вам хлусіць.

Я трымаю тэкставы файл побач з імёнамі ВМ, у якім чатыры адрасы і два імёны сегментаў, і ўстаўляю яго ў кожную абалонку. Праз тыдні, калі змена профілю нешта ламае, гэты файл — розніца паміж адладкай профілю і адладкай маёй уласнай памяці.

Выберыце ўнутраны або «толькі для хоста» для сегмента, які не павінен працякаць

Рэжым «толькі для хоста» стварае віртуальны адаптар на самім хосце, звычайна vboxnet0, і дае хосту адрас у сегменце госця. Гэта зручна для адміністравання і фатальна для тэсту ізаляцыі, бо хост цяпер можа дабрацца да госця напрамую, і кожная служба на баку хоста становіцца магчымым шляхам. Унутраны рэжым не мае адаптара хоста наогул. Два рэжымы лёгка зблытаць у панэлі налад сеткі, таму правярайце апісаную розніцу, а не назву (глядзіце старонку падрабязнасцей пра сеткі VirtualBox).

Для госця, які павінен выкарыстоўваць тунель, унутраны рэжым — больш бяспечны тыповы выбар, а шлюз — адзіны выхад. Калі вы пакідаеце «толькі для хоста», стаўцеся да адаптара хоста як да шляху кіравання і скажыце гэта ўголас: хост можа дабрацца да госця, а госць не павінен мець магчымасці выкарыстоўваць хост як выхад.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

Ізаляцыя, якую вы можаце даказаць, — гэта ізаляцыя, якую вы наладзілі. Госць з адным унутраным адаптарам, маршрутам па змаўчанні на шлюз і без адаптара NAT не мае шляху, які абышоў бы шлюз. Госць з адаптарам «толькі для хоста» і адаптарам NAT мае два шляхі, і толькі адзін з іх — той, які вы хацелі праверыць.

Маршрутызуйце і транслюйце на шлюзе, затым зрабіце так, каб ён зачыняўся пры збоі

VirtualBox не перасылае паміж сегментамі; гэта робіць госць. Калі ВМ сервера VPN стаіць за шлюзам, уключыце перасылку і транслюйце трафік кліента, калі ён сыходзіць да сервера:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

З гэтым правілам сервер бачыць адрас LAN шлюза замест адраса кліента, і менавіта так выглядае рэальны кліент за NAT аператара з пункту гледжання галаўнога вузла. Захавайце значэнне sysctl у /etc/sysctl.d/, а правіла — у той службе файрвола, якую выкарыстоўвае дыстрыбутыў, інакш перазапуск ціха верне лабараторыю ў маршрутызаваны, але нетрансляваны стан.

Перасылка — гэта не аўтарызацыя. Пры тыповай палітыцы FORWARD са значэннем ACCEPT госць, чый маршрут па змаўчанні паказвае на шлюз, выходзіць праз той інтэрфейс, які выбера табліца маршрутызацыі, тунель ці не. Калі ў шлюза ёсць яшчэ і адаптар NAT для ўсталявання пакетаў, гэты адаптар — працоўны незашыфраваны выхад у тую ж хвіліну, калі тунель падае, і ваш тэст «толькі VPN» ніколі не быў тэстам «толькі VPN».

Калі ж сервер знаходзіцца здалёк, а тунель завяршае сам шлюз, тое ж рашэнне паказвае на інтэрфейс тунеля, а не на сеткавы адаптар, які выходзіць у інтэрнэт:

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, працякае па задуме, а не выпадкова.

Нарэшце, зламайце гэта наўмысна. Спыніце тунель або заблакуйце яго знешні порт і адкрыйце новае злучэнне з боку госця. Яно павінна праваліцца, і прычына павінна быць такой, якую вы можаце назваць: няма маршруту, ёсць правіла адхілення або рэзалвер мёртвы. Перазапусціце тунель і пацвердзіце, што госць аднаўляецца без перабудовы сеткі. Калі меш-сетка VPN накшталт Hamachi або ZeroTier дзеліць лабараторыю, памятайце, што мастовы адаптар ідзе за імем адаптара, а не за мешам, таму мост трэба перанакіраваць пасля таго, як кліент усталюе ўласны віртуальны адаптар.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Сумеснае выкарыстанне тунеля госця з хостам люструе праблему. Накіраванне маршруту хоста па змаўчанні на госця працуе, як і проксі ўнутры госця; NAT праз хост не нясе тунель госця для трафіку, які паходзіць ад хоста. Захавайце імёны сегментаў і правілы файрвола ў адным месцы, зрабіце здымак працоўнага стану і запішыце адрас крыніцы, які назіраў сервер. Тады наступная змена профілю каштуе адзін запуск скрыпта замест перабудаванай лабараторыі.