Le ecureuil

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

Только получив его через 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 по идее должна быть нормальная обработка, и ошибки больше быть не должно.

А лог?

NFS, конечно, тормозной и не для WAN-сетей, но в принципе там не супербольшой трафик при открытии каталогов.

Ах вот оно что. Но вообще очень странно - direct-connected маршрут у вас есть на обоих соединениях в self-test.

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

Видимо вам только в официальную поддержку - они помогут с выяснением деталей.

Судя по вашему логу проблем ноль. Дальше вам нужно посмотреть, а вообще по роутингу туда хоть что-то может идти, или нет.

В http/3 по сравнению с http/2 смысла ровно ноль, потому его делать пока не будем.

Все так, на Omni места мало и потому http2 отключен в сборке (а также на других устройствах с 7628, где мало места). На более-менее приличных устройствах http2 есть давно, но только в комбинации с SSL, потому что ни один браузер http2-plaintext все равно не умеет - нет смысла. Более того, http2 работает также и с WebDAV, и с ip http proxy, и даже с SSTP - со всем, что идет через псевдо-http.

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

Проверьте пожалуйста на версии 4.3, и включите interface Wireguard0 debug. У меня воспроизвести не получилось.

Одну из возможных причин устранили, попробуйте на следующей версии 4.3.

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