Перейти к содержанию
Как правильно добавить self-test и прочую отладку в тему
Официальное хранилище ПО в виде файлов

Конфигурация route-based site-to-site IPSEC VPN

Paxton
 Поделиться

Рекомендуемые сообщения

Paxton Новичок

Paxton

Опубликовано
Опубликовано

Приветствую,

Познакомился недавно с Keenetic-ом и возникли вопросы:

1. Если конфигурировать site-to-site route-based IPSEC VPN strongswan требует создания xfrm интерфейса и CLI позволяет задать его в виде tunnel interface XFRM0 для первого туннеля, создается в nxfrm0 интерфейс, который можно включить в маршрутизацию с помощью того же bird. Работает, замечательно.

Однако, если создать еще один site-to-site route-base IPSEC VPN, то CLI опять подсовывает в качестве интерфейса тот же самый XFRM0: 

(config-crypto-map)> tunnel-interface 

 Usage template:  
 tunnel-interface {interface}

(config-crypto-map)> tunnel-interface XFRM0 

хотя нужен новый логически xfrm интерфейс, если править самостоятельно, то выдается ошибка: 

(config-crypto-map)> tunnel-interface XFRM1
Command::Base error[7405602]: argument parse error.

Есть какой-то метод заставить интерфейс NDMS выдать новый туннельный интерфейс?

Или через  OPKG shell самосборным скриптом можно создать интерфейсы, поправить файрвольные записи и конфиг strongswan? Что-то я конфигурации strongswan для этого не нашел...

2. Для работы OSPF через xfrm интерфейс нужно включать multicast примерно таким образом: 

ip link set dev nxfrm0 multicast on

Можно каким-то образом поправить конфигурацию network/interfaces в OPKG shell, чтобы nxfrm0 (и прочие) создавались с включенным multicast?

Или на какое событие лучше вставить скрипт с включением? если при загрузке в /opt/etc/init.d/, то c каким SXY? поскольку желательно, чтобы интерфейс уже был создан из конфига NDMS...

3. Вопрос похожий на предыдущий, но не про IPSEC. Нужен вот такой конфиг, чтобы был доступ на PON-коробку, там можно мониторить уровень сигнала: 

ip addr add 192.168.101.2/24 brd 192.168.101.255 dev eth3
iptables -t nat -A POSTROUTING -o eth3 -d 192.168.101/24 -j SNAT --to-source 192.168.101.2

Опять же к какому событию лучше привязать такой скрипт? 

Заранее спасибо!

Le ecureuil NetFriend

Le ecureuil

Опубликовано
Опубликовано

1. Вы сперва должны создать еще один интерфейс руками. То есть просто interface XFRM1 для создания, и потом привязывайте его, если нужен третий - то interface XFRM2. Необязательно 0-1-2, хоть с XFRM5 начинайте.

2. Лучше на ifcreated.d сделать скрипт, там как раз по id или systemname сможете отфильтровать и включить только на том, котором вам нужно. Все равно для OSPF нужен opkg, потому пока это выглядит лучшим вариантом.

3. Лучше всего на ifipchanged.d с фильтром по eth3, тогда при смене адреса или состояния у вас будет все заново перепрописываться.

Paxton Новичок

Paxton

Опубликовано
  • Автор
Опубликовано (изменено)
6 hours ago, Le ecureuil said:

1. Вы сперва должны создать еще один интерфейс руками. То есть просто interface XFRM1 для создания, и потом привязывайте его, если нужен третий - то interface XFRM2. Необязательно 0-1-2, хоть с XFRM5 начинайте.

2. Лучше на ifcreated.d сделать скрипт, там как раз по id или systemname сможете отфильтровать и включить только на том, котором вам нужно. Все равно для OSPF нужен opkg, потому пока это выглядит лучшим вариантом.

3. Лучше всего на ifipchanged.d с фильтром по eth3, тогда при смене адреса или состояния у вас будет все заново перепрописываться.

По первому вопросу не сразу, но все-таки самостоятельно допер до того, что xfrm интерфейс нужно создавать самому (собственно в мануале strongswan'а это тоже же делается руками конфигурирующего). Просто показалось, что первый XFRM0 был создан системными средствами. Не могу объяснить почему, наверное это уже первые проявления старческого маразма.

Второе и третье сделал следующим образом: изменения в iptables сделал скриптом в netfilter.d, правда пришлось в шелл-скрипте делать проверку на присутствие записей. А смену параметров интерфейса и его адресов - скриптом в ifipchanged.d - там, слава богу, ничего плохого от повторённого введения команд не возникает. Позднее займусь более тонкой фильтрацией, чтобы реже гонять скрипты. Спасибо за информацию.

Однако, возникла с IPSEC туннелем следующая проблема: трафик который приходит внутри туннеля, без проблем достигает адресов рутера, но если его нужно выкинуть обратно в ISP, чтобы достигнуть управляющего интерфейса PON-бокса, то связность пропадает из-за того, что происходит TTL expired на адресах туннеля. То же самое приходит, если трафик из XFRM0 нужно направить, например, в XFRM1 или br0. Причем если снимать PCAP на xfrm0, то он видит только приходящие в туннель пакеты с уменьшающимся TTL. Исходящие пакеты в капчу не попадают. Капча прилагается, конфиг капчи следующий: 

monitor
    capture
        interface XFRM0
            direction in-out
            filter "host 198.18.100.20"
            promisc-mode
            output-directory disk:pcap
            timeout 1000
            buffer-size 512
            max-frame-size 1518
        !
    !
!

Еще снял капчу на ответной стороне, которая, в отличии от кинетика, снимает пакеты в обе стороны, а не только входящие, и видит свой же пакет, возвращенный без изменений кроме уменьшенного на единицу TTL. (См. приложенный файл PCAP.pcap).

Проблем в таблице маршрутизации заметить не удалось. Ну кроме того, что CLI Keenetic-а по-моему неправильно обрабатывает двухстрочные маршруты в выводе ip route и вместо одного маршрута демонстрирует в выводе "show ip route" два: один с нулевой метрикой и второй с установленной: 

(config)> show ip route | grep "XFRM2" -A 2 -B 3
================================================================================
Destination         Gateway          Interface                        F  Metric 
================================================================================
198.18.102.32/30    0.0.0.0          XFRM2                            U  0      
198.18.102.32/30    0.0.0.0          XFRM2                            U  32     
(config)> 
~ # ip route | grep nxfrm2
198.18.102.32/30 dev nxfrm2 scope link  src 198.18.102.34 
198.18.102.32/30 dev nxfrm2 scope link  metric 32 
~ # 

На XFRM0 NAT и файрволинг на данном этапе развития исторического материализма не нужен, поэтому установлена команда security-level private. Конфиг интерфейса прост: 

interface XFRM0
    description "-> HGW Tu6"
    security-level private
    ip address 198.18.102.26 255.255.255.252
    ip mtu 1400
    ip tcp adjust-mss 1360
    up
!

Пробовал и с "ip nat XFRM0" и без него.

Счетчики в iptables ни на какие идеи не наводят, кроме того, что возможно имеются какие-то mark для пакетов, которые переопределяют решения по маршрутизации и пакет вместо ISP (eth3) отправляется в обратно в XFRM0.

Куда еще можно поглядеть, чтобы найти причину такого поведения и, самое главное, его исправить?

 

capture-XFRM0-Sep 7 09-08-10.pcapng PCAP.pcap

Изменено пользователем Paxton
Le ecureuil NetFriend

Le ecureuil

Опубликовано
Опубликовано

А у вас PON-box точно отвечает ICMP в сторону ISP Keenetic или в свой WAN выкидывает?

Можете снять одновременно два дампа - на XFRM0 и на ISP, чтобы понять на каком этапе мы теряем ответ?

Paxton Новичок

Paxton

Опубликовано
  • Автор
Опубликовано
36 minutes ago, Le ecureuil said:

А у вас PON-box точно отвечает ICMP в сторону ISP Keenetic или в свой WAN выкидывает?

Можете снять одновременно два дампа - на XFRM0 и на ISP, чтобы понять на каком этапе мы теряем ответ?

Если пакеты доходят, то отвечает. Например, на пинги и запросы к веб-морде с Home сети - отвечает без проблем.

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

Прикладываю два pcap дампа - первый с XFRM0 с фильтром на пингующую коробку, второй - на аплник, без фильтра. Во втором дампе видно, что ничего кроме ESP трафика туннелей и всяких системных кинетиковских соединений больше ничто не регистрируется.

capture-XFRM0-Sep 9 13-45-25.pcapng capture-GigabitEthernet1-Sep 9 13-45-23.pcapng

Paxton Новичок

Paxton

Опубликовано
  • Автор
Опубликовано
On 9/9/2025 at 3:20 PM, Le ecureuil said:

Спасибо за репорт, проверим. Однако не обещаю что это будет очень быстро.

Спасибо и на том. Правда не уверен, что дождусь. Отсутствие рабочего результата ставит правильность выбранного решения под вопрос.

Поигрался еще с конфигурацией и пришел к пониманию, что есть почти полное непонимание, как работает на коробке нат.

Есть какой-нибудь набор конфигурационных команд, который оставит только маскарадинг на ISP интерфейсах без проверки source адресов? А во всех остальных интерфейсах, чтобы никакого трансляции адресов не производилось...

В настоящее время коробка зачем-то пытается натить трафик, уходящий через xfrm интерфейсы. Хотя они все сделаны security-level private. И c ip nat, и c ip static трансляция адресов продолжается.

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

Denis P Старожил

Denis P

Опубликовано
Опубликовано
3 часа назад, Paxton сказал:

В настоящее время коробка зачем-то пытается натить трафик, уходящий через xfrm интерфейсы. Хотя они все сделаны security-level private. И c ip nat, и c ip static трансляция адресов продолжается.

потому что для локальных сегментов включен ip nat по умолчанию, это можно увидеть в конфиге, например
ip nat Home
его нужно отключить и делать уже выборочно, в необходимые интерфейсы

  • 1 месяц спустя...
Le ecureuil NetFriend

Le ecureuil

Опубликовано
Опубликовано

Проверил вашу схему, все работает нормально в целом, но есть много тонкостей.

Всегда проверяйте настройки firewall на XFRM-интерфейсах, иначе трафик не будет идти вообще.

Учитывая, что у вас приватный интерфейс и нет NAT, то везде нужны обратные роуты, даже на самом роутере с XFRM. Поскольку он видит обратные адреса из удаленных сетей без трансляции, то нужно добавлять руками роуты в эти сети через XFRM-интерфейсы на каждом шагу. Плюс на внешних устройствах навроде gpon-роутера тоже обязателен будет обратный маршрут в удаленную подсеть через Keenetic.

Paxton Новичок

Paxton

Опубликовано
  • Автор
Опубликовано
1 hour ago, Le ecureuil said:

Проверил вашу схему, все работает нормально в целом, но есть много тонкостей.

Всегда проверяйте настройки firewall на XFRM-интерфейсах, иначе трафик не будет идти вообще.

Учитывая, что у вас приватный интерфейс и нет NAT, то везде нужны обратные роуты, даже на самом роутере с XFRM. Поскольку он видит обратные адреса из удаленных сетей без трансляции, то нужно добавлять руками роуты в эти сети через XFRM-интерфейсы на каждом шагу. Плюс на внешних устройствах навроде gpon-роутера тоже обязателен будет обратный маршрут в удаленную подсеть через Keenetic.

Так маршруты сами добавляются с помощью bird, для этого и поставлено. И тем более если нет маршрута, то трафик просто не пойдет в туннельный интерфейс,  а не будет в нем играть в пинбол, пока TTL не закончится.

А вот можете ответить, откуда берутся маршруты как на приложенной картинке, в то время как в CLI взгляд на это другой и на xfrm интерфейсы дефолт нигде не смотрит: 

~ # ip route show table all | grep xfrm
198.18.100.0/24 via 198.18.102.25 dev nxfrm0  table 74  proto bird  metric 32 
198.18.101.0/24 via 198.18.102.25 dev nxfrm0  table 74  proto bird  metric 32 
198.18.102.4/30 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.102.8/30 via 198.18.102.25 dev nxfrm0  table 74  proto bird  metric 32 
198.18.102.12/30 via 198.18.102.25 dev nxfrm0  table 74  proto bird  metric 32 
198.18.102.16/30 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.102.20/30 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.102.24/30 dev nxfrm0  table 74  proto kernel  scope link 
198.18.102.24/30 dev nxfrm0  table 74  proto bird  scope link  metric 32 
198.18.102.28/30 dev nxfrm1  table 74  proto kernel  scope link 
198.18.102.28/30 dev nxfrm1  table 74  proto bird  scope link  metric 32 
198.18.102.32/30 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.102.64/27 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.102.96/27 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.102.128/28 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.102.255 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.200.0/24 via 198.18.102.25 dev nxfrm0  table 74  proto bird  metric 32 
198.18.255.1 via 198.18.102.25 dev nxfrm0  table 74  proto bird  metric 32 
198.18.255.2 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.255.3 via 198.18.102.29 dev nxfrm1  table 74  proto bird  metric 32 
198.18.255.4 via 198.18.102.25 dev nxfrm0  table 74  proto bird  metric 32 
198.18.100.0/24 via 198.18.102.25 dev nxfrm0  proto bird  metric 32 
198.18.101.0/24 via 198.18.102.25 dev nxfrm0  proto bird  metric 32 
        nexthop via 198.18.102.25  dev nxfrm0 weight 1
        nexthop via 198.18.102.29  dev nxfrm1 weight 1
198.18.102.4/30 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.102.8/30 via 198.18.102.25 dev nxfrm0  proto bird  metric 32 
198.18.102.12/30 via 198.18.102.25 dev nxfrm0  proto bird  metric 32 
198.18.102.16/30 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.102.20/30 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.102.24/30 dev nxfrm0  proto kernel  scope link  src 198.18.102.26 
198.18.102.24/30 dev nxfrm0  proto bird  scope link  metric 32 
198.18.102.28/30 dev nxfrm1  proto kernel  scope link  src 198.18.102.30 
198.18.102.28/30 dev nxfrm1  proto bird  scope link  metric 32 
198.18.102.32/30 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.102.64/27 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.102.96/27 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.102.128/28 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.102.255 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.200.0/24 via 198.18.102.25 dev nxfrm0  proto bird  metric 32 
198.18.255.1 via 198.18.102.25 dev nxfrm0  proto bird  metric 32 
198.18.255.2 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.255.3 via 198.18.102.29 dev nxfrm1  proto bird  metric 32 
198.18.255.4 via 198.18.102.25 dev nxfrm0  proto bird  metric 32 
broadcast 198.18.102.24 dev nxfrm0  table local  proto kernel  scope link  src 198.18.102.26 
local 198.18.102.26 dev nxfrm0  table local  proto kernel  scope host  src 198.18.102.26 
broadcast 198.18.102.27 dev nxfrm0  table local  proto kernel  scope link  src 198.18.102.26 
broadcast 198.18.102.28 dev nxfrm1  table local  proto kernel  scope link  src 198.18.102.30 
local 198.18.102.30 dev nxfrm1  table local  proto kernel  scope host  src 198.18.102.30 
broadcast 198.18.102.31 dev nxfrm1  table local  proto kernel  scope link  src 198.18.102.30 
local 198.18.102.34 dev nxfrm2  table local  proto kernel  scope host  src 198.18.102.34 
fe80::/64 dev xfrms1  proto kernel  metric 256  pref medium
fe80::/64 dev xfrms2  proto kernel  metric 256  pref medium
fe80::/64 dev nxfrm0  proto kernel  metric 256  pref medium
fe80::/64 dev nxfrm1  proto kernel  metric 256  pref medium
ff00::/8 dev xfrms1  table local  proto kernel  metric 256  pref medium
ff00::/8 dev xfrms2  table local  proto kernel  metric 256  pref medium
ff00::/8 dev nxfrm0  table local  proto kernel  metric 256  pref medium
ff00::/8 dev nxfrm1  table local  proto kernel  metric 256  pref medium

 

Пока рабочая гипотеза следующая: не может где-то использоваться какая-нибудь фича strongswan, которая вставляет маршрут на сеть, которая предназначена для шифрования, в xfrm интерфейс? Для routed IPSec VPN это очевидно со всех сторон 0.0.0.0/0, поскольку контроль за направлением в туннель трафиком возложен на протоколы маршрутизации.

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

kroutes.png

Le ecureuil NetFriend

Le ecureuil

Опубликовано
Опубликовано

Именно автодобавления согласно политикам не наблюдаю, и кода такого тоже не нашел.

Но сочетание с bird это, конечно, отдельный пласт.

Даже не знаю что посоветовать.

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
 Поделиться
Перейти к списку тем

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю