WireGuard verzendt data maar krijgt niets terug: welke kant?
Een stijgende verzendteller is een richting, geen diagnose. Bepaal of het verzoek de tunnel nooit heeft verlaten of dat het antwoord nooit terugkwam voordat u iets wijzigt.
Verzendtellers die stijgen terwijl de ontvangstteller op nul blijft, beschrijven een richting, geen diagnose. Dezelfde uitlezing verschijnt wanneer de peer nooit een handshake heeft voltooid, wanneer de bestemming de verkeerde peer koos, wanneer de andere kant geen route terug heeft en wanneer een filter het antwoord onderweg naar huis laat vallen. Elk daarvan wordt op een andere plek gerepareerd.
De vergelijking die het werk verkort, is die tussen een verzoek dat de tunnel nooit verliet en een antwoord dat nooit terugkwam. Eén opname op de juiste interface beslist tussen beide.
Tellers beschrijven volume, niet de richting van de storing
De tellers van WireGuard leggen vast wat de interface aan de peer gaf en wat hij daarvan ontving. Ze zeggen niet welke bestemming, welke peer of welke helft van een uitwisseling faalde. Achtergrondverkeer maakt de totalen nog minder informatief, omdat sommige bytes keepalives of ongerelateerde stromen kunnen zijn. Lees ze als een aanwijzing dat de interface actief is en behandel ze daarna niet meer als bewijs.
Het eerste nuttige feit is of een handshake actueel is. Zonder die is er niets voor deze peer versleuteld en heeft de ontvangstteller geen reden om te bewegen.
Peerkeuze of de terugweg van het antwoord: twee verklaringen
De eerste verklaring is dat het pakket de bedoelde peer nooit bereikte, omdat de route ergens anders heen wees of omdat de toegestane prefixen van de peer de bestemming niet dekten. De tweede is dat het pakket aankwam en het antwoord niet kon terugkeren, wat een routeringsprobleem aan de verre kant is. De tabel scheidt beide op basis van wat u op elk punt zou waarnemen.
| 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 |
Lees de tabel van bovenaf. Een ontbrekende handshake stuurt u naar sleutels, eindpunten en de buitenste route, omdat er nog niets anders te onderzoeken is. Een actuele handshake met het verzoek zichtbaar op de server verplaatst het probleem naar de retourrichting, waar de eigen routetabel van de bestemming beslist. Een verzoek dat nooit op de server verschijnt, is een keuzeprobleem, en de toegestane prefixen op beide peers zijn het eerste dat moet worden vergeleken.
Twee van die vier rijen worden op de client gerepareerd en twee op de server. Weten in welk paar u zit, is het grootste deel van het werk.
Waar antwoorden verdwijnen
Een antwoord verlaat de bestemming, bereikt de tunnelinterface van de server en wordt versleuteld voor de peer wiens toegestane adressen overeenkomen met het interne adres van de client. Als die overeenkomst faalt, wordt het antwoord stil weggegooid, wat er vanaf de clientkant precies als een netwerkstoring uitziet. Als het antwoord versleuteld is en het eigen filter van de client het weigert, is het symptoom opnieuw identiek. Beide gevallen hebben de opname nodig in plaats van de teller.
De sterkste vorm van deze fout is een server die pakketten voor de client doorstuurt maar geen route terug heeft naar het interne bereik van de client. Hij accepteert het verzoek, stuurt het antwoord naar zijn standaardgateway, en de tunnel ziet het nooit. Een brede vertaalregel die aan de server wordt toegevoegd, verbergt die fout in plaats van de route te repareren.
Test één bestemming van begin tot eind
Kies één bestemming binnen het bereik van de peer en test die terwijl een handshake aantoonbaar actueel is. De onderstaande opdrachten lezen de toestand van de peer, de gekozen route en beide kanten van de uitwisseling. Voer de opname uit op de interface die de versleutelde pakketten werkelijk gebruiken.
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
Een opname die het verzoek op de tunnelinterface toont zonder dat er iets terugkomt, is een antwoord van de serverkant, en de routetabel van de bestemming is de volgende plek om te kijken. Als er helemaal niets verschijnt, heeft het pakket een andere weg genomen, dus de lokale route is verdacht. Een uitwisseling die in beide opnames zichtbaar is zonder vooruitgang in de applicatie, verplaatst de vraag naar pakketgrootte of naar een filter dat de interfacestatistieken nooit tonen. Houd één bestemming en één client in de test, omdat een tweede variabele bewijs weer in een indruk verandert.
Als namen falen terwijl een toegestaan adres werkt, zit het antwoord in DNS en niet in de tunnel. Als alleen grote overdrachten vastlopen, onderzoek dan de pakketgrootte apart.