На ТСПУ начали блокировать/замедлять Twitter. В моём случае наблюдается блокировка (мобильный Теле2/проводной ОБИТ): подключение устанавливается, первые пакеты TLS-сессии проходят, но все последующие отбрасываются, и до передачи данных внутри сессии не доходит.
Другие пользователи отмечают замедление: https://twitter.com/_monoid/status/1497516502504947713
Для обхода блокировки/замедления можно использовать GoodbyeDPI на Windows (скрипт 2_any_country), zapret на Linux, модифицированный Fennec/Firefox на Android, а также прокси/VPN.
В исходном сообщении (был) процитирован твит, выглядевший довольно странно из-за сокращённых через t.co ссылок. Имелось в виду вот что:
openssl s_client -connect twitteR.com:443
работает быстро, а
openssl s_client -connect twitter.com:443
тормозит (на поддоменах тоже проявляется). Разница в поле SNI.
Как и в прошлый раз, замедляются/блокируются и другие домены, например, abs.twimg.com.
Картинка для теста:
https://abs.twimg.com/sticky/illustrations/lohp_1302x955.png
Есть смысл пытаться оживить сайтик для проверки?
A post was merged into an existing topic: Контейнер VPN АнтиЗапрета для установки на собственный сервер
Шаблоны доменов все поправили, из браузера не получится протестировать. Можно программу сделать, разве что.
Днём было всё в порядке, сейчас тоже наблюдаю замедление. Ростелеком, Свердловская область.
Точнее сказать, это даже не замедление, а невозможность загрузить часть контента. Страница профиля (шапка) может подгрузиться, а картинки и твиты — нет.
У меня на ТСПУшном провайдере не проходит на twitter TLS handshake
nfqws --dpi-desync=fake,split2 помог снять и блокировку, и замедление
Список доменов (F12 в броузере) :
twitter.com
api.twitter.com
abs.twimg.com
pbs.twimg.com
abs-0.twimg.com
t.co
Странная история --dpi-desync=fake,split2 помогает для abs.twimg.com, но не помогает для
twitter.com
api.twitter.com
abs-0.twimg.com
syndication.twitter.com
Маловероятно, но возможно, что запросы идут по разным каналам (апстримам). Проверьте дампом трафика, что пакеты действительно инжектятся, и убедитесь, что вы используете правильный TTL (или какой у вас метод) для поддельного пакета.
Да, действительно не инжектился пакет. Разобрался, почему-то для ipv6 только работало. abs.twimg.com = ipv6, остальные по 4-ке работают. Переустановил скрипт, прописал настройки и для ipv6 и для ipv4. Видимо только для ipv6 было настроено.
OONI measurements suggest potential throttling of @Twitter in russia. https://explorer.ooni.org/search?probe_cc=RU&test_name=web_connectivity&since=2022-01-27&until=2022-02-28&failure=false&domain=twitter.com
By looking at the “network_events” keys, we see that the TLS handshake is performed by reading very small chunks of data very slowly, sometimes leading to a timeout.
They don’t say what measurement they’re looking at, but here is an example from AS 15640 (MTS):
[
{
"address": "104.244.42.1:443",
"failure": null,
"operation": "connect",
"proto": "tcp",
"t": 0.1837934,
"tags": [
"tcptls_experiment"
]
},
{
"failure": null,
"operation": "tls_handshake_start",
"t": 0.1837934,
"tags": [
"tcptls_experiment"
]
},
{
"failure": null,
"num_bytes": 281,
"operation": "write",
"t": 0.1837934,
"tags": [
"tcptls_experiment"
]
},
{
"failure": null,
"num_bytes": 517,
"operation": "read",
"t": 4.796338,
"tags": [
"tcptls_experiment"
]
},
{
"failure": null,
"num_bytes": 507,
"operation": "read",
"t": 4.796338,
"tags": [
"tcptls_experiment"
]
},
{
"failure": null,
"num_bytes": 336,
"operation": "read",
"t": 10.111066,
"tags": [
"tcptls_experiment"
]
},
{
"failure": "generic_timeout_error",
"operation": "read",
"t": 10.1847777,
"tags": [
"tcptls_experiment"
]
},
{
"failure": "generic_timeout_error",
"operation": "write",
"t": 10.1847777,
"tags": [
"tcptls_experiment"
]
},
{
"failure": "generic_timeout_error",
"operation": "tls_handshake_done",
"t": 10.1847777,
"tags": [
"tcptls_experiment"
]
}
]
I think what they are pointing out is the slow rate and low number of bytes transferred.
| time | operation |
|---|---|
| 0.184 s | connect |
| 0.184 s | tls_handshake_start |
| 0.184 s | write 281 bytes |
| 4.796 s | read 517 bytes |
| 4.796 s | read 507 bytes |
| 10.111 s | write 336 bytes |
| 10.185 s | generic_timeout_error |
Ощущение, что у Домру то ли ТСПУ постоянно отваливается, то ли еще что-то, но твиттер у меня без ВПН сегодня работает отлично, вообще проблем не наблюдаю как с ответами по апи так и с загрузкой медиа
У крупных провайдеров ТСПУ установлен не на всех канахал. Провайдерские системы балансировки трафика вполне могут одно время пускать трафик через линки с ТСПУ, а другое — через другие, где он (пока) не установлен.
Вот только что снова отвалилось всё
All subsequent packets are discarded
I remember last year the throttling rate was around 130kbps, can you confirm if the rate limit for this year has been further lowered?
On all my links, twitter/facebook/other TSPU-effected sites are now blocked. Some other people said about throttling, but these days all my ISPs have them blocked.
Just as I’m writing it, I see the throttling of twitter. It’s very slow, very hard policied to a very low speed: in curl it looks like several bytes are transferred in a jiffy, then several seconds no data transfer. Speed is somewhere around 760 bytes per second on average.
Requests for twitter.com on other IP addresses, like my server 31.220.5.43, are not throttled but blocked with “infinite loading”.
Facebook’s fbcdn.net is blocked+throttled: the client instantly receives RSTACKs with increasing seq numbers (to reset traffic which may be transferred “in the future” for DPI standpoint), but if you block these packets, you’ll ocasionnaly receive real packets from the server, which seem to be throttled as hard as Twitter.
http-https-twitter-com-03.03.2022-tspu-my-server.pcapng (9.0 KB)
https-twitter.com-03.03.2022-tspu-throttling.pcapng (390.4 KB)
OONI published very detailed report on blocking / throttling of Twitter and other social media sites.
Twitter just got an onion site: https://twitter3e4tixl4xyajtrzo62zg5vztmjuricljdp2c5kshju4avyoid.onion/
I’m curious, are instance of the alternative front-end Nitter accessible in Russia? I think they only allow you to read, not to post.
Some of these instances have onions as well.
Снова отвалилось…
upd - заработало
В сети Билайн Москва (Корбина), AS8402, наблюдается блокировка части адресов Твиттера.
Заблокированы, как минимум:
104.244.42.1
104.244.42.193
104.244.42.129
104.244.42.65
Пока что доступны следующие (hosts):
104.244.42.3 twitter.com www.twitter.com
104.244.42.66 api.twitter.com
104.244.42.5 t.co
Node: AS3216 Moscow
BGP routing table entry for 104.244.42.129/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 187622866 187622866
Last Modified: Mar 4 23:16:40.840 for 1w1d
Paths: (2 available, best #1, not advertised to EBGP peer)
Not advertised to any peer
Path #1:
Not advertised to any peer
8402
81.211.45.63 (metric 1020) (195.239.255.107)
Origin IGP, metric 0, localpref 150, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 187622856
Community: 3216:667 3216:668 no-export
Originator: 195.239.255.107, Cluster list: 79.104.255.4
Path #2:
Not advertised to any peer
8402
81.211.45.63 (metric 1020) (195.239.255.107)
Origin IGP, metric 0, localpref 150, valid, internal
Received Path ID 0, Local Path ID 0, version 0
Community: 3216:667 3216:668 no-export
Originator: 195.239.255.107, Cluster list: 79.104.255.5
I suppose this is done not by TSPU but by Beeline only?
Yes, seem like so.
Possible BGP hijack
Beginning at 2022-03-28 12:06:26 UTC, we detected a possible BGP hijack.
Prefix 104.244.42.0/24, is normally announced by AS13414 TWITTER, US.
But beginning at 2022-03-28 12:06:26, the same prefix (104.244.42.0/24) was also announced by ASN 8342.
This was detected by 5 BGPMon peers.