Глянуть архитектуру процессора на вашем роутере
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-адрес вашего прокси-сервера.