Le ecureuil

Только через дополнения.

Через curl + rci все можно отлично сделать. Например, создать интерфейс OpenVPN0, сделать его глобальным с приоритетом 200, включить получение роутов, сразу залить конфиг: curl -X POST http://192.168.1.1/rci/interface?name=OpenVPN0 -H "Content-Type: application/json" -d "{\"up\": true, \"ip\":{\"global\":{\"priority\":200}}, \"openvpn\":{\"accept-routes\":true, \"config\":\"JSON_ESCAPED_CONFIG\"}}" --digest -uadmin:test Сохранить настройки: curl -X POST http://192.168.1.1/rci/system/configuration/save -H "Content-Type: application/json" -d "{}" --digest -uadmin:test

Нет, можно подключиться к любому серверу. Аутентификация клиентов по сертификатам не работает, это верно. Но ее и не обещали - это опциональная фича. Если же вы про проверку серверного сертификата, то можете ничего не указывать - Keenetic в случае, если сертификат ненастоящий, всего лишь поругается в консоль, но соединение установит.

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

Все наши VPN-серверы не рассчитаны на подключение из локальных сегментов, только из WAN. Потому даже если и заработает, то это случайно.

До 12-14 Мбит/с в идеальных условиях.

Стандартно же: export http_proxy=http://LOGIN:PASSWORD@PROXY_HOST:PORT transmission использует libcurl для http-запросов, и в теории должен нормально работать с учетными данными.

Только не sda1, а просто sda.

Да, теперь все есть, но явного редиректа нет. Такое ощущение, что это javascript редиректит, и это уже куда хуже - без пошаговой отладки в браузере непонятно почему. Пока заходите по прямой ссылке.

Один раз заход на "/" я увидел в дампе, но там все отлично сработало с редиректом и правильно. Второго раза нет, видимо что-то пошло не так или кэш в браузере сработал - кстати его стоит почистить или заходить из incognito mode.

OpenVPN внутри себя имеет ping-check встроенный, настройте его так, чтобы он через 30 секунд недоступности туннеля (или сколько вам хочется) переинициировал соединение. Или скиньте конфиг openvpn с вырезаными ключами, посмотрим что там не так и подправим.

Включить дамп, зайти по внешнему адресу, прям на http://mts.bla-bla.mykeenetic.ru/. После редиректа на злополучный opennewwindow отключить дамп и скинуть сюда. В дампе должно быть буквально 10-15 секунд, не больше. Все остальные вкладки в браузере, которые открыты на это устройство надо закрыть, иначе будет куча-мала.

А каким боком коммутаторы Z относятся к нам?

Внимательно посмотрел дамп, и не нашел в нем запросов и редиректов на opennewwindow.html. Вы заходили не через proxy? Тогда понятно, но это не помогает понять проблему. Пожалуйста, снимите этот дамп, когда заходите через ip http proxy - будет над чем работать.

Клинетской авторизации по сертификатам пока не планируется.

Про dect создавайте отдельную тему в разделе про dect. Иначе вас не заметят.

Так сложилось исторически.

Спасибо, обязательно проверим все эти случаи.

Проверил все на 2.12 последней - все нормально. Не воспроизводится.

А поподробнее по пунктам? Что именно должно быть разрешено, если стоит галка "Разрешить доступ через Интернет", но снята галка "Разрешить доступ через HTTP" у admin? Что именно вы подразумеваете под авторизацией по сертификатам? Вот это: https://habrahabr.ru/post/213741/ ?

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

На соединении к провайдеру уберите галку "Использовать для выхода в Интернет", и пропишите руками роут только к VPN-серверу через него. Еще отключите получение DNS у провайдера. Теперь и VPN будет соединяться, и трафик наружу не уйдет.

Попробуйте почистить кэш браузера. Если не поможет, то пожалуйста снимите дамп пакетов на CdcEthernet0 при отключенном ppe software в момент захода на корень (/) ресурса модема, посмотрим, что он отвечает не так.

Спасибо, поправлено.

Я думаю, что это лучше решить через официальную техподдержку - у них вроде должен быть такой модем, и они проверят что именно не так.