Маршрутизація трафіку VM у мережі 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 і мережу віртуальної машини та повторіть ті самі три перевірки. Маршрут, доданий вручну, живе до наступного перезавантаження, а конфігурація, що працює лише в теплій сесії, — не проєкт. Запишіть обидва префікси, політику пересилання та маршрут гостьової системи разом. Той, хто додасть наступну віртуальну машину, потребуватиме всі три, інакше він знову відкриватиме їх із кожним невдалим підключенням.