Сценарии использования

Практические руководства для типичных развёртываний rVPN.

---

Выбор режима

rVPN поддерживает два режима работы:

Сценарий	Рекомендуемый режим
Проксирование отдельных приложений (браузер, конкретные приложения)	SOCKS5
Полный VPN устройства (весь трафик)	TUN
Мобильные (iOS, Android)	TUN (встроенный)
Подключение к удалённой сети как в LAN	TUN
Раздельное туннелирование: часть через VPN, часть напрямую	Любой с конфигурацией split_tunnel

Оба режима используют одно и то же шифрование X3DH + Double Ratchet. Разница в том, как трафик попадает в VPN.

---

Удалённый доступ к рабочему столу

Подключитесь к рабочему компьютеру из дома, как если бы вы были в той же офисной сети. Используйте RDP, VNC, SSH или любой инструмент удалённого доступа, не выставляя порты в публичный интернет.

Что это решает

• RDP/VNC, открытые в интернет, — обычный вектор атак
• Корпоративные брандмауэры часто блокируют RDP-порты
• Вы хотите доступ к офисному принтеру, файловым шарам и внутренним инструментам

Настройка

1. Конфигурация сервера

Сервер должен находиться в вашей офисной сети с включённым TUN-режимом и настроенным NAT:

[server]
bind_address      = "0.0.0.0:443"
tls_cert_file     = "/etc/letsencrypt/live/your-office-server.com/fullchain.pem"
tls_key_file      = "/etc/letsencrypt/live/your-office-server.com/privkey.pem"
identity_key_file = "/etc/rvpn/server_identity.key"
websocket_path    = "/api/v1/ws"

[server.network]
nat_enabled = true
dhcp_range  = "10.200.0.0/24"

[server.tun]
tun_ip      = "10.200.0.1/24"
dns_servers = ["1.1.1.1", "8.8.8.8"]

2. Конфигурация клиента

Направьте через VPN только подсеть вашей офисной сети. Не направляйте весь трафик:

server_address    = "wss://your-office-server.com/api/v1/ws"
identity_key_file = "~/.config/rvpn/identity.key"
prekey_bundle     = "~/.config/rvpn/prekey-bundle.json"

[tun]
enabled = true
routes  = ["10.100.0.0/16"]    # Your office network subnet
mtu     = 1420

Это направляет через VPN только трафик к 10.100.0.0/16 (вашей офисной сети). Весь остальной трафик (браузинг, стриминг) идёт через ваше обычное домашнее соединение.

3. Проверьте связность

# Force curl through the TUN interface (tun0 on macOS/Linux, utun# on iOS)
curl --interface tun0 https://ifconfig.me

# Should return an office network IP (your VPN tunnel IP)
# If routing works, regular curl should also work without --interface

# Should reach an office server
ping 10.100.0.50

Что работает через туннель

• RDP: 10.100.0.50:3389
• VNC: 10.100.0.51:5900
• SSH: ssh [email protected]
• SMB-шары: \\10.100.0.53\share
• Внутренние веб-приложения: http://10.100.0.54:8080

---

Связывание частных сетей

Соедините несколько серверов в разных локациях в одну защищённую частную сеть. Все серверы и клиенты выглядят как находящиеся в одной LAN, независимо от их физического местоположения.

Что это решает

• Соединение офисов в разных городах без арендованных линий
• Доступ к облачным ВМ, как если бы они были в той же сети
• Запуск кластерного ПО, требующего LAN-обнаружения сети

Архитектура

Office A (10.100.0.0/24)          Cloud Region (10.200.0.0/24)
     |                                     |
  rvpn-server-TUN                    rvpn-server-TUN
  (10.100.0.1)                       (10.200.0.1)
        \                               /
         \                             /
          \---------------------------/
                    |
            rvpn clients get IPs
            in their respective
            DHCP ranges and can
            reach all subnets

Настройка сервера (каждая локация)

В каждой локации работает один rvpn-server в TUN-режиме. dhcp_range в каждой точке должен быть уникальным:

server.toml для Office A:

[server]
bind_address      = "0.0.0.0:443"
tls_cert_file     = "/etc/letsencrypt/live/office-a.example.com/fullchain.pem"
tls_key_file      = "/etc/letsencrypt/live/office-a.example.com/privkey.pem"
identity_key_file = "/etc/rvpn/server_identity_office_a.key"
websocket_path    = "/api/v1/ws"

[server.network]
nat_enabled = true
dhcp_range  = "10.100.0.0/24"

[server.tun]
tun_ip      = "10.100.0.1/24"
dns_servers = ["10.100.0.1"]

server.toml для облачного региона:

[server.network]
nat_enabled = true
dhcp_range  = "10.200.0.0/24"

[server.tun]
tun_ip      = "10.200.0.1/24"
dns_servers = ["10.200.0.1"]

Маршрутизация клиента для доступа к нескольким подсетям

Чтобы достучаться до обеих подсетей, клиенту нужны маршруты для обеих:

[tun]
enabled = true
routes  = ["10.100.0.0/16", "10.200.0.0/16"]   # Covers both office and cloud subnets
mtu     = 1420

Или, если нужен полный туннель (весь трафик через VPN), просто используйте routes = ["0.0.0.0/0"].

Частный DNS для разрешения имён

Чтобы использовать имена вместо IP во всех локациях, настройте частный DNS-сервер:

[server.network]
nat_enabled = true
dhcp_range  = "10.100.0.0/24"

[server.tun]
tun_ip      = "10.100.0.1/24"
dns_servers = ["10.100.0.1"]

Направьте ваш частный DNS на 10.100.0.1. Добавьте записи хостов:

db01.office.internal    10.100.0.10
db02.office.internal    10.200.0.10

---

Среды разработки

Доступ к dev-серверам, базам данных и микросервисам удалённо, как если бы они работали локально. Полезно при работе из дома или в поездках.

Что это решает

• Среды разработки находятся в частной сети и недоступны снаружи
• Нужно тестировать вебхуки, которые вызывают localhost
• Хочется использовать локальные URL разработки, не меняя их

Сценарий 1: доступ ко всем dev-сервисам

Направьте всю вашу сеть разработки через VPN:

server_address    = "wss://your-dev-server.com/api/v1/ws"
identity_key_file = "~/.config/rvpn/identity.key"
prekey_bundle     = "~/.config/rvpn/prekey-bundle.json"

[socks5]
listen_address = "127.0.0.1:1080"

[dns_proxy]
enabled        = true
listen_address = "127.0.0.1:53"

Настройте системный DNS на 127.0.0.1:53. Теперь dev.internalcompany.com разрешается корректно, и весь dev-трафик идёт через VPN.

Сценарий 2: доступ только к отдельным dev-сервисам

Используйте TUN-режим с конкретными маршрутами, чтобы не замедлять всё соединение:

[tun]
enabled = true
routes  = [
    "10.50.0.0/24",    # Dev network
    "192.168.1.0/24",  # Home network (stays direct)
]
mtu     = 1420

Доступ к базам данных

Для прямых подключений к базам данных используйте SOCKS5-прокси:

# MySQL
mysql -h 10.50.0.20 -P 3306 --protocol=TCP

# PostgreSQL
psql -h 10.50.0.21 -p 5432

# MongoDB
mongosh "mongodb://10.50.0.22:27017"

Настройте свой GUI для баз данных (DBeaver, TablePlus, DataGrip) на подключение через SOCKS5 по адресу 127.0.0.1:1080.

Локальная разработка с вебхуками

Если ваш dev-сервер вызывает localhost:3000 с удалённого API, VPN-туннель позволяет удалённому API достучаться до вашей локальной машины:

1. Ваша dev-машина подключается в TUN-режиме
2. Удалённый сервис вызывает публичный IP вашего сервера
3. Сервер туннелирует запрос через VPN на вашу dev-машину
4. Ваш локальный сервис отвечает через туннель

---

Мульти-облачная настройка

Соедините серверы в AWS, GCP, Azure или других облаках в одну частную сеть без использования облачных VPN и без выставления сервисов в публичный интернет.

Что это решает

• Кроссоблачные базы данных без публичных точек
• Приватная коммуникация между сервисами в разных облачных регионах
• Не нужны специфичные для облака VPN-решения
• Единая сетевая топология независимо от облачного провайдера

Архитектура

AWS us-east-1 (10.0.0.0/24)     GCP europe-west1 (10.1.0.0/24)
        |                                |
  rvpn-server-TUN                  rvpn-server-TUN
  (10.0.0.1)                       (10.1.0.1)
        |                                |
        +-------- rvpn tunnel --------+
                    |
          Clients get IPs in
          respective DHCP ranges
          and can reach all subnets

Конфигурация сервера для каждого облака

server.toml для AWS:

[server]
bind_address      = "0.0.0.0:443"
tls_cert_file     = "/etc/rvpn/certs/cert.pem"
tls_key_file      = "/etc/rvpn/certs/key.pem"
identity_key_file = "/etc/rvpn/server_identity.key"
websocket_path    = "/api/v1/ws"

[server.network]
nat_enabled = false           # NAT disabled - we want direct routing
dhcp_range  = "10.0.0.0/24"

[server.tun]
tun_ip      = "10.0.0.1/24"
dns_servers = ["10.0.0.53"]

server.toml для GCP:

[server.network]
nat_enabled = false
dhcp_range  = "10.1.0.0/24"

[server.tun]
tun_ip      = "10.1.0.1/24"
dns_servers = ["10.1.0.53"]

Группы безопасности и брандмауэры

Брандмауэр каждого облачного провайдера должен разрешать:

• Входящий TCP-порт 443 с диапазонов IP VPN-туннеля
• Для межсайтовой коммуникации — разрешить диапазон VPN IP другой локации

Для групп безопасности AWS:

Inbound: TCP 443 from 10.0.0.0/16 (VPN IP range)
Inbound: TCP 443 from 10.1.0.0/16 (Other cloud VPN range)

Конфигурация клиента

[tun]
enabled = true
routes  = ["10.0.0.0/8"]   # All private cloud ranges
mtu     = 1420

Возможные применения

• Репликация БД между облаками: MySQL на 10.0.0.30:3306 в PostgreSQL на 10.1.0.30:5432
• Приватные реестры контейнеров: registry.internal:5000 независимо от места запуска
• Внутренние API: api.internal:8080 без публичных точек
• Репликация бэкапов: rsync между серверами без выхода в публичный интернет

---

Руководство по раздельному туннелированию

Раздельное туннелирование позволяет решить, какой трафик идёт через VPN, а какой — через ваше обычное интернет-соединение.

Когда использовать раздельное туннелирование

Используйте раздельное туннелирование для:

Сценарий	Настройка
Стриминговые сервисы (Netflix, Spotify)	Обход по стране или конкретным IP
Игры	Обход IP игровых серверов для меньшей задержки
Устройства локальной сети	Обход подсетей домашней/офисной LAN
Банковские приложения	Обход или туннелирование в зависимости от политики безопасности
Dev-серверы	Туннелирование только вашей dev-сети

Избегайте раздельного туннелирования для:

Сценарий	Рекомендация
Ненадёжные публичные Wi-Fi	Полный туннель
Доступ к чувствительным аккаунтам	Полный туннель
Обхода фильтров контента на работе	Полный туннель (может нарушать политику)

Логика обхода

Outgoing packet → Check bypass rules →
  → Matches bypass? → Send directly (no encryption)
  → No match? → Send through VPN tunnel

Обход проверяется до шифрования. Совпавший трафик никогда не попадает в VPN-туннель.

Обход по стране

[split_tunnel]
enabled                  = true
builtin_bypass_countries = ["CN", "HK", "SG", "JP", "KR", "TW"]

Это исключает из туннеля трафик к IP-адресам, зарегистрированным в этих странах. Полезно, когда:

• Вы за границей и хотите доступ к внутреннему контенту без замедления
• Стриминговые сервисы блокируют иностранные IP

Ограничение: обход по стране использует данные диапазонов IP APNIC. Крупные CDN могут отдавать контент с IP в нескольких странах.

Обход по сети (CIDR)

Обход конкретных диапазонов IP независимо от страны:

[split_tunnel]
enabled            = true
bypass_networks    = ["192.168.0.0/16", "10.0.0.0/8", "172.16.0.0/12"]

Типичные сети обхода:

• 192.168.0.0/16 — домашняя/офисная LAN
• 10.0.0.0/8 — частные сети
• 172.16.0.0/12 — Docker, VPN, другие частные подсети

Обход по домену

Обход трафика к конкретным доменам:

[split_tunnel]
enabled            = true
bypass_domains_file = "~/.config/rvpn/bypass-domains.txt"

bypass-domains.txt:

netflix.com
spotify.com
hulu.com
disneyplus.com

Обход по домену использует DNS-разрешение: домен разрешается локально (не через VPN), и полученные IP обходят туннель.

Принудительное туннелирование по домену

Принудительно направить конкретные домены через VPN, даже если они попали бы под обход:

[split_tunnel]
enabled            = true
tunnel_domains_file = "~/.config/rvpn/tunnel-domains.txt"

Это полезно, когда:

• Ваш провайдер троттлит конкретные сервисы
• Вы хотите принудительно направлять стриминг через VPN для приватности

Блокировка рекламы

[split_tunnel]
enabled   = true
block_ads = true

Блокирует известные рекламные и трекинговые домены на уровне DNS. Заблокированные домены сразу возвращают NXDOMAIN. Работает вместе с правилами обхода: обходные домены разрешаются локально без блокировки рекламы.

Комбинирование правил

Правила проверяются в таком порядке:

1. tunnel_networks / tunnel_domains (принудительно через VPN)
2. bypass_networks / bypass_domains / builtin_bypass_countries (принудительно напрямую)
3. По умолчанию (полный туннель в TUN-режиме, прокси в SOCKS5-режиме)

Тестирование настроек раздельного туннелирования

# Check your exit IP (should be VPN server if tunneled)
curl https://api.ipify.org

# Check a specific IP
curl --socks5 127.0.0.1:1080 https://api.ipify.org

# Test DNS resolution through tunnel
dig @127.0.0.1 example.com

# Trace routing
traceroute 8.8.8.8

Соображения безопасности

Когда использовать полный туннель (без split tunnel):

[split_tunnel]
enabled = false

• В ненадёжных публичных сетях (Wi-Fi в кафе, отеле, аэропорту)
• Когда требуется максимальная приватность
• Когда правила обхода могут случайно исключить чувствительный трафик

Риск раздельного туннелирования:

Трафик, обходящий VPN, виден вашему провайдеру и оператору локальной сети. Если вы обходите банковские сайты, ваш провайдер видит, что вы обращались к ним. Взвесьте, приемлемо ли это в вашей модели угроз.

Риск обхода по стране:

Стриминговые сервисы могут обнаружить использование VPN другими способами (валюта оплаты, история аккаунта, GPS-локация). Обход по стране делает трафик по виду внутренним, но не меняет эти другие сигналы.