hoaxisr

Да и репо 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 диапазон и он не хотел подключатся к тому, что ему был оставлен, а упорно хотел запрещенный, то коннекта просто не было. (это из своих наблюдений, не гарантировано, что у других пользователей с их устройствами было ровно такое же поведение)

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

Так сказать для истории. Приведенные изыскания, селфтесты, и прочую информацию отправил в техподдержку 21.03, сегодня получил ответ, что цитата: "На неделе обсудили ситуацию с разработчиками, завели задачу на исправление поведения. Будем ждать." Так что поведение маршрутизации по DNS в части fallback на другие указанные интерфейсы при использовании доменов подтвердили как нерабочую, надеюсь исправления будут включены в какую-то из версий.

Их (моделей многопортовых) даже в анонсах на этот год не было, к сожалению. Как и управляемых коммутаторов (но это понятно тут нет ожиданий). Я не спорю с тем, что 7622 на фоне 7981 или более мощных смотрится так себе, но когда видишь бюджетную линейку на 7628 как бы не очень понимаешь логику Но жираф большой, ему виднее.

То есть плодить роутеры на 7628 и производить их, с 2.4ГГц WiFi и они не "устарели", а WIFI5 все в утиль? Л = логика. М = маркетинг.

Можно никак не заполнять. Просто конфигурация обычного Wireguard будет без расширенных параметров. Их же вообще не задавать.

Да. Весьма. Теперь это воспринимается как странный текст без стилизации. Как будто забыли ее добавить или она сломалась.

На KN-1810 отображается на 5.0.1А6.

У вас badge это как бы уже определённый статус. Нет? Как оно происходит под капотом я не знаю, так же оно маркирует пакеты или нет. Заниматься ловлей пакетов и смотреть нет желания. Функционал заявлен, в стабильной ветке несколько раз ананосирован. Но пока не работает как заявлено. Для себя я хотел выяснить только одно, воспроизводится ли такое поведение (с доменами) у других людей или нет. Вижу, что воспроизводится. Значит это баг. ТП при этом заявляет, что все работает корректно. Вижу что в 4.3.7 LTS и новой 5.0.8 есть изменения "сброс соединений". Буду проверять как там это работает. Но честно говоря, проще использовать альтернативные решения, куда более предсказуемые результаты.

Ну если говорить о том, что функция работает, проверяя ее в других условиях, то мне кажется это некорректно. 🤔 Нигде не заявлено, что функцию приоритета нельзя использовать для доменных имен, я проверил именно так. Вы проверили что-то другое и ответственно заявили, все работает. Но не все работает. UPD. Надо проверить 5.0.8

ТП ответила несколько иначе. Порядок в WEB конфигураторе может не отражать порядок в running config и нельзя на него ориентироваться. Как написал выше это не так, порядку правила не следуют, уходят после down первого интерфейса не во второй интерфейс указанный для правила а спокойно идут в провайдера, делают это практически сразу, при возвращении первого интерфейса в состояние up для возврата работы правила требуется достаточно длительный промежуток времени (до минуты) чтобы они опять начали работать, но во второй интерфейс они не идут никогда Делаем правило, 1 доменом - любой ip check (например 2ip.io) Включаем правило на два интерфейса. Выключаем первый интерфейс (административно, делаем down) Переключение не происходит. При выключении интерфейса я вижу ip через wan (. 207), а не ip интерфейса 2, заданного на правило. (Должен быть не ip на wan). Ни в какой из альф это не работает и нельзя использовать, это не чинилось. Порядок правил играет роль, в каком порядке назначаются интерфейсы через dns-proxy команду тот и будет первым, вопросов нет. Но, опять же, на второй интерфейс никогда не начинает "перекидывать".

Заявленный функционал приоритета и fallback на второй интерфейс не работает при такой настройке: ~ # curl -s http://localhost:79/rci/show/rc/dns-proxy/route [ { "group": "test", "interface": "Wireguard0", "auto": true, "index": "eec3073e15e4e77c29b3c17ddc66a41c", "comment": "" }, { "group": "test", "interface": "Wireguard1", "auto": true, "reject": true, "index": "4e6a4fc5fab8b15b55fa4c2a7e3ddbb2", "comment": "" } ]~ # При Wireguard0 down трафик идет в провайдера. Никогда не идет в Wireguard1. Не реагирует на ping-check, если повесить ping-check на интерфейс Wireguard0 и будет status: fail, то маршрутизация по DNS не реагирует на этот статус. Проверялось на KN-1810 прошивки 5.x (все версии не работает), 5.01.A. (не работает ни на одной из версий). Приоритет маршрутов определяется порядком их ввода -- заявлено, но не функционирует.

Начиная с версии 5.1 Альфа 3 и далее были добавлены расширенные параметры ASC включающие S3,S4, i1-i5 и H1-H4 в виде диапазонов. Соответственно на прошивке из канала "для разработчиков" можно использовать новые параметры этого протокола.

Посмотрите на клиенте Сведения о подключении к сети и убедитесь, что в поле DNS-сервер указан именно IP-адрес роутера. Если вы видите другой IP-адрес (например, адрес публичного DNS-резолвера), вероятно в настройках роутера вы вручную ранее указали дополнительный публичный DNS-сервер или включили использование DoT/DoH. В этом случае его нужно удалить, чтобы для клиента DNS-сервером являлся только роутер, и все DNS-запросы направлялись на него. Начните понимать прочитаное. Или означает клиента, а не роутер. Следующее предложение об этом и говорит.

Я вижу. У сотен людей работает с DoH/DoT upstream на роутере, но пришел Илья и сказал что это не так. Илья не понял что речь идет о том что в DHCP не нужно прописывать DNS отличные от IP роутера и не нужно включать DoH/DoT на клиентах. Так понятно?