Le ecureuil

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

Это давняя проблема китайского мусора, которые отвечают по 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.

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

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

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

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

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