Paxton

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