VPN шлюз VirtualBox за LAN: мост, маршрут, връщане

Свържете шлюзовата VM към LAN чрез мост, обявете LAN на клиентите и добавете маршрута за пула в рутера на LAN. Работен пример с IPv4 и реални обратни пътища.

Отдалечените потребители трябва да достигат до принтер и файлов сървър във физическа LAN, а единствената Linux машина, която работи непрекъснато, е виртуална машина VirtualBox. Свързването на VM към тази LAN чрез мост е първата половина. Втората половина е обратен маршрут, който всяко устройство в LAN наистина ще използва, и точно това е частта, която повечето настройки пропускат. Когато липсва, тунелът се свързва, клиентът пингва шлюза и нищо друго не отговаря.

Използвайте адреси, които са достижими

Задайте LAN адаптера на VM в режим Bridged Adapter, одобрен за тази мрежа, и му дайте адрес чрез нормалния процес за разпределяне. Тогава VM се появява във физическата LAN като всеки друг хост. Маршрутът му по подразбиране трябва да продължава да използва истинския шлюз, за да остане достъпен криптираният транспорт до партньора по VPN. Не използвайте адреса по подразбиране на VirtualBox NAT като следващ хоп за LAN, защото този адрес живее зад виртуален NAT и не е on-link за хоста или за другите машини в LAN.

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

Проверете за застъпване с домашните мрежи на отдалечените потребители, преди да изберете пула. Застъпването се превръща в двусмислие в маршрутизацията, което никаква настройка на сървъра не поправя.

Обявете LAN, после препращайте

За сървър, чиято автентикация и транспорт вече се управляват, мрежовите редове изглеждат така. Push казва на приемащия клиент как да достигне LAN и сам по себе си не кара VM да препраща нищо.

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

Включете препращане на IPv4 в постоянната мрежова конфигурация на VM и разрешете на пула от клиенти да достига предвидените услуги в LAN на границата за препращане на VM. Разрешението за достъп до слушателя на VPN е отделно правило и то вече работи, ако тунелът е вдигнат.

Обратният маршрут принадлежи на рутера в LAN

Устройствата в LAN отговарят през шлюза си по подразбиране, който е рутерът в LAN на 192.168.70.1. Този рутер няма представа къде се намира 10.80.0.0/24, освен ако не му се каже. Добавете маршрута за пула в поддържаната постоянна конфигурация на рутера, сочейки LAN адреса на VM. Добавянето само на хоста VirtualBox поправя пътищата, които се обръщат към този хост, а това не е всяко устройство в LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

Собствената защитна стена на дестинацията все още трябва да разрешава пула от клиенти като източник. Маршрутът носи пакета; той не дава услугата.

Ако рутерът в LAN не може да бъде променен, алтернативата е ограничен превод на източника на VM. Той връща отговорите без маршрута и скрива отделните клиентски адреси от услугата в LAN.

Проследете един пакет от край до край

Клиент на 10.80.0.25 изпраща към 192.168.70.40 през тунела. VM препраща пакета в LAN. Услугата отговаря на своя рутер, който избира VM за пула от клиенти, и VM връща пакета през OpenVPN. Всеки хоп в това изречение е място, където дизайнът може да се провали.

Тествайте с реалното приложение от отдалечен клиент, после повторете след презареждане на управляваната конфигурация и на VM, и на рутера.

Ако клиентът достига VM, но не услугата, проверете първо маршрута на рутера. Ако услугата получава заявката, а клиентът никога не вижда отговора, обратният път е заподозреният.

Подобни статии