Он по умолчанию и так заблокирован, по этому и остальные аргументы довольно странные.
Следить за службами/портами в opkg из ndms так себе затея, учитывая что пользователь развернуть там может практически что угодно.
А тут момент, все зависит от типа интерфейса. Например если речь о вг, нужно повесить на него пинг чек, чтобы интерфейс однозначно отключался при недоступности пира
Наоборот, проверяет нет ли метки и только в этом случае переходит к нужной цепочке
-A PREROUTING -m mark --mark 0x0 -j _NDM_DNSRT_PREROUTING_MANGLE
При наличии entware эта проверка убирается довольно просто и правила начинают работать в других политиках. Вероятно в 5.2 это и будет сделано, но это не точно
и снова вы пришли к неверному выводу, перечитайте пожалуйста мои сообщения.
Если вам сложно верить "на слово" берем entware и смотрим ipset'ы в названиях которых есть _NDM_OGDN_
а дальше в iptables упоминания этих же наборов и/или в цепочку _NDM_DNSRT_PREROUTING_MANGLE . Откроете для себя много нового.
Есть стойкое ощущение что вы просто проигнорировали вышенаписанное. Нет ни одного упоминания того что CIDR правильнее и лучше.
Текст был только о принципе работы и почему при указании CIDR и fqdn в одном и том же модуле может наблюдаться разное поведение.
Вы бы хоть посмотрели как оно работает изнутри, перед тем как делать подобные выводы.
Вся проблема маршрутизации именно доменов не в маршрутах как таковых (которые по факту ими и не являются), а в резолве и последующем наполнении ipset'ов. При указании cidr'a запись в ipset добавляется точно так же, но набор не меняется и не дополняется без участия пользователя.
tldr
dns-proxy слишком медленно резолвит адреса и наполняет ipset'ы
АААА мы получаем всегда и при обычном резолве, в идеале должен отрабатывать fallback.
Бегло проверил на сервисах яндекса (подсеть которого как раз интересовала ТСа)
Кино крутится, интернетометр тоже работает только по ipv4
можно попробовать указать для этого эксклюзивного маршрута другой интерфейс находящийся в отключенном/недоступном состоянии, reject как раз отработает, но как себя поведут приложения при этом и переключатся ли автоматически на v4 - нужно проверять
теперь всё стало на свои места, вы не верно поняли значение параметра reject - эксклюзивный маршрут
читаем справочник и видим там:
Т.е поведение совсем не то, которое вы ожидаете
Вот и крутите "мощность" передатчика в первую очередь. beacon interval очень вряд-ли вам даст хоть какую-то ощутимую экономию без влияния на нормальную работу клиента/ов
Прямо сейчас можно создавать одинаковые маршруты на разные интерфейсы и "резерв" обеспечен. Приоритет определяется порядком в дефолтной политике.
Для отдельной политики тоже есть возможность использовать свои специфичные маршруты, но правда через cli
ip policy PolicyX route <route>
тема про официальные пакеты из репозитория rustdesk, вопрошающий вероятно оттуда же и взял пакет.
Под mips/mipsel официальной сборки нет, авторы rustdesk не планируют этого делать https://github.com/rustdesk/rustdesk-server/issues/401#issuecomment-2067784782
Да, признаю, в entware не заглянул, но вы уже задали правильные вопросы
На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.