Несовпадение ключей WireGuard означает, что хотя бы одна запись пира не содержит публичную идентичность, выведенную из активного закрытого ключа другой стороны, либо различаются необязательные предварительно согласованные ключи. Тишина не показывает, какая сторона неверна. Составьте двустороннюю карту открытых ключей по доверенным локальным наблюдениям и меняйте материал только после обнаружения устаревшей связи.

Полное руководство по VPN охватывает остальные стадии подключения. Здесь исследуются только статические личности WireGuard и согласованность необязательного PSK.

Ключевые выводы

Каждая сторона хранит собственный закрытый ключ и записывает открытый ключ другой стороны как идентичность пира.［1］

Сравнивайте только открытые ключи или контролируемые отпечатки (fingerprints); никогда не обменивайтесь закрытыми ключами «для проверки».

Неверный адрес пира (Endpoint), заблокированный UDP, ошибка маршрута или AllowedIPs выглядят как проблема ключа.

Свежее рукопожатие доказывает совпадение активных статических ключей этого пира в тот момент.

Несовпадение PSK — отдельная проверка секретного состояния; исходные значения нельзя показывать для визуального сравнения.

Как связаны ключи WireGuard?

У каждого интерфейса WireGuard есть статический закрытый ключ. Математически выведенный открытый ключ служит личностью интерфейса. В записи пира хранится открытый ключ удалённого интерфейса. Во время рукопожатия каждая сторона использует свой закрытый ключ и настроенный удалённый открытый ключ; протокол не передаёт согласуемое имя пользователя, способное исправить ошибочную связь.［1］

Техническое описание (whitepaper) связывает пир с открытыми ключами и разрешёнными IP-адресами.［2］ Таким образом, один интерфейс имеет несколько независимых сущностей: свою локальную личность, ожидаемую личность каждого удалённого пира и префиксы адресов, назначенные пиру. Правильная пара ключей всё равно может не передавать полезные данные при неверной адресной привязке.

Необязательный PSK усиливает криптографию с открытыми ключами. Руководство wg описывает поля закрытого ключа, публичных ключей пира, PSK, адреса пира (Endpoint), разрешённых IP, keepalive и текущего состояния.［3］ PSK обязан совпадать на обеих сторонах, но остаётся секретом. Безопасная процедура сравнивает происхождение или локально рассчитанный контролируемый идентификатор, а не исходное значение в чате, заявке, снимке экрана или выводе команды.

Материал стороны A	Ожидаемая связь	Материал стороны B
Активный закрытый ключ A	Выводит	Наблюдаемый открытый ключ A
Открытый ключ B в записи A	Должен равняться	Наблюдаемому открытому ключу B
Открытый ключ A в записи B	Должен равняться	Наблюдаемому открытому ключу A
PSK для B на стороне A	То же поколение секрета	PSK для A на стороне B
`AllowedIPs` для B на стороне A	Отправляет адреса к B	Это не сравнение ключей

Какие признаки подтверждают несовпадение ключей WireGuard?

Сильный контекст — недавно импортированный профиль, который ни разу не выполнил рукопожатие после ротации ключа на одной стороне. Прямое доказательство — публичный ключ в записи пира, не равный ключу, локально выведенному на предназначенном удалённом устройстве. Немедленный отказ после контролируемой замены также сужает окно изменений.

Повторные сообщения инициации без ответа неспецифичны. UDP может блокироваться, адрес пира может быть устаревшим, состояние NAT — истечь, служба — не слушать, а пир — быть выключенным. Руководство по ответу сервера без успешного рукопожатия объясняет, почему доступность и аутентификацию нельзя смешивать.

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

Семь шагов проверки ключей

Шаг 1. Обозначьте две конечные стороны до чтения ключей

Дайте конечным сторонам однозначные рабочие имена, например laptop-2026 и gateway-east, и запишите ответственного администратора. Отметьте ожидаемый интерфейс, запись пира, адрес пира (Endpoint) и клиентский адрес, не копируя полную конфигурацию. Многие «несовпадения» оказываются сравнением старой записи устройства с новым устройством похожего имени.

Зафиксируйте время неудачной попытки и latest handshake нужного пира на обеих сторонах. Если шлюз обслуживает несколько клиентов, находите запись по открытому ключу и назначенному префиксу, а не по положению в списке.

Не переименовывайте, не удаляйте и не генерируйте ничего во время инвентаризации. Изменённый ключ уничтожит сведения, необходимые для различения старого файла, активного процесса и удалённой записи.

Шаг 2. Выведите локальные публичные идентичности на месте

На стороне A используйте доверенный инструмент WireGuard, чтобы вывести или показать открытый ключ, соответствующий закрытому ключу фактически работающего интерфейса. Сохраните в таблице только публичный результат. Повторите локально на стороне B.

Не копируйте закрытые ключи во временные каталоги и не передавайте их через историю командной оболочки. Не загружайте ключ в онлайн-декодер. Если платформа не может безопасно показать активный открытый ключ, используйте поддерживаемое окно регистрации или администрирования и запишите публичную личность оттуда.

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

Остановитесь, если на любой стороне невозможно получить доверенную публичную идентичность. Запросите у уполномоченного администратора подтверждение открытого ключа либо его отпечатка, но не закрытый ключ.

Шаг 3. Сравните связь в обоих направлениях

Прочитайте на A открытый ключ пира B и сравните с наблюдаемой локально публичной идентичностью B. Затем прочитайте на B открытый ключ пира A и сопоставьте с идентичностью A. Это две независимые связи: одна может быть актуальной, другая — устаревшей.

Сравнение	Результат	Интерпретация
A ожидает B = наблюдаемый B	Совпадение	Удалённая запись A согласована
A ожидает B ≠ наблюдаемый B	Несовпадение	Запись A либо предназначенная личность B устарела
B ожидает A = наблюдаемый A	Совпадение	Удалённая запись B согласована
B ожидает A ≠ наблюдаемый A	Несовпадение	Запись B либо предназначенная личность A устарела
Обе связи совпали	Статическая ошибка не показана	Проверяйте PSK, адрес пира, путь и выбор пира

Несовпадение называет противоречивую связь, но не виновного человека или компьютер. Проверьте в источнике регистрации, какая публичная идентичность авторизована. Устройство могло правомерно сменить ключ, а серверная запись не получить обновление; либо локальная замена была несанкционированной.

Когда возможно, сравнивайте открытые ключи точно в защищённой административной сессии. Если заявка или устный канал не должны переносить полный ключ, вычислите отпечаток одинаковым документированным алгоритмом и кодировкой на обеих сторонах. Укажите алгоритм: короткий визуальный префикс может совпасть случайно или быть переписан с ошибкой.

Шаг 4. Обработайте PSK, не раскрывая его

Сначала определите, должны ли обе записи пира использовать PSK. Состояние «есть» на одной стороне и «нет» на другой уже противоречиво. Если PSK присутствует у обеих, подтвердите, что он происходит из одной контролируемой операции создания и доставки.

Когда политика разрешает локальную проверку, вычислите контролируемый криптографический идентификатор на месте и сравните только его по утверждённому каналу. Не публикуйте быстрый несолёный хеш секрета с низкой энтропией. Часто безопаснее создать новый PSK в системе управления секретами и развернуть его на обеих записях, нигде не отображая.

Никогда не ставьте PSK в командную строку, сохраняемую в истории или списке процессов. Статус wg, сообщающий наличие PSK, не доказывает равенство значений.

Шаг 5. Исключите похожие отказы до ротации

Подтвердите, что адрес пира (Endpoint) и UDP-порт ведут к нужному интерфейсу. Идеальная карта ключей не даст ответа, если пакет отправлен старому хосту. Узкие счётчики межсетевого экрана и пакетов помогут понять, приходят ли сообщения инициации и уходят ли ответы.

Сравните ожидаемый пир с маршрутом и AllowedIPs. Руководство по AllowedIPs показывает привязку префиксов. Неправильные префиксы вызывают отсутствие данных после успешного рукопожатия, а дублированная запись заставляет смотреть чужие счётчики.

Убедитесь, что обе стороны загрузили ожидаемое поколение конфигурации, а restart, container, network namespace или агент управления не использовали иной файл. Нельзя выводить mismatch из общего сообщения «нет ответа», не имея наблюдения удалённой стороны.

Шаг 6. Исправьте только доказанно устаревшую связь

После определения разрешённой публичной личности источником регистрации обновите только противоречивую запись удалённого пира через поддерживаемый канал. Не копируйте закрытый ключ удалённой стороны как shortcut. По местной политике сохраните старую публичную запись и ссылку на изменение для rollback и audit.

Если локальный закрытый ключ заменили без разрешения или его конфиденциальность сомнительна, рассматривайте это как security incident. Создайте новую пару в утверждённой среде, распространите только новый открытый ключ всем разрешённым пирам, отзовите прежнюю личность и найдите оставшиеся записи. Это шире исправления опечатки и требует координации администратора.

При ошибке PSK разверните один новый секрет на обеих сторонах через утверждённый секретный канал. Не удаляйте PSK временно ради соединения, если владелец явно не принял изменение безопасности и политика протокола его не разрешает.

Шаг 7. Проверьте личность и данные как разные этапы

Запустите одну разрешённую попытку и подтвердите обновление последнего рукопожатия предназначенного пира на обеих сторонах. Затем измерьте свежие TX/RX вокруг небольшой пробы на числовой адрес. Handshake доказывает исправленную идентичность, а счётчики и приложение отдельно доказывают последующие стадии.

Проверьте, что endpoint, назначенные префиксы и маршрут относятся к подписанному устройству. Ремонт ключа не должен незаметно расширять AllowedIPs или менять клиентский адрес. Удалите временный доступ и рабочие таблицы по правилам хранения.

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

Когда управляемое VPN-приложение проще ручного ведения ключей?

Несовпадение ключей — это эксплуатационная цена собственных пиров. Если вам нужно лишь личное соединение для своих устройств, AethoVPN предлагает путь без такого учёта: документированные шаги — продолжить по коду подтверждения из письма, установить клиент на Windows, Linux или Android (либо пройти мастер настройки на сайте для Mac и iPhone с тарифом Pro или Premium) и выбрать локацию в приложении. Эти шаги не предполагают импорта или проверки ключей WireGuard, поэтому несовпадение между вашими собственными пирами по-прежнему устраняется сверкой публичных ключей на обеих сторонах; и никогда не отправляйте закрытые ключи или PSK ни в какую службу поддержки, включая поддержку AethoVPN. Создайте аккаунт по email, чтобы сравнить управляемый вариант с самостоятельным ведением ключей.

Итоги

Обозначьте точные активные конечные стороны и записи пира до сравнения.
Выводите открытые ключи локально и не перемещайте закрытые ключи ради диагностики.
Сравните ожидаемый B на A с наблюдаемым B, затем выполните обратную проверку.
Проверяйте необязательный PSK как отдельную цепочку доставки секрета.
Исключите адрес пира (Endpoint), межсетевой экран, поколение процесса, маршрут и AllowedIPs.
Исправьте только устаревшую связь и отдельно проверьте рукопожатие и передачу данных.

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

Можно ли по отсутствию рукопожатия определить ошибочную сторону?

Нет. Так же выглядят несовпадение ключей, неверный адрес пира, блокировка UDP, остановленная служба, истёкший NAT и отключённый пир. Нужны доверенные данные обеих сторон.

Безопасно ли передавать открытый ключ WireGuard?

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

Можно ли непосредственно сравнить закрытые ключи?

Нет. Каждый закрытый ключ должен оставаться на своём устройстве или в системе хранения секретов. Локально выведите открытые ключи и сравните их.

Исключает ли свежее рукопожатие несовпадение ключей?

Оно исключает несовпадение активных статических личностей и PSK, использованных этим пиром в тот момент. Другие пиры и последующий маршрут не подтверждены.

Как узнать, совпадают ли PSK?

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

Нужно ли пересоздавать обе пары при любой ошибке WireGuard?

Нет. Массовая ротация уничтожает доказательства и расширяет распространение. Меняйте ключ после определения устаревшего материала или требования политики при компрометации.

Что передать в поддержку?

Передайте очищенные метки конечных сторон, время, версии, наблюдения за рукопожатием, два сравнения открытых ключей или утверждённые отпечатки и первый отказавший этап. Не передавайте закрытые ключи, PSK, профили и дампы.

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

Источники:

WireGuard, "Protocol & Cryptography": https://www.wireguard.com/protocol/
WireGuard, "WireGuard: Next Generation Kernel Network Tunnel": https://www.wireguard.com/papers/wireguard.pdf
WireGuard Tools, "wg(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg.8

Sources checked 12 сентября 2026 г.

Рекомендуемые статьи:

Несовпадение ключей WireGuard: как найти ошибочную сторону