5.1.0 Появилась проблема с переадресацией портов, отличных от 80

[Andrew Voronkov]

Обновился с 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 сервера - опять открывается роутер, а не сервер. 

 

Изменено Пятница в 19:25 пользователем Andrew Voronkov

[Andrew Voronkov]

Чуть конкретики:

 

После обновления с 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 для сравнения.

[Andrew Voronkov]

Похоже на регрессию в обработке публикаций KeenDNS/NDNS в 5.01.C.0.0-1 для сценария “устройство/MAC + нестандартный HTTP-порт” и отдельно для port forwarding через облачный KeenDNS.

Факты:

1. В конфигурации 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.

2. В конфигурации 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 тоже остался.

3. DHCP-привязка <HA_MAC> → <HA_IP> присутствует в обеих конфигурациях, то есть сам адрес устройства в конфиге не потерян.
4. REST/CLI вывод показывает принципиальную разницу: запись, созданная по IP, формирует нормальный upstream, а запись, созданная через устройство/MAC, даёт пустые поля:

"ha":  "upstream": "<HA_IP>:8123"
"ha1": "upstream": "", "host": ""

5. При этом другие записи, созданные через устройство/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 тот же сервис работает.

[Andrew Voronkov]

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

[Andrew Voronkov]

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