WireGuard на VDS: site-to-site и безопасный доступ к админке и БД

WireGuard стал де-факто стандартом для лёгкого и безопасного VPN у админов и DevOps. На VDS он решает сразу две задачи: закрыть административные сервисы (панели, SSH, базы) от внешнего мира и связать площадки в режиме site-to-site для доступа к внутренним подсетям. Ниже — пошаговый гайд: от установки и wg-quick до настройки firewall, маршрутизации и MTU, плюс типовые схемы и чек-листы.

Что будем строить и зачем

Мы поднимем на VDS узел WireGuard с интерфейсом wg0 и:

• дадим администраторам доступ к админке/БД только через VPN;
• свяжем две сети в схеме site-to-site через VDS-хаб;
• настроим firewall, routing, allowed-ips и mtu.

WireGuard минимален по коду и очень быстрый, а конфигурации читаются как обычные INI-файлы. Ключевые файлы — /etc/wireguard/wg0.conf и systemd-юнит wg-quick@wg0.

Топологии

1) Админ-доступ к отдельному серверу

Администратор подключается клиентом WireGuard, получает IP из VPN-подсети (например, 10.8.0.0/24) и попадает на VDS по адресу 10.8.0.1. На VDS админка и БД слушают только на адресе wg0 или ограничены firewall-правилом на эту подсеть.

2) Site-to-site через VDS

Две частные подсети (например, офис 192.168.10.0/24 и прод 10.20.0.0/24) обмениваются маршрутами через VDS-хаб. На концах могут быть роутеры или Linux-хосты с WireGuard-клиентом.

Предварительные требования

• VDS с публичным IPv4, обновлённая ОС (Ubuntu/Debian/Alma/Rocky).
• Доступ по SSH с sudo.
• План адресации: выберите отдельную VPN-подсеть, например 10.8.0.0/24.

Если сервера ещё нет — разверните стартовый инстанс на VDS и выделите ему статический UDP-порт под WireGuard.

Установка WireGuard

Примеры показаны для Debian/Ubuntu:

sudo apt update
sudo apt install wireguard wireguard-tools

Проверим наличие утилит:

wg --version
wg-quick --help

Подготовка ключей

Создадим пару ключей на VDS (сервер):

umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub

Клиентские ключи можно сгенерировать на клиентских машинах или временно на VDS (и затем передать безопасным способом):

wg genkey | tee ~/client1.key | wg pubkey > ~/client1.pub

Базовая конфигурация wg-quick на VDS (хаб)

Создаём /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <содержимое /etc/wireguard/server.key>
SaveConfig = false

# Разрешаем роутинг и NAT для выхода в интернет (по надобности)
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE

# Опциональная настройка MTU (настройте после тестов)
# PreUp = ip link set mtu 1420 dev wg0

Запускаем и включаем автозапуск:

sudo systemctl enable --now wg-quick@wg0
sudo wg show

Добавляем администратора (peer)

На клиенте сгенерируйте ключи, выясните внешний IP/порт VDS и составьте конфиг wg-quick на стороне клиента:

[Interface]
Address = 10.8.0.10/32
PrivateKey = <client1.key>
DNS = 10.8.0.1

[Peer]
PublicKey = <server.pub>
Endpoint = <VDS_public_IP>:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25

AllowedIPs у клиента определяет, какие подсети маршрутизируются в VPN. Если нужен доступ только к самому VDS, сузьте до 10.8.0.1/32. PersistentKeepalive помогает за NAT.

На VDS нужно добавить соответствующий peer (можно через правку файла):

[Peer]
PublicKey = <client1.pub>
AllowedIPs = 10.8.0.10/32

Применяем изменения:

sudo wg syncconf wg0 <(wg-quick strip wg0)

Проверяем хендшейк:

sudo wg show

Базовую защиту самого сервера (SSH, брутфорс, базовый firewall) разберите дополнительно в материале Безопасность VDS: SSH и firewall.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Ограничиваем админку и базу только по VPN

Firewall: разрешаем WireGuard и закрываем лишнее

Открываем UDP-порт WireGuard (пример на iptables):

sudo iptables -A INPUT -p udp --dport 51820 -j ACCEPT
sudo iptables -A INPUT -i wg0 -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -P INPUT DROP

Если используете nftables, базовые правила похожи по смыслу. Главное — разрешить udp/51820 и трафик с wg0.

Привязываем сервисы к адресу wg0

• SSH: в /etc/ssh/sshd_config задайте ListenAddress 10.8.0.1 (или добавьте его к существующим) и перезапустите SSH.
• Nginx-админка: слушайте только 10.8.0.1:8443 или используйте allow/deny по подсети 10.8.0.0/24.
• MySQL: в my.cnf укажите bind-address = 10.8.0.1.
• PostgreSQL: в postgresql.conf — listen_addresses = '10.8.0.1', а в pg_hba.conf добавьте host all all 10.8.0.0/24 md5 (или более строгие роли).

Дополнительно зафиксируйте это в firewall. Пример: разрешить MySQL только с VPN:

sudo iptables -A INPUT -i wg0 -p tcp --dport 3306 -s 10.8.0.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3306 -j DROP

Для PostgreSQL аналогично:

sudo iptables -A INPUT -i wg0 -p tcp --dport 5432 -s 10.8.0.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5432 -j DROP

Связка «сервис слушает только на wg0» плюс firewall «пускать с wg0/подсети» — даёт двукратную страховку.

Не забывайте про HTTPS и актуальные сертификаты для админки — помогут SSL-сертификаты.

Site-to-site через VDS: маршруты и allowed-ips

Предположим, у нас есть две площадки:

• Офисная подсеть: 192.168.10.0/24, за NAT.
• Прод-подсеть: 10.20.0.0/24, доступна с VDS или другой площадки.

VDS выступает хабом. Настройка peer-ов включает маршруты подсетей в AllowedIPs.

Конфиг peer-офиса

[Peer]
# Публичный ключ офиса
PublicKey = <office.pub>
# Разрешаем передавать офисную подсеть через этот peer
AllowedIPs = 192.168.10.0/24
PersistentKeepalive = 25

Конфиг peer-прода

[Peer]
# Публичный ключ прод-площадки
PublicKey = <prod.pub>
# Разрешаем передавать прод-подсеть через этот peer
AllowedIPs = 10.20.0.0/24
PersistentKeepalive = 25

На концах (офис/прод) в своих конфигурациях добавляем маршрут на противоположную подсеть через VDS. Суть: у офиса в разделе [Peer] на VDS-хаб указываем AllowedIPs = 10.20.0.0/24, а у прод-узла — AllowedIPs = 192.168.10.0/24. Это заставит wg-quick добавить соответствующие маршруты.

Если один из концов не умеет маршрутизировать в локальную сеть (NAT без статики), можно включить NAT на его стороне, чтобы трафик в соседнюю подсеть исходил с адреса VPN-интерфейса. На Linux-конце это делается так:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -o wg0 -s 192.168.10.0/24 -d 10.20.0.0/24 -j MASQUERADE

Это упрощает схему ценой потери исходных адресов внутри удалённой подсети (виден адрес из VPN), что иногда даже удобно для ACL. Для сценариев со сложным SNAT на нескольких IP посмотрите примерную методику в статье nftables: управление SNAT с несколькими IP.

AllowedIPs: маршруты и ACL одновременно

Ключевое отличие WireGuard от IPSec/OpenVPN: AllowedIPs — это и список префиксов, которые пойдут через туннель, и списки адресов, которые peer имеет право «анонсировать» (ACL). Ошибки здесь приводят к отсутствию связности или к «чёрным дырам».

• У клиента-админа: ставьте 10.8.0.1/32 (минимальный доступ) или 10.8.0.0/24 (вся VPN-подсеть).
• В site-to-site: на каждой стороне указывайте строго противоположную подсеть. Не добавляйте пересекающихся префиксов.
• Не злоупотребляйте 0.0.0.0/0, если не планируете весь трафик гнать через VPN.

MTU: как избежать фрагментации

По умолчанию WireGuard ставит MTU около 1420, но в облаках, при PPPoE или за каскадами NAT реальная безопасная величина может быть меньше. Симптомы: долгие открытия страниц, подвисающие SSH-сессии, «тихий» сброс некоторых запросов.

Подберите MTU экспериментально с ping (без фрагментации):

ping -M do -s 1372 10.8.0.10
# если ок, поднимайте размер
ping -M do -s 1380 10.8.0.10

Размер полезной нагрузки в ping плюс 28 байт заголовков IPv4 должна укладываться. После подбора задайте MTU для wg0 (например, 1380):

sudo ip link set dev wg0 mtu 1380

Чтобы это сохранилось, добавьте строку в wg0.conf (через PreUp или отдельный systemd-скрипт).

Маршрутизация и policy routing

wg-quick сам добавляет маршруты из AllowedIPs. Если нужна более тонкая политика (например, часть исходящего трафика сервера направлять через wg0), используйте policy routing:

sudo ip rule add fwmark 0x30 lookup 30
sudo ip route add default dev wg0 table 30
sudo iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 0x30

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

Диагностика

• wg show — смотрим хендшейки, байты, эндпоинты.
• ss -lunp | grep 51820 — слушает ли порт.
• journalctl -u wg-quick@wg0 — ошибки запуска.
• tcpdump -ni any udp port 51820 — идёт ли обмен пакетами.
• Проверьте net.ipv4.ip_forward=1 для роутинга.
• Убедитесь, что firewall не блокирует UDP/51820 и трафик с wg0.

Практика: закрываем Nginx-админку

Сценарий: админка на https://<ваш-домен>:8443 слишком легко брутфорсится. Делайте два шага:

1. Сделать listen 10.8.0.1:8443 (или оставить внешний порт, но разрешить только 10.8.0.0/24 в allow).
2. Дублировать ограничение в firewall (вход на 8443 только с wg0).

Тот же подход применим к админкам CMS, phpMyAdmin, панелям мониторинга.

Практика: ограничиваем доступ к MySQL и PostgreSQL

Минимальный набор для MySQL:

1. bind-address = 10.8.0.1 в конфиге.
2. Пользовательские привилегии только с 10.8.0.0/24.
3. Firewall: разрешить 3306 только с wg0, остальное — DROP.

Для PostgreSQL:

1. listen_addresses = '10.8.0.1'.
2. pg_hba.conf: сетевые правила для подсети VPN.
3. Firewall на 5432 по тем же принципам.

Безопасность и эксплуатация

• Храните приватные ключи с правами 0600, владелец root.
• SaveConfig = false защищает от неожиданных перезаписей конфига через wg set.
• Добавляйте новых peer-ов осознанно: минимум прав в AllowedIPs.
• Периодически обновляйте систему и пакет WireGuard.
• Ротируйте ключи раз в 6–12 месяцев или при компрометации.

Частые ошибки

• Забыли ip_forward=1 — трафик между подсетями не ходит.
• Пересекающиеся AllowedIPs у разных peer-ов — чёрные дыры или непредсказуемые маршруты.
• Firewall пропускает udp/51820, но режет трафик с wg0 — добавьте явный ACCEPT для интерфейса.
• Неправильный MTU — «зависания» и таймауты. Подберите и зафиксируйте.
• Сервисы слушают на 0.0.0.0 — открыты всему миру. Привяжите к wg0 и/или ограничьте firewall.

Финишный чек-лист

• wg0 поднят, есть адреса и ключи.
• По wg show виден свежий handshake.
• Админка, SSH, БД доступны только из подсети VPN.
• В site-to-site ходит трафик между подсетями, маршруты корректны.
• MTU подобран, проблем с фрагментацией нет.
• Firewall-правила сохранены и переживают перезагрузку (используйте системный способ сохранения).

Такой сетап на VDS даёт чёткую изоляцию административных интерфейсов и устойчивую связность между площадками. WireGuard прост в сопровождении, легко масштабируется (добавление peer — минуты) и хорошо сочетается с существующими политиками безопасности, будь то строгий firewall или сегментация сетей.