Разбор стратегий

# Discord и весь остальной TLS
--lua-desync=hostfakesplit:host=www.google.com:tcp_ts=-1000:tcp_md5:repeats=4

# YouTube и Google
--lua-desync=fake:blob=tls_google:tcp_md5:tcp_seq=-10000:repeats=6
--lua-desync=multidisorder:pos=1,midsld

hostfakesplit

Режет пакет точно по имени сайта и подставляет фальшивое имя такой же длины. Главное следствие: приём подстраивается под любой размер ClientHello. Поэтому он пускает не только на страницу входа Discord, но и к gateway, у которого приветствие другого размера. Стратегии с фиксированным перекрытием на этом спотыкаются: логин проходит, а подключения к серверам нет.

host=www.google.com

Имя, которое подставляется вместо настоящего. Безобидное и заведомо не заблокированное.

tcp_ts=-1000

Фейк получает более старую временную метку и отбрасывается на стороне сервера механизмом PAWS. Значение обязано быть отрицательным: при положительном отбрасываться будет настоящий пакет, а не фейк.

tcp_md5

Второй способ убить фейк, на случай если временные метки не сработают. Выбран вместо badsum потому, что безопасен за домашним NAT: роутер не выбрасывает такой пакет заранее.

repeats=4

Фейк отправляется четыре раза. Чем больше повторов, тем выше шанс, что DPI успеет его заметить и запомнить соединение как разрешённое.

fake + multidisorder

Для YouTube связка другая: сначала фейковый ClientHello, следом настоящий, разрезанный и отправленный в обратном порядке. Один приём тут обычно не пробивает, работает именно сочетание.

pos=1,midsld

Две точки разреза: сразу после первого байта и в середине домена второго уровня. Второй маркер обязателен: pos=1 сам по себе движок вырезает, и приём превращается в ничего не делающий.

Когда брать. Всегда первой. Она включена по умолчанию и на большинстве провайдеров закрывает вопрос.

# Discord и остальной TLS
--lua-desync=hostfakesplit:host=vk.com:tcp_ts=-1000:tcp_md5:repeats=4

# YouTube: без изменений, как в рекомендуемой

host=vk.com

Единственное отличие от рекомендуемой. ТСПУ относится к отечественному трафику мягче, и фейк «под VK» проходит там, где фейк «под Google» режут. Это заметный тренд последних лет: в других наборах для той же цели берут Ozon или облако Сбера.

YouTube остаётся на google-фейке

Сознательно. Для видеосерверов Google фейк «под VK» не годится: там нужен обычный рабочий профиль, и подмена домена только мешает.

Когда брать. Первым делом после рекомендуемой, особенно в характерной ситуации: в диагностике всё зелёное, а Discord всё равно не открывается.

# Discord и остальной TLS: два фейка подряд
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6
--lua-desync=fake:blob=tls_vk:tcp_ts=-1000:repeats=6

# YouTube
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:ip_id=zero:repeats=6

# голос: отечественный блоб вместо google
--lua-desync=fake:blob=quic_vk:repeats=6

никакой разрезки

Настоящий пакет не трогается вообще. Вся работа делается фейками. Именно поэтому стратегия часто чинит медиа и голос: разрезка иногда пускает только в логин, а дальше соединения ведут себя иначе и ломаются.

два фейка подряд

Сначала «под Google», сразу за ним «под VK». Расчёт на то, что хотя бы один из двух устроит конкретную железку. Дешёвая страховка: лишний фейк всё равно умрёт по дороге.

только tcp_ts

Единственный способ убийства фейка. Отсюда важное следствие: стратегия полностью зависит от включённых TCP timestamps. Программа включает их сама на время сеанса, но если бы не включала, стратегия молча ничего не делала бы.

ip_id=zero

Обнуляет поле идентификатора в заголовке IP у фейка. Дополнительный признак, по которому часть DPI отличает пакеты и обрабатывает их иначе.

blob=quic_vk для голоса

Голосовой мусор тоже отечественный. На части сетей именно это чинит пинг 5000 и «подключается, но никого не слышно».

Когда брать. Классический случай: вход в Discord проходит, а дальше ничего. Не подключается к серверам, не грузятся вложения, молчит голос.

# Discord
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6
--lua-desync=multisplit:pos=1,midsld:seqovl=681:seqovl_pattern=tls_google:optional

# остальной TLS: то же, но перекрытие 664 байта
# голос: quic_vk, как в ALT10

fake сначала, разрезка потом

Порядок принципиален. Фейк с временной меткой идёт первым и «готовит» соединение, и только после этого применяется разрезка с перекрытием. Без этой подготовки большое перекрытие ломало бы подключение к gateway.

seqovl=681

Перекрытие: к началу настоящего пакета дописывается 681 байт постороннего содержимого, так что DPI и сервер собирают поток по-разному. Для multisplit это число байт, а не позиция. У multidisorder тот же параметр означает совсем другое.

seqovl_pattern=tls_google

Дописывается не случайный мусор, а настоящее приветствие от Google. Правдоподобное начало переживает проверки, которые случайные байты не проходят.

:optional

Если разрезка по каким-то причинам не применилась, приём тихо пропускается, а не роняет всю обработку соединения.

664 вместо 681

Для профиля «остальное» перекрытие чуть меньше. Значения подобраны эмпирически в исходном наборе Flowseal и перенесены как есть.

Когда брать. Сразу после ALT10, если та не зашла. Это два варианта одной идеи от одного автора.

# Discord
--lua-desync=multisplit:pos=2:seqovl=681:seqovl_pattern=tls_google:optional

# YouTube: то же плюс ip_id=zero
# остальное: перекрытие 568

никаких фейков

Чистая разрезка с перекрытием, без единого поддельного пакета. Значит, никакого fooling не нужно вовсе, и стратегия не зависит от TCP timestamps и от поведения домашнего роутера. Самая «нетребовательная» из всех.

pos=2

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

Когда брать. Когда варианты с фейками не срабатывают. Часто это признак того, что DPI проверяет пакеты слишком тщательно и фейкам просто не верит.

# одинаково для Discord, YouTube и остального
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6
--lua-desync=fakedsplit:tcp_ts=-1000

fakedsplit

Разрезка, при которой между настоящими сегментами вставляются поддельные. Ключевое отличие от multisplit: fooling применяется только к поддельным сегментам, поэтому tcp_ts здесь безопасен. У multisplit он подействовал бы и на настоящие сегменты и сломал бы соединение.

одинаково для всех

Единственная стратегия, где все три профиля TLS используют один и тот же приём. Простая и предсказуемая, удобна как контрольная точка при переборе.

Когда брать. Если и фейки по отдельности, и чистая разрезка не помогли. Иногда работает именно их сочетание.

# Discord и остальной TLS
--lua-desync=multisplit:pos=2,midsld-2:seqovl=1:seqovl_pattern=tls_google:optional
--lua-desync=wssize:wsize=1:scale=6

# YouTube: fake + multidisorder, как в рекомендуемой

wssize

Единственная стратегия, которая работает с ответом сервера, а не с вашим запросом. Объявляется крошечное окно приёма, сервер вынужден отдавать ответ мелкими порциями, и DPI не собирает из него сигнатуру.

wsize=1:scale=6

Размер окна и множитель масштабирования. Комбинация даёт очень маленькое окно на первых пакетах, дальше оно восстанавливается.

цена

Дробление ответа означает больше пакетов и заметно медленнее загрузку. Это осознанный размен, поэтому стратегия и стоит в списке последней среди комбо.

midsld-2

Разрез на два байта левее середины домена. Смещения к маркерам записываются вот так.

Когда брать. Когда упрямо не открывается именно страница входа и ничего другое не помогло. Готовьтесь к тому, что будет медленнее.

# лёгкая разрезка управляющего соединения discord.media
--filter-tcp=443-65535 --filter-l7=tls {HOSTLIST:discord}
--lua-desync=multisplit:pos=2,midsld-2:seqovl=1:seqovl_pattern=tls_google:optional
--new
# голос: фейк QUIC-блобом, без ограничения TTL
--filter-udp=19294-19344,50000-65535 --filter-l7=discord,stun
--lua-desync=fake:blob=quic_google:repeats=6

это не комбо

YouTube и остальной трафик не трогаются вообще. Стратегия чинит одну конкретную вещь, и только её.

без ip_autottl

Главное отличие от голосового профиля в комбо. Подбор TTL зависит от маршрута и на некоторых сетях мешает. Здесь его нет, фейк просто отбрасывается сервером как мусор.

repeats=6

Больше повторов, чем в комбо, потому что нет второго механизма и вся надежда на то, что DPI заметит фейк.

Когда брать. Ровно один случай: текст в Discord работает, а в голосовом канале вечное подключение, пинг 5000 или никого не слышно.

--filter-tcp=443-65535 --filter-l7=tls {HOSTLIST:discord}
--in-range=-s5556 --out-range=-d10 --payload=tls_client_hello
--lua-desync=circular:fails=2:time=300
  # вариант 1: hostfakesplit
  --lua-desync=hostfakesplit:host=www.google.com:tcp_ts=-1000:tcp_md5:repeats=4:strategy=1
  # вариант 2: двойной fake
  --lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6:strategy=2
  --lua-desync=fake:blob=tls_vk:tcp_ts=-1000:repeats=6:strategy=2
  # вариант 3: fake плюс перекрытие
  --lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6:strategy=3
  --lua-desync=multisplit:pos=1,midsld:seqovl=681:seqovl_pattern=tls_google:strategy=3:optional

circular

Не приём, а распорядитель: он переключает варианты сам, когда его детектор ловит провал. Успешный вариант больше не трогается, и всё это происходит на лету, без перезапуска движка.

fails=2:time=300

Переключаться после двух неудач; окно счёта 300 единиц времени.

strategy=1, 2, 3

Метки вариантов. Нумерация начинается с единицы и идёт без пропусков. Внутри одного варианта может быть несколько приёмов, как в варианте 2.

три независимо рабочих варианта

Это не случайный набор: 1 повторяет рекомендуемую, 2 повторяет ALT10, 3 повторяет ALT11. То есть перебираются три подхода, каждый из которых у кого-то работает сам по себе.

--in-range обязателен

Без кэша входящих пакетов детектор не увидит сброс от DPI и переключаться будет нечему. Пропустить этот флаг означает получить неработающую ротацию.

Когда брать. Когда именно Discord ведёт себя нестабильно: то подключается, то нет. Помечена экспериментальной, потому что зависит от распорядителя, которого движок подгружает отдельной библиотекой.