Ошибка handshake failed при подключении к WireGuard серверу как исправить

[Sdgator]

Поднял WireGuard на VPS (Debian 12), на клиенте Windows 10 конфиг добавил, нажимаю подключиться — статус показывает «Handshake: Never» и интернет через туннель не идёт. Firewall на VPS вроде настроил, порт открыл. Логи клиента особо ничего не говорят. Что проверить в первую очередь?

[quixtar]

Это классика, разберём по шагам. Первое и самое частое — неправильные ключи. Убедись что в конфиге сервера в секции [Peer] стоит ПУБЛИЧНЫЙ ключ клиента, и наоборот — в конфиге клиента в [Peer] стоит публичный ключ сервера, не приватный. Звучит банально, но половина проблем именно отсюда. Публичный ключ генерится из приватного командой `wg pubkey < privatekey`.

[kate2000]

Второе — UDP-порт. WireGuard работает только на UDP. Проверь: `ss -ulnp | grep 51820` на сервере (или какой порт у тебя). Если пусто — демон не запущен или слушает на другом порту. Потом проверь файрвол: `iptables -L -n | grep 51820` или `ufw status`. Для ufw: `ufw allow 51820/udp`. Для iptables: `iptables -A INPUT -p udp --dport 51820 -j ACCEPT`.

[Rhemix]

Третья распространённая причина — IP-форвардинг не включён на сервере. Проверь: `sysctl net.ipv4.ip_forward` — должно быть 1. Если 0, то: `sysctl -w net.ipv4.ip_forward=1` для текущей сессии и добавь `net.ipv4.ip_forward=1` в /etc/sysctl.conf для постоянного эффекта. Без этого клиент подключится, но трафик в интернет не пойдёт.

[pandas4]

Ещё момент: если VPS находится за NAT (у некоторых хостеров бывает), в конфиге сервера в секции [Interface] адрес должен быть внутренним IP машины, а не внешним. Внешний IP прописывается в конфиге клиента в Endpoint. Проверить внешний IP: `curl ifconfig.me`. Сетевой интерфейс сервера: `ip addr show`.

[Rhemix]

Для диагностики в реальном времени: на сервере запусти `wg show` — покажет все пиры и когда был последний handshake. Если время handshake не обновляется после попыток подключения — пакеты вообще не доходят до сервера (проблема с файрволом или сетью). Если обновляется но трафик не идёт — проблема с маршрутизацией или форвардингом.

[svelteops]

У меня была точно такая же ситуация — оказалось что хостер блокирует нестандартные UDP порты на своей стороне, и это не отображается в iptables сервера. Решил переключением на порт 53 (DNS) или 443 — их обычно не трогают. В конфиге сервера меняешь `ListenPort`, в конфиге клиента меняешь порт в `Endpoint`, не забудь пересоздать правило файрвола для нового порта.

[kube_fan]

Добавлю шаг, который сразу делит проблему пополам: запусти на сервере `tcpdump -ni any udp port 51820` и нажми «подключиться» на клиенте. Пакеты прилетают — сеть и файрвол в порядке, копай ключи и конфиг. Пакетов нет — до сервера вообще ничего не долетает, и крутить sysctl бессмысленно. И да, после правки конфига сервера нужен `systemctl restart wg-quick@wg0` — на лету он файл не перечитывает, об это многие спотыкаются.

[misha12]

@kate2000, дополню твой чек-лист: ufw и iptables на самой машине — это полдела. У многих хостеров есть ещё внешний файрвол в панели управления (security groups), и он по умолчанию режет всё, кроме 22, 80 и 443. Изнутри VPS при этом всё выглядит идеально: демон слушает, правила на месте, а пакеты умирают ещё до машины. Стоит проверять до того, как перебирать ключи.

[RedisNinja]

@svelteops, с портом 53 поосторожнее: на VPS его нередко уже держит systemd-resolved или dnsmasq, плюс DPI у некоторых провайдеров косо смотрит на UDP 53 с явно не-DNS начинкой. 443/udp в этом смысле удачнее — снаружи трафик неотличим от QUIC, на котором сейчас полвеба сидит. А вот сам совет про блокировку нестандартных UDP на стороне хостера — золото, эту причину почти никто не проверяет.