WireGuard не показывает последнее рукопожатие: что проверить первым

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

Проверка — это разрешённый пакет к адресату, который peer должен переносить. Всё остальное на этом экране состояния описывает намерение, а не активность.

Простаивающему интерфейсу нечего сообщать

WireGuard выполняет рукопожатия лениво: первый пакет, которому нужен туннель, запускает обмен, и до этого интерфейс молчит. Peer, который настроили и ни разу не использовали, показывает пустое рукопожатие, ноль полученных байт и растущий разрыв с последнего. Такое состояние здорово для простаивающего клиента и тревожно только в том случае, если вы ожидали, что трафик уже пошёл. Проверьте и счётчики передачи, потому что они отделяют «ничего не отправлено» от «попробовали и не вышло».

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

Инициируйте трафик, который peer имеет право переносить

Выберите адрес внутри разрешённых префиксов peer на локальной машине и убедитесь, что таблица маршрутизации отправит его через интерфейс. Адресат вне этих префиксов даёт обычный маршрутизируемый запрос вообще без участия WireGuard. Используйте сервис, который быстро отвечает, например ping или короткое TCP-соединение, чтобы у попытки было видимое начало и конец. Затем перечитайте строку рукопожатия, вместо того чтобы смотреть на экран и ждать.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

Запрос маршрута важнее ping. Если он называет физический интерфейс, пакет так и не попал в туннель, и пустое рукопожатие — это ответ маршрутизации, а не криптографический. Исправьте маршрут, прежде чем отлаживать peer.

Сравните пару ключей и конечную точку

Когда трафик действительно предложен, следующая проверка — идентичность. Локальный закрытый ключ должен соответствовать открытому ключу, который разрешает другая сторона, настроенный удалённый открытый ключ должен указывать на нужный peer, а любой предварительно разделённый ключ должен совпадать с обеих сторон. Разница в одном символе в ключе base64 даёт peer, который выглядит настроенным и никогда не завершает обмен. Сравнивайте с записью подготовки, а не создавайте ключи заново, потому что новый ключ обнуляет каждый peer, который доверял старому.

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

Следите за внешним путём UDP

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

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