C-M
Участники форума-
Постов
14 -
Зарегистрирован
-
Посещение
-
Победитель дней
1
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент C-M
-
Да ну как бы вреда устройству не было, и не сказать что тут есть повод для извинений за само обновление. Тут другая проблема. Через какой-то же механизм 4.* обновляется в обход мнения владельца устройства? И очень похоже, что в 3.* этого механизма нет. Однако и в истории изменений такой фичи нет. Что приводт к вопросу "а почему это скрыли", и нормальный админ, как профессиональный параноик, начинает думать о всяком нехорошем. И сложно что-то с собой поделать - работа такая. Да, такой вектор атаки (что у устройства есть backdoor от производителя) и ранее предполагался, но благодаря репутации разработчиков, рассматривался как хоть и опасный, но крайне маловероятный. Теперь же случилось подтверждение, что этот риск реализован. А это значит, что его уже нельзя игнорировать, надо закрывать реализованный риск. Но и тут опять включается непонятная политика "сокрытия" - нет полноценной информации, куда подключается роутер - какие внешние соединения, к каким адресам и с какими конкретными возможностями. Статья на сайте есть, но для этих целей уровень деталей в ней недостаточный. На явные запросы полноценных ответов тоже нет, максимум что было получено "Мы не раскрываем точный список адресов и имен, поскольку они могут и будут меняться в зависимости от наших внутренних потребностей". Хотя там список то на 10 позиций максимум, его вряд ли сложно собрать и обновить. Это уже идёт как "противодействие". Т.е. в итоге мы имеет - не только реализованный риск, но ещё и пару каноничных "красных флагов". И выходит, что у админа выбор не велик - или скрыть инцидент, или закрывать его, либо внешними средствами либо сменой оборудования. К чему тут извинения? Просто гемор, просто работа. Просто не ожидал
- 588 ответов
-
- 13
-
-
Понятно, спасибо за информацию. Но это же и куда более печально, что даже не упомянули о добавлении механизма управления устройством без ведома владельца😢
-
к работе разработчиков претензий нет - на качестве их работы и основывалась упомянутая ранее "толика доверия". Но принудительное обновлении говорит о проблемах не связанных с разработчиками: - наличие управляющего механизма, который был заложен заранее, без явных упоминаний - да, 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 текст у галочки не предоставляет выбора
-
- 5
-
-
поддерживаю тему с возможностью скрытия соединений. Проблема в том, что сейчас все соединения считаются как Backup - хотя на самом деле, это туннели к другим сетям, и они не являются соединениями с интернетом (ни первичными ни резервными) - они производные от других соединений, и таких может быть много (у меня их более 20 штук). Т.е. в идеале бы иметь вообще две карточки - одна именно для первичных подключений, а вторая для всего остального. Ну или возможность иметь несколько подобных карточек, где набор соединений выбирается руками ...
-
М.б. усилить цветовые отличия вкл/выкл положений переключателей в тёмном режиме? В светлом более-менее нормально, а в тёмном разница в цвете воспринимается только в сравнении.
- 1 ответ
-
- 4
-
-
-
чисто в плане пожеланий: м.б. может можно сделать возможность открывать лог полностью на всю страницу, без лишних элементов? Чтобы лог он не закрывался по клику вне окошка. А то после 4.2.1 окошко лога совсем маленькое по ширине и не регулируется Ну и кнопка (на каждой строке) "скопировать запись лога" в clipboard была бы полезна. Спасибо
-
- 1
-
