Замедление Twitter в России

У меня помимо github-releases.githubusercontent.com судя по всему режется ВЕСЬ *.githubusercontent.com, включая картинки, аватарки и файлы из гистов.

▲ ~ curl -Lo /dev/null -skw "\ntime_connect: %{time_connect}s\ntime_namelookup: %{time_namelookup}s\ntime_pretransfer: %{time_pretransfer}\ntime_starttransfer: %{time_starttransfer}s\ntime_redirect: %{time_redirect}s\ntime_total: %{time_total}s\n\n" https://gist.githubusercontent.com/brettlangdon/85942af486eb79118467/raw/2a7409cd3c26a90b2e82bdc40dc7db18b92b3517/01151_inthedeep_2560x1600.jpg

time_connect: 0.109184s
time_namelookup: 0.017873s
time_pretransfer: 0.295267
time_starttransfer: 0.492951s
time_redirect: 0.000000s
time_total: 58.627166s
time_connect: 0.082141s
time_namelookup: 0.041076s
time_pretransfer: 0.175151
time_starttransfer: 0.448990s
time_redirect: 0.000000s
time_total: 63.107377s

Действительно.
nfqws с --dpi-desync=fake помогает от суверенной блокировки сайтов, но не помогает от шейпинга
зато
nfqws с --dpi-desync=fake,split2 помогает и от того, и от другого

провайдер tiera

Подтверждаю: на моём провайдере zapret и GoodbyeDPI не могут обойти блокировки сайтов, но обходят ограничение скорости.
С определенной долей уверенности это говоорит о наличии разного оборудования DPI на пути пакетов.

На заметку: TTL быстрых и замедленных пакетов одинаков.

Ещё потенциально может быть интересно проверить, что будет если послать тот же SNI на свой сервер (т.е. на сервер не в подсетях Twitter, а других). На сервере можно поднять NAT в сторону твиттера или socat’ом проксю. Если трафик будет троттлиться - можно будет увидеть, что происходит в pcap на другой стороне соединения и, возможно, что-то из этого понять. А если не будет - то Твиттер получает тривиальную конструкцию для убегания всем миром :slight_smile:

Валдик совершенно прав. Блокировка идет по SNI
Прописал в hosts github-releases.githubusercontent.com на IP своего VPS
Создал там файл на 100 mb. Дернул по https через curl -k (игнорировать сертификат)
Медленно. С разбиением запроса через nfqws - быстро

Прикольный артефакт. Запишешь pcap с обоих сторон “хорошей” и “плохой” сессии? Ну не 100 MiB, наверное, поменьше… Хватит ли мегабайта-двух для наблюдения эффекта?

Красноярск, Orion Telecom через магистальщика ertelecom аналогично режет gist.githubusercontent.com

Я провёл больше тестов. Сообщаю вам первым. Сравнение доменов происходит по подстроке, и блокируется строка “t.co” (короткий домен твиттера)

Любой домен, содержащий в каком-либо месте в названии домена строку t.co, замедляется.

У Github домен, на котором видно замедление — http://githubusercontent.com

githubusercontent.com

жесть

Проверил: замедляются rt.com, reddit.com, microsoft.com.

ApplicationFrameHost_LGaAeELjIR
Иконки у предлагаемых приложений в Microsoft Store выглядят примерно вот так, через несколько секунд они подгружаются
Сам Store тоже работает медленнно

упд: шейпер работает, хром сообщает что образ винды скачается через 5 дней

Сделал наглядное сравнение. Ситуация дерьмовая :frowning:

ОС windows 10, последняя версия chrome, провайдер мегафон северозапад, LTE.

С замедлением

Без замедления

googleusercontent.com

wget https://lh3.googleusercontent.com/86arOE_jc_FYR6_mPbeXrzWB4LwvgCRWPGXbbftgG4_zAjY05ajbmq3xiG0Xc_uYCoTccikGvLdo5WIlofH5pmySn1VRejqngh2pwDLquiLJYayCOJKUrZKFnOwmSxKzQqqOM1y5o42TPk6LYR1vbPjrEPx3dQIUEwS4IPRjzt3JdPZT32TkqCECm-PoQtsBAPnyN6g46PbiyD9fblgzuBcT2xuO1AaZgOkR53bom8ATCBkDgcYT_mnsxWuxLGp6cNFUR4lWBFKyYkYJWJY--KmIVCWDDoJ3SxwjimGjwRG-X2Qu3AP4wa6tRazHuBo3a8IOofm6f5arSRdpVy4AaXoacTPz8TSkcofA0YaIttHpek1Gi5v1yMSbi5mHV6Mfv4lyczXPp8c5iNR7IFPvgMz1BiCETTxNwSvDjb2JCN94_256Fzejrs-Dk-kMYeCCYQh2Zd_lt9xiEQDgZ5gufdpxxM9xDiP447vrOqKbBMcAS_6hu43EwRi97ILAhBpS3QLP-4WhKf4GHauWqML_EcBvhszB-6T1iGeCWvpAT9jZVDVgekalBvLZiZNoy5Ow9QlnHA=w1827-h711-no

=> 15 КБ/с

@ValdikSS я уже написал на хабре, напишу и здесь. Проверял на домру и теле2. На первом все ок, но на теле2 режет, причем обходится сменой SNI.
Из интересного: обычные блокировки не обходятся добавлением точки, а обрезка скорости обходится. Плюс, я тут прочитал, что блочатся все сайты с “t.co”. Учитывая все это, мне кажется, что централизовано поставили DPI где-то на границе, ведь обычно провайдерам даются определенные списки доменов, а тут такое ощущение, что тупо grep’ом сделано.

У крупных провайдеров уже стоят ТСПУ (на базе EcoDPI) от РКН.

То, что goodbyedpi/zapret/добавление точки обходит ограничение, но не блокировки, с определенной долей уверенности говорит о наличии разного оборудования DPI на пути пакетов. Т.е. один может быть провайдерский (блокирующий), а другой — Роскомнадзоровский («суверенный», rdp ru), где-то дальше на магистрали. Такое встречается, это не нетипичная ситуация, но всё равно.

История про .*t.co.* вместо ^t.co$ напомнила мне про spec/techniques at master · ooni/spec · GitHub

Возможно, если в техниках поковыряться – можно ещё какие-то интересные гипотезы для проверки найти.

И все же я бы предложил провести тест, чтобы понять, где именно стоят DPI, реализующие новые блокировки. Для этого надо взять какой-нибудь сайт без “t.co”. Потом отправить ему пакет с определенным низким ttl. В sni этого пакета указать “t.co”. Далее необходимо начать нормальный обмен данными с этим сайтом на том же сокете, измеряя при этом скорость. Алгоритм повторять увеличивая значение ttl до тех пор, пока не станет резаться скорость. В этом случае пакет дойдет до фильтра и вся сессия пометиться, что ее надо блокировать.

Можно нагрепать ещё кучу домендов на:

Возможно, там найдётся что-то пожирнее rt.com.