Механизм штатного закрытия сессий IKE и уведомление IKE_DELETE

В спецификациях RFC 7296 (IKEv2) и RFC 2409 (IKEv1) для корректного освобождения ресурсов операционной системы предусмотрена отправка служебной информационной полезной нагрузки Delete Payload (IKE_DELETE). Когда удаленный пир (Remote Peer) решает уничтожить конкретную дочернюю ассоциацию (Child SA) или полностью закрыть сессию управления (IKE SA), он отправляет подписанное зашифрованное уведомление и локально удаляет ключи. Локальный шлюз фиксирует событие PEER_INITIATED_DELETE (Remote peer sent IKE_DELETE payload), корректно очищает таблицы SA в ядре и прекращает шифрование трафика.

Бизнес-риски

Внезапный разрыв туннелей без явных локальных ошибок, деградация сетевых сервисов компании, «плавающие» проблемы со связью при перезагрузках партнерских маршрутизаторов.

Типовые триггеры генерации IKE_DELETE со стороны удаленного узла

Алгоритм расследования причин закрытия туннеля удаленным узлом

Сценарий 1: Проверка штатной ротации ключей (Отличие аварии от нормы)

Если событие PEER_INITIATED_DELETE возникает регулярно (например, раз в 8 часов), но связь не прерывается — это штатное удаление старой Child SA после успешного создания новой:

# Анализ логов strongSwan (Штатное удаление старого SPI)
# [IKE] received DELETE for ESP CHILD_SA with SPI c0a80101
# [IKE] closing CHILD_SA with SPI c0a80101 (successful rekeying cleanup) -> НОРМА

Сценарий 2: Анализ логов на удаленном шлюзе (Remote Diagnostics)

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

1. Подключитесь к удаленному маршрутизатору (Cisco / MikroTik / Linux).
2. Проверьте журнал событий на предмет сбоев питания, срабатывания сторожевых таймеров Watchdog или падения интерфейса WAN.
3. Проверьте статус Dead Peer Detection (DPD): не фиксирует ли удаленный узел потерю связи перед отправкой Delete.

Сценарий 3: Настройка автоматического переподключения (Auto-Restart / Start-Action)

Чтобы локальный узел не ожидал внешнего входящего подключения после получения Delete, настройте политику автоматической инициализации туннеля (Trap / Start):

# Настройка политики auto-restart на strongSwan (/etc/swanctl/swanctl.conf)
connections {
   site-a {
      start_action = trap # Автоматический подъем туннеля при появлении трафика
      dpd_action = restart # Принудительный перезапуск при сбросе пира
   }
}

Типовые ошибки администраторов

• Паника при обнаружении одиночных Delete-пакетов в debug-логах: Попытка перезапускать работоспособные туннели, принимая штатные пакеты закрытия отработавших SPI за системную аварию.
• Отключение реакции на Delete-сообщения: Приводит к накоплению «зомби-ассоциаций» (Ghost SAs), которые продолжают шифровать трафик ключами, уже удаленными на противоположной стороне.