Le ecureuil

Команда ipv6 route уже года полтора как в стабильной версии есть. Насчет файла - а вы уверены что винда поддерживает такое? Если да, просьба скинуть файл, который и на винде маршруты ipv6 прописывает (для образца).

В целом не рекомендовано менять настройки по спецпротоколам ipv6, в том числе и по discovery.

Спасибо, понятно. Поправим.

Спасибо всем за репорт, поправим.

Попробуйте поменять пользователя и идентификатор в настройках чисто для проверки. По результатам напишите.

Ну так посмотрите что там именно за трафик-то? Без детализации неясно.

А у вас какое имя пользователя на клиенте введено? vpn или realme12? Потому что странно: у вас приходит EAP identity vpn, но при этом имя пользователя в RADIUS-пакете - realme12. Какое же из них верное? И кстати, что за клиент у вас?

В bat-файле поддерживаются только ipv4-роуты.

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

Ну раз не хочется, давайте подождем пока кто-то другой возьмет и проверит.

Как минимум проверять на 4.2 или (еще лучше) 4.3.

Здесь надеятся на это бесполезно, нужно иди в официальную поддержку.

Только получив его через ip http ssl acme get <domain>

Мбит/с или Мбайт/с? Если первое, то печальновато конечно.

Нет, написано же для какой подходит.

Попробуйте устройство перезагрузить, а еще лучше проверить на 4.2 и 4.3.

Покажите хоть, что, откуда и куда.

Это давняя проблема китайского мусора, которые отвечают по ARP сразу на разные адреса.

Теперь, после версии 4.3.а4, можно пробрасывать ssh через облако. Настраиваем его как обычно, затем настраиваем ip http proxy типа connect c апстримом 127.0.0.1:22 под названием ssh (по аналогии с описанным в посте ). Затем используем openssh-клиент. Создаем скрипт ~/.ssh/keenetic.sh, в котором описываем подключение через https-proxy (в параметре basic-автризации нужно сделать строку, закодированную через base64 из логина и пароля, разделенного двоеточием, проще всего через утилиту openssl: ($ echo "user:password" | openssl base64)): #!/usr/bin/env bash { printf "CONNECT 127.0.0.1:22 HTTP/1.0\r\nProxy-Authorization: Basic dGVzOnRlc3E=\r\nHost: ssh.l3name.keenetic.link\r\n\r\n"; cat; } | socat - SSL:ssh.l3name.keenetic.link:443 Ну и затем вызываем команду: ssh admin@127.0.0.1 -o "ProxyCommand=~/.ssh/keenetic.sh" Дальше как обычно вводим пароль от admin.

Злоумышленник на другом сайте может попытаться внедрить вам скрипт (или в браузере может быть дырка), который сделает запрос к 192.168.1.1, будет успешно авторизован (по вашему mac из локалки) и дальше будет выполнять команды на роутере. Причем вы тут вообще никакого контроля не имеете, в отличие от ситуации на сейчас, когда можно быть разлогиненным и не иметь доступа к вебу без ввода пароля.

Это небезопасно. Такая "авторизация" потом выйдет вам боком при CSRF-атаке.

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

Вы про маршрут по DHCP, или про адрес? Адрес получается не по DHCP, а по внутреннему каналу. Возможно вам поможет interface OpenConnect openconnect accept-addresses interface OpenConnect openconnect accept-routes

В следующей 4.3 по идее должна быть нормальная обработка, и ошибки больше быть не должно.

А лог?