WireGuard visar ingen senaste handskakning: vad du bör kontrollera först

Ett tomt fält för senaste handskakning betyder oftast att gränssnittet inte har slutfört någon handskakning sedan det kom upp, vilket säger mindre om konfigurationen än det verkar. WireGuard är tyst tills ett paket måste lämna gränssnittet, så en inaktiv peer utan något att skicka rapporterar precis det. Fastställ om något faktiskt erbjöds innan du undersöker nycklarna.

Testet är ett tillåtet paket mot en destination som peeren ska bära. Allt annat på den statusskärmen beskriver avsikt snarare än aktivitet.

Ett inaktivt gränssnitt har inget att rapportera

WireGuard gör handskakningar lättjefullt: det första paketet som behöver tunneln utlöser utbytet, och gränssnittet är tyst till dess. En peer som konfigurerades och aldrig användes visar en tom handskakning, noll mottagna byte och en växande lucka sedan den förra. Det tillståndet är friskt för en inaktiv klient och alarmerande bara om du förväntade dig att trafiken redan hade flödat. Kontrollera även överföringsmätarna, eftersom de skiljer inget-skickat från försökt-och-misslyckats.

Om mätarna står på noll på båda sidor ligger problemet uppströms tunneln. Ingenting nådde gränssnittet för att utlösa något.

Utlös trafik som peeren får bära

Välj en adress inom peerens tillåtna prefix, på den lokala maskinen, och bekräfta att routingtabellen skulle skicka den genom gränssnittet. En destination utanför dessa prefix ger en vanlig routad begäran helt utan WireGuard-inblandning. Använd en tjänst som svarar snabbt, till exempel en ping eller en kort TCP-anslutning, så att försöket har en synlig början och ett slut. Läs sedan om handskakningsraden i stället för att stirra på skärmen och vänta.

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

Rutfrågan spelar större roll än pinget. Om den namnger det fysiska gränssnittet kom paketet aldrig in i tunneln, och den tomma handskakningen är ett routing-svar snarare än ett kryptografiskt. Reparera rutten innan du felsöker peeren.

Jämför nyckelparet och slutpunkten

När trafiken verkligen erbjuds är identitet nästa kontroll. Den lokala privata nyckeln måste motsvara den publika nyckeln som andra sidan auktoriserar, den konfigurerade externa publika nyckeln måste identifiera den avsedda peeren, och en eventuell fördelad nyckel måste stämma på båda sidor. En enda tecken skillnad i en base64-nyckel ger en peer som ser konfigurerad ut och aldrig slutför ett utbyte. Jämför med etableringsregistret i stället för att generera nycklar på nytt, eftersom en ny nyckel ogiltigförklarar varje peer som litade på den gamla.

Slutpunkten kräver samma granskning: värdnamn, adress, UDP-port och den familj som används för att nå den. En inaktuell adress eller fel port ger tystnad i stället för ett meddelande.

Håll koll på den yttre UDP-vägen

Handskakningen färdas som UDP mot slutpunkten, så den yttre vägen måste bära den. Kommandona nedan kontrollerar om det finns en lyssnare, om den lokala stacken skickade datagrammet och vilken slutpunkt som är konfigurerad. Kör fångsten medan du utlöser trafik, inte före.

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

En fångst som visar initieringen utan svar pekar utanför maskinen, eftersom den andra änden antingen inte lyssnar, är filtrerad eller är feladresserad. En fångst som inte visar någonting betyder att paketet aldrig lämnade maskinen, vilket leder dig tillbaka till rutten och till en eventuell socket-markering i spel. När du administrerar båda ändarna, korrelera försöket efter tidsstämpel med en smal fångst på servern i stället för en allmän. Ett TCP-porttest bevisar ingenting här, eftersom protokollet bara är UDP.

Så snart en handskakning dyker upp, testa en applikation genom tunneln, eftersom ett slutfört utbyte bevisar identitet och nåbarhet, inte användbar genomströmning eller korrekt DNS. Spara statusutskriften före och efter ändringen, och skillnaden blir ditt bevis.