WireGuard: проверка конфигурации и AllowedIPs в изолированных netns

Ошибка в конфигурации VPN проявляется потерей доступа или, хуже, туннелем, который «работает», но пропускает лишнее. Проверить конфигурацию WireGuard можно заранее на одной машине: сервер и клиент запускаются в изолированных сетевых пространствах имён (netns), соединённых виртуальным кабелем. Вы получаете настоящее рукопожатие, трафик и проверку правил AllowedIPs без затрагивания рабочих интерфейсов. Ниже конфигурации, скрипт и ожидаемые результаты.

Статья опирается на логику направления «Сетевая безопасность» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена на Debian 12 (ядро 6.1, wireguard-tools 1.0.20210914) от root: после скрипта пространств имён и интерфейсов не осталось, рабочие настройки сети не менялись. Установка и развёртывание сервера: WireGuard: настройка VPN-сервера; изоляция тестов по тому же принципу: проверка правил в netns.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Конфигурации

Скрипт ниже создаёт два файла в формате wg-quick. Сервер (wgs0.conf) и клиент (wgc0.conf):

Принципы: на сервере в AllowedIPs каждого клиента стоит только его адрес с маской /32, на клиенте — только то, что должно идти через туннель (здесь адрес сервера; для выхода всего трафика через VPN — 0.0.0.0/0, но осознанно). Предварительный ключ добавляет защиту на случай появления квантового взлома открытых ключей и усиливает аутентификацию.

Скрипт проверки

Запускайте от root на машине, где установлены wireguard-tools и поддержка WireGuard в ядре (современные ядра Linux её содержат). Скрипт создаёт пространства zwgsrv, zwgcli и виртуальный кабель, генерирует временные ключи, запускает туннель, проверяет связь и полностью убирает за собой.

#!/bin/bash
set -u
S=zwgsrv; C=zwgcli
cleanup() { ip netns del $S 2>/dev/null; ip netns del $C 2>/dev/null; rm -rf /tmp/zwg; }
trap cleanup EXIT; cleanup
umask 077; mkdir -p /tmp/zwg; cd /tmp/zwg
SK=$(wg genkey); SP=$(echo $SK | wg pubkey); CK=$(wg genkey); CP=$(echo $CK | wg pubkey); PSK=$(wg genpsk)
cat > wgs0.conf <<EOF
[Interface]
Address = 10.77.0.1/24
ListenPort = 51820
PrivateKey = $SK

[Peer]
# клиент laptop-anna
PublicKey = $CP
PresharedKey = $PSK
AllowedIPs = 10.77.0.2/32
EOF
cat > wgc0.conf <<EOF
[Interface]
Address = 10.77.0.2/24
PrivateKey = $CK

[Peer]
PublicKey = $SP
PresharedKey = $PSK
Endpoint = 192.0.2.1:51820
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = 25
EOF
ip netns add $S; ip netns add $C
ip link add zwgv0 type veth peer name zwgv1
ip link set zwgv0 netns $S; ip link set zwgv1 netns $C
ip -n $S addr add 192.0.2.1/24 dev zwgv0; ip -n $S link set zwgv0 up; ip -n $S link set lo up
ip -n $C addr add 192.0.2.2/24 dev zwgv1; ip -n $C link set zwgv1 up; ip -n $C link set lo up
command -v wg-quick || { echo "wg-quick не установлен"; exit 3; }
echo "права файлов:"; stat -c '%a %n' wgs0.conf wgc0.conf
ip netns exec $S wg-quick up ./wgs0.conf 2>&1 | grep -vE "^\[#\] (ip link add|wg setconf|ip -4 address|ip link set mtu|ip link set up)" | head -3
ip netns exec $C wg-quick up ./wgc0.conf 2>&1 | grep -vE "^\[#\] (ip link add|wg setconf|ip -4 address|ip link set mtu|ip link set up)" | head -3
echo "=== пинг"; ip netns exec $C ping -c 2 -W 2 -q 10.77.0.1 | tail -2
echo "=== handshake"; ip netns exec $S wg show wgs0 | grep -E "latest handshake|allowed ips|endpoint"
echo "=== wg-quick предупреждение о правах"; chmod 644 wgc0.conf; ip netns exec $C wg-quick down ./wgc0.conf >/dev/null 2>&1; ip netns exec $C wg-quick up ./wgc0.conf 2>&1 | grep -i "world accessible" | head -1

Что проверяется и ожидаемый результат

Дополнительные проверки, выполненные отдельным запуском на том же стенде (команды wg set вместо wg-quick, с теми же параметрами):

Последние две строки показывают главное свойство WireGuard: сервер отвечает только на пакеты от зарегистрированных ключей, а AllowedIPs работает как фильтр источника и как таблица маршрутов.

Типовые ошибки в конфигурации

Эксплуатация ключей

• Закрытые ключи создаются на устройстве клиента и не передаются; на сервер передаётся только открытый ключ.
• Для каждого устройства свой ключ: потеря устройства закрывается удалением одного клиента (wg set wg0 peer ОТКРЫТЫЙ_КЛЮЧ remove и удаление из файла).
• Список клиентов ведите в реестре с владельцем и датой выдачи; при увольнении отзывайте доступ: отзыв прав при увольнении.
• Для критичного доступа добавьте второй фактор на уровне приложений или шлюза: MFA для SSH и WireGuard.
• Журналы подключений: WireGuard не пишет события входа сам; используйте время последнего рукопожатия из wg show и собирайте его в мониторинг.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Сетевая безопасность» (материалы направления, карта зрелости). Уровень 2 требует удалённого доступа через VPN с контролем: воспроизводимая проверка конфигурации и учёт ключей делают этот доступ управляемым.

Как проверить

1. Скрипт проверки выполняется без ошибок: рукопожатие есть, пинг проходит, подмена адреса и неверный ключ блокируются.
2. На сервере у каждого клиента в AllowedIPs только его адрес /32, файлы с ключами имеют права 600.
3. Порт UDP открыт только нужным адресам или защищён ограничениями; клиенты за NAT имеют keepalive.
4. Список клиентов и их ключей ведётся, отзыв проверен на тестовом клиенте.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Документация и описание протокола WireGuard: wireguard.com; руководства man wg, man wg-quick.
• NIST SP 800-77 Rev. 1, Guide to IPsec VPNs (общие принципы защищённого удалённого доступа): csrc.nist.gov. Международная практика, не российский норматив.