Не удается подключиться к VPN-серверу, используя Strongswan IPSec IKEV1 Ubuntu 24.04

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

У меня возникла проблема с подключением к VPN с использованием Strongswan, и я не могу найти никаких ресурсов в интернете, которые решают эту проблему. Мне кажется, что фаза 1 IPSec проходит нормально, но фаза 2 не удается, так как сразу после того, как я получаю “initiating Aggressive Mode IKE_SA work[2] to <vpn_ip_address>“, я получаю “establishing connection ‘work’ failed“.

Я использую правильный PSK в ipsec.secrets, потому что проверяю соединение с помощью приложения для Android, и оно работает.

Мой ipsec.conf:

# ipsec.conf - strongSwan IPsec конфигурационный файл
config setup

# базовая конфигурация
conn %default
        ikelifetime=3h
        keylife=20
        rekeymargin=1
        keyexchange=ikev1
        keyingtries=3
        modeconfig=pull
        aggressive=yes
        xauth=client
        closeaction=restart

conn work
        left=192.168.21.45
        leftid=home
        leftauth=psk
        leftauth2=xauth
        xauth_identity=<my_username>
        leftsendcert=never
        right=<vpn_ip_address>
        rightid=<vpn_ip_address>
        rightauth=psk
        auto=add
        #ike=aes128-sha1-modp1536!
        #esp=aes128-sha1-modp1536!
        ike=aes128-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,3des-sha1-modp1536!
        esp=aes128-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,3des-sha1-modp1536!

и мой вывод журнала:

initiating Aggressive Mode IKE_SA work[1] to <vpn_ip_address>
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from 192.168.21.45[500] to <vpn_ip_address>[500] (524 bytes)
received packet: from <vpn_ip_address>[500] to 192.168.21.45[500] (500 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID HASH V NAT-D NAT-D V V V V V ]
received NAT-T (RFC 3947) vendor ID
received DPD vendor ID
received XAuth vendor ID
received unknown vendor ID: 82:99:03:17:57:a3:60:82:c6:a6:21:de:00:00:00:00
received FRAGMENTATION vendor ID
received FRAGMENTATION vendor ID
selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
local host is behind NAT, sending keep alives
generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
sending packet: from 192.168.21.45[4500] to <vpn_ip_address>[4500] (108 bytes)
received packet: from <vpn_ip_address>[4500] to 192.168.21.45[4500] (76 bytes)
parsed TRANSACTION request 3388019831 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
generating TRANSACTION response 3388019831 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from 192.168.21.45[4500] to <vpn_ip_address>[4500] (108 bytes)
received packet: from <vpn_ip_address>[4500] to 192.168.21.45[4500] (76 bytes)
parsed TRANSACTION request 1716392366 [ HASH CPS(X_STATUS) ]
XAuth authentication of '<my_username>' (myself) successful
IKE_SA work[1] established between 192.168.21.45[home]...<vpn_ip_address>[<vpn_ip_address>]
scheduling reauthentication in 10799s
maximum IKE_SA lifetime 10800s
generating TRANSACTION response 1716392366 [ HASH CPA(X_STATUS) ]
sending packet: from 192.168.21.45[4500] to <vpn_ip_address>[4500] (76 bytes)
generating QUICK_MODE request 2683793279 [ HASH SA No KE ID ID ]
sending packet: from 192.168.21.45[4500] to <vpn_ip_address>[4500] (396 bytes)
received packet: from <vpn_ip_address>[4500] to 192.168.21.45[4500] (92 bytes)
parsed INFORMATIONAL_V1 request 1993870300 [ HASH D ]
received DELETE for IKE_SA work[1]
deleting IKE_SA work[1] between 192.168.21.45[home]...<vpn_ip_address>[<vpn_ip_address>]
initiating Aggressive Mode IKE_SA work[2] to <vpn_ip_address>
establishing connection 'work' failed

Почему клиент получает DELETE для IKE_SA, и является ли это причиной, почему фаза 2 соединения не удается?

Буду очень признателен за любую помощь.

Ответ или решение

Для решения проблемы с подключением к VPN-серверу с использованием Strongswan на Ubuntu 24.04 мы должны подробно проанализировать конфигурацию и лог-файлы подключения, чтобы выявить возможные ошибки и предложить оптимальные пути их исправления.

Теория

IPSec — это набор протоколов, обеспечивающих защиту данных на сетевом уровне. В частности, протоколы IKEv1 и IKEv2 используются для установки защищенного канала обмена ключами между клиентом и сервером. Первую фазу (IKE Phase 1) часто называют уязвимой, так как она отвечает за создание первого защищенного канала. Вторая же фаза (IKE Phase 2) отвечает за установление защищённых туннелей для передачи данных, используя параметры, согласованные в первой фазе.

На основании полученного исходного кода конфигурации и логов, можно сделать вывод, что проблема заключается в фазе 2. Вы видите, что фаза 1 успешна, поскольку идентификация и аутентификация проходят без ошибок. Однако, как только начинается установление канала для передачи данных, происходит ошибка, и вы получаете сообщение "received DELETE for IKE_SA work[1]".

Пример

Ваш файл конфигурации IPsec и предоставленные логи показывают, что вы настроили туннель в режиме агрессивного обмена (Aggressive Mode) с использованием Pre-Shared Key (PSK) и XAuth для аутентификации. Из логов видно, что фаза 1 успешно устанавливается: IKE_SA work[1] established between 192.168.21.45[home]...<vpn_ip_address>. Однако, проблема возникает именно после получения DELETE для IKE_SA: received DELETE for IKE_SA work[1], что может указывать на нестандартную ошибку или отказ сервера в продолжении сессии.

Применение

Для устранения проблемы следует предпринять ряд шагов:

Проверка конфигурации:
- Убедитесь, что параметры шифрования и аутентификации конфигурации полностью соответствуют настройкам ожиданий на серверной стороне. Проверьте параметры ike и esp, использованные вами в конфиге, и их соответствие серверной стороне.
- Убедитесь, что все необходимые для вашей сети порты открыты – обычно это 500 и 4500 для UDP (также NAT-T для IPsec).
Проверка совместимости:
- Некоторые серверы могут иметь ограничения, накладываемые на использование определённых шифров и режимов работы — для проверки протестируйте соединение с каждым из доступных наборов алгоритмов отдельно.
Отладка логов:
- Увеличьте уровень детализации логов в strongswan.conf (charon и libstrongswan), чтобы получить более развернутую информацию о происходящем.
- Опытный анализ логов может выявить неочевидные проблемы, например, несоответствие правил безопасности.
Пересмотрите политику переустановки:
- Убедитесь, что опции, такие как reauth, strictcrlpolicy, closeaction, заданы в соответствии с политиками безопасности вашего VPN-сервера.
Дополнительные проверки:
- Проверьте, не исходит ли запрос DELETE от стороны сервера вследствие достижения ограничений по времени или количеству повторных подключений.
- Проверьте, требуется ли сервером какой-либо дополнительный уровень аутентификации или политики.
Идентификация ошибок сетевого уровня:
- Проверьте настройки вашего брандмауэра или маршрутизатора, так как его настройки могут блокировать пересылку необходимых пакетов.

Если после проведения всех указанных шагов проблема не решается, рекомендуется обратиться к системному администратору вашего VPN-сервера для получения необходимых сведений о его конфигурации и возможных ограничениях. Это позволит убедиться в отсутствии недокументированных требований или изменений в политике безопасности.