WireGuard viser ingen siste handtrykk: kva du bør sjekke først

Eit tomt felt for siste handtrykk tyder vanlegvis at grensesnittet ikkje har fullført eit handtrykk sidan det kom opp, noko som seier mindre om konfigurasjonen enn det ser ut som. WireGuard er stille til ein pakke må forlate grensesnittet, så ein inaktiv peer utan noko å sende rapporterer nettopp det. Fastslå om noko faktisk vart tilbode før du undersøkjer nøklane.

Testen er ein tillaten pakke mot ein destinasjon som peeren skal bera. Alt anna på den statusskjermen skildrar hensikt snarare enn aktivitet.

Eit inaktivt grensesnitt har ingenting å rapportere

WireGuard gjer handtrykk dovent: den første pakka som treng tunnelen utløyser utvekslinga, og grensesnittet er stille til då. Ein peer som vart konfigurert og aldri brukt viser eit tomt handtrykk, null mottekne byte og eit veksande gap sidan det førre. Den tilstanden er sunn for ein inaktiv klient og alarmerande berre viss du venta at trafikken alt hadde flytt. Sjekk også overføringsteljarane, fordi dei skil ingenting-sendt frå forsøkt-og-feila.

Viss teljarane står på null på begge sider, ligg problemet oppstraums for tunnelen. Ingenting nådde grensesnittet for å utløysa noko.

Utløys trafikk som peeren har lov til å bera

Vel ein adresse innanfor dei tillatne prefiksa til peeren, på den lokale maskina, og stadfest at rutetabellen ville sendt henne gjennom grensesnittet. Ein destinasjon utanfor desse prefiksa gir ein vanleg ruta førespurnad heilt utan WireGuard-involvering. Bruk ein teneste som svarar raskt, til dømes ein ping eller ei kort TCP-tilkopling, slik at forsøket har ei synleg byrjing og slutt. Les deretter handtrykklinja på nytt i staden for å stira på skjermen og venta.

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ørjinga tyder meir enn pinget. Viss ho namngir det fysiske grensesnittet, kom pakka aldri inn i tunnelen, og det tomme handtrykket er eit ruting-svar snarare enn eit kryptografisk. Reparer ruta før du feilsøkjer peeren.

Samanlikn nøkkelparet og endepunktet

Når trafikken faktisk vert tilboden, er identitet den neste kontrollen. Den lokale private nøkkelen må svare til den offentlege nøkkelen som den andre sida autoriserer, den konfigurerte eksterne offentlege nøkkelen må identifisere den tiltenkte peeren, og ein kvar førehandsdel nøkkel må stemme i begge endar. Éin einaste teiknskilnad i ein base64-nøkkel gir ein peer som ser konfigurert ut og aldri fullfører ei utveksling. Samanlikn med klargjeringsregisteret i staden for å generere nøklar på nytt, fordi ein ny nøkkel gjer kvar peer ugyldig som stolte på den gamle.

Endepunktet treng same gransking: vertsnamn, adresse, UDP-port og familien som vert brukt for å nå det. Ei utdatert adresse eller feil port gir stillheit i staden for ei melding.

Følg med på den ytre UDP-vegen

Handtrykket reiser som UDP mot endepunktet, så den ytre vegen må bera det. Kommandoane nedanfor sjekkar om det finst ein lyttar, om den lokale stakken sende datagrammet, og kva endepunkt som er konfigurert. Køyr opptaket medan du utløyser trafikk, ikkje før.

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

Eit opptak som viser initieringa utan svar, peikar utanfor maskina, fordi den andre enden anten ikkje lyttar, er filtrert eller er feiladressert. Eit opptak som ikkje viser noko i det heile, tyder at pakka aldri forlet maskina, noko som fører deg tilbake til ruta og til ein eventuell socket-markering i spel. Når du administrerer begge endar, korreler forsøket etter tidsstempel med eit smalt opptak på serveren i staden for eit generelt. Ein TCP-porttest beviser ingenting her, sidan protokollen berre er UDP.

Når eit handtrykk dukkar opp, test ein applikasjon gjennom tunnelen, fordi ei fullført utveksling beviser identitet og nåbarheit, ikkje brukbar gjennomstrøyming eller korrekt DNS. Ta vare på statusutskrifta før og etter endringa, og skilnaden vert beviset ditt.