shadowsocks-libev как настроить

[Santus]

Поставил шэдоусокс без -libev (ss-local), товарищи, подскажите, а можно в нём на Кинетиках прописать несколько серверов и как-то их чередовать автоматом по доступности, как это реализовано в виндовом клиенте?

Пробовал так в json, не катит:

{

server (первый)

.......

},

{

server (второй)

.......

}

[uneasy]

Мой вариант настройки shadowsocks на кинетике:

opkg install nano ipset iptables shadowsocks-libev-ss-redir

nano /opt/etc/shadowsocks.json

{
    "server":"SERVER",
    "server_port":PORT,
    "password":"PASSWORD",
    "method":"METHOD",
    "mode":"tcp_and_udp",
    "local_address":"0.0.0.0",
    "local_port":1080,
    "timeout":600
}

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep unblock)" ]; then
ipset create unblock hash:net -exist
iptables -I PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1080
iptables -I PREROUTING -w -t nat -i br0 -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1080
until ping -c1 dns.google >/dev/null 2>&1; do :; done
for i in `cat /opt/root/sites`; do
for j in `nslookup $i | grep -v 127.0.0.1 | awk '/Addr/ {print $3}' | grep -v ":"`; do
ipset -exist add unblock $j
done
done
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

nano /opt/root/sites

rutracker.org
flibusta.is
tjournal.ru

 

После перезагрузки должно заработать. Получить пароль и метод из ссылки ss:// можно на сайте base64decode.org или с помощью команды:

echo "ss://URL" | grep -oP "(?<=ss://).*?(?=@)" | base64 -d; echo

 

Edited March 23 by uneasy

[Пихал Метрович]

Добрый день, прошу помощи завсегдатаев форума. Никак не могу завернуть трафик UDP (в частности - DNS-запросы клиентов роутера) на порт локального прокси, поднятый на роутере. Есть сервер ss, поднятый на VDS, tcp-трафик (как исходящий от роутера, так и от клиентов роутера при заходе на заблокированный сайт) без проблем идет через данный сервер. Конфиг ss на роутере:

{
    "server":"XX.XXX.XX.XX",
    "server_port":441,
    "local_address":"0.0.0.0",
    "local_port":1080,
    "password":"пароль",
    "mode":"tcp_and_udp",
    "timeout":86400,
    "method":"chacha20-ietf-poly1305",
    "no_delay":true,
    "reuse_port":true,
    "workers":4
}

В настройках DHCP устанавливаю DNS-сервер для клиентов роутера, как 192.168.1.1 (чтобы UDP-трафик клиентов шел через штатный ndnproxy прошивки). Запускаю данный скрипт на роутере (заблокированные сайты прописаны в файле /opt/root/sites), tcp-трафик заворачивается, доступ к заблокированным сайтам я получаю без проблем:

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep unblock)" ]; then
ipset create unblock hash:net -exist
iptables -I PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1080
iptables -w -t nat -N SS-REDIR_TCP-ROUTER
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d XX.XXX.XX.XX -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -p tcp -j REDIRECT --to-ports 1080
iptables -w -t nat -I OUTPUT -p tcp -j SS-REDIR_TCP-ROUTER
until ping -c1 dns.google >/dev/null 2>&1; do :; done
for i in `cat /opt/root/sites`; do
for j in `nslookup $i | grep -v 127.0.0.1 | awk '/Addr/ {print $3}' | grep -v ":"`; do
ipset -exist add unblock $j
done
done
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks_udp.json -f /opt/var/run/ss-redir.pid
fi
exit 0

Проштудировав тему, пробую вручную завернуть UDP-трафик на 1080 порт ss-прокси роутера (т.к. запросы DNS "летят" на сервер VDS в открытом виде до DNS-сервера AdGuard Home, поднятого на VDS), предварительно отключив сетевые ускорители (через CLI кинетика):

system set net.netfilter.nf_conntrack_fastnat 0
no ppe software
no ppe hardware
system configuration save

Из окружения entware вручную выполняю команды:

ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SSREDIR
iptables -w -t mangle -A SSREDIR -p udp -m set --match-set unblock dst -j RETURN
iptables -w -t mangle -A SSREDIR -p udp -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A SSREDIR -p udp -j MARK --set-mark 1
iptables -w -t mangle -A PREROUTING -p udp -j SSREDIR

Но после ввода данных команд интернет как на роутере, так и на его клиентах отваливается полностью, я не могу загрузить ни одну страницу (даже пинг не работает). Кроме того, как только я подключаю нового клиента по wi-fi, интернет сразу же оживает - таблица mangle перезаписывается с удалением всех, введенных вручную, правил iptables. В связи с этим вопросы:

1. Механизм TPROXY на роутере вообще рабочий?

2. Какой процесс перезаписывает таблицу mangle и как туда правильно добавлять правила iptables, чтобы избежать их дальнейшего удаления?

3. Как все-таки правильно завернуть DNS-запросы как самого роутера, так и клиентов его локальной сети на порт локального прокси ss, поднятого на роутере?

[zyxmon]

25 минут назад, Пихал Метрович сказал:

2. Какой процесс перезаписывает таблицу mangle и как туда правильно добавлять правила iptables, чтобы избежать их дальнейшего удаления?

На форуме было неоднократно - https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmnetfilterd

[Пихал Метрович]

10 минут назад, zyxmon сказал:

На форуме было неоднократно - https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmnetfilterd

Благодарю, а что насчет заворота UDP-трафика через ss-redir? Не могу понять, в чем дело.

[Пихал Метрович]

 Разобрался, как говориться: "сам себе не поможешь - никто не поможет".

1. Если сервер shadowsocks-прокси "поднят" на сервере VDS и вы хотите использовать свой собственный DNS-сервер на VDS (например, AdGuard Home - в этом случае в настройках DHCP беспроводной и/или проводной сети веб-морды роутера должен быть указан "белый" IP сервера VDS) для обработки запросов DNS, исходящих как от самого роутера (например, если вы скачиваете торренты на внешний жесткий диск, подключенный к роутеру, и хотите зашифровать DNS-запросы до трекера, чтобы они были скрыты от провайдера (очень актуально для любых мобильных ОПСОСов)) - в этом случае ошибка "Could not connect to tracker" (не могу соединиться с трекером) не будет появляться - https://help.keenetic.com/hc/ru/articles/360010482519), так и от всех клиентов локальной сети роутера, необходимо на сервере VDS применить следующие правила iptables, касающиеся пропуска трафика udp, приходящего на 53 порт:

iptables -A INPUT -s 127.0.0.1/32 -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -s "белый"_IP_сервера_VDS/32 -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j DROP

Этими правилами мы разрешаем роутеру и всем клиентам его локальной сети доступ к DNS-серверу, "поднятому" на VDS и "слушающему" 53 udp-порт - все DNS-запросы (как отправляемые/получаемые самим роутером, так и всеми клиентами его локальной сети) будут отправляться/получаться через прокси, поднятом на роутере - соответственно, при правильной настройке правил iptables на роутере (см. п. 7), такие запросы/ответы будут зашифрованы. Несмотря на то, что сервер DNS, поднятый на VDS, "торчит" наружу глобальной сети, он не общедоступен - последнее правило iptables отбрасывает любой другой udp-трафик, приходящий на 53 udp-порт, кроме трафика, исходящего как от самого роутера, так и от клиентов его локальной сети (такой трафик все равно проходит через роутер).

2. Если вы используете сторонний, рабочий клиентский конфиг shadowsocks-прокси на роутере, настройки которого выдернуты из ссылки вида ss:// (или свой клиентский конфиг shadowsocks-прокси, а собственного DNS-сервера на VDS у вас нет) - укажите в настройках DHCP беспроводной и/или проводной сети веб-морды роутера любой внешний, общедоступный DNS-сервер, например 8.8.8.8 или 1.1.1.1.

3. Далее ставим opkg на роутер и при помощи opkg устанавливаем следующие пакеты:

opkg install nano ipset iptables shadowsocks-libev-ss-redir wget-ssl simple-obfs lscpu curl

4. Корректируем конфиг shadowsocks-прокси (у меня на сервере VDS и на роутере установлен обфусцирующий (запутывающий) tcp-трафик плагин simple-obfs - этот плагин уже не поддерживается сообществом, но прекрасно работает):

nano /opt/etc/shadowsocks.json

{
    "server":"xx.xxx.xx.xx",
    "server_port":443,
    "local_address":"0.0.0.0",
    "local_port":1080,
    "password":"пароль",
    "mode":"tcp_and_udp",
    "timeout":86400,
    "method":"chacha20-ietf-poly1305",
    "no_delay":true,
    "reuse_port":true,
    "workers":число_ядер_процессора_роутера,
    "plugin":"/opt/bin/obfs-local",
    "plugin_opts":"obfs=tls;obfs-host=yandex.ru"
}

Вместо xx.xxx.xx.xx необходимо вписать "белый" IP сервера VDS; число ядер процессора роутера можно определить командой:

lscpu

5. Если вы используете сторонний, рабочий клиентский конфиг shadowsocks-прокси (вытащив параметры сервера из ссылки вида ss:// на сайте по расшифровке кода формата base64), то в большинстве случаев плагин обфускации в таком конфиге не используется:

{
    "server":"xx.xxx.xx.xx",
    "server_port":PORT,
    "local_address":"0.0.0.0",
    "local_port":1080,
    "password":"пароль",
    "mode":"tcp_and_udp",
    "timeout":86400,
    "method":"METHOD",
    "no_delay":true,
    "reuse_port":true,
    "workers":число_ядер_роутера
}

Вместо xx.xxx.xx.xx необходимо вписать IP сервера shadowsocks-прокси, выдернутый из ссылки ss://.
6. Если вместо плагина simple-obfs вы захотите использовать к примеру, плагин v2ray (естественно, он должен быть скачан на ваш сервер VDS и в серверном конфиге shadowsocks-прокси прописаны его опции), то необходимо, предварительно определив архитектуру процессора, скачать его на роутер и отредактировать конфиг shadowsocks-прокси:

lscpu

в выводе данной команды будет указана архитектура процессора, например, в моем случае - mipsle (le - сокращенно от Little Endian).
6.1. Качаем архив под нашу архитектуру:

wget --no-check-certificate https://github.com/shadowsocks/v2ray-plugin/releases/download/v1.3.2/v2ray-plugin-linux-mips-v1.3.2.tar.gz

6.2. Смотрим, какие файлы присутствуют в архиве:

tar -ztf v2ray-plugin-linux-mips-v1.3.2.tar.gz

6.3. Разархивируем архив (извлекаем только нужный файл плагина):

tar -xvzf v2ray-plugin-linux-mips-v1.3.2.tar.gz v2ray-plugin_linux_mipsle

6.4. Удаляем архив, чтобы он не занимал место во внутренней памяти роутера/на флешке (жестком диске):

rm v2ray-plugin-linux-mips-v1.3.2.tar.gz

6.5. Корректируем конфиг shadowsocks-прокси:

{
    "server":"xx.xxx.xx.xx",
    "server_port":443,
    "local_address":"0.0.0.0",
    "local_port":1080,
    "password":"пароль",
    "mode":"tcp_and_udp",
    "timeout":86400,
    "method":"chacha20-ietf-poly1305",
    "no_delay":true,
    "reuse_port":true,
    "workers":число_ядер_процессора_роутера,
    "plugin":"/opt/root/v2ray-plugin_linux_mipsle"
}

7. Далее создаем файл /opt/etc/ndm/netfilter.d/shadow в одном из 4-х вариантов:
7.1. Заворот всего tcp-трафика на порт локального прокси (поможет при скачивании торрентов встроенной в прошивку роутера торрентокачалкой transmission на внешний жесткий диск/флешку (если ваш провайдер блокирует трафик по протоколу BitTorrent); особенно актуально, если вы используете модем (с сим-картой), вставленный в USB-порт роутера для выхода в интернет), поднятого на роутере, а также DNS-запросов (udp-трафик), исходящих как от клиентов локальной сети роутера, так и от него самого (данный вариант использования приемлем в случае личного сервера shadowsocks-прокси, поднятого на своем VDS; я категорически не рекомендую использовать его для подключения к стороннему серверу по ссылке ss://, ибо неизвестно, что владелец сервера будет делать с вашим трафиком):

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_TCP-CLIENT)" ]; then
iptables -w -t nat -N SS-REDIR_TCP-CLIENT
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.1.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.8.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -p tcp -s 192.168.1.0/24 -j REDIRECT --to-ports 1080
iptables -w -t nat -A PREROUTING -p tcp -j SS-REDIR_TCP-CLIENT
iptables -w -t nat -N SS-REDIR_TCP-ROUTER
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d 127.0.0.1 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -p tcp -j REDIRECT --to-ports 1080
iptables -w -t nat -A OUTPUT -p tcp -j SS-REDIR_TCP-ROUTER
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

Внимание, очень важно! Если ваша локальная сеть роутера не 192.168.1.0/24 (а сеть модема, если вы его используете - не 192.168.8.0/24), исправьте адресацию в соответствующих правилах iptables, в противном случае вы потеряете доступ к роутеру/модему! Перезагружаем роутер (возможно, после перезагрузки придется немного подождать, т.к. механизм TPROXY роутера не сразу срабатывает) и проверяем себя на http://2ip.ru - ваш внешний IP должен измениться. Удостовериться, что IP сменился на самом роутере можно командой:

curl ifconfig.me

Проверить, что DNS-запросы шифруются можно на сервере VDS, открыв веб-морду AdGuard Home - DNS-запросы в журнале (в столбце "Клиент") должны исходить только от 127.0.0.1 (сам роутер и его сервисы) и от "белого" IP VDS (клиенты локальной сети роутера).
Если при данном варианте использования у вас не открываются (или открываются, но не дают просматривать контент) некоторые российские ресурсы (типа кинопоиска, авито, десктопные версии сайтов банков и т.п., которые блокируют доступ с подсетей зарубежных (и многих российских) IP VDS), необходимо определить, на какие IP обращается клиент роутера, вводя в строке браузера доменное имя сайта (это можно сделать, например, установив на роутер DNS-сервер AdGuard Home и в журнале просмотреть DNS-запросы конкретного клиента роутера - CIDR, вводя IP ресурса, можно определить, например, здесь - https://2ip.ru/whois/ или посмотреть в журнал AdGuard Home, поднятом на VDS) и пустить трафик до таких подсетей в обход прокси. В этом случае файл shadow будет выглядеть так (пример для кинопоиска и авито):

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_TCP-CLIENT)" ]; then
iptables -w -t nat -N SS-REDIR_TCP-CLIENT
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.1.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.8.0/24 -j RETURN
#kinopoisk
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 213.180.199.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 77.88.21.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 87.250.250.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 87.250.247.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 213.180.204.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 93.158.134.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 87.250.251.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 178.154.131.0/24 -j RETURN
#avito
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 185.89.12.0/23 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 146.158.48.0/21 -j RETURN
#
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -p tcp -s 192.168.1.0/24 -j REDIRECT --to-ports 1080
iptables -w -t nat -A PREROUTING -p tcp -j SS-REDIR_TCP-CLIENT
iptables -w -t nat -N SS-REDIR_TCP-ROUTER
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d 127.0.0.1 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -p tcp -j REDIRECT --to-ports 1080
iptables -w -t nat -A OUTPUT -p tcp -j SS-REDIR_TCP-ROUTER
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

7.2. Вариант по п. 7.1, но tcp-трафик самого роутера будет идти напрямую, минуя прокси:

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_TCP-CLIENT)" ]; then
iptables -w -t nat -N SS-REDIR_TCP-CLIENT
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.1.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.8.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -p tcp -s 192.168.1.0/24 -j REDIRECT --to-ports 1080
iptables -w -t nat -A PREROUTING -p tcp -j SS-REDIR_TCP-CLIENT
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

7.3. Направляем tcp-трафик клиентов локальной сети роутера на порт локального прокси только до заблокированных роскомнадзором сайтов (сами сайты прописываем в файле /opt/root/sites) - остальной tcp-трафик идет напрямую, минуя прокси; шифруем запросы DNS, отправляя их на порт локального прокси:

nano /opt/root/sites

rutracker.org
flibusta.is

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep unblock)" ]; then
ipset create unblock hash:net -exist
iptables -I PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1080
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
until ping -c1 dns.google >/dev/null 2>&1; do :; done
for i in `cat /opt/root/sites`; do
for j in `nslookup $i | grep -v 127.0.0.1 | awk '/Addr/ {print $3}' | grep -v ":"`; do
ipset -exist add unblock $j
done
done
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

7.4. Вариант по п. 7.3, но tcp-трафик самого роутера будет направлен на порт локльного прокси (к примеру, для скачивания торрентов встроенной в прошивку роутера торрентокачалкой transmission):

nano /opt/root/sites

rutracker.org
flibusta.is

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep unblock)" ]; then
ipset create unblock hash:net -exist
iptables -I PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1080
iptables -w -t nat -N SS-REDIR_TCP-ROUTER
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d 127.0.0.1 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -p tcp -j REDIRECT --to-ports 1080
iptables -w -t nat -I OUTPUT -p tcp -j SS-REDIR_TCP-ROUTER
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
until ping -c1 dns.google >/dev/null 2>&1; do :; done
for i in `cat /opt/root/sites`; do
for j in `nslookup $i | grep -v 127.0.0.1 | awk '/Addr/ {print $3}' | grep -v ":"`; do
ipset -exist add unblock $j
done
done
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

P.S. Отключать FastNAT (hwnat) не нужно, правила iptables для заворота DNS-трафика на порт локального прокси роутера через механизм TPROXY ядра работают без отключения. 

Edited February 24 by Пихал Метрович

[Romanvs777]

Добрый день. Как прикрутить клиент в Keenetic:

SERVER
"server":"127.0.0.1"
,"server_port":10000
,"password":"12345678"
,"timeout":50
,"method":"aes-256-gcm"
,"fast_open": true
,"reuse_port": true
,"mode": "tcp_only"
,"nameserver": "8.8.8.8"
,"plugin": "ss-v2ray-plugin"
,"plugin_opts": "server;path=/proxy"
}
CLIENT
ss-local -f /tmp/ss-local.pid -c ~/.config/shadowsocks/config.json &
~/.config/shadowsocks/config.json:
{
"server":"109.107.177.183"
,"server_port":443
,"local_port":1080
,"password":"12345678"
,"timeout":10
,"method":"aes-256-gcm"
,"plugin": "ss-v2ray-plugin"
,"plugin_opts": "tls;fast-open;path=/proxy;host=mydns133.ddns.net"
}

[Пихал Метрович]

2 часа назад, Romanvs777 сказал:

SERVER
"server":"127.0.0.1"

Сервер ss "висит" только на интерфейсе обратной петли lo - это плохо, т.к. ни на какие запросы, кроме исходящих от самого сервера, где развернут сервер ss, он отвечать не будет. Повесьте его на все сетевые интерфейсы - "server":"0.0.0.0"

2 часа назад, Romanvs777 сказал:

"plugin_opts": "tls;fast-open;path=/proxy;host=mydns133.ddns.net"

Без реального ssl-сертификата в режиме websocket-tls плагин v2ray работать не будет; если вы хотите проверить работу плагина без сертификата - используйте режим websocket-http, в этом случае никакие опции плагина на клиенте использовать не нужно - достаточно в строке "plugin" указать полный путь до исполняемого файла плагина.

 

Edited March 11 by Пихал Метрович

[Пихал Метрович]

2 часа назад, Romanvs777 сказал:

"server_port":10000

 

2 часа назад, Romanvs777 сказал:

"server_port":443

Порты должны совпадать.

[Romanvs777]

Настройка серверной части как присылал. Настройка клиентской части в приложении Shadowsocks, установлено на windows: 

[Romanvs777]

Только что, Romanvs777 сказал:

Настройка серверной части как присылал. Настройка клиентской части в приложении Shadowsocks, установлено на windows: 

как присылал. 

Настройка в SwitchyOmega:

Protocol SOCKS5 

Server 127.0.0.1

Port 1080.

Все работает, на 2ip проверку анонимности проходит полностью.

Хочется чтобы не через приложение включать обход блокировок, но установить на роутер, для пользования в домашней сети на всех устройствах.

долгий процесс настройки тут.

Буду признателен энтузиастам за помощь. Спасибо.

 

 

shadowsocks_prezentacia.pdf

[Пихал Метрович]

1 час назад, Romanvs777 сказал:

Хочется чтобы не через приложение включать обход блокировок, но установить на роутер, для пользования в домашней сети на всех устройствах.

 

Через opkg установите пакет shadowsocks-libev-ss-redir и настройте запуск ss-redir (вместо ss-local) через один из скриптов - 

по п. 7 - при правильной настройке правил iptables вы сможете не только отправлять на свой сервер tcp-трафик (который будет обрабатываться плагином v2ray), но и DNS-запросы (udp) до своего DNS-резольвера (которые будут обрабатываться непосредственно самим ss, без участия плагина обфускации). 

Edited March 11 by Пихал Метрович

[Romanvs777]

В 19.02.2023 в 08:42, Пихал Метрович сказал:

 Разобрался, как говориться: "сам себе не поможешь - никто не поможет".

1. Если сервер shadowsocks-прокси "поднят" на сервере VDS и вы хотите использовать свой собственный DNS-сервер на VDS (например, AdGuard Home - в этом случае в настройках DHCP беспроводной и/или проводной сети веб-морды роутера должен быть указан "белый" IP сервера VDS) для обработки запросов DNS, исходящих как от самого роутера (например, если вы скачиваете торренты на внешний жесткий диск, подключенный к роутеру, и хотите зашифровать DNS-запросы до трекера, чтобы они были скрыты от провайдера (очень актуально для любых мобильных ОПСОСов)) - в этом случае ошибка "Could not connect to tracker" (не могу соединиться с трекером) не будет появляться - https://help.keenetic.com/hc/ru/articles/360010482519), так и от всех клиентов локальной сети роутера, необходимо на сервере VDS применить следующие правила iptables, касающиеся пропуска трафика udp, приходящего на 53 порт:

iptables -A INPUT -s 127.0.0.1/32 -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -s "белый"_IP_сервера_VDS/32 -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j DROP

Этими правилами мы разрешаем роутеру и всем клиентам его локальной сети доступ к DNS-серверу, "поднятому" на VDS и "слушающему" 53 udp-порт - все DNS-запросы (как отправляемые/получаемые самим роутером, так и всеми клиентами его локальной сети) будут отправляться/получаться через прокси, поднятом на роутере - соответственно, при правильной настройке правил iptables на роутере (см. п. 7), такие запросы/ответы будут зашифрованы. Несмотря на то, что сервер DNS, поднятый на VDS, "торчит" наружу глобальной сети, он не общедоступен - последнее правило iptables отбрасывает любой другой udp-трафик, приходящий на 53 udp-порт, кроме трафика, исходящего как от самого роутера, так и от клиентов его локальной сети (такой трафик все равно проходит через роутер).

2. Если вы используете сторонний, рабочий клиентский конфиг shadowsocks-прокси на роутере, настройки которого выдернуты из ссылки вида ss:// (или свой клиентский конфиг shadowsocks-прокси, а собственного DNS-сервера на VDS у вас нет) - укажите в настройках DHCP беспроводной и/или проводной сети веб-морды роутера любой внешний, общедоступный DNS-сервер, например 8.8.8.8 или 1.1.1.1.

3. Далее ставим opkg на роутер и при помощи opkg устанавливаем следующие пакеты:

opkg install nano ipset iptables shadowsocks-libev-ss-redir wget-ssl simple-obfs lscpu curl

4. Корректируем конфиг shadowsocks-прокси (у меня на сервере VDS и на роутере установлен обфусцирующий (запутывающий) tcp-трафик плагин simple-obfs - этот плагин уже не поддерживается сообществом, но прекрасно работает):

nano /opt/etc/shadowsocks.json

{
    "server":"xx.xxx.xx.xx",
    "server_port":443,
    "local_address":"0.0.0.0",
    "local_port":1080,
    "password":"пароль",
    "mode":"tcp_and_udp",
    "timeout":86400,
    "method":"chacha20-ietf-poly1305",
    "no_delay":true,
    "reuse_port":true,
    "workers":число_ядер_процессора_роутера,
    "plugin":"/opt/bin/obfs-local",
    "plugin_opts":"obfs=tls;obfs-host=yandex.ru"
}

Вместо xx.xxx.xx.xx необходимо вписать "белый" IP сервера VDS; число ядер процессора роутера можно определить командой:

lscpu

5. Если вы используете сторонний, рабочий клиентский конфиг shadowsocks-прокси (вытащив параметры сервера из ссылки вида ss:// на сайте по расшифровке кода формата base64), то в большинстве случаев плагин обфускации в таком конфиге не используется:

{
    "server":"xx.xxx.xx.xx",
    "server_port":PORT,
    "local_address":"0.0.0.0",
    "local_port":1080,
    "password":"пароль",
    "mode":"tcp_and_udp",
    "timeout":86400,
    "method":"METHOD",
    "no_delay":true,
    "reuse_port":true,
    "workers":число_ядер_роутера
}

Вместо xx.xxx.xx.xx необходимо вписать IP сервера shadowsocks-прокси, выдернутый из ссылки ss://.
6. Если вместо плагина simple-obfs вы захотите использовать к примеру, плагин v2ray (естественно, он должен быть скачан на ваш сервер VDS и в серверном конфиге shadowsocks-прокси прописаны его опции), то необходимо, предварительно определив архитектуру процессора, скачать его на роутер и отредактировать конфиг shadowsocks-прокси:

lscpu

в выводе данной команды будет указана архитектура процессора, например, в моем случае - mipsle (le - сокращенно от Little Endian).
6.1. Качаем архив под нашу архитектуру:

wget --no-check-certificate https://github.com/shadowsocks/v2ray-plugin/releases/download/v1.3.2/v2ray-plugin-linux-mips-v1.3.2.tar.gz

6.2. Смотрим, какие файлы присутствуют в архиве:

tar -ztf v2ray-plugin-linux-mips-v1.3.2.tar.gz

6.3. Разархивируем архив (извлекаем только нужный файл плагина):

tar -xvzf v2ray-plugin-linux-mips-v1.3.2.tar.gz v2ray-plugin_linux_mipsle

6.4. Удаляем архив, чтобы он не занимал место во внутренней памяти роутера/на флешке (жестком диске):

rm v2ray-plugin-linux-mips-v1.3.2.tar.gz

6.5. Корректируем конфиг shadowsocks-прокси:

{
    "server":"xx.xxx.xx.xx",
    "server_port":443,
    "local_address":"0.0.0.0",
    "local_port":1080,
    "password":"пароль",
    "mode":"tcp_and_udp",
    "timeout":86400,
    "method":"chacha20-ietf-poly1305",
    "no_delay":true,
    "reuse_port":true,
    "workers":число_ядер_процессора_роутера,
    "plugin":"/opt/root/v2ray-plugin_linux_mipsle"
}

7. Далее создаем файл /opt/etc/ndm/netfilter.d/shadow в одном из 4-х вариантов:
7.1. Заворот всего tcp-трафика на порт локального прокси (поможет при скачивании торрентов встроенной в прошивку роутера торрентокачалкой transmission на внешний жесткий диск/флешку (если ваш провайдер блокирует трафик по протоколу BitTorrent); особенно актуально, если вы используете модем (с сим-картой), вставленный в USB-порт роутера для выхода в интернет), поднятого на роутере, а также DNS-запросов (udp-трафик), исходящих как от клиентов локальной сети роутера, так и от него самого (данный вариант использования приемлем в случае личного сервера shadowsocks-прокси, поднятого на своем VDS; я категорически не рекомендую использовать его для подключения к стороннему серверу по ссылке ss://, ибо неизвестно, что владелец сервера будет делать с вашим трафиком):

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_TCP-CLIENT)" ]; then
iptables -w -t nat -N SS-REDIR_TCP-CLIENT
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.1.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.8.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -p tcp -s 192.168.1.0/24 -j REDIRECT --to-ports 1080
iptables -w -t nat -A PREROUTING -p tcp -j SS-REDIR_TCP-CLIENT
iptables -w -t nat -N SS-REDIR_TCP-ROUTER
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d 127.0.0.1 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -p tcp -j REDIRECT --to-ports 1080
iptables -w -t nat -A OUTPUT -p tcp -j SS-REDIR_TCP-ROUTER
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

Внимание, очень важно! Если ваша локальная сеть роутера не 192.168.1.0/24 (а сеть модема, если вы его используете - не 192.168.8.0/24), исправьте адресацию в соответствующих правилах iptables, в противном случае вы потеряете доступ к роутеру/модему! Перезагружаем роутер (возможно, после перезагрузки придется немного подождать, т.к. механизм TPROXY роутера не сразу срабатывает) и проверяем себя на http://2ip.ru - ваш внешний IP должен измениться. Удостовериться, что IP сменился на самом роутере можно командой:

curl ifconfig.me

Проверить, что DNS-запросы шифруются можно на сервере VDS, открыв веб-морду AdGuard Home - DNS-запросы в журнале (в столбце "Клиент") должны исходить только от 127.0.0.1 (сам роутер и его сервисы) и от "белого" IP VDS (клиенты локальной сети роутера).
Если при данном варианте использования у вас не открываются (или открываются, но не дают просматривать контент) некоторые российские ресурсы (типа кинопоиска, авито, десктопные версии сайтов банков и т.п., которые блокируют доступ с подсетей зарубежных (и многих российских) IP VDS), необходимо определить, на какие IP обращается клиент роутера, вводя в строке браузера доменное имя сайта (это можно сделать, например, установив на роутер DNS-сервер AdGuard Home и в журнале просмотреть DNS-запросы конкретного клиента роутера - CIDR, вводя IP ресурса, можно определить, например, здесь - https://2ip.ru/whois/ или посмотреть в журнал AdGuard Home, поднятом на VDS) и пустить трафик до таких подсетей в обход прокси. В этом случае файл shadow будет выглядеть так (пример для кинопоиска и авито):

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_TCP-CLIENT)" ]; then
iptables -w -t nat -N SS-REDIR_TCP-CLIENT
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.1.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.8.0/24 -j RETURN
#kinopoisk
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 213.180.199.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 77.88.21.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 87.250.250.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 87.250.247.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 213.180.204.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 93.158.134.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 87.250.251.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 178.154.131.0/24 -j RETURN
#avito
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 185.89.12.0/23 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 146.158.48.0/21 -j RETURN
#
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -p tcp -s 192.168.1.0/24 -j REDIRECT --to-ports 1080
iptables -w -t nat -A PREROUTING -p tcp -j SS-REDIR_TCP-CLIENT
iptables -w -t nat -N SS-REDIR_TCP-ROUTER
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d 127.0.0.1 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -p tcp -j REDIRECT --to-ports 1080
iptables -w -t nat -A OUTPUT -p tcp -j SS-REDIR_TCP-ROUTER
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

7.2. Вариант по п. 7.1, но tcp-трафик самого роутера будет идти напрямую, минуя прокси:

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_TCP-CLIENT)" ]; then
iptables -w -t nat -N SS-REDIR_TCP-CLIENT
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.1.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -d 192.168.8.0/24 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-CLIENT -p tcp -s 192.168.1.0/24 -j REDIRECT --to-ports 1080
iptables -w -t nat -A PREROUTING -p tcp -j SS-REDIR_TCP-CLIENT
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

7.3. Направляем tcp-трафик клиентов локальной сети роутера на порт локального прокси только до заблокированных роскомнадзором сайтов (сами сайты прописываем в файле /opt/root/sites) - остальной tcp-трафик идет напрямую, минуя прокси; шифруем запросы DNS, отправляя их на порт локального прокси:

nano /opt/root/sites

rutracker.org
flibusta.is

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep unblock)" ]; then
ipset create unblock hash:net -exist
iptables -I PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1080
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
until ping -c1 dns.google >/dev/null 2>&1; do :; done
for i in `cat /opt/root/sites`; do
for j in `nslookup $i | grep -v 127.0.0.1 | awk '/Addr/ {print $3}' | grep -v ":"`; do
ipset -exist add unblock $j
done
done
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

7.4. Вариант по п. 7.3, но tcp-трафик самого роутера будет направлен на порт локльного прокси (к примеру, для скачивания торрентов встроенной в прошивку роутера торрентокачалкой transmission):

nano /opt/root/sites

rutracker.org
flibusta.is

nano /opt/etc/ndm/netfilter.d/shadow

#!/bin/sh
if [ -z "$(iptables-save 2>/dev/null | grep unblock)" ]; then
ipset create unblock hash:net -exist
iptables -I PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1080
iptables -w -t nat -N SS-REDIR_TCP-ROUTER
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d xx.xxx.xx.xx -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d 127.0.0.1 -j RETURN
iptables -w -t nat -A SS-REDIR_TCP-ROUTER -p tcp -j REDIRECT --to-ports 1080
iptables -w -t nat -I OUTPUT -p tcp -j SS-REDIR_TCP-ROUTER
fi
if [ -z "$(ip route list table 100)" ]; then
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
fi
if [ -z "$(iptables-save 2>/dev/null | grep SS-REDIR_UDP)" ]; then
insmod /lib/modules/$(uname -r)/xt_TPROXY.ko
iptables -w -t mangle -N SS-REDIR_UDP
iptables -w -t mangle -A SS-REDIR_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -w -t mangle -A PREROUTING -p udp -j SS-REDIR_UDP
until ping -c1 dns.google >/dev/null 2>&1; do :; done
for i in `cat /opt/root/sites`; do
for j in `nslookup $i | grep -v 127.0.0.1 | awk '/Addr/ {print $3}' | grep -v ":"`; do
ipset -exist add unblock $j
done
done
fi
if [ -z "$(ps | grep -v grep | grep ss-redir)" ]; then
ss-redir -u -c /opt/etc/shadowsocks.json -f /opt/var/run/ss-redir.pid
fi
exit 0

P.S. Отключать FastNAT (hwnat) не нужно, правила iptables для заворота DNS-трафика на порт локального прокси роутера через механизм TPROXY ядра работают без отключения. 

Подскажите пожалуйста "iptables -w -t nat -A SS-REDIR_TCP-ROUTER -d xx.xxx.xx.xx -j RETURN" xx.xxx.xx.xx  это адрес роутера 192.168.1.1 и нужно его приписывать в формате 192.168.1.1/24

[Пихал Метрович]

13 минуты назад, Romanvs777 сказал:

xx.xxx.xx.xx  это адрес роутера 192.168.1.1

Нет, это IP сервера VDS, где поднят ваш сервер ss.

Edited March 11 by Пихал Метрович

[Romanvs777]

Установил ss соединение через КВАС, отредактировал shadowsocks.json 

"server": "X.X.X.X",
  "server_port": 443,
  "local_port": 1080,
  "password": "password",
  "method": "aes-256-gcm",
  "timeout": 86400,
  "local_address": "::",
  "dns_ipv6": false,
  "fast_open": false,
  "plugin":"/opt/root/v2ray-plugin_linux_mipsle",
  "plugin_opts": "tls;fast-open;path=/proxy;host=domen.net"

отредактировал kvas.conf

SSR_DNS_PORT=1181 на порт 1080

соединение установилось

Но такой вопрос, когда устанавливаешь соединение через КВАС SS, то проверка анонимности через 2ip определяет реальный IP. Если подключаешься через программу SS (установлено на windows) + SwitchyOmega (Protocol SOCKS5, Server 127.0.0.1, Port 1080) на 2ip проверку анонимности проходит полностью, как исправить, чтобы через КВАС тоже анонимность была?

 

 

[Пихал Метрович]

11 час назад, Romanvs777 сказал:

Но такой вопрос, когда устанавливаешь соединение через КВАС SS, то проверка анонимности через 2ip определяет реальный IP.

Значит, трафик не идет через прокси, поднятый на роутере, а в обход прокси.

Edited March 12 by Пихал Метрович

[Romanvs777]

1 час назад, Пихал Метрович сказал:

Значит, трафик не идет через прокси, поднятый на роутере, а в обход прокси.

Добрый день. Я так понял Вы как раз и боролись с заворачиванием трафика и нужно по Вашей методике делать. Утечка  может быть связана с DNS? У меня adh настроен через КВАС.

[Пихал Метрович]

12 минуты назад, Romanvs777 сказал:

Утечка  может быть связана с DNS?

Служба DNS никак не связана с shadowsocks-прокси - вы лишь можете заставить DNS-запросы, исходящие как от самого роутера, так и от клиентов его локальной сети, заворачиваться на порт клиента ss-прокси, поднятого на роутере через механизм TPROXY ядра Linux операционной системы роутера - в этом случае, DNS-запросы будут зашифрованы.

[Romanvs777]

В 12.03.2023 в 08:42, Пихал Метрович сказал:

Значит, трафик не идет через прокси, поднятый на роутере, а в обход прокси.

Добрый день. Поделитесь какие пакеты на keenetic установлены.

[Пихал Метрович]

В 19.02.2023 в 08:42, Пихал Метрович сказал:

ipset iptables shadowsocks-libev-ss-redir wget-ssl lscpu curl

 

Вот все, что вам нужно, чтобы запустить ss-redir (с полным или частичным заворотом tcp-трафика, а также DNS-запросов). Если вы используете v2ray-plugin, нужно и его скачать с гитхаба, разархивировать архив и указать в конфиге ss путь до исполняемого файла плагина. Пакеты установлены через opkg, никакие дополнительные пакеты ставить не нужно.

[uneasy]

On 2/19/2023 at 8:42 AM, Пихал Метрович said:

6. Если вместо плагина simple-obfs вы захотите использовать к примеру, плагин v2ray (естественно, он должен быть скачан на ваш сервер VDS и в серверном конфиге shadowsocks-прокси прописаны его опции), то необходимо, предварительно определив архитектуру процессора, скачать его на роутер и отредактировать конфиг shadowsocks-прокси:

Спасибо за гайд по плагину v2ray! Единственный минус - он не поддерживает vmess и trojan, в entware для этого есть отдельные пакеты (opkg install v2ray trojan), но гайда по ним не нашел (если не считать гайды на китайском). Если как-нибудь будете настраивать, поделитесь?

[Пихал Метрович]

7 часов назад, uneasy сказал:

Если как-нибудь будете настраивать, поделитесь?

Обязательно, как сам разберусь - кое-какая информация по настройке полноценного v2ray (Project V) есть здесь - 

Кратко - для прозрачного проксирования нужно использовать протокол Dokodemo-door - https://www.v2ray.com/ru/configuration/protocols/dokodemo.html

[uneasy]

15 hours ago, Пихал Метрович said:

Dokodemo-door

Вот кстати еще по вашей ссылке хороший гайд нашел (хотя все равно заморочено):

https://guide.v2fly.org/en_US/app/transparent_proxy.html

Кстати, я свой скрипт переделал, надоело мучаться с DNS - сейчас новые сайты блокируют каждый день, да и часто одного domain.com для обхода недостаточно. Решил перейти на списки блокированных IP:

#!/bin/sh
ipset create unblock hash:net
wget -O /opt/root/allyouneed.lst https://antifilter.download/list/allyouneed.lst
for i in `cat /opt/root/allyouneed.lst`; do ipset add unblock $i; done

Только такое пихать в /opt/etc/ndm/netfilter.d/shadow нельзя, лучше запускать вместе с роутером - /opt/etc/init.d/S52ipset или cron'ом

Если туннель на момент запуска скрипта уже поднят, можно еще добавить строчку

for j in `nslookup antifilter.download | grep -v 127.0.0.1 | awk '/Addr/ {print $3}' | grep -v ":"`; do ipset add unblock $j; done

чтобы закачка файла allyouneed.lst тоже шла через туннель, не светиться им у провайдера.

Edited March 15 by uneasy

[Пихал Метрович]

1 час назад, uneasy сказал:

Кстати, я свой скрипт переделал, надоело мучаться с DNS - сейчас новые сайты блокируют каждый день, да и часто одного domain.com для обхода недостаточно.

А зачем с ним мучится? Отправляйте все DNS-запросы через механизм TPROXY ядра операционной системы роутера до своего сервера VDS, на котором "поднят" сервер DNS. Вы же не на все заблокированные сайты заходите, добавьте всю пачку в /opt/root/sites, да и дело с концом.

Или коренной способ - отправлять весь трафик через прокси до VDS, арендованного за бугром (или в российском дата-центре, до которого пока не добрался роскомнадзор).

Edited March 15 by Пихал Метрович

[uneasy]

30 minutes ago, Пихал Метрович said:

Вы же не на все заблокированные сайты заходите

Ну, как я и сказал, сейчас сайты блочат направо и налево, поэтому править /opt/root/sites приходится постоянно, что уже поднадоело. Плюс далеко не всегда это работает - добавляешь какой-нибудь strava.com, а у них еще сервера на AWS'е в миллионе подсетей, не работает все равно. IP списки решают проблему раз и навсегда.

Отправлять весь трафик тоже не вариант, поскольку некоторые российские сайты уже ставят блок на забугорные IP. Ну и вообще гонять лишний трафик через туннель не хочется. Там и торренты и что только не.

PS Кстати, в моем скрипте выше я не использовал TPROXY, просто отдельно на роутере DoH включил, чтобы не светиться запросами. В этом случае, даже если туннель упадет, DNS будет работоспособен.

[Пихал Метрович]

6 часов назад, uneasy сказал:

PS Кстати, в моем скрипте выше я не использовал TPROXY, просто отдельно на роутере DoH включил, чтобы не светиться запросами. В этом случае, даже если туннель упадет, DNS будет работоспособен.

Да, в этом случае проблема с DNS-запросами клиентов локальной сети роутера решается, а как быть с самим роутером (его службами), например, torrent-клиентом transmission, который качает торренты на внешний жесткий диск, подключенный к роутеру и постоянно обращается к трекеру по udp? Насколько я понимаю, установка внешних DNS-серверов, поддерживающих шифрование, из веб-морды роутера работает только для клиентов его локальной сети, а не для него самого, или нет?

6 часов назад, uneasy сказал:

В этом случае, даже если туннель упадет, DNS будет работоспособен.

Если соединение (не тоннель, shadowsocks-прокси - это не VPN, отдельного тоннельного интерфейса он не создает) с сервером ss пропадет (за всю трехгодовую практику использования ss у меня такого не было ни разу; считаем, что все правила iptables удалились вместе с процессом ss), DNS для клиентов локальной сети роутера (и для его самого) будет также доступен - вы же как для роутера, так и для клиентов его локальной сети указали внешний IP вашего сервера VDS, где "поднят" сервер DNS - в этом случае DNS-запросы пойдут на сервер, но будут незашифрованы.

Edited March 15 by Пихал Метрович

[uneasy]

16 hours ago, Пихал Метрович said:

установка внешних DNS-серверов, поддерживающих шифрование, из веб-морды роутера работает только для клиентов его локальной сети, а не для него самого, или нет?

Нет, для него самого тоже работает. Можно проверить например на адресе api.tmdb.org - сами владельцы сайта сделали блокировку для России, но на уровне DNS. При этом Quad9 к этим блокировкам не присоединился. Соответственно можете сравнить вывод команд на роутере до и после настройки DoH, при использовании URL сервера DNS - https://dns.quad9.net/dns-query

nslookup api.tmdb.org 1.1.1.1
nslookup api.tmdb.org 8.8.8.8
nslookup api.tmdb.org 9.9.9.9
nslookup api.tmdb.org

Первая и вторая команда выдадут неправильный IP, третья правильный, четвертая в зависимости от настройки роутера

16 hours ago, Пихал Метрович said:

не тоннель, shadowsocks-прокси - это не VPN

SS конечно не VPN, но тоннелем для простоты называют любую инкапсуляцию, например - SSH tunnel, который тоже VPNом не является

16 hours ago, Пихал Метрович said:

в этом случае DNS-запросы пойдут на сервер, но будут незашифрованы.

Да, в этом случае запросы будут видны провайдеру (и товарищу майору). Плюс он может их перехватывать и подменять. И еще один момент - лично у меня нет собственного VDS, пользуюсь общедоступными "носками", поэтому падения серверов случаются регулярно.

Я знаю, что вы против такой схемы, но пока речь шла буквально о десятке новостных сайтов (без фейсбуков итд), в принципе терпимо. А кардинально проблему приватности можно решить, пустив внутри SS туннеля еще и VPN туннель к общедоступному провайдеру VPN, типа Proton, им доверия больше. У меня сейчас как раз такая схема реализована, правда для Wireguard - поднят туннель с WARP, а внутри него туннель с Proton (это сделано для того, чтобы обходить западные блоки, так как WARP сам по себе предоставляет российский IP). Работает все это на удивление быстро, правда это Wireguard, известный своей скоростью, как будет с SS сложно сказать

Edited March 16 by uneasy

[uneasy]

Кстати, сейчас заметил, что я в начале своего скрипта /opt/etc/ndm/netfilter.d/shadow совершенно напрасно не добавил проверку на тип таблицы:

[ "$type" == "ip6tables" ] && exit 0
[ "$table" != "nat" ] && exit 0

Исправил, потому что из-за этого могут создаваться дубликаты правил.

[Пихал Метрович]

В 20.03.2023 в 13:51, uneasy сказал:

[ "$type" == "ip6tables" ] && exit 0
[ "$table" != "nat" ] && exit 0

Не работатет скрипт, правила iptables просто тупо не создаются после перезагрузки, в том числе, если и DNS-запросы на прокси заворачивать (дополнительно добавлял строку [ "$table" != "mangle" ] && exit 0).

В 20.03.2023 в 13:51, uneasy сказал:

Исправил, потому что из-за этого могут создаваться дубликаты правил.

Правила без вышеуказанных строк не дублируются, проверял много раз.

[vasek00]

2 часа назад, Пихал Метрович сказал:

Не работатет скрипт, правила iptables просто тупо не создаются после перезагрузки

А почему должны создаваться, используйте скрипт в /opt/etc/init.d для их cозданияю Далее после создания они будут проверяться по вашему скрипту в ndm.