WireGuard на сервере: частые ошибки и решения

MAATRIX

WireGuard ставится за пять минут, но именно на мелочах чаще всего всё и ломается: туннель поднимается, а интернета нет; клиент подключается, но handshake не проходит; после перезагрузки сервера доступ пропадает. Ниже — разбор типичных ошибок WireGuard на сервере и конкретные команды, которыми их находят и чинят, без гадания и переустановок с нуля.

С чего начинать диагностику

Прежде чем менять конфиги наугад, посмотрите фактическое состояние. Основная команда — wg show: она показывает интерфейсы, публичные ключи пиров, время последнего handshake и объём переданных данных. Это ваш главный индикатор: по нему сразу видно, живёт ли соединение вообще.

wg show
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 50 --no-pager

Если в выводе wg show для пира нет строки latest handshake, значит пакеты до сервера не доходят или не расшифровываются — проблема на уровне сети, портов или ключей. Если handshake есть, но нет интернета — проблема в маршрутизации и NAT на сервере. Это первое разветвление, от которого зависит всё дальнейшее, и именно с него стоит начинать, а не с перебора настроек.

Ещё две команды полезны на старте. ip a show wg0 покажет, поднят ли сам интерфейс и получил ли он адрес из туннельной подсети. Пинг внутреннего адреса сервера (ping -c3 10.8.0.1, подставьте свой) со стороны клиента отделяет проблему шифрованного канала от проблемы выхода в интернет. Если внутренний адрес пингуется, туннель жив, и копать нужно в сторону NAT и DNS, а не ключей. Приучите себя собирать эту тройку — состояние интерфейса, статус сервиса и лог — прежде чем что-то менять.

Handshake не проходит вообще

Самая частая причина — до сервера не доходит UDP-трафик. WireGuard работает по UDP (обычно порт 51820), и его легко забыть открыть в фаерволе или в облачной панели провайдера. Проверьте, что порт слушается и открыт:

ss -lunp | grep 51820
ufw allow 51820/udp

Если используете облачную панель с security groups, правило для UDP-порта нужно добавить и там — локальный ufw про внешний фаервол облака не знает, и это самый частый источник тупика «сервер настроен, а handshake нулевой». Второй по частоте случай — несовпадение ключей: публичный ключ клиента в конфиге сервера должен точно соответствовать приватному ключу клиента, и наоборот. Одна лишняя копипаста с пробелом или переносом строки ломает всё молча, без внятной ошибки. Сверьте PublicKey в секции [Peer] на сервере с тем, что выдаёт клиент.

Третья причина — неверный Endpoint. В клиентском конфиге он должен указывать на реальный внешний IP сервера и правильный порт, а не на серый адрес за NAT. Если сервер сам стоит за NAT (например, домашний), нужен проброс UDP-порта на роутере. И проверьте очевидное: совпадает ли номер порта в ListenPort сервера с портом в Endpoint клиента — рассинхрон здесь тоже даёт вечно пустой handshake.

Туннель поднялся, но интернета нет

Handshake есть, пинг до внутреннего адреса сервера идёт, а сайты не открываются — значит сервер не пересылает и не маскирует трафик. Нужны две вещи: включённый IP-форвардинг и правило NAT (masquerade).

sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Важная деталь: в правиле NAT подставляйте имя вашего внешнего интерфейса. Узнать его можно командой ip route get 8.8.8.8 — интерфейс указан после dev. Часто в шаблонах прописан eth0, а на сервере интерфейс называется ens3 или enp1s0, и masquerade просто не срабатывает — трафик уходит в туннель и там умирает. Чтобы правила переживали перезагрузку, используйте секции PostUp/PostDown в конфиге wg0.conf или пакет iptables-persistent. Отдельно проверьте, что в AllowedIPs клиента стоит 0.0.0.0/0 — если там только подсеть туннеля, наружу пойдёт лишь трафик до сервера, а не весь интернет.

DNS не резолвится под туннелем

Симптом узнаваемый: по IP всё пингуется, а по имени — нет. Значит клиент не получил рабочий DNS. В клиентском конфиге в секции [Interface] должна быть строка DNS = 1.1.1.1 или другой доступный резолвер. На десктопных клиентах Linux для применения этой строки нужен пакет openresolv или resolvconf — без него DNS молча игнорируется, и запросы уходят к старому провайдерскому серверу мимо туннеля. На мобильных приложениях WireGuard DNS применяется автоматически. Если сервер сам выступает резолвером, убедитесь, что на нём слушает DNS-служба и в фаерволе открыт порт 53 для подсети туннеля. Иногда помогает диагностика resolvectl status — она показывает, какой DNS реально используется на активном интерфейсе.

После перезагрузки всё пропадает

Классика: настроили, всё работает, перезагрузили сервер — и туннеля нет. Причина в том, что сервис не добавлен в автозапуск. Включите его явно:

systemctl enable wg-quick@wg0
systemctl restart wg-quick@wg0

Вторая причина — правила NAT жили только в оперативной памяти и после ребута исчезли. Их нужно либо восстанавливать через PostUp в конфиге, либо сохранять через netfilter-persistent save. Третья, менее очевидная — параметр ip_forward вернулся к нулю, потому что был задан только через sysctl -w, но не записан в /etc/sysctl.conf. Проверяйте все три пункта, если доступ отваливается именно после перезагрузки: в 90% случаев виноват один из них. Хороший способ раз и навсегда закрыть вопрос — держать всю логику NAT и форвардинга в самом wg0.conf, тогда состояние сервера полностью описывается одним файлом.

Обрывы и «отваливается через минуту»

Если соединение живёт, пока идёт активность, а в простое рвётся, это почти всегда NAT на стороне провайдера клиента, который закрывает «тихую» UDP-сессию. Лечится параметром PersistentKeepalive = 25 в секции [Peer] клиентского конфига — он гоняет служебный пакет каждые 25 секунд и держит канал живым. Если рвётся под нагрузкой или скорость проседает, проверьте MTU: для WireGuard часто помогает снизить его до 1420 или 1412 в секции [Interface], особенно на мобильных сетях и PPPoE, где полный размер пакета не проходит и фрагментируется. Симптом «маленькие страницы грузятся, тяжёлые виснут» — почти всегда именно про MTU.

Стабильность канала зависит и от качества самого сервера: на перегруженной ноде обрывы будут независимо от конфига. Под постоянный туннель берите VPS с гарантированными ресурсами и чистым IP — например, у MAATRIX в США или Европе, с оплатой из России картой, СБП или криптой, так что зарубежная карта не нужна.

Профилактика: что проверить один раз

Чтобы не возвращаться к отладке, пройдитесь по короткому списку. Убедитесь, что UDP-порт открыт и в ufw, и в облачной панели. Проверьте, что wg-quick@wg0 в автозапуске, а правила NAT сохраняются между перезагрузками. Заведите резервный конфиг клиента на случай, если основное устройство потеряет доступ. Держите под рукой одну диагностическую команду — wg show — она за секунду показывает, дошёл ли до сервера handshake, и сразу отсекает половину гипотез. И раз в пару недель проверяйте, что после ребута туннель поднимается сам: это дешевле, чем чинить доступ, когда он внезапно понадобился.

Частые вопросы