Руководство: отдельное подключение двух клиентов OpenVPN

Два клиента на одном хосте звучат как ещё один серверный блок и второй порт. Это становится другим проектом, как только вы перечислите всё, чем клиент действительно владеет: слушатель, пул туннелей, идентичность, файлы доверия, маршруты и график отзыва. Пропустите одно из этого — и второй клиент тихо унаследует часть первого. Создайте карточку для каждого клиента и заполните её до первого подключения клиента.

Назначьте каждому клиенту полную карточку ресурсов

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

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

Держите материал доверия внутри каждого клиента

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

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

Разделите сети так же, как процессы

Два процесса на двух портах по-прежнему делят хост и таблицу маршрутизации, если вы их не разделите. Подтвердите, что слушает, прежде чем доверять схеме.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

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

Доставьте отзыв до передачи

Развёртывание сертификатов не завершено, пока у отзыва нет пути доставки. Проверьте издателя CRL и окно действия как часть подключения.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

Проверка CRL сообщает, когда список был выпущен и когда истекает, а состояние службы подтверждает, что экземпляр, читающий его, работает. Обновляйте список по графику политики выпуска, даже когда ничего нового не отозвано, потому что просроченный CRL может отклонить каждого клиента. Публикуйте полный файл, а не оставляйте читателям частичную запись, и проверяйте подпись перед развёртыванием. Зафиксируйте, кому принадлежат выпуск, эксплуатация конечной точки и вывод из эксплуатации, чтобы отключение клиента A не мешало B.

Затем запустите приёмочную пару: разрешённый клиент достигает своей службы, а учётные данные A отклоняются слушателем B. Это граница, выраженная как тест.