hoaxisr

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

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

Вот так.

Оно работало как 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 на клиентах. Так понятно?

Навык понимания прочитанного необходимо срочно улучшить. Где здесь сказано, что нельзя использовать upstream DoH/DoT на роутере? Вы вообще понимаете о чем пишете?

Ну так сами прочтите и не вводите людей в заблуждение. Работает маршрутизация по доменам с использованием DoT/DoH в качестве upstream на роутере.

Это не соответствует действительности. В статье сказано, что нельзя использовать DNS отличные от DNS роутера. Про то, что нельзя использовать DoH/DoT на роутере в статье не говорится ни слова.

Лучше штатной.

Это не дополнительный пароль. Это значит или пароль неправильный или вы пытаесь попасть в SSH роутера по неправильному логину. Для SSH роутера пара пользователь - admin пароль -- пароль от веб-интерфейса для admin

Можно я немного порассуждаю над вашей задумкой? Вы ведь можете напрямую, без использования xkeen, HR или другого решения настроить mihomo. Сделать у него в конфигурации все нужные правила и использовать этот инструмент для маршрутизации. Тем более его (mihomo) система маршрутизации очень серьезно в лучшую сторону поскольку опирается не на маршрутизацию в IP после резолва доменного имени, а маршрутизирует по связке SNI+IP. Т.е. когда вы на больших CDN на одном IP могут быть несколько сайтов/сервисов в интерфейс для маршрутизации не уйдут сайты, которые вы туда не направляли. Плюсом xkeen конечно является "обвязка" правилами для направление в mihomo пакетов, правда вы можете это реализовать и без xkeen, через okgtun и политики доступа. Единственное ограничение этой стратегии весьма слабое устройство. KN-1811 хоть и ARM, но ожидать от него какой-то сверхпроизводительности не стоит. Ведь по сути вы построите роутер на роутере.

установите компонент системы "Клиент прокси". Или используйте opkgtun в 5.0.4 он как раз доступен.