ivan386 29 янв 2016 в 06:28

Дурим DPI двумя скриптами

3 мин

55K

JavaScript *

+25

Комментарии 54

d1Mm 29 янв 2016 в 07:30

В ростелекоме убрали редирект на страницу-заглушку, теперь просто отдает страницу со статусом 451 (Unavailable For Legal Reasons) и данный способ не помогает это обойти.

ivan386 29 янв 2016 в 07:47

Видимо ваше отделение оперативней среагировало. Или у них алгоритмы блокировки по проще. У меня пока метод работает.

ivan386 29 янв 2016 в 09:02

Этот метод не работает против фильтрующего прокси. Изучаю вопрос.

ElleSolomina 29 янв 2016 в 12:09

Ого, а покажите, пожалуйста скриншот, например, ибо у себя попробовал попасть на страницу блокировки, а там всё тоже самое. Прошу поскольку очень уж интересно посмотреть на страницу с 451 ошибкой в реальном рунете.

d1Mm 29 янв 2016 в 14:20

скриншот

ElleSolomina 29 янв 2016 в 21:56

Какой оригинальный ответ однако от блокировщика ибо приходит с block.ip.center.rt.ru похоже Ростелеком всё таки поставил полноценный DPI.

ivan386 30 янв 2016 в 00:28

В хедерах есть Location но переадресация не происходит. Это даже лучше. В данном случае можно просто обновлять страницу. Кстати нажмите «view source» в «Request Headers» и убедитесь что в GET полный адрес (http://...) а не только путь. Если только путь (GET /...) то proxy.pac не сработал.

ElleSolomina 29 янв 2016 в 12:38

P.S. у меня просто вот такая «заглушка», как раз с кодом 451 по умолчанию выдаётся «моим пользователям»

451.html

<!DOCTYPE html><meta charset="utf-8"/><html><head><title>Государственная цензура</title></head><body><center><br><br><h2>Вас пытались перенаправить с заблокированного в РФ ресурса на страницу заглушку</h2><br><h3>Пожалуйста, сообщите, сами знаете кому, о том, что испытали проблемы с доступом, я всё исправлю.<br><br>В случае если меня в данный момент нет дома или же я сплю, пожалуйста, не беспокойте меня, вы можете самостоятельно восстановить доступ, воспользовавшись одним из способов описанным на станице <a href="http://rublacklist.net/bypass">«Восстановление доступа к информации»</a> на сайте организации Роскомсвобода или же на странице <a href="https://meduza.io/cards/kak-oboyti-blokirovki-saytov">«Как обойти блокировки сайтов?»</a> на сайте Медуза.</h3><img src="/image/lit_censorship.png"><center></body></html>

navion 29 янв 2016 в 07:35

А каков принцип работы?
«Эшелонированную защиту» не пробивает, когда блокирует провайдер и его аплинк.

ivan386 29 янв 2016 в 07:43

DPI пакет не узнаёт и не высылает заглушку. Но работает метод через раз поэтому второй скрипт нужен.

RicoX 29 янв 2016 в 09:23

Сильно зависит от паранойи админов провайдера, встречал схему DPI + дополнительно все запросы на 53 порт редиректятся провайдером на свой сервер DNS, какой у себя DNS не укажи все равно будет обрабатывать провайдерский, тогда только VPN спасает до своего сервера.

Nikon_NLG 29 янв 2016 в 09:41

Кстати, я у себя только dns завернул в vpn, чтобы не весь трафик туда гонять. Дёшево и сердито.

RicoX 29 янв 2016 в 09:48

Аналогично, плюс таблица IP которые ходят исключительно через VPN, все что не в таблице идет через провайдера, оптимальное соотношение скорости работы и доступности сайтов.

arabesc 29 янв 2016 в 15:15

От перехвата DNS запросов может помочь DNSCrypt, он через 443 порт работает.

MaximChistov 29 янв 2016 в 09:32

www.torproject.org/projects/torbrowser.html — захожу через это на заблокированные сайты, полет нормальный.
Не нашел только как тут включить меня как внутрисетевой узел в сеть, раньше это просто было, мб в курсе кто?

ElleSolomina 29 янв 2016 в 12:13

У тора уж очень большие шансы нарваться на человека посередине, даже в топике об этом сказано и рассматривается пример с сайтом без https.

MaximChistov 29 янв 2016 в 12:25

ну если им заходить только на торрент-трекеры/луркоморье и прочие заблокированные, не вижу особо проблемы. он мне не для анонимности нужен

ElleSolomina 29 янв 2016 в 12:43

Проблемы, в основном, из-за авторизации возникают, хотя подделки страниц без https тоже однозначно исключить нельзя.

volk0ff 29 янв 2016 в 10:16

Я дико извиняюсь, но в качестве альтернативной меры использование DNS серверов гугла прям в роутере не практичнее?
Спасибо

ivan386 29 янв 2016 в 10:32

От DPI это не поможет. DNS прописаны и гугловские и яндексовские. Блок у меня идёт на уровне TCP пакетов. Каждый провайдер по своему решил проблему блокирования сайтов поэтому решение не универсально.

mukizu 29 янв 2016 в 16:14

Нет, у меня провайдер весь трафик переводит на себя, простое прописывание альтернативных DNS от этого не спасет, все равно будут его юзаться.

skolk 29 янв 2016 в 11:03

Фактически, вместо поля Host: имя сервера оказывается в самой строке GET.
Интересно, какие веб-сервера совместимы с этим по умолчанию?

ivan386 30 янв 2016 в 02:45

Видимо все. Поскольку если сделать так:

function FindProxyForURL(url, host) {

  if (shExpMatch(url, "http://*")) {
    return "PROXY "+host+"; DIRECT";
  }

  return "DIRECT";
}

Проблем не наблюдается. Проблема здесь может быть только с сайтами которые используют альтернативный порт для http вместо стандартного (80).

skolk 30 янв 2016 в 07:32

А если убрать "; DIRECT"? Порт можно, кстати, выпарсить…

ivan386 30 янв 2016 в 14:40

Тогда проблема с другим портом будет гарантированно. Так хоть если не соедениться с 80тым попробует напрямую.

ValdikSS 29 янв 2016 в 13:16

Есть и более практичные способы, которые, правда, требуют устройства под управлением Linux (роутер, например):
Для ДОМ.ру и Интерзет
Для Ростелекома способ 1 (тот, что ниже, от меня) и способ 2.

Ну и на основе proxy.pac, но с прокси.

ivan386 29 янв 2016 в 19:24

Я также исследовал модификацию хедеров для прохода DPI как и в этой статье. Написал простенький тестер прохода на Lua. Пытался писать свой локальный прокси но он коряво работает. И собственно таки пришёл к идее как прокси использовать сам сервер.

Второй способ вообще должен быть идеален для данного типа блокировки если есть iptables. Я о нём также думал смотря в WireShark. Но в windows iptables нет. Не знаю есть ли у меня доступ к этому на роутере.

Я на кстати на основе этого proxy.pac (скачав и изменив) себе сделал свой для всех заблокированных сайтов.

Если прикроют мой способ будем пробовать вариант с 3proxy если антивирус на него ругаться не будет.

К сожалению все варианты с модификацией заголовка и отбрасыванием пакетов не работают при фильтрующем прокси. Если прокси не понимает заголовка то и сервер не поймет. Этот вопрос я поставил в очередь на исследование. Очень хочется как можно дольше не отдавать трафик в чужие руки.

Krey 29 янв 2016 в 14:08

Что только не придумают, лишь бы ipv6 не настраивать.

ivan386 29 янв 2016 в 19:57

Ну ipv6 на сервере недавно только подняли. И если использовать 6to4 гейт 192.88.99.1 то у него приоритет ниже ipv4. Это наверно можно исправить прописав в proxy.pac как прокси ipv6 адрес узла.

ValdikSS 29 янв 2016 в 20:12

6to4 не нужно использовать, он объявлен устаревшим в мае 2015.

ivan386 29 янв 2016 в 20:21

Надеюсь он всё ещё работает поскольку другого способа получения халявного ipv6 я не знаю.

ValdikSS 29 янв 2016 в 20:23

Его работоспособность зависит от anycast-сервера, ближайшего к вам. Обычно работает, да. Но и других способов хватает.

ivan386 29 янв 2016 в 20:27

А какие альтернативы?

ValdikSS 29 янв 2016 в 20:44

Туннельные брокеры (6in4, иначе говоря), AYIYA, умирающий Teredo (только не с серверами Microsoft).

Krey 29 янв 2016 в 23:44

Вы перепутали с teredo

ValdikSS 29 янв 2016 в 23:46

Нет.

Krey 29 янв 2016 в 23:58

Попробуйте тогда найти этому подтверждение. Я бегло погуглил и вику посмотрел и ничего не нашел. Про отмену тередо везде находится начиная с его rfc.

ValdikSS 30 янв 2016 в 00:03

Подтверждение чему? Я же привел ссылку на RFC.

Krey 30 янв 2016 в 00:06

Извиняюсь, на телефоне не заметил что это ссылка была. Сейчас ознакомлюсь.

ivan386 30 янв 2016 в 00:37

Расскажите пожалуйста вкратце почему они решили отказаться и какую альтернативу предложили.

Krey 30 янв 2016 в 01:00

Много ошибок, глубоко скрытых от пользователя, в результате которых пользователи отключали ipv6, считая его не надежным. В рамках этого rfc никакой альтернативы, кроме того что вернуться к изначальному rfc на 6to4 без этого эникастового релея, а в последствии подумать.
Это то что я вычитал на своем битом английском, надо бы перечитать и перепроверить.

Krey 30 янв 2016 в 00:54

Строго говоря RFC 7526 объявляет устаревшим только позднюю присадку к 6to4 в виде эникаста 192.88.99.1 т.е вроде бы не сам 6to4. Хотя там много всего что отговаривает от его использования. В любом случае перед продолжением его использования надо будет внимательно перечитать этот rfc и пачку связанных. Спасибо за ссылку.
Удивительно — ни одной статьи на хабре по теме.

ivan386 29 янв 2016 в 23:17

Включил 6to4 туннель на роутере. Задал ipv6 в proxy.pac дабы приоритет не играл роли.

Chrome спокойно погнал трафик по ipv6.
FireFox начал флудить коннектами на ipv4 адрес.

Вернул в porxy.pac как было (домен).
Прописал в hosts (Адреса изменены)


2001:db8::          rutracker.og

FireFox и Chrome пошли на сайт через ipv6 без проблем. Фильтрующий прокси трафик не порезал.

Krey 29 янв 2016 в 23:51

В винде приоритет (prefixpolicies) выставляется в netsh довольно удобно. У меня выставлен в приоритет разных видов ipv6 над ipv4 и только для кривых сайтов специально выставлен ipv4. Это сайты районной локалки, которые работали в ipv6 когда местный провайдер игрался с новым протоколом и перестали работать когда пров забыл что этот протокол у него есть.

ivan386 15 фев 2016 в 19:39

Хмм. Только сейчас заметил что у меня ничего кроме него через 6to4 не работает. Все тесты ipv6 не проходит.

Трассировка маршрута к 192.88.99.1 с максимальным числом прыжков 30
...
  8     2 ms     2 ms     1 ms  81-27-241-140.rascom.as20764.net [81.27.241.140]

  9    12 ms    12 ms    12 ms  80-64-96-29.rascom.as20764.net [80.64.96.29]
 10     *        *        *     Превышен интервал ожидания для запроса.
 11     *        *        *     Превышен интервал ожидания для запроса.
 12     *        *        *     Превышен интервал ожидания для запроса.
 13     *        *        *     Превышен интервал ожидания для запроса.
 14     *        *        *     Превышен интервал ожидания для запроса.
 15     *        *        *     Превышен интервал ожидания для запроса.
 16     *        *        *     Превышен интервал ожидания для запроса.
 17     *        *        *     Превышен интервал ожидания для запроса.
 18     *        *        *     Превышен интервал ожидания для запроса.
 19     *        *        *     Превышен интервал ожидания для запроса.
 20     *        *        *     Превышен интервал ожидания для запроса.
 21     *        *        *     Превышен интервал ожидания для запроса.

Пинги из инета ко мне приходят. Видимо проблема именно на моём узле 6to4.

foxmuldercp 1 фев 2016 в 09:00

Мне говорили, что некоторые ISP по IPv6 тоже блокируют ресурсы, так что только vpn и т.п, но мне без надобности запоминать местечковых ISP другой страны, так что без пруфов.

Alexey2005 29 янв 2016 в 15:13

Метод Chrome-only, в Firefox установка proxy.pac ничего не даёт, постоянно всплывает всё та же заглушка.

ValdikSS 29 янв 2016 в 17:12

Думаю, вводить нужно путь с URI, т.е. file://, а не просто путь. Честно говоря, не знал, что в Chrome можно без file:// вводить.

Alexey2005 29 янв 2016 в 17:21

Пробовал и так, всё равно не работает. А в Chrome без проблем.

ValdikSS 29 янв 2016 в 17:22

А если загрузить куда-то, или просто веб-сервер поднять, ссылка с http работает? Может, где-то синтаксическая или иная ошибка?

ivan386 29 янв 2016 в 20:08

Chrome в Windows использует настройки сети в IE и собственно их и открывает. Видимо IE понимает и такой путь а хром получает файл. FireFox в своих настройках автоматом меняет на file://

ivan386 29 янв 2016 в 19:46

У меня работает и в Firefox. Заглушка проскакивает иногда и в Chrome но второй скрипт её тут же её закрывает. Я специально не стал распыляться на все браузеры сосредоточившись на Chrome.

В Firefox для второго скрипта нужно поставить GreaseMonkey и скормить ему «back.user.js». Либо поставить RequestPolicy который запретит переадресацию и можно будет просто нажать кнопку попробовать снова.

Также посмотрите на заголовки в FireBug в исходном виде. Там должен быть полный адрес в GET. Если в GET только путь («GET /… HTTP/1.1») то proxy.pac не сработал.

Alexey2005 29 янв 2016 в 21:25

Получилось запустить. Если в Firefox выбрать пункт «использовать системные настройки прокси», а в системе прописать этот proxy.pac, он подхватывается. А напрямую, через предназначенное для него поле — ни в какую. Перепробовал разные варианты, даже слеш в обратную сторону разворачивал, всё равно не подхватывается.
Ну ладно, главное работает…

stas404 30 янв 2016 в 20:31

Можно избавиться от первого этапа ручной установки pac-скрипта и применить настройки прокси из самого расширения, дав ему соответствующие права в manifest-файле:

 {
    ...
    "permissions": [
        "proxy"
    ],
}

Далее использовать объект «chrome.proxy» в режиме «pac_script» с указанием соответствующего «PacScript».
Подробнее в документации:
https://developer.chrome.com/extensions/proxy

Спасибо за интересный материал.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий