VPNCloud: Строим свою приватную сеть в облаке

Статус проекта на сентябрь 2026 года. VPNCloud написан на Rust. Последний выпуск — 2.3.0 от 23 декабря 2021 года, последние изменения в репозитории — март 2024 года. Проект не архивирован, но фактически не развивается. Для новой сети разумнее взять активно поддерживаемые решения из цикла «Mesh VPN»: что такое mesh-сеть на WireGuard, Tailscale, ZeroTier и NetBird, Headscale или WireGuard вручную. Статья пригодится тем, у кого VPNCloud уже работает.

VPNCloud — одноранговый (peer-to-peer) mesh VPN поверх UDP с шифрованием и прохождением через NAT. Каждый узел сети может обмениваться данными с любым другим напрямую, без центрального сервера, через который шёл бы весь трафик. Узлы объединяют серверы в разных облаках, домашний и офисный компьютеры, одноплатники вроде Raspberry Pi.

Для каких задач подходит

• Доступ к домашним и офисным ресурсам — файловому серверу, камерам, внутренним сервисам — так, будто вы в локальной сети.
• Связь серверов у разных провайдеров по частным адресам.
• Изоляция сервисов: часть инфраструктуры доступна только внутри VPN.
• Узлы за NAT: публичный адрес нужен не каждому узлу, достаточно одного доступного узла, через который остальные найдут друг друга.

Как устроен

VPNCloud передаёт данные по UDP. Для первого подключения узлу нужен адрес хотя бы одного другого узла (peers). Узнав о сети через него, узлы устанавливают прямые соединения друг с другом, в том числе через NAT. На каждом узле создаётся виртуальный интерфейс:

• tun (по умолчанию) передаёт IP-пакеты — сеть третьего уровня;
• tap передаёт Ethernet-кадры — сеть второго уровня, в неё проходят ARP и DHCP.

Режим работы (mode) определяет, как узел выбирает получателя: hub рассылает всё всем, switch запоминает MAC-адреса, router отправляет пакеты по заявленным подсетям узлов. Значение по умолчанию normal означает switch для tap и router для tun.

Установка

Готовые пакеты .deb и .rpm (amd64, arm64, armhf, armel, i386) и статические бинарные файлы лежат на странице выпусков на GitHub. Пример для Debian или Ubuntu на amd64:

wget https://github.com/dswd/vpncloud/releases/download/v2.3.0/vpncloud_2.3.0_amd64.deb
sudo apt install ./vpncloud_2.3.0_amd64.deb
vpncloud --version

Пакет устанавливает шаблон службы systemd vpncloud@.service: конфигурация сети хранится в /etc/vpncloud/ИМЯ.net, служба запускается как vpncloud@ИМЯ.

Формат конфигурации

Конфигурация — YAML-файл. Ниже главные параметры по примеру из репозитория проекта (assets/example.net.disabled):

Параметров network и crypto: aes256, которые встречаются в старых инструкциях, в формате 2.x нет: сеть отделяется паролем или ключами.

Сценарий 1: два сервера

Два сервера с публичными адресами 203.0.113.1 и 203.0.113.2 объединяются в сеть 10.10.10.0/24.

Сервер A, файл /etc/vpncloud/mesh.net:

listen: 3210
peers:
  - 203.0.113.2:3210
crypto:
  password: "длинный-случайный-пароль"
ip: 10.10.10.1/24

Сервер B отличается только адресом соседа и своим IP:

listen: 3210
peers:
  - 203.0.113.1:3210
crypto:
  password: "длинный-случайный-пароль"
ip: 10.10.10.2/24

Запуск и автозапуск на каждом сервере:

sudo systemctl enable --now vpncloud@mesh
ip addr show vpncloud0
ping 10.10.10.2   # с сервера A

Порт 3210/UDP должен быть открыт в межсетевом экране обоих серверов.

Сценарий 2: узлы за NAT

Домашний компьютер и офисный сервер находятся за NAT, облачный сервер 203.0.113.10 имеет публичный адрес. Облачный сервер становится точкой первого подключения:

# облачный сервер
listen: 3210
peers: []
crypto:
  password: "длинный-случайный-пароль"
ip: 10.10.10.10/24

# домашний компьютер (у офисного сервера — свой ip, например 10.10.10.200/24)
listen: 3210
peers:
  - 203.0.113.10:3210
crypto:
  password: "длинный-случайный-пароль"
ip: 10.10.10.100/24

Узлы за NAT подключаются к облачному, узнают друг о друге и пытаются установить прямое соединение. Если адрес точки подключения меняется, используйте DNS-имя или механизм beacon.

Сценарий 3: доступ к подсети за узлом

Облачный сервер обслуживает внутреннюю подсеть 192.168.50.0/24, домашний компьютер должен в неё попадать. В режиме tun узел заявляет подсеть через claims, а адрес интерфейса задаётся с более широкой маской, чтобы все подсети VPN были достижимы через него (так рекомендует руководство VPNCloud):

# облачный сервер
listen: 3210
peers: []
crypto:
  password: "длинный-случайный-пароль"
ip: 10.10.10.30/16
claims:
  - 192.168.50.0/24

На облачном сервере нужно включить пересылку пакетов и разрешить её в межсетевом экране:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpncloud.conf
sudo sysctl --system
sudo iptables -A FORWARD -i vpncloud0 -o eth0 -d 192.168.50.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o vpncloud0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

На домашнем компьютере — маршрут в подсеть через интерфейс VPN:

sudo ip route add 192.168.50.0/24 dev vpncloud0

Если устройства подсети 192.168.50.0/24 не знают обратного маршрута в сеть VPN, добавьте его на их шлюзе или включите маскарадинг на облачном сервере для трафика из VPN (iptables -t nat -A POSTROUTING -s 10.10.0.0/16 -d 192.168.50.0/24 -j MASQUERADE).

Рекомендации

• Пароль сети — длинный и случайный; для строгих требований используйте ключи вместо пароля.
• Подсеть VPN не должна пересекаться с локальными сетями узлов.
• Несколько точек подключения в peers повышают отказоустойчивость, если одна из них недоступна.
• rp_filter. При маршрутизации подсетей строгая проверка обратного пути может отбрасывать пакеты; у VPNCloud есть параметр device.fix-rp-filter, подробнее о механизме — в статье про rp_filter.
• Выбор на будущее. Поскольку проект не развивается, исправлений уязвимостей ждать не приходится. Для новых сетей берите поддерживаемые решения из цикла Mesh VPN.