Блокировка OVH после отправки UDP-пакетов DHT-пирам

Судя по всему это не сработает. Посмотрел я forward dns записи на bgp tools в той подсети, в которой я словил триггер по TCP (ну и UDP потом). Нашёл Mattermost, от открывается, он загружается, он не задевает триггер. Отправил для уверенности 3 UDP пакета не не HTTPS порт на айпишник этого сайта - треггер всё равно не задело. Так что увы, не вижу смысла по одному айпишнику из каждой asn брать, только в ручную страдать с торрентами.

т.е. блок триггерит только 151.115.97.151 но не 151.115.97.150/152?

Ну везде написанно что подсеть в которой висит 151.115.97.151 это 151.115.64.0/18
вот беру айпишники почти крайние этой подсети, так же айпишник сайта, и потом айпишники 150/152
Вот чё получилось

Precheck complete
ip 151.115.64.2:6881 pass (1/6)
ip 151.115.127.253:6881 pass (2/6)
ip 151.115.73.218:6881 pass (3/6)
Таймаут запроса.
ip 151.115.97.150:6881 failed (4/6)

151.115.97.152:6881 тоже проверил тоже триггерит

что это такое не понял

первые три айпишника не стриггерили, соседний (.150) стриггерил

ну если .0 тоже триггерит то хорошо будет, можно получить все /24 со всех asn (кроме рф, китая и т.п.) и проверять только 1 айпи из 256

:white_check_mark: - не задевает триггер
:cross_mark: - задевает триггер (срабатывает)
151.115.97.0:6881 :white_check_mark:(1/3)
151.115.97.1:6881 :cross_mark:(1/20)
151.115.96.255:6881 :white_check_mark:(2/3)
151.115.96.254:6881 :cross_mark:(3/3)
151.115.96.0:6881 :white_check_mark:(1/11)
151.115.96.1:6881 :cross_mark:(2/11)

Сдедовательно:
.0 и .255 триггер не триггерят даже если соседние адреса триггерят
.96.0 тоже забанена :slight_smile:

я прямо сейчас сканирую .0 со всех публичных подсетей /24 ipv4 (кроме рф, китая, украины, вышло около 11 млн айпи) на рт сз, пока что просканил примерно 20%, но уже поймал блок 7-zip.org после обращений на .0 ovh и scaleway

Ну у меня триггерят 151.115.97.1 и 151.115.96.254, при этом находящиеся между ними 151.115.96.255 и 151.115.97.0 не триггерят
Проверь это у себя, может лучше UDP слать на .1 всё же

не знаю тригерит или нет в отличии от DHT
но наткнулся на такое в логах (dnscrypt-proxy)
на кучу разных хостингов с нодами его UDP:443 UDP:8443

Спойлер
|17:59:56,4317508|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:56000 -> 196.240.79.163:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|17:59:58,1535012|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:54113 -> 193.32.87.127:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|17:59:58,1580582|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:54115 -> 195.242.212.131:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:02,1588726|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:52927 -> 23.137.253.24:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:03,5060274|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:59062 -> 146.70.82.3:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:05,5283936|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:58216 -> 78.129.248.67:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:26,0570698|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:53276 -> 104.36.86.181:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:27,7314580|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:50180 -> 190.211.255.227:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:40,8622027|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:61891 -> 217.138.220.243:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:41,6024436|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:51693 -> 209.58.147.36:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:43,8745914|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:60455 -> 195.12.48.171:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:50,9639704|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:51572 -> 217.138.219.219:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:52,7078167|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:52424 -> 217.138.220.243:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:52,7082140|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:52425 -> 86.106.74.219:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:54,9993582|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:53498 -> 45.86.162.110:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:56,7176954|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:62710 -> 185.234.52.87:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:00:56,7178330|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:62711 -> 79.124.77.3:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:13,5606540|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:64781 -> 104.234.231.239:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:13,5611373|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:64782 -> 154.16.159.22:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:14,1938868|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:58732 -> 185.93.221.167:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:19,2332885|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:55860 -> 176.111.219.126:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:20,9932060|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:52130 -> 198.7.58.227:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:21,0008603|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:52131 -> 209.58.147.36:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:21,2710212|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:65411 -> 185.93.221.167:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:24,2910827|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:55252 -> 194.26.213.15:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:25,0226184|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:55254 -> 217.138.220.243:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:29,0249418|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:57159 -> 104.238.186.192:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:32,3760313|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:49893 -> 45.80.209.55:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:39,4422860|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:64985 -> 195.123.245.19:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:47,5342827|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:62318 -> 176.113.74.19:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
|18:01:53,6008045|dnscrypt-proxy64.exe|16744|UDP Send|192.168.1.111:50397 -> 165.232.32.95:443|SUCCESS|Length: 576, seqnum: 0, connid: 0|
findstr /i scaleway public-resolvers.md
## scaleway-ams
DNSSEC/Non-logged/Uncensored in Amsterdam - DEV1-S instance donated by Scaleway.com
## scaleway-fr
DNSSEC/Non-logged/Uncensored in Paris - DEV1-S instance donated by Scaleway.com
## sfw.scaleway-fr 
Hosted in Paris, running on a 1-XS server donated by Scaleway.com

в общем действительно .1 триггерят блок чаще, поэтому просканил их.
триггеры есть как минимум в
AS12876 SCALEWAY S.A.S. - 99 /24 триггеров
AS63023 GTHost - 26 /24
AS33333 objx.net - 18 /24
AS206378 Stolitomson - 16 /24
AS25198 INTERKVM HOST SRL - 2 /24
AS40065 CNSERVERS LLC - 1 /24
AS60068 Datacamp Limited - 1 /24
AS135391 AOFEI DATA - 1 /24
AS214894 Cloud225 - 1 /24

в AS24940 Hetzner и AS16276 OVH тоже есть триггеры, но у них слишком много /24, проверка заняла бы слишком долго поэтому точного списка нет

список триггерящих asn и подсетей (кроме hetzner и ovh)
bad_iplist.txt (3.5 KB)

ну и еще 134.195.198.1 не триггерит блок, но 134.195.198.230 и другие ip из /24 триггерят блок, так что мой список не точный т.к. проверялся только .1

У меня также вернулись блокировки. Datacamp 62.93.165.0 - 62.93.165.255.

Подтверждаю. РТК ПФО

у меня на рт сз отправка пустых udp на твой диапазон триггерит блок timeweb (ru ip, напр applee.ru). (hetzner 7-zip.org при этом впорядке)

upd:
sni stackoverflow.com обходит блок
http и ssh блочит тоже (мгновенно)
блок срабатывает на ближайшем тспу (отправлял udp с ттл=3)

СЗ, хожу через AS31500
у меня 62.93.165.0/24 триггерит timeweb И OVH
всё остальное нормально работает (хетзнер, скейлвей и тд)
Щас из МСК проверю
UPD Абсолютно такая же ситуация из Москвы на AS8334
@0ka у тебя OVH с триггером таймвеба не отлетает?

Та же проблема. Трассировка при этом ок в обе стороны, по дампам трафика (пробую ssh), со стороны сервера:

tcpdump на сервере

10:51:19.073558 IP host-my-ip.bb-nsk.sib.mts.ru.58148 > somehost.tmweb.ru.ssh: Flags [S], seq 676237546, win 64240, options [mss 1400,sackOK,TS val 3093116117 ecr 0,nop,wscale 10], length 0
10:51:19.135672 IP host-my-ip.bb-nsk.sib.mts.ru.58148 > somehost.tmweb.ru.ssh: Flags [.], ack 2210502822, win 63, options [nop,nop,TS val 3093116180 ecr 3115421939], length 0

tcpdump на клиенте

15:48:48.535906 IP 192.168.100.2.53344 > someip.22: Flags [S], seq 1960136578, win 64240, options [mss 1460,sackOK,TS val 3096565594 ecr 0,nop,wscale 10], length 0
15:48:48.604488 IP someip.22 > 192.168.100.2.53344: Flags [S.], seq 2631081474, ack 1960136579, win 65160, options [mss 1400,sackOK,TS val 3118871413 ecr 3096565594,nop,wscale 7], length 0
15:48:48.604509 IP 192.168.100.2.53344 > someip.22: Flags [.], ack 1, win 63, options [nop,nop,TS val 3096565662 ecr 3118871413], length 0
15:48:48.604607 IP 192.168.100.2.53344 > someip.22: Flags [P.], seq 1:23, ack 1, win 63, options [nop,nop,TS val 3096565662 ecr 3118871413], length 22: SSH: SSH-2.0-OpenSSH_10.0
15:48:48.874654 IP 192.168.100.2.53344 > someip.22: Flags [P.], seq 1:23, ack 1, win 63, options [nop,nop,TS val 3096565933 ecr 3118871413], length 22: SSH: SSH-2.0-OpenSSH_10.0
15:48:49.146662 IP 192.168.100.2.53344 > someip.22: Flags [P.], seq 1:23, ack 1, win 63, options [nop,nop,TS val 3096566205 ecr 3118871413], length 22: SSH: SSH-2.0-OpenSSH_10.0

Последний пакет при этом начинает просто повторяться бесконечно, но на сервере его нет

Адреса src/dest скрыты, но точно доподлинно известно, что есть проблема по отношению к сетям в СПб/МСК, Новосибирск, Нидерланды и Германию проблема не затрагивает, возможно из-за того, что там другие AS

62.93.165.0/24 перестал триггерить у меня блокировку TimeWeb (на примере applee.ru), теперь блокирует только OVH. Видимо санкции с TimeWeb сняты
Проверял в ЦФО на РТ, Йоте и AS8334
UPD: Зато была замечена мной кратковременная недоступность только DigitalOcean, подозреваю очередной триггер, постараюсь в ближайшее время вычислить адрес

Появился новый триггер - 151.243.109.0/24 AS209274 Kraken Network ISP
Изначально я выловил 151.243.109.110 в дампе трафика торрент клиента, но другие адреса 151.243.109.1хх тоже триггерят блок на 10 минут.

Найден ещё один триггер - 82.198.246.97 AS212238 Datacamp. В этот раз не связано с торрентами, обнаружил его по чистой случайности.

Пришёл гость, подключился к гостевому WiFi, в ту же минуту посыпались алерты из Uptime Kuma о недоступностях хостингов (у меня настроен мониторинг, как раз чтобы отлавливать такие ситуации с “триггерами”). Гость оказался любителем сидеть в интернете через бесплатные прокси, он был подключен к публичному VMESS прокси на 82.198.246.97:180.

Та же история - отправка любых пакетов на этот адрес триггерит блок разных хостингов на 10 минут. Выборочно потыкал другие адреса из этой подсети, но они блок не триггерят. Этот адрес в базах действительно бьется как Public Proxy Service. Похоже, это новый прецедент.

Уже не первый месяц мучаюсь с блокировками сайтов из-за постоянно работающих торрент-клиентов. Есть ли инструменты под Windows (для чайников), чтобы определить обращение к каким адресам вызывает блок?