UDP-Scan meldet gefiltert: Ist dein WireGuard-Peer wirklich ausgefallen?

Scanner geben für einen UDP-Port offen oder gefiltert aus, und die Schlussfolgerung folgt meist innerhalb von Sekunden: Der Tunnel ist kaputt. Das mag sein, aber der Scan hat es nicht belegt. UDP kennt keinen Verbindungs-Handshake, und WireGuard antwortet auf nichts, was es nicht authentifizieren kann, also ist Schweigen die erwartete Antwort auf die meisten Probes.

Arbeite stattdessen vom Client nach außen und behandle den Scan als einen schwachen Datenpunkt unter mehreren.

Was der Scanner sehen kann und was nicht

Ein UDP-Scanner schickt eine Nutzlast und wartet. Kommt ein ICMP port-unreachable zurück, kann er den Port als geschlossen melden. Kommt nichts zurück, ist das Ergebnis konstruktionsbedingt mehrdeutig: ein gefilterter Pfad, ein fehlender Host und ein laufender Dienst, der die Nutzlast ignoriert hat, erzeugen alle dasselbe Schweigen. Drei verschiedene Zustände, eine Ausgabezeichenkette.

WireGuard verschärft diese Mehrdeutigkeit absichtlich. Das Protokoll nimmt ein Paket nur an, wenn es sich authentifiziert, also wird eine Probe mit den falschen Schlüsseln ohne Antwort verworfen. Es gibt kein Banner, keine Versionszeichenkette und keine Fehlermeldung zum Fingerprinting.

Ein TCP-Test auf derselben Portnummer prüft nichts Zusammenhängendes. Er beansprucht einen anderen Listener, der vielleicht gar nicht existiert, und seine Ablehnung sagt nichts über UDP aus.

Offene gefilterte Zustände beschreiben also die Unsicherheit des Scanners genauer als deinen Server.

Geh den echten Client vom Profil nach innen durch

Beginne mit der Sicht des Clients selbst. Hat die Schnittstelle eine Adresse, nennt die Konfiguration den richtigen Endpunkt und bewegt sich der Handshake-Zähler, wenn ein Verbindungsversuch läuft? Ein Client, der nie ein Paket gesendet hat, und ein Client, dessen Pakete verworfen wurden, sehen in einem Statusfenster identisch aus. Nur die Zähler unterscheiden sie, also lies zuerst die Zähler.

Beobachte dann die Serverseite während eines autorisierten Versuchs, statt einen separaten Scan von einem dritten Ort aus zu starten:

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

Der erste Befehl meldet den letzten Handshake pro Peer, was ein direkter Beleg dafür ist, dass ein authentifizierter Austausch abgeschlossen wurde. Der zweite zeigt, ob Pakete für den Listener überhaupt ankommen, was ein Pfadproblem in einem Schritt von einem Konfigurationsproblem trennt.

Zeigt die Aufzeichnung nichts, hat das Paket den Host nie erreicht und die Tunnelkonfiguration ist nicht verdächtig. Zeigt sie ankommende Pakete von der erwarteten Adresse, während der Handshake bei null bleibt, sind die Schlüssel oder die erlaubten Adressen des Peers die nächste Stelle zum Nachsehen.

Korreliere auf dem Server, wenn du ihn administrierst

Bestätige, dass der Listener existiert und dass die Firewall des Anbieters den UDP-Port zulässt. Eine Host-Firewall-Regel und eine Cloud-Sicherheitsgruppe sind zwei unabhängige Tore, und jedes von beiden kann ein Paket verwerfen, das das andere erlaubt hat. Prüfe beide gegen den tatsächlichen Port in der Konfiguration statt gegen den Port, den du in Erinnerung hast.

Die Adresse zählt genauso viel wie der Port. Ein Server, der auf einer bestimmten Adresse lauscht, antwortet nicht auf ein Paket, das auf einer anderen ankommt, und ein Host mit mehreren Schnittstellen kann die Probe auf der Schnittstelle empfangen, die du nicht gemeint hast.

Halte jeden Test innerhalb von Systemen, für die du autorisiert bist. Der nützliche Vergleich ist der zwischen einem echten Client-Versuch und dem erwarteten Serverpfad, nicht ein breiterer Durchlauf über Adressen, die zufällig demselben Anbieter gehören.

Ein Scan-Ergebnis ehrlich lesen

Ein Scan ist eine billige Möglichkeit zu prüfen, ob ein Host existiert und ob ein Port nicht offensichtlich von einem Zwischengerät blockiert wird. Er ist kein Erreichbarkeitsbeweis für ein authentifiziertes Protokoll und ganz sicher kein Konfigurationstest.

Der stärkere Beleg ist ein abgeschlossener Handshake von dem Client, der dir wirklich wichtig ist, gefolgt von einer Anfrage, die den Tunnel nutzt und eine Antwort erhält. Diese Abfolge prüft die Schlüssel, die erlaubten Adressen, beide Firewalls und den Rückweg in einem Zug.

Wo der echte Versuch scheitert, muss der Fehler trotzdem mit den Zählern des Clients und der Aufzeichnung des Servers diagnostiziert werden, nicht mit einer weiteren Probe. Die Protokollbeschreibung erklärt, warum ein nicht authentifiziertes Paket keine Antwort erhält, und genau das ist der Grund, warum das Scan-Ergebnis mehrdeutig ist.