WireGuard вместо IPsec: миграция корпоративного VPN

Корпоративные VPN на IPsec существуют уже десятилетиями. Они надёжны, поддерживаются всем мыслимым оборудованием и хорошо изучены. Но каждый, кто хоть раз настраивал IKEv2 с сертификатами вручную, знает цену этой надёжности — сотни строк конфига, тонны опций и постоянное ощущение, что что-то пойдёт не так. WireGuard предлагает радикально другой подход: минимализм как принцип проектирования.

IPsec — это не один протокол, а целое семейство: IKEv1/v2, ESP, AH, различные режимы шифрования. Для enterprise это плюс — гибкость и совместимость. Для команды из пяти devops-инженеров, которым нужно связать три офиса и удалённых сотрудников — это боль.

Типичные проблемы с IPsec:

• Конфигурация на 200+ строк для простого site-to-site
• Сложная отладка: ipsec statusall выдаёт простыню текста
• NAT traversal работает, но с оговорками
• Производительность зависит от реализации и железа

WireGuard написан с нуля как минималистичный протокол. Весь код ядра — около 4000 строк. Для сравнения, OpenVPN — десятки тысяч.

WireGuard работает на уровне ядра Linux (модуль wireguard), использует современную криптографию:

• ChaCha20 для шифрования
• Poly1305 для аутентификации
• Curve25519 для обмена ключами
• BLAKE2s для хеширования

Никаких переговоров об алгоритмах, никаких устаревших cipher suite. Один набор — и он современный.

На каждом узле генерируем пару ключей:

wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
chmod 600 /etc/wireguard/privatekey
cat /etc/wireguard/privatekey
cat /etc/wireguard/publickey

# /etc/wireguard/wg0.conf на сервере
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <PRIVATE_KEY_SERVER>

# Включаем форвардинг
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]
# Офис Москва
PublicKey = <PUBLIC_KEY_MOSCOW>
AllowedIPs = 10.10.0.2/32, 192.168.1.0/24

[Peer]
# Офис Питер
PublicKey = <PUBLIC_KEY_SPB>
AllowedIPs = 10.10.0.3/32, 192.168.2.0/24

# /etc/wireguard/wg0.conf на клиенте (офис Москва)
[Interface]
Address = 10.10.0.2/24
PrivateKey = <PRIVATE_KEY_MOSCOW>

[Peer]
PublicKey = <PUBLIC_KEY_SERVER>
Endpoint = vpn.company.ru:51820
AllowedIPs = 10.10.0.0/24, 192.168.2.0/24
PersistentKeepalive = 25

Запуск и автозапуск:

systemctl enable --now wg-quick@wg0
wg show  # статус туннеля

Для связи офисных подсетей через WireGuard включаем форвардинг на сервере:

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

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

Тест на серверах с Intel Xeon E5−2690, 10GbE:

WireGuard выигрывает за счёт работы в пространстве ядра и современных алгоритмов, которые аппаратно ускоряются на современных процессорах.

WireGuard — UDP only. Если у клиента заблокирован UDP (корпоративный файрвол, отель), туннель не поднимется. Решение: udp2raw или проброс через TCP-туннель, но это усложняет архитектуру.

Нет динамической маршрутизации. IPsec можно интегрировать с BGP через OSPF. WireGuard — статика. Для большинства компаний это не проблема, но при сложной топологии придётся смотреть на надстройки типа innernet или netbird.

Нет встроенного PKI. Управление ключами — ваша ответственность. При десятках пиров стоит посмотреть на Headscale (self-hosted Tailscale) или Netbird.

Для большинства компаний с простой топологией VPN (hub-and-spoke, несколько офисов + remote workers) WireGuard — очевидный выбор. Конфиг на 20 строк вместо 200, производительность в разы выше, поверхность атаки минимальна. Если у вас нет жёстких требований к совместимости со старым оборудованием — мигрируйте.