hoaxisr

У меня есть устройство - сушильная машина LG. Сначала она отражалась как подключенная по LAN, хотя у нее есть только WIFI и по проводу она никогда не была подключена к роутеру. Сейчас вот устройство имеет возможность с одним MAC адресом получить два IP. Как бы ее побороть так не делать?

Поскольку сейчас появилась маршрутизация по DNS и как известно для работоспособности этого функционала необходимо, чтобы клиенты находились в системной политике, то отслеживать нахождение клиентов в нужной политике через закладку "применение политик" в виде свалки клиентов не очень удобно предлагаю: В разделе Список клиентов добавить колонку и показывать в какой политике доступа находятся клиенты. Места там по-моему мнению предостаточно для того, чтобы отразить эту информацию. @Anna_ посмотрите, пожалуйста, по возможности добавления в планы?

Да . Вы поняли правильно. Вы указываете IP машины с NPM и домен. Можно использовать wildcard (то есть *. Yourdomain.LAN) и все запросы пойдут к прокси.

Перезапись запросов раздел называется. Там можно сделать A записи для доменов с указанием IP в локальной сети, если речь идет об этом.

100%. Спасибо, что дали развернутый ответ. Возможно наиболее простым на первоначальном этапе будет не автоматизировать эту историю. Поскольку часть кейсов использования это когда пользователь точно знает IP точки выхода своего интерфейса и может просто указывать его руками. Насколько я понимаю сейчас идет этап построения концепции как будет работать DNS резолв на роутере и отлично, что вы смотрите в сторону расширения возможностей для настройки. Будем ждать реализации

Да, мне тоже так кажется, периодически устройства, подключенные через ретрансляторы отображаются как подключенные через LAN, но с течением времени они меняют свое состояние в дашборде. Это было и в 4.2.х, и в 4.3.х. При это у меня одно устройство всегда отображается как подключенное через LAN и никогда не меняет свое состояние это сушильная машина. Другие устройства меняют свой статус, а вот эта зараза всегда "по кабелю"

А можно я задам вопрос, по теме ECS DNS - поскольку сейчас имеется функционал доменных списков, возможно ли рассчитывать на появление в будущем возможности назначать этим спискам специфичный DNS сервер и указывать определённый IP (ECS DNS) для того, чтобы резолвить IP из CDN ближе к точке выхода интерфейса, через который этот доменный список маршрутизируется? Ведь это улучшит пользовательский опыт?

Реакции закончились Спасибо!

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

Для того, чтобы роутинг по доменам (Маршруты DNS) работали должны быть ОДНОВРЕМЕННО выполнены следующие условия: 1. Клиент находится в политике доступа "по умолчанию". 2. Клиент использует в качестве DNS роутер. (особенно это касается всяких Chrome, который очень любит по умолчанию использовать "безопасный" резолвер) 3. Интерфейс через который будут идти соединения включен, настроен и работает. После проверки выполнения всех трех условий, настраиваете: 1. Создаете группу, добавляете в нее какой-то набор доменных имен (для тестирования добавьте какой-нибудь сервис, показывающий ваш IP - 2ip.io, ifconfig.me или что-то такое) 2. Назначаете группе интерфейс через который вы хотите маршрутизировать этот набор доменных имен. 3. Ждете. Сбрасываете кеш DNS на клиенте. Проверяете. Не надо "поднимать" или переставлять местами интерфейсы в политике доступа по-умолчанию. Это не требуется.

Спасибо. Не пользуюсь ни тем, ни другим.

У моего DoT вполне себе имеется IP. И его резолвить не нужно. Я его знаю заранее. Но все равно логика мне не ясна, к сожалению.

Но ведь dashboard новый, возможно стоит в нем указывать активные DNS сервера для интерфейса. При этом если DoT/DoH должны иметь приоритет над нешифрованнными DNS, то странно что для резервных соединений указываются нешифрованные DNS.

Все может быть конечно.Буду наблюдать. В случае повторения - промониторю активность.

В логе после перезагрузки роутера спустя более 7 минут появляется сообщение: Sep 26 15:59:38 kernel conntrack: generic helper won't handle protocol 47. Please consider loading the specific helper module. Но модуль GRE туннелей у меня не установлен. Я так понимаю это просто сообщение о том, что не будет работать маршуртизация GRE туннелей? Ранее такого в логе не было

Вот такие настройки.

Для основного интернет соединения не указывается действующий DNS сервер, для дополнительного указывается. Так задумано?

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

При разрещении экрана FHD и масштабе 125% третья колонка не позволяет вместить полностью доменное имя. при этом у четвертой колонки еще очень много "пустого" пространства. Нельзя ли немного расширить третью колонку за счет четвертой?

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

Спасибо за информацию. Возможно полезным будет как-то ограничивать пользователей от создания подобных нагрузок?

ОК. Попробую вернуть настройки клиентов так, чтобы они снова использовали роутер как default gateway и сброшу более подробный лог. По второму пункту проверю.

xhttp имеет смысл только если у вас заблокирован IP вашего VPS, но не заблокирован CDN с поддержкой gRPC. Актуально для Ирана. У нас ситуация обратная часто IP CDN блокируются, а IP хостеров нет.

SoC на базе 7621 MediaTek появился на свет в 2014 году, а роутеры на нем с 2015 года насколько я понимаю. Но не суть. Если по сути вопроса, то нет. Беру включаю WIFI на "контроллере" к нему естественно цепляются какие-то устройства, на этих устройствах прошу просто посерфить по инету, полистать какие-нибудь сайтики/видеохостинги и т.д. и т.п., в это время на машине которая подключена по Ethernet запускаю iperf как клиент к серверу на VPS в РФ. Имею один результат, при этом имею одну загрузку ЦП роутера. Повторяю манипуляцию, но отключив WIFI на "контроллере" - его клиенты убегают к AP которые есть в локальной сети и подключены к "контроллеру" по Ethernet, и они продолжают свою активность,а я запускаю повторную серию тестов iperf - имею выше скорость и меньшую загруженность роутера. Вот таким нехитрым и не совсем научным способом, я сделал вывод, что мне так лучше

Если создать Proxy подключение к машине в локальной сети по Socks5 и маршрутизировать через этот Proxy какой либо трафик (например какой-нибудь видеохостинг), то весь лог будет забит бесконечными сообщениями вида: [xxxxx] Proxy0: client session connect [xxxxx] Proxy0: client connect Я понимаю, что можно сделать system log suppress Proxy0, но возможно не нужно спамить в лог этими сообщениями об установлении TCP/UDP соеденинений - они не несут информативной нагрузки. Эти сообщения никак не влияют на работу Proxy, все работает как ожидается, просто лог засосорен малоинформативными сообщениями. P.s. на самой локальной машине поднимал sing-box/xray-core/mihome/v2ray-core - никакой разницы, роутер спамить не прекращает. В логах этих socks5 серверов ошибок нет.