diff --git a/binaries/armhf/nfqws b/binaries/armhf/nfqws
new file mode 100644
index 0000000..86c1f04
Binary files /dev/null and b/binaries/armhf/nfqws differ
diff --git a/binaries/armhf/redsocks-0.4-62.tgz b/binaries/armhf/redsocks-0.4-62.tgz
new file mode 100644
index 0000000..ee9459f
Binary files /dev/null and b/binaries/armhf/redsocks-0.4-62.tgz differ
diff --git a/binaries/armhf/tpws b/binaries/armhf/tpws
new file mode 100644
index 0000000..948dce5
Binary files /dev/null and b/binaries/armhf/tpws differ
diff --git a/binaries/mips32r2/nfqws b/binaries/mips32r2/nfqws
new file mode 100644
index 0000000..8d7afd2
Binary files /dev/null and b/binaries/mips32r2/nfqws differ
diff --git a/binaries/mips32r2/redsocks-0.4-62.tgz b/binaries/mips32r2/redsocks-0.4-62.tgz
new file mode 100644
index 0000000..da76bd0
Binary files /dev/null and b/binaries/mips32r2/redsocks-0.4-62.tgz differ
diff --git a/binaries/mips32r2/tpws b/binaries/mips32r2/tpws
new file mode 100644
index 0000000..5d32d0f
Binary files /dev/null and b/binaries/mips32r2/tpws differ
diff --git a/https.txt b/https.txt
new file mode 100644
index 0000000..f3fca03
--- /dev/null
+++ b/https.txt
@@ -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