Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

WG_HANDSHAKE_TIMEOUT Сетевое оборудование и VPN

WireGuard Error: No response from endpoint after multiple handshake initiations — Решение

Обновлено: 24.08.2026 · Официальная документация ↗

При попытке установить VPN-соединение WireGuard передача трафика отсутствует. В выводе команды wg show статус latest handshake либо полностью отсутствует, либо содержит старое значение (более 2 минут назад), счетчик transfer: tx непрерывно растет при нулевом или статичном значении transfer: rx.

  • В выводе wg show wg0 строка рукопожатия не обновляется: latest handshake: (never) или latest handshake: 3 minutes ago.
  • Клиент отправляет пакеты инициализации, но не получает ответов (растут только переданные байты transfer: 15.4 KiB sent, 0 B received).
  • Журнал journalctl -u wg-quick@wg0 или модуль ядра фиксирует: wireguard: wg0: Handshake for peer N did not complete after 20 attempts, retrying....
  • Утилиты ping и curl через VPN-интерфейс возвращают Destination Host Unreachable или зависают по таймауту.

1. Анализ текущего состояния туннеля и трафика

Проверьте вывод статуса интерфейса на клиенте и сервере:

wg show wg0
ip -s link show wg0

Запустите захват пакетов на стороне сервера для проверки поступления входящих UDP-дейтаграмм:

tcpdump -nn -v -i any udp port 51820

2. Проверка соответствия криптографических ключей

WireGuard не отвечает на входящие пакеты, если публичный ключ клиента не зарегистрирован на сервере, либо если на клиенте указан некорректный PublicKey сервера. Проверьте соответствие пар ключей:

# На клиенте: извлечение публичного ключа из приватного
wg pubkey < /etc/wireguard/privatekey

# На сервере: сверка зарегистрированного ключа пира
wg show wg0 peers
grep -A 3 "[Peer]" /etc/wireguard/wg0.conf

3. Настройка межсетевого экрана (Netfilter / iptables / nftables / UFW)

На сервере необходимо явно разрешить входящий UDP-порт и включить IP-форвардинг:

# Открытие порта 51820 UDP через UFW
ufw allow 51820/udp

# Либо через iptables
iptables -I INPUT 1 -p udp --dport 51820 -j ACCEPT

# Включение форвардинга IPv4 в ядре
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.d/99-wireguard.conf
sysctl --system

4. Решение проблем с CGNAT и маршрутизацией через провайдера

Если сервер находится за NAT провайдера (CGNAT) или домашним роутером, настройте Port Forwarding порта 51820 UDP на локальный IP-адрес хоста. Если клиент находится за симметричным NAT, добавьте директиву поддержания соединения в секцию [Peer] клиента:

PersistentKeepalive = 25

5. Перезапуск и проверка соединения

wg-quick down wg0 && wg-quick up wg0
wg show
💡 Практика специалистов: Главная особенность WireGuard — полное молчание при ошибках аутентификации. Если сервер получил пакет с неизвестным PublicKey или поврежденным MAC1, он молча уничтожает дейтаграмму, исключая возможность сканирования портов сканерами вроде nmap.

Частые вопросы (FAQ)

Почему WireGuard не выдает ошибку Connection Refused при недоступности порта?

WireGuard работает исключительно по протоколу UDP и по соображениям безопасности (stealth design) полностью игнорирует невалидные пакеты, не отправляя ICMP Port Unreachable и не выдавая сигналов о существовании службы, если авторизация рукопожатия не прошла.

Почему растет только Tx (отправка), а Rx (прием) остается нулевым?

Рост счетчика Tx при нулевом Rx означает, что локальный узел генерирует пакеты Handshake Initiation, но сервер либо не получает их (блокировка ISP, закрытый порт, NAT), либо отбрасывает из-за несовпадения криптографических ключей.

Помогает ли смена стандартного порта 51820 при блокировках провайдером?

Да, многие интернет-провайдеры и мобильные операторы выборочно фильтруют стандартный порт 51820 UDP. Перевод туннеля на порты 443/UDP, 53/UDP или случайный диапазон (например, 41194/UDP) часто решает проблему.

Как включить подробное логирование рукопожатий WireGuard в dmesg?

Включите отладочный динамический вывод ядра Linux: echo 'module wireguard +p' > /sys/kernel/debug/dynamic_debug/control. События рукопожатия начнут отображаться в dmesg -w.

Полезные материалы
Рекомендуем