Инфраструктурная дисциплина для тех, кто устал настраивать прокси на каждом устройстве

ВМЕСТО ВСТУПЛЕНИЯ

Вы когда-нибудь задумывались, почему в 2026 году, чтобы зайти на заблокированный сайт, нужно:

  1. Купить VPS

  2. Настроить VPN

  3. Включить VPN на каждом устройстве

  4. Выключать VPN для российских сервисов

  5. Повторить для всех членов семьи

Это не архитектура. Это бардак.

GOLDENROUTE — это одно решение, которое работает на уровне сети. Вы настраиваете его один раз на шлюзе, и всё. LAN-клиенты не знают, что такое прокси. Они просто выходят в интернет. Шлюз решает, что направить в Tor, а что — напрямую.

ПРОБЛЕМА: ПОЧЕМУ СУЩЕСТВУЮЩИЕ РЕШЕНИЯ НЕСОСТОЯТЕЛЬНЫ

Вариант 1: VPN на каждом устройстве

Работает ровно до тех пор, пока:

  • Не закончится место на телефоне от 5 (пяти) VPN-приложений

  • Член семьи не спросит: «А почему у меня Яндекс не открывается?»

  • Ребёнок не найдёт способ отключить VPN

Вариант 2: Роутер с OpenWrt + VPN

Требует:

  • Поддержки роутера

  • Прошивки

  • Настройки

  • Перепрошивки после неудачной настройки

  • Покупки нового роутера после того, как старый превратился в кирпич

Вариант 3: Docker-контейнер с прокси

Почти то, что нужно. Почти. Но каждый раз, когда вы пытаетесь объяснить жене, как настроить DNS на ноутбуке, вы понимаете: что-то пошло не так.

РЕШЕНИЕ: GOLDENROUTE

GOLDENROUTE — это 3 (три) Docker-контейнера, которые превращают любой Linux-хост в прозрачный шлюз для обхода блокировок.

Что он делает:

  1. Перехватывает весь TCP-трафик с LAN и хоста

  2. Проверяет destination: российский? → пропускает напрямую. В списке исключений? → пропускает напрямую. Всё остальное? → в Tor.

  3. Перехватывает все DNS-запросы и направляет их через DoT (DNS-over-TLS)

Что он НЕ делает:

  • Не анонимизирует (Tor здесь — средство обхода блокировок, не более)

  • Не требует настройки на каждом устройстве

  • Не требует VPN-клиентов

  • Не требует покупки VPS

КАК ЭТО РАБОТАЕТ (БЕЗ АСКЕТИЧНЫХ ASCII-СХЕМ)

Система принимает 3 (три) решения о каждом пакете:

  1. Destination в russian-ips → RETURN. Трафик идёт напрямую. Российские адреса не требуют посредников. Список диапазонов загружается с RIPE API и автоматически обновляется.

  2. Destination в tor-exclude → RETURN. Ваш персональный список исключений. Вы сами решаете, что не должно касаться Tor.

  3. Всё остальное → REDIRECT → Tor. Без обсуждений.

Цепочки iptables

Их 3 (три). И каждая делает ровно то, для чего предназначена.

1. FW_REDIRECT (PREROUTING)

Встречает трафик от LAN-клиентов. Порядок проверки критичен — нарушение фатально:

dst-type LOCAL        → RETURN   # пакеты самому хосту
src 172.16.0.0/12     → RETURN   # Docker bridge (анти-петля)
10/8, 172.16/12,      → RETURN   # приватные диапазоны
192.168/16
russian-ips           → RETURN   # домашняя территория
tor-exclude           → RETURN   # ваши исключения
dport 12346/9050      → RETURN   # не перехватывать свой трафик
dport 53              → REDIRECT # DNS → unbound
всё остальное TCP     → REDIRECT # → :12346 → Tor

2. FW_OUTPUT (OUTPUT)

Абсолютно та же логика для трафика, рождённого на хосте. Хост не является исключением.

3. DOCKER-USER (FORWARD)

Разрешает транзитный трафик из LAN и MASQUERADE для SNAT.

QUIC — ПРОТОКОЛ, КОТОРЫЙ ДУМАЕТ, ЧТО ОН ВЫШЕ TCP

QUIC (UDP/443) — протокол, который браузеры предпочитают TCP при любой возможности.

Прокси-серверы не поддерживают перехват UDP. Если QUIC не заблокировать, браузер устанавливает прямое соединение с иностранным сервером, минуя Tor. Весь смысл системы теряется.

Решение — блокировка QUIC для всего, что не в russian-ips и не в tor-exclude:

FORWARD: UDP/443 !russian-ips !tor-exclude → DROP
OUTPUT:  UDP/443 !127.0.0.1 !russian-ips !tor-exclude → DROP

Браузер, не получив ответа по UDP, откатывается на TCP/443. TCP/443 перехватывается правилами PREROUTING/OUTPUT и направляется в Tor.

QUIC к российским сайтам и к адресам из вашего списка исключений работает штатно — без задержек, без потери производительности.

КОМПОНЕНТЫ

fw (Firewall)

Центральный компонент. network_mode: host, права NET_ADMIN + NET_RAW. Управляет iptables на хосте напрямую.

При старте:

  1. Очищает старые цепочки через while-цикл (идемпотентность — обязательное требование)

  2. Загружает ipset russian-ips из файла + фоновое обновление с RIPE (4 попытки)

  3. Загружает ipset tor-exclude из файла

  4. Запускает redsocks на порту 12346, апстрим — Tor SOCKS5 :9050

  5. Применяет правила к OUTPUT и PREROUTING

  6. Блокирует QUIC для не-российских и не-исключённых адресов

При остановке: trap cleanup убивает redsocks и убирает за собой.

tor

Единственный бэкенд. SOCKS5 на порту 9050. Мосты obfs4 для обхода блокировок. Никакой балансировки, никаких альтернатив.

unbound

DNS-over-TLS форвардер. Все DNS-запросы с LAN и хоста перехватываются на порту 53 и направляются сюда. .ru — через Яндекс DNS (DoT), всё остальное — через Cloudflare и Google (DoT).

ОДИН ДЕНЬ ИЗ ЖИЗНИ ПОЛЬЗОВАТЕЛЯ GOLDENROUTE

Утро. Вы открываете ноутбук. Он подключается к Wi-Fi. Вы получаете IP по DHCP. Шлюз по умолчанию — хост с GOLDENROUTE. DNS — хост с GOLDENROUTE. Вы открываете Яндекс — он открывается напрямую, без Tor. Быстро.

День. Вы открываете заблокированный сайт. Браузер сначала пробует QUIC (UDP/443) — пакет тихо дропается. Браузер откатывается на TCP/443. Пакет попадает в PREROUTING, destination не российский, не в исключениях. REDIRECT :12346. redsocks → Tor. Сайт открывается.

Вечер. Ребёнок открывает YouTube на планшете. Никаких настроек. Никаких вопросов. Просто работает.

ТРЕБОВАНИЯ К СИСТЕМЕ

GOLDENROUTE устанавливается НА ХОСТ, а не в нём. Он становится шлюзом. Это не приложение — это сетевая инфраструктура.

Железо:

  • Любой x86-64 Linux‑хост. Raspberry Pi — да. Старый ноутбук — да. Сервер в стойке — да.

  • 1 (один) сетевой интерфейс для LAN. Хост должен быть шлюзом по умолчанию для вашей сети.

  • 512 MB RAM — достаточно. 1 GB — комфортно.

Софт:

  • Linux с ядром, собранным с поддержкой: ip_tables, iptable_nat, ip_set, ip_set_hash_net

  • Docker Engine + Docker Compose

  • net.ipv4.ip_forward = 1 (без этого LAN-клиенты не выйдут в интернет)

  • Порт 53 должен быть свободен на хосте (unbound занимает его)

  • Модуль nf_conntrack (включён в ядро по умолчанию)

Сеть:

  • Хост должен быть шлюзом по умолчанию для LAN-клиентов

  • Клиенты должны использовать хост как DNS-сервер

  • Если хост не является шлюзом — настройте DHCP соответствующим образом

Где установить:

  • На отдельном Linux-хосте в вашей LAN (рекомендуется)

  • На той же машине, где вы работаете (работает, но требует network_mode: host)

  • На виртуальной машине с bridge-сетью (если гипервизор позволяет пробросить LAN)

  • На Raspberry Pi с Ethernet (классический сценарий «шлюз за 2000 рублей»)

Не пытайтесь установить это на роутер с OpenWrt через opkg. Это не OpenWrt-пакет. Это Docker Compose-проект.

Не пытайтесь установить это на macOS или Windows. GOLDENROUTE требует нативного Linux со всеми модулями iptables. Docker Desktop на Mac — не Linux.

---

БЫСТРЫЙ СТАРТ

# 1. Клонировать
git clone https://github.com/lshnls/goldenroute.git
cd goldenroute
cp .env.example .env
# 2. Получить свежие мосты Tor
#    https://bridges.torproject.org → tor/bridges.txt
# 3. Добавить исключения (опционально)
#    fw/tor-exclude-ips.txt
# 4. Запустить
docker compose up -d

Настройка клиентов: указать IP хоста как шлюз по умолчанию и DNS-сервер. Всё.

КОНФИГУРАЦИЯ

env:

Переменная

По умолчанию

Описание

UNBOUND_PORT

53

Порт DNS

TOR_SOCKS_PORT

9050

SOCKS5 порт Tor

TOR_CONTROL_PORT

9051

Control-порт Tor

TOR_REDSOCKS_PORT

12346

Порт redsocks

LAN_CIDR

192.168.1.0/24

Подсеть LAN



ДИАГНОСТИКА

Tor не забутстрапился:

docker compose logs tor | grep "Bootstrapped"

Ожидается Bootstrapped 100% (done). Если нет — обновить мосты на https://bridges.torproject.org.

Трафик не идёт через Tor:

docker compose exec fw iptables -t nat -L FW_REDIRECT -n -v

Счётчик REDIRECT tcp --dport 12346 должен расти.

QUIC не блокируется:

docker compose exec fw iptables -L FORWARD -n -v | grep "udp dpt:443"

Счётчик DROP должен расти на иностранных сайтах.

Мосты заблокированы:

docker compose up -d --force-recreate tor

ОГРАНИЧЕНИЯ (ЧЕСТНОСТЬ — ЛУЧШАЯ ПОЛИТИКА)

  • Только TCP уходит через Tor. UDP (кроме DNS и заблокированного QUIC) — напрямую.

  • Snowflake не работает через Docker NAT. Только obfs4-мосты.

  • network_mode: host обязателен для fw.

  • Только IPv4.

ПОЧЕМУ НЕ WSPROXY? ПОЧЕМУ НЕ БАЛАНСИРОВКА?

В проекте может быть два бэкенда: wstunnel (WebSocket-туннель до вышестоящего SOCKS5-прокси) и Tor. Между ними — вероятностная балансировка через nginx.

Практика показала: балансировка между платным прокси и Tor — это компромисс, который не нужен никому. Tor справляется с обходом блокировок. Если вам нужна производительность — используйте Tor с правильными мостами. Если вам нужна анонимность — используйте Tor. Два бэкенда — это не гибкость. Это лишняя сложность.

GOLDENROUTE — это один бэкенд. Одно направление. Tor.

ЗАКЛЮЧЕНИЕ

GOLDENROUTE — это не прокси. Это инфраструктурная дисциплина.

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

Никаких VPN-клиентов. Никаких настроек на каждом устройстве. Никаких вопросов «а почему у меня не открывается».

Один хост. Три контейнера. Tor.