UDP-VPN stumm beim Portscan? Warum das passiert

Sie scannen den VPN-Port, erhalten keine Antwort und schließen daraus, dass der Dienst ausgefallen oder die Firewall geschlossen ist. Bei WireGuard und bei OpenVPN-Kontrollkanälen, die ihre eigene Authentifizierung mitbringen, folgt dieser Schluss nicht. Ein Datagramm ohne gültiges Authentifizierungsmaterial wird ohne Antwort verworfen, Stille ist also das, wie ein gesunder Dienst von außen aussieht. Die Sonde ist falsch, bevor es der Tunnel ist.

Stille ist das Protokoll, kein Fehler

UDP hat keinen Verbindungsaufbau, also gibt es kein SYN und keine Bestätigung, die einem Scanner erlauben würde, einen offenen von einem gefilterten Port zu unterscheiden. Eine Sonde kommt als isoliertes Datagramm an, und der Dienst prüft, ob es zu dem Protokoll passt, das er erwartet. Wenn nicht, wird das Paket verworfen, und Verwerfen ist das dokumentierte Verhalten und nicht eine Fehlfunktion.

WireGuard validiert seine Handshake-Nachrichten kryptografisch und ignoriert alles, was fehlschlägt. OpenVPN mit tls-auth oder tls-crypt macht dasselbe für seinen Kontrollkanal. In beiden Fällen erreicht eine beliebige Nutzlast nie eine benutzerseitige Stufe, es gibt also nichts zu antworten und keinen Fehler zurückzugeben.

TCP hätte Ihnen einen Reset von einem geschlossenen Port geliefert. UDP lässt Ihnen Mehrdeutigkeit, die Scanner auflösen, indem sie offen oder gefiltert ausgeben, statt zu raten.

Was ein Scanner schließen kann und was nicht

Ein Scanergebnis ist nur so aussagekräftig wie die Nutzlast, die es gesendet hat. Ordnen Sie die möglichen Beobachtungen danach, was jede einzelne tatsächlich stützt:

Lesen Sie die dritte Zeile als den einzigen positiven Test in der Liste. Er verlangt das echte Profil, den echten Schlüssel und den richtigen Endpunkt, und genau das hat ein generischer Scanner nicht.

Betrachten Sie beide Enden des Pfads

Bei einem Server, den Sie administrieren, mitschneiden Sie an der Schnittstelle, bevor Sie irgendeinen Schluss ziehen, und fragen Sie dann den Dienst, was er gesehen hat. Beide Befehle benötigen root auf dem Gateway:

tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg show

Erscheint an der Schnittstelle kein Paket, hat der Pfad es verworfen, bevor der Dienst etwas gesehen hat, und der nächste Halt sind Routing und Filterung. Kommen Pakete an, aber kein Handshake wird abgeschlossen, ist der Dienst erreichbar, und die Abweichung liegt in Schlüsseln, Endpunktkonfiguration oder Protokollversion. Dieser Vergleich beantwortet die Frage, die der Scanner nicht konnte. Führen Sie ihn aus, während ein echter Client eine Verbindung versucht, nicht während der Scanner sich wiederholt.

Ändern Sie den Test, nicht den Schutz

Die verlockende Abkürzung ist, den Schutz des Kontrollkanals abzuschalten, damit eine Diagnose eine Antwort bekommt. Das tauscht eine echte Sicherheitseigenschaft gegen ein schöneres Scanergebnis und ist die falsche Richtung. Verwenden Sie stattdessen ein gültiges Profil aus einem freigegebenen Netz und notieren Sie Endpunkt und Zeit, damit der Vergleich wiederholbar ist.

Der nützlichste Test ist ein differenzieller: dasselbe Profil auf einem Pfad, der funktioniert, und auf dem Pfad, der es nicht tut. Wenn der funktionierende Pfad einen Handshake erzeugt und der fehlschlagende Pfad an der Schnittstelle nichts erzeugt, haben Sie die Unterbrechung lokalisiert, ohne etwas zu schwächen.

Ein unbeantwortetes UDP-Paket beweist daher weder, dass der Server offline ist, noch dass er sicher ist. Es beweist, dass diese Sonde, auf diesem Pfad, in diesem Moment nicht akzeptiert wurde.