Таймер сеансу VPN і токен автентифікації спливають окремо

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

Проти одного тунелю йдуть троє годинників, і лише один із них — сам тунель.

Троє різних годинників на одному тунелі

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

Лише перший є поняттям VPN. Решта двоє запозичені з ідентичності та мереж, і їх регулярно плутають із ним.

Як токен насправді використовується повторно

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

Інтервал повторного узгодження — окремий параметр. Його зміна зсуває момент пред'явлення токена, а не тривалість його життя.

Як виглядає кожне спливання з боку клієнта

Тайм-аут сеансу зазвичай приходить як чисте відключення з причиною на боці сервера, часто після передбачуваної тривалості й без помилки автентифікації. Тайм-аут простою виглядає як тиша: тунель перестає нести трафік, потім механізм підтримання зв'язку здається. Спливання токена приходить як AUTH_FAILED посеред сеансу, який працював секунду тому.

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

Чому збережений пароль не допомагає

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

Стійкі виправлення — це правильний термін життя на правильному об'єкті, або клієнтський потік, здатний виконати потрібний запит без людини.

Що документувати й перевіряти

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

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