WireGuard toont geen laatste handshake: wat u eerst moet controleren

Een leeg veld voor de laatste handshake betekent meestal dat de interface sinds het opkomen geen handshake heeft voltooid, wat minder over de configuratie zegt dan het lijkt. WireGuard blijft stil totdat een pakket de interface moet verlaten, dus een inactieve peer zonder iets te verzenden meldt precies dat. Stel vast of er werkelijk iets is aangeboden voordat u de sleutels onderzoekt.

De test is een toegestaan pakket naar een bestemming die de peer hoort te dragen. Al het overige op dat statusscherm beschrijft bedoeling, niet activiteit.

Een inactieve interface heeft niets te melden

WireGuard doet handshakes lui: het eerste pakket dat de tunnel nodig heeft, start de uitwisseling, en de interface blijft tot dan stil. Een peer die is geconfigureerd en nooit is gebruikt, toont een lege handshake, nul ontvangen bytes en een groeiende kloof sinds de laatste. Die toestand is gezond voor een inactieve client en alleen alarmerend als u verwachtte dat er al verkeer had moeten stromen. Controleer ook de overdrachtstellers, want die scheiden niets-verzonden van geprobeerd-en-mislukt.

Staan de tellers aan beide kanten op nul, dan ligt het probleem stroomopwaarts van de tunnel. Niets bereikte de interface om iets te starten.

Lok verkeer uit dat de peer mag dragen

Kies een adres binnen de toegestane prefixen van de peer, op de lokale machine, en bevestig dat de routetabel het via de interface zou sturen. Een bestemming buiten die prefixen levert een gewoon gerouteerd verzoek op zonder enige betrokkenheid van WireGuard. Gebruik een dienst die snel antwoordt, zoals een ping of een korte TCP-verbinding, zodat de poging een zichtbaar begin en einde heeft. Lees daarna de handshake-regel opnieuw in plaats van naar het scherm te kijken en te wachten.

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

De routequery is belangrijker dan de ping. Als die de fysieke interface noemt, is het pakket nooit in de tunnel gekomen en is de lege handshake een routing-antwoord, geen cryptografisch. Repareer de route voordat u de peer debugt.

Vergelijk het sleutelpaar en het eindpunt

Zodra verkeer echt wordt aangeboden, is identiteit de volgende controle. De lokale privésleutel moet overeenkomen met de publieke sleutel die de andere kant autoriseert, de geconfigureerde externe publieke sleutel moet de bedoelde peer identificeren, en een eventuele vooraf gedeelde sleutel moet aan beide kanten kloppen. Eén tekenverschil in een base64-sleutel levert een peer op die geconfigureerd lijkt en nooit een uitwisseling voltooit. Vergelijk met het inrichtingsrecord in plaats van sleutels opnieuw te genereren, want een nieuwe sleutel maakt elke peer ongeldig die op de oude vertrouwde.

Het eindpunt vraagt dezelfde controle: hostnaam, adres, UDP-poort en de familie waarmee het wordt bereikt. Een verouderd adres of de verkeerde poort levert stilte in plaats van een bericht.

Houd het externe UDP-pad in het oog

De handshake reist als UDP naar het eindpunt, dus het externe pad moet die dragen. De onderstaande opdrachten controleren of er een luisteraar is, of de lokale stack het datagram heeft verzonden en welk eindpunt is geconfigureerd. Voer de capture uit terwijl u verkeer uitlokt, niet ervoor.

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

Een capture die de initiatie zonder antwoord toont, wijst buiten de machine, omdat de andere kant ofwel niet luistert, gefilterd is of verkeerd is geadresseerd. Een capture die helemaal niets toont, betekent dat het pakket nooit is vertrokken, wat u terugbrengt bij de route en bij een eventuele socket-markering in het spel. Als u beide kanten beheert, correleer de poging dan op tijdstempel met een smalle capture op de server in plaats van een algemene. Een TCP-poorttest bewijst hier niets, want het protocol is alleen UDP.

Zodra er een handshake verschijnt, test een applicatie via de tunnel, want een voltooide uitwisseling bewijst identiteit en bereikbaarheid, niet bruikbare doorvoer of correcte DNS. Bewaar de statusuitvoer van voor en na de wijziging, en het verschil wordt uw bewijs.