BitTorrent payload - быть или не быть?

[AlexTransit]

на урал, сегодня ночью, подвезли торрентовскую сигнатуру.
все входящие торрентовские TCP соединения "рубят" ресетом. (типа от пира прилетает ресет с задержкой в миллисекунду, после хендшейка)
может имеет смысл сделать BitTorrent payload? что бы на стадии конекта разобраться.

[bol-van]

шифрование в клиенте не лучше ли включить ?
вообще можно использовать lua protocol detector. они хоть и не действуют на execution plan и не появятся вдруг внезапно в ком строке nfqws, но "standard payload" в antidpi функциях реагирует на desync.l7payload

[bol-van]

в шифрованном варианте они могут искать стандартные для согласования ключей длины tcp сегментов.
их можно и порезать, и дисордером бахнуть по ним.
порт можно фильтрануть на уровне windivert фильтра. source or dest port = порт торрент клиента. его зафиксировать

[AlexTransit]

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

их можно и порезать, и дисордером бахнуть по ним.

тут я не совсем понял.

порт можно фильтрануть

тут совсем не понял. :) я порт указал в конфиге. и его видно в table inet zapret2 в цепочках prenat, postnat.

что я помотрел и сделал.
снав дамп увидел
FIN,ACK ← сразу после handshake
RST ← после payload. с минимальнейшей задержкой.
пробовал разные способы, и мне подсказали как можно сделать.
в дурилке,
--filter-tcp=12345 --payload=empty --lua-desync=multisplit:pos=1,6 --lua-desync=fake:repeats=1
а в nft
type filter hook prerouting priority mangle; policy accept;
iifname $wan tcp flags rst ct state established drop

такой фигней увел клиента в udp. но логичней порезать именно нужный payload. а как его задетектить я не знаю.

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

[bol-van]

Предполагал, что винда, но раз linux
Порт в linux конфиге не указать, потому что там только dest порты, но не src порты.
Кастом скрипт надо делать. Торрент клиент может быть зафиксирован на порт, а пиры имеют произвольные порты, поэтому dest port не работает.

Любое tcp соединение можно сегментировать и дисордернуть.

Если FIN идет сразу после tcp handshake, то дело не в сигнатуре. Может это белый список протоколов ? Или бан на конкретные IP ?
шифрованный торрент может опознаваться или по размеру пакетов, или статистическими методами

payload=empty - это не будет работать, вы неправильно пользуетесь
fake после split - тоже не слишком понятная штука
не учтен "standard payload" фильтр, он не пропустит unknown

пейлоад никак не задетектить в шифрованном торренте. в том и смысл шифрования

[AlexTransit]

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

[bol-van]

Для профилактики
Шифрованный он не обнаружит