Le ecureuil

А не покажете еще логи на кинетике-сервере до кучи?

То есть по вашему утверждению, с сервера 4.3 на клиент 4.3 подключиться невозможно?

В следующей версии 4.3 в клиенте при выборе accept-routes будут приниматься внешние роуты, будет работает получение и настройка IPv6-адресов. Также в сервере появится команда oc-server route для задания маршрутов, которые уйдут клиентам.

Можно и уже сейчас на устройствах с arm64, но пока мы очень стараемся не допустить сегментации по фичам (кроме USB). А иначе выйдет так, что dnscrypt будет доступен только на устройствах с arm64 - и мы немного устанем объяснять, как же понять, на какой конкретно модели эта фича есть, а на какой - точно нет, и покупатьее нельзя. Даже с USB и то постоянно есть проблемы в этом плане.

Исполняемый файл на C занимает 100-200 кбайт в бинарном виде, на Go - 10 мегабайт. В ОЗУ пропорции аналогичные. Потребление процессора тоже возрастает.

Это вариант на Go, а было сверху сказано, что нужно на C.

@Edikward @nastya05-11 обратитесь, пожалуйста, в официальную поддержку.

Покажешь репу на github?

Не существует нормальной реализации DNSCryptv2 на C.

Компетентные органы сообщили, что ситуация должна исправиться.

Просто он похоже уже устал.

@avn пока это не было доделано, но в работу взято.

Есть мнение, что баг не в роутере, а в браузере. Раньше мы использовали сессионные куки, которые обязаны полностью удаляться после закрытия браузера и перезагрузки. Однако выяснилось, что уже пару лет браузеры игнорируют RFC, и хранят сессионные куки вечно из-за фичи под названием "Восстановление сессии". Теперь в 4.3 мы перешли на обычные куки с ограничением срока их жизни именно для того, чтобы они не "висели" в браузере вечно - и вот видимо смесь старых и новых вызывает какую-то странную реакцию. Попробуйте проверить, помогает ли полное закрытие браузера и перезагрузка ПК с неподходящим паролем.

Стоимость их поддержки - околонулевая, и еще есть активные пользователи.

Поправлено, в следующей версии 4.3 будет все нормально.

Вторую точно нет, а для первой между interface и usb нужен аргумент в виде имени интерфейса.

Более тщательно проверить маршруты, возможно часть из них используется и этими сервисами. Потому что на маршруты, отличные от default route, политики не действовуют. Чтобы в политику не копировались маршруты от vpn, не включенного в нее, используйте команду ip policy Policy0 standalone.

На 3.5 никогда этого не будет.

Так тут вопрос не в авторизации, а в том, что OpenVPN-пакеты дропаются по пути еще на этапе установки соединения.

В принципе не фатально, но часть лишнего трафика начинает идти не через основное соединение.

Самодельные костыли прикручиваются уже много лет через opkg, и тут наша помощь не нужна.

Покажите скриншот, пока непонятно о чем у вас идет речь. И бутстрапы встроенные в https-dns-proxy уже многие годы как не используются.

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

Проверяете клиента на последней версии 4.3?

По идее да.