VPN-инфраструктура на нескольких VPS: балансировка и резерв

Инфраструктура VPN на одном сервере — удобное решение для небольшого проекта, но как только речь заходит о реальной эксплуатации, появляется риск: отказ единственного VPS остановит весь канал. Рассказываем, как построить VPN-инфраструктуру на нескольких VPS, распределить трафик и автоматически переживать сбои.

Почему одного VPS недостаточно

Многие администраторы считают, что достаточно одного надёжного сервера. Однако даже крупные дата-центры регулярно сообщают о DDoS-атаках, сбоях в сети и плановых работах. Для VPN-сервиса неприемлемо, когда работники теряют доступ к внутренним ресурсам в конце квартала.

• Резервирование: при отказе одного узла пользователи продолжают работать через другой.
• Балансировка нагрузки: несколько серверов распределяют трафик, снижая задержки и повышая пропускную способность.
• Географическая близость: выбирая VPS в разных регионах, вы обеспечиваете низкий пинг для разных групп пользователей.

Ниже опишем схему, которая использует WireGuard в качестве VPN-протокола и Nginx Stream в качестве балансировщика UDP-трафика. Это один из самых простых и надёжных вариантов для самостоятельно настраиваемых серверов.

Архитектура отказоустойчивой VPN-инфраструктуры

Базовая схема выглядит так:

1. Два и более сервера выполняют роль VPN-узлов (backend). На них поднят WireGuard, они имеют постоянные туннели друг с другом и с балансировщиком.
2. Фронт-сервер принимает входящие соединения от клиентов и перенаправляет их на один из backend-узлов.
3. Для автоматического переключения используется Nginx Stream с passive health check: если backend перестал отвечать, балансировщик исключает его из ротации на несколько секунд.

Важно, чтобы фронт-сервер сам не был единственной точкой отказа. Если нужно гарантировать бесперебойную работу, фронт стоит дублировать с помощью VRRP (Keepalived) и плавающего IP. В противном случае мы просто перенесли проблему «съехал диск» на «съехал балансировщик».

VPN-протоколы различаются, и это влияет на архитектуру:

• WireGuard — работает поверх UDP, поэтому для балансировки нужен L4-балансировщик с поддержкой UDP (например, Nginx Stream).
• OpenVPN — чаще работает поверх TCP, поэтому можно использовать классический HAProxy или Nginx.
• IPsec IKEv2 — тоже использует UDP; балансировка сложнее из-за необходимости синхронизации SAD/SPD.

Пошаговая настройка: WireGuard + Nginx Stream

Шаг 1. Готовим серверы

Создайте минимум три VPS: два backend-узла (например, в разных регионах) и один фронт. Актуальность версий и наличие необходимого ПО проверяйте на официальных сайтах дистрибутива. Рекомендуем использовать свежие LTS-версии Ubuntu или Debian.

# на каждом сервере
apt update && apt upgrade -y
apt install -y wireguard nginx

Если используете только OpenVPN, замените wireguard на openvpn. Управление файрволом (ufw или nftables) настройте так, чтобы разрешить UDP-порт WireGuard.

Шаг 2. Настраиваем WireGuard на backend

На каждом backend-сервере сгенерируйте пару ключей:

wg genkey | tee privatekey | wg pubkey > publickey

Создайте файл /etc/wireguard/wg0.conf. Пример для первого узла (10.10.0.1):

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <private_key_1>
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# Client 1
[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.10.0.10/32

# Second backend
[Peer]
PublicKey = <peer_public_key>
Endpoint = 10.20.0.2:51820
AllowedIPs = 10.10.0.0/24

Аналогично настройте второй узел. Не забудьте включить ip_forward: добавить в /etc/sysctl.conf строку net.ipv4.ip_forward=1 и выполнить sysctl -p.

Шаг 3. Настраиваем Nginx Stream на фронте

В nginx.conf добавьте include фрагмента stream, либо создайте отдельный конфиг. Для UDP-балансировки WireGuard используйте модуль ngx_stream_core_module (входит в стандартную поставку nginx). Пример:

stream {
    upstream wireguard_backend {
        server 10.20.0.1:51820 max_fails=1 fail_timeout=15s;
        server 10.20.0.2:51820 max_fails=1 fail_timeout=15s;
    }
    server {
        listen 51820 udp reuseport;
        proxy_pass wireguard_backend;
        proxy_responses 1;
        proxy_timeout 10s;
    }
}

Ключевые параметры: max_fails и fail_timeout задают алгоритм переключения при недоступности одного из backend. Значение proxy_responses 1 говорит nginx, что каждое соединение будет получать хотя бы один ответ; это важно для корректной работы UDP-проксирования.

Шаг 4. Клиент и проверка

В конфигурации WireGuard клиента укажите публичный адрес фронт-сервера и порт 51820. Остальная настройка не отличается от подключения к одиночному серверу. Для переключения между серверами клиенту не нужно менять конфигурацию — всё происходит на стороне инфраструктуры.

Сравнение подходов и сценариев

Какой вариант выбрать? Если важна пропускная способность — берите балансировщик. Если нужно пережить отказ фронта — добавьте Keepalived. Если вы готовы жертвовать авто-резервом ради простоты — подойдёт DNS round-robin, но только для некритичных задач.

Диагностика и типовые проблемы

После настройки обязательно проверьте работу. Последовательность действий:

1. ping 10.20.0.1 с фронт-сервера — проверка связности.
2. wg show на backend-серверах — убедитесь, что handshake выполняется.
3. ss -ulpn | grep 51820 — слушает ли nginx UDP-порт.
4. tail -f /var/log/nginx/stream.log — следите за ошибками соединений.
5. Отключите один backend (например, systemctl stop wg-quick@wg0) и подключитесь клиентом. Через несколько секунд nginx должен направить трафик на второй узел.

Если соединение не устанавливается, проверяйте правила файрвола и параметр AllowedIPs: слишком широкий диапазон может нарушить маршрутизацию. Также убедитесь, что на фронте включён NAT для исходящих пакетов.

Резюмируем: VPN-инфраструктура на нескольких VPS требует продуманной архитектуры, но награждает стабильностью. Начните с двух backend-узлов и одного балансировщика, затем добавьте мониторинг и резервирование фронта. Проверяйте актуальные возможности и лимиты на официальных сайтах используемого ПО, чтобы не попасть на неприятные сюрпризы в продакшене.