VPN падає після оновлення DHCP? Порівняйте адреси

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

Почніть із клієнта, який відпав

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

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

Порівняйте чотири значення навколо події

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

Що оновлення може і чого не може змінити

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

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

Коли клієнт не може адаптуватися

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

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

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

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

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