Comments 53
Мне данный пост интересен лишь с технической точки зрения (мне посчастливилось не быть гражданином такой страны как у Вас). Спасибо за интересную статью! Однако, в контексте вашего применения — это лечение побочных эфектов и, как мне кажется, решать проблему нужно в другом месте (но это я так, гипотетически).
-17
Ничего. «Успешный» опыт вполне неплохо перенимают.
+9
Я с удовольствием прочитал бы пару критических тезисов относительно моего набирающего популярность комментария (-14 у комментария против всего +10 у самой статьи). Вам нравятся блокировки, которые (как мне опять же кажется) никто из здравомыслящих граждан не заказывал? Так тогда странно, что вы читаете эту статью вовсе. Мне любопытно: кто вы?
+3
«а что говорить, когда и так всё понятно?»
я не минусовал — нечем, но причина по-моему вполне очевидна — наступание на больную мозоль вместе со словами «мне вас так жаль, но у меня-от не болит!» ничем хорошим не оканчивается.
я не минусовал — нечем, но причина по-моему вполне очевидна — наступание на больную мозоль вместе со словами «мне вас так жаль, но у меня-от не болит!» ничем хорошим не оканчивается.
+8
Хмм, я не хотел никому на мозоль наступать (простите, я просто об этом не подумал), как и не хотел злорадствовать (надеюсь хоть это у меня получилось передать), наоборот, я надеюсь увидеть победу здравого смысла (нет, я не надеюсь на политиков уже давно и не только в РФ) в такой-то большой стране!
+1
Не совсем понятен смысл вашего комментария. Для минусующих, наверное, он выглядит так: «вы неудачники, а я на коне, статья интересная, но мне кажется, что она не нужна, потому что вам нужно решать ваши проблемы совсем другим путём». Выглядит, как нравоучения человека со стороны, такие вещи обычно воспринимаются негативно (тем более, что никто ничего нового из вашего комментария не узнал).
+14
Спасибо за помощь в осознании ошибки, которая привела к негативу.
Смысл моего комментария был в том, что мне действительно было интересно прочитать о том, как можно собрать proxy с модификациями пакетов на лету «на коленке», да ещё и все утилиты есть в OpenWrt прошивке роутера.
Ещё раз спасибо, я всё понял и дальше зарываться в политику у меня желания нет.
Смысл моего комментария был в том, что мне действительно было интересно прочитать о том, как можно собрать proxy с модификациями пакетов на лету «на коленке», да ещё и все утилиты есть в OpenWrt прошивке роутера.
Остальной текст был неудачным...
Намёк был на то, что меры будут ужесточаться и, если посмотреть на Китай, эта гонка может закончиться не в пользу граждан. «Когда они пришли...»
Ещё раз спасибо, я всё понял и дальше зарываться в политику у меня желания нет.
+2
умора, вам не повезло быть гражданином еще большего ада
-1
echo -ne "$header1\r\n"Возможно, проблема в stdin буфере netcat'a. Можно бы попробовать отключить буферизацию, но я знаю только одну утилиту для этого —
# ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе — скажу спасибо
stdbuf -i0
, но я сомневаюсь, что она будет в прошивке роутера. 0
Попробуйте поиграть с символами конца строки перед Host вместо разделения пакетов.
0
Нечего там играть, символы конца строки исключительно \r\n и других вариантов в http не предусмотрено. Если и заработает что-то другое, это по недосмотру разработчиков сервера, а не потому, что так можно было.
По поводу разделения пакетов: можно было и вообще отправить первую «G» первым пакетом (1 байт), остальное — вторым. С точки зрения DPI, насколько я понимаю, это то же самое — первый пакет не содержит ничего криминального. Один байт отрезать проще, чем ловить конец строки.
По поводу разделения пакетов: можно было и вообще отправить первую «G» первым пакетом (1 байт), остальное — вторым. С точки зрения DPI, насколько я понимаю, это то же самое — первый пакет не содержит ничего криминального. Один байт отрезать проще, чем ловить конец строки.
+1
G в первом пакете не поможет т.к. DPI реагирует на
Ну по крайней мере у меня так.
У меня прекрасно работает конструкция.
Возможно это наследие древних времён.
HTTP 1.1 Работает в режиме keep-alive(соединение с сервером не прерывается после получения ответа) а это значит что DPI приходится анализировать не только первый пакет но и все последующие т.к. заблокирован может быть не сайт полностью а только одна страница.
" HTTP/1.1\13\10Host: rutracker.og"
Ну по крайней мере у меня так.
У меня прекрасно работает конструкция.
" HTTP/1.1\10Host: rutracker.og"
Возможно это наследие древних времён.
HTTP 1.1 Работает в режиме keep-alive(соединение с сервером не прерывается после получения ответа) а это значит что DPI приходится анализировать не только первый пакет но и все последующие т.к. заблокирован может быть не сайт полностью а только одна страница.
+1
Ну тогда нужен свой DPI, который разделяет на отдельные пакеты имя заголовка «Host» и его содержимое :)
0
Мой DPI смотрит только первый запрос, если он прошел, то остальные в пределах TCP сессии тоже пройдут.
0
Если интересно, я только что добавил в BlockCheck 3 теста на обход DPI: фрагментирование заголовка, точка в конце домена и дополнительный пробел после GET.
+2
Интересно, надо будет заценить утилитку.
0
Попробовал, у меня полный DPI. А не подскажете, где кратко и толково почитать про инициализацию https? Там вроде бы имя хоста не шифруется и ловится провайдером.
0
Лог полный приложите, пожалуйста, а то утилита иногда ошибается.
В HTTPS домен может передаваться (и передается во всех современных браузерах) в заголовке SNI.
albertx.mx/blog/https-handshake
В HTTPS домен может передаваться (и передается во всех современных браузерах) в заголовке SNI.
albertx.mx/blog/https-handshake
0
запустил еще раз, прибив левые маршруты, 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.
0
Проверил сейчас Вашу утилитку от себя — говорит, что полный DPI. Подключился через штатовский VPN, захожу на rule34.yyy — тоже не открывается. Хотелось бы иметь возможность проверяемый URL задавать свой.
0
Странно, сайт прекрасно работает и не падал. Может, у вас что-то с DNS? Сайты вы можете в самом blockcheck.py изменить.
0
Сейчас опять поднял VPN, попробовал зайти на rule34 — зашёл нормально. А в тот раз появлялось сообщение, что мол сайт перегружен запросами бла, бла, бла… Завтра с работы ещё раз попытаю утилитку — дома нет машинки с линуксом на борту.
0
Потестил несколько адресов — всё время пишет, что полный DPI, но тем не менее, помогает фрагментирование заголовка. Эх (мечтательно :), вот бы кто-нибудь написал плагинчик для лисы, фрагментирующий заголовки…
0
Решил попроводить кое-какие эксперименты с помощью телнета. Пытаюсь подключиться, например, на archive.org — не коннектится. Вообще. Похоже, что блокировка выполняется по IP. А Ваша утилитка утверждает, что помогает фрагментирование заголовка. Похоже, она ошибается.
0
Утилита фрагментирует заголовок по 2 символа:
GE
T_
/_
HT
TP
_1
.0
И все в таком духе. А telnet отправляет построчно.
GE
T_
/_
HT
TP
_1
.0
И все в таком духе. А telnet отправляет построчно.
0
Проверил на своем провайдере, не работает.
0
В статье чётко написано, когда это работает: когда у провайдера используется DPI (на маршрутизаторе для транзитных пакетов) и когда этот самый DPI анализирует только первый пакет с данными TCP.
У моего провайдера используется прозрачный прокси для IP запрещённых сайтов, поэтому описанный в статье подход тоже не работает.
У моего провайдера используется прозрачный прокси для IP запрещённых сайтов, поэтому описанный в статье подход тоже не работает.
0
Давно использую такой вариант. С моим провайдером работает, но через раз приходит страница с уведомлением о блокировке. Т.е. DPI все же умеет частично склеивать HTTP-пакеты.
0
Как реализовали?
0
Не автоматизировал, как автор данной статьи. Просто использую программу telnet. Режим передачи — построчный. Вбиваем две строки — с GET и с Host (лучше их набрать в блокноте заранее и скопировать), результат сохраняем. У многих сайтов слишком маленький keep-alive, и через telnet очень трудно успеть отправить запрос вручную :)
0
Идея очевидная, но, боюсь, реализация на shell-скрипте, да еще и на роутере, будет очень малопроизводительна, а потреблять ресурсов относительно много. И, вероятно, сломает обмен не текстовыми данными внутри запроса.
Есть еще вариант для бедных — можно еще и добавлять какой-нибудь огромный ненужный заголовок размером под 2 КБ, чтобы пакет точно фрагментировался. Подобное уже делали — habrahabr.ru/post/249433
Есть еще вариант для бедных — можно еще и добавлять какой-нибудь огромный ненужный заголовок размером под 2 КБ, чтобы пакет точно фрагментировался. Подобное уже делали — habrahabr.ru/post/249433
+2
TP-Link WDR-3500 проседает по процессору не сильно. Бинарный обмен тоже в порядке, так как после первого заголовка в сессии идет прямой форвард потока, а netcat и cat вроде как едят бинарные данные без проблем. Ну и опять же повторю, что это только proof of concept, а не готовое решение. Насчет изменения регистра поля host не подумал, надо проверить. Спасибо за ссылку.
+1
Если же первую строку запроса с путем и строку с полем Host растащить по разным пакетам, то DPI не может корректно обработать такую сессию и пропускает ее.
Я могу ошибаться, но по-моему это решается парой кликов в настройках DPI. В крайнем случае скриптом от вендора.
0
Скрипт несколько неэффективный. Поскольку sdtout функции appendline записывается в переменные, лучше было бы эти результаты передавать через переменные — это уменьшит число системных вызовов, требуемые ресурсы снизятся в 3-4 раза.
0
А можно на примере? А то на ночь глядя туго соображается.
0
Я так понял, что автор хотел сказать, что данные в функцию appendLine у вас передаются через аргументы (
P.S. Я не знаю какие накладные расходы у передачи через аргументы по сравнению с передачей через переменные окружения, я только перефразировал с примерами то, как я понял слова автора.
appendLine "один" "два"
), а он предлагает передавать через переменные окружения (header1="одиин" header2="два" appendLine
), а в вашем случае можно их из глобальных переменных вообще читать, но это не очень красиво будет выглядеть.P.S. Я не знаю какие накладные расходы у передачи через аргументы по сравнению с передачей через переменные окружения, я только перефразировал с примерами то, как я понял слова автора.
0
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 ...
0
# ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе — скажу спасибо
Очень похоже на алгоритм Нейгла.
Возможно, какие-то версии нетката позволяют его отключить, но по-моему проще на Си переписать.
0
UFO just landed and posted this here
Пока ревизоры будут показывать что всё нормально РКН не на чём основывать свои претензии. А дырки эти публиковать надо чтоб не только избранные пользовались своим правами.
0
UFO just landed and posted this here
Ревизоры в данном случае это коробки у провайдеров которые проверяют доступность/недоступность сайтов. Как их запрограммировали так они и будут проверять. Для того что бы были «просвещённые» их нужно «просветить». РКН борется за скрытие информации. Им будет только наруку то что всё будет скрыто в том числе и знание как открыть.
+1
Провайдеру даже выгоднее, если его DPI обойти проще, чем DPI конкурента, это добавит ему пользователей. Главное, чтобы РосКомНадзор видел, что все, что надо, блокировано.
+1
Sign up to leave a comment.
Обход DPI провайдера на роутере с OpenWrt, используя только busybox