hoaxisr

Не все. Заявленный функционал fallback для fqdn как не работал, так и не работает. Как были пропуски наполнения ipset, так и остались. Функция как была нестабильной, так и осталась.

Создать политику доступа с выходом в виде туннеля. Воспользоваться командой ip hotspot

Вот тут

Я думаю, что если вы захотите найти домены - вы найдете способ, их много. Я лишь говорю, что к маршрутизации по IP нужно подходить аккуратно. 20K строк в списков CIDRов это перебор. Я лишь об этом.

По первому пункту: 1. Узнать домены куда хочет попасть приложение или сервис довольно просто -- для этого есть инструменты как на телефонах (Apple встроенное, Android - бесплатное), на компе есть расширение браузера, которое соберет все в авто режиме. Т.е. это не большая проблема, плюс маршритузация по доменам работает с маской и покрывает все субдомены. 2. Узнать IP тоже не проблема конечно тем же механизмом. И маршрутизация по IP работает в КинетикОС пока явно стабильнее. (но это проблема реализации, а не концепции) Так что корень зла только в том, что при IP маршрутизации люди используют весьма широкие CIDR сомнительного происхождения.

Если это произойдет, то я добавлю новый домен в маршрутизацию. Аналогично я могу задать тот же вопрос, а вы уверены, что ASN/CIDR сервиса всегда постоянен и не может меняться? Почему-то я думаю, что домены более постоянная сущность, чем множество IP, именно для этого и были придуманы домены в том числе, что можно произвольно менять назначение куда указывает доменное имя не передавая пользователю новые наборы IP.

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

Для HR достаточно чтобы WG сервер был bind в домашний сегмент сети. (Есть в настройках wg server) И чтобы клиент использовал роутер как DNS, но с IP в домашнем сегменте (br0). Для этого нужно подправить конф файл, который отдает роутер.

Не работает заявленный режим fallback между интерфейсами. Не работает (или скорее работает с серьезными "затупами") высоконагруженные по DNS сервисы (типа shorts на известном видеохостинге) и reals (в другом не менее известном) Рандомно, периодически пропускается наполнение IP для FQDN группы и поэтому летишь в провайдера и ожидаемо получаешь бяку.

Все верно, ASC параметры появились в 4.х ветке, в 5.1 Альфа 3 появились "расширенные" ASC параметры 2.0 (включащие S3,S4, i1-i5 параметры и дозволяющие H1-H4 в виде диапазонов).

В смысле менялась? Она изначально для DNS маршрутов была такой. Официальная документация по DNS маршрутам Советую прочесть внимательно документацию и сделать как там написано. Будет плюс/минус работать.

Имеется в виду интерфейс Wireguard может иметь расширенные параметры ASC, начиная с версии 5.1 Альфа 3 и выше. А уж будет это условный сервер или клиент уже не имеет значения.

Вы прям сделали ровно противоположность тому, что требуется. Есть база знаний Кинетик. Там все весьма четко расписано, что нужно сделать, чтобы получить результат. 1. Все клиенты использует роутер как DNS. Не используют "безопасные", "приватные", не используют подобное в браузере. Только роутер 2. Находятся в политике доступа по умолчанию.

Да и репо hoaxisr.github.io не существует, что отношения к antiscan не имеет никакого, но мешает работе opkg. Вам нужно в /opt/etc/opkg/ Найти файлы .conf и убрать или поправить репозитории пакета на http://repo.hoaxisr.ru

В теме есть ответ на ваш вопрос. Нужно лишь прочитать сообщения до вашего.

может гео списки refilter покрывают и ютуб? не?

Если идет речь о маршрутизации, то, что показано на скриншоте - скорее заявлено как работающий механизм, чем реально работающий. На форуме есть пара тем, где описаны все проблемы этой штуки в "стабильной" версии, можно сделать выводы о том, как жто работает. Ну и заявленный механизм fallback в правилах на второй интерфейс не работает вообще для доменных имен.

Для того, чтобы воспроизвести описываемое поведение необходимо задать профиль тестирования с такими параметрами: После ожидаемое поведение - увеличение счетчика succescount на 1 за каждый интервал update-interval В реальности же при любом разрешенном update-interval счетчик будет увеличиваться на значение = 2 Почему проверки проходят дважды? Ожидаемо ли такое поведение?

Возможно. Все данные для этого имеются. Но будет ли это реализовано

1. Настроить Proxy (socks5) на какой-нибудь ipv4 адрес 2. Импортировать Wireguard конфигурацию с ipv6 адресом и allowed-ips ::/0 3. Установить в обоих интерфейсах check-box "Использовать для выхода в интернет" 3. Включить Proxy интерфейс 4. Включить WIreguard интерфейс. 5. Наблюдать как Proxy будет выключен и включен без действий пользователя. Вопросы: 1. Для каких целей на t2sX интерфейсах задаются ipv6 scope global адреса? (ни на WAN интерфейсе нет ipv6, ни в Bridge0) 2. UI роутера не предполагает каких-либо настроек ipv6 для Proxy интерфейсов, как предлагается влиять на эту настройку? 3. Check-box "включить ipv6" не проставлен для Bridge0, в настройках Интернет --> Кабель Ethernet стоит "Настройка IPv6" - "не используется". При отсутствии ipv6 адреса в конфигурации Wireguard -- Proxy0 ведет себя адекватно и не реагирует на изменение состояния Wireguard интерфейса. Мар 31 22:14:58 ndm Network::Interface::Ip6: "Proxy0": unable to find address fc03:52b:6:a56:10c:14ac:8c0c:5102/128. Мар 31 22:14:58 ndm Network::Interface::EndpointTracker: "Proxy0": remote endpoint is "192.168.1.150". Мар 31 22:14:58 ndm Network::Interface::EndpointTracker: "Proxy0": connecting via "Home" (Bridge0). Мар 31 22:14:58 ndm Network::Interface::EndpointTracker: "Proxy0": local endpoint is "192.168.1.1". Мар 31 22:15:00 ndm Network::Interface::Base: "Proxy0": "ip" changed "ipv4" layer state "disabled" to "pending". Мар 31 22:15:00 ndm Network::Interface::Ip: "Proxy0": IP address is 172.20.12.1/32. Мар 31 22:15:00 ndm Network::Interface::Ip: "Proxy0": interface "Proxy0" is global, priority 4095. Мар 31 22:15:00 ndm Network::Interface::Ip: "Proxy0": adding default route via Proxy0. Мар 31 22:15:00 ndm Network::Interface::Base: "Proxy0": "ip6" changed "ipv6" layer state "disabled" to "pending". Мар 31 22:15:00 ndm Network::Interface::Ip6: "Proxy0": interface "Proxy0" is global, priority 4095. Мар 31 22:15:00 ndm Network::Interface::Ip6: "Proxy0": adding default route via Proxy0.

Весьма дельная идея! Видеть всю информацию в одном месте

У меня устройства без регистрации. Бомжи они. А для прописанных как у вас. с трафиком.

Вот так.

Оно работало как blacklist скорее. Т.е. если клиенту выбрать только 1 диапазон и он не хотел подключатся к тому, что ему был оставлен, а упорно хотел запрещенный, то коннекта просто не было. (это из своих наблюдений, не гарантировано, что у других пользователей с их устройствами было ровно такое же поведение)

Спасибо за реализацию предложения. Очень приятно, что компания слышит и реализует идеи