Le ecureuil

Реализовано в 4.1.

Сделано через ip policy <name> route / ipv6 route в версии 4.3.

Реализовано в 4.3.

Частично реализовано через привязку сегмента, на котором работает VPN Server к политике.

Режим fail-safe реализован в версии 3.9.

Поддержка ipv6 в dyndns появилась в версии 4.1 через метапеременную $ip6. Кроме нее поддерживаются переменные $ip, $user, $password, $domain.

Реализовано в 4.2 и выше в cli, по вопросам работы создаем отдельные темы.

Реализовано

Принудительное завершение сессии в cli реализовано в следующей версии 4.3 через команду "session-logout", она доступна для vpn-server, sstp-server, oc-server, crypto map l2tp-server и crypto map virtual-ip. ID сессии берется из show соответствующего сервера.

Реализовано в версии 4.1 посредством XFRM-интерфейсов.

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

Caller ID это случайное число, меняющееся при реконнекте. Вы имеете в виду "завершать конкретные сессии принудительно"? Есть такая тема, пока нельзя, но работаем.

Все устройства на MIPS для таких хотелок уже не очень подходят. Вам надо смотреть с Racer 4010 и выше.

Пока в логах ничего особенного нет, что могло бы помочь в выяснении причины. Подскажите, у вас через облачный режим работает sstp? Это может вносить дополнительные дисконнекты - облачный доступ поставляется в режиме "as is", и его 100% доступности не гарантируется. Если вы можете поставить версию 4.3 на сервер, то было бы интересно взглянуть на лог после команды sstp-server debug в моменты дисконнектов.

Сделать через туннель до него маршрут по умолчанию.

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

Судя по self-test у вас собственно работа с Web и занимает весь CPU. У вас модель из начального сегмента, процессор у нее не особо мощный, так что это ожидаемо. Закройте веб - и нагрузка пропадет.

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

Если честно, то вы конечно что-то ужасное накрутили. Подобная схема не была проверена, потому и возникнуть может все что угодно. Правильное решение, которое мы считаем типовым и рабочим - получить wildcard на самом Keenetic, и дальше уже во все апстримы отдавать по plaintext (или по SSL, неважно). В таком случае понадобится всего один сертификат, а не 16. Подскажите, а откуда снят ваш скриншот? Если с NAS, то значит с ним и надо разбираться. Помните, что у LE есть свои ограничения - https://letsencrypt.org/docs/rate-limits/

Возможно будет.

> no interface ZeroTier0 и затем все создавать заново.

Еще раз повторю - нужен self-test снятый после того как ничего не сработало (а также нужно дождаться retry в 30 секунд). Перед этим нужно включить interface debug на вамшем WAN, сохранить конфиг и отправить устройство в перезагрузку.

Это было еще в веб-интерфейсе первого поколения Уже два сменилось с тех пор.

Покажите self-test.

Как в официальном мануале от MS: route delete 8.8.8.8/32 2.2.2.2