Действительно.
nfqws с --dpi-desync=fake помогает от суверенной блокировки сайтов, но не помогает от шейпинга
зато
nfqws с --dpi-desync=fake,split2 помогает и от того, и от другого
Подтверждаю: на моём провайдере zapret и GoodbyeDPI не могут обойти блокировки сайтов, но обходят ограничение скорости.
С определенной долей уверенности это говоорит о наличии разного оборудования DPI на пути пакетов.
На заметку: TTL быстрых и замедленных пакетов одинаков.
Ещё потенциально может быть интересно проверить, что будет если послать тот же SNI на свой сервер (т.е. на сервер не в подсетях Twitter, а других). На сервере можно поднять NAT в сторону твиттера или socat’ом проксю. Если трафик будет троттлиться - можно будет увидеть, что происходит в pcap на другой стороне соединения и, возможно, что-то из этого понять. А если не будет - то Твиттер получает тривиальную конструкцию для убегания всем миром
Валдик совершенно прав. Блокировка идет по SNI
Прописал в hosts github-releases.githubusercontent.com на IP своего VPS
Создал там файл на 100 mb. Дернул по https через curl -k (игнорировать сертификат)
Медленно. С разбиением запроса через nfqws - быстро
Прикольный артефакт. Запишешь pcap с обоих сторон “хорошей” и “плохой” сессии? Ну не 100 MiB, наверное, поменьше… Хватит ли мегабайта-двух для наблюдения эффекта?
Иконки у предлагаемых приложений в Microsoft Store выглядят примерно вот так, через несколько секунд они подгружаются
Сам Store тоже работает медленнно
упд: шейпер работает, хром сообщает что образ винды скачается через 5 дней
@ValdikSS я уже написал на хабре, напишу и здесь. Проверял на домру и теле2. На первом все ок, но на теле2 режет, причем обходится сменой SNI.
Из интересного: обычные блокировки не обходятся добавлением точки, а обрезка скорости обходится. Плюс, я тут прочитал, что блочатся все сайты с “t.co”. Учитывая все это, мне кажется, что централизовано поставили DPI где-то на границе, ведь обычно провайдерам даются определенные списки доменов, а тут такое ощущение, что тупо grep’ом сделано.
То, что goodbyedpi/zapret/добавление точки обходит ограничение, но не блокировки, с определенной долей уверенности говорит о наличии разного оборудования DPI на пути пакетов. Т.е. один может быть провайдерский (блокирующий), а другой — Роскомнадзоровский («суверенный», rdp ru), где-то дальше на магистрали. Такое встречается, это не нетипичная ситуация, но всё равно.
И все же я бы предложил провести тест, чтобы понять, где именно стоят DPI, реализующие новые блокировки. Для этого надо взять какой-нибудь сайт без “t.co”. Потом отправить ему пакет с определенным низким ttl. В sni этого пакета указать “t.co”. Далее необходимо начать нормальный обмен данными с этим сайтом на том же сокете, измеряя при этом скорость. Алгоритм повторять увеличивая значение ttl до тех пор, пока не станет резаться скорость. В этом случае пакет дойдет до фильтра и вся сессия пометиться, что ее надо блокировать.