WireGuard логи: как читать wg show и journalctl при диагностике

WireGuard — это современный VPN-протокол, который ценится за простоту настройки и высокую производительность. Но даже у самого простого инструмента бывают сбои. Когда соединение не устанавливается или трафик не идёт, на помощь приходят логи. В этой статье разберём, как правильно читать вывод wg show и журналы journalctl, чтобы быстро находить причину проблемы. Мы не будем повторять общий обзор WireGuard, а сосредоточимся именно на диагностике.

wg show: взгляд внутрь интерфейса

Команда wg show — это основной инструмент для проверки состояния WireGuard-интерфейса. Выполните wg show без аргументов, чтобы увидеть все интерфейсы, или wg show wg0 для конкретного. Вывод содержит несколько важных полей:

• interface: wg0 — имя интерфейса, его текущий публичный ключ, номер порта прослушивания.
• peer: — список пиров. Для каждого пира показываются:
• endpoint: — удалённый адрес и порт. Если endpoint не указан, пир не настроен для соединения.
• allowed ips: — какие подсети маршрутизируются через данного пира. Ошибки в allowed ips — частая причина проблем.
• latest handshake: — время последнего успешного рукопожатия. Если оно отсутствует или очень старое, значит пир не обменивается данными.
• transfer: — количество переданных и полученных байт. Рост счётчиков указывает на активность, но не гарантирует корректность маршрутизации.

Пример вывода (значения не являются реальными конфигами):

interface: wg0
  public key: xxxxxxxx
  private key: (hidden)
  listening port: 51820

peer: yyyyyyyy
  endpoint: 203.0.113.2:44788
  allowed ips: 10.0.0.2/32
  latest handshake: 1 minute ago
  transfer: 1.2 KiB received, 3.4 KiB sent

Обратите внимание на время handshake. Если оно более нескольких минут, а соединение должно быть постоянным, это первый признак проблемы. Отсутствие строки latest handshake означает, что пир никогда не устанавливал рукопожатие после перезапуска интерфейса.

journalctl: системные журналы для WireGuard

WireGuard работает на уровне ядра, поэтому важные сообщения попадают в kernel и systemd журналы. journalctl — стандартная утилита для их просмотра. Начните с фильтра по wg-quick, если вы использовали эту команду для настройки:

journalctl -u wg-quick@wg0 -f

Опция -f следит за новыми сообщениями. Здесь вы увидите вывод скриптов wg-quick: создание интерфейса, добавление пиров, ошибки при выполнении команд. Например, сообщение Unable to set up WireGuard interface или Permission denied укажет на проблемы с правами или отсутствие модуля ядра.

Для сообщений ядра используйте:

journalctl -k -t kernel | grep wireguard

или

dmesg | grep wireguard

Ядро может сообщать о том, что интерфейс создан, удалён, не может перехватить пакет, а также о проблемах с маршрутизацией. Иногда полезно смотреть сообщения netfilter и iptables, если они связанны с WireGuard.

Типичные симптомы и их причины

Прежде чем углубляться в логи, проверьте, как проявляется неисправность. Вот частые сценарии:

• Handshake не появляется — пир не отвечает. Возможные причины: неправильный endpoint, файрвол блокирует UDP-порт, ключи не совпадают.
• Handshake есть, но трафик не ходит — проблема в маршрутизации или allowed ips.
• Интерфейс не запускается — ошибка в конфиге, отсутствует модуль ядра, конфликт портов.
• Периодические отвалы — смена IP у пира, потери пакетов на сети, таймауты.

Используйте этот список как отправную точку для поиска по логам.

Пошаговая диагностика: от вероятного к редкому

При возникновении проблемы действуйте последовательно.

1. Проверьте состояние интерфейса: ip link show wg0 — интерфейс должен быть UP. Если его нет, сообщение об ошибке будет в journalctl.
2. Выполните wg show wg0 — посмотрите на наличие handshake. Отсутствие handshake указывает на проблему с соединением. Проверьте endpoint и доступность хоста командой ping (но помните, что ping может быть запрещён).
3. Проверьте ключи: сверьте публичные ключи на обеих сторонах. Ошибки в конфиге (например, лишний пробел или устаревший ключ) часто видны невооружённым глазом. Также убедитесь, что приватный ключ соответствует публичному: wg pubkey < privatekey.
4. Проверьте маршрутизацию: ip route show table all | grep wg0. Обратите внимание на allowed ips у пира — они должны перекрывать нужные подсети. Если маршрут не создался, проверьте wg-quick скрипт.
5. Проверьте файрвол — разрешён ли UDP-порт WireGuard на обоих концах. Используйте ss -ulpn для проверки, что процесс слушает порт.
6. Следите за журналом в реальном времени: journalctl -u wg-quick@wg0 -f и journalctl -k -f. Попробуйте установить соединение и наблюдайте за новыми записями.

Этот порядок покрывает большинство проблем: сначала очевидные состояния, затем ключи и настройки, и только потом низкоуровневые детали ядра.

Как отличить проблему с WireGuard от проблем сети

Иногда причина не в WireGuard, а в сетевой инфраструктуре. Используйте traceroute и mtr для проверки пути до endpoint. Если пакеты не доходят, смените endpoint или проверьте NAT. Если пакеты доходят, но handshake не происходит, значит дело в самом WireGuard — например, в ключах или порте. В journalctl вы можете увидеть сообщение Invalid handshake initiation: no peer with matching public key — это прямое указание на неверный ключ. Также бывают ошибки Key pair generation failed или Packet dropped из-за проблем с MTU. В этих случаях изучайте dmesg.

Советы по чтению логов в больших объёмах

Если журналов много, используйте grep и фильтры по времени:

journalctl -u wg-quick@wg0 --since "10 minutes ago"

Комбинируйте с grep -i для поиска ошибок:

journalctl -k | grep -i ERROR

WireGuard сам по себе не создаёт многословных логов, поэтому каждая запись ценна. Привычка смотреть логи сразу при настройке поможет быстрее освоиться и избегать типовых ошибок.