SystemdDoctor
служба не работает vpn сеть права

Служба IPsec запускается, а туннели не поднимаются

Туннель IPsec требует двух согласований подряд, и отказ на любом шаге выглядит одинаково снаружи: служба работает, туннеля нет. Разбор строится по журналу согласования, а не по состоянию службы.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Служебные порты закрыты

    Согласование идёт по двум портам, а сам трафик — отдельным протоколом. Брандмауэр по умолчанию не пропускает ни то, ни другое.

  2. Параметры шифрования не совпадают

    Стороны не находят общего набора. В журнале это видно как отказ на первой фазе согласования.

  3. Нет доступа к файлам ключей

    Служба работает от своего пользователя, а закрытые ключи часто лежат с правами только для root.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Журнал согласования: на каком шаге отказ.

sudo journalctl -u strongswan -u ipsec -n 40 --no-pager 2>/dev/null

Установленные соединения и их состояние.

sudo swanctl --list-sas 2>/dev/null

Слушает ли служба служебные порты.

sudo ss -ulnp | grep -E ":500|:4500"

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Служебные порты закрыты
Почему происходит
Согласование идёт по двум портам, а сам трафик — отдельным протоколом. Брандмауэр по умолчанию не пропускает ни то, ни другое.
Как проверить
Посмотрите правила и попытки согласования. 
sudo ss -ulnp | grep -E ":500|:4500"
sudo journalctl -u strongswan -u ipsec -n 30 --no-pager 2>/dev/null | grep -iE "IKE|retransmit"
Как исправить
Разрешите порты согласования и протокол шифрованного трафика. При прохождении через преобразование адресов нужен второй порт согласования.
2. Параметры шифрования не совпадают
Почему происходит
Стороны не находят общего набора. В журнале это видно как отказ на первой фазе согласования.
Как проверить
Посмотрите предложенные и принятые наборы. 
sudo journalctl -u strongswan -n 40 --no-pager 2>/dev/null | grep -iE "no proposal|selected proposal"
Как исправить
Приведите наборы шифрования в соответствие с другой стороной. Списки должны пересекаться хотя бы в одном варианте.
3. Нет доступа к файлам ключей
Почему происходит
Служба работает от своего пользователя, а закрытые ключи часто лежат с правами только для root.
Как проверить
Посмотрите права на ключи и пользователя службы. 
sudo ls -l /etc/ipsec.d/private/ 2>/dev/null
systemctl show strongswan -p User -p LoadCredential 2>/dev/null
Как исправить
Передайте ключи пользователю службы или подайте их через механизм учётных данных systemd: он выдаёт файлы только процессам этой службы. 
[Service]
LoadCredential=vpn.key:/etc/ipsec.d/private/vpn.key

Пример вывода

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

charon[5800]: initiating IKE_SA site-to-site[1] to 198.51.100.20
charon[5800]: retransmit 1 of request with message ID 0
charon[5800]: retransmit 5 of request with message ID 0
charon[5800]: establishing IKE_SA failed, peer not responding

Связанные ошибки

Где встречается чаще всего

Источники

  • Документация strongSwan документация программы
    сверено 15 сентября 2026
  • systemd.exec(5)
    LoadCredential= и выдача секретов процессам службы.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено блокировкой портов согласования между двумя узлами.     собственная проверка, systemd 255
    сверено 15 сентября 2026