WireGuard на VDS: выделенный IP, split tunnel и site-to-site

Зачем WireGuard на VDS и при чём тут «выделенный IP»

WireGuard — лёгкий и быстрый VPN, который хорошо ложится на задачи админа: безопасный доступ к инфраструктуре, объединение сетей (site-to-site), доступ к сервисам «как в локалке», а при необходимости — контролируемый выход в интернет через один адрес.

Когда говорят «WireGuard на VDS с выделенным IP», чаще всего имеют в виду один (или оба) сценария:

• Публичный IP endpoint: у сервера WireGuard на VDS есть стабильный публичный адрес, и клиенты всегда знают, куда подключаться.
• Единый egress IP: клиент отправляет интернет-трафик через туннель, и внешние сервисы видят IP вашей VDS (удобно для allowlist по IP и предсказуемого выхода).

Дальше разберём split tunnel и full tunnel, конфигурацию сервера и клиентов, правила nftables и сценарий site-to-site. По пути отмечу типовые ошибки, из-за которых «handshake есть, но ничего не работает».

Базовая модель: интерфейсы, адреса и логика маршрутизации

WireGuard поднимает виртуальный интерфейс (обычно wg0) и работает как L3 VPN: пакеты маршрутизируются, а не «бриджатся» как в L2.

Самая важная практичная мысль: в WireGuard маршрутизация во многом определяется AllowedIPs. Это одновременно:

• список «какие адреса разрешено ожидать от пира» (на стороне сервера/роутера);
• и список «что отправлять в туннель» (на стороне клиента при использовании wg-quick).

Типовая схема для одного сервера и нескольких клиентов:

• VDS (сервер): публичный адрес 203.0.113.10, VPN-адрес 10.10.10.1/24 на wg0
• Клиент (ноутбук): 10.10.10.2/32
• Клиент (офисный шлюз): 10.10.10.3/32

Если нужен full tunnel, на клиенте выставляют AllowedIPs = 0.0.0.0/0, ::/0, а на VDS включают форвардинг и NAT (masquerade) из VPN-сети в интернет. Если нужен split tunnel — в AllowedIPs оставляют только нужные подсети/хосты, и интернет у клиента остаётся напрямую.

Установка WireGuard на VDS (Debian/Ubuntu)

Ниже — минимальный, рабочий набор шагов. В примере публичный интерфейс VDS — eth0, VPN-сеть — 10.10.10.0/24.

1) Установка пакетов

apt update
apt install -y wireguard

2) Генерация ключей сервера

Сразу выставляем безопасные права через umask. Приватные ключи храните с правами 600 (или строже).

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

3) Включаем IP forwarding

Форвардинг нужен для маршрутизации между интерфейсами (для full tunnel и для site-to-site). Для чистого «доступа к самому VDS по VPN» он может и не понадобиться, но чаще включают сразу.

cat > /etc/sysctl.d/99-wireguard.conf << 'EOF'
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
EOF
sysctl --system

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

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

Подробнее

Конфигурация сервера: /etc/wireguard/wg0.conf

Файл конфигурации по умолчанию: /etc/wireguard/wg0.conf. Ниже пример с заделом под full tunnel (NAT), при этом split tunnel на клиентах тоже будет работать.

Важно: если у вас уже настроен nftables, лучше вынести правила в общий конфиг, а не создавать таблицы в PostUp/PostDown. Но для быстрого старта пример ниже удобен.

cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

# NAT для full tunnel: трафик из VPN-сети уходит в интернет с IP VDS
PostUp = nft add table inet wg; nft 'add chain inet wg post { type nat hook postrouting priority 100; }'; nft add rule inet wg post ip saddr 10.10.10.0/24 oifname "eth0" masquerade
PostDown = nft delete table inet wg

[Peer]
# Laptop
PublicKey = CLIENT1_PUBLIC_KEY
AllowedIPs = 10.10.10.2/32

[Peer]
# Office gateway
PublicKey = CLIENT2_PUBLIC_KEY
AllowedIPs = 10.10.10.3/32
EOF

Замените SERVER_PRIVATE_KEY на содержимое /etc/wireguard/server.key. Клиентские публичные ключи добавите позже (после генерации на клиентах).

Запуск

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

Firewall (nftables): что открыть и как не сломать маршрутизацию

Минимум для WireGuard: входящий UDP на порт 51820 (или ваш). Дальше правила зависят от сценария:

• Split tunnel только «к VDS»: чаще всего достаточно открыть UDP-порт WireGuard и разрешить доступ к нужным локальным сервисам на самом VDS со стороны wg0.
• Full tunnel: нужен форвардинг wg0 → eth0 и NAT.
• Site-to-site: нужен форвардинг между wg0 и интерфейсом/сетью, куда вы маршрутизируете удалённую подсеть.

Ниже — пример «скелета» nftables. Если у вас уже есть правила, аккуратно интегрируйте изменения, а не заменяйте конфиг целиком.

cat > /etc/nftables.conf << 'EOF'
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    iifname "lo" accept
    ct state established,related accept

    # SSH (пример)
    tcp dport 22 accept

    # WireGuard
    udp dport 51820 accept

    # ICMP полезен для PMTUD/диагностики
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;

    ct state established,related accept

    # Full tunnel: разрешаем клиентам wg выходить в интернет через VDS
    iifname "wg0" oifname "eth0" accept
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}

table inet nat {
  chain postrouting {
    type nat hook postrouting priority 100;

    # NAT для full tunnel
    ip saddr 10.10.10.0/24 oifname "eth0" masquerade
  }
}
EOF
systemctl enable --now nftables
nft list ruleset

Если включили NAT и форвардинг, клиент при full tunnel будет выходить в интернет с IP вашей VDS — это и есть «выделенный внешний IP для клиента» в прикладном смысле.

Если хотите глубже разобраться, как аккуратно вести правила между iptables и nftables и не ловить сюрпризы, пригодится материал про подходы к firewall на Linux: iptables vs nftables.

Клиентские конфиги: split tunnel и full tunnel

На клиенте (Linux) ставите пакет wireguard, генерируете ключи и создаёте конфиг. На десктопах можно использовать GUI, но формат одинаковый.

Генерация ключей на клиенте

umask 077
wg genkey | tee client1.key | wg pubkey > client1.pub

Содержимое client1.pub добавьте на сервер в секцию [Peer].

Split tunnel (рекомендуемый «админский» сценарий)

Split tunnel означает: через VPN идёт только то, что вы явно направили (например, приватные подсети, мониторинг, админки), а обычный интернет остаётся напрямую.

[Interface]
PrivateKey = CLIENT1_PRIVATE_KEY
Address = 10.10.10.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.10.10.0/24, 192.168.50.0/24
PersistentKeepalive = 25

Через туннель пойдёт доступ к самой VPN-сети 10.10.10.0/24 и к удалённой подсети 192.168.50.0/24 (например, за офисным шлюзом). Остальное — мимо VPN.

Full tunnel (весь интернет через VDS)

Full tunnel нужен, когда вы хотите, чтобы внешний IP был IP вашей VDS.

[Interface]
PrivateKey = CLIENT1_PRIVATE_KEY
Address = 10.10.10.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Если full tunnel «поднялся, но не работает» — почти всегда проблема в NAT/форвардинге/политике firewall на сервере или в MTU (см. ниже).

Site-to-site: объединяем две сети через WireGuard

Site-to-site — это когда по обе стороны есть локальные подсети, и вы хотите, чтобы хосты из одной сети ходили в другую (например, офис 192.168.10.0/24 и подсеть на VDS 10.20.0.0/24).

WireGuard не делает «магический мост»: это L3, поэтому нужны маршруты, форвардинг и разрешения firewall.

Ключевая логика

• На пире A в AllowedIPs для пира B указываются сети B.
• На пире B в AllowedIPs для пира A указываются сети A.
• На обоих узлах включён форвардинг, а firewall разрешает форвард между нужными интерфейсами.

Пример: VDS как хаб, офис как пир

Пусть за офисным шлюзом сеть 192.168.10.0/24. На VDS добавляем пир «office», где AllowedIPs включает и VPN-адрес офиса, и офисную подсеть:

[Peer]
PublicKey = OFFICE_PUBLIC_KEY
AllowedIPs = 10.10.10.3/32, 192.168.10.0/24
PersistentKeepalive = 25

На офисном шлюзе (пир VDS) указываем, какие сети доступны через туннель, например VPN-сеть и сервисную подсеть на VDS:

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.10.10.0/24, 10.20.0.0/24
PersistentKeepalive = 25

Дальше в офисной сети нужно распространить маршрут до 10.10.10.0/24 и 10.20.0.0/24 через офисный шлюз: либо статикой на хостах, либо (чаще) через DHCP-опции/настройки роутера.

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

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Split tunnel «по-взрослому»: не ломаем интернет и не раздуваем доступ

Split tunnel обычно лучше full tunnel для ежедневной работы: обновления, мессенджеры и «обычный интернет» идут напрямую, а админка/БД/внутренние панели — через VPN.

• Разделяйте “доступ” и “выход”: если вам нужно только попасть в приватные подсети, не включайте NAT и не делайте AllowedIPs = 0.0.0.0/0.
• Будьте точны в AllowedIPs: на сервере каждому пиру — его /32 и только необходимые подсети (если это шлюз). На клиенте — только то, что реально должно ехать в туннель.

Технически можно настроить «выход на один конкретный публичный IP через VPN» (policy routing или подмена маршрута к конкретному адресу), но это отдельная конструкция: она легко конфликтует с локальными маршрутами и диагностикой. В большинстве случаев проще либо честный full tunnel, либо честный split tunnel по подсетям.

MTU и ситуация «handshake есть, а сайты не открываются»

Классика: туннель поднялся, wg show показывает latest handshake, но часть сайтов «висит» (особенно при full tunnel). Часто виноваты MTU/PMTUD и слишком жёсткий firewall.

Если полностью вырезать ICMP, вы ломаете Path MTU Discovery: большие пакеты начинают теряться, и симптомы выглядят как «странные зависания» без явной ошибки.

Практические шаги:

• Не режьте ICMP «в ноль» без веской причины.
• Если подозрение на MTU — задайте MTU на wg0 ниже (часто работает 1420, иногда нужно 1380).

Пример явной настройки MTU в конфиге:

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
MTU = 1420

Роуминг, NAT и PersistentKeepalive

WireGuard нормально переносит смену IP у клиента (роуминг): он привязан к ключам, а endpoint обновляется по факту обмена пакетами. Но если клиент за NAT и долго молчит, у NAT может «протухнуть» состояние, и сервер не сможет первым достучаться до клиента.

Для таких клиентов обычно включают PersistentKeepalive = 25 на стороне клиента. Это поддерживает состояние NAT, отправляя минимальный пакет раз в 25 секунд.

Эксплуатация и дебаг: что проверить в первую очередь

Статус WireGuard

wg show
systemctl status wg-quick@wg0

Смотрите на latest handshake, счётчики transfer и корректность allowed ips для каждого пира.

Маршруты и адреса

ip -brief address
ip route
ip route get 8.8.8.8

При split tunnel убедитесь, что маршрут к нужной подсети уходит в wg0. При full tunnel — что дефолтный маршрут на клиенте действительно уходит в VPN, а на сервере разрешён форвардинг и NAT.

Форвардинг и firewall

sysctl net.ipv4.ip_forward
nft list ruleset

Частая ошибка: WireGuard «как бы работает», но политика forward режет трафик, и вы не попадаете ни в удалённые сети, ни в интернет при full tunnel.

Минимальные рекомендации по безопасности

• На сервере не раздавайте широкие AllowedIPs «на всякий случай». Каждый пир должен иметь только свой /32 (и нужные подсети, если это шлюз).
• Ограничивайте доступ к сервисам по VPN-адресам: админки и базы лучше слушать только VPN-сеть, либо разрешать доступ firewall-правилами только со стороны wg0.
• Не смешивайте разные политики: «VPN для админки» и «VPN как выход в интернет» лучше держать раздельно (хотя бы концептуально), иначе легко выдать лишний доступ.
• Продумайте отзыв: в WireGuard отзыв — это удаление пира/ключа из конфигурации и перезагрузка интерфейса. Хорошо, когда это рутина, а не «экстренный ремонт».

Чек-лист перед запуском

1. Определили сценарий: split tunnel, full tunnel или site-to-site.
2. Выбрали VPN-сеть, которая не пересекается с вашими локальными подсетями.
3. На сервере включён форвардинг (если нужен).
4. Firewall: открыт UDP-порт WireGuard, разрешён нужный форвардинг, NAT включён только при full tunnel.
5. На каждом пире корректные AllowedIPs (это и доступ, и маршрутизация).
6. Для клиентов за NAT включён PersistentKeepalive.
7. ICMP не вырезан полностью; при проблемах — проверили MTU.

Итоги

WireGuard на VDS — быстрый и предсказуемый VPN под практичные задачи: точечный split tunnel для администрирования, полноценный site-to-site между подсетями и full tunnel для выхода в интернет с IP VDS. Держите в фокусе три вещи — AllowedIPs, форвардинг и firewall — и конфигурация будет обслуживаемой, а не «магией на удаче».

Если нужно развить тему именно в сторону межсетевых связок, посмотрите материал про практику site-to-site на WireGuard: маршруты и типовые грабли.