t800

@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-сервере?

Добрый день Столкнулся вот с такой ситуацией. Есть два кинетика. Локальный - Гига-1 и удалённый - Гига-2. Настройки ssh-сервера у меня в Гиге-1: ip ssh security-level private lockout-policy 5 15 3 session timeout 3600 То есть, явно указано, что принимаются входящие соединения только с интерфейсов, где security-level установлен = private. Далее, в Гига-1 настроен WG-туннель до Гига-2. Интерфейс имеет уровень public: interface Wireguard0 description WG-Tunnel security-level public ip address 10.0.0.2 255.255.255.0 ip mtu 1324 ip access-group _WEBADMIN_Wireguard0 in ip tcp adjust-mss pmtu wireguard peer *** !WG-S endpoint ****:16332 keepalive-interval 30 allow-ips 10.0.0.0 255.255.255.0 allow-ips 192.168.1.0 255.255.255.0 allow-ips 192.168.2.0 255.255.255.0 При этом ssh соединения, входящие на этот интерфейс (из сети с Гига-2) без проблем устанавливаются с сервером на Гига-1. Открыл кейс в поддержку. Первый ответ был вообще удивительным. Мол, исходно соединение приходит из Home сегмента удалённого кинетика (Гига-2), где тип интерфейса - private. Поэтому Гига-1 принимает входящие ssh соединения. На мой вопрос откуда известен тип исходного интерфейса, особенно если на удалённом конце мог быть НЕ кинетик вообще, я получил второй ответ. Что соединение устанавливается, потому что у меня есть аксесс-лист, разрешающий входящие соединения из удалённой сети. Но это же ерунда, аксесс-лист не меняет тип интерфейса и не меняет логику ssh-сервера, он просто разрешает входящие соединения извне! Тем не менее, такой ответ предоставлен официально, я на него дал свои комментарии, но хотел бы услышать мнение сообщества. Может я чего-то не понимаю и исходно неправ в ожиданиях?