Pull to refresh

Comments 54

В ростелекоме убрали редирект на страницу-заглушку, теперь просто отдает страницу со статусом 451 (Unavailable For Legal Reasons) и данный способ не помогает это обойти.
Видимо ваше отделение оперативней среагировало. Или у них алгоритмы блокировки по проще. У меня пока метод работает.
Этот метод не работает против фильтрующего прокси. Изучаю вопрос.
Ого, а покажите, пожалуйста скриншот, например, ибо у себя попробовал попасть на страницу блокировки, а там всё тоже самое. Прошу поскольку очень уж интересно посмотреть на страницу с 451 ошибкой в реальном рунете.
Какой оригинальный ответ однако от блокировщика ибо приходит с block.ip.center.rt.ru похоже Ростелеком всё таки поставил полноценный DPI.
В хедерах есть Location но переадресация не происходит. Это даже лучше. В данном случае можно просто обновлять страницу. Кстати нажмите «view source» в «Request Headers» и убедитесь что в GET полный адрес (http://...) а не только путь. Если только путь (GET /...) то proxy.pac не сработал.
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>

А каков принцип работы?
«Эшелонированную защиту» не пробивает, когда блокирует провайдер и его аплинк.
DPI пакет не узнаёт и не высылает заглушку. Но работает метод через раз поэтому второй скрипт нужен.
Сильно зависит от паранойи админов провайдера, встречал схему DPI + дополнительно все запросы на 53 порт редиректятся провайдером на свой сервер DNS, какой у себя DNS не укажи все равно будет обрабатывать провайдерский, тогда только VPN спасает до своего сервера.
Кстати, я у себя только dns завернул в vpn, чтобы не весь трафик туда гонять. Дёшево и сердито.
Аналогично, плюс таблица IP которые ходят исключительно через VPN, все что не в таблице идет через провайдера, оптимальное соотношение скорости работы и доступности сайтов.
От перехвата DNS запросов может помочь DNSCrypt, он через 443 порт работает.
www.torproject.org/projects/torbrowser.html — захожу через это на заблокированные сайты, полет нормальный.
Не нашел только как тут включить меня как внутрисетевой узел в сеть, раньше это просто было, мб в курсе кто?
У тора уж очень большие шансы нарваться на человека посередине, даже в топике об этом сказано и рассматривается пример с сайтом без https.
ну если им заходить только на торрент-трекеры/луркоморье и прочие заблокированные, не вижу особо проблемы. он мне не для анонимности нужен
Проблемы, в основном, из-за авторизации возникают, хотя подделки страниц без https тоже однозначно исключить нельзя.
Я дико извиняюсь, но в качестве альтернативной меры использование DNS серверов гугла прям в роутере не практичнее?
Спасибо
От DPI это не поможет. DNS прописаны и гугловские и яндексовские. Блок у меня идёт на уровне TCP пакетов. Каждый провайдер по своему решил проблему блокирования сайтов поэтому решение не универсально.
Нет, у меня провайдер весь трафик переводит на себя, простое прописывание альтернативных DNS от этого не спасет, все равно будут его юзаться.
Фактически, вместо поля Host: имя сервера оказывается в самой строке GET.
Интересно, какие веб-сервера совместимы с этим по умолчанию?
Видимо все. Поскольку если сделать так:
function FindProxyForURL(url, host) {

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

  return "DIRECT";
}


Проблем не наблюдается. Проблема здесь может быть только с сайтами которые используют альтернативный порт для http вместо стандартного (80).
А если убрать "; DIRECT"? Порт можно, кстати, выпарсить…
Тогда проблема с другим портом будет гарантированно. Так хоть если не соедениться с 80тым попробует напрямую.
Я также исследовал модификацию хедеров для прохода DPI как и в этой статье. Написал простенький тестер прохода на Lua. Пытался писать свой локальный прокси но он коряво работает. И собственно таки пришёл к идее как прокси использовать сам сервер.

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

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

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

К сожалению все варианты с модификацией заголовка и отбрасыванием пакетов не работают при фильтрующем прокси. Если прокси не понимает заголовка то и сервер не поймет. Этот вопрос я поставил в очередь на исследование. Очень хочется как можно дольше не отдавать трафик в чужие руки.
Что только не придумают, лишь бы ipv6 не настраивать.
Ну ipv6 на сервере недавно только подняли. И если использовать 6to4 гейт 192.88.99.1 то у него приоритет ниже ipv4. Это наверно можно исправить прописав в proxy.pac как прокси ipv6 адрес узла.
6to4 не нужно использовать, он объявлен устаревшим в мае 2015.
Надеюсь он всё ещё работает поскольку другого способа получения халявного ipv6 я не знаю.
Его работоспособность зависит от anycast-сервера, ближайшего к вам. Обычно работает, да. Но и других способов хватает.
Туннельные брокеры (6in4, иначе говоря), AYIYA, умирающий Teredo (только не с серверами Microsoft).
Вы перепутали с teredo
Попробуйте тогда найти этому подтверждение. Я бегло погуглил и вику посмотрел и ничего не нашел. Про отмену тередо везде находится начиная с его rfc.
Подтверждение чему? Я же привел ссылку на RFC.
Извиняюсь, на телефоне не заметил что это ссылка была. Сейчас ознакомлюсь.
Расскажите пожалуйста вкратце почему они решили отказаться и какую альтернативу предложили.
Много ошибок, глубоко скрытых от пользователя, в результате которых пользователи отключали ipv6, считая его не надежным. В рамках этого rfc никакой альтернативы, кроме того что вернуться к изначальному rfc на 6to4 без этого эникастового релея, а в последствии подумать.
Это то что я вычитал на своем битом английском, надо бы перечитать и перепроверить.
Строго говоря RFC 7526 объявляет устаревшим только позднюю присадку к 6to4 в виде эникаста 192.88.99.1 т.е вроде бы не сам 6to4. Хотя там много всего что отговаривает от его использования. В любом случае перед продолжением его использования надо будет внимательно перечитать этот rfc и пачку связанных. Спасибо за ссылку.
Удивительно — ни одной статьи на хабре по теме.
Включил 6to4 туннель на роутере. Задал ipv6 в proxy.pac дабы приоритет не играл роли.

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

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

FireFox и Chrome пошли на сайт через ipv6 без проблем. Фильтрующий прокси трафик не порезал.
В винде приоритет (prefixpolicies) выставляется в netsh довольно удобно. У меня выставлен в приоритет разных видов ipv6 над ipv4 и только для кривых сайтов специально выставлен ipv4. Это сайты районной локалки, которые работали в ipv6 когда местный провайдер игрался с новым протоколом и перестали работать когда пров забыл что этот протокол у него есть.
Хмм. Только сейчас заметил что у меня ничего кроме него через 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.
Мне говорили, что некоторые ISP по IPv6 тоже блокируют ресурсы, так что только vpn и т.п, но мне без надобности запоминать местечковых ISP другой страны, так что без пруфов.
Метод Chrome-only, в Firefox установка proxy.pac ничего не даёт, постоянно всплывает всё та же заглушка.
Думаю, вводить нужно путь с URI, т.е. file://, а не просто путь. Честно говоря, не знал, что в Chrome можно без file:// вводить.
Пробовал и так, всё равно не работает. А в Chrome без проблем.
А если загрузить куда-то, или просто веб-сервер поднять, ссылка с http работает? Может, где-то синтаксическая или иная ошибка?
Chrome в Windows использует настройки сети в IE и собственно их и открывает. Видимо IE понимает и такой путь а хром получает файл. FireFox в своих настройках автоматом меняет на file://
У меня работает и в Firefox. Заглушка проскакивает иногда и в Chrome но второй скрипт её тут же её закрывает. Я специально не стал распыляться на все браузеры сосредоточившись на Chrome.

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

Также посмотрите на заголовки в FireBug в исходном виде. Там должен быть полный адрес в GET. Если в GET только путь («GET /… HTTP/1.1») то proxy.pac не сработал.
Получилось запустить. Если в Firefox выбрать пункт «использовать системные настройки прокси», а в системе прописать этот proxy.pac, он подхватывается. А напрямую, через предназначенное для него поле — ни в какую. Перепробовал разные варианты, даже слеш в обратную сторону разворачивал, всё равно не подхватывается.
Ну ладно, главное работает…
Можно избавиться от первого этапа ручной установки pac-скрипта и применить настройки прокси из самого расширения, дав ему соответствующие права в manifest-файле:
 {
    ...
    "permissions": [
        "proxy"
    ],
}

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

Спасибо за интересный материал.
Only those users with full accounts are able to leave comments. Log in, please.

Articles