mirror of https://github.com/bol-van/zapret/
7 changed files with 142 additions and 0 deletions
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -0,0 +1,142 @@ |
|||
Расскажу как я решал вопрос с блокировкой https на роутере. |
|||
На тех провайдерах, что мне доступны, все, кроме одного либо банили https по IP (вообще нет конекта), либо захватывали TLS сессию и она намертво зависала - пакеты больше не приходили. На домру удалось выяснить, что DPI цепляется к SNI (Server Name Indication) в TLS, но сплит TLS запроса не помог. Я пришел к выводу, что https самым разумным будет прозрачно заворачивать в socks. |
|||
Tor поддерживает "из коробки" режим transparent proxy. Это можно использовать в теории, но практически - только на роутерах с 128 мб памяти и выше. Таких роутеров не так много. В основном объем памяти 32 или 64 мб. И тор еще и тормозной. |
|||
Другой вариант напрашивается, если у вас есть доступ к какой-нибудь unix системе с SSH, где сайты не блокируются. Например, у вас есть VPS вне России. Именно так и поступил. |
|||
Понятийно требуются следующие шаги : |
|||
1) Выделять IP, на которые надо проксировать трафик. У нас уже имеется ipset "zapret", технология создания которого отработана. |
|||
2) Сделать так, чтобы все время при загрузке системы на некотором порту возникал socks. |
|||
3) Установить transparent соксификатор. Redsocks прекрасно подошел на эту роль. |
|||
4) Завернуть через iptables трафик с порта назначения 443 и на ip адреса из ipset 'zapret' на соксификатор |
|||
Буду рассматривать систему на базе openwrt dedicated driver, где уже установлена система обхода dpi "zapret". |
|||
По крайней мере нужно иметь заполненный ipset 'zapret', устанавливать tpws или nfqws не обязательно. |
|||
Более того, если они на вашей системе не срабатывают, то можно соксифицировать не только https, но и http. |
|||
Сделать так, чтобы все время при загрузке системы на некотором порту возникал socks |
|||
Т.к. дефолтный dropbear клиент не поддерживает создание socks, то для начала придется заменить dropbear ssh client на openssh : пакеты openssh-client и openssh-client-utils. |
|||
Устанавливать их нужно с опцией opkg --force-overwrite, поскольку они перепишут ssh клиент от dropbear. |
|||
После установки пакетов расслабим неоправданно жестокие права : chmod 755 /etc/ssh. |
|||
Следует создать пользователя, под которым будем крутить ssh client. Допустим, это будет 'proxy'. |
|||
Сначала установить пакет shadow-useradd. |
|||
Код: |
|||
useradd -d /home/proxy proxy |
|||
mkdir -p /home/proxy |
|||
chown proxy:proxy /home/proxy |
|||
Openssh ловит разные глюки, если у него нет доступа к /dev/tty. |
|||
Добавим в /etc/rc.local строчку : "chmod 666 /dev/tty" |
|||
Сгенерируем для него ключ RSA для доступа к ssh серверу. |
|||
Код: |
|||
su proxy |
|||
cd |
|||
mkdir -m 700 .ssh |
|||
cd .ssh |
|||
ssh-keygen |
|||
ls |
|||
exit |
|||
Должны получиться файлы id_rsa и id_rsa.pub. |
|||
Строчку из id_rsa.pub следует добавить на ssh сервер в файл $HOME/.ssh/authorized_keys. |
|||
Более подробно о доступе к ssh через авторизацию по ключам : http://vds-admin.ru/ssh/ssh-autentifikatsiya-po-klyucham-ispolzovanie-programm-ss...ygen-i-ssh-agent |
|||
Предположим, ваш ssh сервер - vps.mydomain.com, пользователь называется 'proxy'. |
|||
Проверить подключение можно так : ssh -N -D 1098 -l proxy vps.mydomain.com. |
|||
Сделайте это под пользователем "proxy", поскольку при первом подключении ssh спросит о правильности hostkey. |
|||
Соединение может отвалиться в любой момент, поэтому нужно зациклить запуск ssh. |
|||
Для этого лучший вариант - использовать procd - упрощенная замена systemd на openwrt версий BB и выше. |
|||
/etc/init.d/socks_vps : |
|||
Код: |
|||
#!/bin/sh /etc/rc.common |
|||
# Copyright (C) 2006-2011 OpenWrt.org |
|||
START=50 |
|||
STOP=50 |
|||
USE_PROCD=1 |
|||
USERNAME=proxy |
|||
COMMAND="ssh -N -D 1098 -l proxy vps.mydomain.com" |
|||
start_service() { |
|||
procd_open_instance |
|||
procd_set_param user $USERNAME |
|||
procd_set_param respawn 10 10 0 |
|||
procd_set_param command $COMMAND |
|||
procd_close_instance |
|||
} |
|||
Этому файлу нужно дать права : chmod +x /etc/init.d/socks_vps |
|||
Запуск : /etc/init.d/socks_vps start |
|||
Останов : /etc/init.d/socks_vps stop |
|||
Включить автозагрузку : /etc/init.d/socks_vps enable |
|||
Проверка : curl --socks5 127.0.0.1:1098 https://btc-e.com |
|||
Организовать прозрачную соксификацию |
|||
Установить пакет redsocks. Для более старых версий openwrt его придется собирать самим. |
|||
/etc/redsocks.conf : |
|||
скрытый текст |
|||
После чего перезапускаем : /etc/init.d/redsocks restart |
|||
Смотрим появился ли листенер : netstat -tnlp | grep 1099 |
|||
Автостарт redsocks при таком конфиге не работает, потому что на момент запуска сеть не инициализирована, и у нас даже нет 127.0.0.1. |
|||
Вместо штатного автостарта будем вешаться на события поднятия интерфейса. Разберем это позже. |
|||
Пока что отключим автостарт : /etc/init.d/redsocks disable |
|||
Завертывание соединений через iptables |
|||
/etc/firewall.user |
|||
Код: |
|||
SOXIFIER_PORT=1099 |
|||
. /lib/functions/network.sh |
|||
network_find_wan wan_iface |
|||
for ext_iface in $wan_iface; do |
|||
network_get_device ext_device $ext_iface |
|||
iptables -t nat -C OUTPUT -p tcp --dport 443 -o $ext_device -m set --match-set zapret dst -j REDIRECT --to-port $SOXIFIER_PORT || |
|||
iptables -t nat -I OUTPUT -p tcp --dport 443 -o $ext_device -m set --match-set zapret dst -j REDIRECT --to-port $SOXIFIER_PORT |
|||
done |
|||
sysctl -w net.ipv4.conf.br-lan.route_localnet=1 |
|||
iptables -t nat -C prerouting_lan_rule -p tcp --dport 443 -m set --match-set zapret dst -j DNAT --to 127.0.0.1:$SOXIFIER_PORT || |
|||
iptables -t nat -I prerouting_lan_rule -p tcp --dport 443 -m set --match-set zapret dst -j DNAT --to 127.0.0.1:$SOXIFIER_PORT |
|||
Внести параметр "reload" а /etc/config/firewall в указанное место : |
|||
Код: |
|||
config include |
|||
option path '/etc/firewall.user' |
|||
option reload '1' |
|||
Перезапуск : /etc/init.d/firewall restart |
|||
Все, теперь можно проверять : |
|||
/etc/init.d/redsocks stop |
|||
curl https://btc-e.com |
|||
# должно обломаться с надписью "Connection refused". если не обламывается - значит ip адрес btc-e.com не в ipset, |
|||
# либо не сработали правила фаервола. например, из-за не установленных модулей ipt |
|||
/etc/init.d/redsocks start |
|||
curl https://btc-e.com |
|||
# должно выдать страницу |
|||
Автозапуск redsocks |
|||
Я сделал для себя небольшой скриптик, вешающийся на события поднятия и опускания интерфейсов. |
|||
/etc/hotplug.d/iface/99-exec-on-updown |
|||
Код: |
|||
#!/bin/sh |
|||
local cmd |
|||
if [ "$ACTION" = ifup ]; then |
|||
cmd=$(uci get network.$INTERFACE.exec_on_up) |
|||
[ -n "$cmd" ] && $cmd |
|||
fi |
|||
if [ "$ACTION" = ifdown ]; then |
|||
cmd=$(uci get network.$INTERFACE.exec_on_down) |
|||
[ -n "$cmd" ] && $cmd |
|||
fi |
|||
Теперь можно в описания интерфейсов в /etc/config/nework внести в соответствующий раздел : |
|||
Код: |
|||
config interface 'wan' |
|||
........ |
|||
option exec_on_up '/etc/init.d/redsocks start' |
|||
Теперь reboot. Заходим снова, смотрим, что есть redsocks, есть ssh, опять проверяем curl https://btc-e.com. |
|||
Пробуем зайти на https://btc-e.com с компа внутри локалки. |
|||
Если у вас нет своего сервера |
|||
Если у вас нет своего сервера, да и просто для упрощения настройки, можно использовать proxy от antizapret.prostovpn.org. |
|||
Посмотрите на http://antizapret.prostovpn.org/proxy.pac. Вы увидите javascript, который проверяет ip назначения и выносит решение для броузера : идти напрямую или использовать proxy. Proxy указано как "proxy.antizapret.prostovpn.org:3128". |
|||
Этот прокси работает только на IP назначения из списка, на остальные возвращает ошибку, чтобы его не использовали для других целей. Поддерживается метод CONNECT, а значит можно его использовать для проксирования https. |
|||
В последней версии "zapret" я добавил скрипт "ipset/get_antizapret.sh". Он парсит список ip от "antizapret" и заносит в ipset "zapret". Это гарантирует, что вызов прокси будет по тем адресам, которые разрешены для проксирования. |
|||
Как изменится вышеописанная процедура |
|||
Убираем все, что связано с ssh. Это нам не потребуется. |
|||
В /etc/redsocks.conf меняем : |
|||
Код: |
|||
ip = 127.0.0.1; |
|||
port = 1098; |
|||
type = socks5; |
|||
на : |
|||
Код: |
|||
ip = proxy.antizapret.prostovpn.org; |
|||
port = 3128; |
|||
type = http-connect; |
|||
В отличие от SSH, TLS хэндшейк теперь пойдет в открытую, то есть DPI его могут высечь из proxy протокола и проверить поле SNI (Server Name Indication). |
|||
Так же могут поступить чуть проще : анализировать IP назначения в методе "CONNECT". |
|||
Однако, практически это вряд ли будут делать. Если и будут, то немногие. |
|||
Но если вы вдруг захотите таким способом проксировать http, то здесь вероятность перехвата и облома очень высока. Многие DPI прекрасно ловят proxy запросы. |
|||
Сначала проверьте работает ли у вас antizapret в предложенном ими варианте : http://antizapret.prostovpn.org |
Loading…
Reference in new issue