WireGuard VPN для віддаленого офісу: практичний досвід, конфіги та вирішення факапів у production

Вівторок, 14:15. Легасі-монстр Cisco ASA на боці варшавського офісу вчергове вирішив, що Phase 2 в IPsec йому більше не потрібна. 150 розробників миттєво втратили доступ до стейджингу в AWS. Замість того, щоб знову дебажити заплутані логи IPsec, гратися з фазами та погоджувати шифри, ми за 15 хвилин підняли WireGuard на копійчаній віртуалці в AWS та налаштували піринг. Цей «тимчасовий» милиця-рішення працює вже 14 місяців без жодного ребуту чи втручання адмінів. Нижче — сухий залишок нашого досвіду, готові конфіги та граблі, на які ми наступили.

Чому IPsec та OpenVPN ідуть на пенсію

Давайте чесно: IPsec — це оверінжиніринг з 90-х. Налаштування StrongSwan або Cisco ASA вимагає занадто багато розумових зусиль, а крок ліворуч-праворуч приводить до мовчазного падіння тунелю. OpenVPN — повільний однопотоковий софт, який витискає максимум 100-150 Мбіт/с на одному ядрі процесора і вимагає постійної підтримки сертифікатів.

WireGuard працює в просторі ядра (kernel space), використовує сучасну криптографію (ChaCha20-Poly1305) і на практиці видає майже лінійну швидкість гігабітного порту з мінімальним навантаженням на CPU. Але у нього є свої нюанси: відсутність динамічної маршрутизації з коробки та специфічна робота з MTU.

Production-конфіг сервера (Hub в AWS)

Ми використовуємо Ubuntu 22.04 LTS. Конфіг лежить у /etc/wireguard/wg0.conf. Зверніть увагу на правила iptables — вони автоматично налаштовують NAT та форвардинг при піднятті інтерфейсу.

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = sE...[SERVER_PRIVATE_KEY]...=

# Автоматичний NAT та форвардинг трафіку
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# Peer 1: Офісний роутер (Mikrotik/Linux)
[Peer]
PublicKey = fT...[OFFICE_PUBLIC_KEY]...=
AllowedIPs = 10.8.0.2/32, 192.168.1.0/24
PersistentKeepalive = 25

Production-конфіг клієнта (Gateway у віддаленому офісі)

На боці офісу стоїть Linux-шлюз (або Mikrotik з RouterOS v7, де WireGuard підтримується нативно). Конфіг для Linux-шлюзу:

[Interface]
Address = 10.8.0.2/24
PrivateKey = aK...[OFFICE_PRIVATE_KEY]...=
MTU = 1360

[Peer]
PublicKey = kY...[SERVER_PUBLIC_KEY]...=
Endpoint = 198.51.100.1:51820
AllowedIPs = 10.8.0.0/24, 172.16.0.0/12
PersistentKeepalive = 25

Головні факапи та їх вирішення

1. MTU Hell (Пекло з розміром пакетів)

Найчастіша проблема: тунель піднявся, пінги йдуть, але важкі сайти або SSH-сесії «зависають» при передачі даних. Це класична проблема MTU. Стандартний MTU для WireGuard — 1420 байт. Але якщо ваш провайдер використовує PPPoE, L2TP або ви працюєте через LTE-беклінк, реальний MTU каналу менший.

Рішення: Жорстко прописати MTU = 1360 (або навіть 1280 для поганих каналів) у конфігу клієнта. Також обов’язково затиснути MSS на рівні iptables:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

2. Проблема «мовчазного» NAT (Silent Drop)

Оскільки WireGuard працює по UDP і не підтримує постійне з’єднання (він stateless), офісний роутер за NAT швидко видаляє запис про трансляцію портів зі своєї таблиці, якщо немає трафіку. Як результат — сервер не може ініціювати з’єднання до офісу.

Рішення: Обов’язкове використання параметра PersistentKeepalive = 25 у конфігах обох сторін. Це змушує WireGuard кожні 25 секунд відправляти пусті пакети для підтримки NAT-сесії відкритою.

3. Динамічні IP-адреси та DNS

WireGuard резолвить доменне ім’я Endpoint лише один раз — під час старту інтерфейсу. Якщо у вашого офісу чи сервера змінився IP (наприклад, провайдер перепідключив сесію), тунель помре і сам не підніметься.

Рішення: Використовувати легкий bash-скрипт у cron на боці клієнта, який перевіряє статус з’єднання і робить рестарт інтерфейсу, якщо пінги зникли:

#!/bin/bash
ping -c 3 10.8.0.1 > /dev/null || systemctl restart wg-quick@wg0

Корисні команди для швидкого дебагу

Перевірити поточний статус тунелю, обсяг переданого трафіку та час останнього рукостискання (handshake):

wg show

Подивитися, чи взагалі долітають UDP-пакети на порт сервера:

tcpdump -n -i eth0 udp port 51820

Моніторинг трафіку всередині самого тунелю:

tcpdump -n -i wg0

Висновки та рекомендації

WireGuard — це найкраще, що траплялося з VPN-технологіями за останні роки. Він позбавляє від необхідності тримати штатних сертифікованих інженерів Cisco для підтримки банального офісного тунелю. Головне — відразу занижувати MTU до безпечних лімітів та не забувати про Keepalive.