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. Запазете изхода от състоянието преди и след промяната и разликата става вашето доказателство.