Чому тунель Azure OpenVPN обривається приблизно кожні шістдесят секунд

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

Прочитайте цей рядок, перш ніж торкатися будь-якого таймера.

Міф: щось на шляху блокує тунель

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

Ритм — корисна підказка. Його створюють таймери; втрата пакетів робить це рідко.

Прочитайте причину відключення раніше за таймер

OpenVPN називає свою причину, і кожне ім'я вказує на іншу підсистему. Session invalidated: KEEPALIVE_TIMEOUT — це таймер, що спливає, тому порівняйте значення ping і ping-restart на обох кінцях. AUTH_FAILED — це облікові дані або стан сертифіката, і жодна зміна таймера не допоможе. Помилка TLS означає, що сторони взагалі не дійшли до етапу keepalive.

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

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

Два таймери keepalive, які так і не домовилися

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

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

Мінімальна зміна на боці клієнта — обнулити таймери на верхньому рівні профілю, поза кожним вбудованим блоком:

keepalive 0 0

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

Ім'я сертифіката може зсунутися у вас під ногами

Автентифікація сертифікатом Azure залежить від того, чи довіряє клієнт імені, яке шлюз подає сьогодні. Рядок verify-x509-name у старішому завантаженні може закріпити ім'я, яке перебудова шлюзу або оновлення сертифіката відтоді змінили, і невідповідність проявляється як цикл перепідключення, а не як чітка помилка. Видалення рядка відновлює зв'язок, що робить його доброю діагностикою і поганим постійним виправленням, бо воно також прибирає перевірку. Коли тунель утримається, відновіть рядок з іменем, яке шлюз справді подає.

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

Що змінювати і в якому порядку

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

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

Налаштування шлюзу слід змінювати лише після цих чотирьох перевірок.