Виявлення мертвого піра IKEv2 не перевіряє ваш застосунок

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

Прочитайте два види доказів окремо, перш ніж змінювати таймер.

Про що насправді питає перевірка живучості

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

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

Прочитайте асоціації безпеки до браузера

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

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

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

Відмова маршруту виглядає точно як мертвий пір

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

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

Тримайте таймери поза діагностикою

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

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

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