Denis P

"NAT для клиентов" естественно установлен подключение через anyconnect 4.2.6.3 4.3.1 вручную добавить не получается (config)> oc-server route 0.0.0.0/0 Vpn::DhcpInform error[101516564]: "OCSRVVPN": default route not allowed. self-test в скрытом сообщении.

Вы и так уже используете entware для создания этих интерфейсов. О каких кастомных прошивках вообще речь? Интеграция в веб подобных вещей кажется крайне сомнительным решением, что же это за такие продвинутые пользователи у которых отсутствие ui вызывает сложности) Еще добавлю немного, веб взаимодействует с условным "линуксом" через api, а не напрямую. Т.е для реализации вашей хотелки требуется проделать довольно большую работу, которая будет учитывать все возможные типы интерфейсов которых нет в ndms, но могут быть добавлены с помощью сторонних пакетов. Всё вышесказанное сугубо личное мнение.

я понимаю что conntrack не умеет ограничения per network подумалось что удобно было это иметь сразу из коробки, но намек понятен, продолжу крутить iptables через opkg)

4.3.1 - всё ок

спасибо, в 4.3.1 сразу же при распаковке оффлайн инсталера (если он содержит скрипты в netfilter.d) они тут же обрабатываются

в данный момент ограничение касается только % от таблицы, было бы намного удобнее иметь возможность указывать и конкретное число возможных подключений со стороны public интерфейсов для одного адреса и/или подсети upd в принципе можно и не только для внешних, для внутренних тоже - например чтобы клиента с включенным dht и торрентами жестко ограничить т.е что-то типа ip conntrack max-entries private host

И чего вдруг не должен? Баг то в чем?

по факту веб ведь и не врет, а показывает тот что задан для "домашней сети", т.е если его изменить он тоже изменится и в этом разделе

можно, придется использовать https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmneighbourd на форуме можете поискать примеры что это и с чем его едят потом передавать через ndmc -c необходимые параметры настроек (как в cli)

разве если повесить его через веб на "Home" не будет того же эффекта? как раз output из-за security level private

Это тоже локальный адрес, он вам не мешает. Можете убедиться в выводе ip a конкретно интерфейс ezcfg0 Но если это принципиально: ip http proxy cloud no dns-override

к сожалению не работает проверил на 4.3.0 тут же сделал down/up случайному интерфейсу и скрипты из netfilter.d обработались

В основном это ситуация при разворачивании "офлайн" инсталера с уже готовым набором пакетов и скриптами Т.е приходится дергать интерфейс чтобы подхватилось из netfilter.d. не сказать что это прям создает сильный дискомфорт, но если есть какой-то вариант этого не делать, кроме ручного запуска скриптов, было бы удобнее)

уже реализовано в cli, можно конкретные маршруты привязать к конкретным политикам IP: добавлены настройки статических маршрутов, специфичных для политики [NDM-3435]: ip policy {name} ip route ( {network} {mask} | {host} ) ( {gateway} [interface] | {interface}) [auto] [metric] [reject] ip policy {name} ipv6 route {prefix} ( {interface} [gateway] | {gateway} ) [auto] [metric] [reject]

@Le ecureuilвсё еще актуально последний раз воспроизвелось include'ом интерфейса USB сетевой карты в Bridge0 дергаем любой интерфейс (down/up) - loopback снова работает

Собственно проблема указана в заголовке Заводим нового пользователя -> даем ему права администратора -> создаем пароль -> Пользователь создается без пароля. Что чревато потерей удаленного доступа к вебу: Тема создана именно в разделе о ПО, а не приложения, потому что по словам одного из разработчиков она касается именно прошивки да и на 4.2.6 такого поведения нет

немного влезу, но попутно задам один вопрос, который тоже касается netfilter каким-то образом можно инициализировать его перезапуск не трогая политики/интерфейсы/правила переадресации/мсэ и остальное что служит тригером для его перезапуска? т.е грубо говоря вручную заставить перечитать скрипты которые лежат в netfilter.d не меняя параметры системы

Точно никак не могла скорость из-за них упасть, это два самых быстрых алгоритма, один для совместимости, второй, для того что поновее, скорее всего просто совпадение)

+ даже никаких манипуляций производить не пришлось, ошибки просто валятся в лог с изрядной частотой

Запрещающее правило создано при этом?

Зачем же вы тогда создаете разрешающее правило в мсэ, если при пробросе порта это не требуется? Имеет смысл только запрещающее, если нужно ограничить доступ временно или в соответствии с определенными критериями

Так у вас настроена и переадресация и правила в мсэ?

Перед тем как написать, проверил на нескольких устройствах с 4.2.х из стабильной ветки и на 4.3.b4. В первом случае не воспроизводится. Во втором - отключение правила срабатывает с задержкой

Вернитесь на ветку stable, там такой проблемы нет.

В догонку точно работающий конфиг из локалки Transmission Remote GUI