Возможность удаленного доступа к приложениям локальной сети без разрешения удаленного доступа к конфигуратору

[sbat]

Keenetic имеет встроенный удобный обратный прокси HTTPS, с помощью которого можно дать доступ к ресурсам локальной сети (NAS, видеокамера, собственный веб-сервер для разработки). Это очень удобно! Особенно учитывая, что Keenetic берет на себя все заботы с Let's Encrypt сертификатами. 

Однако, как стало понятно из дискуссии в комментариях к соответствующей статье, для этого обязательно необходимо разрешить и удаленный доступ к веб-конфигуратору: https://help.keenetic.com/hc/ru/articles/360000563719?utm_source=webhelp&utm_campaign=3.01.C.10.0-0&utm_medium=ui_notes&utm_content=controlpanel/remoteaccess

Предлагаю дать возможность разрешать доступ к внутренним ресурсам сети по адресам типа https://xxx.yyy.keenetic.link/ без обязательного разрешения удаленного доступа к веб-конфигуратору по адресу https://xxx.keenetic.link/. Аналогичная возможность уже есть для внутренних сервисов Keenetic (Transmission). 

Все-таки чем меньше интерфейсов доступно из публичного интернета, тем выше безопасность. Наверное, было бы достаточно, если бы такая тонкая настройка была доступна только CLI.

Edited November 11, 2019 by sbat

[JIABP]

Поддержу.

[keenet07]

А дополнительно заблокировать правилом доступ к админке в Межсетевом экране разве нельзя в этой схеме?

Но наличие такой галочки поддержу.

Edited November 11, 2019 by keenet07

[r13]

2 минуты назад, keenet07 сказал:

А дополнительно заблокировать правилом доступ к админке в Межсетевом экране разве нельзя в этой схеме?

Но наличие такой галочки поддержу.

Тогда все заблокируется, а не только админка

[keenet07]

Так это смотря что и где блокировать. Можно заблокировать только внутренние запросы или ответы админки ещё до ухода в туннель. Нужно только выявить правильный интерфейс, адрес и порт.

Edited November 11, 2019 by keenet07

[sbat]

1 minute ago, keenet07 said:

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

У меня была такая мысль, но я не смог выявить правильный интерфейс, адрес и порт.

1) Нельзя заблокировать SSL из внешней сети, иначе заблокируется все. 

2) Нужно как-то заблокировать взаимодействие https reverse proxy (nginx?) и веб-интерфейс админки, но я а) не уверен, что это вообще реализовано как сетевое взаимодействие б) управляется межсетевым экраном. 

Если у кого-то есть мысли, как можно сформулировать такое правило, буду рад! 

[keenet07]

Не могу попробовать это у себя, не пользуюсь KeenDNS. Единственное могу подсказать, что тут очень поможет функция роутера Захват пакетов. Прослушиваете пакеты в разных вариациях интерфесов и смотрите что куда отправляется. 

Проще было бы конечно у разработчиков уточнить, но они как правило не очень любят как-то комментировать некоторые аспекты внутренней кухни.

Edited November 11, 2019 by keenet07

[K1fa]

поддерживаю

[Le ecureuil]

Да, сейчас так можно сделать, особенно учитывая, что уже SSTP и WebDAV включаются, но доступа к Web не появляется при ip http security-level private.

Надо подумать.

[antonwantstosleep]

Здравствуйте! Есть ли новости по данному вопросу? Тоже очень заинтересован в этой фиче.

[OlegOs]

Здравствуйте ! Тоже давно жду, хочется сделать доступ извне к некоторым службам, не давая доступ к админке !

[Le ecureuil]

Смотрю это активная тема. Постараемся ускорить.

[Аркадий]

Странно, что это обсуждается. Внешнее управление роутером никому не нужно. Прошу разъединить, т.е. убрать зависимость управления роутером с доступом снаружи к приложениям локальной сети. То, что касается домена 3-го, то его данные должны хранится в службе KeencDNS, а 4-ого уровня — как удобней разработчику.

[Le ecureuil]

Реализовано в 3.5 Alpha 16