Маршрутизация трафика виртуальных машин в сети host-only через сервер TUN OpenVPN

Адаптеры host-only создают локальную виртуальную сеть, а маршрутизируемые TUN-туннели переносят IP-пакеты между адресами. Ни один из них не является мостом к другому, поэтому работающая конфигурация должна сказать, кто пересылает и кому принадлежит обратный маршрут. Перепутайте эти две роли, и гость ответит туннелю источником, который клиент туннеля никогда не запрашивал. Конфигурация ниже держит оба префикса раздельно и делает обратный путь явным.

Две сети, два префикса

Дайте пулу туннеля и сети host-only разные префиксы и никогда не используйте один вместо другого. В этом примере пул VPN — 10.44.0.0/24, а сеть host-only — 192.168.99.0/24, хост находится на 192.168.99.1, а гость — на 192.168.99.20. Назначение одного и того же префикса и устройству TUN, и адаптеру host-only не объединяет их. Оно создаёт две заявки на один диапазон адресов, и таблица маршрутизации затем отвечает за ту заявку, которую случайно сохранила.

Адаптер host-only существует на хосте и внутри гостя, и сам по себе он не имеет пути за пределы машины. Мостовые и NAT-подключения имеют разную экспозицию, и переключение в мостовой режим не является условием доступа к одной службе гостя.

Хост уже держит путь

Посмотрите, что существует, прежде чем что-то добавлять. У хоста есть интерфейс в сети host-only и маршрут для этого префикса, оба созданы при поднятии адаптера.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Третья строка — механизм, который превращает хост в промежуточный узел. Без него пакет, пришедший из туннеля, адресован сети, до которой хост может добраться, но которую не станет пересылать. Пересылка необходима и недостаточна. Политика фильтрации по-прежнему решает, разрешён ли конкретный поток между интерфейсом туннеля и интерфейсом host-only, и это решение должно быть записано, а не лежать в политике по умолчанию, которую никто не читал.

Протолкните маршрут, затем отфильтруйте то, до чего он доходит

Сервер может передать префикс host-only клиентам, принимающим протолкнутые маршруты, — это тот же механизм, что используется для любой другой подсети за туннелем.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Эти два правила разрешают одну службу в одном направлении и её ответы. Маршрут, доходящий до всего префикса, и фильтр, разрешающий один порт, — осознанное сочетание; маршрут плюс безусловное разрешение — это путь, которым лабораторная служба становится открытой. Протолкнутый маршрут также не является авторизацией. Клиент его принимает, хост его пересылает, а межсетевой экран гостя и сама служба по-прежнему имеют голос.

Гостю нужен путь назад

Гость, до которого доходят с 10.44.0.x, должен отправлять свои ответы на адрес host-only хоста, или хост должен транслировать источник. Получение адреса от DHCP VirtualBox ничего не говорит ни об одном из этих вариантов.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Добавление этого маршрута внутри гостя сохраняет исходный источник, что делает осмысленными политику и журналы по каждому клиенту. Ограниченная трансляция источника на хосте — альтернатива, и она работает, но ценой сокрытия того, какой клиент подключился. Перекрытие — другой режим отказа. Удалённый клиент, чья домашняя сеть уже использует 192.168.99.0/24, прочитает протолкнутый маршрут как свою собственную сеть, и никакое изменение на стороне сервера не устранит эту неоднозначность. Перенумеруйте одну сторону или выберите префикс, который вряд ли столкнётся.

Устройство TUN переносит IP-пакеты, поэтому добавление шлюза по умолчанию внутри гостя не превращает туннель в сегмент Ethernet с адаптером host-only. Мост TAP — это другой проект с собственной поддержкой клиентов и собственным владением адресами, и смешение двух описаний ведёт к конфигурациям, которые никогда не сходятся.

Проверьте, а затем сделайте так, чтобы это пережило перезапуск

Проверьте одну безобидную службу с обычного удалённого клиента, посмотрите обратный маршрут гостя и убедитесь, что служба, которую вы не разрешали, отклоняется, а не работает медленно.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Затем перезапустите службу VPN и сеть виртуальной машины и повторите те же три проверки. Маршрут, добавленный вручную, живёт до следующей перезагрузки, а конфигурация, работающая только в тёплой сессии, — не проект. Запишите оба префикса, политику пересылки и маршрут гостя вместе. Кто добавит следующую виртуальную машину, тому понадобятся все три, иначе он будет открывать их заново с каждым неудачным подключением.