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) визначає межі дії опції; ваша процедура видалення визначає, чи справді прийнятне спільне використання.