ale_xb

спасибо, т.е. в моем случае все надо делать руками. Возможно, попробую пойти от обратного: сначала установлю asterisk от Keenetic на пустую флэшку, а затем добавлю/донастрою свои пакеты в entware. В общем, подумаю, что для меня будет проще. Еще уточните, пожалуйста, если пойти по вашему рецепту, стартовый скрипт запуска asterisk установится или его надо тоже руками копировать и править?

У меня уже установлен entware и в нем несколько пакетов (mc, openconnect,...). Сейчас хочу добавить asterisk 18 сборки команды Keenetic. Как мне правильно действовать, чтобы сохранить уже установленные пакеты entaware?

Оказалось, что не обязательно. Достаточно добавить стандартными средствами Keenetic Cli или проще через web-интерфейс разрешающее правило (спасибо ТП), цитирую: "на Home сегменте достаточно сделать правило вида источник: локальная сеть, назначение: удалённая сеть, протокол: ip, действие: разрешить" У меня сразу все заработало. В netfilter правило в моем случае выглядит так (добавляется в таблицу по умолчанию filter, цепочку @Bridge0 ) root@keenetic:/opt/etc$ iptables -nL @Bridge0 Chain @Bridge0 (1 references) target prot opt source destination ACCEPT all -- 192.168.100.0/24 172.27.96.0/20

Хочу понять, зачем ставить cron из entaware? Разве crond из состава прошивки/busybox не достаточно для этого?

В этом и сложность, что на систему (приходится) параллельно воздействуют из двух мест - на уровне NDM Shell CLI Keenetic и собственно ОС Linux/bash/...

Заработало. Дело оказалось, действительно в файрволе роутера. После команды no isolate-private доступ к хостам за vpn сервером из моей LAN появился. Мне это не совсем понятно, т.к. в справочнике CLI Keenetic написано, что всем создаваемым новым интерфейсам присваивается public security-level, а трафик из private (Home LAN) в public (tun1) разрешен по умолчанию. Возможно, здесь что-то работает не совсем так, т.к. интерфейс tun1 создан не средствами CLI, а вовсе доп.пакетом из entware и по команде show interface он (tun1) никак не отображается. Попробовал отключить nat-ирование, т.е. убрать правило маскарадинга, все работает и без него. Странно, мои проверки в предыдущем посте показывали его необходимость. Впрочем, tcpdump на интерфейсе tun1 показал, что icmp request уходят с src=ip tun1, т.е. nat-ирование все же работает и без моего доп.правила. В справочнике CLI keenetic нашел команду ip nat vpn которая включает/выключает nat-ирование для vpn клиентов. Во-первых, не ясно, работает ли эта команда для любых vpn-клиентов или только, встроенных в прошивку или для части из них, во-вторых, не указано ее значение по умолчанию, но, похоже, что "включено". Вот так выглядит цепочка POSTROUTING в таблице nat. Проверил, команда no ip nat vpn удаляет из этой цепочки последнее 4-е правило, но доступ из моей LAN к хостам за vpn-сервером сохраняется и в этом случае: # iptables -t nat -nL POSTROUTING --line-numbers Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 _NDM_IPSEC_POSTROUTING_NAT all -- 0.0.0.0/0 0.0.0.0/0 2 _NDM_SNAT all -- 0.0.0.0/0 0.0.0.0/0 3 _NDM_MASQ all -- 0.0.0.0/0 0.0.0.0/0 4 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 ndmmark match 0x40/0x40 Я не силен в netfilter/iptables, и несколько десятков цепочек/правил в Keenetic понять (пока) не могу, но все равно придется разбираться, как теперь это (файервол) правильно настроить при поднятом туннеле opennconnect, чтобы не попортить настройки безопасности на роутере. Ну и стартовый скрипт для openconnect добавить, конечно.

Продолжу пока разговор самим с собой. Пробовал ловить трафик на интерфейсах tcpdump-ом. Обнаружил, что пинги с самого роутера ходят до хостов за vpn сервером нормально только с src=ip на tun1. Если попытаться указать src=ip другого интерфейса роутера, например, смотрящим внутрь LAN, echo request уходит с интерфейса tun1 в сторону vpn сервера нормально, но останется без ответа. Если же сначала добавить правило nat-ирования (моё сообщение выше), echo reply начинает приходить нормально и для этого src. Напрашиваются выводы: 1) nat-ирование нужно, т.к. vpn сервер дропает все, что пришло с "неправильного" интерфейса, т.е. src!=ip tun1; 2) при пингах хостов за vpn-сервером с любого хоста из моей LAN видно, что echo request нормально приходит на интерфейс br0, но на tun1 этот запрос не появляется. Вероятно, он дропается файерволом роутера. Надо разбираться с этим и/или, возможно, как уже писал выше с interface security-level . Позже попробую это подкрутить.

Вот тоже, очень интересует эта тема. Ставлю openconnect, туннель до Cisco ASA поднимается, маршруты на keenetic прилетают и даже в отличие от автора темы хосты за ASA отвечают на пинги. Но вот дальше - та же беда, все это не доступно из локалки. Есть подозрение, что NAT для tun1, который поднимается с помощью openconnect не работает. Пробовал руками добавить правило iptables -t nat -I POSTROUTING -d 172.27.96.0/24 -s 192.168.100.0/24 -o tun1 -j MASQUERADE не помогает. Счетчик пакетов для данного правила, так и остается нулевым. Может, что-то еще с interface security-level на keenetic следует подкрутить?