WireGuard viser ingen seneste håndtryk: hvad du skal tjekke først

Et tomt felt for seneste håndtryk betyder normalt, at grænsefladen ikke har fuldført et håndtryk, siden den kom op, hvilket siger mindre om konfigurationen, end det ser ud til. WireGuard er tavs, indtil en pakke skal forlade grænsefladen, så en inaktiv peer uden noget at sende rapporterer præcis det. Fastslå, om noget faktisk blev tilbudt, før du undersøger nøglerne.

Testen er en tilladt pakke mod en destination, som peeren bør bære. Alt andet på den statusskærm beskriver hensigt snarere end aktivitet.

En inaktiv grænseflade har intet at rapportere

WireGuard laver håndtryk dovent: den første pakke, der har brug for tunnelen, udløser udvekslingen, og grænsefladen er tavs indtil da. En peer, der blev konfigureret og aldrig brugt, viser et tomt håndtryk, nul modtagne bytes og et voksende mellemrum siden det sidste. Den tilstand er sund for en inaktiv klient og alarmerende kun, hvis du forventede, at trafikken allerede var løbet. Tjek også overførselsstællerne, fordi de adskiller intet-sendt fra forsøgt-og-fejlet.

Hvis stællerne står på nul på begge sider, ligger problemet opstrøms for tunnelen. Intet nåede grænsefladen for at udløse noget.

Udløs trafik, som peeren må bære

Vælg en adresse inden for peerens tilladte præfikser på den lokale maskine, og bekræft, at routingtabellen ville sende den gennem grænsefladen. En destination uden for de præfikser giver en almindelig routet anmodning helt uden WireGuard-indblanding. Brug en tjeneste, der svarer hurtigt, såsom en ping eller en kort TCP-forbindelse, så forsøget har en synlig begyndelse og slutning. Læs derefter håndtrykslinjen igen i stedet for at stirre på skærmen og vente.

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

Ruteopslaget betyder mere end pinget. Hvis det nævner den fysiske grænseflade, kom pakken aldrig ind i tunnelen, og det tomme håndtryk er et routing-svar snarere end et kryptografisk. Reparer ruten, før du fejlfinder peeren.

Sammenlign nøgleparret og endepunktet

Når trafikken reelt tilbydes, er identitet den næste kontrol. Den lokale private nøgle skal svare til den offentlige nøgle, som den anden side autoriserer, den konfigurerede eksterne offentlige nøgle skal identificere den tilsigtede peer, og enhver forudelt nøgle skal matche i begge ender. En enkelt tegnforskel i en base64-nøgle giver en peer, der ser konfigureret ud og aldrig fuldfører en udveksling. Sammenlign med klargøringsregistret i stedet for at genskabe nøgler, fordi en ny nøgle ugyldiggør enhver peer, der stolede på den gamle.

Endepunktet kræver samme granskning: værtsnavn, adresse, UDP-port og den familie, der bruges til at nå det. En forældet adresse eller den forkerte port giver tavshed snarere end en meddelelse.

Hold øje med den ydre UDP-vej

Håndtrykket rejser som UDP mod endepunktet, så den ydre vej skal bære det. Kommandoerne nedenfor tjekker, om der findes en lytter, om den lokale stak sendte datagrammet, og hvilket endepunkt der er konfigureret. Kør optagelsen, mens du udløser trafik, ikke før.

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

En optagelse, der viser initieringen uden svar, peger uden for maskinen, fordi den fjerne ende enten ikke lytter, er filtreret eller adresseret forkert. En optagelse, der slet intet viser, betyder, at pakken aldrig forlod maskinen, hvilket fører dig tilbage til ruten og til ethvert socket-mærke i spil. Når du administrerer begge ender, korreler forsøget efter tidsstempel med en snæver optagelse på serveren i stedet for en generel. En TCP-porttest beviser intet her, da protokollen kun er UDP.

Når et håndtryk vises, test en applikation gennem tunnelen, fordi en fuldført udveksling beviser identitet og nåelighed snarere end brugbar gennemstrømning eller korrekt DNS. Gem statusoutputtet fra før og efter ændringen, og forskellen bliver dit bevis.