Pull to refresh

Comments 53

Мне данный пост интересен лишь с технической точки зрения (мне посчастливилось не быть гражданином такой страны как у Вас). Спасибо за интересную статью! Однако, в контексте вашего применения — это лечение побочных эфектов и, как мне кажется, решать проблему нужно в другом месте (но это я так, гипотетически).
Я с удовольствием прочитал бы пару критических тезисов относительно моего набирающего популярность комментария (-14 у комментария против всего +10 у самой статьи). Вам нравятся блокировки, которые (как мне опять же кажется) никто из здравомыслящих граждан не заказывал? Так тогда странно, что вы читаете эту статью вовсе. Мне любопытно: кто вы?
«а что говорить, когда и так всё понятно?»

я не минусовал — нечем, но причина по-моему вполне очевидна — наступание на больную мозоль вместе со словами «мне вас так жаль, но у меня-от не болит!» ничем хорошим не оканчивается.
Хмм, я не хотел никому на мозоль наступать (простите, я просто об этом не подумал), как и не хотел злорадствовать (надеюсь хоть это у меня получилось передать), наоборот, я надеюсь увидеть победу здравого смысла (нет, я не надеюсь на политиков уже давно и не только в РФ) в такой-то большой стране!
Не совсем понятен смысл вашего комментария. Для минусующих, наверное, он выглядит так: «вы неудачники, а я на коне, статья интересная, но мне кажется, что она не нужна, потому что вам нужно решать ваши проблемы совсем другим путём». Выглядит, как нравоучения человека со стороны, такие вещи обычно воспринимаются негативно (тем более, что никто ничего нового из вашего комментария не узнал).
Спасибо за помощь в осознании ошибки, которая привела к негативу.

Смысл моего комментария был в том, что мне действительно было интересно прочитать о том, как можно собрать proxy с модификациями пакетов на лету «на коленке», да ещё и все утилиты есть в OpenWrt прошивке роутера.

Остальной текст был неудачным...
Намёк был на то, что меры будут ужесточаться и, если посмотреть на Китай, эта гонка может закончиться не в пользу граждан. «Когда они пришли...»

Ещё раз спасибо, я всё понял и дальше зарываться в политику у меня желания нет.
Поддержу. Все эти обходы блокировок напоминают попытки прятать голову в песок. И в один прекрасный момент можно обнаружить вместо песка бетон.

А статья интересная.
умора, вам не повезло быть гражданином еще большего ада
echo -ne "$header1\r\n"
# ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе — скажу спасибо
Возможно, проблема в stdin буфере netcat'a. Можно бы попробовать отключить буферизацию, но я знаю только одну утилиту для этого — stdbuf -i0, но я сомневаюсь, что она будет в прошивке роутера.
Нечего там играть, символы конца строки исключительно \r\n и других вариантов в http не предусмотрено. Если и заработает что-то другое, это по недосмотру разработчиков сервера, а не потому, что так можно было.

По поводу разделения пакетов: можно было и вообще отправить первую «G» первым пакетом (1 байт), остальное — вторым. С точки зрения DPI, насколько я понимаю, это то же самое — первый пакет не содержит ничего криминального. Один байт отрезать проще, чем ловить конец строки.
G в первом пакете не поможет т.к. DPI реагирует на
" HTTP/1.1\13\10Host: rutracker.og"


Ну по крайней мере у меня так.

У меня прекрасно работает конструкция.
" HTTP/1.1\10Host: rutracker.og"


Возможно это наследие древних времён.

HTTP 1.1 Работает в режиме keep-alive(соединение с сервером не прерывается после получения ответа) а это значит что DPI приходится анализировать не только первый пакет но и все последующие т.к. заблокирован может быть не сайт полностью а только одна страница.
Ну тогда нужен свой DPI, который разделяет на отдельные пакеты имя заголовка «Host» и его содержимое :)
Мой DPI смотрит только первый запрос, если он прошел, то остальные в пределах TCP сессии тоже пройдут.
Если интересно, я только что добавил в BlockCheck 3 теста на обход DPI: фрагментирование заголовка, точка в конце домена и дополнительный пробел после GET.
Интересно, надо будет заценить утилитку.
Попробовал, у меня полный DPI. А не подскажете, где кратко и толково почитать про инициализацию https? Там вроде бы имя хоста не шифруется и ловится провайдером.
Лог полный приложите, пожалуйста, а то утилита иногда ошибается.
В HTTPS домен может передаваться (и передается во всех современных браузерах) в заголовке SNI.
albertx.mx/blog/https-handshake
запустил еще раз, прибив левые маршруты, DPI стал обычным

Лог
[O] Тестируем DNS                                                                                                                                                                                              
[O] Получаем эталонные DNS с сервера                                                                                                                                                                           
        Эталонные адреса:                ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']                                                                                  
        Адреса через системный DNS:      ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']                                                                                  
        Адреса через Google DNS:         ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']                                                                                  
        Адреса через DNS AntiZapret:     ['107.150.11.192', '107.150.11.192', '107.150.11.192', '107.150.11.192']                                                                                              
[✓] DNS-записи не подменяются                                                                                                                                                                                  
[✓] DNS не перенаправляется                                                                                                                                                                                    
                                                                                                                                                                                                               
[O] Тестируем HTTP                                                                                                                                                                                             
        Открываем  http://gelbooru.com/index.php?page=post&s=view&id=1989610                                                                                                                                   
[] Сайт не открывается                                                                                                                                                                                        
        Открываем  http://rule34.xxx/index.php?page=post&s=list&tags=loli                                                                                                                                      
[] Сайт не открывается                                                                                                                                                                                        
        Открываем  http://gelbooru.com/                                                                                                                                                                        
[✓] Сайт открывается                                                                                                                                                                                           
        Открываем  http://rule34.xxx/
[✓] Сайт открывается
        Открываем через прокси  http://gelbooru.com/index.php?page=post&s=view&id=1989610
[✓] Сайт открывается
        Открываем через прокси  http://rule34.xxx/index.php?page=post&s=list&tags=loli
[✓] Сайт открывается
        Открываем через прокси  http://gelbooru.com/
[✓] Сайт открывается
        Открываем через прокси  http://rule34.xxx/
[✓] Сайт открывается

[O] Тестируем HTTPS
        Открываем  https://2chru.cafe/
[] Сайт не открывается
        Открываем  https://e621.net/
[] Сайт не открывается

[O] Тестируем обход DPI
        Пробуем способ: точка в конце домена
[✓] Сайт открывается
        Пробуем способ: дополнительный пробел после GET
[✓] Сайт открывается
        Пробуем способ: фрагментирование заголовка
[✓] Сайт открывается

[!] Результат:
[] Ваш провайдер блокирует доступ к HTTPS-сайтам.
[] У вашего провайдера "обычный" DPI.
 Вам поможет HTTPS/Socks прокси, VPN или Tor.
Проверил сейчас Вашу утилитку от себя — говорит, что полный DPI. Подключился через штатовский VPN, захожу на rule34.yyy — тоже не открывается. Хотелось бы иметь возможность проверяемый URL задавать свой.
Странно, сайт прекрасно работает и не падал. Может, у вас что-то с DNS? Сайты вы можете в самом blockcheck.py изменить.
Сейчас опять поднял VPN, попробовал зайти на rule34 — зашёл нормально. А в тот раз появлялось сообщение, что мол сайт перегружен запросами бла, бла, бла… Завтра с работы ещё раз попытаю утилитку — дома нет машинки с линуксом на борту.
Оно и под Windows работает, в releases есть собранные в exe версии.
Потестил несколько адресов — всё время пишет, что полный DPI, но тем не менее, помогает фрагментирование заголовка. Эх (мечтательно :), вот бы кто-нибудь написал плагинчик для лисы, фрагментирующий заголовки…
Решил попроводить кое-какие эксперименты с помощью телнета. Пытаюсь подключиться, например, на archive.org — не коннектится. Вообще. Похоже, что блокировка выполняется по IP. А Ваша утилитка утверждает, что помогает фрагментирование заголовка. Похоже, она ошибается.
Утилита фрагментирует заголовок по 2 символа:
GE
T_
/_
HT
TP
_1
.0

И все в таком духе. А telnet отправляет построчно.
Но Вашей утилите же надо как-то сначала подключиться к серверу, прежде чем начать слать фрагменты этого заголовка? Телнет, значит, не может соединиться, а утилита — смогла? Каким, интересно, способом?
По IP подключается, на gelbooru.
Ааа. Ну понятно. У меня gelbooru и так открывается — не заблокирован совсем.
Проверил на своем провайдере, не работает.
В статье чётко написано, когда это работает: когда у провайдера используется DPI (на маршрутизаторе для транзитных пакетов) и когда этот самый DPI анализирует только первый пакет с данными TCP.

У моего провайдера используется прозрачный прокси для IP запрещённых сайтов, поэтому описанный в статье подход тоже не работает.
Давно использую такой вариант. С моим провайдером работает, но через раз приходит страница с уведомлением о блокировке. Т.е. DPI все же умеет частично склеивать HTTP-пакеты.
Не автоматизировал, как автор данной статьи. Просто использую программу telnet. Режим передачи — построчный. Вбиваем две строки — с GET и с Host (лучше их набрать в блокноте заранее и скопировать), результат сохраняем. У многих сайтов слишком маленький keep-alive, и через telnet очень трудно успеть отправить запрос вручную :)
Идея очевидная, но, боюсь, реализация на shell-скрипте, да еще и на роутере, будет очень малопроизводительна, а потреблять ресурсов относительно много. И, вероятно, сломает обмен не текстовыми данными внутри запроса.
Есть еще вариант для бедных — можно еще и добавлять какой-нибудь огромный ненужный заголовок размером под 2 КБ, чтобы пакет точно фрагментировался. Подобное уже делали — habrahabr.ru/post/249433
TP-Link WDR-3500 проседает по процессору не сильно. Бинарный обмен тоже в порядке, так как после первого заголовка в сессии идет прямой форвард потока, а netcat и cat вроде как едят бинарные данные без проблем. Ну и опять же повторю, что это только proof of concept, а не готовое решение. Насчет изменения регистра поля host не подумал, надо проверить. Спасибо за ссылку.
Проверил регистр хоста и добавление пробелов, не сработало, сессию дропнули.
Если же первую строку запроса с путем и строку с полем Host растащить по разным пакетам, то DPI не может корректно обработать такую сессию и пропускает ее.


Я могу ошибаться, но по-моему это решается парой кликов в настройках DPI. В крайнем случае скриптом от вендора.
Зависит от DPI. Насколько я понимаю, данный конкретный DPI не собирает TCP поток, а тупо смотрит первый пакет с данными, поэтому способ и прокатывает. Если DPI по своей природе не умеет собирать TCP поток, то парой кликов это не решить.
Скрипт несколько неэффективный. Поскольку sdtout функции appendline записывается в переменные, лучше было бы эти результаты передавать через переменные — это уменьшит число системных вызовов, требуемые ресурсы снизятся в 3-4 раза.
А можно на примере? А то на ночь глядя туго соображается.
Я так понял, что автор хотел сказать, что данные в функцию appendLine у вас передаются через аргументы (appendLine "один" "два"), а он предлагает передавать через переменные окружения (header1="одиин" header2="два" appendLine), а в вашем случае можно их из глобальных переменных вообще читать, но это не очень красиво будет выглядеть.

P.S. Я не знаю какие накладные расходы у передачи через аргументы по сравнению с передачей через переменные окружения, я только перефразировал с примерами то, как я понял слова автора.
appendLine() 
{
    if [[ ! -z "$1" ]]
    then
        NEWLINE="$1
$2"
    else
        NEWLINE="$2"
    fi
}

...

#     header2=`appendLine "$header2" "$line"`
       appendLine "$header2" "$line"
       header2="$NEWLINE"
...


На практике для HTTP в большинстве случаев достаточно завершать строки запрос \n, \r\n необязателен. Опять же, если хочется, можно tr \n \r\n поставить в пайп к последнему в скрипте echo

Ещё оптимизация: вместо
        if [[ `echo "$line" | grep -c "Host:"` -eq "1" ]]
        then
            host=`echo "$line" | sed -re 's/^Host: (.*)\r?$/\1/'`

Можно сделать один внешний вызов приблизительно так:
  host=`echo "$line" | sed -nre '/^Host:/s/^Host: (.*)\r?$/\1/p'`
  if [[ -n $host ]]; then ...


# ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе — скажу спасибо

Очень похоже на алгоритм Нейгла.

Возможно, какие-то версии нетката позволяют его отключить, но по-моему проще на Си переписать.
UFO just landed and posted this here
Пока ревизоры будут показывать что всё нормально РКН не на чём основывать свои претензии. А дырки эти публиковать надо чтоб не только избранные пользовались своим правами.
UFO just landed and posted this here
Ревизоры в данном случае это коробки у провайдеров которые проверяют доступность/недоступность сайтов. Как их запрограммировали так они и будут проверять. Для того что бы были «просвещённые» их нужно «просветить». РКН борется за скрытие информации. Им будет только наруку то что всё будет скрыто в том числе и знание как открыть.
А можно про коробки по-подробнее (если это не домысел, а реальное знание)?
Провайдеру даже выгоднее, если его DPI обойти проще, чем DPI конкурента, это добавит ему пользователей. Главное, чтобы РосКомНадзор видел, что все, что надо, блокировано.
Sign up to leave a comment.

Articles