UDP-scan zegt gefilterd: is je WireGuard-peer echt offline?

Scanners drukken open of gefilterd af voor een UDP-poort, en de conclusie volgt meestal binnen enkele seconden: de tunnel is kapot. Dat kan, maar de scan heeft dat niet aangetoond. UDP vervoert geen verbindingshandshake, en WireGuard antwoordt niets dat het niet kan authenticeren, dus stilte is het verwachte antwoord op de meeste probes.

Werk in plaats daarvan van de client naar buiten, en behandel de scan als één zwak datapunt tussen meerdere.

Wat de scanner wel en niet kan zien

Een UDP-scanner stuurt een payload en wacht. Komt er een ICMP port-unreachable terug, dan kan hij de poort als gesloten melden. Komt er niets terug, dan is het resultaat ontwerpmatig dubbelzinnig: een gefilterd pad, een afwezige host en een draaiende dienst die de payload negeerde, produceren allemaal dezelfde stilte. Drie verschillende toestanden, één uitvoerstring.

WireGuard maakt die dubbelzinnigheid opzettelijk erger. Het protocol accepteert een pakket alleen wanneer het zich authenticeert, dus een probe met de verkeerde sleutels wordt zonder antwoord weggegooid. Er is geen banner, geen versiestring en geen foutmelding om te fingerprintern.

Een TCP-test op hetzelfde poortnummer test niets verwant. Hij oefent een andere listener uit die misschien niet bestaat, en zijn weigering zegt niets over UDP.

Open gefilterde toestanden beschrijven dus de onzekerheid van de scanner nauwkeuriger dan je server.

Loop de echte client van het profiel naar binnen door

Begin met de eigen blik van de client. Heeft de interface een adres, noemt de configuratie het juiste eindpunt, en beweegt de handshake-teller wanneer een verbinding wordt geprobeerd? Een client die nooit een pakket stuurde en een client wiens pakketten werden gedropt, zien er in een statusvenster identiek uit. Alleen de tellers onderscheiden ze, dus lees eerst de tellers.

Kijk dan naar de serverkant terwijl één geautoriseerde poging plaatsvindt, in plaats van een aparte scan vanaf een derde locatie te draaien:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

Het eerste commando rapporteert de laatste handshake per peer, wat direct bewijs is dat een geauthenticeerde uitwisseling is voltooid. Het tweede laat zien of pakketten voor de listener überhaupt aankomen, wat een padprobleem in één stap van een configuratieprobleem scheidt.

Als de capture niets toont, heeft het pakket de host nooit bereikt en is de tunnelconfiguratie niet de verdachte. Als hij pakketten van het verwachte adres ziet aankomen terwijl de handshake op nul blijft, zijn de sleutels of de toegestane adressen van de peer de volgende plek om te kijken.

Correleer op de server wanneer je die beheert

Bevestig dat de listener bestaat en dat de firewall van de provider de UDP-poort toestaat. Een host-firewallregel en een cloudbeveiligingsgroep zijn twee onafhankelijke poorten, en elk van beide kan een pakket droppen dat de ander toestond. Controleer beide tegen de werkelijke poort in de configuratie in plaats van de poort die je je herinnert.

Het adres is even belangrijk als de poort. Een server die op een specifiek adres luistert, antwoordt niet op een pakket dat op een ander adres aankomt, en een host met meerdere interfaces kan de probe ontvangen op de interface die je niet bedoelde.

Houd elke test binnen systemen die je mag testen. De nuttige vergelijking is die tussen één echte clientpoging en het verwachte serverpad, niet een bredere sweep van adressen die toevallig bij dezelfde provider horen.

Een scanresultaat eerlijk lezen

Een scan is een goedkope manier om te controleren of een host bestaat en of een poort niet duidelijk door een tussenliggend apparaat wordt geblokkeerd. Het is geen bereikbaarheidsbewijs voor een geauthenticeerd protocol, en zeker geen configuratietest.

Het sterkere bewijs is een voltooide handshake van de client die je echt belangrijk vindt, gevolgd door een verzoek dat de tunnel gebruikt en een antwoord krijgt. Die reeks oefent de sleutels, de toegestane adressen, beide firewalls en het retourpad in één keer uit.

Waar de echte poging mislukt, moet de fout nog steeds worden gediagnosticeerd met de tellers van de client en de capture van de server, niet met een nieuwe probe. De protocolbeschrijving legt uit waarom een niet-geauthenticeerd pakket geen antwoord krijgt, en dat is de hele reden waarom het scanresultaat dubbelzinnig is.