Если рукопожатие WireGuard есть, но данные не передаются, пиры недавно аутентифицировали друг друга, однако судьба тестового пакета остаётся неизвестной. Создайте один контролируемый поток и сравните свежие приращения отправленных и принятых байтов на обеих сторонах. Полученная картина укажет, нужно ли проверять локальный маршрут и выбор пира, внешний путь, удалённую пересылку и возврат либо более высокий уровень — DNS, MTU или приложение.

Полное руководство по VPN описывает все стадии подключения. Эта инструкция начинается только после обновления latest handshake у именно того пира, который вы собираетесь проверять.

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

Актуальное рукопожатие доказывает взаимную аутентификацию, но не использование туннеля выбранным приложением.［1］

Сравнивайте приращения счётчиков вокруг одного теста, а не накопленные итоги с посторонним трафиком.

Отсутствие локального TX указывает прежде всего на маршрут или выбор пира; TX без RX означает односторонний разрыв.

Когда TX и RX растут вместе с пробой, переходите к DNS, MTU, транспорту или приложению.

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

Как проверить: рукопожатие WireGuard есть, но данные не передаются?

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

Интерфейс wg показывает время последнего рукопожатия и накопленные объёмы передачи пира.［2］ Счётчики полезны, когда вы записали их непосредственно до и после узкой проверки. Фоновый keepalive, другое приложение или старая передача могут создать ненулевые значения, хотя текущий поток вообще не вошёл в туннель.

При криптографической маршрутизации (cryptokey routing) префиксы назначения и источника участвуют в выборе пира. Исходящий пакет назначается пиру по адресу назначения, а принятый пакет сверяется с разрешёнными исходными префиксами отправившего пира.［3］ Правильное рукопожатие с пиром A ничего не говорит о пакете, который система направила в другой интерфейс или назначила пиру B.

Семь шагов проверки пути данных

Шаг 1. Определите один контролируемый поток

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

Не начинайте с имени хоста. DNS добавляет отдельный запрос, маршрут к резолверу, кэш и, возможно, несколько результатов IPv4 и IPv6. Сначала используйте числовой адрес, а имя проверяйте после подтверждения пути пакета.

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

Остановитесь, если рукопожатие выбранного пира неактуально. Это ошибка рукопожатия или личности, а не состояние после него. Руководство по ответу сервера при неудачном рукопожатии помогает отделить доступность от аутентификации.

Шаг 2. Прочитайте матрицу приращений TX/RX

Направления ниже названы с точки зрения инициатора теста. TX клиента — зашифрованные транспортные байты, отправленные инициирующим пиром; RX сервера — байты, принятые соответствующим пиром. Объёмы включают служебные данные и не обязаны совпадать, поэтому ищите временную и направленную связь.

Новое наблюдение во время одной пробы	Что проверить сначала	Почему
TX клиента не растёт	Маршрут клиента, исходная политика, выбор пира	Проба не стала данными этого пира
TX клиента растёт, RX сервера нет	Внешний адрес пира (Endpoint), маршрут, межсетевой экран, NAT	Шифрованный пакет вышел, но не дошёл
RX сервера растёт, пересылки нет	Исходный префикс, input/forward, межсетевой экран	WireGuard принял пакет, следующий шаг не выполнен
Сервер переслал пакет, ответа нет	Служба, фильтр, NAT или обратный маршрут	Запрос ушёл дальше, но не вернулся
Ответ пришёл на сервер, RX клиента нет	Обратный пир, разрешённый источник, внешний возврат	Ответ не стал входными данными клиента
TX и RX клиента растут	DNS, MTU, TCP/TLS либо приложение	Шифрованный путь работает в обе стороны

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

Шаг 3. Если локальный TX не меняется, проверьте выбор пути

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

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

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

Исправляйте только одно поддерживаемое условие выбора. Повторите ту же пробу и отмените изменение, если выбранный интерфейс или приращение не поменялись.

Шаг 4. Если пакет вышел, но не пришёл, изучите внешний путь

Новое рукопожатие и потерянный транспортный пакет могут сосуществовать: состояние сети способно измениться после рукопожатия. Удалённый адрес (Endpoint) мог смениться из-за роуминга, состояние NAT могло истечь, мобильная сеть могла переключиться, а межсетевой экран — применить иное правило к последующим пакетам.

Сравните текущую конечную точку каждого пира с ожидаемой сессией, не публикуя частные адреса без необходимости. Когда мобильный пир инициирует новое аутентифицированное рукопожатие, другая сторона обычно узнаёт его последний адрес (Endpoint).［3］ Старые сведения до смены сети недостаточны.

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

Шаг 5. После роста RX удалённой стороны проследите внутренний пакет

Когда RX сервера растёт, определите, расположен внутренний адрес на самом сервере или за ним. Для локальной службы проверьте входной межсетевой экран, адрес прослушивания, порт и семейство адресов. Для внешнего назначения проверьте пересылку IP (IP forwarding), цепочку пересылки и предусмотренный интерфейс выхода.

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

Не добавляйте широкий NAT автоматически: он может оживить одну пробу, скрыв неправильную топологию. Проверка WireGuard без доступа в интернет продолжает диагностику шлюза, DNS и двойного стека IPv4/IPv6 после соответствующего результата счётчиков.

Шаг 6. При двусторонних приращениях покиньте уровень рукопожатия

Связанный с пробой рост TX и RX клиента показывает, что зашифрованные транспортные данные двигались в обе стороны. Если действие пользователя всё ещё не выполняется, прекратите заменять ключи и идентичности пира. Проверяйте следующий уровень.

Сначала сравните числовой адрес с именем. Затем сопоставьте небольшой запрос с крупным ответом и повторите для IPv4 и IPv6 отдельно. Работающий малый двусторонний обмен с зависанием больших данных поддерживает гипотезу о проблеме MTU WireGuard, а отказ только по имени указывает на DNS. TCP reset, TLS alert, HTTP-ошибка или ответ авторизации также доказывают, что туннель доставил обмен до следующего уровня.

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

Шаг 7. Сохраните доказательства и верните исходное состояние

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

Удалите временные маршруты, правила межсетевого экрана, генераторы трафика и тестовые службы. Если изменили постоянную привязку пира, проверьте административный источник истины, иначе после перезапуска неисправность вернётся. Не отправляйте wg show all dump: в нём могут раскрыться публичные идентичности, конечные точки, разрешённые префиксы и состояние PSK.

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

Может ли второй туннель служить контрольным тестом?

Когда ваш собственный пир завершает рукопожатие, но ничего не передаёт, независимый туннель на том же устройстве — дешёвый способ отделить проблемы устройства от проблем пира. Отключите собственный пир, установите AethoVPN, подключитесь к рекомендуемой локации и пропустите через него реальные данные, например загрузку страницы или короткое скачивание: если передача проходит, устройство и сеть доступа способны переносить туннелированный трафик, и следующим подозреваемым становятся AllowedIPs, пересылка или обратный маршрут вашего пира. AethoVPN показывает состояния подключения, а не исходные счётчики пира или захват пакетов, поэтому сравнение приращений TX/RX по-прежнему выполняется на вашем сервере. Начните 3-дневный бесплатный пробный период по email перед сравнением.

Итоги

Начинайте только после свежего рукопожатия нужного пира.
Снимайте новые TX/RX вокруг одной ограниченной пробы на числовой адрес.
Отсутствие TX означает проблему выбора; односторонние приращения указывают направление потери.
После серверного RX разделите локальную службу, пересылку, NAT и возврат.
При росте TX и RX переходите к DNS, MTU или приложению.
Отменяйте бесполезные эксперименты и храните только очищенную запись границы отказа.

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

Доказывает ли свежее рукопожатие правильность AllowedIPs?

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

Почему накопленные объёмы ненулевые, когда тест не проходит?

Они могут включать прежний сеанс, keepalive или другой поток. Снимите TX/RX на обеих сторонах до и после одного запроса и сравните только приращение.

Может ли рукопожатие оставаться свежим после изменения сетевого пути?

Да. Путь, адрес пира (Endpoint) или NAT могли измениться после последнего обмена. Сопоставьте внешний интерфейс и адрес пира с точным неудачным запросом.

Что означает рост TX клиента без роста RX сервера?

Локальный пир сформировал транспортные данные, но удалённый пир не зарегистрировал их получение в этом окне. Затем проверяйте внешний путь и фильтрацию.

Что проверять, если RX сервера растёт, а назначение ничего не видит?

Проверьте внутренний исходный адрес, локальные правила входящего трафика и пересылки, межсетевой экран, состояние пересылки и выбор выхода. Зашифрованный пакет уже прошёл рукопожатие.

Нужно ли менять ключи, когда TX и RX растут в обе стороны?

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

Достаточно ли keepalive, чтобы подтвердить передачу данных приложения?

Нет. Keepalive поддерживает состояние, но не проверяет назначение, размер ответа, DNS или протокол приложения. Используйте отдельный ограниченный запрос.

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

Источники:

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

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

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

Рукопожатие WireGuard есть, но данные не передаются