Новый оркестратор per_instance_condition.
Бывает, что в одном профиле нужно вызывать разные инстансы с разными параметрами в
зависимости от текущей обстановки, которая не может быть выражена условиями --payload или range.

Оркестратор все последующие инстансы вызывает только, если у них есть аргумент “cond”. “cond” - имя iff функции. “cond_neg” - признак инверсии. Инстанс выполняется только если cond вернул true.
Имена аргументов выбраны не iff/neg, чтобы не было конфликтов с уже существующими вложенными оркестраторами.

Например, сервер не поддерживает timestamps. tcp_ts обламывается, соединение ожидаемо виснет, потому что фейк принимается сервером. Что делать ?
Можно было бы поломать код fake. Наплодить там тучу условий, аргументов. И реплицировать их на fakedsplit, hostfakesplit и тд. Но это путь уродования кода и превращения его в монстро-комбайн. Мы так не делаем

вот решение :

--lua-desync=per_instance_condition
--lua-desync=fake:blob=fake_default_tls:tcp_ts=-1000:cond=cond_tcp_has_ts
--lua-desync=fake:blob=fake_default_tls:ip_ttl=7:ip6_ttl=4:cond=cond_tcp_has_ts:cond_neg

И на закуску.

Аргумент “instances” в condition и per_instance_condition.
Выполнять условно только последующее кол-во инстансов, остальные безусловно.

cond_lua - iff функция, выполняющая произвольный код. Код должен вернуть значение условия.
Для всякой мелочи, чтобы не писать целые функции

Следующие 2 инстанса только для пакетов tcp с длиной данных не менее 1200 байт

--lua-desync=condition:instances=2:iff=cond_lua:code='return desync.dis.tcp and #desync.dis.payload>=1200'

В принципе, condition может заменить per_instance_condition, если его писать перед каждым инстансом и дать аргумент instances=1.
На самом деле это будут вложенные оркестраторы condition. Но запись с per_instance_condition будет компактнее

Когда я умру, помните мои последние слова к нации

НИХУЯ А ЧЕ ТАК МОЖНО

Теперь без вертикальных вкладок у меня такая фигня

Можно пожалуйста перестать меня блокировать

@remindertodotelegrambot умер но скоро восстановится.
Он мне нужен

Тут пишут что начали банить подсети стима по новому — никак не обойти блокировку — ни через белые SNI, ни через отправку мусора

Посмотрим когда раскатают для всех

С МТпрото очень интересное наблюдение.

Если подключаться через проксик MTProto, то идет соединение с другим адресом, но по тому же протоколу, при этом замедление остаётся и ЭТО ВАШ СЛУЧАЙ — блокируют именно протокол, а не подсеть. Либо и то и другое

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

И это уже интереснее так как тогда телеграм заблокировать получиться — впрочем расшифровка его протокола дорогая и очень ресурсоемкая.

В 99% случаев скорее всего банят CIDR и не парятся

открываешь service.bat, смотришь на пункты 4 и 5 и отправляешь соответствующие цифры (смена режима) до того как у пункта game filter стоит "enabled" и у пункта ipset filter - "any"

Ох шаманство

А я хочу пойти дальше и написать не просто нормальный айпсет а точечный windivert фильтр

Чтобы winws даже не захватывал лишние адреса на 443 и не пропускал их через pass и все фильтры

В запретехаб сделаю подтемы как у ntc.party чтобы было удобнее общаться