woojin

сейчас на OPNsense и используется sing-box как прокси и как DNS резольвер по спискам доменов

хорошо если нет потребности искать обходные пути для некоторых сервисов и Вы обходитесь без них а мне multiwan нужен из-за непредвиденных падений провайдеров (хоть один точно будет работать) согласен

если не секрет чем пользуетесь ВЫ и какая у вас настройка?

да, знаю, но как её ввести, сначала ввести полный ip route и потом сразу ip route disable - дико не удобно тогда зачем данная возможность была вообще в документации указана? извините если повторился - тогда почему статика хоть как то да работает, а вот куча доменных имён шлёт лесом? я делаю вывод что оно или не работает вовсе или работает как то не так, а деталей ни где не нашёл именно по этому сейчас с "кина" собираюсь переезжать на отдельный ПК с OPNsense, там работает так как мне надо, выкатил список в файл и оно полетело всё куда надо хотелось что бы не приходилось использовать отдельную машину для этих нужд (возможно я не прав)

Приветствую, команда Keenetic! Настраиваю Sprinter KN-3710 на KeeneticOS 5.0.12 в конфигурации multipath (MultiWAN) — два провайдера по PPPoE + SOCKS5-прокси Proxy3 для обхода блокировок. Устройств в сети много, все они в Policy0 (multipath) с permit auto. Суть проблемы: мне нужно настроить доступ к определённому списку доменных имён таких сервисов как OpenAI, Grok, Gemini, YouTube и т.д. через Proxy3, оставив остальной трафик через провайдеров. DNS-Based Routes (dns-proxy route object-group domain-list6 Proxy3 auto) — идеальное решение, но… Оно не работает. Потому что все клиенты висят в Policy0, а DNS-Based Routes, как оказалось, работают только в Default Policy. Получается, чтобы FQDN-роутинг работал, нужно сломать всю логику multipath и перевести все устройства в Default Policy. Почему это критично: в моём конфиге Policy0 — это multipath с балансировкой между двумя провайдерами + авто-переключение. Переводить устройства в Default Policy — значит лишиться MultiWAN. Делать сотни статических маршрутов (ip route) — не масштабируется при динамических IP сервисов (Google, Cloudflare, Twitter и т.д.). Сейчас у меня уже более 80 статических маршрутов на подсети этих сервисов в конфиге, и это только ради обхода блокировок. Получается тупик: либо роутер, либо костыли. И ещё две несостыковки CLI ↔ Web: 1. Нет команды «включить/выключить» статический маршрут в CLI. В CLI есть ip route — добавляет маршрут, и no ip route — полностью удаляет его. Но нет команды включить/выключить маршрут без удаления (аналог галочки «Включить/Выключить» в веб-интерфейсе). Приходится либо держать в голове, какие маршруты «временно выключены», либо каждый раз пересоздавать их заново. Для автоматизации через скрипты это неудобно. 2. Нет метрики в Web. В CLI можно назначить метрику статическому маршруту (ip route ... auto <метрика>), а в веб-интерфейсе поля для метрики просто нет. Предлагаю: Сделать DNS-Based Routes работающими в любой Policy, где разрешён целевой интерфейс (или хотя бы добавить параметр принудительного включения вне зависимости от Policy). Это решает корневую проблему — FQDN-роутинг становится полезным в реальных конфигурациях с MultiWAN. Добавить приоритет FQDN-роутинга над статическими маршрутами — чтобы не плодить ip route ради обхода блокировок, а управлять маршрутизацией декларативно через домены. Также было бы удобно: 3. Добавить в CLI команду включения/выключения статического маршрута без его удаления (ip route disable/enable или аналог) — чтобы соответствовало веб-интерфейсу. При этом нужна возможность идентифицировать конкретный маршрут без необходимости полностью переписывать всю строку ip route. 4. Добавить поле метрики в веб-интерфейс для статических маршрутов — чтобы соответствовало CLI.