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. Зачувајте го излезот од состојбата пред и по промената, и разликата станува ваш доказ.