VPN через UDP завмирає в простої: міжмережевий екран забув ваш потік

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

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

Як виглядає зупинка через простій

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

Обидва випадки пов'язані з простоєм, і їм потрібні різні виправлення.

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

Знайдіть пристрій, який забув

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

Не вважайте, що задокументоване значення за замовчуванням — це тайм-аут на вашому шляху. Це значення за замовчуванням одного пристрою.

• Домашній маршрутизатор: часто хвилини, іноді значно менше.
• Хмарний NAT або балансувальник навантаження: шукайте задокументований тайм-аут простою саме для UDP.
• Міжмережевий екран хоста: таймери відстеження netfilter діють для кожного потоку.

Перевірте таймери на реальному шляху

У Linux таймери відстеження netfilter видимі й налаштовні: sysctl net.netfilter.nf_conntrack_udp_timeout і net.netfilter.nf_conntrack_udp_timeout_stream. Другий діє, коли трафік уже видно в обох напрямках, тому встановлений тунель може пережити просту перевірку.

RFC 4787 описує поведінку UDP NAT і рекомендовані мінімуми. Це посилання, на яке варто спиратися, коли значення за замовчуванням у постачальника виглядає незвично коротким.

Keepalive і повторне підключення — різні інструменти

Keepalive підтримує зіставлення живим; повторне підключення заново будує мертвий сеанс. Вони вирішують різні збої і не є взаємозамінними налаштуваннями швидкості. Параметр PersistentKeepalive у WireGuard надсилає пакет із фіксованим інтервалом, щоб утримувати прив'язку NAT відкритою. Параметр keepalive в OpenVPN робить ту саму роботу по-своєму. Жоден не допоможе, якщо пристрій посередині вже забув потік і скидає обидва напрямки.

Занадто часті перевірки додають роботи, не виправляючи хибну межу.

Перевіряйте новим запитом, а не перезавантаженням сторінки

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

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