WireGuard sender data, men får ingenting tilbake: hvilken side?

Sendetellere som stiger mens mottakertelleren blir stående på null, beskriver en retning, ikke en diagnose. Samme avlesning vises når peer-en aldri fullførte en handshake, når destinasjonen valgte feil peer, når den fjerne siden ikke har noen rute tilbake, og når et filter slipper svaret på vei hjem. Hver av dem repareres på et annet sted.

Sammenligningen som forkorter arbeidet, er mellom en forespørsel som aldri forlot tunnelen og et svar som aldri kom tilbake. Én opptak på riktig grensesnitt avgjør det.

Tellere beskriver volum, ikke feilens retning

WireGuards tellere registrerer hva grensesnittet overleverte til peer-en og hva det mottok fra den. De sier ikke hvilken destinasjon, hvilken peer eller hvilken halvdel av en utveksling som feilet. Bakgrunnstrafikk gjør totalene enda mindre informative, siden noen byte kan være keepalives eller urelaterte strømmer. Les dem som en indikasjon på at grensesnittet er aktivt, og slutt deretter å behandle dem som bevis.

Det første nyttige faktumet er om en handshake er aktuell. Uten den ble ingenting kryptert for denne peer-en, og mottakertelleren har ingen grunn til å bevege seg.

Valg av peer eller svarets vei: to forklaringer

Den første forklaringen er at pakken aldri nådde den tiltenkte peer-en, fordi ruten pekte et annet sted, eller fordi peer-ens tillatte prefikser ikke dekket destinasjonen. Den andre er at pakken kom frem og svaret ikke kunne returnere, noe som er et ruteproblem i den fjerne enden. Tabellen skiller dem etter hva du ville observere på hvert punkt.

Les tabellen ovenfra. En manglende handshake sender deg til nøkler, endepunkter og den ytre veien, fordi det ikke finnes noe annet å undersøke ennå. En aktuell handshake med forespørselen synlig på serveren flytter problemet til returretningen, der destinasjonens egen rutetabell avgjør. En forespørsel som aldri vises på serveren, er et valgproblem, og de tillatte prefiksene på begge peer-er er det første som må sammenlignes.

To av disse fire radene rettes på klienten og to på serveren. Å vite hvilket par du er i, er det meste av arbeidet.

Hvor svar forsvinner

Et svar forlater destinasjonen, når serverens tunnelgrensesnitt og krypteres for peer-en hvis tillatte adresser samsvarer med klientens indre adresse. Hvis den samsvaren feiler, forkastes svaret lydløst, noe som fra klientsiden ser nøyaktig ut som en nettverksfeil. Hvis svaret er kryptert og klientens eget filter avviser det, er symptomet igjen identisk. Begge tilfellene trenger opptaket i stedet for telleren.

Den sterkeste versjonen av denne feilen er en server som videresender pakker for klienten, men ikke har noen rute tilbake til klientens indre område. Den godtar forespørselen, sender svaret mot standardgatewayen sin, og tunnelen ser det aldri. En bred oversettelsesregel lagt til på serveren skjuler den feilen i stedet for å reparere ruten.

Test én destinasjon fra ende til ende

Velg én enkelt destinasjon innenfor peer-ens område, og test den mens en handshake beviselig er aktuell. Kommandoene nedenfor leser peer-ens tilstand, den valgte ruten og begge sider av utvekslingen. Kjør opptaket på grensesnittet som de krypterte pakkene faktisk bruker.

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

Et opptak som viser forespørselen på tunnelgrensesnittet uten at noe kommer tilbake, er et svar fra serversiden, og destinasjonens rutetabell er det neste stedet å se. Hvis ingenting vises i det hele tatt, tok pakken en annen vei, så den lokale ruten er den mistenkte. En utveksling som er synlig i begge opptakene uten fremgang i applikasjonen, flytter spørsmålet til pakkestørrelse eller til et filter som grensesnittstatistikken aldri viser. Hold én destinasjon og én klient i testen, fordi en annen variabel gjør bevis til en følelse igjen.

Hvis navn feiler mens en tillatt adresse virker, ligger svaret i DNS og ikke i tunnelen. Hvis bare store overføringer stopper, må pakkestørrelsen undersøkes separat.