Налаштування WireGuard VPN для офісу: практичний гайд, оптимізація MTU та розв’язання проблем маршрутизації

П’ятниця, 15:00. У Slack починають сипатися тікети: розробники не можуть випустити терміновий реліз у GitLab, хоча звичайний ping до сервера проходить без проблем. Веб-інтерфейси внутрішніх сервісів зависають на етапі авторизації, а SSH-сесії просто відвалюються при спробі вивести великий лог. Проблема виявилася класичною для поспіхом налаштованих VPN — «чорна діра» MTU (Path MTU Discovery failure) на стику WireGuard та провайдерського PPPoE. Цей гайд — вижимка з нашого досвіду розгортання WireGuard для офісу на 150+ співробітників, де ми набили всі можливі гулі з маршрутизацією, автогенерацією конфігів та тюнінгом пакетів.

Чому WireGuard в офісі — це не «встановив і забув»

WireGuard витіснив OpenVPN з нашого стеку років чотири тому. Він швидший, не висаджує батарею на мобільних пристроях і конфігурується за 5 хвилин. Але в продакшені ви обов’язково зіткнетеся з його особливостями:

• Відсутність динамічної маршрутизації з коробки: кожен новий клієнт або підмережа вимагають прописування в конфігах та перезапуску (або використання wg syncconf).
• Проблеми з MTU: стандартний MTU у 1420 байт ламає TCP-сесії, якщо у клієнта «сіра» IP-адреса, PPPoE або мобільний модем.
• Статичні IP для клієнтів: доводиться вести облік адрес вручну або прикручувати сторонні оркестратори.

Конфігурація сервера (Hub) — реальний production-конфіг

Нижче наведено робочий конфіг шлюзу на базі Ubuntu Server 22.04. Зверніть увагу на правила iptables у секціях PostUp та PostDown. Вони не просто вмикають NAT, а й примусово затискають MSS для запобігання проблемам з MTU.

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = sEcrEtPrIvAtEkEyGoEsHeRe1234567890abcde=
MTU = 1360

# Правила для форвардингу, NAT та MSS Clamping
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -t mangle -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Клієнт 1 (Робочий ноутбук інженера)
[Peer]
PublicKey = cLiEnTpUbLiCkEy1234567890abcdefghijklm=
AllowedIPs = 10.8.0.2/32

# Клієнт 2 (Віддалений офіс / Site-to-Site)
[Peer]
PublicKey = oFfiCePuBlIcKeYabcdefghijklmnopqrstuvw=
AllowedIPs = 10.8.0.10/32, 192.168.2.0/24
PersistentKeepalive = 25

Налаштування клієнта (Road Warrior)

Для кінцевих користувачів ми віддаємо конфіг із заниженим MTU та увімкненим keepalive. Останнє критично важливо, якщо клієнт сидить за NAT (а це 99% домашніх провайдерів), інакше з’єднання закриватиметься за таймаутом з боку роутера.

# /etc/wireguard/wg0-client.conf
[Interface]
PrivateKey = cLiEnTpRiVaTeKeY1234567890abcdefghijkl=
Address = 10.8.0.2/32
DNS = 1.1.1.1, 8.8.8.8
MTU = 1360

[Peer]
PublicKey = sErVeRpUbLiCkEyGoEsHeRe1234567890abcde=
Endpoint = 198.51.100.50:51820
AllowedIPs = 10.8.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25

Траблшутинг MTU: чому «пінги ходять, а сайти не відкриваються»

Якщо ви підключилися до VPN, можете пінгувати хости, але при спробі відкрити веб-сторінку або стягнути файл усе «замерзає» — ви стали жертвою завеликого MTU. Стандартний кадр Ethernet — 1500 байт. Заголовок WireGuard забирає 60 або 80 байт (залежно від використання IPv4/IPv6). Якщо провайдер клієнта використовує PPPoE, це забирає ще 8 байт.

Щоб знайти точний розмір MTU, запустіть ping з забороною фрагментації з клієнтської машини до сервера:

# Для Linux
ping -M do -s 1332 10.8.0.1

# Для macOS
ping -D -s 1332 10.8.0.1

Збільшуйте значення -s (розмір корисного навантаження), поки не отримаєте повідомлення frag needed and DF set. Додайте до знайденого числа 28 байт (заголовки IP та ICMP) — це і буде ваш ідеальний MTU. На практиці значення 1360 є найбільш універсальним для уникнення проблем на будь-яких типах підключень, включаючи LTE.

Маршрутизація та системні налаштування Linux

Сервер не пересилатиме трафік між інтерфейсами, якщо ви не дозволите це на рівні ядра. Не наступайте на дитячі граблі, перевірте конфігурацію sysctl:

# Перевірка в реальному часі
sysctl net.ipv4.ip_forward

# Якщо повернуло 0, вмикаємо тимчасово:
sysctl -w net.ipv4.ip_forward=1

# І обов'язково фіксуємо в конфігу для збереження після ребуту:
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/99-wireguard.conf
sysctl -p /etc/sysctl.d/99-wireguard.conf

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

Коли щось іде не так, не гадайте на кавовій гущі. Використовуйте ці інструменти:

# Перегляд поточного стану з'єднань та об'єму трафіку
wg show

# Перевірка, чи взагалі долітають пакети на порт сервера
tcpdump -n -i eth0 udp port 51820

# Аналіз проходження трафіку всередині тунелю
tcpdump -n -i wg0 icmp or tcp port 80

Якщо wg show показує останній трансфер (latest handshake) більше ніж кілька хвилин тому — клієнт не може «достукатися» до сервера. Перевіряйте відкриті порти на фаєрволі провайдера та наявність білої IP-адреси на сервері.