Как проверить конфигурацию WireGuard на ошибки

Коротко: ошибки конфигурации WireGuard: для выявления ошибок проверьте статус интерфейса через wg show, удостоверьтесь, что handshake стабильно обновляется, сравните ключи и endpoint, а также исключите блокировку UDP-порта брандмауэром. Ключевой индикатор — нулевой счётчик трафика и отсутствие handshake в выводе команды.

Ошибки конфигурации WireGuard часто маскируются под сетевую недоступность из-за отсутствия традиционных сообщений. Целенаправленная проверка каждого узла конфигурации помогает быстро восстановить туннель и избежать длительных экспериментов с настройками.

Что понадобится

• Доступ к серверу и клиенту WireGuard с правами суперпользователя
• Установленный WireGuard (версия ≥ 1.0)
• Конфигурационные файлы или сведения об обоих участниках туннеля
• Базовое понимание структуры интерфейса [Interface] и пира [Peer]

Типичные симптомы неработающего туннеля

Проблемы с WireGuard редко сопровождаются явными сообщениями об ошибках, поэтому первым шагом становится распознавание косвенных признаков. Вы можете заметить, что удалённые IP-адреса не пингуются, трафик через туннель не проходит, а в выводе утилиты wg show напротив пира отсутствуют поля latest handshake или transfer: 0 B received, 0 B sent.

• Не отвечает удалённая сторона
• Утилита wg show показывает пустые transfer и handshake
• Локальный интерфейс WireGuard поднят, но пакеты не идут
• В логах ядра появляются сообщения типа wireguard: … Handshake did not complete

Проверка состояния интерфейса и сбор логов

Начинайте диагностику с визуального анализа текущего статуса туннеля. Команда wg show — основной инструмент: она отобразит параметры интерфейса, публичные ключи, endpoint и данные о рукопожатиях. Параллельно проверьте, активен ли интерфейс на уровне ОС с помощью ip link show wg0. Логи ядра доступны через dmesg | grep wireguard или journalctl -k | grep wireguard и могут указать на криптографическую или сетевую ошибку.

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

1. Выполните wg show и изучите секцию peer.
2. Убедитесь, что интерфейс поднят (ip link show wg0).
3. Просмотрите логи: dmesg | grep wireguard.
4. Оцените наличие handshake и значение transfer.

Важно: Отсутствие handshake более 2–3 минут при корректном endpoint и открытом порте почти всегда означает ошибку в ключах или AllowedIPs.

Анализ рукопожатия (handshake)

WireGuard использует бессостоятельный протокол, и установление соединения проявляется в виде периодически обновляемой временной метки 'latest handshake'. Если эта строка отсутствует вовсе, пакеты инициализации не доходят до цели. Распространённые причины: неправильный публичный IP/порт сервера в строке endpoint клиента, фильтрация UDP-трафика на пути, либо неверный ключ.

Для проверки вручную отправьте UDP-датаграмму на подозреваемый порт утилитой netcat: nc -u server_ip 51820. Если порт открыт, сервер не должен сбрасывать соединение. Затем сверьте открытые ключи двух сторон: команда wg pubkey < privatekey выведет публичный ключ, который должен в точности совпадать с тем, что записан в секции [Peer] противоположной стороны.

1. Запишите endpoint клиента (IP:порт).
2. С клиентской машины проверьте доступность порта: nc -zu server_ip 51820.
3. Сравните публичные ключи командой wg pubkey.
4. При необходимости включите PersistentKeepalive = 25 для обхода NAT.

Важно: Если сервер находится за NAT, убедитесь, что на маршрутизаторе настроена проброска порта в DNAT.

Проверка ключей и параметров пира

Ошибки на уровне ключей — самая частая, но труднозаметная проблема. Даже один неверный символ в base64-строке делает туннель неработоспособным. Используйте строгое копирование или сверку хэшей: echo 'ключ' | wg pubkey должен выдавать один и тот же публичный ключ для одного и того же закрытого.

Кроме ключей, обратите внимание на директиву AllowedIPs. Она определяет, какие адреса пропускаются через конкретного пира. Если вы указали 10.7.0.2/32, но на интерфейсе адрес клиента задан как 10.7.0.3/32, пакеты фильтруются. Типичная схема: на сервере AllowedIPs клиента = 10.7.0.2/32, Address клиента = 10.7.0.2/24; у клиента AllowedIPs сервера = 10.7.0.1/32 (и возможно 0.0.0.0/0 для полного туннеля). Проверьте, нет ли перекрывания с локальными сетями, если это не требуется.

1. Сгенерируйте публичный ключ из закрытого и сравните с удалённой стороной.
2. Убедитесь, что AllowedIPs содержит IP-адреса в формате CIDR, которые принадлежат интерфейсу пира.
3. Проверьте Address интерфейса на уникальность в рамках туннеля.

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

Маршрутизация и IP-адресация

Даже при успешном handshake трафик может не идти из-за ошибок маршрутизации. Проверьте таблицу маршрутов командой ip route show | grep wg0: должен присутствовать маршрут до сети пира. Если AllowedIPs включает 0.0.0.0/0, убедитесь, что локальные маршруты не конфликтуют (например, не исключён шлюз по умолчанию для управления).

При использовании нескольких интерфейсов может потребоваться настройка таблиц маршрутизации через PostUp/PreDown скрипты. Базовая проверка: с клиента пингуйте IP-адрес туннельного интерфейса сервера (обычно 10.7.0.1). Если пинг проходит, туннель работает, а проблема выше — в настройках приложений или DNS.

1. Выполните ip route show и найдите строку с устройством wg0.
2. Пропингуйте адрес удалённого туннельного интерфейса.
3. Убедитесь, что локальная подсеть не входит в AllowedIPs = 0.0.0.0/0 без маршрутизации.
4. Проверьте, включён ли IP forwarding на сервере: sysctl net.ipv4.ip_forward.

Важно: Для сквозного туннеля необходимо, чтобы на сервере был включён IP forwarding и настроен NAT-маскарадинг.

Диагностика брандмауэра и NAT

UDP-трафик WireGuard легко блокируется межсетевыми экранами. Проверьте правила iptables/nftables на обеих сторонах. На сервере должен быть открыт входящий UDP-порт, используемый в ListenPort (по умолчанию 51820). Команда для быстрой проверки: sudo ufw status или sudo iptables -L -n.

Если сервер стоит за NAT, не забудьте переадресацию: на маршрутизаторе должно быть правило DNAT на внутренний IP сервера. Для тестирования можно временно отключить брандмауэр (sudo ufw disable) и повторить попытку соединения. Помните, что некоторые провайдеры блокируют нестандартные UDP-порты — в этом случае смените порт на 53, 123, 443 и проверьте снова.

1. Проверьте, что на сервере разрешён входящий UDP-порт: iptables -L INPUT -n.
2. На роутере настройте проброс порта (если требуется).
3. Временно отключите брандмауэр и проверьте handshake.
4. Попробуйте альтернативный порт при подозрении на блокировку провайдером.

Важно: При изменении порта не забудьте обновить ListenPort на сервере и Endpoint на клиенте.

Проверка результата

• Сравните открытые ключи на обоих концах туннеля с помощью wg pubkey
• Проверьте доступность endpoint-порта утилитой nc -zu
• Убедитесь, что на сервере включён IP forwarding
• Просмотрите лог ядра на наличие сообщений wireguard
• Уточните, не блокирует ли провайдер UDP-порт 51820

Частые ошибки и нюансы

• Использование неправильного типа кавычек или лишних пробелов в конфигурационном файле
• Несовпадение подсети между Address интерфейса и AllowedIPs пира
• Забытый PersistentKeepalive при нахождении клиента за NAT
• Закрытый ключ, не соответствующий тому открытому, что прописан на другой стороне
• Спешка с проверкой рукопожатия сразу после запуска интерфейса — дайте до 30 секунд

FAQ

Почему в выводе wg show нет строки handshake?

Наиболее вероятная причина — недоступность endpoint (закрыт порт, неверный IP) или несовпадение ключей. Проверьте сетевую связность и точное соответствие открытых ключей.

Как быстро найти параметр, вызывающий ошибку?

Скопируйте конфигурационные файлы обеих сторон и выполните построчное сравнение в текстовом редакторе; обратите внимание на каждый символ ключей и CIDR-маски.

Может ли проблема быть в устаревшей версии WireGuard?

Крайне редко, но рекомендуется использовать стабильную версию не ниже 1.0 на всех узлах. Проблемы совместимости между разными ОС почти не встречаются.

Что делать, если handshake появляется, но сразу пропадает?

Установите PersistentKeepalive = 25 в секции пира для поддержания соединения через NAT и нестабильные каналы.

Как убедиться, что UDP-порт не блокируется провайдером?

Поменяйте ListenPort на сервере и endpoint на клиенте на заведомо открытые порты (53, 123, 443) и проверьте рукопожатие заново.

Обязателен ли IP forwarding на клиенте?

Нет, IP forwarding нужен только если клиент маршрутизирует трафик для других устройств. Обычному клиенту достаточно корректных адресов и AllowedIPs.

Итог

Методичная проверка конфигурации WireGuard от ключей до маршрутизации и брандмауэра выявляет практически любую ошибку. Сохраняйте проверенные конфигурации как эталон и используйте команду wg show как основной диагностический инструмент. Простота протокола требует особого внимания к деталям — тщательный построчный контроль избавит от большинства неполадок.

Также может быть интересно

Когда стоит переустановить WireGuard, а когда проблема не в клиентеОткрыть инструкциюПочему WireGuard расходует больше батареи на смартфоне: причины и способы уменьшить разрядОткрыть инструкциюЧто делать, если WireGuard подключён, но IP-адрес не меняетсяОткрыть инструкцию