Le ecureuil

Теперь, после версии 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.

На первый взгляд все в порядке, в self-test зацепок нет, и локально воспроизвести в подобной конфигурации не вышло. Попробуйте убрать conform для этого хоста - чисто для проверки ситуации. Еще неплохо бы проверить работает ли проброс с других WAN, которые сейчас в резерве.

Поправлено. Причем причина была в том, как устроен протокол HTTP/2 - и поймать этот баг еще нужно было постараться. Теперь в первом случае будет просто веб, во втором - 502, в третьем - тоже просто веб. Попробуйте на следующей версии 4.3.

У вас OpenVPN1 прописывает прилетевший с удаленной стороны роут в 10.1.1.0/24, в то время как в OpenVPN0 ничего не приходит снаружи, и, естественно, ничего не прописывается. Адреса удаленные, на которые вы хотите заходить, лежат в 10.1.1.0/24?

Скорее всего MTU кривой, уменьшайте.

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

Все это переделано и должно быть нормально в 4.3. Если есть возможность и желание - лучше проверять там. В 4.2 относительно 4.1 никаких существенных изменений нет.

А можете с interface OpenConnect0 debug снять лог (только более-менее большой) и сюда приложить?