strongSwan остаётся выключенным после перезагрузки peer: восстановить один туннель

Откажитесь от перезапуска демона. Перенесите инициирование и DPD на соединение, которое должно вернуться, затем проверьте по имени и докажите службу, а не демон.

Удалённый шлюз перезагружается, возвращается в течение минуты, а локальный демон strongSwan продолжает работать, пока туннель остаётся выключенным. Задача cron, которая ищет ESTABLISHED и перезапускает демон, в конце концов замаскирует это, а также прервёт каждый посторонний туннель на машине, возможно пропустив тот, который отказал. Восстановление принадлежит соединению, которое должно вернуться, и выражается в настройках, переживающих перезагрузку. Этот runbook настраивает это для одного соединения и доказывает результат по имени.

Откажитесь от глобального перезапуска, сохраните его доказательства

У перезапуска демона два конкретных недостатка: он уничтожает состояние каждого соединения и ничего не говорит о том, какое событие на самом деле отказало. Текст статуса, который вы искали, мог прийти от другого соединения, а нужный child простаивал, потому что ничто его не запустило.

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

swanctl --list-conns
swanctl --list-sas

Перенесите инициирование и повторы на возвращающееся соединение

В развёртывании swanctl.conf эти настройки живут на уровне соединения и child, а не в глобальной политике. Фрагмент ниже — пример со стороны инициатора, который предполагает, что предложения, аутентификация и селекторы уже корректны.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action решает, что происходит при загрузке child: start инициирует немедленно, а trap устанавливает политику, которая запускает инициирование при появлении подходящего трафика. Запись trap|start требует strongSwan 5.9.6 или новее, поэтому проверьте версию перед копированием строки. dpd_action=restart запрашивает новые переговоры, как только peer объявлен мёртвым, а keyingtries=0 на уровне соединения разрешает дополнительные попытки до успеха или постоянной ошибки. В IKEv2 dpd_timeout не имеет никакого эффекта, потому что обычная повторная передача решает, когда peer не отвечает.

Задержка в этом примере — отправная точка, а не универсальный срок. Выбирайте её исходя из того, сколько длится перезагрузка peer и сколько повторных передач вы готовы вытерпеть.

Знайте, от какого события вы восстанавливаетесь

Три сбоя выглядят одинаково на панели и требуют разных настроек. Первоначальное соединение, которое так и не поднялось, — это проблема конфигурации или доступности. Peer, переставший отвечать, — это случай DPD. Child, который peer явно закрыл, — это событие политики с собственным close_action, которое DPD никогда не замечает. Чтение журнала вокруг сбоя подскажет, какой из трёх у вас, и ответ меняет исправление.

Не добавляйте агрессивное повторное инициирование соединению, которое операторы намеренно закрывают на обслуживание, иначе туннель появится снова посреди окна. Для схем по требованию достаточно сохранённого trap, потому что подходящий трафик восстанавливает child без какого-либо таймера.

Проверяйте по имени, а не по статусу демона

Прочитайте соединение и его child по имени, пока peer ещё выключен, а затем снова, когда он вернётся; разница между этими двумя выводами и есть доказательство.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Затем подтвердите службу, а не ассоциацию. Свежая ассоциация безопасности child плюс успешный запрос к частному назначению за ней — это та пара фактов, которая имеет значение, а работающий демон со здоровым посторонним туннелем не доказывает ни одного из них.

Если child никогда не инициирует, проверьте, что тестовый трафик точно соответствует настроенным селекторам, включая протокол и порт. Если он инициирует и терпит неудачу, прочитайте ошибку аутентификации или предложения вместо того, чтобы прятать её за бесконечным циклом, потому что keyingtries=0 с удовольствием повторит постоянный отказ навсегда.

Загрузите изменение в окно обслуживания и повторите тест

Перезагрузка безопаснее перезапуска демона, и всё же она не бесплатна: замена или выгрузка child может закрыть запущенную ассоциацию или сбросить его trap.

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

swanctl --load-conns
swanctl --list-conns

Откатитесь, восстановив предыдущий файл и загрузив его снова, затем повторите те же две команды. Туннель, который возвращается только после перезапуска демона, не отремонтирован, а сброшен.

Похожие статьи