Обход блокировки провайдера в любое время суток

🔥Мы профессиональная команда, которая на рынке работает уже более 5 лет и специализируемся исключительно на лучших продуктах.

У нас лучший товар, который вы когда-либо пробовали!

______________

✅ ️Наши контакты (Telegram):✅ ️

>>>НАПИСАТЬ ОПЕРАТОРУ В ТЕЛЕГРАМ (ЖМИ СЮДА)<<<

✅ ️ ▲ ✅ ▲ ️✅ ▲ ️✅ ▲ ️✅ ▲ ✅ ️

_______________

ВНИМАНИЕ! ВАЖНО!🔥🔥🔥

В Телеграм переходить только по ССЫЛКЕ что ВЫШЕ, в поиске НАС НЕТ там только фейки !!!

_______________

Обход Блокировки Онлайн

Обход блокировки провайдера в любое время суток

Faq по воздушным винтам

Долгое время я терпел ограничения РосКомНадзора и соответствующие действия провайдеров по различным ограничениям доступа к сайтам - но с определённого момента устал, и начал думать как бы сделать так, чтобы было и удобно, и быстро, и при этом с минимумом заморочек после настройки Хочу оговориться, что цель анонимизации не ставилась. В случае с TOR-ом о скорости можно забыть, в остальных случаях скорость и время отклика также страдают, поскольку необходимо проксировать через удалённый сервер. Поскольку РосКомНадзор у нас действует на всей территории России, получается что весь трафик придётся проксировать через зарубежный сервер, а значит время отклика или 'пинг' будет сильно страдать. Сразу отрезается весь пласт, например, игровых приложений. Списки можно забирать, например, отсюда. Минусы - приходится периодически обновлять эти списки, и какими бы они не были актуальными есть вероятность всё же наткнуться на заблокированный сайт. На самом деле, один из лучших способов для комфортного пользования интернетом без ограничений. Но можно лучше! Использование 'чёрной магии', связанной с особенностями применяемого провайдерами DPI-софта. Я, в общем и целом, про 'дыры' в обработке трафика например, блокирование только на уровне DNS, или пропуск необычно сформированных пакетов , и, в частности, про GoodbyeDPI уважаемого ValdikSS. Самый большой минус - работает далеко не везде. И чем дальше, тем хуже работает. Рост вычислительных мощностей скорее упрощает жизнь провайдерам, чем нам в этом вопросе На самом деле этот способ является подвариантом 'гибридного', но безо всяких списков. При этом он кроссплатформенен, имеет мало зависимостей и при этом бесконечно расширяем. Мне могут сейчас возразить, что современный NGINX поддерживает 'изкаробки' возможность скриптинга на JavaScript njs , и будет прав, но, во-первых, OpenResty гораздо более развитый проект и его API имеет гораздо больше возможностей, а во-вторых, OpenResty использует LuaJit с поддержкой FFI, что позволяет вызывать C-методы напрямую из Lua-мира - и это создаёт такую возможность для расширения, которая njs даже и не снилась. Во всяком случае пока что Конкретно у меня по причине отсутствия кабельного интернета дома сейчас используется 4G-интернет от Мегафона, поэтому описание будет происходить с точки зрения именно Мегафона. Подробнее как именно всё сконфигурировать будет дальше. Здесь только общее описание и логика, которой я следовал при реализации. Пусть будет Но сам по себе nginx не знает что делать с трафиком, что туда приходит. Именно это мы и будем разруливать с помощью Lua. Кхм, я отвлёкся. Эту информацию можно извлечь при помощи getsockopt Правда из коробки обёртки над ним не было, так что пришлось написать простенький C-модуль для nginx. Несмотря на то, что HTTP постепенно умирает, всё же есть ещё сайты, использующие его. Так что обработка HTTP реализована. Да, Мегафон просто напросто отправил Temporary Redirect с Location на свой собственный сайт для отображения этого сообщения. Для этого мы вычитываем первые данные, пришедшие от клиента вплоть до 16 кбайт, но по факту первые пакеты весьма маленькие , перенаправляем их серверу и читаем ответ от него. Если находим в нём этот редирект - это означает сразу две вещи:. Запрос скорее всего не дошёл до сервера, а значит переотправять его повторно - безопасно. Правда, если это неверно, и вы отправляете запросы, что-то меняющие на удалённом сервере, то тут беда Прилетит по итогу два запроса - один - тот на который заблокирован ответ, и второй - спроксированный. И узнать мы это никак не сможем. Если редиректа нету, значит мы просто отправляем этот запрос дальше клиенту и дальше просто проксируем трафик, не вмешиваясь в него. Но есть и хорошие новости. Перед любым HTTP-запросом мы сначала должны выполнить Handshake, а значит первый пакет точно не вызовет выполнение команды на сервере в случае, если нас заблокировали, но исходный пакет таки ушёл на сервер. Сертификат недействительный, потому что выпущен даже не для этого домена, беда-беда Анализируем сам сертификат И что же мы видим? Получается, что для того, чтобы понять, что сайт блокируется, достаточно вычитать полученный от сервера сертификат, и если мы запрашиваем что угодно кроме megafon. Осталось только понять, как понять, куда именно мы изначально обращались, и как получить этот сертификат. И здесь нам поможет SNI - дело в том, что современный, мы не говорим про эпоху IE6, она ушла и слава богу клиент отправляет домен, к которому обращается, в составе незашифрованных данных ClientHello. Ну а Lua-биндинги позволяют получить эту информацию и для наших целей Итак, что мы делаем? Процедура во многом аналогична HTTP - мы отправляем первый пакет от клиента серверу который как раз содержит ClientHello и ждём от сервера ответа с сертификатом. После чего убеждаемся что SNI не megafon. Во-первых, в TLSv1. Вторая особенность в том, что сертификат сервер клиенту теперь тоже отправляет в зашифрованном виде Проблема усугубляется ещё и тем, что Мегафон отправляет свой сертификат как раз таки по TLSv1. А все основные браузеры сейчас его поддерживают. В нём реализовано аж ДВА механизма по предотвращению подобных даунгрейдов, поэтому вариант плохой. И здесь приходится прибегать к экстренным мерам. На самом деле этот метод я реализовал даже первым, и он по сути и является сутью метода peek and splice у Squid-а. Мы не можем просто взять и вычитать сертификат. Поэтому мы просто открываем свой собственный коннект к серверу и пытаемся сами совершить tls-handshake. Значит нас блокируют. Значит всё в порядке. И нам не сильно важно какой другой - да пусть даже мы дисконнект получим. Главное, что мы не получили сертификат, который является флагом блокировки. Единственным минусом такого подхода является то, что в случае, если Мегафон начнёт поддерживать eSNI, то коннекты к его сайту будут проксироваться, но пока что SNI у него вполне незашифрованный. Да и, на самом деле, сертификат там самоподписанный отдаётся, так что можно и углубить проверку. Итак, мы понимаем, что сайт блокируется. Что делать? Протокол проще некуда, к нему есть удобная клиентская реализация, которую чуть доработать - и можно пользоваться. Во время тестов я натолкнулся на весьма странное поведение linkedin. Дело в том, что при его запросе почему-то я вообще не получал никакого ответа, коннект просто уходил в таймаут. Я решил, что если коннект таймаутится, есть смысл попробовать его тоже перенаправить через VPN - хуже точно не будет. Каково же было моё удивление, когда точно такое же поведение было и через VPN. Поэтому я реализовал следующую обработку соединения Hostname мы получаем из SNI :. С таймаутом на соединение в 2 секунды. В чём смысл? Если вдруг оказывается, что наша машина, на котором развёрнут NGINX оказывается IPv6-capable, а изначальный клиент нет, то мы сможем спроксировать трафик через IPv6, при том, что клиент будет думать что соединяется по IPv4. Аналогично и с прокси-сервером. Конкретно в моём случае, основные затраты на производительность - при первичном подключении к серверу. Но, честно говоря, даже они минимальны. Самую большую нагрузку составил как ни странно сайт по проверке замедления t. В качестве железа подойдёт почти что всё что угодно, на чем можно запустить Linux. В моём случае, я запускаю это всё на Netgear R с ARM-процессором внутри, и кастомной прошивкой с версией ядра всего лишь 2. В общем и целом теоретически запустится на практически любом Linux-е с версией ядра хотя бы 2. Я успешно собирал прямо на самом роутере - занимает некоторое время, но не так чтобы бесконечное. Я скачивал релизный тарболл из их раздела загрузок. Нужен для получения и разбора сертификатов SSL-сессий. Настройка socks-прокси выходит за рамки этой статьи. Также я исхожу из того, что запускаете вы это на устройстве, маршрутизирующем ваш доступ к интернету - в моём случае это роутер. Оно должно завестись в том числе и на локалхосте, но для этого придётся садаптировать правила iptables. Также, исхожу из того, что трафик от клиентов приходит с br0 устройства. Разархивируем тарболл openresty, делаем git clone всем указанным выше дополнениям. Для удобства переименовываем папку openresty-X. V в openresty. Также замените Обратите внимание, что br0 - это интерфейс локальной сети, с которого подключаются клиенты! Даём start. В принципе теоретически может заработать и без рута, но я не пробовал Во-первых, как я уже писал, для того, чтобы исключить проблемы с ненужным проксированием провайдерского сайта в случае если они начнут использовать eSNI, есть смысл проверять сертификат на самоподписанность - это несложно средствами OpenSSL. Во-вторых, пока что совершенно не поддерживается IPv6. Добавить поддержку на самом деле несложно С другой стороны, как правило IPv6 трафик сейчас фильтруется редко если вообще где-то фильтруется. В-третьих, опять таки не поддерживается UDP. Там будет хватать своих проблем. Это, наверное, самая сложная задача. На самом деле этот механизм можно использовать и для полноценного DPI. По сути мы получаем полноценную TCP-сессию, которую можем инспектировать 'на лету' - достаточно, по сути, пропатчить pipe-функцию. С другой стороны, смысла в анализе сырых данных после завершения SSL-handshake нынче мало, а зашифрованного трафика становится только больше Этот же метод в принципе позволяет и записывать трафик - закон Яровой исполнять, например. Надеюсь я не открыл сейчас ящик Пандоры Кто знает. Скажу честно, местами мне было лень обрабатывать ошибки, поэтому возможно странное поведение. Если обнаружите какие-то ошибки пишите, попробую поправить - но в принципе я сижу через этот DPI сейчас сам, и проблем особых не заметил а те что заметил - пофиксил. Поиск Профиль. Настройка Linux Nginx Lua. Зачем всё это нужно? Какие вообще уже есть методы решения? Вообще, эта проблема имеет несколько решений. Про последний способ дальше и пойдёт речь. О деталях реализации Конкретно у меня по причине отсутствия кабельного интернета дома сейчас используется 4G-интернет от Мегафона, поэтому описание будет происходить с точки зрения именно Мегафона. Итак, мы запрашиваем заблокированный сайт Пусть будет, например, rutracker. Если находим в нём этот редирект - это означает сразу две вещи: Сайт блокируется, значит этот коннект надо редиректить. И всё было бы хорошо, если бы не TLSv1. А что дальше с заблокированным трафиком-то делать? Особенности некоторых сайтов и приятный бонус Во время тестов я натолкнулся на весьма странное поведение linkedin. А что насчёт производительности? Итак, переходим к практике - что нам для этого потребуется? Можно приступать к конфигурированию. Конфигурация Вся логика содержится в следующем конфигурационном файле: nginx. DEBUG, dest ; ngx. DEBUG, k.. DEBUG, err ; end upstream:setoption 'keepalive', true ; upstream:setoption 'tcp-nodelay', true ; upstream:setoption 'sndbuf', bufsize ; upstream:setoption 'rcvbuf', bufsize ; ngx. WARN, src. WARN, dst. Теги: Lua dpi nginx обход блокировок. Хабы: Настройка Linux Nginx Lua. Evengard Evengard. Сайт Github. Комментарии Комментарии Комментарии Больше вакансий на Хабр Карьере. Комментарии 6. Ваш аккаунт Войти Регистрация.