WireGuard збоїть після простою: спершу перевірте напрямок

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

Який напрямок збоїть?

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

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

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

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

Сон, радіо й стан застосунку

На телефоні або ноутбуці сплячий пристрій міг повністю втратити мережевий доступ, а keepalive не може відновити вимкнене радіо чи завершити незадоволений captive portal. Мобільні платформи призупиняють фонову роботу за політикою, тож чи продовжиться періодичний трафік, залежить від платформи й від того, про що застосунок із нею домовився. Кешоване з’єднання — третій випадок і найбільш оманливий, бо повернення тунелю не те саме, що повторне підключення застосунку до нього.

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

Що насправді робить keepalive

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

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

Зачекайте інтервал, який раніше збоїв

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

Тримайте одну зміну на тест і записуйте використану тривалість простою. Без цього кожне подальше порівняння пливе, і ніхто не може сказати, яка зміна мала значення. Запишіть чотири факти разом: напрямок, тривалість, стан сну й поведінку застосунку.