Скорее всего. Таких совпадений не бывает.
Может быть через несколько дней отключат.
Это сигнал. Ждем цифру 5.
Обнаружил, что пакеты с src port 1…1024 не блокируются.
Если бы все дружно изменили порт торент клиента на <=1024 (для android 1024 прокатит без рута), то у нас бы снова заработал DHT
Спасибо, хоть и поменял только у себя, но заметно лучше.
Порт входящих подключений в торрент клиенте влияет и на исходящий DHT?
Я так понимаю порт входящих подключений в торренте это и исходящий порт для соединения с пирами (сидами/личами). Но применяется ли он и для исходящих DHT запросов?
Видимо да, потому что в шарке с другого порта ничего не идет
qbittorrent ведет себя так, остальные не проверял
Лучше, но пиров практически 0 везде. Изредка кто-то еще появляется
nping всеравно говорит что ответа нет. Поменял порт в параметре -g
# nping --udp -p 4444 -g 1025 1.1.1.1 --data 64313a6164323a696432303a2e2b4e412da2d4757414dadb459677ce91694ab7393a696e666f5f6861736832303a3b0ac215c5d9e4bea7be93e4d9184fc1a33249c265313a71393a6765745f7065657273313a74323ae4e2313a76343a4c540208313a79313a7165
Starting Nping 0.7.91 ( https://nmap.org/nping ) at 2023-09-06 17:04 MSK
SENT (0.1050s) UDP x.x.x.x:1025 > 1.1.1.1:4444 ttl=64 id=17131 iplen=132
SENT (1.1082s) UDP x.x.x.x:1025 > 1.1.1.1:4444 ttl=64 id=17131 iplen=132
SENT (2.1181s) UDP x.x.x.x:1025 > 1.1.1.1:4444 ttl=64 id=17131 iplen=132
^C
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (396B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 2.34 seconds
# nping --udp -p 4444 -g 1024 1.1.1.1 --data 64313a6164323a696432303a2e2b4e412da2d4757414dadb459677ce91694ab7393a696e666f5f6861736832303a3b0ac215c5d9e4bea7be93e4d9184fc1a33249c265313a71393a6765745f7065657273313a74323ae4e2313a76343a4c540208313a79313a7165
Starting Nping 0.7.91 ( https://nmap.org/nping ) at 2023-09-06 17:04 MSK
SENT (0.1038s) UDP x.x.x.x:1024 > 1.1.1.1:4444 ttl=64 id=10912 iplen=132
RCVD (0.3613s) UDP 202.61.226.152:6882 > x.x.x.x:1024 ttl=53 id=57810 iplen=95
RCVD (0.3668s) UDP 146.19.24.245:43824 > x.x.x.x:1024 ttl=50 id=15931 iplen=95
RCVD (0.3806s) UDP 144.126.233.32:6882 > x.x.x.x:1024 ttl=51 id=48849 iplen=95
SENT (1.1074s) UDP x.x.x.x:1024 > 1.1.1.1:4444 ttl=64 id=10912 iplen=132
RCVD (1.1081s) UDP 18.196.86.103:6992 > x.x.x.x:1024 ttl=242 id=16918 iplen=104
RCVD (1.1081s) UDP 207.180.192.206:39380 > x.x.x.x:1024 ttl=53 id=54148 iplen=125
SENT (2.1177s) UDP x.x.x.x:1024 > 1.1.1.1:4444 ttl=64 id=10912 iplen=132
SENT (3.1274s) UDP x.x.x.x:1024 > 1.1.1.1:4444 ttl=64 id=10912 iplen=132
RCVD (3.1281s) UDP 196.190.32.17:28472 > x.x.x.x:1024 ttl=111 id=22325 iplen=427
RCVD (3.1281s) UDP 170.51.110.71:31204 > x.x.x.x:1024 ttl=223 id=50437 iplen=104
nping --udp -p 4444 -g 1024 1.1.1.1 --data 64313a6164323a696432303a2e2b4e412da2d4757414dadb459677ce91694ab7393a696e666f5f6861736832303a3b0ac215c5d9e4bea7be93e4d9184fc1a33249c265313a71393a6765745f7065657273313a74323ae4e2313a76343a4c540208313a79313a7165
Starting Nping 0.7.93 ( https://nmap.org/nping ) at 2023-09-06 17:28 MSK
SENT (0.0013s) UDP packet with 104 bytes to 1.1.1.1:4444
SENT (1.0024s) UDP packet with 104 bytes to 1.1.1.1:4444
SENT (2.0035s) UDP packet with 104 bytes to 1.1.1.1:4444
SENT (3.0046s) UDP packet with 104 bytes to 1.1.1.1:4444
SENT (4.0057s) UDP packet with 104 bytes to 1.1.1.1:4444
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
UDP packets sent: 5 | Rcvd: 0 | Lost: 5 (100.00%)
Nping done: 1 IP address pinged in 5.01 seconds
Попробовал другие порты кроме 1024, тоже самое
1.1.1.1 - плохой пример. это anycast.
попробуйте 178.210.74.11
разные хосты могут отвечать , а могут не отвечать на udp.
какие-то хосты или фаерволы генерят однократный icmp unreachable, но если взять другие без ддос защит, там многократный icmp ответ
На рутрекере говорят, что смена порта помогает.
Линуксоидов не слышно, им не повезло. Неудобно запускать торрент клиент от рута.
В линуксе можно установить net.ipv4.ip_unprivileged_port_start=0
Если бы все дружно изменили порт торент клиента
Это замкнутый круг. Блокируемое приложение тоже изменит настройки. Правила поправят и все по новой, в тупик.
Не совсем. На android , равно как и ios (bsd based ) , невозможно забиндаться на порты <1024. То, что пропускают 1024, это должно быть ошибка в правиле в знаке сравнения. <= вместо <
Само наличие этого правила указывает на таргетирование блока именно на телефоны, потому что для windows PC, откуда в основном качают торенты, это не имеет значения.
Значит блокируют не торент, а приложение, и даже если поправят на <1024, то торентщиков это сильно не расстроит. А на ведроидах можно с помощью рута опустить порог привилегированных портов.
BitTorrent DHT library patch
Патч для BitTorrent DHT library:
diff --git a/dht.c b/dht.c
index c069bc5..7f5c9ca 100644
--- a/dht.c
+++ b/dht.c
@@ -2507,6 +2507,8 @@ dht_send(const void *buf, size_t len, int flags,
return -1;
}
+ *(char *)(buf+len)=0;
+ len++;
return dht_sendto(s, buf, len, flags, sa, salen);
}
Выглядит не безопасно, но это только пример и один байт должен влезть (512 или 2048 байт для buf выбраны в коде с запасом). Можно усложнить код, выделять место на куче и добавлять несколько байт, включая рандом. Или менять только пинг?
Поскольку содержимое это строка, вменяемый парсер приемника должен такое принимать правильно.
Умное голосование мы делать будем, но точечно и непублично
Приложения еще нет, а солнцеликий уже испугался.
К сожалению, нет.
nfqws имеет режим десинхронизации udplen. Он дописывает указанное количество нулей в конец пакета, увеличивая его длину.
Да, такие пакеты проходят ТСПУ, но количество узлов по сравнению с вариантом без обхода не меняется. Их очень мало. Если же снизить порт до <=1024 или включить обход по fake, то их сразу же становится сотни.
UPD.
Если добивать пакеты не нулями, а символами “e” до превышения размера 400 байт
–dpi-desync=udplen --dpi-desync-any-protocol --dpi-desync-cutoff=d2 --dpi-desync-ttl=11 --dpi-desync-udplen-increment=300 --dpi-desync-udplen-pattern=0x65
то вроде работает. но узлов все равно меньше, чем при фейке или low port. видимо зависит от используемого клиента - хавает или не хавает
А могут ли нерутованные линуксовые торрент клиенты на высоких портах на белом ip принимать входящие подключения с портов <1024?
root требуется только для локального биндинга низких портов, а входящее прилететь может? Это например как если бы не ты подключался к серверу на 443 порт, а сервер подключался к тебе с 443 порта. Это редкость, вот я и спрашиваю. На случай, если виндоюзеры начнут менять у себя порты и заходят соединиться к ничего не подозревающим линуксоидам.
Отвечают на ping с нулевым приветом:
dht.libtorrent.org 25401
dht.transmissionbt.com 6881
router.bittorrent.com 6881