OpenVPN пізніше скидає сеанс OTP: що потрібно повторній автентифікації

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

Рішення — це вибір того, що має пред'явити друге рукостискання, а не довший таймер повторних спроб.

Пройдіть обмін з погляду клієнта

Під час входу клієнт надсилає ім'я користувача, пароль і код із токен-пристрою, і сервер приймає цю комбінацію. Далі сеанс триває, доки не спрацює тригер переузгодження, який запускає нове рукостискання TLS у наявному тунелі. Це рукостискання знову запитує автентифікацію. Якщо шлях автентифікації на сервері очікує пароль і поточний одноразовий код, клієнтові нема чого пред'явити, якщо користувач не присутній і не вводить код.

Більшість клієнтів не відкривають запит посеред сеансу, тож рукостискання завершується за тайм-аутом, а тунель падає. Користувач бачить перепідключення, а не запит автентифікації, тому в першому звіті зазвичай звинувачують мережу.

auth-gen-token змінює того, хто відповідає на друге питання

Параметр auth-gen-token дозволяє серверу видати токен після успішного входу, і подальші переузгодження пред'являють цей токен замість повторення пароля та коду. У посібнику описано його строк життя та поведінку під час поновлення, і токен слід розглядати як облікові дані з власним строком дії. На шляху за замовчуванням сервер сам перевіряє токен, а не викликає повторно зовнішній автентифікатор паролів.

З інтеграцією зовнішньої автентифікації цей поділ змінюється. Плагіну потрібно розуміти стан токена й застосовувати власні перевірки, бо сервер більше не єдиний компонент, що вирішує, чи триватиме сеанс. Ставитися до токена як до ще одного числового одноразового коду — це не реалізація цієї функції.

Вирішіть, що відбувається зі статусом облікового запису

Токен, який живе довше за доступ облікового запису, — це діра в політиці. Вирішіть, як вимкнений обліковий запис, вилучено членство в групі або відкликано пристрій діють, поки токен ще чинний. Короткий строк життя токена звужує вікно; явний шлях відкликання робить його навмисним. Запишіть відповідь до ввімкнення параметра, бо шлях за замовчуванням не звертається до зовнішнього автентифікатора під час кожного переузгодження.

У розгортанні з кількома серверами секрет підпису токена має бути спільним, інакше клієнт може потрапити на вузол, який не може перевірити його токен.

Перевіряйте закінчення строку та перепідключення, а не лише вхід

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

Видалення облікового запису перевіряйте останнім. Цей випадок показує, чи виконується написана вами політика, чи вона лише задокументована.

Не виправляйте це вимкненням поновлення

Установлення інтервалу переузгодження на нуль на обох вузлах прибирає симптом і разом із ним ротацію ключів. Це ховає проблему повторного використання облікових даних за зміною політики, яку ніхто не переглядав. Збережіть поновлення і вибирайте між токеном, який видає сервер, і новим інтерактивним викликом залежно від того, чи присутній користувач.

Довший таймер повторних спроб не робить використаний код знову чинним. Він лише відсуває розрив і ускладнює читання журналу.