Чому VPN під час повторного підключення знову запитує облікові дані
Збережений пароль і багаторазовий токен спливають за різними розкладами. Прочитайте, який матеріал запитало повторне підключення, перш ніж щось змінювати на клієнті.
Тунель, що працював годинами, запитує пароль у ту мить, коли ноутбук прокидається, і в конфігурації нічого не змінилося. Змінився стан облікових даних, які повторне підключення намагалося використати повторно. Цим керують три види матеріалу, і лише один із них переживає довільну перерву.
Прочитайте, який із них запитав клієнт, бо всі три спливають за різними годинниками й відмовляють із різними повідомленнями.
Три види багаторазового матеріалу
Кешований пароль — це секрет, який зберігає клієнт, і він залишається дійсним, доки обліковий запис його не змінить. Токен сеансу видає сервер після успішного входу, він має власний термін життя і може бути відкликаний у будь-який момент. Квиток сеансу TLS або асоціація безпеки IKE — це стан протоколу, дешевий для поновлення й повністю незалежний від вашого пароля. Кожен видається окремим компонентом, і кожен спливає на своїх умовах.
Перший переживає перезавантаження, другий зазвичай переживає сон, а третій може взагалі не пережити зміну мережі. Їхнє змішування дає неправильне рішення, наприклад скидання пароля, який ніколи не відхилявся.
Сам запит — це діагностика. Вікно браузера або код другого фактора означають, що сервер вимагав інтерактивну автентифікацію, тоді як тиха відмова без запиту означає, що клієнт не дійшов до моменту, коли його запитують.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Оновлення ключів — не повторна автентифікація
Оновлення ключів замінює ключі, зберігаючи автентифіковану особу, тому на здоровому тунелі воно час від часу відбувається тихо. Повторна автентифікація знову проводить саму перевірку особи, і саме ця подія потребує вас. IKEv2 явно розділяє ці дві речі, і партнер може вимагати повної повторної автентифікації через заданий інтервал незалежно від того, скільки оновлень ключів сталося між ними. Ззовні обидві події виглядають однаково, доки не прочитаєш, яку з них називає журнал.
OpenVPN поводиться так само у своїй термінології: інтервал повторних перемовин освіжає канал даних, а токен автентифікації можна повернути клієнтові, щоб уникнути повного входу під час наступного з'єднання. Цей токен має термін, і сервер вирішує, чи приймати його знову.
Тож повторне підключення через вісім годин може не вдатися там, де повторне підключення через вісім хвилин удалося, без жодних змін конфігурації з обох боків. Це все пояснення запиту, який з'являється лише після обіду.
Коли клієнт не може завершити новий виклик
Політика, що вимагає кроку в браузері, не спрацює на клієнті, який не має способу його показати. Сервери без графічного інтерфейсу, скрипти запуску та старі профілі, створені для автентифікації лише паролем, усі впираються в цю стіну, і збій часто виглядає як загальний тайм-аут, а не як помилка автентифікації.
Переходи між пристроями й мережами теж можуть потрапити у вікно оцінювання політики, тому перехід із Wi-Fi на точку доступу збігається з перевіркою, яка відбулася б у будь-якому разі. Цей збіг робить мережу винною, коли причина — таймер.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Перший рядок показує події повторних перемовин і автентифікації у власному журналі клієнта, а другий показує асоціації безпеки, які партнер strongSwan зараз тримає. Порівняйте позначки часу з моментом появи запиту; збіг підтверджує таймер, а не мережу.
Що повідомляти і що не вимикати
Якщо ручний вхід вдається, а автоматичне повторне використання стабільно не вдається, скажіть це оператору саме так. Це називає компонент: шлях повторного використання, а не облікові дані. Додайте час збою, використовуваний обліковий запис і тип запиту, який ви бачили.
Не вимикайте другий фактор, не пропускайте перевірку сертифіката і не вставляйте облікові дані в скрипт, щоб підключення відбувалося тихо. Кожне з цього прибирає перевірку, для якої існує політика, і кожне перетворює запит входу на інцидент.
Натомість попросіть підтримуваний сценарій: клієнт, здатний пройти виклик, термін життя токена, що відповідає робочому дню, або затверджений неінтерактивний профіль для машини, яка не може запитати. Усе це рішення конфігурації, які хтось може схвалити, а обхідний шлях — ні.