Заявка в АРК Технолоджис
(812)974.06.35
О компании archive.arctech.ru

OpenVPN - с чего начать. UDP vs TCP, bridge vs P2P, net30 vs subnet

OpenVPN - с чего начать. UDP vs TCP, bridge vs P2P, net30 vs subnet

Проектируя сервер OpenVPN администратор должен решить - какой протокол использовать для VPN-канала: TCP или UDP. Разработчкики OpenVPN считают, что лучшим вариантом является UDP (http://sites.inka.de/sites/bigred/devel/tcp-tcp.html) по надежности, быстродействию и безопасности. Однако, если вы планируете использовать Микротики в качестве клиентских оконечных VPN-устройств выбора у вас нет: только TCP. Поэтому при планировании VPN-сети разумно поднимать два сервера: один для UDP-клиентов, второй - для TCP-клиентов. В качестве первых могут выступать любые Unix- и Windows-клиенты. В качестве вторых - Микротики.

Приняв решение поддерживать 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-серверов.

Вернуться в список статей