а тебе именно функция dup помогает открывать сайты? без нее будет блок?
я немного потестировал с ней пока была возможность, сайты то открывались, то переставали открываться (тоже самое с orig), так и не смог сделать каких-то выводов по этим функциям.
при этом стабильно открывались, если указать ttl предпоследнего хопа или совсем его убрать
но по итогу на всех сайтах, где тестил, этот блок убрали.
p,s сделал себе 200байт фейк от http запроса, который пробивает и ютуб и дис, но скорее там просто срабатывает не-tls проверка (тоже самое что и нули)
Я уточню, если я буду использовать split то сайты тоже будут открываться, но dup не будет работать.
Я решил убрать split и тестировать только dup.
Ютуб работает на отлично с dup, но если оставить только ttl, то интерфейс грузится быстро, но начинаются приключения с качеством видео.
Остальные сайты только с dup.
Еще я попробовал --orig-autottl=+10:3-128 --dup-replace=0
Если делать +1, +2, +3, то долго грузит сайт, но рано или поздно загрузит.
Сделал на абум +10,+20 - сразу получил эффект быстрой загрузки, значит как-то может адекватно работать в связке с dup.
Когда я тестировал dup без хостлиста на 443, то сайты ломались из-за отсутствия cutoff, добавив его, я случайно столкнулся с сайтом 5post, который отказывался принимать соединение…
Методом тыка я пришел к тому, что сделал в dup - badsum,md5sig, а в desync - badseq,md5sig; при таком сайт дает подключение, но я пошел дальше и включил ttl для desync и вот с ttl сайт не дает подключение: --dpi-desync-autottl=1:3-20; если я сделаю 2:3-20, то дурение работать не будет, а 1 работает.
На twitch с fooling не загружаются изображения.
Когда натыкал стратегию, вернул хостлист.
Можно ослаблять дурение, например, хватит только md5sig.
Я понял твою идею с конкретным ttl, как-нибудь протестирую, а то накопил усталось все это тестировать в последнии дни…
n - номер пакета
d - номер пакета с данными
для udp n==d
для tcp n!=d , тк d не считает пакеты без data payload. такие, как ACK
d1 для tcp - это первый пакет с data payload, он же обычно n3
data payload это данные tcp. есть заголовки разных уровней. l2 (ethernet)-l3 (ip) -l4(tcp), дальше идут данные tcp, собственно полезная нагрузка, которую КАЧАЮТ. информация
c MTU это связано лишь тем, что нельзя создать пакет размером, превышающим MTU. размер считается, начиная с L3 хедера
@bolvan скажите пожалуйста по поводу изменений в zapret, nfqws: allow zero autottl даёт возможность любой из этих переменных присваивать 0? Что-то вроде --dup-autottl=0, --orig-autottl=0 или --dpi-desync-autottl=0? И какой в этом практический смысл?
autottl считается включенным, если любой из параметров delta,min,max отличен от 0
при присваивании =0 min,max остаются по умолчанию, ненулевые, значит =0 включает autottl. раньше autottl считался включенным, если delta!=0 , то есть =0 выключало autottl.
практический смысл продиктован расширением сферы применения autottl на сценарии, когда пакет должен доходить до сервера. =0 - это точное соответствие длине пути, когда пакет приходит на сервер с TTL=1. без 0 такое сделать было невозможно.
в идеале autottl orig=0, desync=-1 , то есть разница всего 1 хоп, который и определяет доходимость до сервера. хотя на практике это работать не будет для большинства случаев, возможность все равно должна быть
Я не исследовал этот вопрос, но Валдик говорил, что с проходным трафиком у windivert что-то не то.
Если вы не можете настроить прокси, то у вас большие проблемы с уровнем знаний, который уже требуется для успешного обхода блокировок. Дальше будет только сложнее
Я пока не разобрался именно с 3proxy но думаю что осилю в конце концов. Главная проблема в том, что нужно во всех приложениях вписывать адрес прокси что неудобно и не везде его вабще можно вписать.
Хотелось бы чтобы как в виндеверте работало сразу со всеми приложениями но и через хотспот. Но ладно, тагда наверно буду мучить дальше проксю ведь другого выхода нет.
The forward layer does not interact well with the Windows NAT: It is not possible to block packets pre-NAT with WinDivert. As a general principle, you should not try and mix WinDivert at the forward layer with the Windows NAT implementation.
Пакеты ловятся, но не работает дроп. Невозможно остановить пакет, не дать ему уйти.
Инжект работает, но ловятся пакеты до NAT, и после инжекта снова NAT не проходят, так и уходя с внутренним IP.
Обе проблемы критические. Так что в топку, нереально
И это еще не все. Входящие, ответные пакеты, не ловятся на forward layer, а на network layer там внешний IP адрес, соотнести с внутренним невозможно, значит отвал всего, что завязано на входной трафик - autottl, autohostlist
Спасибо !!! Как мне показалось, на той же стратегии в 71 версии страницы открываются быстрее, возможно просто показалось не знаю, но нужно время чтоб освоить функционал
Слишком оно заумно для хомячка.