hoaxisr

У вас 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 он как раз доступен.

Это тоже vless-о-подобное чудо мимикрия под https.

Реакции были. Вам привели даже ссылку. Во-вторых, не кажется вам странным, что вы считаете нормальным требовать что-то? Ну вот почему вы считаете, что можете потребовать от производителя угодить вашим желаниям? Это ведь не вопрос технической поддержки, неисправности или неожидаемой работы устройства, это развитие и добавление функционала которого в нем сейчас нет, да, здорово, если у разработчиков будет ресурс на имплементацию этого пожелания, но никто не обещал вам, что любое желание (пусть объединяющее много людей) будет сделано моментально, в течение дня и тут же вам выдано, ведь так? Вы можете не знать и половины внутренней кухни производителя, возможные риски, текущие планы, перспективные планы, вы думаете там сидит специальный человек и ждет когда вы придете и потребуете срочно вам ответить и сразу все сделать? В реальном мире это работает не так.

Хм. Я возможно ошибаюсь, но для того чтобы добавить в Mesh устройство, оно должно быть сброшено до заводских настроек, не иметь пароля администратора и в процессе оно обновляется до последнего релиза в стабильном канале обновлений. И мнение пользователя на этот счет не учитывается. Но я могу ошибаться, и поведение другое. Знающие люди поправят если это не так.

вынести его в отдельный сегмент сети например, а в magitrickle по-умолчанию маршрутизация работает только на br0. Домашний сервер будет в br1 и не будет его трафик маршрутизироваться через правила этой программы насколько я понимаю.

Я думаю (сугубо личное мнение), что все эти различные варианты прокси (а это по своей сути больше прокси, чем туннель) не будут добавлены нативно, в том числе потому что весят много, поддерживать сложно, изучать чужую работу и адаптировать ее к прошивке это большие затраты человеческих ресурсов. Я нисколько не против самой темы и предложения, не подумайте дурного, но реальность такова, что быстрее и эффективнее использовать возможности Entware для экспериментов в этой области. А вся это https мимикрия может довольно быстро закончиться при более активном развертывании 16-20кб блока, и там будет уже не важно vless, trusttunnel или еще чего модное, стильное, молодёжное.

А это by design так. При добавлении устройства в mesh оно обновляется до последнего релиза.

Не то, чтобы это баг скорее вопрос к обсуждению, теперь к сути - у меня архитектура локальной сети предполагает, что ни одно устройство (кроме двух точек доступа) не использует роутер как шлюз по умолчанию. Соответственно в мониторе трафика я не предполагаю увидеть вот такую картинку: То есть у всех устройств кроме одного единственного нет потока трафика через роутер (все по 0/0 Б), но при этом для них выделяется место в круговом чарте некой величины (видимо это какое-то дефолт значение для 0% - тут я могу ошибаться и это может быть не так). Отсюда вопрос - можно ли изменить этот подход и не показывать ТОП-5 потребителей, если потребления у них нет? Потому что при октрытии этой страницы я ожидаю увидеть только 1 устройство, а если вижу другие то сначала возникает мысль, что что-то пошло не так. Или мои ожидания от этого монитора не верны и отображение включает трафик не только LAN <--> ISP, но и LAN <--> роутер, но он настолько незначительный, что при округлении получается 0 Б, а по факту он все же есть и поэтому происходит вот такое отображение?

Тут дело в том, что не во всех местах сделано единообразно. Местами ссылки без подчеркивания. Местами с подчеркиванием. И вот поэтому это все не консистентность дизайна. Не баг конечно, но не последоставательно и не цельно.

Среди прочих преимуществ продукта этой компании в маркетинге аккуратно продвигается нарратив про ультимативность возможностей, в этом разрезе да, компании как бизнесу нужно в этой "гонке" участвовать, если она хочет сохранить это реномэ. А вообще как таковой гонки нет. Есть риски. И они растут. Но бизнес это всегда сочетание рисков и прибыли.

Я описывал подобную проблему с внешним диском, но ситуация там была такая, что на этом диске в корне есть папка внутри которой есть большое (>10 тысяч) количество файлов. Веб-морда роутера умирает если попробовать открыть этот диск или попытася настроить сервер SMB. в технической поддержке сообщили, что не нужно так делать и хранить на диске такое количество файлов в одной папке По факту роутер не NAS, его возможности сильно ограничены производительностью архитектуры.

ну пробел после названия диска поставить же нужно. должно быть "opkg disk BLA_BLA_BLA https://...."