C-M

зеленый => значит что на странице /wired/GigabitEthernet1 Ethernet Cable - CONNECTED Check the Availability of the Internet (Ping Check) - AVAILABLE через CLI не проверял, но роутинг в подключенный резервный канал не шёл, пока GigabitEthernet1 был включен как интерфейс.

Ситуация: WAN интерфейс подключен ко внешнему роутеру, за которым интернета нет. Наличие или отсутствие подключенных резервных каналов не влияет. Проблема: ping check для WAN в любых режимах режимах (tls/tcp/ping) показывает зелёный, хотя указан недоступный адрес. Если указать DNS имя, а не IP, но тоже зелёный, но в логах будет ошибка: PingCheck::Profile: "_WEBADMIN_GigabitEthernet1": failed to resolve "...". После смены режима ping check, зелёный возвращается через 1-2 интервала проверки. Проверено, что при отсутствии резервного, с самого кинетика пинги на внешний IP не проходят, но ping check стабильно выдаёт зелёный. Если же роутер перезагрузить то зелёный для нерабочего WAN возвращается не сразу, но возвращается. Разброс по времени очень большой - может позеленеть за пару минут, а может через час. Всё это время интернет на внешнем роутере отключен полностью. Подскажите пожалуйста, как это чинить? Спасибо PS: до 5.x такого не наблюдалось

Да ну как бы вреда устройству не было, и не сказать что тут есть повод для извинений за само обновление. Тут другая проблема. Через какой-то же механизм 4.* обновляется в обход мнения владельца устройства? И очень похоже, что в 3.* этого механизма нет. Однако и в истории изменений такой фичи нет. Что приводт к вопросу "а почему это скрыли", и нормальный админ, как профессиональный параноик, начинает думать о всяком нехорошем. И сложно что-то с собой поделать - работа такая. Да, такой вектор атаки (что у устройства есть backdoor от производителя) и ранее предполагался, но благодаря репутации разработчиков, рассматривался как хоть и опасный, но крайне маловероятный. Теперь же случилось подтверждение, что этот риск реализован. А это значит, что его уже нельзя игнорировать, надо закрывать реализованный риск. Но и тут опять включается непонятная политика "сокрытия" - нет полноценной информации, куда подключается роутер - какие внешние соединения, к каким адресам и с какими конкретными возможностями. Статья на сайте есть, но для этих целей уровень деталей в ней недостаточный. На явные запросы полноценных ответов тоже нет, максимум что было получено "Мы не раскрываем точный список адресов и имен, поскольку они могут и будут меняться в зависимости от наших внутренних потребностей". Хотя там список то на 10 позиций максимум, его вряд ли сложно собрать и обновить. Это уже идёт как "противодействие". Т.е. в итоге мы имеет - не только реализованный риск, но ещё и пару каноничных "красных флагов". И выходит, что у админа выбор не велик - или скрыть инцидент, или закрывать его, либо внешними средствами либо сменой оборудования. К чему тут извинения? Просто гемор, просто работа. Просто не ожидал

Понятно, спасибо за информацию. Но это же и куда более печально, что даже не упомянули о добавлении механизма управления устройством без ведома владельца😢

к работе разработчиков претензий нет - на качестве их работы и основывалась упомянутая ранее "толика доверия". Но принудительное обновлении говорит о проблемах не связанных с разработчиками: - наличие управляющего механизма, который был заложен заранее, без явных упоминаний - да, release notes всегда читаю, и про TR-098, TR‑069 писали, но подавалось как фишка "на заказ", никаких упониманий про её включение не было. - наличие менеджмента, который считает, что его мнение самое правое, при чём не один раз. Потому как сначала принято решение: (a) заложить такую фичу (3.х же не обновился) (b) никому про это не сказать явно - а это в 90% значит, что там не только обновление накатить можно (с) сделать такую фичу неотключаемой ... хотя это скорее следствие (b), а не отдельное решение (d) применить эту фичу, при чём не у тех кому надо, а скорее у тех у кого смогли. И я всё ещё уважаю то, что делают разработчики Кинетика. Но с такими привычками у менеджмента Кинетика мне лично не по пути. Жаль, с Кинетиком было удобно.

например, на днях обновился Peak (KN-2710), 4.3.6.1 -> 4.3.6.3, который был с сильными паролями, с отключенными обновлениями, но с подключением к cloud. Другие коробки, которые были без подключения к cloud не обновились. Жаль конечно. Была надежда и толика доверия к Кинетику, что доступ к роутеру закрыт паролем в app'ке и для Cloud/KeenDNS инфраструктура Кинетика работает только тунелем, без управляющего доступа. Оказалось что нет. Пришлось отрезать самостоятельно.

спасибо! Ту статью посмотрел, но к сожалению даже в web.archive она изначально без ссылок. Возможно, что была по другому адресу. В теме про диагностичесй модуль нашёл только ndss.keenetic.ndmsystems.com (а сейчас есть ещё ndss.keenetic.ndmsystems.ru). Ну и из уже известного ndss.keenetic.com / ndss.keenetic.net / ndss.netcraze.ru Буду признателен, если сможете что-то ещё подсказать. PS: ещё знаком с неувядающей классикой "Мы не раскрываем точный список адресов и имен, поскольку они могут и будут меняться в зависимости от наших внутренних потребностей" ... видимо такой большой список, что надо куда больше усилий, чем фильтровать регулярные release notes 🤣

Уважаемые @keenet07 и @krass подскажите пожалуйста, какие DNS имена надо блокировать чтобы роутер к серверам C&C обновлений не ходил?

уверен, что не часто но в правилах вроде и не написано "не пишите если вас не рать". Но в целом посыл понял - более беспокоить не буду, спасибо за разьяснения местной политики.

спасибо, я в курсе про галочку - только врядли бы тут оценили, если б я начал цитировать мануал для полноты моего комментария. Так вот, речь то именно про карточку Интернет - там надо бы возможность вручную выбирать соединения. Давайте я ещё раз опишу проблему: 1. есть два _физических_ соединения с интернетом 2. есть ~20 VPN соединений с другими сетями и/или VPN серверами на которых стоит галочка "использовать для интернета". Причин тому иного, в том числе, потому что есть куча политик, и разные хосты и сегменты сети выходят в интернет через разные точки. 3. и есть другие соединения (их тут не рассматриваем - не про интернет, ок). Так вот с т.з. подключения к интернету - п.2 нет смысла показывать в карточке, т.к. если нет физических соединений, то и все эти каналы накрываются шляпой. Но в текущей логике карточки они висят длинным и бесполезным списком. М.б. можно добавить хотя бы "показывать первые Х соединиений"?

на самом деле наличие NAT (что и включается галочкой) не всегда однозначно говорит о подключении к интернету. Например, есть удалённые сети с одинаковыми адресными диапазонами, где переделать весьма сложно, проще включать NAT.

Для оптимизации нагрузки на сеть от системы хранения используется bridge с одним IP поверх нескольких интерфейсов с разными MAC (aka Adaptive Load Balancing) и с подключением разных интерфейсов к нескольким keenetic'ам собранным в mesh. В принципе, это работает, но в логи кинетика постоянно сыпятся предупреждения о разных MAC для одного IP, ну и информация о точке подключения в UI кинетика постоянно "прыгает". М.б. это можно как-то "полечить"? Спасибо

Извините если не в тот раздел - не знаю, это ограничние UI или прошивки. Было бы оч полезно иметь выбор, в какой сегмент происходит авторегистрация нового клиента. Т.е. конкретно сейчас у меня Home это сеть с фильтрацией по MAC и там авторегистрация в принципе не пройдёт, а для гостей есть отдельная сетка, где как раз авторегистрация была бы полезна. Но в UI текст у галочки не предоставляет выбора

поддерживаю тему с возможностью скрытия соединений. Проблема в том, что сейчас все соединения считаются как Backup - хотя на самом деле, это туннели к другим сетям, и они не являются соединениями с интернетом (ни первичными ни резервными) - они производные от других соединений, и таких может быть много (у меня их более 20 штук). Т.е. в идеале бы иметь вообще две карточки - одна именно для первичных подключений, а вторая для всего остального. Ну или возможность иметь несколько подобных карточек, где набор соединений выбирается руками ...

М.б. усилить цветовые отличия вкл/выкл положений переключателей в тёмном режиме? В светлом более-менее нормально, а в тёмном разница в цвете воспринимается только в сравнении.