IP-адреса WAN змінилася, а тунель упав: перевірки по порядку

Тунель падає, маршрутизатор фіксує перепідключення, а в локальній мережі нічого не зрушило. Нова адреса WAN робить зовнішнє з'єднання недійсним, нічого не змінюючи всередині: адреса джерела клієнта змінилася, старий стан NAT указує на джерело, якого більше немає, а віддалений пір може досі надсилати на попередню адресу. Відновлення — звичайна поведінка, і корисне питання в тому, який стан не оновився.

Назвіть подію, перш ніж читати журнал

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

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

Роумінг і перепідключення — різні протоколи

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

OpenVPN типово поводиться інакше. Сеанс UDP може завершитися й перепідключитися, а необов'язкова поведінка float дозволяє автентифікованому піру продовжити з нової адреси там, де це дозволяє конфігурація. Тунелі на основі TCP суворіші, бо саме з'єднання прив'язане до пари адрес. Ця різниця вирішує, чи виглядатиме відновлення непомітним, чи щоразу оголошуватиме себе в журналі.

Жодна з поведінок нічого не каже про застосунки всередині. Відновлений тунель не відновлює сеанс TCP, який пір уже вважав мертвим.

Стан, яким тунель не володіє

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

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

Упорядкуйте перевірки ззовні всередину

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

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

Визначте очікувану поведінку і запишіть її

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

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