Публічний IP змінився, і VPN перестав пропускати трафік

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

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

Яка адреса насправді змінилася

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

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

Нехай протокол сам дає раду переміщенню

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

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Очистіть застаріле зовнішнє прив’язування

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

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

Перевірте знову новим запитом

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

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

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