55736 2025-08-27 11:18:17 +0300 Перестал работать туннель 2026-09-23 12:11:02 +0300 1 1 4 Development Sisyphus strongswan unstable x86 Linux CLOSED WORKSFORME https://bugzilla.altlinux.org/show_bug.cgi?id=60664 P5 normal --- 1 oleg.ibn.a mike glinkinvd mike oddity week qa-sisyphus oldest_to_newest 271474 0 oleg.ibn.a 2025-08-27 11:18:17 +0300 После обновления клиента на версию 6.0.2 перестал работать туннель l2tp ipsec. Соединения клиента с сервером проходит нормально, но в туннеле работали только ping до ресурсов, а ssh, curl, telnet "зависали". по tcpdump-у видно что первый пакет от сервера приходит, клиент сообщает о его получении и ждет следующего, а дальше тишина - пакеты от сервера не доходили до клиента. strongswan version Linux strongSwan U6.0.2/K6.12.25-6.12-alt1 Description: ALT Regular Codename: Sisyphus Помогло откатиться до версии 6.0.1 297216 1 rider 2026-09-08 21:23:03 +0300 Сейчас в Sisyphus strongswan-6.0.7-alt1 (задание https://packages.altlinux.org/tasks/421790/ не относится; актуальное задание см. в истории пакета). По апстримным changelog: - в 6.0.2 изменена установка SA в ядро: используется sequence number из acquire, при rekey повторно используются ранее согласованные traffic selectors — это как раз затрагивает transport mode, на котором работает L2TP/IPsec; - явного исправления регрессии для L2TP в 6.0.3–6.0.7 нет; ближайшее — в 6.0.5 в kernel-netlink исправлено обновление address family в селекторе SA для transport mode при смене адресов. Просьба перепроверить туннель на 6.0.7-alt1. Если проблема воспроизводится, полезны будут `ip xfrm state` и `ip xfrm policy` на клиенте в момент, когда пакеты от сервера перестают приходить, и вывод `swanctl --list-sas`. 297217 2 rider 2026-09-08 21:23:43 +0300 Поправка к предыдущему комментарию: ссылка на задание 421790 попала туда по ошибке, она не имеет отношения к strongswan. Актуальная сборка strongswan-6.0.7-alt1 — задание https://packages.altlinux.org/tasks/420646/ (2026-06-10). 299506 3 glinkinvd 2026-09-17 18:35:30 +0300 Перепроверил на чистом актуальном Sisyphus. --- Версии пакетов и ядра на клиенте: - strongswan-6.1.0-alt1.x86_64 - xl2tpd-1.3.20-alt1.x86_64 - ppp-2.5.2-alt3.x86_64 - kernel-image-6.12-6.12.110-alt1.x86_64 На сервере использовались те же версии: - strongswan-6.1.0-alt1.x86_64 - xl2tpd-1.3.20-alt1.x86_64 - ppp-2.5.2-alt3.x86_64 - kernel-image-6.12-6.12.110-alt1.x86_64 --- Стенд состоит из двух чистых VM, соединённых отдельной сетью: client 10.88.0.2/24 | | IPsec transport mode, IKEv2 | L2TP | server 10.88.0.1/24 PPP: client 192.168.173.2 server 192.168.173.1 strongSwan настроен с PSK, IKEv2 и CHILD_SA в TRANSPORT mode. Traffic selectors ограничены L2TP: client: local 10.88.0.2/32[udp] remote 10.88.0.1/32[udp/1701] server: local 10.88.0.1/32[udp/1701] remote 10.88.0.2/32[udp] После установки соединения CHILD_SA имеет состояние: INSTALLED, TRANSPORT L2TP/PPP успешно поднимается через xl2tpd: клиент получает 192.168.173.2, сервер — 192.168.173.1. Счётчики XFRM/ESP увеличиваются, т.е. L2TP действительно проходит через IPsec. MTU на ppp0 оставлен 1500, вручную MTU/MRU не уменьшались. Для проверки исходного симптома на сервере был поднят HTTP-сервис на 192.168.173.1:8080, клиент скачивал через туннель файл размером 256 MiB. --- Результат: ping через PPP: OK, 0% packet loss TCP до rekey: 11 x 256 MiB — успешно CHILD_SA rekey: swanctl --rekey --child l2tp — успешно SPI сменились CHILD_SA остался INSTALLED, TRANSPORT PPP-соединение не разорвалось TCP после rekey: 11 x 256 MiB — успешно Полное disconnect/connect: 3 цикла после каждого IPsec, L2TP/PPP, ping и загрузка 256 MiB — успешно Всего через туннель успешно передано около 6.25 GiB TCP-данных. Ошибок/drops на ppp0 не наблюдалось. Таким образом, на данном чистом стенде с strongswan-6.1.0-alt1, IKEv2, L2TP/IPsec и IPsec transport mode исходный симптом — «ping работает, а TCP после первых пакетов зависает» — не воспроизводится. --- Примечание по IKEv1. Первоначально стенд был настроен с IKEv1 (version = 1), однако strongswan-6.1.0-alt1 отказывался инициировать соединение ещё до отправки IKE-пакетов: vici initiate CHILD_SA 'l2tp' IKE version 1 not supported Это соответствует изменению в upstream strongSwan 6.1.0: IKEv1 is now disabled by default. Upstream также указывает, что при сборке поддержку IKEv1 теперь требуется включать явно с помощью --enable-ikev1, а в одной из будущих версий поддержку IKEv1 планируется удалить. В исходниках пакета это также видно непосредственно в configure. При отсутствии --enable-ikev1 устанавливается: ikev1=false ikev1_given=false и IKEv1 добавляется в список отключённых по умолчанию возможностей: disabled_by_default=${disabled_by_default}" ikev1" См. strongswan/configure, строка 8265: https://git.altlinux.org/gitoskop/#/srpms/s/strongswan.git/-/blob/sisyphus/strongswan/configure?L=8254 Upstream changelog strongSwan 6.1.0: https://github.com/strongswan/strongswan/releases/tag/6.1.0 В strongswan.spec версии 6.1.0-alt1 параметр --enable-ikev1 в вызов %configure не добавлен. Фактический вызов ./configure в логе сборки также не содержит --enable-ikev1. Поэтому strongswan-6.1.0-alt1 собран без поддержки IKEv1, что и объясняет сообщение IKE version 1 not supported. В исходном сообщении #55736 версия IKE не указана, поэтому дальнейшая проверка была выполнена с IKEv2. Результат выше относится к конфигурации IKEv2 + L2TP/IPsec transport mode.