WireGuard sender data, men får intet tilbage: hvilken side?
En stigende sendetæller er en retning, ikke en diagnose. Afgør, om forespørgslen aldrig forlod tunnelen, eller svaret aldrig kom tilbage, før du ændrer noget.
Sendetællere, der stiger, mens modtagertælleren bliver på nul, beskriver en retning, ikke en diagnose. Samme aflæsning vises, når peer'en aldrig fuldførte et handshake, når destinationen valgte den forkerte peer, når den fjerne side ikke har nogen rute tilbage, og når et filter smider svaret væk på vej hjem. Hver af dem repareres et andet sted.
Den sammenligning, der forkorter arbejdet, er mellem en forespørgsel, der aldrig forlod tunnelen, og et svar, der aldrig kom tilbage. Én optagelse på det rigtige interface afgør det.
Tællere beskriver volumen, ikke fejlens retning
WireGuards tællere registrerer, hvad interfacet overlod til peer'en, og hvad det modtog fra den. De siger ikke, hvilken destination, hvilken peer eller hvilken halvdel af en udveksling der fejlede. Baggrundstrafik gør totalerne endnu mindre informative, da nogle bytes kan være keepalives eller urelaterede strømme. Læs dem som en indikator på, at interfacet er aktivt, og hold så op med at behandle dem som bevis.
Den nyttige første kendsgerning er, om et handshake er aktuelt. Uden det blev intet krypteret til denne peer, og modtagertælleren har ingen grund til at bevæge sig.
Valg af peer eller svarets vej: to forklaringer
Den første forklaring er, at pakken aldrig nåede den tilsigtede peer, fordi ruten pegede et andet sted hen, eller fordi peer'ens tilladte præfikser ikke dækkede destinationen. Den anden er, at pakken ankom, og svaret ikke kunne vende tilbage, hvilket er et ruteproblem i den fjerne ende. Tabellen adskiller dem efter, hvad du ville observere på hvert punkt.
| Observation | Points to |
|---|---|
| No handshake while transmit climbs | Peer selection or endpoint |
| Handshake current, request visible on the server | Reply path or far-side route |
| Request never visible on the server | Allowed prefixes or local route |
| Both packets visible, nothing reaches the client | Return filter or translation |
Læs tabellen ovenfra. Et manglende handshake sender dig til nøgler, endepunkter og den ydre vej, fordi der ikke findes noget andet at undersøge endnu. Et aktuelt handshake med forespørgslen synlig på serveren flytter problemet til returretningen, hvor destinationens egen rutetabel afgør det. En forespørgsel, der aldrig vises på serveren, er et valgproblem, og de tilladte præfikser på begge peers er det første, der skal sammenlignes.
To af de fire rækker rettes på klienten, og to på serveren. At vide, hvilket par du er i, er det meste af arbejdet.
Hvor svar forsvinder
Et svar forlader destinationen, når serverens tunnelinterface og bliver krypteret til den peer, hvis tilladte adresser matcher klientens indre adresse. Hvis den matchning fejler, kasseres svaret lydløst, hvilket ser præcis ud som en netværksfejl fra klientsiden. Hvis svaret er krypteret, og klientens eget filter afviser det, er symptomet igen identisk. Begge tilfælde kræver optagelsen frem for tælleren.
Den stærkeste version af denne fejl er en server, der videresender pakker for klienten, men ikke har nogen rute tilbage til klientens indre område. Den accepterer forespørgslen, sender svaret mod sin standardgateway, og tunnelen ser det aldrig. En bred oversættelsesregel tilføjet på serveren skjuler den fejl i stedet for at reparere ruten.
Test én destination fra ende til ende
Vælg en enkelt destination inden for peer'ens område, og test den, mens et handshake beviseligt er aktuelt. Kommandoerne nedenfor læser peer'ens tilstand, den valgte rute og begge sider af udvekslingen. Kør optagelsen på det interface, som de krypterede pakker faktisk bruger.
wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5
En optagelse, der viser forespørgslen på tunnelinterfacet uden noget, der kommer tilbage, er et svar fra serversiden, og destinationens rutetabel er det næste sted at kigge. Hvis der slet ikke vises noget, tog pakken en anden vej, så den lokale rute er den mistænkte. En udveksling, der er synlig i begge optagelser uden fremskridt i applikationen, flytter spørgsmålet til pakkestørrelse eller til et filter, som interfacestatistikken aldrig viser. Hold én destination og én klient i testen, fordi en anden variabel gør bevis til en fornemmelse igen.
Hvis navne fejler, mens en tilladt adresse virker, ligger svaret i DNS og ikke i tunnelen. Hvis kun store overførsler går i stå, skal pakkestørrelsen undersøges separat.