WireGuard: не поднимается туннель — причины и решение

MAATRIX

Запускаете туннель, а он не встаёт: WireGuard не поднимается туннель, wg-quick up падает с ошибкой. Это частая ситуация при первой настройке, и почти всегда причина конкретна и написана в выводе команды: ошибка в конфиге, неверный ключ, занятый порт или отсутствие модуля ядра. WireGuard лаконичен, и его ошибки читаемы. Разберём, как найти причину и поднять туннель.

Первое действие: прочитайте вывод wg-quick и логи

Не запускайте команду повторно вслепую — прочитайте, на чём именно она спотыкается. Запустите поднятие туннеля и посмотрите точную ошибку, а при необходимости и системный лог:

wg-quick up wg0
journalctl -xe | tail -n 20

wg-quick подробно печатает, какую команду он выполняет и где падает: неверная строка конфига, проблема с адресом, отказ при добавлении маршрута, отсутствие интерфейса. Эта строка — ваш диагноз. Частые сообщения: Unable to access interface: Protocol not supported (нет модуля), Address already in use (занят порт), Key is not the correct length (битый ключ), ошибки парсинга конфига. Определив по выводу характер проблемы, вы сразу переходите к нужному разделу. WireGuard не любит гадания — он честно говорит причину, надо лишь внимательно прочитать вывод, а не перезапускать команду по кругу.

Причина 1: ошибка в конфигурационном файле

Самая частая причина — опечатка или неверное значение в конфиге /etc/wireguard/wg0.conf. WireGuard строг к формату: секции [Interface] и [Peer], корректные ключи, правильные адреса и маски. Типичные ошибки — лишние пробелы, неверная маска подсети, пропущенное поле, неправильный AllowedIPs. Проверьте структуру конфига:

cat /etc/wireguard/wg0.conf

Убедитесь, что в [Interface] заданы PrivateKey, Address (с маской, например 10.0.0.1/24) и ListenPort, а в [Peer] — PublicKey и AllowedIPs. Частая путаница — перепутать местами приватный и публичный ключи или указать чужой публичный ключ. Ещё ошибка — неверный Address или пересечение подсетей. wg-quick при ошибке парсинга укажет проблемную строку. Исправьте её и снова поднимите туннель. Аккуратный, правильно структурированный конфиг — основа: большинство отказов старта именно из-за мелкой ошибки в этом файле, которую видно при внимательном чтении.

Причина 2: неверные или битые ключи

WireGuard работает на паре ключей, и если ключ повреждён (лишние символы, перенос строки, неполная копия) или перепутан, туннель не встанет. Ошибка вида Key is not the correct length or format прямо на это указывает. Ключи должны быть ровно нужной длины в base64. Сгенерируйте пару заново, если сомневаетесь в целостности:

wg genkey | tee privatekey | wg pubkey > publickey

Ключевое правило WireGuard: в конфиге сервера в [Interface] стоит приватный ключ сервера, а в [Peer] — публичный ключ клиента; на клиенте зеркально — его приватный в [Interface] и публичный сервера в [Peer]. Перепутанные местами ключи — очень частая ошибка, при которой туннель либо не встаёт, либо встаёт, но не передаёт трафик. Убедитесь также, что при копировании ключа не попали лишние пробелы или перевод строки. Свежесгенерированные и правильно расставленные ключи снимают эту причину. После правки перезапустите туннель и проверьте статус через wg show.

Причина 3: нет модуля ядра или пакета

Ошибка Unable to access interface: Protocol not supported или module wireguard not found означает, что в системе нет поддержки WireGuard — не загружен модуль ядра или не установлен нужный пакет. На современных ядрах WireGuard встроен, но на старых или урезанных системах его может не быть. Проверьте наличие инструментов и модуля:

modprobe wireguard
wg --version

Если modprobe ругается, что модуля нет, обновите ядро и установите пакеты (wireguard и wireguard-tools). На большинстве актуальных дистрибутивов достаточно установить wireguard-tools, модуль уже в ядре. Отдельная и важная тонкость — тип виртуализации сервера: на контейнерном VPS (OpenVZ, иногда LXC) загрузка модулей ядра может быть запрещена провайдером, и тогда классический WireGuard на модуле ядра не заработает вовсе. Именно поэтому под VPN берут KVM-VPS с полноценным своим ядром, где нет таких ограничений. Если вы на контейнере и модуль не грузится — это не чинится настройкой, нужен сервер с полной виртуализацией.

Причина 4: порт занят или конфликт интерфейса

Ошибка Address already in use на ListenPort означает, что UDP-порт (по умолчанию 51820) уже занят другим процессом или вторым экземпляром WireGuard. Также туннель не встанет, если интерфейс wg0 уже существует после неудачного предыдущего запуска. Проверьте, что происходит с портом и интерфейсом:

ss -ulnp | grep 51820
ip link show wg0

Если порт занят другим сервисом — смените ListenPort в конфиге или освободите порт. Если wg0 уже существует как «висячий» интерфейс от прошлого сбойного старта, корректно опустите его и поднимите заново:

wg-quick down wg0; wg-quick up wg0

Иногда после ошибки интерфейс остаётся в промежуточном состоянии, и повторный up падает именно из-за этого — тогда сначала down, потом up. Убедитесь также, что не запущены два конфига на одном порту. Разрешив конфликт порта и убрав висячий интерфейс, вы поднимете туннель. Это частая причина, когда «конфиг вроде верный, а всё равно не встаёт после неудачной попытки».

Как проверить, что туннель поднялся

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

wg show

Если вы видите интерфейс wg0, свой публичный ключ и секцию пира — туннель поднят на уровне интерфейса. Дальше проверьте, идёт ли трафик: после первого обмена у пира появится latest handshake и ненулевые счётчики transfer. Отсутствие handshake означает, что интерфейс есть, но пиры не договорились — это уже вопрос сети, портов или ключей на другой стороне (тема отдельного разбора про «нет интернета через VPN»). Но сам факт, что wg show показывает поднятый интерфейс без ошибок, подтверждает, что проблема старта решена. Это и есть цель данного этапа — чтобы туннель поднимался, а не падал командой up.

Профилактика: чтобы туннель поднимался стабильно

Чтобы wg-quick up не подводил, соблюдайте несколько правил. Ведите конфиги аккуратно и с бэкапом: одна опечатка в ключе или адресе валит старт, а копия рабочего конфига позволяет мгновенно откатиться. Генерируйте ключи корректно и расставляйте их по правилу «приватный свой в [Interface], публичный чужой в [Peer]». Берите под VPN сервер с полной виртуализацией KVM, где модуль ядра WireGuard гарантированно доступен, — это снимает целый класс проблем с контейнерными ограничениями.

Проверяйте, что порт WireGuard свободен и не конфликтует с другими сервисами, а после сбойных запусков не забывайте опускать висячий интерфейс перед повторным поднятием. Для постоянной работы включите автозапуск туннеля через systemd (systemctl enable wg-quick@wg0), чтобы он поднимался после перезагрузки. Эти привычки делают запуск WireGuard предсказуемым. А главное — всегда читайте вывод wg-quick: он точно называет причину, и большинство отказов старта решаются за пару минут внимательного чтения, а не перебором наугад.

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