WireGuard skickar data men får ingenting tillbaka: vilken sida?

Sändräknare som stiger medan mottagningsräknaren stannar på noll beskriver en riktning, inte en diagnos. Samma avläsning visas när peeren aldrig slutförde en handskakning, när destinationen valde fel peer, när den bortre sidan saknar väg tillbaka och när ett filter släpper svaret på vägen hem. Var och en av dem repareras på ett annat ställe.

Jämförelsen som förkortar arbetet är mellan en begäran som aldrig lämnade tunneln och ett svar som aldrig kom tillbaka. En fångst på rätt gränssnitt avgör mellan dem.

Räknare beskriver volym, inte felets riktning

WireGuards räknare registrerar vad gränssnittet lämnade till peeren och vad det tog emot från den. De säger inte vilken destination, vilken peer eller vilken halva av ett utbyte som misslyckades. Bakgrundstrafik gör summorna ännu mindre informativa, eftersom vissa byte kan vara keepalives eller orelaterade flöden. Läs dem som en indikation på att gränssnittet är aktivt och sluta sedan behandla dem som bevis.

Det första användbara faktumet är om en handskakning är aktuell. Utan den krypterades ingenting för den här peeren och mottagningsräknaren har ingen anledning att röra sig.

Val av peer eller svarets väg: två förklaringar

Den första förklaringen är att paketet aldrig nådde den avsedda peeren, eftersom rutten pekade någon annanstans eller peerens tillåtna prefix inte täckte destinationen. Den andra är att paketet kom fram och svaret inte kunde återvända, vilket är ett routingproblem i den bortre änden. Tabellen skiljer dem åt efter vad du skulle observera vid varje punkt.

Läs tabellen uppifrån. En saknad handskakning skickar dig till nycklar, ändpunkter och den yttre vägen, eftersom det ännu inte finns något annat att undersöka. En aktuell handskakning med begäran synlig på servern flyttar problemet till returriktningen, där destinationens egen routingtabell avgör. En begäran som aldrig dyker upp på servern är ett urvalsproblem, och de tillåtna prefixen på båda peerarna är det första som måste jämföras.

Två av dessa fyra rader repareras på klienten och två på servern. Att veta vilket par du är i är det mesta av arbetet.

Var svar försvinner

Ett svar lämnar destinationen, når serverns tunnelgränssnitt och krypteras för den peer vars tillåtna adresser matchar klientens inre adress. Om den matchningen misslyckas kastas svaret tyst, vilket från klientsidan ser exakt ut som ett nätverksfel. Om svaret är krypterat och klientens eget filter avvisar det är symtomet återigen identiskt. Båda fallen behöver fångsten i stället för räknaren.

Den starkaste formen av detta fel är en server som vidarebefordrar paket åt klienten men saknar väg tillbaka till klientens inre intervall. Den tar emot begäran, skickar svaret mot sin standardgateway och tunneln ser det aldrig. En bred översättningsregel som läggs till på servern döljer felet i stället för att reparera rutten.

Testa en destination från början till slut

Välj en enda destination inom peerens intervall och testa den medan en handskakning bevisligen är aktuell. Kommandona nedan läser peerens tillstånd, den valda rutten och båda sidor av utbytet. Kör fångsten på det gränssnitt som de krypterade paketen faktiskt använder.

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 fångst som visar begäran på tunnelgränssnittet utan att något kommer tillbaka är ett svar från serversidan, och destinationens routingtabell är nästa ställe att titta på. Om ingenting alls visas tog paketet en annan väg, så den lokala rutten är den misstänkta. Ett utbyte som syns i båda fångsterna utan framsteg i applikationen flyttar frågan till paketstorlek eller till ett filter som gränssnittsstatistiken aldrig visar. Håll en destination och en klient i testet, eftersom en andra variabel förvandlar bevis till en känsla igen.

Om namn misslyckas medan en tillåten adress fungerar ligger svaret i DNS och inte i tunneln. Om bara stora överföringar fastnar, undersök paketstorleken separat.