Supermaks

Эту переписку я видел в поиске, но у меня всё работало в начале 2023 года, проблема началась только в конце января 2023. Плюс я думаю что если бы Яндекс со своей стороны что-то поломал, то за полмесяца уже в Интернетах бы всплыла жалоба не только от меня (не думаю что я один пользуюсь связкой rclone+yandex), а гуглятся все переписки именно от лета 2022 года. Плюс я еще раз уточню - примерно в 20% случаев у меня всё работает успешно. Вряд бы ли Яндекс стал ломать именно так, просто бы запретили и всё, но тогда бы оно в принципе не работало.

Возникла проблема с синхоронизацией файлов через rclone на ЯндексДиск, путем эспериментов и упрощения задачи было выяснено что проблема не именно в команде sync а вообще при общении с https://cloud-api.yandex.com Итак, имеем домашний интернет от Билайна, Giga III, на ней entware, в нем rclone. Простейшая команда rclone --log-level DEBUG copyurl --stdout https://cloud-api.yandex.com (по сути своей аналог curl -L https://cloud-api.yandex.com который работает без проблем в 101% случаев) отваливается в 80% случаев в ошибкой 2023/02/15 19:28:37 ERROR : Attempt 1/3 failed with 1 errors and: Get "https://cloud-api.yandex.com": net/http: TLS handshake timeout 2023/02/15 19:29:37 ERROR : Attempt 2/3 failed with 1 errors and: Get "https://cloud-api.yandex.com": net/http: TLS handshake timeout 2023/02/15 19:30:37 ERROR : Attempt 3/3 failed with 1 errors and: Get "https://cloud-api.yandex.com": net/http: TLS handshake timeout 2023/02/15 19:30:37 DEBUG : 2 go routines active 2023/02/15 19:30:37 Failed to copyurl: Get "https://cloud-api.yandex.com": net/http: TLS handshake timeout В остальных 20% (как и через curl всегда) ответ успешный root@GigaIII:~$ rclone --log-level DEBUG copyurl --stdout https://cloud-api.yandex.com 2023/02/15 19:54:07 DEBUG : rclone: Version "1.60.1" starting with parameters ["rclone" "--log-level" "DEBUG" "copyurl" "--stdout" "https://cloud-api.yandex.com"] {"build":"2.1084.1","api_version":"v1"} root@GigaIII:~$ curl -L https://cloud-api.yandex.com {"build":"2.1084.1","api_version":"v1"} При неуспешных попытках через tcpdump видно что пакетики летят только в одну сторону, при успешных - обмен пакетами двусторонний. Если бы бы оно не срабатывало всегда, то я бы еще наверное понял что мешает firewall или может даже какой фильтр у провайдера, но когда ты за минуту подряд выполняешь команду 5-6 раз и в среднем 1 раз она срабатывает то непонятно куда еще посмотреть и кому пожаловаться. Причем всё работало почти год без вопросов, а месяц назад начались проблемы. Пробовал разные версии rclone (1.59-1.61) - никакой разницы. Также пробовал ту же самую команду rclone на windows с компа который подключен к этой GigaIII и на linux в виртуалке которая запущена на этом компе - проблем нет вообще. То есть затык именно при доступе с самого роутера. Куда можно еще покопать?

Несколько раз перечитал пост, понял зачем был придуман poorbox, но так и не понял что "теперь мона". Получается что перед каждым opkg upgrade можно делать: opkg remove wget opkg install poorbox opkg upgrade opkg remove poorbox opkg install wget и жить всё остальное время с wget и openssl? Так?

Дак получается теперь нельзя иметь "безопасную систему" и wget с https одновременно? Понятно, печалька. Эта проблема с ffmpeg вылезла при попытке заюзать youtube-dl, абыдна что не сработало.

Отвечу частично самому себе: wget в дефолтной установке теперь это symlink на обрезанный busybox в /opt/usr/bin, который ставится по умолчанию в пакете poorbox, Если поставить нормальный wget в /opt/bin через opkg то проблема снимается. Что касается ffmpeg с ssl то получается надо самому его что ли собирать? Ведь есть же например в пакетах httping и httping-nossl, почему бы не сделать ffmpeg и ffmpeg-nossl.

Установил Entware с нуля, ca-certificates, ffmpeg При попытке обращения wget по https выдается ошибка протокола: wget: not an http or ftp url: https://ya.ru При попытке обращения ffmpeg по https выдается ошибка: https protocol not found, recompile FFmpeg with openssl, gnutls or securetransport enabled. Что я делаю не так? Спасибо.

Похоже проблема с маршрутами как-то связана с опцией Enable software compression в настройках vpn-подключения (их количество меняется в зависимости от этой опции при всём остальном неизменном), перебрав варианты у меня получилось что при отключенной опции и включенном принудительном шифровании и на клиенте и на роутере всё работает так как у меня работало в 2.14. Почему у меня эта опция исторически была включена я уже не помню к сожалению. Update: получил ответ от официальной поддержки: Да, вы правы. С включением компрессии работать перестает. Обсудили этот вопрос с разработчиками и они говорят, что реализация данной компрессии MPPC от Microsoft в Linux вообще не работает на уровне ядра. Там другие типы компрессии, несовместимые. И ранее использовался дополнительный патч на ядро для совместимости с MPPC. Вообщем, это довольно глубокий уровень и придется дожидаться возвращения из отпуска основного программиста, который пишет все, что касается PPP и прочих туннелей, чтобы окончательно прояснить ситуацию. Пока лишь могу рекомендовать не использовать компрессию (по-умолчанию, кстати, она выключена).

Сделал, прикрепил, скрыл как положено.в отдельном сообщении. Только не очень понял чем это отличается от того что я прикреплял после первого своего сообщения в этой теме, ну разве что дебаг включил из консоли, а не из web-интрефейса кнопкой Start test. Дело вряд ли в моей версии W10, вон выше у Vasek00 на обычной W10 Home таже самая проблема.

LTSC English 1809 17763.316

Да, действительно, если в настройке сервера отключить "With encryption only" и в настройках клиента на W10 выбрать "No Encryption allowed" то проблема снимается. У меня разница лишь в том что с включенным шифрованием клиент на W10 всё равно коннектится успешно, но не работает после этого.

Модель ZyXEL Keenetic Giga III, используются только релизные прошивки. После обновления прошивки с 2.14.C.0.0-4 на 2.15.C.0.0-0 перестал корректно работать PPTP-сервер. Клиент успешно коннектится, линк устанавливается, но с консоли кинетика ip адрес клиента не пингуется да и вообще никакой трафик судя по всему не ходит. Откат на 2.14.C.0.0-4 проблему устраняет. Прикрепляю self-test запущенный перед подключением клиента.

Update: всё таки нашелся фильтр на 445 порту в одном месте, доступ с WAN заработал. Для себя фиксирую что на 2.09 хватало открытого 139 порта, на 2.10 нужен 445.

Дак и на Windows 10 наверное уже 3-я версия, разве нет?

Обновился с релиза 2.09 до 2.10 и таже самая проблема. В качестве клиента Windows10 LTSB x64, модуль "Контроль доступа к папкам" не установлен. Файрвол на клиенте отключать пробовал, у провайдера не зафильтровано.