MTProto в 2026 году

Смогли рубануть даже fake tls. Спасибо софту “Z” за помощь в дурении.

Правда так и не понятно а что сломали?

С сервера тоже можно, если слать fake перед server hello.
Не 100% стабильно на всех провайдерах, но в основном срабатывает.
Зато на девайсах ничего не нужно делать

А вы гений :slight_smile:

Видимо все, MTProxy умер, как и SOCKS5, что не пробовал накатывать, все бесполезно, работают только HTTP прокси на ПК, но на телефонах нет поддержки HTTP

Гений но я понял почему я об этом не подумал.

Сгенерированный пакет дальше виден как:

mark=40000000 ifin=lo
ignoring generated packet

Для ТСПУ у провайдера клиента это бесполезно, потому что провайдер уже увидел исходный SYN до того, как он дошёл до VPS поэтому толку в этом мало.

Пока идей нет. Впрочем нашептали что надо ограничивать ответы на syn пакеты (не чаще 1 в секунду).

Единственное что точно известно на яндекс клауд блокировки этой нет.

nft 'add table inet filter; add chain inet filter output { type filter hook output priority 0; }; add rule inet filter output tcp flags & (syn|ack) == syn|ack tcp sport 443 limit rate over 1/second burst 1 packets drop'

помогает оживить MTProxy

Не знаю, как у вас, а у меня позавчера отвалились телемт прокси на двух VPS на яклауде, которые несколько месяцев прекрасно работали. И видимо не я один такой, судя по постам на 4pda.

Да. Но решение уже найдено. Можно и без запрета. И без дурилок выше с syn пакетами в раз одну секунду – это бред, а не решение.

А какое решение-то?

Менять ClientHello где банят его – ну а где-то и лимит про 1 секунду SYN пакета достаточно.

Это кстати объясняет почему ВК сломался у многих, скорость упала в хроме и все РУ провайдеры сегодня в панике носятся и говорят что “у нас ничего не сломалось”.

У меня nginx (myserver.com) слушает внешний 443 порт, и если видит в SNI ad.myserver.com то кидает его на telemt 127.0.0.1:1080. И какой порт мне надо ставить в дурилку SYN пакета? ClientHello я же не могу поменять. Кстати, кто-нибудь пользовался mtproto.zig, он вроде умеет

TCPMSS=88 Дробит ClientHello на маленькие TCP-пакеты
nfqws TCP desync Fake packets + TTL-limited splits против stateful DPI

имхо не отпечаток, а зашкваренные хостинги\ип массово обновили

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

главное что 1 из них и при плешивом бс продолжает на lte жить и медию без шейпа качает

Так можно на зависание нарваться - нет фильтра в таблицах по mark
Если он блочит по SYN сразу - это называется блок по IP или IP:port и запрет тут не при делах
Обычно блок срабатывает даже не сразу после client hello, поэтому если ответ от сервера будет бредоерундой или не tls server hello, то алгоритм блокировки рассыпается.

del

У кого-то удавалось оживить MTProto через ByeByeDPI?

Мои двое telemt проксей оживают при включении ByeByeDPI. Стратегия подобрана на ютуб вручную, старая.
-o1 -d1 -a1 -At,r,s -s1 -d1 -s5+s -s10+s -s15+s -s20+s -r1+s -S -a1 -As -s1 -d1 -s5+s -s10+s -s15+s -s20+s -S -a1

Также некоторые (публичные) работают как раньше.

Спасибо, попробую.

Продолжая обсуждение из темы Zapret: what’s new:

Вот это теоретически можно использовать как раз с мтпрокси. Но пока избыточно для обхода после 5 июня.

В curl-impersonate есть curl со свежим отпечатком chrome145. Докинул в папку такой тупой скрипт:

parallel.sh
#!/bin/bash

SCRIPT_LOCATION="$(dirname $(realpath $0))"
#DOMAIN=46.183.116.195.nip.io; PORT=47443; RESOURCE=flood.html
DOMAIN=google.com
PORT=
IP=
RESOURCE=
PARALLEL_REQUESTS=3
ARGS="-Ik4 -m 10 ${IP:+--resolve $DOMAIN:${PORT:-443}:$IP} --parallel --parallel-immediate "

for i in $(seq $PARALLEL_REQUESTS)
do
	ARGS="$ARGS""https://$DOMAIN:${PORT:-443}/$RESOURCE -o /dev/null "
done
IMPERSONATE_SCRIPT="curl_chrome145"
echo "$SCRIPT_LOCATION/$IMPERSONATE_SCRIPT $ARGS"
"$SCRIPT_LOCATION/$IMPERSONATE_SCRIPT" $ARGS

Провайдер Ростелеком, МО. До моего ВПС в Европке 3 одновременных соединения проскакивают, если соединений четыре - триггерится блок на отпечаток chrome145 на какое-то время. Более старые версии продолжают работать (проверял chrome131 - работает). Такая же реакция у нескольких обычных сайтов из Hetzner as24940, например. Ответ сервера не важен, блокируются даже 4 TLS соединения на настоящий ssh на порту 22. Со стороны клиента дурилки client_hello помогают, но это неудобно на нерутованной мобиле на сотовой сети.

Снял дамп через PCAPdroid - телега может делать и 6 соединений к Fake-TLS прокси подряд с JA4 отпечатком chrome145. Такое поведение могли бы исправить авторы клиента телеги, но Паша слишком занят цифровым сопротивлением в твитторе. Предложенный выше костыль можно немного доработать:

добавить в /etc/nftables.conf
table inet rkn-anti-burst {
	set anti-burst {
		type ipv4_addr
		size 65535
		flags dynamic,timeout
		timeout 1m
	}
	chain prerouting_early_drop {
		type filter hook prerouting priority -201; policy accept;
		meta nfproto ipv4 tcp flags == syn tcp dport 443 update @anti-burst { ip saddr limit rate over 2/second burst 1 packets } drop
	}
}

Так боты-сканеры не будут мешать прокси на 443 порту, и несколько пользователей друг другу. Но если у клиентов прокси один внешний IP, то скорость установления соединения к прокси может упасть.

UPD: прозевал, статья на хабре была

а если попробовать встроенную в xray finalmask фрагментацию?