OpenWrt настройка tun2socks

Openwrt

Глянуть архитектуру процессора на вашем роутере

opkg print-architecture

Скачиваем архив с нужной архитектурой на компьютер, разархивируем и перекидываем на роутер в /tmp.

wget https://github.com/xjasonlyu/tun2socks/releases/download/v2.5.1/tun2socks-под-нужную-архитектуру.zip
unzip tun2socks-под-нужную-архитектуру.zip
scp tun2socks-под-нужную-архитектуру root@192.168.1.1:/tmp/

После этого заходим на роутер и проверяем, что точно скачали подходящий под вашу архитектуру бинарник

root@OpenWrt:~# /tmp/tun2socks-linux-mipsle-softfloat --help
Usage of ./tun2socks-linux-mipsle-softfloat:
  -config string

Help вывелся, значит, всё ок. Но если выводится такая ошибка

/tmp/tun2socks-linux-mips-softfloat: line 1: syntax error: unexpected "("

значит, архитектура выбрана неверно.

Перекидываем в /usr/bin/ и заодно переименовываем

mv tun2socks-linux-mipsle-softfloat /usr/bin/tun2socks

Для работы tun интерфейса понадобится пакет kmod-tun

opkg update && opkg install kmod-tun

Настройка интерфейса и firewall

tun2socks не создаёт интерфейс сам, поэтому нужно самим создать интерфейс и присвоить ему ip.
Добавляем в /etc/config/network

config interface 'tun0'
        option device 'tun0'
        option proto 'static'
        option ipaddr '172.16.250.1'
        option netmask '255.255.255.0'

Имейте в виду, что ip a покажет его только при запуске tun2socks.

Учтите, что если у вас настроен какой-нибудь VPN, то tun0 может быть занят. Можно поменять на tun1 тут и далее.

Создаём зону и правило в /etc/config/firewall

Обратите внимание, что требуется указывать device, а не network.

Рестартуем сеть

service network restart

Автозапуск

Накидал простой сценарий, кладём его в /etc/init.d/tun2socks

#!/bin/sh /etc/rc.common

USE_PROCD=1

# starts after network starts
START=40
# stops before networking stops
STOP=89

PROG=/usr/bin/tun2socks
IF="tun0"
PROTO="$PROTO"
METHOD_USER="$METHOD/USER"
PASS="$PASS"
HOST="$HOST"
PORT="$PORT"

start_service() {
        procd_open_instance
        procd_set_param command "$PROG" -device "$IF" -proxy "$PROTO"://"$METHOD_USER":"$PASS"@"$HOST":"$PORT"
        procd_set_param stdout 1
        procd_set_param stderr 1
        procd_set_param respawn ${respawn_threshold:-3600} ${respawn_timeout:-5} ${respawn_retry:-5}
        procd_close_instance
}

Надо подставить свои переменные, примеры:

Shadowsocks

METHOD_USER="aes-256-gcm"
PASS="ochslozniyparol"
HOST="domain.com"
PORT="8388"

Socks5 прокси без пароля

PROTO="socks5"
#METHOD_USER="aes-256-gcm"
#PASS="ochslozniyparol"
HOST="domain.com"
PORT="46202"

Socks5 прокси с логином и паролем

PROTO="socks5"
METHOD_USER="user"
PASS="ochslozniyparol"
HOST="domain.com
PORT="1080"

Переменную METHOD_USER назвал так, потому что для SS — это метод шифрования, а в socks5 — это логин.

Для HTTP и SOCKS4 логика та же.

Не советую использовать бесплатные публичные прокси. Перенаправлять даже часть своего трафика на такие прокси опасно.

Делаем исполняемым, помещаем в автозапуск и стартуем

chmod +x /etc/init.d/tun2socks
ln -s ../init.d/tun2socks /etc/rc.d/S40tun2socks
service tun2socks start

Тестирование работоспособности и поиск ошибок

Глянуть логи приложения

logread -f -e tun2socks

Потестить без сценария инициализации можно так

tun2socks -device tun0 -proxy ss://aes-256-gcm:ochslozniyparol@domain.com:8388 -loglevel debug

При -loglevel debug выводится трафик, который ходит через tun2socks. Но показывается только TCP и UDP. loglevel можно и в сценарий закинуть.

Если будет кушать много памяти, то у проекта есть целая страница с описанием флагов, которые можно подкрутить.

ping -I ничего не скажет о работоспособности. Пакеты будут «ходить» (по итогу до хоста они не доходят) даже если соединение не установлено.

Для проверки прокси лучше всего использовать curl и какой-нибудь сервис, определяющий IP-адрес.

Curl умеет направлять запрос через сетевой интерфейс.

curl --interface tun0 ifconfig.me

Curl должен отдать IP-адрес вашего прокси-сервера.