Может ли соединение OpenVPN со статическим ключом обслуживать несколько клиентов?

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

Два узла, один ключ и никакого состояния на клиента: эта форма — вся история режима.

Для чего нужен режим статического ключа

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

Режим остаётся полезным для фиксированной пары машин с документированным процессом ротации ключа, и OpenVPN 2.6 помечает его устаревшим именно потому, что режим TLS покрывает эти случаи с лучшими свойствами. Чего он не может — отличить одно подключающееся устройство от другого, поскольку владение файлом и есть вся история аутентификации. Добавление третьего устройства означает совместное использование с ним того же ключа, после чего первые два уже не могут отличить его от себя.

Поэтому ограничение в два узла структурное, а не настройка, которую можно изменить.

Почему client-to-client не является недостающей частью

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

Другое распространённое заблуждение касается материала tls-crypt или tls-auth. Сервер TLS может совместно использовать один из этих ключей для всех клиентов, потому что он защищает канал управления, а не доказывает, кто есть каждый клиент. Общий ключ канала управления в режиме TLS — это другой объект, чем общий статический ключ данных, хотя оба поступают как похожие на вид файлы.

Выбор между режимами сводится к двум вопросам. Должно ли более одного устройства подключаться независимо, и нужно ли развёртыванию отзывать доступ для каждого устройства? Ответ нет на оба оставляет режим статического ключа жизнеспособным; ответ да на любой из них указывает на TLS. Нет третьего варианта, где второй клиент допускается без собственной идентичности.

Построение сервера для нескольких клиентов

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

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

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

Затем осознанно решите политику перенаправления. client-to-client включает трафик между клиентами на серверном пути в пользовательском пространстве, чего хотят многие развёртывания, а некоторые не должны иметь. Это переключатель политики, а не механизм идентичности, и его следует включать потому, что этого требует схема, а не потому, что его включило руководство.

Проверка того, что клиенты действительно независимы

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

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

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

Если журнал показывает одно общее имя для каждого устройства, проблема не в режиме. Проблема в процессе регистрации.