WireGuard viser ingen siste håndtrykk: hva du bør sjekke først

Et tomt felt for siste håndtrykk betyr vanligvis at grensesnittet ikke har fullført et håndtrykk siden det kom opp, noe som sier mindre om konfigurasjonen enn det ser ut som. WireGuard er stille til en pakke må forlate grensesnittet, så en inaktiv peer uten noe å sende rapporterer nettopp det. Fastslå om noe faktisk ble tilbudt før du undersøker nøklene.

Testen er en tillatt pakke mot en destinasjon som peeren skal bære. Alt annet på den statusskjermen beskriver hensikt snarere enn aktivitet.

Et inaktivt grensesnitt har ingenting å rapportere

WireGuard gjør håndtrykk dovent: den første pakken som trenger tunnelen utløser utvekslingen, og grensesnittet er stille til da. En peer som ble konfigurert og aldri brukt viser et tomt håndtrykk, null mottatte byte og et voksende gap siden det forrige. Den tilstanden er sunn for en inaktiv klient og alarmerende bare hvis du forventet at trafikken allerede hadde flytt. Sjekk også overføringstellerne, fordi de skiller ingenting-sendt fra forsøkt-og-feilet.

Hvis tellerne står på null på begge sider, ligger problemet oppstrøms for tunnelen. Ingenting nådde grensesnittet for å utløse noe.

Utløs trafikk som peeren har lov til å bære

Velg en adresse innenfor peerens tillatte prefikser, på den lokale maskinen, og bekreft at rutetabellen ville sende den gjennom grensesnittet. En destinasjon utenfor disse prefiksene gir en vanlig rutet forespørsel helt uten WireGuard-involvering. Bruk en tjeneste som svarer raskt, for eksempel en ping eller en kort TCP-forbindelse, slik at forsøket har en synlig begynnelse og slutt. Les deretter håndtrykklinjen på nytt i stedet for å stirre på skjermen 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

Rutespørringen betyr mer enn pinget. Hvis den navngir det fysiske grensesnittet, kom pakken aldri inn i tunnelen, og det tomme håndtrykket er et ruting-svar snarere enn et kryptografisk. Reparer ruten før du feilsøker peeren.

Sammenlign nøkkelparet og endepunktet

Når trafikken faktisk tilbys, er identitet den neste kontrollen. Den lokale private nøkkelen må samsvare med den offentlige nøkkelen som den andre siden autoriserer, den konfigurerte eksterne offentlige nøkkelen må identifisere den tiltenkte peeren, og enhver forhåndsdelt nøkkel må stemme i begge ender. Én enkelt tegnforskjell i en base64-nøkkel gir en peer som ser konfigurert ut og aldri fullfører en utveksling. Sammenlign med klargjøringsregistret i stedet for å generere nøkler på nytt, fordi en ny nøkkel ugyldiggjør hver peer som stolte på den gamle.

Endepunktet trenger samme gransking: vertsnavn, adresse, UDP-port og familien som brukes for å nå det. En utdatert adresse eller feil port gir stillhet i stedet for en melding.

Følg med på den ytre UDP-veien

Håndtrykket reiser som UDP mot endepunktet, så den ytre veien må bære det. Kommandoene nedenfor sjekker om det finnes en lytter, om den lokale stakken sendte datagrammet, og hvilket endepunkt som er konfigurert. Kjør opptaket mens du utløser trafikk, ikke før.

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

Et opptak som viser initieringen uten svar, peker utenfor maskinen, fordi den andre enden enten ikke lytter, er filtrert eller er feiladressert. Et opptak som ikke viser noe i det hele tatt, betyr at pakken aldri forlot maskinen, noe som fører deg tilbake til ruten og til en eventuell socket-markering i spill. Når du administrerer begge ender, korreler forsøket etter tidsstempel med et smalt opptak på serveren i stedet for et generelt. En TCP-porttest beviser ingenting her, siden protokollen bare er UDP.

Når et håndtrykk dukker opp, test en applikasjon gjennom tunnelen, fordi en fullført utveksling beviser identitet og nåbarhet, ikke brukbar gjennomstrømning eller korrekt DNS. Ta vare på statusutskriften før og etter endringen, og forskjellen blir beviset ditt.