Блокировки на российских серверах Cloudflare (CDN/DNS/WARP)

Сегодня заметил на DME 16 кб блокировку для

rbc.ru

Так же уже некоторое время вижу полную блокировку к своему сайту который поднят на домашнем проводном РТК Москва. Если подключаться к нему через warp пинг не проходит, рукопожатие тоже. У других провайдеров пока такого не заметил

16 кб блоки на варпе:

  1. https://www.infrance.su/forum/
curl -A "Mozilla" https://www.infrance.su/forum/ >> /dev/null

Также блочит Hetzner клиентов, но не сразу.

  1. https://images.vfl.ru/ii/1777634000/f549f53a/40187825.jpg
curl https://images.vfl.ru/ii/1777634000/f549f53a/40187825.jpg >> /dev/null

upd: это не точно, на кажется, если качать торренты через warp, то к ростелекомовским пирам теперь можно подключиться только с принудительным шифрованием (флаг E).

На WARP+ в Рылеево (104.28.156.92) есть ограничения telegram и других сайтов, но они то работают, то не работают.

Сейчас WARP+ через usque и оффициальный клиент коннектит к Домодедово. Ограничений нет

DME ограничения есть только на тг, картинки с веб версии не отправляются

16 кб блок

deutschebank.ru

и другие его домены

www.nic.ru
конкретно storage.nic.ru

Телега через warp(wg, usque) через DME работает исправно

Заметил на днях у себя, что QUIC не работает на эндпоинтах из подсети 8.47.69.0/24 и 8.6.112.0/24:

$ curl -4vo /dev/null --max-time 3 --doh-url https://1.1.1.1/dns-query --http3-only https://4pda.to
* Some HTTPS RR to process
* Host 4pda.to:443 was resolved.
* IPv6: (none)
* IPv4: 8.6.112.0, 8.47.69.0
* HTTPS-RR: 1 . alpn=h2 ipv6hint=2a06:98c1:3122:8000::,2a06:98c1:3123:8000:: ipv4hint=8.6.112.0,8.47.69.0
*   Trying 8.6.112.0:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
*   Trying 8.47.69.0:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* Connection timed out after 3000 milliseconds
* closing connection #0
curl: (28) Connection timed out after 3000 milliseconds
$ curl -4vo /dev/null --max-time 3 --doh-url https://8.8.8.8/dns-query --http3-only https://4pda.to
* Some HTTPS RR to process
* Host 4pda.to:443 was resolved.
* IPv6: (none)
* IPv4: 8.47.69.6, 8.6.112.6
* HTTPS-RR: 1 . alpn=h2 ipv6hint=2a06:98c1:3122:8000::6,2a06:98c1:3123:8000::6 ipv4hint=8.6.112.6,8.47.69.6
*   Trying 8.47.69.6:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
*   Trying 8.6.112.6:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* Connection timed out after 3001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 3001 milliseconds
$ curl -4vo /dev/null --max-time 3 --doh-url https://9.9.9.11/dns-query --http3-only https://4pda.to
* Some HTTPS RR to process
* Host 4pda.to:443 was resolved.
* IPv6: (none)
* IPv4: 8.6.112.9, 8.47.69.9
* HTTPS-RR: 1 . alpn=h2 ipv6hint=2a06:98c1:3122:8000::9,2a06:98c1:3123:8000::9 ipv4hint=8.6.112.9,8.47.69.9
*   Trying 8.6.112.9:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
*   Trying 8.47.69.9:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* Connection timed out after 3000 milliseconds
* closing connection #0
curl: (28) Connection timed out after 3000 milliseconds
$ curl -4vo /dev/null --max-time 3 --doh-url https://9.9.9.9/dns-query --http3-only https://4pda.to
* Some HTTPS RR to process
* Host 4pda.to:443 was resolved.
* IPv6: (none)
* IPv4: 104.20.39.144, 172.66.159.63
* HTTPS-RR: 1 . alpn=h2 ipv6hint=2606:4700:10::6814:2790,2606:4700:10::ac42:9f3f ipv4hint=104.20.39.144,172.66.159.63
*   Trying 104.20.39.144:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
*   Trying 172.66.159.63:443...
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* Server certificate:
*   subject: CN=4pda.to
*   start date: May 10 18:50:49 2026 GMT
*   expire date: Aug  8 19:50:43 2026 GMT
*   issuer: C=US; O=Google Trust Services; CN=WE1
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   subjectAltName: "4pda.to" matches cert's "4pda.to"
* OpenSSL verify result: 0
* SSL certificate verified via OpenSSL.
* Established connection to 4pda.to (104.20.39.144 port 443) from 192.168.1.244 port 33875
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
  0      0   0      0   0      0      0      0           00:02              0* using HTTP/3
* [HTTP/3] [0] OPENED stream for https://4pda.to/
* [HTTP/3] [0] [:method: GET]
* [HTTP/3] [0] [:scheme: https]
* [HTTP/3] [0] [:authority: 4pda.to]
* [HTTP/3] [0] [:path: /]
* [HTTP/3] [0] [user-agent: curl/8.20.0]
* [HTTP/3] [0] [accept: */*]
> GET / HTTP/3
> Host: 4pda.to
> User-Agent: curl/8.20.0
> Accept: */*
>
* Request completely sent off
< HTTP/3 403
< accept-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
< cf-mitigated: challenge
< content-type: text/html; charset=UTF-8
< x-frame-options: SAMEORIGIN
< server: cloudflare
< critical-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
< cross-origin-embedder-policy: require-corp
< cross-origin-opener-policy: same-origin
< cross-origin-resource-policy: same-origin
< origin-agent-cluster: ?1
< permissions-policy: accelerometer=(),camera=(),clipboard-read=(),clipboard-write=(),geolocation=(),gyroscope=(),hid=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=(),xr-spatial-tracking=*
< referrer-policy: same-origin
< server-timing: chlray;desc="a0c3d5d40c431053"
< server-timing: cfExtPri
< x-content-type-options: nosniff
< strict-transport-security: max-age=2592000; preload
< date: Mon, 15 Jun 2026 19:03:31 GMT
< priority: u=3,i=?0
< content-length: 9996
< cf-ray: a0c3d5d40c431053-HKG
<
{ [125 bytes data]
100   9996 100   9996   0      0   3422      0   00:02   00:02              0
* Connection #0 to host 4pda.to:443 left intact

с двух разных зарубежных эндпойнтов недоступен хабр (который видимо находится где-то в москве)
не проходит ни ping ни syn

Спойлер

Хабр находится за anycast IP куратора, вполне может быть активна агресcивная митигация атак со стороны последних

С Амстердама проходит ping у меня:
image
Сам сайт также открывается.

Ещё заметил, что домены Proton снова перестали резолвиться у их DNS.

В смысле куратора?

В буквальном. https://curator.pro

У меня github как-то странно работает через 162.159.192.1 (colo=fra) и 162.159.195.1 (colo=dme), loc=ru у обоих, ростелеком. То грузит, то не грузит, не пойму. У всех так?

У гитхаба четыре ip, два из них под замедлением уже несколько месяцев

Не совсем понял) Cloudflare замедляет?) В плане, без vpn ничего не тупит, всё грузит ровно, а с варпом через ж*** работает.

А вот интересно. Говорят, после DME стоит ТСПУ. Но
curl -4 -v https://rutracker.org/cdn-cgi/trace открывается, а
curl -4 -v https://rutracker.org нет
Как же так? Ведь в https параметры URL зашифрованы.

Почему тогда youtube, instagram и куча прочего заблокированного работает?

Ютуб заблочен по ipv4, но браузер предпочитает ipv6.
tuta.com не открывается.
А вы попробуйте для прикола ipv6 в конфиге отключить. Ведь это же невозможно будет пользоваться.
Или скачайте через yt-dlp (yt-dlp предпочитает ipv4, вроде).
Но главный вопрос как чебурнилы залезают в https? (trace работает, рутрекер нет).

Никак они не залезают. То что после DME стоит тспу не значит, что абсолютно весь трафик идет именно через тспу, до сих пор бывают моменты что достаточно обновить страницу раз 5-10 и она загрузится.

Дата центрные тспу сильно отличаются от тех которые на домашних провайдерах, их максимум это банить глобально по ip например как это сделано с тг. Если они будут анализировать sni да еще и пытатся в https залезть то тут даже магистральные провайдеры лягут

Что это значит? Что не блокируют/не фильтруют? Понятное дело, работающим это не назвать, раз через жопу только с 5-10 раза работает))

А они вообще там есть? Если они там есть, то как-то странно они работают, раз всего пара-тройка никому ненужных сайтов не работает

Штука мощная, наверное, там можно все-таки настроить это…

А зачем его отключать?

Убрал я из dns и address ipv6 адреса, ютуб в браузере как работал, так и работает. Решил проверить телеграм (сайт, канал) - вообще не грузит без ipv6 ни на DME, ни на FRA

Хз, как минимум с ipv6 в конфиге у меня все открывается

@wigeance Доброе утро/день/вечер/ночь! Подскажите, как сейчас обстоят дела с тспу после двенадцать девяносто девять? Странный какой-то тспу с таким мизерным количеством ограничений