Перейти к содержанию

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

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

Выбор режима

r-vpn поддерживает два режима работы:

Сценарий Рекомендуемый режим
Проксирование для отдельных приложений (браузер, конкретные приложения) SOCKS5
Полный VPN устройства (весь трафик) TUN
Мобильные устройства (iOS, Android) TUN (встроенный)
Подключение к удалённой сети как к локальной TUN
Split tunnel: часть трафика через 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"
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"]    # Подсеть вашей офисной сети
mtu     = 1420

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

3. Проверка подключения

# Принудительный curl через TUN-интерфейс (tun0 на macOS/Linux, utun# на iOS)
curl --interface tun0 https://ifconfig.me

# Должен вернуть IP офисной сети (ваш VPN-туннельный IP)
# Если маршрутизация работает, обычный curl тоже должен работать без --interface

# Должен достичь офисного сервера
ping 10.100.0.50

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

  • RDP: 10.100.0.50:3389
  • VNC: 10.100.0.51:5900
  • SSH: ssh user@10.100.0.52
  • SMB файловые ресурсы: \\10.100.0.53\share
  • Внутренние веб-приложения: http://10.100.0.54:8080

Объединение приватных сетей

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

Что решает эта задача

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

Архитектура

Офис A (10.100.0.0/24)           Облачный регион (10.200.0.0/24)
     |                                     |
  rvpn-server-TUN                    rvpn-server-TUN
  (10.100.0.1)                       (10.200.0.1)
        \                               /
         \                             /
          \---------------------------/
                    |
            Клиенты rvpn получают IP
            в соответствующих диапазонах
            DHCP и могут обращаться
            ко всем подсетям

Настройка сервера (каждое местоположение)

Каждое местоположение запускает один rvpn-server в TUN-режиме. dhcp_range на каждом сайте должен быть уникальным:

server.toml офиса 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"
dns_servers = ["10.100.0.1"]

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

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

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

Для доступа к обеим подсетям клиенту нужны маршруты для обеих:

[tun]
enabled = true
routes  = ["10.100.0.0/16", "10.200.0.0/16"]   # Охватывает обе подсети: офисную и облачную
mtu     = 1420

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

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

Для использования имён хостов вместо IP во всех местоположениях настройте приватный DNS-сервер:

[server.network]
nat_enabled = true
dhcp_range  = "10.100.0.0/24"
dns_servers = ["10.100.0.1"]        # Ваш приватный DNS-сервер

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

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

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

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

Что решает эта задача

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

Сценарий 1: Доступ ко всем сервисам разработки

Маршрутизируйте всю сеть разработки через 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 разрешается корректно, и весь трафик разработки проходит через VPN.

Сценарий 2: Доступ только к конкретным сервисам разработки

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

[tun]
enabled = true
routes  = [
    "10.50.0.0/24",    # Сеть разработки
    "192.168.1.0/24",  # Домашняя сеть (остаётся прямой)
]
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.

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

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

  1. Ваша машина разработки подключается в TUN-режиме
  2. Удалённый сервис вызывает публичный IP вашего сервера
  3. Сервер туннелирует запрос через VPN к вашей машине разработки
  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 туннель --------+
                    |
          Клиенты получают IP
          в соответствующих диапазонах
          DHCP и могут обращаться
          ко всем подсетям

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

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 отключён -- нужна прямая маршрутизация
dhcp_range  = "10.0.0.0/24"
dns_servers = ["10.0.0.53"]   # Внутренний DNS в этом местоположении

server.toml GCP: 

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

Группы безопасности и файрволы

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

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

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

Inbound: TCP 443 from 10.0.0.0/16 (диапазон IP VPN)
Inbound: TCP 443 from 10.1.0.0/16 (диапазон VPN другого облака)

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

[tun]
enabled = true
routes  = ["10.0.0.0/8"]   # Все приватные облачные диапазоны
mtu     = 1420

Доступные сценарии

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

Руководство по split tunneling

Split tunneling позволяет решать, какой трафик проходит через VPN, а какой использует обычное интернет-подключение.

Когда использовать split tunneling

Используйте split tunneling для:

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

Избегайте split tunneling для:

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

Понимание логики обхода

Исходящий пакет -> Проверка правил обхода ->
  -> Совпадает с обходом? -> Отправить напрямую (без шифрования)
  -> Нет совпадения? -> Отправить через VPN-туннель

Обход проверяется до шифрования. Совпадающий трафик никогда не попадает в 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)

Принудительно направляйте конкретные домены через 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-режиме)

Тестирование конфигурации split tunnel

# Проверьте ваш выходной IP (должен быть VPN-сервер, если через туннель)
curl https://api.ipify.org

# Проверьте конкретный IP
curl --socks5 127.0.0.1:1080 https://api.ipify.org

# Тест разрешения DNS через туннель
dig @127.0.0.1 example.com

# Трассировка маршрута
traceroute 8.8.8.8

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

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

[split_tunnel]
enabled = false
  • В недоверенных публичных сетях (кафе, отель, аэропорт Wi-Fi)
  • Когда требуется максимальная приватность
  • Когда правила обхода могут случайно исключить конфиденциальный трафик

Риск split tunneling:

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

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

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