Чому ваш VPN відновлюється довше, ніж триває збій

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

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

Три очікування, які виглядають як одне

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

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

Який етап насправді повільний?

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

Класифікуйте збій, перш ніж торкатися числа.

Коли зниження таймера допомагає, а коли ні

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

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

Перевірте готовність, перш ніж звинувачувати клієнт

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

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

Що записувати

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

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