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

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

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

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

Ошибка WireGuard: handshake for peer did not complete after 5 seconds

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

Криптография WireGuard и механика Handshake

WireGuard работает по принципу Connectionless (без установки сессии) на базе протокола UDP. Сообщение «handshake for peer did not complete after 5 seconds, retrying» в логах клиента означает, что клиент отправил пакет инициализации (Initiation Packet), но не получил ответного пакета (Response Packet) от сервера в течение таймаута. Из-за архитектуры Cryptokey Routing (маршрутизация по криптоключам) сервер WireGuard молча отбрасывает пакеты (Silent Drop), если они не прошли проверку подлинности, не отвечая ошибкой. Симптомы: туннель в ОС показывается как «Активный», счетчик переданных байт (Tx) растет, а счетчик принятых байт (Rx) остается на нуле. Бизнес-риски: отсутствие доступа к сервисам, ложное впечатление работающего VPN.

Типовые причины сбоя хендшейка

Причина (Уровень)ОписаниеДействие на стороне Сервера
Несовпадение ключейКлиент использует не тот Public Key сервера, или сервер не знает Public Key клиента.Сервер молча дропает пакет. Лог: Keypair mismatch.
Проблема с сетью (NAT/Firewall)Указан неверный Endpoint IP, либо провайдер/роутер блокирует входящий UDP порт (51820).Пакет не доходит до сервера вообще.
Асимметричный роутингПакет дошел до сервера, но ответ уходит через другой интерфейс (Default Gateway).Ответный пакет теряется в интернете.

Траблшутинг хендшейков WireGuard (Tx растет, Rx = 0)

Сценарий 1: Проверка криптографической пары (Ключи)

Самая частая ошибка — опечатки при переносе ключей или генерация новых без обновления сервера.

  1. На клиенте: Проверьте параметр PublicKey в секции [Peer]. Он должен в точности совпадать с результатом команды wg show (поле public key) на сервере!
  2. На сервере: Убедитесь, что публичный ключ клиента прописан в его секции [Peer] конфигурации сервера (/etc/wireguard/wg0.conf).

Сценарий 2: Доступность порта и NAT (Endpoint)

Трафик UDP не имеет гарантии доставки. Нужно проверить, открыт ли порт снаружи.

 Проверка доступности UDP порта с помощью Netcat (с другого ПК)
nc -u -v -z ВАШ_IP_СЕРВЕРА 51820

 На сервере: проверка, что WG слушает порт
ss -ulnp | grep 51820

 На сервере: захват пакетов (приходят ли они вообще?)
tcpdump -i eth0 udp port 51820 -n

Сценарий 3: Настройка PersistentKeepalive (за NAT)

Если клиент находится за NAT роутером (например, дома или в кафе), таблица трансляции адресов роутера может быстро забыть UDP-сессию. Сервер не сможет сам инициировать связь с клиентом.

 Добавьте в конфигурацию клиента в секцию [Peer]
PersistentKeepalive = 25

 Это заставит клиента пинговать сервер каждые 25 секунд, поддерживая NAT-проброс активным.

Типовые ошибки администраторов

  • Забытый форвардинг в Iptables: Сервер получил пакет, расшифровал его, но не переслал дальше в ядро Linux. Убедитесь, что net.ipv4.ip_forward=1 в sysctl.conf и настроен MASQUERADE.
  • Смена динамического IP сервера: Если у сервера WG нет статического IP, и он изменился, клиент будет вечно стучаться по старому адресу (Endpoint). Встроенный клиент WireGuard резолвит доменное имя (DDNS) только один раз при запуске туннеля!
WireGuard периодически «отваливается» и требует перезапуска?
Проблемы с роутингом и NAT-таймаутами в сетях Enterprise масштаба лучше решать с использованием динамической маршрутизации (BGP/OSPF поверх WireGuard). Инженеры ITSTM спроектируют стабильную Overlay-сеть для вашей распределенной инфраструктуры.
💡 Практика специалистов: Практика ITSTM: При развертывании WireGuard на серверах за NAT (например, AWS EC2 или Azure), убедитесь, что параметр Endpoint в конфигурации клиента указывает на публичный (EIP) адрес облака, а сам сервер слушает 0.0.0.0. Также не забывайте открывать UDP-порт в Security Groups облачного провайдера (AWS SG).

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

Как посмотреть подробные логи WireGuard на сервере Linux?

В ядре Linux нужно включить отладку (Dynamic Debug). Выполните: 'echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control', а затем смотрите логи через 'dmesg -T -w'.

Почему клиент показывает статус 'Активен', если хендшейк упал?

В отличие от OpenVPN или IPsec, WireGuard — интерфейс без состояния (stateless). 'Активен' означает лишь то, что виртуальный сетевой адаптер поднят в ОС и готов инкапсулировать пакеты. Он не отражает реальное состояние линка с сервером.

Что делать, если провайдер блокирует WireGuard?

WireGuard легко распознается по первому пакету хендшейка. Если блокировка происходит на уровне провайдера (DPI), используйте обфускацию: AmneziaWG, или заворачивайте WireGuard поверх Shadowsocks / UDP2RAW.

Влияет ли рассинхронизация времени на хендшейк?

Да. WireGuard использует метки времени (TAI64N) для защиты от атак повторного воспроизведения (Replay Attacks). Если время на сервере или клиенте сильно отстает (на годы), пакеты инициализации будут отбрасываться.

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