РКН начал использовать запрет?

Пока делал детектор торента, обнаружил, что по utp каналу из 50 пиров обычно 2-3 сыпят quic google.com
Иного обьяснения как сборка запрета найти сложно.
Казалось бы запрет - какая-то дичь непонятная, но юзает народ
Причем непонятно то ли это намеренно по торренту бьют , то ли какой-то лось засборил --wf-udp-out=1-65535 any protocol . Хоть с cutoff слава оллаху

Это, кстати, возможная причина почему может неверно назначиться l7proto на входящие. Если incoming сыпет запретом. Запрет дурит запрет. До чего мир докатился. Лучше бы РКН задурил РКН

Новый оркестратор 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 и все фильтры