Локальный прокси tpws что это
Маршрутизация локальной сети через прозрачный socks-прокси
Потребовалось пустить трафик со всех домашних устройств, включая смартфоны, через ssh tunnel.
Советую другой способ с использованием tun2socks.
openssh-client — стандартный ssh клиент для linux.
autossh — позволяет проверять соединение с ssh сервером, и подключаться при разрыве.
redsocks — прозрачный socks-прокси сервер.
isc-dhcp-server — dhcp сервер.
iptables — думаю, комментарии излишне.
Итак, приступим. Первым делом поднимем DHCP сервер на беспроводном интерфейсе ноутбука.
Настроим нужный интерфейс:
Узнать название необходимого интерфейса можно командой:
Далее настроим сам dhcp сервер:
Должен содержать строчку с указанием необходимого интерфейса:
Пробежимся по главным параметрам:
option domain-name-servers — адреса DNS серверов, которые получат клиенты при подключении. В случае наличия локального DNS сервера (как у меня), необходимо указать адрес интерфейса 192.168.1.100.
range — диапазон присваиваемых IP адресов.
option routers — этот адрес будет служить шлюзом для клиентов.
Настройка завершена, необходимо перезапустить службу командой:
Проверить состояние можно командой:
Осталось только настроить маршрутизатор на использование нашего DHCP сервера, а именно, переключить режим DHCP, в настройках LAN на «Relay» и указать там, IP адрес нашего DHCP сервера — 192.168.1.100.
Теперь все устройства, подключающиеся к точке доступа роутера, будут получать сетевые настройки от сетевого интерфейса ноутбука, но сам доступ в интернет необходимо настроить. Напомню, что задача состоит в том, чтобы трафик всех устройств, включая ноутбук заворачивал в ssh-туннель. На мой взгляд ssh туннель разумней запускать в качестве службы, которая будет принимать перенаправления от прокси сервера redsocks.
Установим необходимый инструментарий:
After=network.target — Запуск службы при наличии сетевого подключения.
Environment=«AUTOSSH_GATETIME=0» — указывает systemd работу ssh в фоне.
Отдельно следует рассмотреть параметр ExecStart:
Запуск autossh со следующими параметрами:
-M — порт мониторинга. С этим параметром autossh будет непрерывно посылать запросы на сервер через указанные порты, если от сервера не приходит ответ, autossh подключается заново. Указанный порт мониторинга и порт порядком выше (+1) должны быть свободными в системе. Так как это делает такой мониторинг не практичным, мы отключаем эту функцию указывая значение 0.
«- o ServerAliveInterval» и «-o ServerAliveCountMax» — две опции, указывающие ssh клиенту отправлять запросы серверу непосредственно через туннель (то что нам нужно), чтобы поддерживать соединение, когда оно не активно. Также, если от сервера не следует ответа, соединение будет считаться разорванным и autossh подключается заново.
-N — не отправлять команд на сервер.
-D 1080 — открываем динамический порт на localhost.
user@server — здесь следует указать пользователя и адрес(доменное имя) сервера.
-p 22 — указываем порт подключения.
Включаем запуск во время загрузки:
Итак, запущены DCHP сервер на беспроводном интерфейсе ноутбука и стабильный ssh туннель в системе, осталось только завернуть в него трафик со всех устройств в локальной сети. Сделаем это с помощью redsocks и iptables.
Сохраняем конфиг и перезагружаем службу:
Остался, последний трюк с использование iptables. Предлагаю сразу создать скрипт со следующим содержанием:
Теперь все запросы с локальной сети, включая хост, будут направляться в ssh туннель.
Как обойти блокировку сайта роcкомнадзором с помощью DPI
Мы прекрассно знаем что цензура это плохо. Но не смотря на старания властей усилить свое влияние в сети, они все также слабы и часто глупы. Мы уже рассказывали как обойти блокировку рутрекера. Сегодня мы познакомим вас с еще одним способом обхода блокировки сайта при помощи технологии обхода DPI(deep packet inspection)
У провайдеров в DPI бывают бреши. Они случаются от того, что правила DPI пишут дляобычных пользовательских программ, опуская все возможные случаи, допустимые по стандартам.
Это делается для простоты и скорости. Нет смысла ловить хакеров, которых 0.01%, ведь все равно эти блокировки обходятся довольно просто даже обычными пользователями.
Некоторые DPI не могут распознать http запрос, если он разделен на TCP сегменты.
Например, запрос вида «GET / HTTP/1.1rnHost: kinozal.tv……»
мы посылаем 2 частями : сначала идет «GET «, затем «/ HTTP/1.1rnHost: kinozal.tv…..».
Другие DPI спотыкаются, когда заголовок «Host:» пишется в другом регистре : например, «host:».
Кое-где работает добавление дополнительного пробела после метода : «GET /» => «GET /» или добавление точки в конце имени хоста : «Host: kinozal.tv.»
Как реализовать обход б на практике в системе linux
Дальнейшее поведение системы по выбору размера отсылаемых пакетов зависит от реализованногов ней алгоритма. Опыт показывает, что linux первый пакет всегда отсылает не более указанной в window size длины, остальные пакеты до некоторых пор шлет не более max(36,указанный_размер).
После некоторого количества пакетов срабатывает механизм window scaling и начинает учитываться фактор скалинга, размер пакетов становится не более max(36,указанный_рамер [ad name=»Responbl»]
Использование модификатора пакетов NFQWS
Эта программа — модификатор пакетов и обработчик очереди NFQUEUE.
Она берет следующие параметры :
—daemon ; демонизировать прогу
—qnum=200 ; номер очереди
—wsize=4 ; менять tcp window size на указанный размер
—hostcase ; менять регистр заголовка «Host:»
Параметры манипуляции могут сочетаться в любых комбинациях.
Использование transparent proxy TPWS
tpws — это transparent proxy.
—bind-addr ; на каком адресе слушать. может быть ipv4 или ipv6 адрес. если не указано, то слушает на всех адресах ipv4 и ipv6
—port=
; на каком порту слушать
—daemon ; демонизировать прогу
—user= ; менять uid процесса
—split-http-req=method|host ; способ разделения http запросов на сегменты : около метода (GET,POST) или около заголовка Host
—split-pos= ; делить все посылы на сегменты в указанной позиции. Если отсыл длинее 8Kb (размер буфера приема), то будет разделен каждый блок по 8Kb.
—hostcase ; замена «Host:» => «host:»
—hostdot ; добавление точки после имени хоста : «Host: kinozal.tv.»
—methodspace ; добавить пробел после метода : «GET /» => «GET /»
Параметры манипуляции могут сочетаться в любых комбинациях.
Есть исключение : split-pos заменяет split-http-req.
Обход блокировки сайтов у конкретных провайдеров.
Загружайте сайт и смотрите куда идет редирект. Потом вносите домен в zapret-hosts-user.txt. Например, на kinozal.tv имеются 2 запрашиваемых поддомена : s.kinozal.tv и st.kinozal.tv с разными IP адресами.
sknt.ru : проверена работа с tpws с параметром «—split-http-req=method». возможно, будет работать nfqueue, пока возможности проверить нет.
tkt : помогает разделение http запроса на сегменты, настройки mns.ru подходят
ТКТ был куплен ростелекомом, используется фильтрация ростелекома.
Поскольку DPI не отбрасывает входящую сессию, а только всовывает свой пакет, который приходит раньше ответа от настоящего сервера, блокировки так же обходятся без применения «тяжелой артиллерии» следующим правилом :
Ростелеком : см tkt
tiera : сама тиера до последнего ничего не банила. Похоже, что банит вышестоящий оператор, возможно telia. Требуется сплит http запросов в течение всей сессии.
Способы получения списка заблокированных IP
1) Внесите заблокирванные домены в ipset/zapret-hosts-user.txt и запустите ipset/get_user.sh
На выходе получите ipset/zapret-ip-user.txt с IP адресами.
2) ipset/get_reestr.sh получает список доменов от rublacklist и дальше их ресолвит в ip адреса в файл ipset/zapret-ip.txt. В этом списке есть готовые IP адреса, но судя во всему они там в точности в том виде, что вносит в реестр РосКомПозор. Адреса могут меняться, позор не успевает их обновлять, а провайдеры редко банят по IP : вместо этого они банят http запросы с «нехорошим» заголовком «Host:» вне зависимости от IP адреса. Поэтому скрипт ресолвит все сам, хотя это и занимает много времени.
Все варианты рассмотренных скриптов автоматически создают и заполняют ipset.
Варианты 2 и 3 дополнительно вызывают вариант 1.
Принудительное обновление ipset выполняет скрипт ipset/create_ipset.sh
Можно внести список доменов в ipset/zapret-hosts-user-ipban.txt. Их ip адреса будут помещены в отдельный ipset «ipban». Он может использоваться для принудительного завертывания всех соединений на прозрачный proxy «redsocks».
Пример обхода блокировки сайта на debian 7
Debian 7 изначально содержит ядро 3.2. Оно не умеет делать DNAT на localhost.
Конечно, можно не привязывать tpws к 127.0.0.1 и заменить в правилах iptables «DNAT 127.0.0.1» на «REDIRECT», но лучше установить более свежее ядро. Оно есть в стабильном репозитории :
Скопировать директорию «zapret» в /opt.
Собрать nfqws :
Скопировать /opt/zapret/init.d/debian7/zapret в /etc/init.d.
В /etc/init.d/zapret выбрать пераметр «ISP». В зависимости от него будут применены нужные правила.
Там же выбрать параметр SLAVE_ETH, соответствующий названию внутреннего сетевого интерфейса.
Включить автостарт : chkconfig zapret on
(опционально) Вручную первый раз получить новый список ip адресов : /opt/zapret/ipset/get_antizapret.sh
Зашедулить задание обновления листа :
Создать строчку «0 12 * * */2 /opt/zapret/ipset/get_antizapret.sh». Это значит в 12:00 каждые 2 дня обновлять список.
Запустить службу : service zapret start
Попробовать зайти куда-нибудь : http://ej.ru, http://kinozal.tv, http://grani.ru.
Если не работает, то остановить службу zapret, добавить правило в iptables вручную,
запустить nfqws в терминале под рутом с нужными параметрами.
Пытаться подключаться к заблоченым сайтам, смотреть вывод программы.
Если нет никакой реакции, значит скорее всего указан неверный номер очереди или ip назначения нет в ipset.
Если реакция есть, но блокировка не обходится, значит параметры обхода подобраные неверно, или это средство не работает в вашем случае на вашем провайдере.
Пример обхода блокировки сайта на ubuntu 12,14
Имеется готовый конфиг для upstart : zapret.conf. Его нужно скопировать в /etc/init и настроить по аналогии с debian.
Запуск службы : «start zapret»
Останов службы : «stop zapret»
Ubuntu 12 так же, как и debian 7, оснащено ядром 3.2. См замечание в разделе «debian 7″.
[ad name=»Responbl»]
Пример обхода блокировки сайта на ubuntu 16,debian 8
Процесс аналогичен debian 7, однако требуется зарегистрировать init скрипты в systemd после их копирования в /etc/init.d.
install : /usr/lib/lsb/install_initd zapret
remove : /usr/lib/lsb/remove_initd zapret
[ad name=»Responbl»]
Пример обхода блокировки сайта на других linux системах.
Существует несколько основных систем запуска служб : sysvinit, upstart, systemd.
Настройка зависит от системы, используемой в вашем дистрибутиве.
Типичная стратегия — найти скрипт или конфигурацию запуска других служб и написать свой по аналогии, при необходимости почитывая документацию по системе запуска. Нужные команды можно взять из предложенных скриптов.
Настройка файрвола для обхода блокировок сайтов.
Если вы используете какую-то систему управления фаерволом, то она может вступать в конфликт с имеющимся скриптом запуска. В этом случае правила для iptables должны быть прикручены к вашему фаерволу отдельно от скрипта запуска tpws или nfqws.
Именно так решается вопрос в случае с openwrt, поскольку там своя система управления фаерволом.
При повторном применении правил она могла бы поломать настройки iptables, сделанные скриптом из init.d.
Что делать с openwrt для обхода блокировок сайта.
Установить дополнительные пакеты :
Самая главная трудность — скомпилировать программы на C.
Это можно сделать средствами кросс-компиляции на любой традиционной linux системе.
Читайте compile/build_howto_openwrt.txt.
Ваша задача — получить ipk файлы для tpws и nfqws.
Скопировать директорию «zapret» в /opt на роутер.
Установить ipk. Для этого сначала копируем на роутер ipk в /tmp, потом
Смотрим, что появились исполняемые файлы /opt/zapret/tpws/tpws, /opt/zapret/nfq/nfqws.
Скопировать /opt/zapret/init.d/zapret в /etc/init.d.
В /etc/init.d/zapret выбрать пераметр «ISP». В зависимости от него будут применены нужные правила.
В зависимости от вашего провайдера внести нужные записи в /etc/firewall.user.
Зашедулить задание обновления листа :
Создать строчку «0 12 * * */2 /opt/zapret/ipset/get_antizapret.sh». Это значит в 12:00 каждые 2 дня обновлять список.
Если у вас linux x64, то вместо компиляции toolchain можно использовать пре-компилированный SDK от разработчиков openwrt.
https://downloads.openwrt.org/
Найдите вашу версию openwrt, найдите вашу архитектуру, скачайте файл «OpenWrt-SDK-*».
Фактически это тот же buildroot, только в нем уже подготовлен toolchain для нужной версии openwrt, нужной target архитектуры и хост-системы linux x64.
Прекомпилированые бинарики
Компилировать для роутеров может быть непростой задачей, требующей изучения вопроса и гугления «глюков из коробки» в openwrt SDK.
Нет кое-каких бинариков, нет кое-каких линков, в результате из коробки SDK может выдавать ошибки. Для самых распространенных архитектур собраны статические бинарики. См binaries.
Статическая сборка означает, что бинарик не зависит от типа libc (uclibc или musl) и наличия установленных so — его можно использовать сразу.
Лишь бы подходил тип CPU. У ARM и MIPS есть несколько версий. Если на вашей версии выдаются ошибки при запуске — придется собирать самостоятельно под вашу систему.
Защищённые прокси — практичная альтернатива VPN
В интернете есть достаточное количество информации по теме шифрования и защиты трафика от вмешательств, однако сложился некоторый перекос в сторону различных VPN-технологий. Возможно, отчасти он вызван статьями VPN-сервисов, которые так или иначе утверждают о строгом превосходстве VPN-решений перед прокси. При этом многие решения тех же VPN-провайдеров, не смотря на маркетинговое позиционирование в качестве VPN, технически являются прокси.
На практике прокси больше подходят для повседневной защиты веб-трафика, не создавая при этом неудобств в виде заметной потери скорости и неизбирательности туннелирования. То есть при использовании хорошего прокси не стоит необходимость его отключать для комфортного пользования интернетом.
В этой статье расказано о преимуществах защищённого прокси перед VPN и предложены различные реализации, готовые к использованию.
В чём различие между VPN и прокси?
VPN — это общее название технологий для объединения внутренних сетей на уровне сетевых пакетов или кадров через соединение, установленное поверх другой сети (чаще всего публичной).
Прокси — это серверное приложение, осуществляющее соединения или запросы от своего имени и сетевого адреса в пользу подключившегося к нему клиента, пересылая в результате ему все полученные данные.
VPN осуществляет пересылку полезной нагрузки, находящейся на третьем или втором уровне сетевой модели OSI. Прокси осуществляют пересылку полезной нагрузки между четвёртым и седьмым уровнями сетевой модели OSI включительно.
И VPN, и прокси могут иметь или не иметь шифрования между клиентом и сервером. Обе технологии пригодны для того, чтобы направить трафик пользователя через доверенный сервер, применяя шифрование по пути до него. Однако, подключение через прокси делает это более прямолинейным способом, не привнося дополнительную инкапсуляцию сетевых пакетов, серые адреса самой VPN сети и изменения таблицы маршрутизации, которые привносит VPN просто лишь для того, чтобы сетевой стек системы пользователя направил трафик через нужный сервер.
Преимущества прокси
Требования к прокси
Выбирая для себя реализацию защищённого прокси-сервера, я отметил несколько критериев, которым она должна удовлетворять:
Особенности obfs4
В спецификации протокола obfs4 есть места, которые вызывают вопросы. В рукопожатии со стороны клиента используется номер часа от начала эпохи UNIX, который потом участвует в HMAC-подписи. Сервер, принимая такой пакет от клиента проверяет его, подставляя номер часа по своему времени. Если всё верно, то отвечает своей частью рукопожатия. Для борьбы с разбросом часов сервер должен ещё проверять предыдущий и следующий час.
Зная такое характерное поведение, можно проверить сервер на границе следующего и послеследующего часа, воспроизведя одно из прошлых записанных рукопожатий со стороны клиента. Если сервер перестанет отвечать своей частью рукопожатия в это самое время, то это достаточное основание, чтобы судить, что сервер обслуживает протокол obfs4.
Судя по всему, автор со временем осознал эту проблему и в коде obfs4 реализована защита от обнаружения через воспроизведение. В спецификации она нигде не описана.
Однако, такая защита наоборот упрощает работу по блокировке протокола: сетевому фильтру достаточно в случае сомнений задержать отправку рукопожатия от клиента, перехватив её, а затем отправить сообщение с рукопожатием первым. Таким образом он спровоцирует защиту от воспроизведения уже против клиента, вынуждая сам сервер блокировать клиента.
Следующий момент, вызывающий сомнения это формат «кадра» с данными. Выглядит он следующий образом:
Первые два байта каждого кадра это длина пакета, гаммированная с ключом, который вычисляется от предыдущих ключей. Как он вычисляется ключ не столь важно, главное, что настоящая длина пакета подвергается операции побитового исключающего ИЛИ каким-то ключом. Это значит, что можно инвертировать бит в этой части данных и подмена не будет сразу замечена. Если инвертировать младший значащий бит этого поля, то длина кадра станет либо на единицу меньше истинной, либо на единицу больше. В первом случае это приведёт к сбросу соединения через небольшое случайное время из-за ошибки распаковки NaCl secretbox.
Второй случай более интересный: сервер будет ждать ещё один байт для того, чтобы начать распаковку криптобокса. Получив ещё ровно один байт он также сбросит соединение из-за ошибки распаковки криптобокса. Это поведение можно считать специфичным для obfs4 и можно судить, что мы с высокой вероятностью имеем дело с ним. Таким образом, удачно разрушив одно из соединений клиента, можно с примерно 50%-ным шансом обнаружить obfs4.
Конечно, определение границ одного кадра в потоке тоже может представлять непростую задачу, но нет чётких гарантий, что нерешаемую. В случае обмена короткими сообщениями границы одного кадра могут совпасть с границами TCP-сегмента.
Ну и последняя особенность заключается в том, что сам по себе протокол внешне не похож ни на один из общепринятых. Он спроектирован с предположением, что DPI играет по правилам и незнакомые протоколы просто не трогает. Суровая реальность может показать, что это не так.
По всем этим соображениям я воздержался от использования obfs4.
TLS и SSH в качестве криптографического транспорта
Разумно было бы воспользоваться стандартными защищёнными сетевыми протоколами вроде TLS или SSH для обёртывания соединений с прокси. Действительно, к таким протоколам обычно не возникает претензий со стороны DPI, потому что ими может быть зашифрован легетимный трафик. Что же касается активных проб со стороны DPI, этот вопрос можно решить в частном порядке, в зависимости от конкретного протокола прокси.
Ниже будут представлены несколько готовых решений на базе этих протоколов, пригодных для повседневной постоянной защиты трафика.
SOCKS5 внутри SSH
Вариант с использованием функции dynamic port forwarding у OpenSSH рассматривался выше, но он имеет большие проблемы со скоростью. Единственный способ избавиться от мультиплексирования соединений — это использовать альтернативную реализацию клиента SSH, который обеспечивал бы каждое проксируемое соединение отдельной SSH-сессией.
Я проделал такую работу и реализовал его: Rapid SSH Proxy. Эта реализация обеспечивает каждое проксируемое соединение отдельной SSH-сессией, поддерживая пул подготовленных SSH-сессий для удовлетворения поступающих запросов подключения с минимальной задержкой.
Следует особо отметить ключевую особенность: никакого стороннего ПО не нужно устанавливать на сервер — rsp работает как ssh-клиент с обычным сервером OpenSSH. Сервером может быть любая unix-подобная операционная система, а так же Windows и Windows Server (в новых версиях OpenSSH теперь доступен в компонентах системы).
Приведу сравнение скорости через сервер в США:
SOCKS5 внутри TLS
В случае с TLS очевидным решением было бы использовать stunnel или аналогичную TLS-обёртку для TCP-соединений с SOCKS5-сервером. Это действительно вполне хорошо работает, но возникает следующая проблема: рукопожатие TLS для каждого нового соединения занимает дополнительное время и появляется заметная на глаз задержка при установлении новых соединений из браузера. Это несколько ухудшает комфорт при веб-серфинге.
Для того, чтобы скрыть эту задержку, я подготовил специализированную замену stunnel на клиенте, которая поддерживает пул уже установленных, готовых к запросу TLS-соединений. Даже целых два — первый из них послужил прототипом:
HTTP-прокси внутри TLS aka HTTPS-прокси
Есть небольшая путаница в отношении сочетания слов «HTTPS» и «прокси». Есть два понимания такого словосочетания:
Примечательно, что ни в одном браузере нет простой возможности задать в настройках HTTPS-прокси через пользовательский интерфейс (то поле HTTPS-прокси, которое там есть, как раз относится к первому случаю). Но это не представляет собой большой трудности.
Поперебирав различные готовые варианты, я решил написать свой HTTP(S) прокси-сервер: dumbproxy.
Ключевой особенностью получившегося решения является то, что современные браузеры (Firefox и семейство Chrome, включая новый MS Edge) могут работать с ним без какого-либо дополнительного ПО на клиенте (см. руководство по настройке клиентов).
Следует отметить особенности реализации в отношении противодействия активным пробам со стороны DPI. HTTP-прокси легко распознать, подключившись к нему и осуществив попытку какого-либо запроса стороннего ресурса. Если прокси имеет авторизацию, то по стандарту он должен отвергнуть запрос с кодом 407, специфичным именно для HTTP-прокси, и предложить возможную схему для авторизации. Если прокси работает без авторизации, то он выполнит запрос, чем так же себя выдаст. Есть как минимум два способа решения этой проблемы (и оба они реализованы в dumbproxy).
Первый способ заключается в том, чтобы использовать аутентификацию клиентов по сертификатам ещё на этапе TLS-рукопожатия. Это самый стойкий метод, и это действительно корректная причина, по которой любой обычный веб-сервер мог бы отвергнуть клиента.
Второй способ заключается в том, чтобы скрыть от неавторизованных клиентов код ответа 407, возвращая вместо него любой другой ответ с ошибкой. Это вызывает другую проблему: браузеры не смогут понять, что для прокси требуется авторизация. Даже если браузер имеет сохранённый логин и пароль для этого прокси, ответ 407 важен для определения схемы авторизации, по которой эти учётные данные должны быть отправлены (Basic, Digest и т. д.). Для этого нужно позволить прокси генерировать ответ 407 на секретный запрос, чтобы браузер мог запомнить схему авторизации. В качестве такого секретного запроса используется настраиваемый секретный домен (не обязательно реально существующий). По умолчанию этот режим выключен. Подробности можно посмотреть в разделе об аутентификации.
Заключение
Я пользуюсь этими решениями уже один год и в итоге они мне полностью заменили VPN, вместе с этим сняв все проблемы, с которыми сопряжено его использование.
Надеюсь, что эта статья добавит к арсеналу читателей новые подходы к защите трафика и будет им полезной.