☰

Лучшие практики по настройке нескольких экземпляров OpenVPN для разных клиентов

tag-icon • tag-icon linux vpn openvpn pki
Лучшие практики по настройке нескольких экземпляров OpenVPN для разных клиентов

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

Для обработки сертификатов я рассматриваю следующую структуру:

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

Итак, я бы настроил отдельный экземпляр OpenVPN для каждого клиента, например /etc/openvpn/server/Client1/и /etc/openvpn/server/Client2/, и запустил бы их с помощью таких команд:

sudo systemctl start [email protected] Приемлем ли такой подход? Буду признателен за любые идеи или альтернативные предложения по организации инфраструктуры для нескольких VPN-клиентов и серверов.

Дополнительные вопросы:

  • Как управлять большим количеством децентрализованных устройств, может быть, Ansible?
  • Для каждого экземпляра OpenVPN мне нужен дополнительный порт.
    • Что происходит дальше после использования 443 TCP,UDP и 1194 TCP,UDP?

Спасибо!

решение1

Руководство OpenVPN утверждает, что оно будет доверять любому сертификату, который является потомком сертификата CA, который вы в нем настроили. Поэтому, чтобы действительно разделить VPN, вы исключаете корневой сертификат из всех конфигураций. Он нигде не будет использоваться, не добавляет никакой ценности или выгоды, так зачем беспокоиться о его поддержке? Просто возьмите EasyRSA и создайте отдельный и независимый «корневой, одноуровневый» CA для каждого VPN.

Я не знаю, почему вы указали здесь порт 443; он редко используется для OpenVPN, потому что это известный порт HTTPS, который часто занят, поэтому, когда он используется, часто возникают сложные конфигурации, включающие port-share. В этом случае sslhон лучше, по крайней мере, потому что вы можете использовать его «прозрачный режим» для демонов, чтобы видеть реальный IP-адрес удаленного устройства и не беспокоиться о том, как OpenVPN делает эту информацию доступной. Хотя я сомневаюсь, что вам нужна эта особенность для вашего проекта. Кроме этого, вы действительно можете использовать произвольные номера портов. 1194 указан как «официальный», но ничто не запрещает вам установить 11941 или 1195 или 5000 (что было предложено пятнадцать лет назад) или что-нибудь еще. Выберите набор портов, скажем, начиная с 1194 и выше, и просто добавляйте по одному для каждого последующего экземпляра VPN.

Остальное верно: вы используете отдельные (публичные) порты для независимых демонов и запускаете их как отдельные единицы SystemD. Рассмотрите отдельные контейнеры для разных VPN: хотя можно запускать отдельные экземпляры VPN в одном пространстве имен, проще и менее подвержено ошибкам просто разделить их (и не намного больше потребляет ресурсов). Как я понял, ваши клиенты — это не связанные между собой сущности, поэтому это будет более простым способом их разделения. В этом случае конфигурации VPN внутри контейнеров могут использовать порт по умолчанию, но вы будете пересылать (публиковать) для них разные порты.

Назначьте какую-нибудь систему исключительно для управления VPN; она будет хранить ваши CA, и только она может, следовательно, выдавать сертификаты. Эта система также понадобится для выдачи CRL; по умолчанию CRL существуют в течение 30 дней, и если вы настроите crl-verify(вы это сделаете!), когда срок действия CRL истечет, VPN прекратит принимать новые соединения, пока он снова не станет действительным. Так что вам действительно нужно автоматизировать повторную выдачу и распространение CRL. При обновлении файла CRL вам не нужно перезагружать демон, scpдостаточно простого переноса старого файла в целевую систему.

Полезно создать шаблон файла конфигурации клиента OpenVPN и сгенерировать клиентские конфигурации со встроенными сертификатами из этого шаблона; это сэкономило мне много времени даже без Ansible. Я часто настраиваю bundled openssl.cnfи varsфайлы, чтобы добавить несколько полей и удалить неиспользуемые, а также реорганизовать вещи и чтобы они работали с меньшим количеством вопросов (или без вопросов, для пакетной обработки). В вашем случае может быть полезно иметь такие шаблоны и сценарии генерации для создания новых VPN и конфигураций серверов. Такие шаблоны, сценарии и настройки будут полезны для плейбуков Ansible, которые создают экземпляр нового клиента или нового устройства IoT существующего клиента. Для последнего может быть неплохо привязать CN сертификата к серийному номеру устройства IoT, что должно упростить учет.

Связанный контент