slydiman

Я правильно понимаю что при удалённом компоненте Cloud services agent (и соответственно неработающем KeenDNS) поднять OpenConnect server на роутере не получится из-за невозможности подсунуть свой сертификат? То есть ровно такая же проблема как тут?

Так и сделал, хотел написать, а тут уже такой же ответ.

Это никак не поможет. Статья, на которую я дал ссылку в первом посте, не просто так появилась.

Есть 3 интернет провайдера и 3 роутера Keenetic. Роутеры имеют IP 192.168.1.1, 192.168.8.1, 192.168.9.1 Каждый роутер подключен к своему провайдеру, за каждым роутером свои сервера. На первом роутере который 192.168.1.1 помимо основного WAN1 настроены WAN2 и WAN3 и подключены к двум другим роутерам. На первом роутере этим WAN портам соответствуют IP 192.168.8.100 и 192.168.9.100 Это позволяет клиентам первого роутера настроить через какого провайдера (или нескольких с балансировкой) ходить в интернет. Также из сети 192.168.1.х можно спокойно попасть в админку 2-го и 3-го роутера просто открыв в браузере 192.168.8.1 или 192.168.9.1 Проблема возникла когда на первом роутере настроился WireGuard сервер, пусть будет подсеть 172.16.82.х Так вот задача VPN клиенту попасть в админку 2-го и 3-го роутера. Ситуация в точности как описано тут https://help.keenetic.com/hc/ru/articles/4403101043218-Доступ-в-веб-интерфейс-USB-модема-за-VPN-клиентом-Wireguard-туннеля Только там вместо 2-го роутера 4G модем, но суть та же. Всё решается добавлением очень странной переадресации ВСЕГО, где вход - это целая подсеть 172.16.82.х (которая VPN). Тут слушается целая подсеть и если указать конкретный хост вместо подсети, то это не работает. И собственно сама проблема - подсеть VPN можно перенаправить только на ОДИН адрес, то есть например на 2-й роутер. Тогда VPN клиент имеет доступ на 192.168.8.1, но не имеет доступа к 192.168.9.1 Как сделать чтобы VPN клиент имел доступ к обоим роутерам 192.168.8.1 и 192.168.9.1 одновременно?

Не понимаю что значит может использовать только сертификаты от LE. Не важно как получен сертификат. Он где-то хранится. Что мешает туда же записать его просто из веба? Ладно, всё понятно. Спасибо что на сегодня хотя бы ещё можно удалить компонент Cloud services agent. Эх, шикарный был облачный сервис. В новом облаке обнаружил подписку на уведомления в телеграм - просто супер, знаешь когда кто домой пришёл, телевизор включил. Но времена нынче такие, что приходится выбирать и чем-то жертвовать.

Чтобы без реверс прокси на третьих девайсах я поднимаю (слово из 3х букв которое нельзя называть) до роутера и захожу по HTTP на внутренний IP роутера. Но хотелось бы без костылей. Все остальные девайсы сети зависят от роутера. Делать саму админку роутера зависимой ещё от каких-то девайсов - так себе решение.

Он у меня просто есть со всеми ключами, причем wildcard, ибо за этим роутером куча сайтов и сервисов с этим сертификатом.

Я удалил не KeenDNS, а Cloud services agent, потому что он делал лишнего даже при выключенной галочке Keenetic Cloud access. Отдельно компонент KeenDNS поставить не возможно. Я не очень понимаю что за acme компонент и зачем ему KeenDNS. Есть обращение к WEB UI снаружи по HTTPS. WEB сервер должен использовать какой-то сертификат для TLS/SSL хэндшейка. Нужно как-то дать ему этот сертификат и всё. Ни KeenDNS, ни acme, ни Let's encrypt в этом никак не должны участвовать.

Я правильно понимаю что указать свой домен (и сертификат) для доступа к роутеру снаружи нельзя? Только *.keenetic.pro или .link через KeenDNS и всеми облачными тараканами? Возможно ли добавление такой опции в будущем?

Когда облако всё видит даже при выключенной галочке Keenetic Cloud access - это напрягает. В связи с непонятками вокруг переезда на netcraze снёс нафиг Cloud services agent, ибо непонятно кому он ещё стучит и о чём. При удалении Cloud services agent пропал и KeenDNS. В Remote Web interface connections стоит HTTPS only. У меня белый статический IP и свой домен. Я не использую никаких DynDNS и пр. Как указать роутеру свой домен чтобы при обращении снаружи не получать ERR_SSL_UNRECOGNIZED_NAME_ALERT? Заранее спасибо

При включении комуфляжа в адрес добавляется ?secret_word Секретное слово разумеется ваше, прописанное на сервере. То есть если на клиенте адрес был https://my_server/, то становится https://my_server/?secret_word В данном примере подразумевается порт 443 стандартный для https.

Тоже было 10..18 мбит. Заменил роутер на Hopper SE (KN-3812) - стало лучше, почти 100 мбит. Другие утверждали что и 150 тянет. Кстати, что за провайдер, где VPS, если не секрет?

Было ощущение что тегирование - это тегирование, а не порча IP пакетов, приводящая к тому что 99.9% устройств перестают понимать трафик. Самый ценный ответ был: 802.1q

Воткнул в POE шлюз SSC-PS308G. Там 8 POE портов, 2 гигабитных uplink LANs и SFP. Есть 2 режима VLAN - port и tag. В режиме port, только POE портам можно выбрать VLAN group от 1 до 8. При этом 2 LAN порта никак не настраиваются. Из китайской документации: Очевидно очепятка. Всё бы хорошо, если бы можно было задействовать не только POE порты. Выбирать двум POE портам отдельную группу, в один порт втыкать камеру, а другой POE порт в роутер (в тот самый LAN4, через POE сплитер разумеется) - видимо единственное решение. В режиме tag можно POE портам прикрутить PVID от 2 до 4096. При этом двум LAN и SFP порту прикручено 1 и поменять нельзя. Из китайской документации: Видимо это всё мало полезно. Вывод - просто забыть про тегирование VLAN. Всем спасибо.

Давайте конкретику. IP камеры 192.168.4.2, ей его выдал роутер по DHCP. Далее без перезагрузок роутера или камеры я включаю VLAN ID 4 на порту, куда воткнута камера, трафик становится тегированный. Как получить доступ к камере хотя бы из домашней сети с 192.168.1.x? > Если камера не умеет тэгированный трафик, то тут только VLan на основе портов. Не умеет что конкретно? Тут и есть VLAN на основе портов. В вопросе #1 камера втыкается в порт роутера, которому прикручен VLAN ID 4. В вопросе #2 камера втыкается в порт шлюза, которому прикручен VLAN ID 4. Как получить доступ к камере из домашней сети, которая в роутере 192.168.1.x и которой не задан VLAN ID? В вопросе #2 нужно ещё как-то сегмент CAM в роутере прикрутить к VLAN ID 4, не тегируя при этом никакой физический порт роутера.