t800

@Le ecureuil По журналу диагностики видно, что профиль присваивается, но по тестам упорно используется Adguard DNS. Тест был не единственный, профили пробовал разные. Один или два раза тест показал корректный DNS, но закономерности никакой я не уловил. Если нужно провести тест по какой-то конкретной методике - дайте знать, я выполню и пришлю логи. Селфтест - ниже в скрытом сообщении

@vst Добрый день! Есть новости по NDM-2928? Спасибо

@vst @hellonow Не удалось локализовать проблему?

@vst Можете сказать, этот кейс в работе, или еще не рассматривался?

4.0.2 - ситуация не изменилась. При любом варианте кроме «присвоенный сегменту» кинетик упорно перенаправляет запросы в adguard. Не взирая на настройки клиента @Le ecureuil посмотрите проблему?

Перезагрузка не решила проблему

Ситуация: дети пожаловались на то, что внезапноYyoutube заработал в безопасном режиме, хотя ничего не предполагало. Проверил профили DNS - стояли сервера Cloudflare защита по-умолчанию. Потом сам внезапно получил в браузере заглушку от Adguard DNS, мол сайт для взрослых. Стал проверять (используя dnsleak.com), оказалось, что не смотря на выбранный профиль, всё время используются сервера Adguard. Выключил публичные фильтры - всё нормально заработало по схеме segment default. Включил - снова Adguard. При этом настройки все верные. Снял self-test и еще попробую перезагрузиться. Если что-то изменится напишу чуть позже.

@vst А по этой проблеме есть понимание о причинах? Спасибо.

Яндекс не проверял, но adguard и cloudflare точно не работают. И это только в 4.0а18. Откатился на 3.9.6 - всё заработало снова. Пробовал дважды, результат один и тот же.

До кучи перестал интернет работать: поломались днсы. Гора вот таких сообщений: Dns::Secure::DotConfigurator: unable to obtain addresses for "cloudflare-dns.com". и так для всех днс. Пришлось откатить на 3.9.6. Впервые за все время так фатально поломалась альфа

@hellonow Я прошу прощения за деревянность, но я не понимаю, какая связь между включением/выключением PC, подключённого в ethernet-порт экстендера, рестартом DHCP на контроллере (откуда информация о его рестарте?), и уведомлением об отключении экстендера от сегмента. Почему тогда по второму экстендеру нет никаких проблем в этот момент? В техподдержку - ок, могу открыть кейс, но обычно они рекомендуют по бетам и драфтам писать на форум.

@hellonow прошу прощения, будет какой-то комментарий по этому вопросу? Проблема никуда не делась, воспроизводиться 100% чётко.

@hellonow понимаете, получается так, что линк падает всегда когда ПК включается и выключается. Как такое может быть? FastEthernet0/1 - это порт, куда включён комп. Получается, что up и down по этому порту провоцирует сетевую недоступность шлюза через FastEthernet0/0. Быть может с чипом какая-то проблема? А самое главное, не было такого раньше. Мне не пришло в голову зафиксировать момент, когда впервые стали приходить эти уведомления, но началось это именно на 3.9

Чтобы было проще копать в файле диагностики: последний раз проблема наблюдалась сегодня, 24.11.2022 ~10:20 Из облака пришло два пуш-сообщения в телефон.

Привет Keenetic Air (KN-1610) RU (в режиме экстендера) после обновлений до одной из альф 3.9 внезапно стал рапортовать через приложение Keenetic аварии по отключению от домашнего сегмента. Аварии короткие, почти сразу приходит уведомление о том, что соединение восстановлено. Закономерность удалось поймать: это совпадало с включением/выключением ПК, включенного в ethernet порт. У меня достаточно большой парк кинетиков, больше ни на одной модели такого не наблюдается. Диагностика - в скрытом посте. @Le ecureuil

Мелькает в диагностике экстендеров строка: Селф-тест добавлен в скрытое сообщение Upd. Сообщение появляется в отладке после того как я захожу в "Изменить список установленных компонентов" Core::Configurator: not found: "show/rc/ntp/master" [http/rci].

Аналогично. Пробовал с айфона пока, правда. Ни в сафари, ни в хроме нет страницы Upd. Проверил на айпаде - та же история. Под виндой - норм, тестировал в хроме. В общем, похоже, что с IOS девайсами какая-то несрастямба у WebUI вышла в 3.8.1

Проблема решилась полным сбросом ретранслятора и повторным его добавлением в wifi-систему

После обновления вижу ретранслятор в списке незарегистрированных устройств гостевого сегмента. Кроме того, он же присутствует в списке устройств, которые можно добавить в систему. При том, что уже добавлен фактически, и давно. Так и задумывалось?

Да, ок. Я просил вашего коллегу это подтвердить в рамках запроса, но от явного ответа он ушел в тот момент. 🙂 Сейчас всё понятно, спасибо за разъяснения!

Спасибо за ответ. Но хочу пояснить почему вообще возник мой вопрос. Я предполагал, что ACL имеет наивысший приоритет только для сетевых интерфейсов. Ssh-сервер, всё-таки, это служба, пусть и имеющая настройку security-level. Поэтому, разрешив входящий трафик из Wireguard0, я ожидал, что ssh-сервер не пустит входящий коннект от public-интерфейса, раз это явно запрещено. Исходя из вашего объяснения, получается, что ssh-сервер имеет тот же подход в работе уровней безопасности, что и сетевые интерфейсы. Это всё объясняет, но было бы неплохо в какой-то форме отразить это в документации. Допускаю, что я один такой тугой, но всё-таки служба <> интерфейс, отсюда и вопросы.

Отправил в запрос. Виноват, обычно вполне внятно изъясняюсь. Попробую еще раз: 1. Есть два кинетика - Giga и Giga-III, между ними поднят Wireguard-тоннель, имя интерфейса на обоих - Wireguard0 2. На Giga-III Wireguard0 имеет уровень public. 3. Подключения с хостов в домашней сети Giga 192.168.1.0/24 по ssh к Giga-III проходят успешно. На мой взгляд это неверно, потому на Giga-III настроено ip ssh security-level private Я понимаю это так, что ssh-сервер должен принимать входящие соединения только с интерфейсов с уровнем private. Таким образом, с Wireguard0 ssh-соединения в текущей конфигурации проходить не должны. Но они проходят, и я хотел бы разобраться в причинах.

Не отправлял, только куски конфигурации. Но инженер поддержки и не просил, с его точки зрения всё очевидно, а я неправ в своих ожиданиях. Посмотрите - запрос № 578948

Приоритет выше для интерфейса же, на котором ACL создан, а не для всех прочих интерфейсов или компонентов, имеющих настраиваемый уровень безопасности. Есть. Разрешён входящий трафик по протоколу IP; источник - удалённая сеть (192.168.1.0/24), цель - локальная сеть (192.168.0.0/24)

Согласен. Только причём здесь ssh-сервер? ACL это набор запретов и разрешений для интерфейса. Для ssh-сервера я не создаю никаких ACL. Почему ACL на интерфейсе Wireguard0 оверрайдит прямой запрет на коннект с public интерфейсов на ssh-сервере?