наблюдаю необъяснимую потерю скорости отдачи торрентов. Ещё вчера была 8Мбайт/сек, сейчас не поднимается выше 1Мбайта/сек. Провайдер - Ростелеком.
количество и состав торрентов не изменились
Upd:
Вырубили электричество на 5 минут. После скорость снова возросла до 5мбит/сек.
Я - паникёр. Отбой тревоги
А есть теоретическая возможность у Ростелекома ограничивать скорость скачивания в торрент-клиенте?
Есть, если есть ТСПУ. Но обычно скорость торрентов ограничивают мобильные операторы.
а это можно как-то проверить и по возможности обойти?
В домашнем регионе у РТ скорость до гигабита, так? Если да, то раздайте торрент у другого человека в вашем городе с РТ, и посмотрите какая будет скорость у вас. Если ожидания не будут оправданы, проверьте также и скачивание файла с веб сервера (miniweb подойдет)
Со вчерашнего дня пропали все DHT пиры, провайдер wifire (chebnet), связано ли с блокировками?
$ nping --udp -g 6881 -p 25401 -c1 dht.libtorrent.org --data "\x64\x31\x3a\x61\x64\x32\x3a\x62\x73\x69\x31\x65\x32\x3a\x69\x64\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x85\xbd\x80\x66\x18\x56\x00\xfd\x39\x3a\x69\x6e\x66\x6f\x5f\x68\x61\x73\x68\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x4a\x6d\x72\xdb\x91\x7c\x54\xcc\x65\x31\x3a\x71\x39\x3a\x67\x65\x74\x5f\x70\x65\x65\x72\x73\x31\x3a\x74\x32\x3a\x1a\x2e\x31\x3a\x76\x34\x3a\x4c\x54\x01\x2d\x31\x3a\x79\x31\x3a\x71\x65"
Starting Nping 0.7.94 ( https://nmap.org/nping ) at 2023-09-06 04:29 MSK
SENT (0.0040s) UDP packet with 111 bytes to dht.libtorrent.org:25401 (185.157.221.247:25401)
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
UDP packets sent: 1 | Rcvd: 0 | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.01 seconds
$ nping --udp -g 6881 -p 6881 -c1 router.bittorrent.com --data "\x64\x31\x3a\x61\x64\x32\x3a\x62\x73\x69\x31\x65\x32\x3a\x69\x64\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x85\xbd\x80\x66\x18\x56\x00\xfd\x39\x3a\x69\x6e\x66\x6f\x5f\x68\x61\x73\x68\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x4a\x6d\x72\xdb\x91\x7c\x54\xcc\x65\x31\x3a\x71\x39\x3a\x67\x65\x74\x5f\x70\x65\x65\x72\x73\x31\x3a\x74\x32\x3a\x1a\x2e\x31\x3a\x76\x34\x3a\x4c\x54\x01\x2d\x31\x3a\x79\x31\x3a\x71\x65"
Starting Nping 0.7.94 ( https://nmap.org/nping ) at 2023-09-06 04:30 MSK
SENT (0.0105s) UDP packet with 111 bytes to router.bittorrent.com:6881 (67.215.246.10:6881)
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
UDP packets sent: 1 | Rcvd: 0 | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.01 seconds
$ nping --udp -g 6881 -p 25401 -c1 dht.libtorrent.org --data-string A; \
nping --udp -g 6881 -p 25401 -c1 dht.libtorrent.org --data "\x64\x31\x3a\x61\x64\x32\x3a\x62\x73\x69\x31\x65\x32\x3a\x69\x64\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x85\xbd\x80\x66\x18\x56\x00\xfd\x39\x3a\x69\x6e\x66\x6f\x5f\x68\x61\x73\x68\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x4a\x6d\x72\xdb\x91\x7c\x54\xcc\x65\x31\x3a\x71\x39\x3a\x67\x65\x74\x5f\x70\x65\x65\x72\x73\x31\x3a\x74\x32\x3a\x1a\x2e\x31\x3a\x76\x34\x3a\x4c\x54\x01\x2d\x31\x3a\x79\x31\x3a\x71\x65"
Starting Nping 0.7.94 ( https://nmap.org/nping ) at 2023-09-06 04:32 MSK
SENT (0.0028s) UDP packet with 1 bytes to dht.libtorrent.org:25401 (185.157.221.247:25401)
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
UDP packets sent: 1 | Rcvd: 0 | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.00 seconds
Starting Nping 0.7.94 ( https://nmap.org/nping ) at 2023-09-06 04:32 MSK
SENT (0.0062s) UDP packet with 111 bytes to dht.libtorrent.org:25401 (185.157.221.247:25401)
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
UDP packets sent: 1 | Rcvd: 0 | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.01 seconds
$ traceroute dht.libtorrent.org
traceroute to dht.libtorrent.org (185.157.221.247), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 0.642 ms 0.611 ms 0.594 ms
2 chb-b21-p4.ti.ru (212.1.254.164) 2.005 ms 1.908 ms 1.923 ms
3 212.1.240.218 (212.1.240.218) 2.492 ms 2.599 ms 2.536 ms
4 178.176.191.136 (178.176.191.136) 4.294 ms 3.675 ms 4.305 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 83.169.204.78 (83.169.204.78) 36.105 ms 35.896 ms 83.169.204.82 (83.169.204.82) 35.506 ms
10 netnod-ix-ge-a-sth-1500.portlane.net (194.68.123.194) 54.231 ms 53.404 ms 54.309 ms
11 be-1.cr2.got1.se.portlane.net (80.67.4.146) 54.669 ms 55.175 ms 56.999 ms
12 be-9.cr2.fal4.se.portlane.net (80.67.4.195) 58.010 ms 57.322 ms 54.711 ms
13 eth-52-2.le4.fal4.se.portlane.net (80.67.4.202) 53.836 ms 54.165 ms eth-52-2.le3.fal4.se.portlane.net (80.67.4.200) 55.630 ms
14 vl-166.z10-03-05.fal4.se.portlane.net (46.246.38.1) 54.626 ms 54.905 ms 56.152 ms
15 185-157-221-247-static.glesys.net (185.157.221.247) 55.709 ms 56.878 ms 56.518 ms
На рутрекере тоже массовые жалобы на работу торрентов.
Похоже на всех провайдерах заблочили. 3 прова проводных в спб одна картина.
Блокируются в stateful режиме исходящие udp пакеты с src портом 1025…65535 на любые порты dst, с длиной от 101 до 399 байт (100<x<400), начинающиеся с “d1” и заканчивающиеся “e”
src port <=1024 не блокируются. поэтому один из вариантов заставить пакет проходить - назначить торрент клиенту порт из нижнего диапазона. Порт 1024 уникален тем, что он не требует рута, потому его можно использовать на unix/android
обычно пробив работает только в одну сторону (должно быть из-за множественных ТСПУ). после пробива обратные пакеты по той же связке src_port-dst_port с d1…e ходить не начинают. нужен пробив с обоих сторон, и потому с обходом не все так просто.
nfqws помогает, с ним количество DHT узлов быстро подпрыгивает до сотен, без него топчется на 1-2
Но проблема, что от других юзеров пакеты тоже блокируются, потому работает кое-как
Интересный момент. Пробовал отправлять себе с VPS из финки d1…e - не доходит. В финке нет ТСПУ.
Однако, от некоторых IP эти пакеты доходят. Страны в основном не Россия. Германия, США засветились. Но есть и парочка пакетов и от российских провайдеров.
Предполагаю, что все-таки пакеты на ТСПУ блокируются только исходящие, но кое-где стоят ТСПУ у магистралов, которые интерпретируют направление непонятно каким образом.
У некоторых Российских провайдеров все еще нет ТСПУ, либо он работает неправильно, либо по каким-то причинам там не задействовали блок.
Потому эффект получается такой : все исходящие блок, входящие - почти все блок.
Если бы все ТСПУ блочили и входящие, то мне бы не дошло ничего и ниоткуда.
Проводной МТС, северо-запад, аналогично
Может, это связано с выборами.
В прошлый раз DHT блокировали из-за навальновской проги с кандидатами.
УГ и блокировщик УГ это плохой (хороший) и хороший (плохой) полицейский.
У Lantern, Zeronet тоже DHT используется.
Скорее всего. Таких совпадений не бывает.
Может быть через несколько дней отключат.
Это сигнал. Ждем цифру 5.
Обнаружил, что пакеты с src port 1…1024 не блокируются.
Если бы все дружно изменили порт торент клиента на <=1024 (для android 1024 прокатит без рута), то у нас бы снова заработал DHT
Спасибо, хоть и поменял только у себя, но заметно лучше.
Порт входящих подключений в торрент клиенте влияет и на исходящий DHT?
Я так понимаю порт входящих подключений в торренте это и исходящий порт для соединения с пирами (сидами/личами). Но применяется ли он и для исходящих DHT запросов?
Видимо да, потому что в шарке с другого порта ничего не идет
qbittorrent ведет себя так, остальные не проверял
Лучше, но пиров практически 0 везде. Изредка кто-то еще появляется
nping всеравно говорит что ответа нет. Поменял порт в параметре -g