Azure VPN Client 3.4 відключається щогодини: частота входу

Один користувач підключається, працює, а потім щогодини його відключають із повідомленням про закінчення строку перевірки дійсності в Microsoft Entra. Повторне підключення працює, і цикл повторюється як за секундоміром. На шлюзі типу «точка — сайт», де нічого не розгорнуто, така схема вказує на облікові дані, а не на тунель. Azure VPN Client 3.4.0 почав застосовувати частоту входу умовного доступу під час уже встановленого сеансу — політику, яку попередні клієнти оцінювали лише під час входу.

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

Крок 1: прочитайте точне повідомлення

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

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

Крок 2: з'ясуйте версію клієнта

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

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

Крок 3: знайдіть, де мешкає політика

Частота входу — це налаштування умовного доступу в політиці, спрямованій на корпоративний додаток Azure VPN. Вона не на ресурсі шлюза VPN, не в конфігурації «точка — сайт» і не в профілі клієнта. Знайдіть додаток Azure VPN у списку політик і прочитайте керування сеансами.

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

Крок 4: порахуйте

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

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

Крок 5: відокремте розклад від rekey

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

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

Крок 6: розгорніть без сюрпризів

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

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