VPN-шлюз VirtualBox для LAN: міст, маршрут, повернення

Підключіть шлюзову віртуальну машину до LAN через міст, оголосіть LAN клієнтам і додайте маршрут пулу на маршрутизатор LAN. Розібраний приклад IPv4 зі справжніми зворотними шляхами.

Віддаленим користувачам потрібен доступ до принтера й файлового сервера у фізичній LAN, а єдина постійно ввімкнена машина з Linux — це віртуальна машина VirtualBox. Підключити її до цієї LAN через міст — перша половина. Друга половина — зворотний маршрут, який справді використовуватиме кожен пристрій у LAN, і саме його більшість налаштувань пропускає. Коли його немає, тунель піднімається, клієнт пінгує шлюз, і більше ніхто не відповідає.

Використовуйте доступні адреси

Перемкніть LAN-адаптер віртуальної машини в режим Bridged Adapter, дозволений для цієї мережі, і видайте йому адресу звичайним процесом розподілу. Тоді віртуальна машина з'явиться у фізичній LAN як будь-який інший хост. Її маршрут за замовчуванням має й далі використовувати справжній шлюз, щоб шифрований транспорт до партнера VPN залишався доступним. Не використовуйте стандартну NAT-адресу VirtualBox як наступний крок для 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, і сам по собі не змушує віртуальну машину щось пересилати.

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

Увімкніть пересилання IPv4 у постійній мережевій конфігурації віртуальної машини й дозвольте пулу клієнтів досягати потрібних служб LAN на межі пересилання. Дозвіл на доступ до слухача VPN — окреме правило, і воно вже працює, якщо тунель піднявся.

Зворотний маршрут належить маршрутизатору LAN

Пристрої в LAN відповідають через свій шлюз за замовчуванням — маршрутизатор LAN за адресою 192.168.70.1. Цей маршрутизатор гадки не має, де розташована 10.80.0.0/24, якщо йому не сказати. Додайте маршрут пулу в підтримувану постійну конфігурацію маршрутизатора, спрямувавши його на LAN-адресу віртуальної машини. Якщо додати його лише на хості VirtualBox, виправляться тільки шляхи, що звертаються до цього хоста, а це не кожен пристрій у LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

Власний міжмережевий екран призначення все одно має дозволяти пул клієнтів як джерело. Маршрут несе пакет; він не надає послугу.

Якщо маршрутизатор LAN змінити неможливо, альтернатива — обмежений переклад джерела на віртуальній машині. Він повертає відповіді без маршруту й приховує окремі адреси клієнтів від служби LAN.

Простежте один пакет від початку до кінця

Клієнт за адресою 10.80.0.25 надсилає на 192.168.70.40 через тунель. Віртуальна машина пересилає пакет у LAN. Служба відповідає своєму маршрутизатору, який вибирає віртуальну машину для пулу клієнтів, і вона повертає пакет через OpenVPN. Кожен крок у цьому реченні — місце, де схема може відмовити.

Перевірте справжнім застосунком з віддаленого клієнта, потім повторіть після перезавантаження керованої конфігурації і на віртуальній машині, і на маршрутизаторі.

Якщо клієнт досягає віртуальної машини, але не служби, спершу перевірте маршрут маршрутизатора. Якщо служба отримує запит, а клієнт ніколи не бачить відповіді, підозрюваний — зворотний шлях.

Схожі статті