WireGuard nie pokazuje ostatniego handshake: co sprawdzić najpierw

Puste pole ostatniego handshake zwykle oznacza, że interfejs nie ukończył żadnego handshake od chwili podniesienia, co mówi o konfiguracji mniej, niż się wydaje. WireGuard milczy, dopóki pakiet nie musi wyjść przez interfejs, więc bezczynny peer bez niczego do wysłania zgłasza dokładnie to. Ustal, czy coś rzeczywiście zostało zaproponowane, zanim sprawdzisz klucze.

Testem jest dozwolony pakiet w stronę celu, który peer powinien nieść. Wszystko inne na tym ekranie stanu opisuje zamiar, a nie aktywność.

Bezczynny interfejs nie ma nic do zgłoszenia

WireGuard wykonuje handshake leniwie: pierwszy pakiet potrzebujący tunelu uruchamia wymianę, a interfejs do tego czasu milczy. Peer skonfigurowany i nigdy nieużywany pokazuje pusty handshake, zero odebranych bajtów i rosnący odstęp od ostatniego. Ten stan jest zdrowy dla bezczynnego klienta i niepokojący tylko wtedy, gdy oczekiwałeś, że ruch już płynął. Sprawdź też liczniki transferu, ponieważ oddzielają nic-nie-wysłano od próbowano-i-nie udało się.

Jeśli liczniki po obu stronach stoją na zero, problem jest powyżej tunelu. Nic nie dotarło do interfejsu, aby cokolwiek wywołać.

Wywołaj ruch, który peer może nieść

Wybierz adres wewnątrz dozwolonych prefiksów peera na maszynie lokalnej i potwierdź, że tablica routingu wysłałaby go przez interfejs. Cel spoza tych prefiksów tworzy zwykłe trasowane żądanie bez żadnego udziału WireGuard. Użyj usługi, która odpowiada szybko, na przykład ping lub krótkie połączenie TCP, aby próba miała widoczny początek i koniec. Następnie przeczytaj ponownie linię handshake, zamiast patrzeć na ekran i czekać.

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

Zapytanie o trasę waży więcej niż ping. Jeśli wskazuje interfejs fizyczny, pakiet nigdy nie wszedł do tunelu, a pusty handshake jest odpowiedzią routingu, nie kryptograficzną. Napraw trasę, zanim zaczniesz debugować peera.

Porównaj parę kluczy i punkt końcowy

Gdy ruch jest rzeczywiście oferowany, następnym sprawdzeniem jest tożsamość. Lokalny klucz prywatny musi odpowiadać kluczowi publicznemu, który autoryzuje druga strona, skonfigurowany zdalny klucz publiczny musi identyfikować zamierzonego peera, a ewentualny klucz wstępnie współdzielony musi się zgadzać po obu stronach. Jedna różnica znaku w kluczu base64 daje peera, który wygląda na skonfigurowany i nigdy nie kończy wymiany. Porównuj z rekordem zaopatrzenia, zamiast generować klucze od nowa, ponieważ nowy klucz unieważnia każdego peera, który ufał staremu.

Punkt końcowy wymaga takiej samej kontroli: nazwa hosta, adres, port UDP i rodzina używana do dotarcia. Nieaktualny adres lub zły port dają ciszę zamiast komunikatu.

Obserwuj zewnętrzną ścieżkę UDP

Handshake podróżuje jako UDP w stronę punktu końcowego, więc zewnętrzna ścieżka musi go nieść. Poniższe polecenia sprawdzają, czy istnieje nasłuch, czy lokalny stos wysłał datagram i który punkt końcowy jest skonfigurowany. Uruchom przechwytywanie podczas wywoływania ruchu, a nie przed nim.

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

Przechwycenie pokazujące inicjację bez odpowiedzi wskazuje na zewnątrz maszyny, ponieważ druga strona albo nie nasłuchuje, albo jest filtrowana, albo ma zły adres. Przechwycenie, które nie pokazuje niczego, oznacza, że pakiet nigdy nie wyszedł, co prowadzi z powrotem do trasy i do ewentualnego znacznika gniazda. Gdy administrujesz oboma końcami, skoreluj próbę po znaczniku czasu z wąskim przechwyceniem na serwerze, a nie ogólnym. Test portu TCP niczego tu nie dowodzi, bo protokół to wyłącznie UDP.

Gdy pojawi się handshake, przetestuj aplikację przez tunel, ponieważ ukończona wymiana dowodzi tożsamości i osiągalności, a nie użytecznej przepustowości czy poprawnego DNS. Zachowaj wynik stanu sprzed i po zmianie, a różnica stanie się twoim dowodem.