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

[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]

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

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

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

[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

Изменено Понедельник в 15:18 пользователем Paxton

[Le ecureuil]

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

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

[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

[Le ecureuil]

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