Чому ваш VPN відвалюється при кожній зміні ключів

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

Читайте етап, а не мітку

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

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

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

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

Порівняйте пропозицію, яка зривається

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

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

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

Відокремте проблему облікових даних від недоступного партнера

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

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

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

Примусово викличте одне поновлення й прочитайте результат

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

Коли виправлення на місці, перевірте поновлений тунель і потім зробіть новий запит із застосунку. Сеансу застосунку, який був живий під час зміни асоціації, може знадобитися власне відновлення, навіть якщо тунель знову здоровий. Користувачі повідомлять про це як про все ще зламаний VPN.

Запишіть версії випуску, узгоджені таймери та етап, який зірвався. Наступне повторення тоді можна буде порівняти з цим, а не описувати знову з пам'яті.