Andrew Voronkov

UPD 2. Проблема снова возникает после каждой перезагрузки основного роутера в мэш системе. Решается только полной перезагрузкой клиента. Похоже, это всё-таки баг прошивки 5.1.0.

Upd. Всё решилось полной перезагрузкой всех кинетиков в wifi системе и тех клиентов, на которых наблюдались эти проблемы. Странно, на предыдущих десятках обновлений такого поведения не наблюдал.

Похоже на регрессию в обработке публикаций KeenDNS/NDNS в 5.01.C.0.0-1 для сценария “устройство/MAC + нестандартный HTTP-порт” и отдельно для port forwarding через облачный KeenDNS. Факты: В конфигурации 5.01.B.4.0-1 рабочая публикация Home Assistant была задана через устройство/MAC на порт 8123: ip http proxy ha upstream http <HA_MAC> 8123 domain ndns ssl redirect security-level public Эта же версия также содержала проброс 591 → <HA_MAC>:8123. В конфигурации 5.01.C.0.0-1 исходная запись через MAC сохранилась, а дополнительно был создан тестовый вариант через IP: ip http proxy ha1 upstream http <HA_IP> 8123 domain ndns ip http proxy ha upstream http <HA_MAC> 8123 domain ndns При этом проброс 591 → <HA_MAC>:8123 тоже остался. DHCP-привязка <HA_MAC> → <HA_IP> присутствует в обеих конфигурациях, то есть сам адрес устройства в конфиге не потерян. REST/CLI вывод показывает принципиальную разницу: запись, созданная по IP, формирует нормальный upstream, а запись, созданная через устройство/MAC, даёт пустые поля: "ha": "upstream": "<HA_IP>:8123" "ha1": "upstream": "", "host": "" При этом другие записи, созданные через устройство/MAC, но на стандартный HTTP-порт 80, работают. В конфиге таких записей несколько: domofon, road2, pool — все через MAC и порт 80. Вывод по HTTP Proxy: ломается не сам MAC-resolve вообще, а конкретная комбинация: запись KeenDNS, созданная через устройство/MAC, с upstream на нестандартный HTTP-порт 8123. При создании той же публикации по IP upstream формируется корректно. Вывод по port forwarding: правило 591 → <HA_MAC>:8123 в конфигурации сохранилось после обновления, но через облачный KeenDNS стало отдавать 403 Forbidden. Поскольку по другому клиенту порт 280 → 80 работает, это не общая поломка облачного доступа, а проблема с обработкой конкретных нестандартных портов/целей в облачном режиме KeenDNS. Формулировка гипотезы: в 5.01.C.0.0-1 появилась регрессия в слое KeenDNS/NDNS cloud publication, связанная с обработкой внутренних сервисов, заданных через объект устройства/MAC и нестандартный TCP-порт. Дополнительно похожая регрессия проявляется в port forwarding через облачный KeenDNS: правило есть, но внешний доступ через domain:591 возвращает 403. В UI запись через устройство/MAC отображается как <HA_IP>:8123, но в REST/CLI proxy backend для неё имеет upstream="" и host="". Та же запись, созданная вручную по IP, формирует upstream корректно. Одновременно port forwarding на тот же хост и порт через облачный KeenDNS возвращает 403. Обе проблемные схемы используют один и тот же объект назначения по MAC: <HA_MAC> → 192.168.1.123 → 8123 И обе ломаются после обновления: ip http proxy через <HA_MAC>:8123 → upstream пустой / не тот сервис ip static 591 → <HA_MAC>:8123 → через KeenDNS отдаёт 403 При этом вариант: ip http proxy через 192.168.1.123:8123 работает. Значит наиболее аккуратная гипотеза: В 5.01.C.0.0-1 сломалась обработка назначения, заданного через MAC/объект устройства, для внешней публикации сервиса Home Assistant на нестандартном порту 8123. Это проявляется и в ip http proxy, и в ip static port forwarding через облачный KeenDNS. Обе неисправности объединяет один и тот же способ указания цели: не IP-адрес, а устройство/MAC. При указании IP тот же сервис работает.

Чуть конкретики: После обновления с 5.01.B.4.0-1 на 5.01.C.0.0-1 в облачном режиме KeenDNS (без белого IP) обнаружены два изменения поведения, которых ранее не было. Проблема 1. Переадресация через KeenDNS стала возвращать 403 Используется стандартная переадресация порта на внутренний сервис: ip static tcp <WAN> 591 <HOST_MAC> 8123 Данная запись присутствует как в конфигурации 5.01.B.4.0-1, так и в 5.01.C.0.0-1. До обновления работал доступ вида: http://<domain>.keenetic.pro:591 После обновления тот же URL возвращает: 403 Forbidden При этом: внутренний сервис продолжает работать локально; правило переадресации сохранилось; конфигурация не изменялась; проблема появилась сразу после обновления. Проблема 2. Изменилось поведение HTTP Proxy через KeenDNS В рабочей конфигурации 5.01.B.4.0-1 присутствует публикация сервиса: ip http proxy ha upstream http <HOST_MAC> 8123 domain ndns ssl redirect security-level public После обновления на 5.01.C.0.0-1 данный proxy перестал открывать опубликованный сервис и вместо него отображается веб-интерфейс роутера. Для проверки был создан дополнительный proxy: ip http proxy ha1 upstream http <HOST_IP> 8123 domain ndns ssl redirect security-level public где в качестве upstream используется IP-адрес того же устройства вместо MAC-адреса. Поведение через IP отличается от поведения через MAC, что позволяет предположить возможную проблему в обработке upstream по MAC-адресу. Почему предполагаю связь между проблемами Обе проблемы появились одновременно после перехода с 5.01.B.4.0-1 на 5.01.C.0.0-1. Обе затрагивают механизмы публикации внутренних сервисов через KeenDNS в облачном режиме. При этом: обычная доступность сервиса внутри LAN сохранена; DHCP-привязка MAC ↔ IP не изменялась; записи публикации и переадресации в конфигурации сохранились. Поэтому есть подозрение, что обе неисправности могут иметь общий источник в изменениях работы KeenDNS / NDNS / HTTP Proxy между версиями B.4 и C.0. При необходимости могу предоставить оба startup-config для сравнения.

Обновился с 5.1 beta 4 на 5.1.0 - смотрю внешний доступ к home assistant тут же отвалился. Начинаю разбираться. Вижу две странности с переадресацией. Home Assistant внутри сети у меня по адресу http://192.168.1.123:8123 Первая проблема. У меня настроено его доменное имя таким образом: На 5.1 beta 4 по этому адресу ha.blabla.keenetic.pro извне открывался Home Assistant без проблем, на 5.1 теперь открывает заглавную страницу самого Кинетика (как будто ha. - неверное доменное имя). Стоит поменять на любого другого клиента в сети с 80 портом - тут же по имени открывается этот клиент. Возвращаю 8123 порт и Home Assistant - опять открывается сам роутер. На 5.1 beta 4 всё открывалось нормально и по этому имени Home Assistant был доступен извне. Вторая проблема. У меня настроена переадресация таким образом: На 5.1 beta 4 при переходе извне по blabla.keenetic.pro:591 я попадал в интерфейс Home Assistant. Ha 5.1.0 при переходе извне по blabla.keenetic.pro:591 я попадаю на страницу keendns с кодом ошибки "403 - именно так с одной кавычкой. При этом вторая переадресация на Счетчик с порта 280 на порт 80 работает прекрасно. Меняю в первом адресе в выходе на что угодно с портом 80 - работает, возвращаю Home Assistant и 8123 порт - опять ошибка "403. Итого: на 5.1.0, похоже, появилась проблема с переадресацией на порты, отличные от 80. Причем проявляется она в целом ряде мест. UPD. По совету из tg группы сделал следующее: "укажите "Другой клиент" и ip адрес вашего сервера с HA в доменном имени 4го уровня" и адрес ha.blabla.keenetic.pro снова стал открывать Home Assistant. Но при этом если возвращаю не "Другой клиент", а конкретный ip сервера - опять открывается роутер, а не сервер.

Подскажите, пожалуйста, dns маршрутизация ведь никогда не будет работать для сервера Home Assistant, если он в любой политике Не по умолчанию? Ситуация такая. Сервер в политике авг, но нужно, чтобы только его доступ к серверам xiaomi шел не через авг. А всё остальное - через авг. Если делать через dns маршруты - они не срабатывают, поскольку сервер в политике авг. Если делать через ipv4 маршруты - всё работает отлично, но: 1. В качестве интерфейса я могу выбрать только 1 источник интернета - а у меня их 3 (основной и 2 резервных) и хотелось бы выбрать три. И непонятно, при выбранном одном основном и его падении - коннект пойдет через авг или через резерв? Очередность нигде не настраивается. При настройках добавлять автоматически - вкл, эксклюзивный - выкл. 2. Если xiaomi сменит ip своих серверов - вся эта история превратится в тыкву. Нет ли какой-то хитрости всё-таки с dns маршрутизацией для моего случая (весь коннект сервера через выбранную политику, коннект с серверами xiaomi - НЕ через выбранную политику). Заранее спасибо!

Мне кажется, эта проблема была всегда, она не специфична для пятерки..

Моя wifi система: Контроллер - Репитер 1, Репитер 2, Репитер 3, Репитер 4. При обновлении с беты на 4.3.0 словил баг, что ретранслятор (репитер 1) с назначенным адресом 192.168.1.3 полностью пропал из wifi системы. Оказывается, это служебный айпишник, на 4.3.0 были какие-то изменения по этому поводу (сказали в саппорте, у кого этот адрес используется - лучше освобождайте). В итоге до этого система работала лет 5 с такой адресацией - после обновления на 4.3.0 всё развалилось (на странице wifi системы репитер с 192.168.1.3 висит как офлайн, при этом он в доступе по этому внутреннему адресу, спокойно открывается и тд, но wifi система не работает с ним). НО! Проблема не только в этом! Пока я не понимал, в чем дело, я решил перезахватить этот репитер. Сбросил на дефолт, включил как усилитель, подключил по проводу, захватил - всё по классике. Wifi система его захватила с другим ip - всё заработало, оставил как есть. Но спустя пару часов я заметил, что стали отваливаться клиенты, причём массово так. Два дня я это наблюдал и пытался найти причину. Пока случайно не зашел в свойства одного из отвалившихся клиентов в меню кинетика. Оказалось, что для него перезахваченный репитер почему-то оказался в запрете на подключение. Такая же ситуация оказалась на всех отвалившихся клиентах (штук 15). Убрал Репитер из запрещенных - всё заработало. Итого. Ровно на всех клиентах, где в меню кинетика стоял старый запрет на подключение к Репитеру 2 (он вообще в другом конце территории, на нем запрет стоял много лет) - при перезахвате Репитера 1 (который 192.168.1.3) - в запретах заодно оказался и перезахваченный репитер 1. Мне кажется, такого происходить точно не должно.

Оказывается, их вообще убрали..

Добрый день! Для Netcraze будет бета тестирование через testflight? Полагаю, версия Netcraze в appstore не соответствует последней бете Keenetic app в testflight.

Ого ничего себе! Никогда бы не догадался, что надо выбрать репитер галкой и только тогда появится интерфейс для его редактирования. Спасибо! P.S. Но дельту там всё равно не выбрать. В общем, странное решение. Не хватает там пункта "не выбрано", чтобы выбор остался на стороне репитера, как раньше.

В упор не вижу эту настройку в вебе в wifi системе на 4.2.3 (((

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

У меня в мэше устройства в разном статусе добавлены за последние годы - и как тд, и как усилитель. И там, и там - недоступна смена каналов. Возможно, вам помогла именно настройка с нуля, а не смена типа устройства в мэш. Кроме того, через приложение канал меняется, так что все-таки баг, а не фича )

4.2.1 - НЕ исправлено (