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 + дополнительно все запросы на 53 порт редиректятся провайдером на свой сервер DNS, какой у себя DNS не укажи все равно будет обрабатывать провайдерский, тогда только VPN спасает до своего сервера.
Кстати, я у себя только dns завернул в vpn, чтобы не весь трафик туда гонять. Дёшево и сердито.
От перехвата DNS запросов может помочь DNSCrypt, он через 443 порт работает.
www.torproject.org/projects/torbrowser.html — захожу через это на заблокированные сайты, полет нормальный.
Не нашел только как тут включить меня как внутрисетевой узел в сеть, раньше это просто было, мб в курсе кто?
Не нашел только как тут включить меня как внутрисетевой узел в сеть, раньше это просто было, мб в курсе кто?
Я дико извиняюсь, но в качестве альтернативной меры использование DNS серверов гугла прям в роутере не практичнее?
Спасибо
Спасибо
От DPI это не поможет. DNS прописаны и гугловские и яндексовские. Блок у меня идёт на уровне TCP пакетов. Каждый провайдер по своему решил проблему блокирования сайтов поэтому решение не универсально.
Нет, у меня провайдер весь трафик переводит на себя, простое прописывание альтернативных DNS от этого не спасет, все равно будут его юзаться.
Фактически, вместо поля Host: имя сервера оказывается в самой строке GET.
Интересно, какие веб-сервера совместимы с этим по умолчанию?
Интересно, какие веб-сервера совместимы с этим по умолчанию?
Видимо все. Поскольку если сделать так:
Проблем не наблюдается. Проблема здесь может быть только с сайтами которые используют альтернативный порт для http вместо стандартного (80).
function FindProxyForURL(url, host) {
if (shExpMatch(url, "http://*")) {
return "PROXY "+host+"; DIRECT";
}
return "DIRECT";
}
Проблем не наблюдается. Проблема здесь может быть только с сайтами которые используют альтернативный порт для http вместо стандартного (80).
Есть и более практичные способы, которые, правда, требуют устройства под управлением Linux (роутер, например):
Для ДОМ.ру и Интерзет
Для Ростелекома способ 1 (тот, что ниже, от меня) и способ 2.
Ну и на основе proxy.pac, но с прокси.
Для ДОМ.ру и Интерзет
Для Ростелекома способ 1 (тот, что ниже, от меня) и способ 2.
Ну и на основе proxy.pac, но с прокси.
Я также исследовал модификацию хедеров для прохода DPI как и в этой статье. Написал простенький тестер прохода на Lua. Пытался писать свой локальный прокси но он коряво работает. И собственно таки пришёл к идее как прокси использовать сам сервер.
Второй способ вообще должен быть идеален для данного типа блокировки если есть iptables. Я о нём также думал смотря в WireShark. Но в windows iptables нет. Не знаю есть ли у меня доступ к этому на роутере.
Я на кстати на основе этого proxy.pac (скачав и изменив) себе сделал свой для всех заблокированных сайтов.
Если прикроют мой способ будем пробовать вариант с 3proxy если антивирус на него ругаться не будет.
К сожалению все варианты с модификацией заголовка и отбрасыванием пакетов не работают при фильтрующем прокси. Если прокси не понимает заголовка то и сервер не поймет. Этот вопрос я поставил в очередь на исследование. Очень хочется как можно дольше не отдавать трафик в чужие руки.
Второй способ вообще должен быть идеален для данного типа блокировки если есть iptables. Я о нём также думал смотря в WireShark. Но в windows iptables нет. Не знаю есть ли у меня доступ к этому на роутере.
Я на кстати на основе этого proxy.pac (скачав и изменив) себе сделал свой для всех заблокированных сайтов.
Если прикроют мой способ будем пробовать вариант с 3proxy если антивирус на него ругаться не будет.
К сожалению все варианты с модификацией заголовка и отбрасыванием пакетов не работают при фильтрующем прокси. Если прокси не понимает заголовка то и сервер не поймет. Этот вопрос я поставил в очередь на исследование. Очень хочется как можно дольше не отдавать трафик в чужие руки.
Что только не придумают, лишь бы ipv6 не настраивать.
Ну ipv6 на сервере недавно только подняли. И если использовать 6to4 гейт 192.88.99.1 то у него приоритет ниже ipv4. Это наверно можно исправить прописав в proxy.pac как прокси ipv6 адрес узла.
6to4 не нужно использовать, он объявлен устаревшим в мае 2015.
Надеюсь он всё ещё работает поскольку другого способа получения халявного ipv6 я не знаю.
Вы перепутали с teredo
Попробуйте тогда найти этому подтверждение. Я бегло погуглил и вику посмотрел и ничего не нашел. Про отмену тередо везде находится начиная с его 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 (Адреса изменены)
FireFox и Chrome пошли на сайт через ipv6 без проблем. Фильтрующий прокси трафик не порезал.
Chrome спокойно погнал трафик по ipv6.
FireFox начал флудить коннектами на ipv4 адрес.
Вернул в porxy.pac как было (домен).
Прописал в hosts (Адреса изменены)
2001:db8:: rutracker.og
FireFox и Chrome пошли на сайт через ipv6 без проблем. Фильтрующий прокси трафик не порезал.
В винде приоритет (prefixpolicies) выставляется в netsh довольно удобно. У меня выставлен в приоритет разных видов ipv6 над ipv4 и только для кривых сайтов специально выставлен ipv4. Это сайты районной локалки, которые работали в ipv6 когда местный провайдер игрался с новым протоколом и перестали работать когда пров забыл что этот протокол у него есть.
Хмм. Только сейчас заметил что у меня ничего кроме него через 6to4 не работает. Все тесты ipv6 не проходит.
Пинги из инета ко мне приходят. Видимо проблема именно на моём узле 6to4.
Трассировка маршрута к 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:// вводить.
У меня работает и в Firefox. Заглушка проскакивает иногда и в Chrome но второй скрипт её тут же её закрывает. Я специально не стал распыляться на все браузеры сосредоточившись на Chrome.
В Firefox для второго скрипта нужно поставить GreaseMonkey и скормить ему «back.user.js». Либо поставить RequestPolicy который запретит переадресацию и можно будет просто нажать кнопку попробовать снова.
Также посмотрите на заголовки в FireBug в исходном виде. Там должен быть полный адрес в GET. Если в GET только путь («GET /… HTTP/1.1») то proxy.pac не сработал.
В Firefox для второго скрипта нужно поставить GreaseMonkey и скормить ему «back.user.js». Либо поставить RequestPolicy который запретит переадресацию и можно будет просто нажать кнопку попробовать снова.
Также посмотрите на заголовки в FireBug в исходном виде. Там должен быть полный адрес в GET. Если в GET только путь («GET /… HTTP/1.1») то proxy.pac не сработал.
Получилось запустить. Если в Firefox выбрать пункт «использовать системные настройки прокси», а в системе прописать этот proxy.pac, он подхватывается. А напрямую, через предназначенное для него поле — ни в какую. Перепробовал разные варианты, даже слеш в обратную сторону разворачивал, всё равно не подхватывается.
Ну ладно, главное работает…
Ну ладно, главное работает…
Можно избавиться от первого этапа ручной установки pac-скрипта и применить настройки прокси из самого расширения, дав ему соответствующие права в manifest-файле:
Далее использовать объект «chrome.proxy» в режиме «pac_script» с указанием соответствующего «PacScript».
Подробнее в документации:
https://developer.chrome.com/extensions/proxy
Спасибо за интересный материал.
{
...
"permissions": [
"proxy"
],
}
Далее использовать объект «chrome.proxy» в режиме «pac_script» с указанием соответствующего «PacScript».
Подробнее в документации:
https://developer.chrome.com/extensions/proxy
Спасибо за интересный материал.
Sign up to leave a comment.
Дурим DPI двумя скриптами