общая скорость домашнего интернета гарантированно просядет, ведь оборудованию провайдера придется не просто пропускать трафик, а постоянно сверяться с «белыми списками».
Впн внутри России прекрасно работает. Для иностранных компаний уж точно можно будет что нибудь придумать. Очередная статья чтобы еще больше разогнать панику, расходимся
Запугивать, конечно, круто, но в реальности, боюсь, что из машинного обучения там только гпт для разработчиков)
Факт в том, что ТСПУ стоят у всех, и что они должны обрабатывать десятки гигабайт трафика. Если они начнут задыхаться, это будет катастрофой. Кем бы РКН не были, они всё же стараются не допускать такого сценария, и ТСПУ остаётся достаточно легковесным. Они даже на пакеты стараются полностью не смотреть (буквально, tcp чексуммы не считают). Там куча эвристик по заголовкам протокола или прыжкам по пакету. А вы говорите про какую-то недетерминированную модель, которая будет анализировать пакет целиком. К тому же, это будет уже не какая-то табличная регрессия, а целая нейросеть со сложной архитектурой. Это требует огромных мощностей и огромных затрат. К тому же вопрос на чём её тренировать? И что будет, если она правильный трафик воспримет за неправильный?
Короче, далее этого заголовка статью читать не имеет смысла, а автора и всех тех, кто пишет про нейронки на мыло. Хотя, это же журналисты, что с них взять)
У вас старая версия программы. Обновите до новой. И придётся поиграть с параметрами из 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 обрабатывает только первый пакет из соединения, остальные проходят автоматически.
Да делайте что хотите) Если знаете сервер, который в +- такой же манере работает - почему нет. Другой интересный кейс - дотянет ли оно до ТСПУ. Кстати, у меня на мегафоне сработало:
Это вы по вайбу написали, да?
Вот когда либра сделает нормальные приложения, тогда и поговорим, а пока что мс офис, увы, лучший
Впн внутри России прекрасно работает. Для иностранных компаний уж точно можно будет что нибудь придумать. Очередная статья чтобы еще больше разогнать панику, расходимся
Запугивать, конечно, круто, но в реальности, боюсь, что из машинного обучения там только гпт для разработчиков)
Факт в том, что ТСПУ стоят у всех, и что они должны обрабатывать десятки гигабайт трафика. Если они начнут задыхаться, это будет катастрофой. Кем бы РКН не были, они всё же стараются не допускать такого сценария, и ТСПУ остаётся достаточно легковесным. Они даже на пакеты стараются полностью не смотреть (буквально, 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.