Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

Не удалось подключиться к серверу VPN Strongswan

На чтение 10 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. 1. Проверка состояния сервера
  4. 2. Настройка брандмауэра
  5. 2.1 Проверка правил в nftables
  6. 3. Настройки логирования
  7. 4. Проверка логов
  8. 5. TCP Dump для анализа пакетов
  9. 6. Дополнительные настройки IPv6
  10. Заключение

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

Я пытаюсь подключиться к своему VPN-серверу Strongswan, собранному с версии 5.9.14.

Сервер работает, и клиент пытается подключиться, но сервер никогда не отвечает на запрос. Я проверил брандмауэр, и он настроен на разрешение портов 500 и 4500. Я также пытался получить более детализированные логи, но этого не происходит / или нет записей в системном журнале.

В общем, я в затруднении и буду признателен за любую помощь. Я пробовал это с UFW как включенным, так и выключенным – без изменений.

Сервер на Ubuntu 24.04.01 LTS.

Команда сборки:

 ./configure --prefix=/usr --sysconfdir=/etc --disable-defaults --enable-silent-rules --enable-charon --enable-systemd --enable-ikev2 --enable-vici --enable-swanctl --enable-nonce --enable-random --enable-drbg --enable-openssl --enable-curl --enable-pem --enable-x509 --enable-constraints --enable-revocation --enable-pki --enable-pubkey --enable-socket-default --enable-kernel-netlink --enable-resolve --enable-eap-identity --enable-eap-md5 --enable-eap-dynamic --enable-eap-tls --enable-updown --enable-tss-tss2 --enable-tpm

root@huginn:~/strongswan-5.9.14# service strongswan status
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
     Loaded: loaded (/usr/lib/systemd/system/strongswan.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-09-02 21:06:16 EDT; 10min ago
    Process: 220846 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
   Main PID: 220827 (charon-systemd)
     Status: "charon-systemd running, strongSwan 5.9.14, Linux 6.8.0-41-generic, x86_64"
      Tasks: 17 (limit: 9445)
     Memory: 3.5M (peak: 6.1M)
        CPU: 44ms
     CGroup: /system.slice/strongswan.service
             └─220827 /usr/sbin/charon-systemd

Sep 02 21:06:16 huginn swanctl[220846]: loaded certificate from '/etc/swanctl/x509ca/ca-chain.cert.pem'
Sep 02 21:06:16 huginn swanctl[220846]: loaded private key from '/etc/swanctl/private/vpn.server.org.key.pem'
Sep 02 21:06:16 huginn swanctl[220846]: loaded eap secret 'eap-user'
Sep 02 21:06:16 huginn swanctl[220846]: loaded authority 'Strongswan'
Sep 02 21:06:16 huginn swanctl[220846]: successfully loaded 1 authorities, 0 unloaded
Sep 02 21:06:16 huginn swanctl[220846]: loaded pool 'remote_pool'
Sep 02 21:06:16 huginn swanctl[220846]: successfully loaded 1 pools, 0 unloaded
Sep 02 21:06:16 huginn swanctl[220846]: loaded connection 'roadwarrior'
Sep 02 21:06:16 huginn swanctl[220846]: successfully loaded 1 connections, 0 unloaded
Sep 02 21:06:16 huginn systemd[1]: Started strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.

logging.conf

charon-systemd {
  journal {
    default = 4
    ike = 4
    knl = 4
    # ...
  }
}

charon {

  # два определенных файловых логгера
  filelog {
    charon {
      # путь к лог-файлу, укажите это как имя раздела в версиях до 5.7.0
      path = /var/log/charon.log
      # добавьте префикс временной метки
      time_format = %b %e %T
      # добавьте имя соединения, упрощает фильтрацию
      ike_name = yes
      # перезаписать существующие файлы
      append = yes
      # увеличьте уровень логирования по умолчанию для всех подсистем демона
      default = 2
      # сбрасывать каждую строку на диск
      flush_line = yes
    }
    stderr {
      # более детализированный уровень логирования для конкретной подсистемы, переопределяя 
      # уровень логирования по умолчанию.
      ike = 2
      knl = 3
    }
  }

  # и два логгера, использующих syslog
  syslog {
    # префикс для каждого сообщения лога
    identifier = charon-custom
    # используйте настройки по умолчанию для логирования в узел LOG_DAEMON
    daemon {
    }
    # очень минималистичные логи аудита IKE в LOG_AUTHPRIV
    auth {
      default = -1
      ike = 0
    }
  }
 # ...
}

connection.conf

# конфигурация roadwarrior
authorities {
     Strongswan {
          cacert = ca-chain.cert.pem
     }
}    

  journal {
    default = 4  
    ike = 4
    knl = 4
    # ...
  }

  connections {
    roadwarrior {
      pools = rw_pool
      local {
        auth = pubkey
          certs = vpn.server.org.cert.pem
          id = vpn.server.org
        }
      remote {
        auth = pubkey
      }
      children {
        roadwarrior {
#          local_ts  = 10.1.0.0/16
#          local_ts = 0.0.0.0/0
           local_ts = 0.0.0.0/0, ::/0
           rekey_time = 0
        }
      }
    }
  }

  }

лог клиента (ubuntu desktop 24.04)

2024-09-02T19:32:04.323589-06:00 fafnir charon-nm: 05[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2024-09-02T19:32:04.323634-06:00 fafnir charon-nm: 05[NET] sending packet: from 192.168.30.50[46858] to 167.71.166.210[500] (972 bytes)
2024-09-02T19:32:08.324281-06:00 fafnir charon-nm: 12[IKE] retransmit 1 of request with message ID 0
2024-09-02T19:32:08.324342-06:00 fafnir charon-nm: 12[NET] sending packet: from 192.168.30.50[46858] to <server ip>[500] (972 bytes)
2024-09-02T19:32:15.524583-06:00 fafnir charon-nm: 14[IKE] retransmit 2 of request with message ID 0
2024-09-02T19:32:15.524692-06:00 fafnir charon-nm: 14[NET] sending packet: from 192.168.30.50[46858] to <server ip>[500] (972 bytes)
2024-09-02T19:32:28.485020-06:00 fafnir charon-nm: 09[IKE] retransmit 3 of request with message ID 0
2024-09-02T19:32:28.485079-06:00 fafnir charon-nm: 09[NET] sending packet: from 192.168.30.50[46858] to <server ip>[500] (972 bytes)
2024-09-02T19:32:51.813298-06:00 fafnir charon-nm: 15[IKE] retransmit 4 of request with message ID 0
2024-09-02T19:32:51.813448-06:00 fafnir charon-nm: 15[NET] sending packet: from 192.168.30.50[46858] to <server ip>[500] (972 bytes)
2024-09-02T19:33:04.247159-06:00 fafnir charon-nm[70214]: Connect timer expired, disconnecting.
2024-09-02T19:33:04.247220-06:00 fafnir charon-nm: 08[IKE] destroying IKE_SA in state CONNECTING without notification
2024-09-02T19:33:04.247899-06:00 fafnir charon-nm: 07[KNL] интерфейс nm-xfrm-2751540 деактивирован
2024-09-02T19:33:04.248785-06:00 fafnir charon-nm: 13[KNL] fe80::bddd:f33c:78f:5cd9 исчез из nm-xfrm-2751540

Обновление 4 сентября.

Мой клиент подключается через Starlink, который, как я понимаю, имеет проблемы с IPV4, поэтому я перенастроил его на IPv6 на основе конфигурации тестовой лаборатории Strongswan для IPv6 roadwarrior. Затем я запустил TCPDUMP во время попытки подключения, который, исходя с сервера, привел к следующему:

02:42:11.805109 IP6 (flowlabel 0x064f8, hlim 53, next-header UDP (17) payload length: 248) client-ipv6-address.55059 > server-ipv6-address.500: [udp sum ok] isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:
    (sa: len=44
        (p: #1 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=integ id=#12 )
            (t: #3 type=prf id=#5 )
            (t: #4 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 data=(37b6ff2309f8d07e5532...0000402f00020003000400050000000800004016))
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))
02:42:15.803606 IP6 (flowlabel 0x064f8, hlim 53, next-header UDP (17) payload length: 248) client-ipv6-address.55059 > server-ipv6-address.500: [udp sum ok] isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:
    (sa: len=44
        (p: #1 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=integ id=#12 )
            (t: #3 type=prf id=#5 )
            (t: #4 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 data=(37b6ff2309f8d07e5532...0000402f00020003000400050000000800004016))
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))
02:42:23.008293 IP6 (flowlabel 0x064f8, hlim 53, next-header UDP (17) payload length: 248) client-ipv6-address.55059 > server-ipv6-address.500: [udp sum ok] isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:
    (sa: len=44
        (p: #1 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=integ id=#12 )
            (t: #3 type=prf id=#5 )
            (t: #4 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 data=(37b6ff2309f8d07e5532...0000402f00020003000400050000000800004016))
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))
02:42:35.966303 IP6 (flowlabel 0x064f8, hlim 53, next-header UDP (17) payload length: 248) client-ipv6-address.55059 > server-ipv6-address.500: [udp sum ok] isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:
    (sa: len=44
        (p: #1 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=integ id=#12 )
            (t: #3 type=prf id=#5 )
            (t: #4 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 data=(37b6ff2309f8d07e5532...0000402f00020003000400050000000800004016))
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))
02:42:59.299393 IP6 (flowlabel 0x064f8, hlim 53, next-header UDP (17) payload length: 248) client-ipv6-address.55059 > server-ipv6-address.500: [udp sum ok] isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:
    (sa: len=44
        (p: #1 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=integ id=#12 )
            (t: #3 type=prf id=#5 )
            (t: #4 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 data=(37b6ff2309f8d07e5532...0000402f00020003000400050000000800004016))
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431

Я не вижу ничего в syslog для IP клиента или для соединений IKEV2.

Обновление 4 сентября – вывод ps -ef

UID          PID    PPID  C STIME TTY          TIME CMD
root        1020       1  0 03:03 ?        00:00:00 /usr/sbin/charon-systemd

Итак, проблема заключалась в том, что Ubuntu 24.04 использовал брандмауэр netfilter / nft. Был создан отдельный таблица inet, которая применяется как к IPV4, так и к IPV6, но не была изменена через команды UFW или IPTABLES.

nft -a list ruleset

Выводит правила с номером позиции.

Примените нижеуказанные правила к позиции правила, как минимум выше последнего (drop) правила

nft add rule inet filter input position 22 udp dport 4500 accept
nft add rule inet filter input position 22 udp dport 500 accept

Добавление вышеуказанных правил выше последнего правила drop решило проблему с потерей пакетов, независимо от правил UFW и IPTABLES для разрешения порта 500.

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

Проблема, с которой вы столкнулись при подключении к серверу VPN StrongSwan, вероятно, связана с настройкой вашего брандмауэра и использованием связи через IPv4 и IPv6. На основании предоставленной вами информации, вот некоторые шаги и рекомендации, которые помогут вам устранить проблему и успешно подключиться к вашему VPN-серверу.

1. Проверка состояния сервера

Первым делом убедитесь, что ваш сервер StrongSwan запущен и работает корректно. Вы уже проверили это с помощью команды service strongswan status, и у вас все в порядке. Основной процесс charon-systemd активен, что является хорошим знаком.

2. Настройка брандмауэра

Согласно вашему сообщению, вы уже проверяли настройки брандмауэра UFW, но необходимо также учесть, что в Ubuntu 24.04 введен новый фреймворк сетевого фильтра nftables, который может перекрывать ваши настройки UFW и IPTABLES.

2.1 Проверка правил в nftables

Вам следует проверить текущие правила nftables, чтобы убедиться, что порты 500 и 4500 не блокируются. Выполните следующую команду, чтобы просмотреть настройки:

nft -a list ruleset

Если вы не видите разрешения для необходимых портов, добавьте их с помощью следующих команд:

nft add rule inet filter input position 22 udp dport 4500 accept
nft add rule inet filter input position 22 udp dport 500 accept

Убедитесь, что эти правила находятся выше любых правил, которые могут блокировать входящий трафик (например, правил drop).

3. Настройки логирования

Вы упомянули, что у вас проблемы с логированием. Убедитесь, что ваш файл конфигурации logging.conf правильный. С увеличением уровня детализации логирования вы сможете лучше следить за событиями. Например:

charon-systemd {
  journal {
    default = 4
    ike = 4
    knl = 4
  }
}

4. Проверка логов

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

journalctl -u strongswan

Или для просмотра журнала файла:

cat /var/log/charon.log

5. TCP Dump для анализа пакетов

Вы делали tcpdump и видели, что пакеты отправляются, но не получаете ответов от сервера. Это говорит о том, что возможно, пакеты блокируются на уровне сети (брандмауэр или маршрутизация) или отсутствует ответ со стороны сервера. Продолжайте использовать tcpdump на сервере, чтобы отследить входящие UDP-пакеты на портах 500 и 4500:

tcpdump -i any port 500 or port 4500

6. Дополнительные настройки IPv6

Вы упомянули, что используете Starlink, который может иметь специфические проблемы с IPv4. Если вы перешли на IPv6, убедитесь, что ваш сервер правильно настроен для работы с IPv6. Убедитесь, что в конфигурации connection.conf у вас есть настройки для работы через IPv6.

Заключение

Скорее всего, проблема была связана с настройками брандмауэра nftables, которые не учитывались при использовании UFW. Выполнив предлагаемые шаги, вы сможете успешно настроить подключение к вашему StrongSwan VPN-серверу. Если после всех изменений проблема не будет решена, продолжайте мониторить логи и использовать инструменты анализа сети для дальнейшего устранения неполадок.

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

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

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности