[ГАЙД] OpenWrt + olcRTC: стабильный интернет через LTE в условиях белых списков

Starred Gists，GitHub Gist，即时分享代码、笔记与代码片段。关注
翻译

readme.md

OpenWrt + olcRTC + sing-box: стабильный интернет через LTE

Практический сетап для ситуации, когда проводного интернета нет, доступна только LTE-связь, обычные VPN/VLESS-конфигурации работают нестабильно, а нормальный доступ в интернет нужен сразу для нескольких устройств — в том числе для работы через корпоративные VPN.

Это не универсальная инструкция и не «правильная архитектура на все случаи жизни». Ниже описан конкретно мой сетап, который сейчас работает у меня и который можно использовать как отправную точку.

Поддержать можно:

  • BTC bc1q6r9tdctf2wjrhj03w0u8lrg3gs2m8fkvcv4953
  • USDT (TRC20) TK29wf2q2pBtm4rFDPkVqfBoNKdKR7qMXS
  • ETH 0x6e6ec7Bea1dF21f836310EB6B86D26738907A382
  • SOL E1GPt8SGKLamSPiRRDFzSSdcwKgjop766bVbYoPw6sGx

Связаться можно в комментариях или Telegram: @swekonstantin

Проблема

Приехал в деревню: доступа к проводному интернету нет, только LTE.

Белые списки уже не выключают — терпите, карлики.

VLESS-конфигурации часто подводят и работают нестабильно. При этом нужен доступ к нормальному интернету, чтобы не сойти с ума от использования ВК, а также для работы.

Кроме самого доступа в интернет, хотелось решить ещё несколько проблем.

Корпоративный VPN

С корпоративными VPN получалось особенно неудобно:

  • сложная настройка корпоративного VPN поверх уже действующего обхода;
  • два VPN на одной машине плохо дружат друг с другом;
  • вручную настраивать маршруты и туннели — геморно;
  • соединение становится нестабильным из-за нескольких одновременно работающих слоёв туннелирования.

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

Подключение новых устройств

Отдельная проблема — устройства, на которых VPN ещё не настроен или его вообще невозможно установить.

Например, однажды я сбросил настройки телефона и не смог нормально продолжить первоначальную настройку без подключения к рабочему Wi-Fi.

Кроме того:

  • не для всех устройств существуют актуальные VPN-клиенты;
  • на каждом новом устройстве приходится повторять настройку;
  • часть IoT/embedded-устройств вообще ничего кроме обычного Wi-Fi не умеет.

Поэтому хотелось вынести всю логику на роутер.

Экономика

В какой-то момент у меня было 4 параллельные подписки на VPN.

Каждый сервис был настроен немного по-разному и периодически отваливался. Пока один работал — остальные просто лежали в простое.

В сумме я тратил около 1500 ₽ в месяц только на VPN-подписки.

Теперь постоянные расходы — в основном аренда VPS.

Что получилось

На текущий момент:

  • устройства подключаются к Wi-Fi без каких-либо дополнительных настроек на клиенте;
  • около 5 устройств одновременно пользуются зарубежными сервисами;
  • поверх соединения можно подключать корпоративные VPN:
    • WireGuard;
    • L2TP over IPsec;
    • другие VPN;
  • при необходимости можно использовать и VLESS-серверы;
  • первоначальные вложения — около 5000 ₽ за роутер плюс аренда VPS;
  • по стабильности решение не хуже предыдущих вариантов вроде CDN-based обходов.

С точки зрения клиента всё выглядит просто:

Устройство
    │
    │ Wi-Fi
    ▼
OpenWrt Router
    │
    ├── sing-box
    │      │
    │      ▼
    │    SOCKS5
    │      │
    │      ▼
    └── olcRTC
           │
           │ WebRTC / Telemost
           ▼
          VPS
           │
           ▼
        Internet

Известные проблемы / TODO

Решение пока не идеальное.

UDP, ICMP и DNS

Периодически возникают проблемы с:

  • UDP;
  • ICMP;
  • DNS-трафиком.

Скорее всего, проблема находится в моей текущей конфигурации роутера. Пока меня это устраивает, поскольку есть простой костыль.

Костыль: подключиться на проблемном устройстве ещё к одному VPN.

olcRTC и WebRTC

olcRTC периодически отваливается.

Пока связываю это с двумя факторами:

  1. вайбкод самого инструмента;
  2. особенности провайдера WebRTC.

Размер olcRTC

olcRTC получается достаточно большим бинарником.

Нужно подумать, как уменьшить его размер и потребление ресурсов на роутере.

Возможно, в будущем сделаю облегчённый форк специально под embedded/OpenWrt-сценарии.

Что понадобится

Ниже описываю только свой сетап. На него можно ориентироваться или попробовать повторить.

Компонент Что использую
Роутер Cudy TR3000 256 MB v1, китайская версия
ОС OpenWrt 25.12.5
Транспорт olcRTC
Маршрутизация sing-box 1.13.18
Интернет LTE через Android / USB-модем
VPS 2 vCPU / 4 GB RAM
Дополнительно Android-телефон + USB-кабель

Мой форк olcRTC:

https://github.com/jojopko/olcrtc

Инструкция OpenWrt для Cudy TR3000:

https://openwrt.org/toh/cudy/tr3000

Также во время настройки желательно иметь какой-либо доступ к глобальной сети.

Если его нет, пакеты и бинарники можно заранее скачать на другом устройстве и перекинуть на роутер через scp.

Требования к VPS

У меня VPS:

2 vCPU
4 GB RAM

CPU

2+ vCPU желательно.

Это важно для Яндекс Телемоста, поскольку процессору приходится заниматься обработкой/расшифровкой кадров.

RAM

4 GB для одного olcRTC избыточны.

Если на сервере больше ничего не будет работать:

1 GB RAM — скорее всего достаточно
2 GB RAM — более чем достаточно

Больше 2 GB специально ради этого сетапа брать большого смысла не вижу.

Установка

1. Устанавливаем OpenWrt

Как установить OpenWrt на Cudy TR3000:

https://openwrt.org/toh/cudy/tr3000

У меня используется:

OpenWrt 25.12.5

2. Необходимые пакеты

Ниже список пакетов, которые понадобились мне.

Возможно, что-то забыл.

sudo-1.9.17_p2-r3.apk

kmod-mii-6.12.94-r1.apk
kmod-usb-net-cdc-ether-6.12.94-r1.apk
kmod-tun-6.12.94-r1.apk
kmod-usb-net-rndis-6.12.94-r1.apk
kmod-usb-net-6.12.94-r1.apk

Если роутер находится в условиях полного БС и не может сам скачать зависимости, пакеты можно заранее взять отсюда:

https://downloads.openwrt.org/releases/25.12.5/packages/

Например:

curl -LO https://downloads.openwrt.org/releases/25.12.5/packages/aarch64_cortex-a53/base/ca-bundle-20260601-r1.apk

3. Устанавливаем sing-box

sing-box можно найти в репозиториях OpenWrt.

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

Для ARM64:

curl -fLO "https://github.com/SagerNet/sing-box/releases/download/v1.13.18/sing-box-1.13.18-linux-arm64-musl.tar.gz"

Используемая версия:

sing-box 1.13.18

4. Передаём файлы на роутер

Файлы можно перекинуть через scp.

Без -O, скорее всего, работать не будет:

scp -O  root@192.168.1.1:/tmp/

После этого устанавливаем APK-пакеты вручную:

apk --no-network --allow-untrusted add

Настройка USB-интернета

Этот раздел нужен, если интернет приходит:

  • с Android-телефона через USB tethering;
  • либо через совместимый USB/SIM-модем.

Создаём интерфейс android:

uci set network.android=interface
uci set network.android.proto='dhcp'
uci set network.android.device='usb0'
uci commit network

Добавляем интерфейс в firewall zone:

uci add_list firewall.@zone[1].network='android'
uci commit firewall

Перезапускаем сеть и firewall:

/etc/init.d/network restart
/etc/init.d/firewall restart

Проверяем интерфейс

ifstatus android

В JSON должно быть:

{
  "up": true
}

Проверяем маршрутизацию

Дефолтный маршрут тоже должен идти через usb0.

route show default

Пример:

default via 192.168.156.48 dev usb0 src 192.168.156.92
172.19.0.0/30 dev singtun0 scope link src 172.19.0.1
192.168.1.0/24 dev br-lan scope link src 192.168.1.1
192.168.156.0/24 dev usb0 scope link src 192.168.156.92

После этого попробуйте:

ping <какой-нибудь-доступный-хост>

или сделать обычный HTTP-запрос.

Если:

  • передача данных на телефоне включена;
  • на самом телефоне интернет работает;
  • USB tethering активен;

то роутер тоже должен получить доступ в сеть.

Установка olcRTC и sing-box

Бинарники:

olcrtc
sing-box

кладём в:

/usr/bin/

Конфиги:

/etc/olcrtc/config.yaml
/etc/sing-box/config.json

Конфигурация olcRTC

У меня DNS работает довольно странно.

Я использую DNS, который приходит через /etc/resolv.conf.

Яндекс DNS:

77.88.8.8

работает, но некоторые зарубежные сайты через него режутся.

Google DNS:

8.8.8.8

в условиях БС, скорее всего, работать не будет нигде.

Отдельный пользователь для olcRTC

Я рекомендую запускать olcRTC от имени отдельного пользователя.

Это позволяет правильно настроить маршрутизацию в sing-box и избежать циклов, когда трафик olcRTC снова попадает в тот же туннель.

Создайте пользователя, например:

olcrtc

и запомните его UID.

Дальше этот UID понадобится в:

"exclude_uid": [
  1001
]

Пример /etc/olcrtc/config.yaml

mode: cnc

auth:
  provider: telemost

room:
  id: "room_id"

crypto:
  key: "secret_key"

net:
  transport: vp8channel

  # DNS-варианты:
  # dns: "77.88.8.8:53"
  # dns: "8.8.8.8:53"

  dns: "192.168.156.48:53"

liveness:
  interval: 10s
  timeout: 15s
  failures: 4

socks:
  host: "127.0.0.1"
  port: 8808
  user: "admin"
  pass: "1111"

vp8:
  fps: 30
  batch_size: 64

debug: false

data: data/

Конфигурация sing-box

Здесь обязательно нужно заменить DNS на актуальный для вашей сети.

Я смотрел адрес DNS в:

/etc/resolv.conf

Логирование

Во время первоначальной настройки имеет смысл поставить:

"level": "info"

или:

"level": "debug"

Но после тестирования лучше переключить на:

"level": "warn"

или:

"level": "error"

Иначе логи довольно быстро начинают забиваться мусором.

Ошибки при этом всё равно будут видны.

exclude_uid

Параметр:

"exclude_uid": [
  1001
]

должен содержать UID пользователя, от имени которого работает olcRTC.

Это нужно, чтобы трафик самого olcRTC не загонялся обратно в sing-box и не возникала петля.

SOCKS outbound

Проверьте, что параметры подключения в outbounds совпадают с настройками SOCKS в конфигурации olcRTC.

То есть эти значения:

127.0.0.1
8808
admin
1111

должны совпадать в обоих конфигах.

Пример /etc/sing-box/config.json

{
  "log": {
    "level": "warn",
    "timestamp": true
  },

  "dns": {
    "servers": [
      {
        "type": "udp",
        "tag": "dns-direct",
        "server": "192.168.156.48",
        "server_port": 53,
        "bind_interface": "usb0"
      }
    ],
    "final": "dns-direct",
    "strategy": "ipv4_only"
  },

  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "interface_name": "singtun0",
      "address": [
        "172.19.0.1/30"
      ],
      "mtu": 1500,
      "auto_route": true,
      "auto_redirect": true,
      "strict_route": true,
      "stack": "system",

      "exclude_uid": [
        1001
      ],

      "route_exclude_address": [
        "192.168.0.0/16"
      ]
    }
  ],

  "outbounds": [
    {
      "type": "socks",
      "tag": "olcrtc",
      "server": "127.0.0.1",
      "server_port": 8808,
      "username": "admin",
      "password": "1111",
      "version": "5",
      "network": "tcp"
    },

    {
      "type": "direct",
      "tag": "direct",
      "bind_interface": "usb0"
    }
  ],

  "route": {
    "rules": [
      {
        "port": 53,
        "action": "hijack-dns"
      },

      {
        "ip_is_private": true,
        "action": "route",
        "outbound": "direct"
      },

      {
        "network": "udp",
        "action": "route",
        "outbound": "direct"
      },

      {
        "network": "tcp",
        "action": "route",
        "outbound": "olcrtc"
      }
    ],

    "final": "direct"
  }
}

Ручной запуск

До создания системных сервисов лучше сначала проверить всё руками.

Запускаем olcRTC

sudo -u olcrtc /usr/bin/olcrtc /etc/olcrtc/config.yaml

Проверяем конфиг sing-box

sing-box check -c /etc/sing-box/config.json

Если ошибок нет:

sing-box run -c /etc/sing-box/config.json

После этого подключитесь к Wi-Fi роутера и проверьте доступ в интернет.

Настройка системных сервисов

Если ручной запуск работает нормально, имеет смысл превратить оба процесса в OpenWrt-сервисы.

Тогда они будут:

  • запускаться автоматически после включения роутера;
  • работать без активной SSH/shell-сессии;
  • автоматически перезапускаться после падения;
  • писать stdout и stderr в системные логи.

Перед настройкой убедитесь, что процессы, запущенные вручную, остановлены:

ps w

Сервис sing-box

Создаём файл:

vi /etc/init.d/sing-box

Содержимое:

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

START=95
STOP=10
USE_PROCD=1

PROG="/usr/bin/sing-box"
CONFIG="/etc/sing-box/config.json"

start_service() {
    procd_open_instance

    procd_set_param command "$PROG" run -c "$CONFIG"

    # threshold timeout retry
    procd_set_param respawn 3600 5 5

    procd_set_param file "$CONFIG"

    procd_set_param stdout 1
    procd_set_param stderr 1

    procd_close_instance
}

reload_service() {
    stop
    start
}

service_triggers() {
    procd_add_reload_trigger "sing-box"
}

Делаем исполняемым:

chmod +x /etc/init.d/sing-box

Включаем автозапуск:

/etc/init.d/sing-box enable

Запускаем:

/etc/init.d/sing-box start

Сервис olcRTC

Создаём:

vi /etc/init.d/olcrtc

Содержимое:

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

START=95
STOP=10
USE_PROCD=1

start_service() {
    procd_open_instance

    procd_set_param command /usr/bin/olcrtc /etc/olcrtc/config.yaml

    procd_set_param user olcrtc

    procd_set_param respawn 3600 5 5

    procd_set_param stdout 1
    procd_set_param stderr 1

    procd_close_instance
}

Делаем исполняемым:

chmod +x /etc/init.d/olcrtc

Включаем автозапуск:

/etc/init.d/olcrtc enable

Запускаем:

/etc/init.d/olcrtc start

Проверка

После запуска обоих сервисов:

ps w

Проверяем, что работают:

olcrtc
sing-box

При необходимости смотрим системный лог:

logread

или фильтруем конкретный процесс:

logread | grep sing-box
logread | grep olcrtc

Дальше:

  1. подключаем устройство к Wi-Fi;
  2. никаких VPN на клиенте не включаем;
  3. открываем нужный зарубежный сервис;
  4. проверяем обычный интернет;
  5. при необходимости поверх этого подключаем корпоративный VPN.

Если всё настроено правильно — должно работать.

Особенности стабильности

На практике я заметил, что в первые минуты после запуска могут быть некоторые нестабильности.

Через некоторое время соединение обычно выравнивается.

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

Интересное наблюдение: подключение дополнительного VPN уже на компьютере почти полностью решает проблему нестабильности.

Минус — увеличивается ping.

Пока предполагаю, что причина может быть в том, что в таком сценарии большинство обращений с точки зрения внешней сети идёт к одному IP-адресу, но уверенности в этом пока нет.

Итоговая схема

                         ┌──────────────────────┐
                         │         VPS          │
                         │                      │
                         │    olcRTC server     │
                         └──────────▲───────────┘
                                    │
                                    │ WebRTC
                                    │
                         ┌──────────┴───────────┐
                         │  LTE (белые списки)  │
                         └──────────▲───────────┘
                                    │
                                    │ usb0
                                    │
┌─────────────┐          ┌──────────┴───────────┐
│  Laptop     │          │      OpenWrt         │
│             │── Wi-Fi ─▶                      │
│ Corp. VPN   │          │  sing-box            │
└─────────────┘          │      │               │
                         │      ▼ SOCKS5        │
┌─────────────┐          │    olcRTC            │
│   Phone     │── Wi-Fi ─▶                      │
└─────────────┘          └──────────────────────┘

Главная идея сетапа — вынести весь обход на роутер.

Клиентские устройства при этом получают обычный Wi-Fi и не должны знать, каким образом трафик дальше выходит в глобальную сеть.

Что в итоге

За примерно 5000 ₽ первоначальных вложений в роутер и стоимость одного VPS я получил:

  • единый шлюз для всех домашних устройств;
  • отсутствие VPN-клиентов на каждом устройстве;
  • возможность спокойно использовать корпоративные VPN поверх этой схемы;
  • возможность подключать устройства, на которых нельзя установить VPN;
  • меньше ежемесячных расходов;
  • приемлемую стабильность даже в условиях LTE и ограниченного доступа в сеть.

Не идеально, но на данный момент для моего сценария работает заметно удобнее, чем набор из нескольких отдельных VPN-подписок.

Поддержать можно:

  • BTC bc1q6r9tdctf2wjrhj03w0u8lrg3gs2m8fkvcv4953
  • USDT (TRC20) TK29wf2q2pBtm4rFDPkVqfBoNKdKR7qMXS
  • ETH 0x6e6ec7Bea1dF21f836310EB6B86D26738907A382
  • SOL E1GPt8SGKLamSPiRRDFzSSdcwKgjop766bVbYoPw6sGx

Связаться можно в комментариях или Telegram: @swekonstantin

Полезные ссылки

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论