сбой установки IKE_SA в случае roadwarrior, пир не отвечает

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

Я пытаюсь реализовать случай с дорожным воином с использованием strongswan. В этом случае клиент VPN отправляет запрос на шлюз, но шлюз просто отбрасывает пакет. Я убедился, что работает только charon-systemd. В основном я удалил другие пакеты с помощью

sudo apt install -y strongswan charon-systemd strongswan-swanctl strongswan-pki libstrongswan-extra-plugins libtss2-tcti-tabrmd0
sudo apt remove -y strongswan-starter strongswan-charon

Даже в ss -tunlp на шлюзе мы видим, что charon-systemd слушает порты

Netid  State   Recv-Q  Send-Q   Local Address:Port   Peer Address:Port Process                                                                                                                                     
udp    UNCONN  0       0           127.0.0.54:53          0.0.0.0:*     users:(("systemd-resolve",pid=1265,fd=19))                                                                                                 
udp    UNCONN  0       0        127.0.0.53%lo:53          0.0.0.0:*     users:(("systemd-resolve",pid=1265,fd=17))                                                                                                 
udp    UNCONN  0       0              0.0.0.0:68          0.0.0.0:*     users:(("charon-systemd",pid=1420,fd=22))                                                                                                  
udp    UNCONN  0       0              0.0.0.0:111         0.0.0.0:*     users:(("rpcbind",pid=1264,fd=5),("systemd",pid=1,fd=37))                                                                                  
udp    UNCONN  0       0            127.0.0.1:323         0.0.0.0:*     users:(("chronyd",pid=1382,fd=5))                                                                                                          
udp    UNCONN  0       0              0.0.0.0:500         0.0.0.0:*     users:(("charon-systemd",pid=1420,fd=15))                                                                                                  
udp    UNCONN  0       0              0.0.0.0:4500        0.0.0.0:*     users:(("charon-systemd",pid=1420,fd=16))                                                                                                  
udp    UNCONN  0       0              0.0.0.0:5355        0.0.0.0:*     users:(("systemd-resolve",pid=1265,fd=11))                                                                                                 
udp    UNCONN  0       0                 [::]:111            [::]:*     users:(("rpcbind",pid=1264,fd=7),("systemd",pid=1,fd=39))                                                                                  
udp    UNCONN  0       0                [::1]:323            [::]:*     users:(("chronyd",pid=1382,fd=6))                                                                                                          
udp    UNCONN  0       0                 [::]:500            [::]:*     users:(("charon-systemd",pid=1420,fd=13))                                                                                                  
udp    UNCONN  0       0                 [::]:4500           [::]:*     users:(("charon-systemd",pid=1420,fd=14))                                                                                                  
udp    UNCONN  0       0                 [::]:5355           [::]:*     users:(("systemd-resolve",pid=1265,fd=13))                                                                                                 
tcp    LISTEN  0       20           127.0.0.1:25          0.0.0.0:*     users:(("exim4",pid=1864,fd=4))                                                                                                            
tcp    LISTEN  0       4096        127.0.0.54:53          0.0.0.0:*     users:(("systemd-resolve",pid=1265,fd=20))                                                                                                 
tcp    LISTEN  0       4096           0.0.0.0:5355        0.0.0.0:*     users:(("systemd-resolve",pid=1265,fd=12))                                                                                                 
tcp    LISTEN  0       4096           0.0.0.0:3128        0.0.0.0:*     users:(("spiceproxy work",pid=1923,fd=6),("spiceproxy",pid=1922,fd=6))                                                                     
tcp    LISTEN  0       128            0.0.0.0:22          0.0.0.0:*     users:(("sshd",pid=1387,fd=3))                                                                                                             
tcp    LISTEN  0       4096           0.0.0.0:111         0.0.0.0:*     users:(("rpcbind",pid=1264,fd=4),("systemd",pid=1,fd=36))                                                                                  
tcp    LISTEN  0       4096     127.0.0.53%lo:53          0.0.0.0:*     users:(("systemd-resolve",pid=1265,fd=18))                                                                                                 
tcp    LISTEN  0       4096              [::]:5355           [::]:*     users:(("systemd-resolve",pid=1265,fd=14))                                                                                                 
tcp    LISTEN  0       128               [::]:22             [::]:*     users:(("sshd",pid=1387,fd=4))                                                                                                             
tcp    LISTEN  0       4096              [::]:111            [::]:*     users:(("rpcbind",pid=1264,fd=6),("systemd",pid=1,fd=38))                                                                                  
tcp    LISTEN  0       20               [::1]:25             [::]:*     users:(("exim4",pid=1864,fd=5))  

Клиент пытается инициировать запрос, но не получает никакого ответа от шлюза

Nov 21 20:32:40 client-node charon-systemd[3938]: retransmit 1 of request with message ID 0
Nov 21 20:32:40 client-node charon-systemd[3938]: sending packet: from <REDACTED>[500] to <REDACTED>[500] (1048 bytes)
Nov 21 20:32:48 client-node charon-systemd[3938]: retransmit 2 of request with message ID 0
Nov 21 20:32:48 client-node charon-systemd[3938]: sending packet: from <REDACTED>[500] to <REDACTED>[500] (1048 bytes)
Nov 21 20:33:00 client-node charon-systemd[3938]: retransmit 3 of request with message ID 0
Nov 21 20:33:00 client-node charon-systemd[3938]: sending packet: from <REDACTED>[500] to <REDACTED>[500] (1048 bytes)
Nov 21 20:33:24 client-node charon-systemd[3938]: retransmit 4 of request with message ID 0
Nov 21 20:33:24 client-node charon-systemd[3938]: sending packet: from <REDACTED>[500] to <REDACTED>[500] (1048 bytes)
Nov 21 20:34:06 client-node charon-systemd[3938]: retransmit 5 of request with message ID 0
Nov 21 20:34:06 client-node charon-systemd[3938]: sending packet: from <REDACTED>[500] to <REDACTED>[500] (1048 bytes)
Nov 21 20:35:21 client-node charon-systemd[3938]: giving up after 5 retransmits
Nov 21 20:35:21 client-node charon-systemd[3938]: establishing IKE_SA failed, peer not responding

На шлюзе, используя tcpdump, мы можем видеть запрос, приходящий от клиента, но шлюз не отвечает

20:32:48.050763 eno2np1 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:32:48.050763 bond0 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:32:48.050763 bond0.7 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:33:01.011245 eno2np1 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:33:01.011245 bond0 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:33:01.011245 bond0.7 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:33:24.339522 eno2np1 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:33:24.339522 bond0 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:33:24.339522 bond0.7 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:34:06.329906 eno2np1 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:34:06.329906 bond0 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]
20:34:06.329906 bond0.7 In  IP <REDACTED>.isakmp > <REDACTED>.maas.isakmp: isakmp: parent_sa ikev2_init[I]

.

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

Устранение проблемы: Не удается установить IKE_SA, пира не отвечает

Введение

При настройке VPN-клиента в сценарии "roadwarrior" с использованием StrongSwan возникает ошибка: "не удается установить IKE_SA, пира не отвечает". Данная проблема обычно связана с тем, что запрос клиента на соединение не получает ответа от VPN-шлюза. В этой статье мы рассмотрим основные причины возникновения данной проблемы и предложим решения.

Анализ проблемы

Основные указатели на наличие проблемы:

  1. Записи журнала клиента показывают, что запросы отправляются, но не получают ответов:

    establishing IKE_SA failed, peer not responding
  2. Сетевые снифферы, такие как tcpdump, на стороне шлюза фиксируют поступающие запросы от клиента, однако видно, что ответ не отправляется:

    isakmp: parent_sa ikev2_init[I]

Причины и их диагностика

1. Неправильная конфигурация фаервола

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

  • 500/UDP: основной порт IKE
  • 4500/UDP: порт для NAT-T (если NAT используется)

Для проверки состояния фаервола используйте команды, такие как iptables -L или ufw status.

2. Ошибки в конфигурации StrongSwan

Проверьте файл конфигурации StrongSwan, чтобы убедиться, что настройки заданы правильно. Основные аспекты:

  • Убедитесь, что параметры аутентификации и шифрования соответствуют настройкам клиента.
  • Проверьте, правильно ли указаны поля left, right, leftsubnet и другие. Неправильная маршрутизация может привести к отсутствию ответа.

Пример конфигурации:

conn roadwarrior
    keyexchange=ikev2
    left=%any
    leftid=@your_gateway
    leftcert=your_cert.pem
    leftsendcert=always
    right=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.10.0/24
    eap_identity=%identity

3. Проблемы с NAT

Если клиент или шлюз находится за NAT, возможно, это вызывает проблемы с обменом сообщениями. Включите NAT-T в конфигурации StrongSwan, добавив следующую строку:

nat_traversal=yes

Также убедитесь, что NAT работает корректно и что шлюз способен обнаружить запрашивающие пакеты и ответить на них.

4. Проверьте состояние службы Charon

Согласно предоставленным данным, вы уже запустили только charon-systemd. Убедитесь, что служба работает корректно и обрабатывает запросы:

sudo systemctl status charon-systemd

Рекомендуемые шаги по устранению неполадок

  1. Проверка фаервола. Убедитесь, что порты 500 и 4500 открыты.
  2. Проверка конфигурации. Проверьте файл конфигурации StrongSwan на наличие ошибок.
  3. Настройка NAT-T. Если необходимо, добавьте поддержку NAT-T.
  4. Просмотр логов. Используйте опцию --log для получения расширенных данных о работе daemon.

Заключение

Ситуация, когда возникает ошибка "установить IKE_SA не удалось, пира нет", может быть вызвана множеством факторов, включая неправильные настройки фаервола, ошибки в конфигурации StrongSwan или проблемы с NAT. Тщательный анализ каждого из этих компонентов поможет устранить проблему. Если после выполнения всех проверок проблема остается актуальной, рассмотрите возможность обращения к форумам поддержки StrongSwan или поисковых систем для существующих сообществ, которые могут предоставить дополнительную поддержку.

Оцените материал
Добавить комментарий

Капча загружается...