У вас старая версия программы. Обновите до новой. И придётся поиграть с параметрами из README.md. Может быть, fake-sni=ttl сработает. Также отключите quic в браузере.
А что если попробовать отключить udp пакеты с телека на роутере? Конечно, плохое решение, даже ужасное я бы сказал, но как будто бы может сработать: если есть потеря пакетов, ютуб может перескочить на TCP и всё заведётся.
Собственно, тут вопрос может встать не про телодвижения в бинарнике, а про ресурс роутера. По факту все пакеты прыгают сейчас kernel-space - user-space - kernel-space. И на всё это нужен context switch. У меня роутер одноядерный и втыкался в 2 МБ/с + 100 % sys CPU с простейщим netfilter queue, а тут целый прокси. И по факту для меня тут торренты - единственное что будет нормально работать, ведь практически всё сейчас скачивается по https.
Решение для netfilter queue есть: заставить conntrack считать отправленные пакеты и не кидать в user-space, если в соединении было уже больше чем, скажем, 20.
С прокси, к сожалению, такое не сработает - nat обрабатывает только первый пакет из соединения, остальные проходят автоматически.
Да делайте что хотите) Если знаете сервер, который в +- такой же манере работает - почему нет. Другой интересный кейс - дотянет ли оно до ТСПУ. Кстати, у меня на мегафоне сработало:
Работает/не работает можно посмотреть если делать make dev (или просто передать -DDEBUG флагом). Тогда когда программа видит SNI гуглвидео, она будет выводить сообщение об этом + пропроцию в которой разбивается пакет. Отключение байпасса ничем особо не грозит, разве что если программа отвалится (мало ли), можно остаться без интернета. Узнать точно, что помогает можно по логам Wireshark. Тогда на контрасте можно будет посмотреть разницу (правда, это видно только если подключение без QUIC).
RST это прям ярко красные. Я про всякие Out-of-order, Retransmission и им подобные.
"Скорость не бывает просто маленькая" - вообще, бывает. Сразу пришли на ум сервера эклипса. Месяца два назад скачивал jdtls на скорости 20 килобайт/с. Сейчас они их пофиксили чуть-чуть, я получил 1 мегабайт, но всё равно в вайршарке с точки зрения TCP никаких ошибок нет.
Всё настраивается параметрами через аргументы к анблоку. Смотрите в ридми.
У вас старая версия программы. Обновите до новой. И придётся поиграть с параметрами из README.md. Может быть, fake-sni=ttl сработает. Также отключите quic в браузере.
Правило iptables добавили?
Попробуйте это https://github.com/Waujito/youtubeUnblock/issues/32#issuecomment-2269789997
Реджект на UDP случайно не port unreachable даёт?
Кстати, в windivert открытый исходный код.
В конкретном случае, хоть он и есть, windivert использует закрытые API Microsoft, к которым ни у кого нет доступа.
Теперь живите с этим.
Можете это попробовать https://wiki.mikrotik.com/wiki/Manual:Metarouter
А что если попробовать отключить udp пакеты с телека на роутере? Конечно, плохое решение, даже ужасное я бы сказал, но как будто бы может сработать: если есть потеря пакетов, ютуб может перескочить на TCP и всё заведётся.
Собственно, тут вопрос может встать не про телодвижения в бинарнике, а про ресурс роутера. По факту все пакеты прыгают сейчас kernel-space - user-space - kernel-space. И на всё это нужен context switch. У меня роутер одноядерный и втыкался в 2 МБ/с + 100 % sys CPU с простейщим netfilter queue, а тут целый прокси. И по факту для меня тут торренты - единственное что будет нормально работать, ведь практически всё сейчас скачивается по https.
Решение для netfilter queue есть: заставить conntrack считать отправленные пакеты и не кидать в user-space, если в соединении было уже больше чем, скажем, 20.
С прокси, к сожалению, такое не сработает - nat обрабатывает только первый пакет из соединения, остальные проходят автоматически.
Так у него же есть автосборка на Github Actions. Там всё прозрачно.
Хм, у меня через тор открывается
Значит по IP заблокировали.
Да делайте что хотите) Если знаете сервер, который в +- такой же манере работает - почему нет. Другой интересный кейс - дотянет ли оно до ТСПУ. Кстати, у меня на мегафоне сработало:
```curl --connect-to ::msc.bigspeedtest.netbynet.ru.prod.hosts.ooklaserver.net 'https://manifest.googlevideo.com:8080/download?nocache=ffb8h452-219c-46a2-ac07-ae26f8064445&size=25000000&guid=fb78549a8-f40a-40d9-b760-1f8fcaa03c8e' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0' -H 'Accept: /' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'Origin: https://www.speedtest.net' -H 'Connection: keep-alive' -H 'Referer: https://www.speedtest.net/' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: cross-site' -H 'Sec-GPC: 1' -o NUL -k```
Я просто скопировал это как cURL из окна для разработчиков в Firefox во время speedtest
Патч уже есть.
Да, мой пакет можно поставить на OpenWRT. Также по слухам туда можно поставить zapret.
Понятное дело, что РКН просто так не оставит форум, который с ними уже тучу лет воюет)
Нет, к счастью, там только информация по установке соединения, ничего такого нет.
Работает/не работает можно посмотреть если делать make dev (или просто передать -DDEBUG флагом). Тогда когда программа видит SNI гуглвидео, она будет выводить сообщение об этом + пропроцию в которой разбивается пакет. Отключение байпасса ничем особо не грозит, разве что если программа отвалится (мало ли), можно остаться без интернета. Узнать точно, что помогает можно по логам Wireshark. Тогда на контрасте можно будет посмотреть разницу (правда, это видно только если подключение без QUIC).
OUTPUT на роутере не надо делать.
RST это прям ярко красные. Я про всякие Out-of-order, Retransmission и им подобные.
"Скорость не бывает просто маленькая" - вообще, бывает. Сразу пришли на ум сервера эклипса. Месяца два назад скачивал jdtls на скорости 20 килобайт/с. Сейчас они их пофиксили чуть-чуть, я получил 1 мегабайт, но всё равно в вайршарке с точки зрения TCP никаких ошибок нет.
В zapret заявлена частичная поддержка MacOS.