Paxton

Так маршруты сами добавляются с помощью 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, поскольку контроль за направлением в туннель трафиком возложен на протоколы маршрутизации. Поэтому если автоматически вставлять дефолты, то может наблюдаться как раз ситуация с закольцовыванием и блэкхолингом приходящего извне трафика.

Спасибо и на том. Правда не уверен, что дождусь. Отсутствие рабочего результата ставит правильность выбранного решения под вопрос. Поигрался еще с конфигурацией и пришел к пониманию, что есть почти полное непонимание, как работает на коробке нат. Есть какой-нибудь набор конфигурационных команд, который оставит только маскарадинг на ISP интерфейсах без проверки source адресов? А во всех остальных интерфейсах, чтобы никакого трансляции адресов не производилось... В настоящее время коробка зачем-то пытается натить трафик, уходящий через xfrm интерфейсы. Хотя они все сделаны security-level private. И c ip nat, и c ip static трансляция адресов продолжается. Кроме того, конфигурация цепочек iptables все время акцентируется на сетях подключенных интерфейсов, не учитывая, что при наличии такого большого количества VPN возможностей маршрутизатор так-то может получать трафик и от других отнюдь не directly connected сетей.

Если пакеты доходят, то отвечает. Например, на пинги и запросы к веб-морде с Home сети - отвечает без проблем. В данном случае до этой коробки запросы не доходят, поскольку весь транзитный трафик, приходящий из туннеля не на адреса роутера, разворачивается обратно. Прикладываю два pcap дампа - первый с XFRM0 с фильтром на пингующую коробку, второй - на аплник, без фильтра. Во втором дампе видно, что ничего кроме ESP трафика туннелей и всяких системных кинетиковских соединений больше ничто не регистрируется. capture-XFRM0-Sep 9 13-45-25.pcapng capture-GigabitEthernet1-Sep 9 13-45-23.pcapng

По первому вопросу не сразу, но все-таки самостоятельно допер до того, что 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

Приветствую, Познакомился недавно с 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 Опять же к какому событию лучше привязать такой скрипт? Заранее спасибо!