Маршрутизиране на трафика на VM в мрежа само на хоста през TUN OpenVPN сървър

Адаптерите само на хоста създават локална виртуална мрежа, а маршрутизираните TUN тунели пренасят IP пакети между адреси. Нито едно от двете не е мост към другото, затова работеща конфигурация трябва да каже кой препраща и на кого принадлежи обратният маршрут. Объркате ли тези две назначения, гостът отговаря на тунела с източник, който клиентът на тунела никога не е поискал. Дизайнът по-долу държи двата префикса разделени и прави обратния път явен.

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

Дайте на пула на тунела и на мрежата само на хоста различни префикси и никога не използвайте един вместо друг. В този пример VPN пулът е 10.44.0.0/24, а мрежата само на хоста е 192.168.99.0/24, с хост на 192.168.99.1 и гост на 192.168.99.20. Задаването на един и същ префикс и на TUN устройство, и на адаптера само на хоста не ги свързва. То създава две претенции към един адресен диапазон и таблицата за маршрутизиране отговаря за тази, която случайно е запазила.

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

Хостът вече държи пътя

Вижте какво съществува, преди да добавите нещо. Хостът има интерфейс в мрежата само на хоста и маршрут за този префикс, и двете създадени при вдигането на адаптера.

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

Третият ред е механизмът, който превръща хоста в междинен възел. Без него пакет, пристигащ от тунела, е адресиран до мрежа, до която хостът може да достигне, но няма да препрати. Препращането е необходимо и недостатъчно. Политиката за филтриране все още решава дали конкретен поток между интерфейса на тунела и интерфейса само на хоста е разрешен, и това решение трябва да е записано, а не в политика по подразбиране, която никой не е чел.

Изпратете маршрута, после филтрирайте какво достига

Сървърът може да предостави префикса само на хоста на клиенти, които приемат изпратени маршрути, което е същият механизъм, използван за всяка друга подмрежа зад тунела.

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, трябва да изпраща отговорите си до адреса само на хоста на хоста, или хостът трябва да транслира източника. Получаването на адрес от 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 сегмент с адаптера само на хоста. TAP мостът е различен дизайн със своя поддръжка на клиенти и собственост на адреси, а смесването на двете описания води до конфигурации, които никога не се сближават.

Проверете, после го направете устойчиво на рестарт

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

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

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