Назад |
Перейти на главную страницу
Как настроить надлежащую инфраструктуру OpenVPN для множественного независимого взаимодействия клиент-клиент с центральным сервером OpenVPN посередине
У меня есть небольшой опыт настройки простого решения OpenVPN, при котором несколько клиентов подключаются к центральному серверу и общаются вместе в одной VPN.
Однако сейчас я собираюсь создать OpenVPN-инфраструктуру с нуля, и я сомневаюсь, что мой подход является разумным. Инфраструктура OpenVPN имеет следующие характеристики:
- Есть N сайты двух типов:
- Мобильные сайты
- Стационарные сайты
- По логике, каждый мобильный сайт имеет ровно один назначенный стационарный сайт
- Стационарные клиенты сайта А может разговаривать только с мобильными клиентами сайта А и наоборот
- Один или несколько мобильных клиентов (linux) на сайт должен подключаться к центральному серверу (linux) через мобильную сеть и, следовательно, не иметь фиксированного IP-адреса, к которому можно получить доступ напрямую из-за NAT провайдера.
- Один или несколько стационарных клиентов (окон) на сайт должен подключаться к одному центральному серверу. У каждого из этих клиентов должна быть возможность подключиться к одному из мобильных клиентов или к подмножеству мобильных клиентов. Однако стационарный клиент не должен взаимодействовать более чем с одним мобильным клиентом одновременно.
- Связь между двумя подключенными клиентами должна быть изолирована от всех других, возможно установленных подключений.
- Мобильные клиенты, скорее всего, всегда стараются иметь соединение с центральным сервером. Но они могут быть настроены для подключения только по запросу.
- Стационарные клиенты могут установить соединение с центральным сервером в любое время и должны иметь возможность мгновенно связываться с желаемым мобильным клиентом (когда он, конечно, также подключен)
- Связь между всеми мобильными клиентами одного мобильного сайта или связь между подмножеством клиентов одного мобильного сайта может быть требованием на будущее. Однако даже если это требование будет выполнено, стационарные клиенты могут по-прежнему подключаться только к одному мобильному клиенту.
- Стационарные клиенты, даже принадлежащие к одному сайту, никогда не должны разговаривать друг с другом.
- Один административный стационарный клиент, отвечающий за инфраструктуру, должен иметь доступ к каждому мобильному клиенту (по одному за раз), независимо от того, к какому сайту он принадлежит. Административному клиенту никогда не приходится разговаривать с одним из стационарных клиентов.
- Вся инфраструктура будет (в первую очередь) иметь все мобильные клиенты, оснащенные OpenVPN 2.1.3, который довольно старый и может измениться с обновлениями прошивки (ничего, за что я не отвечаю). Стационарные клиенты и сервер будут иметь гораздо более свежие версии OpenVPN.
- Объем данных, который регулярно передается между стационарным и мобильным клиентом, довольно невелик (я ожидаю, что он будет меньше нескольких КиБ / с), однако со временем он может значительно увеличиться, в зависимости от того, какие дополнительные коммуникационные технологии мы будем использовать в будущем. .
После некоторого чтения и размышлений я пришел к мысли, что всем этим требованиям можно удовлетворить:
- Предоставление единого центрального сервера OpenVPN (с учетом использования решения на основе докеров, например https://github.com/kylemanna/docker-openvpn)
- Предоставление скриптовой инфраструктуры, в которой административный орган может запросить пару staionary cert / pk и mobile cert / pk, а также выполнить изменение конфигурации на сервере OpenVPN, который устанавливает некоторые конфигурации маршрутизации / IP на основе используемых общих имен.
- Предоставление возможности стационарным клиентам выбрать желаемую мобильную цель для подключения, просто подключившись к серверу с использованием определенной пары сертификат / пакет.
Звучит ли это как разумный механизм для удовлетворения требований? Если смотреть на подход с учетом масштабируемости и скорости, следует ли мне настраивать такие вещи или мне следует провести некоторое исследование альтернатив (даже других технологий, кроме OpenVPN?)
Спасибо за ваш вклад заранее
Извините, у меня нет времени полностью обдумывать ваш ответ (хотя спасибо за столь хорошо сформулированное объяснение, что редко для формата SO, я признаю), но вот список различных идей, с которыми вы, возможно, еще не знакомы, но которые могут вам помочь идти вперед:
- У вас может быть несколько экземпляров OpenVPN, работающих на одном сервере (на разных портах); это может обеспечить грубое разделение групп клиентов (и см. ниже Netfilter).
- Использовать топологию
subnet
для подключения ваших клиентов и размещения их в разных частных подсетях; у вас может быть любое количество частных сетей, которыми владеет экземпляр сервера OpenVPN. - включить
client-to-client
параметр в конфигурации сервера, чтобы клиенты могли взаимодействовать друг с другом в контексте одного экземпляра сервера OpenVPN. - Использовать
push "route <addr> <netmask>"
рассказать клиентам, которые Другой сети, к которым они могут подключиться через свое соединение OpenVPN (то есть сети, отличные от их "родных" - тех, к которым они подключаются при подключении); обратите внимание, что вам может потребоваться соответствие iroute
директивы в конфигурации OpenVPN. - Вы можете использовать клиентские фрагменты конфигурации через
client-config-dir
параметр (дублированный ccd
); это позволяет передавать определенные директивы маршрута конкретным клиентам, чтобы разные клиенты могли при необходимости подключаться к разным наборам сетей. - Когда вы завершите настройку OpenVPN, вы можете уточнить ее с помощью правил Netfilter (
iptables
), поскольку весь трафик, обрабатываемый OpenVPN, по-прежнему проходит через соответствующие таблицы FORWARD
chain, так что здесь вы можете контролировать, каким сетям, обслуживаемым OpenVPN, разрешено общаться друг с другом. - Также возможно, чтобы OpenVPN принимал одновременные подключения клиентов, представляющих сертификаты с одним и тем же общим именем (CN); это можно использовать в качестве последнего средства, чтобы одни и те же настройки применялись к разным клиентам (обычно через
ccd
упомянутый выше механизм). Подчеркну, что это крайняя мера, так как она исключает детальный отзыв доступа для отдельных клиентов.
Надеюсь это поможет!