Приняв решение поддерживать UDP- и TCP-клиентов системный администратор неизбежно приходит ко второму вопросу: bridge-server или P2P-сервер. Напомним:
1. В режиме bridge-сервер используется виртуальный L2-интерфейс: tap. В этом случае VPN-клиент – и возможно его внутренняя сеть – становятся частью поднимаемой вами VPN-сети. К вам в сеть пойдут ARP-трафик и broadcast-пакеты из сети клиента. Если последняя собрана на Windows, то широковещательный трафик будет изрядным. А если в сети клиента заведется доморощенный хакер, то сеть ваша и сети других ваших клиентов могут стать мишенью атак. Ибо L2-трафик предоставляет для этого больше возможностей;
2. В режиме P2P используется виртуальный L3-интерфейс: tun. Степень защищенности вашей сети от клиента (и клиента от вашей сети) определяются настройками вашего файрвола. Широковещательный трафик (в частности NetBIOS-пакеты) отсутсвуют. Вы можете разрешить к вам движение RDP и HTTP пакетов – т.е. полностью подавить UDP-трафик из сети клиента – а к клиенту ограничить трафик SMB и SNMP портами.
Предположим: у вас поднята группа терминальных серверов (обычно – виртуальных), собранных в одну внутреннюю сеть. И, возможно – на разных физических хостах. И вот оно искушение: включаем ОБА – TCP и UDP VPN-сервера – в режим bridge-server и vous a la! Клиенты просто и легко ходят к серверам через оба VPN-сервера. Более того: появляется возможность кластеризовать VPN, подняв их на хостах у разных провайдеров! Никакой маршрутизации! Однако постарайтесь преодолеть это искушение. Если не хотите потом заниматься настройкой ebtables, а также решать с помощью политик Windows задачки – как не дать увидеть с ваших терминальных серверов компьютеры из разных клиентских сетей.
Наш совет: не использовать bridge-server конфигурацию без веских оснований. И никогда не использовать ее для подключения к своей сети недоверенных клиентов.
Bridge-server оказывается полезным, когда нужно связать – в том числе временно – ваши собственные надежно защищенные внутренние серверные сети. Инструкции разработчика по конфигурации OpenVPN bridge-server: https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.htm
Если выбор конфигурации склонился в сторону P2P соединения остается решить последний вопрос: какую использовать топологию.
Опция topology приобретает смысл совместно с dev tun. И предусматривает три варианта: net30, p2p, subnet – в случае использования OpenVPN версии 2.1 или новее.
Универсальным решением для VPN-сервера является net30 – default. Он будет работать со всеми версиями Windows, Unix, Mikrotik. Его недостатками являются: избыточное расходование адресного пространства – по 4 адреса на каждого VPN-клиента и более сложная маршрутизация к клиентской сети со стороны сервера в случае пула VPN-серверов.
topology p2p для счастливчиков, у которых отсутсвуют Windows-VPN-клиенты.
topology subnet рекомендуем, во-первых, для TCP-серверов, рассчитанных на подключение Микротиков. Во-вторых для UDP-серверов, клиентами которых являются unix и Windows от 8.2 и выше. Данная топология выделяет каждому клиенту один адрес.
Надеемся, что данная заметка позволила кому-то расставить недостающие точки над Ё в своих планах. И подготовила к мысли, что на одном хосте логично поднимать несколько VPN-серверов.