При использовании GDPI или zapret на сети ростелекома невозможно впринципе получть какие-либо данные (даже веб) с youtube. Помимо этого стали недоступны или не не с первой попытки загружаемы любые другие сервисы гугла (docs, news, play и прочее). Никакие настройки gdpi или zapret не помогают.
Создается впечатление, что банят ютюб подсетями и динамически.

Возможно на тспу идет настройка на длокировку CIDR или даже сразу же целыми AS

Не стоит вскрывать эту тему.

поч?

это отсылка на одну копипасту

Если рассуждать логически, то тогда нужно не использовать GDPI или zapret, и в результате получится получть какие-либо данные (даже веб) с youtube

В сети ростелекома невозможно пользоваться интернетом без zapretа, поэтомк работу без него даже не рассматривается теперь. Пробовал без - результат тот же.
Увы, но теперь такова реальность рт, что необходимо донастраивать роутер для нормальной работы.

Замечал на некоторых сайтах которые не заблокированы вместе с запретом сайт быстрее прогружается, возможно показалось

Мне кажется, что вы что-то делаете неправильно, например конфиг кривой, или настройки прокси. Да может быть что угодно. Нужно смотреть на месте что у вас там, но вряд ли кто-то этим будет заниматься.

Вам не показалось. Так и есть Я также заметил, если принудительно включить только tls 1.3, то еще шустрее работает.

Ага особенно ютуб который не заблокирован

Ну не заблокирован же!!! Технически просто замедлен…до скорости диалапа

У меня по вечерам ютуб совсем лагает даже с запретом какие то глюки на msk-ix подъехали

Если б с конфигом запрета накосячил, то тогда бы ничего из забаненного не открывалось. А так работает все, что не банится по ip. До этого даже quic видел на CF сети и ютюбе

Вам нужно указать как минимум регион (чем точнее, тем лучше), ОС и версию программы обхода, которой пользуетесь. Экстрасенсов здесь нет

А какая ваша стратегия в конфиге, вот мой пример последния версия моей стратегии
–dpi-desync=fake,split2 --dpi-desync-repeats=10 --dpi-desync-ttl=6 --dpi-desync-fake-tls=0x00000000 --dpi-desync-split-seqovl=1 --dpi-desync-fooling=badsum если бы не утуб то вместо split2 поставил бы disorder2 и убрал бы
–dpi-desync-fake-tls=0x00000000 --dpi-desync-split-seqovl=1 --dpi-desync-repeats=10

rutracker

image2559×659 141 KB

а ютюб просто висит и ошибка timeout

HTTPS=“–dpi-desync-any-protocol=1 --dpi-desync-skip-nosni=0 --wssize 1:6 --dpi-desync-ttl=5 --dpi-desync=fake,disorder --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_gosuslugi_ru.bin --dpi-desync-split-pos=4 --dpi-desync-fooling=none”
QUIC=“–dpi-desync-any-protocol=1 --dpi-desync-skip-nosni=0 --dpi-desync=fake,udplen --dpi-desync-udplen-increment=132 --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_initial_vk_com.bin --dpi-desync-ttl=4 --dpi-desync-udplen-pattern=0x05000000 --dpi-desync-repeats=4 --dpi-desync-fooling=none”

это что делает?

Товарищ, ну что вы в самом деле, мануал то зачем придумали Вам бы форум пару дней почитать в разделе Zapret и не только. Потом уже двигаться дальше. Мануал к запрету мастхэв тоже.

–dpi-desync-split-seqovl= ; использовать sequence overlap перед первым отсылаемым оригинальным

использую вместе со split

это прочитал.
Он технически че делает? )

Обычно он используется так –dpi-desync=fake,split2 --dpi-desync-split-seqovl=1

seqovl добавляет в начало первой отсылаемой части оригинального пакета (1 часть для split и 2 часть для disorder)
seqovl байт со смещенным в минус sequence number на величину seqovl.
В случае split2 расчет идет на то, что предыдущий отсыл, если он был, уже попал в сокет серверного приложения,
поэтому новая пришедшая часть лишь частично находится в пределах текущего окна (in-window).

Для disorder2 overlap идет на 2-ю часть пакета. Обязательно, чтобы seqovl был меньше split_pos, иначе
все отосланное будет передано в сокет сразу же, включая фейк, ломая протокол прикладного уровня.
При соблюдении этого условия 2-я часть пакета является полностью in-window,
поэтому серверная ОС принимает ее целиком, включая фейк. Но поскольку начальная часть данных из 1 пакета
еще не принята, то фейк и реальные данные остаются в памяти ядра, не отправляясь в серверное приложение.
Как только приходит 1-я часть пакета, она переписывает фейковую часть в памяти ядра.
Ядро получает данные из 1 и 2 части, поэтому далее идет отправка в сокет приложения.
Таково поведение всех unix ОС, кроме solaris - оставлять последние принятые данные.
Windows оставляет старые данные, поэтому disorder с seqovl будет приводить к зависаниям соединения
при работе с Windows серверами. Solaris практически мертв, windows серверов очень немного.
Можно использовать листы при необходимости.
Метод позволяет обойтись без fooling и TTL. Фейки перемешаны с реальным данными.
split/disorder вместо split2/disorder2 по-прежнему добавляют дополнительные отдельные фейки.

там же все написано

Я бы убрал --wssize 1:6 как по мне лишнее

получилось так, но эффекта нет

А split вместо disorder пробывали

тогда вообще все падает и ничего из забаненного не открывается
disorder только и спасает

И да fake нужно убрать он используется только на split2 или disorder2

потому что они уже фейк содержат

КОМБИНИРОВАНИЕ МЕТОДОВ ДЕСИНХРОНИЗАЦИИ
В параметре dpi-desync можно указать до 3 режимов через запятую.
0 фаза предполагает работу на этапе установления соединения. Может быть synack или syndata.
На 0 фазу не действует фильтр по hostlist.
Последующие режимы отрабатывают на пакетах с данными.
Режим 1-й фазы может быть fake,rst,rstack. Режим 2-й фазы может быть disorder,disorder2,split,split2,ipfrag2.
Может быть полезно, когда у провайдера стоит не один DPI.

все оттуда же

Я имел виду то что у вас посылается два фейк пакета может быть с одним сработало надо пробовать

Протестил - тайиаут на ютюбе, а рутракер и подобное открывает

Может попробовать из моих параметров которые я дал может проканает, и вместо disorder split, или уже всяко пробывали я бы по тестировал но у меня не ростелеком, давно от них отказался

Вы весь ридми запрета сюда переписать решили?

И да, нет на РТ никаких банов подсетей и адресов ютуба, не надо бредить, конфиг лучше нормальный сделайте.