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, изтича по замисъл, а не случайно.

Накрая го счупете нарочно. Спрете тунела или блокирайте външния му порт и отворете нова връзка от госта. Тя трябва да се провали и причината трябва да е такава, която можете да назовете: няма маршрут, има правило за отхвърляне или резолверът е мъртъв. Рестартирайте тунела и потвърдете, че гостът се възстановява без да се престроява мрежата. Ако mesh VPN като Hamachi или ZeroTier споделя лабораторията, помнете, че мостовият адаптер следва името на адаптера, а не mesh мрежата, затова мостът трябва да се пренасочи, след като клиентът инсталира собствения си виртуален адаптер.

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

Споделянето на тунела на госта с хоста огледално показва проблема. Насочването на маршрута по подразбиране на хоста към госта работи, както и прокси вътре в госта; NAT през хоста не пренася тунела на госта за трафик, който хостът е започнал. Запазете имената на сегментите и правилата на защитната стена на едно място, направете снимка на работещото състояние и запишете адреса на източника, който сървърът е наблюдавал. Тогава следващата промяна в профила струва едно изпълнение на скрипт вместо престроена лаборатория.