duplicate-cn даёт двум устройствам одну личность, а не две

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

Миф: вторая сессия — это вторая личность

Интуиция подсказывает, что два подключения должны быть двумя клиентами, а два клиента — двумя устройствами со своими правами. Сервер моделирует это иначе. Он видит общее имя и при включённом duplicate-cn принимает больше одной живой сессии с этим именем, и каждая получает собственное состояние сессии в демоне.

Это принятие никак не затрагивает проверку сертификата. Тот же сертификат остаётся учётными данными, тот же ключ остаётся закрытым ключом, и любая политика, привязанная к субъекту сертификата, по-прежнему дважды разрешается в одно и то же значение. Вторая сессия — это второй сокет, а не вторая личность.

Это различие незаметно, пока всё работает. Оно становится очень заметным в тот момент, когда нужно различить два устройства, — и обычно это день, когда одно из них теряется.

Что действительно меняется, когда две сессии делят одно имя

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

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

Проверьте, что именно делает ваша сборка, прежде чем проектировать вокруг этого, потому что эффект опции определяется самой опцией, а не преданиями:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

Статический адрес, который вы якобы назначили

Конфигурация для каждого клиента ищется по имени, и вот здесь ловушка. Файл client-config-dir, названный по общему имени применяется к каждому устройству с этим именем, поэтому ifconfig-push внутри него выдаёт обоим устройствам одинаковый адрес туннеля. Вторая сессия либо не устанавливается, либо конфликтует так, что это похоже на сбой маршрутизации.

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

Если развёртывание использует username-as-common-name, ключом поиска становится аутентифицированное имя пользователя вместо субъекта сертификата, и тот же конфликт повторяется у любого, кто входит дважды. Имя, управляющее конфигурацией, должно быть уникальным для каждого устройства, иначе конфигурация для каждого устройства ничего не значит.

Чего общая личность не может сделать при удалении

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

Журналы наследуют ту же неоднозначность. Вывод состояния показывает общее имя и реальный адрес, и оба могут принадлежать любому из двух устройств. Разбор инцидента, которому нужно знать, какая машина что сделала, не может ответить на этот вопрос по собственным записям VPN, сколько бы подробностей ни давал уровень журналирования.

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

Когда совместное использование уместно и как его ограничить

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

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

Какой бы путь вы ни выбрали, проверяйте модель управления, а не вход. Подключите оба устройства, убедитесь, что у них разные адреса, затем смоделируйте потерю и проверьте, что можете удалить ровно одно из них. Руководство openvpn(8) определяет область действия опции; ваша процедура удаления определяет, действительно ли совместное использование приемлемо.