Le ecureuil

В 4.3 оно и так уже есть.

Если есть возможность, проверьте на версии 4.3.

В альфе никто и не обещал, что будет как-то иначе.

Хорошее замечание, отвяжем в 4.3, теперь он там не нужен.

Это нормально, ручное управление настройкой disable_ipv6 крайне не рекомендуется. Аналогичного эффекта можно достичь просто не поставив компонент IPv6 - это правильный способ решения.

- из локальной сети соединение установить нельзя, это особенность реализации. - то, что ваш пользователь не имеет к вам доступа даже посредством ping говорит о том, что Keenetic тут не при чем.

Погонял с USB-flashdrive и с USB-SSD дисками для теста в 16 потоков копируя ядро linux (10 тысяч файлов самого разного размера). Да, на USB-flashdrive все туговато, нагрузка на CPU высокая, отвечает медленно, но в итоге все скопировалось хорошо. Основной вклад в нагрузку - это iowait, то есть медленно выполняющиеся операции с накопителем. На USB-SSD все просто летало, нагрузку выше 30% не видел. Вывод - все зависит от накопителя.

Нет, 4.2 вышла в stable.

Нет, с AES-GCM. Сейчас таких скоростей нет, я только сегодня добавил многопроцессорную обработку.

На следующей версии 4.3 скорость работы openvpn + dco на ARM-процессорах должна быть примерно как у wireguard. На KN-1012 у меня получилось в идеальных условиях по 450+ мегабит на прием получать, на отдачу по 300.

Покажите журнал системный в этот момент.

Почему бы тогда ваш домен router.xxxxx.com не завернуть A-записями в адрес роутера и не сделать ip http ssl acme get router.xxxx.com ? В итоге будет все то же самое, только acme-клиент будет получать сертификат без участия keendns и вообще без участия облачных сервисов Keenetic.

А, ну все правильно - вы пытаетесь зайти в роутер по доменному имени, которое ему не принадлежит. Вас блокирует CSRF-защита. Не подскажете, зачем вы авторизуетесь в веб роутера столь странным способом? В качестве решения добавьте очистку заголовкой Origin и Referer в свой прокси, и должно заработать.

Проверьте в дампе или в access-log своего nginx куда же реально приходят запросы.

Присоединении двух Keenetic в ролях клиента и сервера идентификатор не играет никакой роли, потому не думаю что он важен.

На мой взгляд скорее правильно как сделано сейчас, по крайней мере путем перебора снаружи в таком случае невозможно узнать есть ли вообще такая proxy, если она стоит в private. Код 400 же однозначно ее выдает и дальше нужно пытаться подобрать пароль.

Поскольку это не баг, а фича, то делатся будет в порядке очереди.

Более того, официально сжатие не рекомендуется еще и из-за проблем безопасности, потому разработчики его давно перевели в категорию "нерекомендуемых настроек".

Пока подождать, решение возможно, но требует реализации.

Начиная с 4.3 вероятно возможно при помощи ip http proxy upstream connect, лично проверю чуть позже.

Уже есть начиная с версии 4.3.a.4: https://forum.keenetic.ru/topic/15968-openconnect/?do=findComment&comment=193136

На самом деле она скорее для улучшения работы, но в основном есть fallback-механизмы и все будет работать и так. Если будут проблемы, то лучше на них посмотреть отдельно.

В OpenVPN могут приходить маршруты от сервера. Эта галка включает их автоматическое добавление в таблицу маршрутизации.

Да, есть. Для полноценного использования нужно или 2 кинетика на версии > 4.3.a.3, или сервер будет на кинетике на версии > 4.3.a.3 + клиент на версии > 2.6.11. Подразумеваем, что у нас два кинетика, на одном из них есть сервер OpenVPN, и мы хотим его пробросить через KeenDNS. Для этого настраиваем сервер как обычно, только делаем его tcp-server и вешаем его явно на loopback на какой-то явный порт, например вот такой группой команд в конфиге: local 127.0.0.1 port 8000 proto tcp-server Затем на сервере настраиваем ip http proxy типа connect, которая будет указывать в локальный экземпляр сервера (в данном случае берем имя проки ovpn), не забываем включить авторизацию на самой прокси: ip http proxy ovpn upstream connect 127.0.0.1 8000 domain ndns ssl redirect security-level public auth ! Также добавляем юзера tes с паролем pwd, и даем ему доступ по тегу http-proxy. На этом сервер закончен, переходим к клиенту на другом кинетике. Настраивается совершенно обычный openvpn tcp-клиент, который подсоединяется на 127.0.0.1 и порт 8000 (именно ту комбинацию, что мы задали в сервере), и затем указываются параметры proxy, в роли которого выступает KeenDNS: Обязательно указывать опции http-proxy и http-proxy-option, в них должно быть одно и то же: имя вашей proxy на кинетике, доступной по KeenDNS. Логин и пароль для авторизации на этой proxy задаются в виде inline-блока. В принципе, клиент может быть не только на Кинетике, но и где угодно. Inline-параметры для авторизации поддерживаются начиная с версии 2.6.11 в оригинальном клиенте, в более старом тоже заработает, но нужно будет сделать отдельный файл с 2 строчками (логин и пароль), и указать его в конце http-proxy, после слова auto.

Просьба сравнить поведение с выключеным OpenConnect-сервером и включенным на ваших примерах.