autottl. Суть режима в автоматическом определении TTL, чтобы он почти наверняка прошел DPI и немного не дошел до сервера. Берутся базовые значения TTL 64,128,255, смотрится входящий пакет (да, требуется направить первый входящий пакет на nfqws !).
Вычисляется длина пути, отнимается delta (1 по умолчанию). Если TTL вне диапазона (min,max - 3,20 по умолчанию), то берутся значения min,max, чтобы вписаться в диапазон. Если при этом полученный TTL больше длины пути, то автоматизм не сработал и берутся фиксированные значения TTL для атаки.
Техника позволяет решить вопрос, когда вся сеть перегорожена шлагбаумами (DPI, ТСПУ) везде где только можно, включая магистралов. Но потенциально может давать сбои.
Например, при асимметрии входящего и исходящего канала до конкретного сервера.
На каких-то провайдерах эта техника будет работать неплохо, на других доставит больше проблем, чем пользы.
Где-то может потребоваться тюнинг параметров. Лучше использовать с дополнительным ограничителем.
Фиксированное значение - это --dpi-desync-ttl. Если не указывать или поставить 0 - пакет будет уходить с оригинальным TTL. В этом случае требуется fooling, иначе это 100% поломка tcp.
Или можно поставить ttl=1. Тогда атака фейками будет в большинстве случаев пропущена, тк фейки не дойдут до DPI, но и соединение не будет гарантированно ломаться, оставляя ситуацию как есть, без обхода. Хотя бывают и провы, где DPI стоят на 1 хопе. В этом случае может обойтись только часть DPI фейком, а дальше на магистралах - нет, и результат будет все равно нет.
Если кроме фейков есть еще и компонента фрагментации (split/disorder), то она будет штатно применена в версии “2” - (split2/disorder2), тк обрамляющие фейки используют тот же ttl, что и --dpi-desync=fake
Вы описали для чего нужен --dpi-desync-ttl и как он сочетается с другими параметрами. Это есть в талмуде. И как работает --dpi-desync-autottl тоже там есть, а как оба параметра сочетаются друг с другом одновременно? Они же оба меняют TTL на какое-то своё значение, так? Нельзя ведь одни и те же пакеты отправлять с разным TTL.
Единственное, что я вроде понял из талмуда и ответов здесь и на гитхабе, это что --dpi-desync-ttl сразу отправляет пакеты с заданным TTL, а --dpi-desync-autottl отправляет без изменения TTL, а уже по ответу сервера определяет число хопов, и уже после этого задаёт TTL, как описано в талмуде. Поэтому я здесь вижу сочетаемость только при сценарии, когда первый пакет отправляется с заданным --dpi-desync-ttl, а после ответа сервера пакеты начинают отправляться с --dpi-desync-autottl.
Я в правильную сторону думаю?
Всем привет!
Кто-нибудь пробовал настроить тик ток и нетфликс?
Все другие соц сети удалось пробить, а эти чет не даются
Может есть какие другие методы.
Tiktok никто не блокировал, он сам заблокировал российских пользователей частично (информация легко гуглится).
Netflix - аналогично (вообще список сайтов, которые блокируют доступ с российских айпишников можно глянуть, например, тут - no-russia-hosts/hosts.txt at master · dartraiden/no-russia-hosts · GitHub )
Так что в данном случае zapret никак не поможет - только vpn.
+1
под подобные задачи на том же openwrt поднял v2ray+reality и там тоже есть возможность оборачивать только определённые домены. обернул нетфликс, jetbrains и подобные, кто сами блокируют ру зону. прекрасно работает
да, можно и так, но мне проще “контролировать” куда пускать, куда нет, т.к. на моём инете сидят ещё и соседи, соответственно, куча детей разного возраста итп. поэтому мне “проще” добавлять домены к нужным сервисам. юзаю вот этот ресурс как основу. когда надо какой-то сервис добавить, беру из этого списка, т.к. там он вполне себе полный
–dpi-desync-ttl=4 не обязательно, похоже
–dpi-desync-split-seqovl=1 - у меня критично, но без подделки SNI (последний параметр) у меня провайдер видит кривизну, сбрасывает соединение и лочит IP адрес, то есть роутер приходится перезапускать.
