t800

Яндекс не проверял, но 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-систему

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

@Xambeyтакого функционала нет, увы. Я решил это "от противного": всё по дефолту идёт в VPN за исключением тех ресурсов, которые через VPN работать отказываются. Благо их не так много.

Только маршрутизацией по подсетям.

Где в вашем исходном сообщении вы пишете о доменах? Цитата: "Очень хочется иметь возможность создать список хостов, которые будут ходить через определенный интерфейс (vpn например)".

Именно в таком виде (привязка хост-подключение) невероятно актуальная фича давно реализована и прекрасно работает. См. раздел управления "приоритеты подключений"

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

Спасибо за ответ. Но хочу пояснить почему вообще возник мой вопрос. Я предполагал, что 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-сервера, он просто разрешает входящие соединения извне! Тем не менее, такой ответ предоставлен официально, я на него дал свои комментарии, но хотел бы услышать мнение сообщества. Может я чего-то не понимаю и исходно неправ в ожиданиях?

Собрал wifi-систему (Giga - основной + Air и Extra - репитеры), стык медью, бэкхол выключен. Для AppleTV после регистрации настроил запрет работать через Air и Extra, чтобы не прыгал с точки на точку. В итоге, когда перезагружал wifi на гиге, appletv перескочил в экстру и назад не вернулся. Логика работы настройки непонятна. Буду признателен за пояснения и решение. Скриншоты и селф-тесты - в следующем сообщении

@Le ecureuil Плюсану по проблеме с хардовым шифрованием. У меня это выглядит как постоянные проблемы с RDP. Он просто зависает каждые 10-60 секунд до момента пока клиент не сделает реконнект. При этом пинги с сервера до клиента идут нормально. По совету Максима Анисимова сегодня включил software режим и всё заработало отлично. Изменение MTU lj 1200 в режиме hardware не помогало. Интернет у меня pppoe с фиксированным белым IP.

Добрый день В настоящее время wifi-система реализована по принципу "всё или ничего". Или точка доступа захвачена и на ней развёрнуты все сегменты, что и на контроллере, или точка должна работать независимо. Тем не менее, вовсе не всегда нужно копировать конфигурацию всех сегментов. Например в том случае, если нужно пространственно изолировать определённых клиентов и исключить саму возможность случайных переходов на другую точку доступа. Я предлагаю два варианта доработки: простой и посложнее: 1. В каждом сегменте сделать чек-бокс "передавать участникам wifi-системы". Если чек-бокс активен, ок, все подчинённые девайсы будут получать конфигурацию данного сегмента; если не активен - соответственно этот сегмент останется только на контроллере 2. То же самое, что и вариант №1, но с возможностью задания конкретных точек доступа, куда настройки данного сегмента будут копироваться.