Обход dpi блокировки провайдера
Пессимистичные прогнозы что до внедрения так называемого суверенного интернета с использованием технологии DPI не оправдались, но радоваться пока рано. DPI по-прежнему может использоваться провайдерами для блокировки неугодных сайтов, и чтобы обойти такую блокировку, одного VPN будет недостаточно, вернее, VPN в этом случае будет бесполезен. Существует два типа DPI : пассивный и активный.
Активный банально режет пакет, не давая ему дойти до пользователя, пассивный вместо этого подменяет пакет фейковым и переадресует пользователя на страницу-заглушку.
Звучит устрашающе, но не всё так безнадежно как кажется. Сила DPI одновременно является его слабостью, если проверять все байты трафика, скорость соединения может упасть в несколько сот раз, что сделает использование интернета в принципе невозможным. Поэтому система анализа пакетов исследует только наиболее часто встречающиеся запросы, игнорируя нетипичные. На этом и основывается метод обхода DPI . Чтобы сломать DPI , достаточно изменить регистр любого символа в заголовке или добавить в него лишние пробелы.
Так ведь NGINX - это веб-сервер, а не инструмент для DPI?
И самым лучшим расширением NGINX является проект OpenResty - который добавляет практически ко всем аспектам NGINX-а поддержку Lua.
Мне могут сейчас возразить, что современный NGINX поддерживает "изкаробки" возможность скриптинга на JavaScript (njs), и будет прав, но, во-первых, OpenResty гораздо более развитый проект и его API имеет гораздо больше возможностей, а во-вторых, OpenResty использует LuaJit с поддержкой FFI, что позволяет вызывать C-методы напрямую из Lua-мира - и это создаёт такую возможность для расширения, которая njs даже и не снилась. Во всяком случае пока что.
При этом, NGINX имеет возможность проксировать и "сырой" TCP-трафик (теоретически и UDP тоже, но я реализовал "DPI" только TCP).
Программа для обхода DPI
Заключение и TL;DR
GoodbyeDPI — программа под Windows, позволяющая обходить пассивные и активные DPI. Просто скачайте и запустите ее, и заблокированные сайты станут снова доступны.
Для Linux есть аналогичная программа — zapret.
Используйте кроссплатформенную программу ReQrypt, если ваш провайдер блокирует сайты по IP-адресу.
Определить тип блокировки сайтов можно программой Blockcheck. Если в тестах DPI вы видите, что сайты открываются, или видите строку «обнаружен пассивный DPI», то GoodbyeDPI вам поможет. Если нет, используйте ReQrypt.
Как обитатель РФ, я готов ответственно заявить что в своём большинстве провайдеры Российской Федерации используют DPI (системы глубокого анализа трафика (DPI, Deep Packet Inspection)) для блокировки сайтов. Не существует единого стандарта DPI, однако есть множество реализаций как по типу, так и по работе, о них подробнее, а также как их обойти. (Упрощенная статья с хабра)
Активный DPI — DPI, подключенный в сеть провайдера привычным образом, как и любое другое сетевое устройство. Провайдер настраивает маршрутизацию так, чтобы DPI получал трафик от пользователей к заблокированным IP-адресам или доменам, а DPI уже принимает решение о пропуске или блокировке трафика. Активный DPI может проверять как исходящий, так и входящий трафик, однако, если провайдер применяет DPI только для блокирования сайтов из реестра, чаще всего его настраивают на проверку только исходящего трафика.Системы DPI разработаны таким образом, чтобы обрабатывать трафик с максимально возможной скоростью, исследуя только самые популярные и игнорируя нетипичные запросы, даже если они полностью соответствуют стандарту.
Я не буду приводить тяжелые материй как в оригинальной статье, а просто оставлю ссылку для тех кто хочет устроить себе ломку мозга а также ковыряние в винде. ТЫК
Если в тестах DPI вы видите, что сайты открываются, или видите строку «обнаружен пассивный DPI», то GoodbyeDPI вам поможет. Если нет, используйте ReQrypt.
Программа написанная автором этой статьи. Проста как мир, особенно интерфейсом. В случае Читинского ростелекома — убивает любую блокировку.
Есть кстати для линукса аналог — zapret
Используйте кроссплатформенную программу ReQrypt, если ваш провайдер блокирует сайты по IP-адресу.
Это очень убогая, сокращенная статья для хомячка по типу меня. Оригинал во всей сложности и красе:
P.S. На мобиле DPI обходить трудно, поэтому рекомендую 1.1.1.1 от cloudfire
Тут стоит отметить, что при использовании GoodbyeDPI факт обхода блокировки ОЧЕНЬ хорошо виден со стороны провайдера, равно как и посещаемые сайты. В то время как VPN выглядит просто как обращение к какому-то левому серверу за рубежом.
Так это головная боль провайдера, что он видит, как пользователь ходит по ресурсам, которые провайдер должен заблокировать, но ничего не может с этим сделать, это его зона ответственности, а не пользователя.
Нет, провайдеру похуй. Ему роскомнадзор поставил ТСПУ и сказал весь трафик гонять через него, провайдер это делает, на этом его полномочия всё. Этот ТСПУ, собственно, и занимается анализом пакетов (DPI) и выкидыванием ненужных. GoodbyeDPI, грубо говоря, абузит баги в этом ТСПУ. Он рандомно делает кучу замен в запросах уровня «вставить лишний пробел», «написать pOst вместо POST» — это всё ещё соответствует стандарту (и понимается большинством серверов), но одурманивает блокировщик.
А теперь два сценария развитий событий.
1. Ты использовал GoodbyeDPI, чтобы выйти в интернет с анонимного аккаунта и написать пост, дискредитирующий действия вооружённых сил РФ. Менты обратили на это внимание, завели дело и начали тебя вычислять. И вот в логах сервера будет лежать твой IP в открытом виде, а в логах провайдера — твои запросы в открытом виде. У тебя нулевая анонимность.
2. Вводится ответственность за обход блокировок. Роскомндазор тем временем обновляет прошивку ТСПУ, делая так, чтобы замены, указанные выше, больше не проскакивали, а заносились в специальный блокнотик. В следующий раз, когда ты запускаешь GoodbyeDPI, тебя ловят с поличным. Вот прям вообще никак не отвертишься.
Я это всё не к тому, что GoodbyeDPI — плохой способ выходить в интернет и им пользоваться нельзя. Просто надо чётко отдавать себе отчёт, что он не добавляет ни капли анонимности, наоборот — кричит о том, что ты обходишь блокировку. И, соответственно, не делать из-под GoodbyeDPI ничего, за что тебя могут привлечь к ответственности.
Надёжность сервисов обхода блокировки.
Будем проверять? Обязательно! Нам поможет в этом телеграмм бот @checkVPNbot
Заходим в телегу, запускаем бот, вбиваем название сервиса для проверки. Пусть это будет популярный Turbo VPN с зайкой в интерфейсе.
И так, что мы имеем?
Текст на скрине
А вот ещё. Чрезвычайно популярно расширение для Хром FastProxy - обход блокировки сайтов. Но! Читаем статью на Хабре «Вирусы» в расширениях на примере FastProxy. Однако. Стоит задуматься перед установкой.
По моему мнению, самый удобный способ обхода блокировок - установить Прокси пак от "Антизапрета". Об этом я упоминал месяц назад, но считаю, что стоит напомнить (да, баян, но мой и полезный)) .
Прокси Антизапрета автоматически включаются на заблокированных сайтах, на остальных не работают.
Тоже самое, но как расширения для браузеров. Обход блокировок Рунета от Антизапрета.
А теперь главное, из-за чего я решил запилить этот пост. DPI .
Часто в комментах к постам о ВПН пикабушники пишут, что у них не работают сервисы обхода блокировок. Тор, ВПН, Прокси бессильны. Похоже, что их провайдер использует для блокировки Deep Packet Inspection (DPI). Мой провайдер этим не балуется, но недавно я слетал в гости в Сибирь и у родни там такая проблема. Прекрасный случай попытаться применить накопленные знания. У меня получилось, значит и у Вас получится.
Далее, всё делаем на свой страх и риск. Опасаетесь? Проходим мимо
Launcher for GoodbyeDPI.
Прежде всего скачиваем утилиту с официального сайта (линк с сайта ведёт на файлохранилище) и скачивается в виде архива.
Упс! Сайт перестал работать. Санкции? Вот что автор пишет на своём телеграм-канале
Но скачать можно. Файлообменник работает. КЛИК
Просто магнет-ссылка для скачивания
Пока сайт не работает, мы всё же можем посмотреть на него из веб-архива
Программа портабельная, установки не требует.
Архив распаковать, к примеру, на диск С, где у нас и будет папка GoodbyeDPI.0.2.2.Launcher.v.5.2 .
Выбрать подпапку x86 или x86_64 - в зависимости от разрядности вашей Windows
Запустить файл Launcher for GoodbyeDPI.exe от имени Администратора.
Далее выбираем "Быстрый Шаблон" и кликаем "Запустить обход блокировок".
1-2-3-4-8 шаблоны устаревшие, 5-6-7 шаблоны новейшие улучшенные. Пробуем, экспериментируем, находим лучшее сочетание и сохраняем результат в настройках. В крайнем случае нас выручит кнопочка сброса. Она есть всё в тех же настройках.
Уже должно открыться. Не открывается? Кликаем другой шаблон и снова кликаем "Запустить обход блокировок". Обновляем страницу без кеша клавишами Shift + F5. Иногда приходится перезапустить браузер вставив в адресную строку chrome://restart/ и нажав Enter. Почти всегда помогает перезагрузка компа.
Не забываем! Всегда.
В проге есть ещё полезные "плюшки". Она может легко менять настройки ДНС и вам станут доступны сайты в доменной зоне .LIB В частности Рутор и Рутрекер уже освоились в этой зоне.
Найдёте эту настройку нажав в интерфейсе кнопку Мини FAQ и выбрав "Гайд по установке альтер. DNS".
Вот такая вкладка откроется.
Клик по окошку Получить OpenNIC DNS, копируем из открывшегося списка ДНС в Предпочитаемый DNS-сервер, клик Применить DNS-адреса для выбранного соединения (выбрана беспроводная сеть).
Точно также мы можем поменять наш ДНС на Гугловский, Днс от Яндекса, Cloudflare, Quad9.
И это ещё не всё. В начальном интерфейсе в верхнем правом углу нажав на кнопку Получить прокси, вам откроется вот такой список. К GoodbyeDPI это не имеет прямого отношения, но иногда требуется иметь актуальные прокси для своих нужд.
Некоторым эта фича может пригодится.
Если вам не требуется интерфейс, то GoodbyeDPI можно использовать в качестве службы Windows. Кликаем на кнопку вверху и настраиваем под себя.
Если у вас нормально работает обход блокировок с Прокси или ВПН, можно с настройкой GoodbyeDPI не заморачиваться. Разве что для общего развития.
UPD: Для обхода блокировок на Андроид, тоже можно прописать прокси от Антизапрета но только в WI-FI.
В мобильной сети не работает. Нужен root.
Там очень простые настройки. В интерфейсе внизу выбрать DNS Changer, вверху тыкнуть в плюсик. В открывшемся окне даём название и ниже вставляем значения DNS. В приложении создаётся интерфейс VPN, но это не совсем ВПН )))
Берём нужные ДНС вот ТУТ
или прямо здесь:
Подготовка и сборка
Предполагаю, что сборку осуществляем в /home/username/build. Устанавливать будем в /opt/nginxdpi
Разархивируем тарболл openresty, делаем git clone всем указанным выше дополнениям. Для удобства переименовываем папку openresty-X.Y.Z.V в openresty.
Переходим в /home/username/build/openresty, выполняем:
./configure --prefix=/opt/nginxdpi --with-cc=gcc \
--add-module=/home/username/build/lua-resty-openssl-aux-module \
--add-module=/home/username/build/lua-resty-openssl-aux-module/stream \
--add-module=/home/username/build/lua-resty-getorigdest-module/src
Выполняем make -j4 && make install , ждём пока всё соберётся.
После сборки копируем:
Готово! Можно приступать к конфигурированию.
Особенности некоторых сайтов и приятный бонус
Каково же было моё удивление, когда точно такое же поведение было и через VPN. Причём, с подключением через VPN IPv4 не соединялся, а по IPv6 вполне всё работало.
Тут я вспомнил, что у SOCKS5 есть два режима подключения к удалённому хосту - по IP и по хосту. Поэтому я реализовал следующую обработку соединения (Hostname мы получаем из SNI):
direct IP => direct Hostname => socks5 IP => socks5 Hostname
С таймаутом на соединение в 2 секунды. В чём смысл? Если вдруг оказывается, что наша машина, на котором развёрнут NGINX оказывается IPv6-capable, а изначальный клиент нет, то мы сможем спроксировать трафик через IPv6, при том, что клиент будет думать что соединяется по IPv4. Аналогично и с прокси-сервером.
Обход DPI на Android
На рутированных гаджетах автор приложения рекомендует установить в настройках использование DPITunnel прокси глобально, на устройствах с root в настройках Wi-Fi или APN нужно выставить прокси с адресом 127.0.0.1 и портом, указанным в настройках приложения.
Долгое время я терпел ограничения РосКомНадзора и соответствующие действия провайдеров по различным ограничениям доступа к сайтам - но с определённого момента устал, и начал думать как бы сделать так, чтобы было и удобно, и быстро, и при этом с минимумом заморочек после настройки. Хочу оговориться, что цель анонимизации не ставилась.
И в завершение.
На самом деле этот механизм можно использовать и для полноценного DPI. По сути мы получаем полноценную TCP-сессию, которую можем инспектировать "на лету" - достаточно, по сути, пропатчить pipe-функцию. С другой стороны, смысла в анализе сырых данных после завершения SSL-handshake нынче мало, а зашифрованного трафика становится только больше.
Этот же метод в принципе позволяет и записывать трафик - закон Яровой исполнять, например. Надеюсь я не открыл сейчас ящик Пандоры.
. вдруг кому-то из провайдеров этот метод позволит сэкономить на DPI-софте и уменьшить цену тарифов? Кто знает.
Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.
Существует два распространенных типа подключения DPI: пассивный и активный.
Какие вообще уже есть методы решения?
Вообще, эта проблема имеет несколько решений. Кратко перечислю самые известные и их минусы:
Заворачивание всего трафика в VPN-туннель либо какой-то прокси - как вариант, TOR. В случае с TOR-ом о скорости можно забыть, в остальных случаях скорость и время отклика также страдают, поскольку необходимо проксировать через удалённый сервер. Поскольку РосКомНадзор у нас действует на всей территории России, получается что весь трафик придётся проксировать через зарубежный сервер, а значит время отклика (или "пинг") будет сильно страдать. Сразу отрезается весь пласт, например, игровых приложений.
"Гибридный" вариант с использованием списков. Основной трафик идёт напрямую, но часть IP-адресов перенаправляются через VPN/прокси/TOR. Списки можно забирать, например, отсюда. Минусы - приходится периодически обновлять эти списки, и какими бы они не были актуальными есть вероятность всё же наткнуться на заблокированный сайт. На самом деле, один из лучших способов для комфортного пользования интернетом без ограничений. Но можно лучше!
Использование "чёрной магии", связанной с особенностями применяемого провайдерами DPI-софта. Я, в общем и целом, про "дыры" в обработке трафика (например, блокирование только на уровне DNS, или пропуск необычно сформированных пакетов), и, в частности, про GoodbyeDPI уважаемого @ValdikSS. Самый большой минус - работает далеко не везде. И чем дальше, тем хуже работает. Рост вычислительных мощностей скорее упрощает жизнь провайдерам, чем нам в этом вопросе.
. и наконец, использование DPI для обхода DPI! На самом деле этот способ является подвариантом "гибридного", но безо всяких списков. Мы анализируем пришедшие пакеты от провайдера, делаем вывод, заблокировал ли он нам что-то, и на этом основании либо пускаем дальше трафик к запросившему, либо перенаправляем трафик через VPN/прокси/TOR. Всё ещё требует конфигурации VPN/прокси/TOR, но уже не требует никаких списков, а также позволяет принимать решения на основании теоретически сколь угодно сложной логики!
Про последний способ дальше и пойдёт речь. И поможет нам в этом NGINX.
Активный DPI
Активный DPI — DPI, подключенный в сеть провайдера привычным образом, как и любое другое сетевое устройство. Провайдер настраивает маршрутизацию так, чтобы DPI получал трафик от пользователей к заблокированным IP-адресам или доменам, а DPI уже принимает решение о пропуске или блокировке трафика. Активный DPI может проверять как исходящий, так и входящий трафик, однако, если провайдер применяет DPI только для блокирования сайтов из реестра, чаще всего его настраивают на проверку только исходящего трафика.
Системы DPI разработаны таким образом, чтобы обрабатывать трафик с максимально возможной скоростью, исследуя только самые популярные и игнорируя нетипичные запросы, даже если они полностью соответствуют стандарту.
OWS — опциональный один или несколько символов пробела или табуляции, SP — одинарный символ пробела, HTAB — табуляция, CRLF — перенос строки и возврат каретки (\r\n).
Это значит, что запрос ниже полностью соответствует стандарту, его должны принять многие веб-серверы, придерживающиеся стандарта:
На деле же, многие веб-серверы не любят символ табуляции в качестве разделителя, хотя подавляющее большинство серверов нормально обрабатывает и отсутствие пробелов между двоеточием в заголовках, и множество пробелов.
Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.
Этой рекомендации придерживаются далеко не все веб-серверы. Из-за двух пробелов между методом и путем ломаются некоторые сайты.
Выявляем и блокируем пакеты пассивного DPI
Поддельные пакеты, формируемые DPI, легко обнаружить анализатором трафика, например, Wireshark.
Пробуем зайти на заблокированный сайт:
Рассмотрим пакет от DPI подробнее:
А что дальше с заблокированным трафиком-то делать?
Итак, мы понимаем, что сайт блокируется. Что делать? Лучшее и наиболее универсальное что я придумал - это SOCKS5 прокси. Протокол проще некуда, к нему есть удобная клиентская реализация, которую чуть доработать - и можно пользоваться. Вдобавок, SOCKS5 реализован в Tor и SSH. Поднять SOCKS5-сервер - дело пяти минут.
Спускаемся на уровень TCP
Пакет 1:
Пакет 2:
В настоящий момент, в РФ DPI устанавливают и у конечных провайдеров, и на каналах транзитного трафика. Бывают случаи, когда одним способом можно обойти DPI вашего провайдера, но вы видите заглушку транзитного провайдера. В таких случаях нужно комбинировать все доступные способы.
А что насчёт производительности?
Итак, переходим к практике - что нам для этого потребуется?
В качестве железа подойдёт почти что всё что угодно, на чем можно запустить Linux. В моём случае, я запускаю это всё на Netgear R7000 с ARM-процессором внутри, и кастомной прошивкой с версией ядра всего лишь 2.6.36. В общем и целом теоретически запустится на практически любом Linux-е с версией ядра хотя бы 2.6.32.
Поскольку решение не совсем стандартное, придётся пересобирать NGINX/OpenResty из исходников. Я успешно собирал прямо на самом роутере - занимает некоторое время, но не так чтобы бесконечное.
OpenResty - это NGINX с LuaJit и основными Lua модулями. Я скачивал релизный тарболл из их раздела загрузок.
lua-resty-openssl и его C-модуль к NGINX lua-resty-openssl-aux-module. Нужен для получения и разбора сертификатов SSL-сессий.
Мой самописный C-модуль к NGINX и Lua-биндинг lua-resty-getorigdest-module для получения информации об IP и порте того, куда изначально обращался клиент.
lua-struct для парсинга бинарных пакетов (в частности, поиска сертификата после ServerHello).
Мой форк SOCKS5 Lua-клиента lua-resty-socks5 уважаемого @starius, которому была добавлена возможность соединяться через SOCKS5 не только по хостнейму, но и по IP-адресу.
SOCKS5 прокси-сервер для проксирования заблокированного трафика - например, socks-прокси TOR-а, либо обыкновенный ssh -D . Для VPN-сервера - надо установить его на самом VPN-сервере и проксировать через него. Настройка socks-прокси выходит за рамки этой статьи.
Также я исхожу из того, что запускаете вы это на устройстве, маршрутизирующем ваш доступ к интернету - в моём случае это роутер. Оно должно завестись в том числе и на локалхосте, но для этого придётся садаптировать правила iptables. Также, исхожу из того, что трафик от клиентов приходит с br0 устройства.
Что можно сделать ещё?
На самом деле есть несколько вещей, которые можно доработать, разной степени сложности.
Во-первых, как я уже писал, для того, чтобы исключить проблемы с ненужным проксированием провайдерского сайта в случае если они начнут использовать eSNI, есть смысл проверять сертификат на самоподписанность - это несложно средствами OpenSSL.
Во-вторых, пока что совершенно не поддерживается IPv6. Добавить поддержку на самом деле несложно. С другой стороны, как правило IPv6 трафик сейчас фильтруется редко (если вообще где-то фильтруется).
TLSv1.3 наносит ответный удар
Во-первых, в TLSv1.3 SNI может быть зашифрованным. Хорошая новость в том, что зашифрованный SNI не расшифрует и сам провайдер, а значит он будет блокировать любые TLS-запросы к IP точно так же. Вторая особенность в том, что сертификат сервер клиенту теперь тоже отправляет в зашифрованном виде.
Проблема усугубляется ещё и тем, что Мегафон отправляет свой сертификат как раз таки по TLSv1.3, то есть зашифрованным, в случае если клиент поддерживает TLSv1.3. А все основные браузеры сейчас его поддерживают. Проблема.
На этом этапе я уже даже думал о том, чтобы патчить ClientHello, убирая из него поддержку TLSv1.3, осуществляя по сути атаку на downgrade до TLSv1.2, но вовремя почитал описание TLSv1.3. В нём реализовано аж ДВА механизма по предотвращению подобных даунгрейдов, поэтому вариант плохой.
. И здесь приходится прибегать к экстренным мерам. На самом деле этот метод я реализовал даже первым, и он по сути и является сутью метода peek and splice у Squid-а.
Единственным минусом такого подхода является то, что в случае, если Мегафон начнёт поддерживать eSNI, то коннекты к его сайту будут проксироваться, но пока что SNI у него вполне незашифрованный. Да и, на самом деле, сертификат там самоподписанный отдаётся, так что можно и углубить проверку.
О деталях реализации
Конкретно у меня по причине отсутствия кабельного интернета дома сейчас используется 4G-интернет от Мегафона, поэтому описание будет происходить с точки зрения именно Мегафона.
Подробнее как именно всё сконфигурировать будет дальше. Здесь только общее описание и логика, которой я следовал при реализации.
Прежде всего, мы поднимаем NGINX в режиме stream на каком-то порту. Пусть будет 40443. Но сам по себе nginx не знает что делать с трафиком, что туда приходит. Именно это мы и будем разруливать с помощью Lua.
Прежде всего, мы перенаправляем весь трафик с 80 и 443 порта на этот самый 40443 порт при помощи iptables и его команды REDIRECT. Эта команда интересна тем, что прописывает в свойства сокета опцию SO_ORIGINAL_DST, в которой сохраняет оригинальный IP и порт, куда пакет изначально направлялся, до того как iptables над ним зверски поиздевался, переписав destination. Кхм, я отвлёкся. Эту информацию можно извлечь при помощи getsockopt. Правда из коробки обёртки над ним не было, так что пришлось написать простенький C-модуль для nginx.
Теоретически можно было бы использовать TPROXY, и пропатчить NGINX для поддержки SO_TRANSPARENT сокетов, но хотелось не прибегать к прямому патчу исходников NGINX-а и обойтись модулями, поэтому REDIRECT.
Для этого мы вычитываем первые данные, пришедшие от клиента (вплоть до 16 кбайт, но по факту первые пакеты весьма маленькие), перенаправляем их серверу и читаем ответ от него. Если находим в нём этот редирект - это означает сразу две вещи:
Сайт блокируется, значит этот коннект надо редиректить.
Если редиректа нету, значит мы просто отправляем этот запрос дальше клиенту и дальше просто проксируем трафик, не вмешиваясь в него.
Осталось только понять, как понять, куда именно мы изначально обращались, и как получить этот сертификат.
И здесь нам поможет SNI - дело в том, что (современный, мы не говорим про эпоху IE6, она ушла и слава богу) клиент отправляет домен, к которому обращается, в составе незашифрованных данных ClientHello. Самое интересное, что эти данные умеет вычитывать даже сам NGINX из коробки - модуль ssl_preread поставляется вместе с ним. Ну а Lua-биндинги позволяют получить эту информацию и для наших целей.
И всё было бы хорошо, если бы не TLSv1.3, который всю эту историю сильно обламывает.
Обход DPI на Windows, Linux и MacOS
Это консольный инструмент, чтобы его запустить, нужно открыть командную строку от имени администратора, перейти в расположение исполняемого файла и выполнить команду:
goodbyedpi.exe -1 -a
Вместо -1 можно использовать ключи -2, -3 и -4, более подробную информацию ищите на странице разработчика.
GoodbyeDPI доступна только для Windows.
Второй более удобный вариант предполагает использование утилиты GreenTunnel с графическим интерфейсом.
Эффективное проксирование для обхода блокировок по IP
В случае блокировок по IP-адресу, провайдеры фильтруют только исходящие запросы на IP-адреса из реестра, но не входящие пакеты с этих адресов.
Программа ReQrypt работает как эффективный прокси-сервер: исходящие от клиента пакеты отправляются на сервер ReQrypt в зашифрованном виде, сервер ReQrypt пересылает их серверу назначения с подменой исходящего IP-адреса на клиентский, сервер назначения отвечает клиенту напрямую, минуя ReQrypt.
Долгое время разработка была заморожена из-за того, что автор не мог найти сервер с возможностью спуфинга. Спуфинг IP-адресов часто используется для амплификации атак через DNS, NNTP и другие протоколы, из-за чего он запрещен у подавляющего большинства провайдеров. Но сервер все-таки был найден, хоть и не самый удачный. Разработка продолжается.
Пассивный DPI
Конфигурация
Вся логика содержится в следующем конфигурационном файле:
Можно было бы наверное разделить lua код от конфига, но мне было немного лень =)
Замените 192.168.120.1 и 45213 на хост и порт вашего SOCKS5-сервера!
Также замените 192.168.3.1 на IP-адрес DNS-сервера, которым вы хотите резолвить хосты.
Размещаем его в /opt/nginxdpi/cfg/nginx.conf
Создаём файл /opt/nginxdpi/cfg/start.sh со следующим содержимым:
Обратите внимание, что br0 - это интерфейс локальной сети, с которого подключаются клиенты!
Даём start.sh права на выполнение chmod +x /opt/nginxdpi/cfg/start.sh , и наконец запускаем всё это добро (от рута! В принципе теоретически может заработать и без рута, но я не пробовал. ):
Читайте также: