hoaxisr

Ну так оставьте предыдущую версию в одной из секций. Функционал же не пострадает для этой цели.

А еще можно использовать DualBoot с какой-то практической пользой, а не просто хранить две одинаковые копии прошивки. В чем смысла с практической точки зрения просто 0. Можно хранить во второй секции предыдущую конфигурацию и прошивку. Поскольку сейчас реализация dual-boot просто крадет место, но практической пользы не приносит.

На Бета3 роутер пока решил, что должен быть 1 IP у устройства. Буду наблюдать.

Остановите ее пожалуйста, она меня уже пугает. Теперь ее три.

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

Видимо все же проблема на стороне роутера. Потому что после этих манипуляций в списке клиентов я все равно вижу 2 сушилки. И если "провалится" в одну из них, то ее адрес теперь .1.125, даже если я проваливаюсь в 1.75. Уже физически выключал из розетки и роутер и сушилку, роутер включил до сушилки. И один черт я вижу 2 устройства.

И я проголосовал. Белые списки каналов WiFi могли бы быть полезными.

Индикация тоже отличный вариант. По большому счету нужно просто знать, что клиенты находятся/ не находятся в системной политике доступа. Если проще реализовать вариант с индикатором, то это тоже отличное решение.

Но в 5.0 Бета 2 стало сильно хуже надо сказать, теперь устройства повально отображаются как подключенные по кабелю. Просто скопом. 1-2 отображается правильно, а остальные нет. Я уже перестал туда смотреть, потому что информация абсолютно нерелевантная.

О Спасибо за разъяснение. Перезагружу устройства. После перезагрузки как клиента, так и роутера ситуация не изменилась. Клиенты хаотично скачут между вариантами подключения LAN/WIFI и сушилка все равно имеет два адреса. Плюс в Log есть вот такая ошибка, связанная с двумя ретрансляторами: Окт 8 17:07:41 ndm Discovery::Arp::Explorer: "Bridge0": network conflict: hosts 50:ff:20:b4:f4:1c and 50:ff:20:b4:f4:37 have the same IPv4 address 192.168.1.3.

У меня есть устройство - сушильная машина 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 туннелей? Ранее такого в логе не было