Ошибка при согласовании с пиром в WireGuard и других VPN чаще всего проявляется одинаково: туннель включён, интерфейс «поднят», но в журнале видно, что handshake (рукопожатие) так и не завершился — счётчик переданных байт растёт, а принятых остаётся нулевым. Это означает, что клиент отправляет пакеты инициализации, но не получает ответа от удалённого узла, и защищённый канал не устанавливается.
Проблема почти всегда сводится к узкому набору причин: несовпадение ключей, закрытый UDP-порт, неверный адрес пира или сетевые ограничения на стороне провайдера. Ниже разберём, как локализовать сбой и устранить его без рискованных действий.
Что означает ошибка согласования с пиром
Согласование (handshake) — это начальный обмен криптографическими сообщениями между двумя узлами VPN. В ходе него стороны проверяют публичные ключи друг друга и договариваются о сеансовых ключах шифрования. Только после успешного рукопожатия через туннель начинает идти полезный трафик.
Если согласование не проходит, появляются характерные признаки:
- 🔴 в статусе интерфейса поле latest handshake пустое или показывает устаревшее время;
- 📤 счётчик transfer показывает отправленные данные, но ноль принятых;
- ⏱️ в журнале повторяются попытки повторного рукопожатия с нарастающими интервалами;
- 🌐 ресурсы за туннелем недоступны, хотя сам интерфейс активен.
Проверить состояние на Linux можно командой:
sudo wg showОбратите внимание на строки latest handshake и transfer для нужного пира — это главный индикатор того, завершилось ли согласование.
Основные причины сбоя handshake
Диагностику стоит начинать с наиболее вероятных причин. Ниже — типовые источники проблемы, которые проверяются простыми средствами.
| Причина | Как проявляется | Как проверить |
|---|---|---|
| Неверный публичный ключ пира | Ответы приходят, но отклоняются | Сверить ключи на обеих сторонах |
| Закрыт UDP-порт на сервере | Полная тишина, ноль принятых байт | Проверить файрвол и проброс порта |
| Неверный endpoint (адрес:порт) | Пакеты уходят «в никуда» | Проверить параметр Endpoint в конфиге |
| Блокировка UDP провайдером | Туннель не работает в одной сети, но работает в другой | Переключиться на мобильный интернет для теста |
| Проблемы с MTU | Handshake проходит, но трафик «виснет» | Проверить ping крупными пакетами |
Отдельно стоит упомянуть несовпадение времени на устройствах. Хотя WireGuard менее чувствителен к расхождению часов, чем некоторые другие протоколы, значительный сдвиг системного времени способен мешать отдельным реализациям и сопутствующим проверкам. Синхронизация по NTP — дешёвая проверка, которую стоит сделать в любом случае.
Проверка ключей и конфигурации
Начните с самого частого источника сбоя — пары ключей. В WireGuard каждая сторона должна знать публичный ключ другой: в секции [Peer] клиента указывается публичный ключ сервера, а на сервере — публичный ключ клиента. Если ключи перепутаны, скопированы с ошибкой или относятся к другой паре, рукопожатие не завершится.
Типичный фрагмент конфигурации клиента выглядит так:
[Peer]
PublicKey = <публичный ключ сервера>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Проверьте следующие пункты:
- 🔑 публичный ключ в
[Peer]соответствует приватному ключу на противоположной стороне; - ✂️ при копировании не потеряны символы и не добавлены пробелы — ключи чувствительны к любому изменению;
- 📄 на сервере клиент добавлен в конфигурацию и интерфейс был перезапущен после изменений;
- 🔁 если ключи генерировались заново, обновлены обе стороны, а не одна.
Публичный ключ можно вывести из приватного командой: cat privatekey | wg pubkey — так вы быстро сверите соответствие пары без поиска по файлам.
⚠️ Внимание: приватный ключ нельзя передавать по открытым каналам и хранить в общедоступных местах. Если есть подозрение на компрометацию, сгенерируйте новую пару ключей и обновите конфигурацию на обеих сторонах.
Сеть, порты и файрвол
Если ключи в порядке, следующий шаг — проверить доставку пакетов. WireGuard по умолчанию использует UDP, и порт, указанный в ListenPort на сервере, должен быть доступен извне: открыт в файрволе сервера, проброшен на маршрутизаторе (если сервер за NAT) и не заблокирован вышестоящим оборудованием или провайдером.
На Linux-сервере состояние правил можно посмотреть, например, через sudo nft list ruleset или инструмент вашего файрвола (ufw, firewalld — зависит от дистрибутива). Убедитесь, что входящий UDP-трафик на нужный порт разрешён. Точный синтаксис зависит от используемого инструмента, поэтому сверяйтесь с его документацией.
Отдельный сценарий — сервер за домашним роутером. В этом случае потребуется проброс порта (port forwarding) на внутренний адрес сервера, а также актуальный внешний IP или доменное имя в параметре Endpoint у клиентов. Если провайдер выдаёт «серый» адрес за CG-NAT, входящие подключения могут быть невозможны в принципе — это проверяется у провайдера.
☑️ Быстрая диагностика сетевой части
MTU, маршрутизация и тонкие симптомы
Бывает иначе: handshake проходит, но соединение работает нестабильно — мелкие запросы успешны, а загрузка страниц или файлов зависает. Типичная причина — несоответствие MTU: крупные пакеты фрагментируются или отбрасываются на промежуточных узлах.
Возможная проверка — уменьшить значение MTU в секции [Interface] конфигурации (например, задать MTU = 1420 или ниже) и понаблюдать за поведением. Подбор оптимального значения зависит от конкретного канала, поэтому действуйте итеративно, проверяя результат после каждого изменения.
Также убедитесь, что AllowedIPs настроен корректно: этот параметр одновременно задаёт маршрутизацию и список разрешённых адресов пира. Ошибка здесь не мешает рукопожатию, но полностью блокирует полезный трафик, что внешне похоже на сбой согласования.
Почему handshake проходит, а интернет через туннель не работает
Почти всегда дело не в рукопожатии, а в AllowedIPs, маршрутизации или NAT на сервере. Проверьте, что на сервере включена маршрутизация пакетов (ip_forward) и настроен маскарадинг исходящего трафика, если клиенты выходят в интернет через туннель. Точные команды зависят от дистрибутива и файрвола.
Ошибка согласования в других VPN и программах
Формулировка про согласование с пиром встречается не только в WireGuard. В IPsec/IKE аналогичный сбой означает неудачу на этапе обмена IKE SA: причины те же по сути — несовпадение параметров аутентификации (PSK или сертификатов), несогласованные криптографические предложения, недоступность UDP-портов 500/4500. В OpenVPN подобные симптомы даёт таймаут TLS-handshake.
Общий порядок действий одинаков для любого протокола: сначала логи обеих сторон, затем ключи и параметры аутентификации, затем доступность портов и маршрутов. Смотреть журнал нужно на обеих сторонах соединения — сторона, которая отклоняет рукопожатие, обычно прямо пишет причину отказа.
⚠️ Внимание: не меняйте криптографические параметры и не отключайте проверки сертификатов «для теста» на рабочих системах. Такие упрощения открывают туннель для подмены пира. Диагностируйте причину, а не обходите защиту.
Нулевой счётчик принятых байт при растущем счётчике отправленных — верный признак того, что пакеты не доходят до пира или ответы не возвращаются: ищите проблему в сети, а не в ключах.
Порядок действий при неудаче
Соберём всё в единый алгоритм. Двигайтесь от простого к сложному, после каждого шага проверяя latest handshake:
- Посмотрите статус интерфейса и журнал на обеих сторонах.
- Сверьте публичные ключи и параметр Endpoint.
- Проверьте, что UDP-порт открыт и проброшен.
- Протестируйте подключение из другой сети, чтобы исключить блокировки провайдера.
- При проходящем handshake, но «висящем» трафике подберите MTU и проверьте AllowedIPs.
Если ни один шаг не помог, соберите полные логи обеих сторон и сверьтесь с документацией вашей версии ПО — поведение и сообщения об ошибках различаются между реализациями и платформами.
Частые вопросы
Handshake проходит, но пинг через туннель не работает. Это та же ошибка?
Нет. Если latest handshake показывает свежее время, согласование завершилось успешно. Ищите проблему в AllowedIPs, маршрутизации, правилах файрвола на туннельном интерфейсе или MTU.
Туннель работает дома, но не работает через мобильный интернет. Почему?
Вероятная причина — ограничения на стороне мобильного оператора: фильтрация UDP или блокировка нестандартных портов. Попробуйте сменить порт сервера на другой (например, на часто разрешённые значения вроде 53 или 443 UDP, если это не конфликтует с другими сервисами).
Нужно ли перезапускать сервер после добавления нового пира?
Зависит от способа настройки. При редактировании файла конфигурации изменения обычно применяются перезапуском интерфейса. Альтернатива — добавить пира «на лету» командой wg set без остановки интерфейса, но такие изменения нужно затем зафиксировать в конфиге.
Может ли ошибка согласования возникать из-за неправильного времени?
Значительное расхождение системного времени способно мешать работе отдельных реализаций и сопутствующих проверок. Включите синхронизацию времени по NTP на обеих сторонах — это простая и безопасная мера.
Что делать, если сервер находится за CG-NAT провайдера?
Входящие подключения в этом случае обычно невозможны. Варианты: запросить у провайдера публичный адрес, использовать VPS как промежуточный узел или применить решения с выходом через сторонний координирующий сервер. Выбор зависит от ваших задач и требований к приватности.