Все статьи

Развертывание VPN-инфраструктуры на RemnaWave: 10 серверов от А до Я и реализация «Лучшего сервера»

vpndevopsremnawavevlessrealityhysteria2dockerlinuxnetworking

Развертывание VPN-инфраструктуры на RemnaWave: 10 серверов от А до Я и реализация «Лучшего сервера»

Современные реалии маршрутизации трафика и протокольных ограничений требуют перехода от одиночных серверов к распределенным многоузловым инфраструктурам. Один заблокированный IP-адрес или локальная авария в европейском дата-центре не должны лишать пользователей связи.

В данном руководстве подробно разобран процесс построения распределенной VPN-экосистемы на базе RemnaWave Panel с кластером из 10 серверов в разных локациях (Германия, Нидерланды, Латвия, Чехия, Швеция, Финляндия, США), поддержкой протоколов VLESS + REALITY и Hysteria 2, а также детальной реализацией функционала «⚡ Лучший сервер» (автоматический Failover и URL-Test).

1. Архитектура распределенного кластера

Инфраструктура строится по схеме «Мастер — Воркеры» с разделением контуров управления и обработки трафика:

[ Master Server: RemnaWave Panel ]
  (Web UI, REST API, PostgreSQL 16, Redis, Генератор подписок)
       │
       ├── gRPC / TLS (Безопасный туннель управления)
       │
       ├── Worker 1: Германия - 1 (VLESS REALITY)
       ├── Worker 2: Германия - 2 (VLESS REALITY)
       ├── Worker 3: Германия - 3 (VLESS REALITY)
       ├── Worker 4: Нидерланды - 1 (VLESS REALITY)
       ├── Worker 5: Нидерланды - 2 (VLESS REALITY + Hysteria 2)
       ├── Worker 6: Рига / Латвия (VLESS REALITY)
       ├── Worker 7: Прага / Чехия (VLESS REALITY)
       ├── Worker 8: Швеция (VLESS REALITY)
       ├── Worker 9: Финляндия (VLESS REALITY)
       └── Worker 10: Америка / США (VLESS REALITY)
Компонент Роль в системе Стек
Master Node (Панель) Хранение пользователей, биллинг, мониторинг нод, раздача подписок Docker, RemnaWave, PostgreSQL, Redis, Caddy
Worker Nodes (1–10) Прием и проксирование пользовательского трафика RemnaWave Node Daemon, Xray-core, Sing-box
Протокол VLESS + REALITY Основной протокол с маскировкой под легитимный TLS 1.3 TCP, XTLS Reality, X25519, SNI Camouflage
Протокол Hysteria 2 Высокоскоростной протокол на базе UDP (QUIC) для нестабильных сетей UDP, Salamander Obfuscation, BBR Congestion Control
Виртуальный узел «Лучший сервер» Автоматический выбор ноды с минимальным RTT и нулевыми потерями Client-side URL-Test / Fallback Proxy Group

2. Развертывание Master-сервера (RemnaWave Panel)

Мастер-сервер не участвует в передаче клиентского трафика — он отвечает за авторизацию, синхронизацию конфигураций нод и выдачу подписок клиентам (Happ, v2rayN, Sing-box, Clash, Streisand).

Шаг 2.1. Подготовка ОС и установка зависимостей

На чистом сервере под управлением Ubuntu 24.04 LTS устанавливаются Docker и сетевые утилиты:

apt update && apt upgrade -y
apt install -y curl ufw git jq

# Установка Docker и Docker Compose
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

Настройка базового файрвола (UFW):

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 3000/tcp
ufw enable

Шаг 2.2. Конфигурация Docker Compose для RemnaWave

Создается рабочая директория и файл конфигурации:

mkdir -p /opt/remnawave && cd /opt/remnawave

Файл /opt/remnawave/docker-compose.yml:

version: '3.8'

services:
  remnawave:
    image: remnawave/backend:latest
    container_name: remnawave-panel
    restart: always
    ports:
      - '3000:3000'
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://remna:secure_db_pass@postgres:5432/remnawave
      - REDIS_URL=redis://redis:6379
      - JWT_SECRET=super_secret_jwt_key_random_generated_string_here
      - APP_PORT=3000
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16-alpine
    container_name: remnawave-postgres
    restart: always
    environment:
      POSTGRES_USER: remna
      POSTGRES_PASSWORD: secure_db_pass
      POSTGRES_DB: remnawave
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    container_name: remnawave-redis
    restart: always
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

Шаг 2.3. Запуск и настройка Reverse Proxy (Caddy)

Запуск контейнеров:

docker compose up -d

Для автоматического получения SSL-сертификатов Let’s Encrypt и безопасного проксирования Web UI используется Caddy:

apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

Конфигурация /etc/caddy/Caddyfile:

panel.yourdomain.com {
    reverse_proxy localhost:3000
}

После перезапуска (systemctl restart caddy) панель управления доступна по HTTPS в браузере.

3. Подключение и оптимизация 10 Worker-нод

Каждая из 10 нод развертывается на отдельном VPS с гигабитным портом. Для максимальной скорости и устойчивости на каждой ноде выполняется предварительная оптимизация ядра Linux.

Шаг 3.1. Тюнинг ядра Linux и включение BBR

На каждой ноде прописываются параметры оптимизации сетевого стека в /etc/sysctl.conf:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192

Применение параметров:

sysctl -p

Шаг 3.2. Установка RemnaWave Node Daemon

На каждой ноде запускается легковесный агент RemnaWave Node через Docker:

mkdir -p /opt/remnawave-node && cd /opt/remnawave-node

Файл /opt/remnawave-node/docker-compose.yml:

version: '3.8'

services:
  node:
    image: remnawave/node:latest
    container_name: remnawave-node
    restart: always
    network_mode: host
    environment:
      - PANEL_URL=https://panel.yourdomain.com
      - NODE_SECRET_TOKEN=unique_node_token_generated_in_panel
      - PORT=2053

Запуск агента:

docker compose up -d

После этого в веб-интерфейсе панели узел моментально переходит в статус Connected и отображает реальный пинг, потребление RAM и входящий/исходящий трафик.

4. Конфигурация протоколов: VLESS REALITY и Hysteria 2

4.1. Настройка VLESS-TCP-REALITY

REALITY обеспечивает максимальную маскировку: при сканировании сторонний наблюдатель видит валидный TLS 1.3 handshake с реальным доверенным сайтом (SNI).

  1. Генерация ключей X25519: Панель генерирует пару ключей (Private Key / Public Key) и короткий Short ID (например, 16a8d0ef).
  2. Выбор маскировочного домена (Target SNI): Подбираются серверы с поддержкой TLS 1.3 и HTTP/2, физически расположенные рядом с нодой (например, gateway.icloud.com, dl.google.com, swdist.apple.com, www.microsoft.com).
  3. Порт: 443/TCP.

4.2. Настройка Hysteria 2 (UDP) на узле Нидерланды-2

Для каналов с высоким уровнем потерь пакетов (мобильный интернет, удаленные провайдеры) на ноде Нидерланды - 2 настраивается Hysteria 2:

  • Протокол: Hysteria 2 (QUIC / UDP).
  • Порт: 443/UDP (или диапазон портов 20000-50000/UDP для порт-хоппинга).
  • Обфускация: Salamander пароль.
  • Собственный self-signed или Let’s Encrypt сертификат.

5. Глубокий разбор: Как устроен «⚡ Лучший сервер»

В верхней части списка серверов пользователи видят виртуальный узел «⚡ Лучший сервер». Это не отдельный физический VPS, а клиентская динамическая группа автоматического тестирования и переключения (URL-Test / Smart Failover).

                  ┌── [ Probe: http://gstatic.com/generate_204 ] ──┐
                  │                                                │
[ Входящий трафик ] ──> [ URL-Test Group: ⚡ Лучший сервер ] ───────┤
                                                                   ├──> Германия-1 (RTT: 42ms)  [АКТИВЕН]
                                                                   ├──> Германия-2 (RTT: 45ms)
                                                                   ├──> Нидерланды-1 (RTT: 48ms)
                                                                   ├──> Рига (RTT: 62ms)
                                                                   └──> Америка (RTT: 128ms)

Принцип работы URL-Test и Failover

  1. Фоновые проверки доступности (Probing): Клиентское приложение (Happ, Sing-box, Clash Meta / Mihomo) с заданным интервалом (обычно каждые 300 секунд) отправляет легковесный HTTP GET запрос через каждый из 10 серверов на контрольный адрес http://www.gstatic.com/generate_204 или https://cp.cloudflare.com/generate_204.
  2. Вычисление метрик (RTT и Packet Loss): Приложение замеряет время отклика (Round Trip Time) и фиксирует процент успешных ответов.
  3. Автоматический выбор наименьшей задержки: Трафик мгновенно направляется на сервер с наименьшим пингом (например, Германия - 1 с RTT 42 мс).
  4. Мгновенный бесшовный Failover: Если выбранная нода перестает отвечать (падение дата-центра, блокировка магистрального провайдера или плановый рестарт), клиент автоматически переключает сессии на следующий живой узел (Германия - 2 или Нидерланды - 1) без разрыва соединения и без ручных действий со стороны пользователя.

Структура группы в конфигурации подписки (Sing-box / Clash Meta)

При генерации профиля подписки генератор RemnaWave формирует секцию outbounds / proxy-groups:

{
    "tag": "⚡ Лучший сервер",
    "type": "urltest",
    "outbounds": [
        "Германия",
        "Германия - 2",
        "Германия - 3",
        "Рига",
        "Прага",
        "Нидерланды - 1",
        "Нидерланды - 2",
        "Швеция",
        "Финляндия",
        "Америка"
    ],
    "url": "http://www.gstatic.com/generate_204",
    "interval": "5m",
    "tolerance": 50,
    "idle_timeout": "30m"
}

Параметр tolerance: 50 предотвращает постоянные микро-переключения между серверами с близким пингом (например, 42 мс и 45 мс), стабилизируя TCP-сессии и звонки.

6. Синхронизация подписок и автообновление

  1. Автообновление профиля: В заголовках HTTP-ответа генератора подписок передается директива profile-update-interval: 12, указывающая клиентам обновлять список рабочих нод и ключи каждые 12 часов.
  2. Лимиты трафика и сброс: Панель передает заголовки Subscription-Userinfo: upload=...; download=...; total=...; expire=..., благодаря чему в приложении отображается точный статус (на скриншоте: 678GB / ∞, истекает 25.05.2027).
  3. Бесшовная ротация нод: При добавлении 11-го или замене старого сервера администратор просто добавляет узел в веб-панели RemnaWave — при следующем автообновлении подписки новый сервер мгновенно появится у всех клиентов и автоматически включится в пул «Лучшего сервера».

7. Ключевые инженерные выводы

  1. Изоляция управления от проксирования: Размещение панели на отдельном мастере гарантирует, что падение или блокировка любого из 10 воркеров не повлияет на работу системы и доставку подписок.
  2. Комбинация TCP и UDP протоколов: Сочетание VLESS REALITY (как основного незаметного протокола) и Hysteria 2 (как спасения при потерях пакетов) перекрывает 100% сценариев использования.
  3. «Лучший сервер» как стандарт UX: Реализация клиентских urltest групп сглаживает любые сетевые всплески и делает инфраструктуру по-настоящему надежной и прозрачной для конечного пользователя.