Один сервер TAP или несколько? Клиенты OpenVPN на мосту

Несколько клиентов TAP не требуют по одному серверному процессу, одному порту UDP и одному устройству TAP на хосте для каждого. Один сервер OpenVPN в режиме Ethernet может принять много прошедших проверку клиентов и подключить их к одному мосту, и это документированный способ расширить сегмент канального уровня 2. Схема с одним процессом — та, что описана в руководстве, и обычно это правильное значение по умолчанию.

Настоящий вопрос в том, должны ли эти клиенты делить этот сегмент. Количество процессов на него не отвечает, потому что свойства изоляции определяются топологией, а не тем, сколько демонов запущено. Остальная часть сравнения — о двух топологиях и о том, что каждая упрощает.

Две архитектуры, а не две настройки

Развёртывание с маршрутизируемым TUN даёт каждому клиенту соединение «точка-точка» в домен маршрутизации сервера. Широковещание останавливается на сервере, клиенты не видят кадры друг друга, а трафик между клиентами, если он есть, нужно явно маршрутизировать и фильтровать.

Развёртывание с мостовым TAP делает клиентов членами одного сегмента Ethernet. Они видят широковещание, могут находить друг друга через ARP и для разделения полагаются на политику моста и межсетевого экрана, а не на маршрутизацию. Это полезно, когда клиенты должны выглядеть так, будто они подключены к одному коммутатору.

Таким образом, сравнение о том, чего клиентам нужно достичь, а не о производительности. Сначала выберите уровень, затем решите, сколько процессов его обслуживают.

Что делает помощник server-bridge

Помощник server-bridge настраивает режим Ethernet для нескольких клиентов. Его форма с пулом адресов принимает шлюз, маску сети и выделенный диапазон внутри мостовой подсети, например шлюз 192.168.50.1 с пулом от 192.168.50.160 до 192.168.50.199.

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

Существует форма с прокси DHCP для развёртываний, где адреса выдаёт внешний сервер. У неё свои предварительные условия, а смешивание двух форм создаёт ровно тот конфликт, о котором предупреждает документация. Выберите один распределитель для мостовой подсети.

Изоляция не определяется числом процессов

Восемь процессов OpenVPN, подключённых к одному и тому же неограниченному мосту, по-прежнему делят один домен широковещания. Клиенты могут отправлять друг другу ARP через мост, и число слушателей на это никак не повлияло.

Если требование в том, чтобы группы клиентов не видели друг друга на уровне 2, схеме нужны отдельные мосты или подключения VLAN вместе с соответствующими правилами доступа. Это решение о проектировании сети, и оно одинаково независимо от того, задействован один серверный процесс или восемь. Фильтрация моста может ограничить часть трафика, но не создаёт отдельных доменов широковещания. Рассматривайте её как дополнение к сегментации, а не как замену.

Если требование лишь в том, чтобы клиенты достигали определённых служб IP, схема с маршрутизируемым TUN обычно проще, чем мост с фильтрацией. Каждый клиент получает своё соединение, а политика живёт в правилах маршрутизации и межсетевого экрана, а не внутри моста.

Когда несколько процессов всё же оправданы

Отдельные процессы можно оправдать эксплуатационными нуждами: разными системами аутентификации, разными удостоверяющими центрами, отдельными циклами обновления или несовместимыми наборами параметров. Это реальные причины, и они не зависят от числа клиентов.

Если их несколько, дайте каждому свой слушатель и владение устройством и согласуйте диапазоны адресов. Два сервера, каждый из которых считает, что владеет одним и тем же пулом на одном и том же мосту, рано или поздно выдадут один и тот же адрес.

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

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