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

Будьте добры, скиньте пожалуйста. На гитхабе уже версия 9.2

Доброго времени суток, а можно ли как-то добавить не домен, а несколько подсетей (в дополнение к списку antifilter, которые с ними не пересекаются), трафик на IP которых должен идти через прокси? Видео с телеги долго грузится, заворачиваешь весь трафик клиентов роутера на прокси - загрузка происходит раз в 10 быстрее, видимо, мобильный провайдер подрезает скорость, а весь трафик не хочется заворачивать.

Пришлите пароль ss в личку - попробую протестировать.

А файл клиента ss /opt/etc/shadowsocks.json заполнен верно (IP сервера, порт, метод шифрования, пароль)? К какому серверу ss вы пытаетесь приконнектиться - к своему, поднятому на VDS, или найденному в глобальной сети? Вы проверили, что сервер доступен и отвечает на запросы (это можно сделать из клиента ss под Android)?

На роутере запускали (через ss-redir) или на linux-клиенте (ss-tunnel)?

Можно так, например - https://lore.kernel.org/wireguard/CAMwURuCj4O2rik1kWeA22x7ovHxfGNTEyk_aNsTwc9yYbihvbw@mail.gmail.com/T/, как-то давно настраивал и это даже работало. Да, можно, настройки по созданию тоннельного интерфейса есть, но это не полноценная замена тоннелю VPN (хотя маршрутизация в отношении оного должна работать), некоторыми функциями все равно невозможно будет воспользоваться - https://ntc.party/t/topic/1425/3 "Все технологии туннелирования так или иначе строятся на двух принципах: VPN: пакетная передача данных, ПО создаёт отдельный сетевой интерфейс (L2/L3), возможность использования стандартных способов маршрутизации, передачи любых протоколов и приёма входящих соединений; Прокси: потоковая передача данных, ПО создаёт отдельный TCP/UDP-порт, возможность передачи только TCP/UDP-трафика, невозможность (в общем случае) приёма входящих соединений. Через прокси у вас не будет работать ping (протокол ICMP), а голосовая связь VoIP (и другие p2p-программы) может работать плохо или не работать вовсе, из-за невозможности входящих подключений. Тем не менее, для большинства обычных программ функциональности прокси вполне достаточно. Нередко прокси-программы эмулируют VPN-интерфейс для удобства настройки или из-за технических ограничений – не каждая программа поддерживает работу через прокси, а VPN-интерфейс настраивается на уровне операционной системы и не требует ничего от программ. Эмуляция VPN-интерфейса не добавляет недостающих функций прокси – вы всё ещё не сможете пользоваться ping, принимать входящие соединения."

Спасибо за скрипт, все работает отлично, заблокированные сайты открываются. Это правило работать не будет, трафик udp можно затолкать на порт локального прокси только через механизм TPROXY iptables (пример куска скрипта ниже - для DNS-запросов как клиентов локальной сети роутера, так и его самого; для роутера и для его клиентов локальной сети нужно в настройках DHCP установить любой внешний обычный DNS-сервер без шифрования, типа 1.1.1.1, 8.8.8.8 и т.п.): 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 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 Кстати, shadowsocks-rust, собранный под архитектуру mips, нормально работает на сабже (запускал вместе с плагином обфускации трафика simle-tls, собранного также под mips-архитектуру; архивы бинарников можно скачать на гитхабе). Команда на запуск transparent proxy (редирект tcp и udp-трафика (DNS-запросы)): sslocal --local-addr 0.0.0.0:1080 --protocol redir --tcp-redir redirect --udp-redir tproxy -d -U -c /opt/etc/shadowsocks/shadowsocks.json Загрузка процессора конечно выше, чем в случае shadowsocks-libev, но жить можно, каких-то сильных тормозов не заметил (даже в случае скачки торрентов на внешний жесткий диск встроенным торрент-клиентом роутера).

Можете выложить весь скрипт? Кстати, если вашем текущем скрипте удалить строку: то я теряю доступ к веб-морде роутера (роутер работает, но перестает отвечать на запросы), я так понимаю, что это просто проверка доступности интернета. Вопрос - как эту строку выпилить правильно?

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

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

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

Обязательно, как сам разберусь - кое-какая информация по настройке полноценного v2ray (Project V) есть здесь - Кратко - для прозрачного проксирования нужно использовать протокол Dokodemo-door - https://www.v2ray.com/ru/configuration/protocols/dokodemo.html

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

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

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

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

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

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

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

Разобрался, как говориться: "сам себе не поможешь - никто не поможет". 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 ядра работают без отключения.

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

Добрый день, прошу помощи завсегдатаев форума. Никак не могу завернуть трафик 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, поднятого на роутере?