Перемагає перша сесія: обмеження входів OpenVPN до витіснення
Відхилити пізніший вхід — не те саме, що замінити старий. Рішення має ухвалюватися до витіснення однойменної сесії, а перевірка слота має бути атомарною.
Політика, що дозволяє одну сесію на обліковий запис, здається вирішеною, доки не надійде другий вхід. Можливі два результати: новий клієнт замінює поточну сесію або поточна сесія зберігає слот, а новому відмовляють. Лише другий варіант - це політика, де перемагає перша сесія. Клієнтська опція, до якої вдається більшість, вмикає паралельність і тому такого результату не дає.
За одним налаштуванням ховаються два договори
Коли паралельність вимкнена, друге з'єднання з тим самим ім'ям сертифіката може витіснити вже робочу сесію. Увімкнення паралельності дозволяє кілька сесій одночасно, що є протилежністю обмеженню. Жоден зі станів не є політикою відмови, тож рішення треба ухвалювати зовсім в іншому місці.
Запишіть договір до того, як щось упроваджувати: кому відмовляють, які докази ідентифікують поточну сесію і що відбувається, коли сесія помирає без чистого від'єднання. Політику, яку ніхто так не сформулював, згодом неможливо перевірити.
Витіснення відбувається до вашого хука підключення
У кодовому шляху сервера 2.6 рання підготовка нового клієнта видаляє наявні екземпляри з тим самим ім'ям, коли паралельність вимкнена. Це видалення відбувається до запуску ланцюжка обробників підключення. Тому скрипт, який помічає дублікат і повертає помилку, відхиляє нового вже після того, як поточну сесію скинули, - саме той результат, який політика мала відвернути. Порядок зворотних викликів в upstream-реалізації - єдина надійна відповідь для вашої збірки.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
Опитування файлу стану теж не є воротами. Дві спроби, що надійшли одночасно, можуть обидві побачити порожній слот до того, як якась його підтвердить, і обидві продовжаться.
Перенесіть рішення в автентифікацію
Інтерфейс керування може взяти на себе рішення про автентифікацію після перевірки сертифіката. У такій схемі контролер не спостерігач: він отримує кожен екземпляр клієнта, що підключається, і відповідає, чи можна цьому екземпляру продовжувати. Оскільки відповідь надходить до встановлення, відмова залишає поточну сесію недоторканою. Той самий канал повідомляє про від'єднання, і так контролер дізнається, що слот було звільнено законно.
Кожен новий екземпляр має пройти ці ворота, включно з повторними підключеннями й будь-яким шляхом, що повторно автентифікується без запиту. Ворота, до яких деякі екземпляри ніколи не доходять, нічого не захищають, і цей пропуск залишається непомітним, доки хтось не спробує обхід.
Токени можуть пройти повз ворота
Після видачі токена сервер може перевірити його внутрішньо й пропустити зовнішню автентифікацію для цього з'єднання. Виклик керування ніколи не відбувається, тож перевірка слота, реалізована лише там, ніколи не бачить нового екземпляра. Така поведінка - зручність для користувачів і діра в політиці паралельності. Змусьте з'єднання з токеном проходити еквівалентну авторитетну перевірку або вимкніть шлях токена, коли політика вимагає рішення щодо кожного з'єднання.
Не компенсуйте це безумовним прийняттям кожного токена. Прострочений або недійсний токен усе одно має зазнавати невдачі, і він має зазнавати невдачі через ту саму точку рішення, що й усе інше.
Прив'яжіть резервування до екземпляра, а не до адреси
Адреса - слабка ідентичність: повторне підключення з того самого ноутбука може прийти з іншої адреси, а скопійовані облікові дані - з тієї самої. Прив'яжіть резервування до екземпляра клієнта, який призначає сервер, щоб повторна автентифікація вже допущеного екземпляра розпізнавалася як власник. Новий ідентифікатор екземпляра має отримати свій слот через рішення перемагає перший, навіть коли він пред'являє той самий токен.
Звільняйте лише резервування, що належить невдалій спробі. Запізніла подія від'єднання від старішої спроби не повинна очищати слот новішого власника, тому звільнення називає екземпляр, а не обліковий запис. Після перезапуску контролера узгодьте живі сесії, перш ніж когось допускати, і застосовуйте те саме правило на кожному шлюзі, що обслуговує обліковий запис.
Окремо вирішіть, як відновлюється справді застарілий слот. Адміністратору потрібен задокументований спосіб очистити його, і цей шлях не має бути доступним користувачеві, який просто натискає перепідключитися.
Перевірте важливі пари: два майже одночасні входи, повторне підключення після чистого завершення, повторну автентифікацію поточної сесії, відхиленого новачка й перезапуск контролера. У кожному разі поточна сесія має залишатися придатною, а новачкові треба відмовити без побічної шкоди для інших облікових записів.