Ein Portscan verrät nicht, wer die Anmeldung annimmt

Drei Fragen geraten durcheinander, wenn jemand einen Portscan vor ein VPN-Problem hält: Ist irgendetwas erreichbar, ist es der Dienst, den Sie meinen, und wird er Ihre Identität annehmen. Ein Scanner beantwortet die erste und deutet vage auf die zweite. Die dritte kann er überhaupt nicht beantworten, denn das Annehmen eines Anmeldedatensatzes ist nicht das, was eine Transportsonde tut. Entscheiden Sie, welche Frage Sie stellen, bevor Sie die Ausgabe lesen.

Das Werkzeug irrt nicht; es beantwortet eine engere Frage als die auf dem Tisch.

Ein offener Socket ist ein Fakt über einen Socket

Eine erfolgreiche TCP-Verbindung bedeutet, dass etwas diesen Endpunkt angenommen hat. Sie belegt nicht, dass der Listener der beabsichtigte VPN-Dienst ist, dass das vorgelegte Zertifikat zu dem erwarteten Namen passt oder dass die TLS-Prüfung bestehen würde. Eine Gateway-Verwaltungsseite auf demselben Hostnamen ist ein völlig anderer Dienst und zeigt nichts über den Tunnel. Behandeln Sie das Ergebnis als Erreichbarkeitsfakt und nicht mehr.

Wo die Sonde tatsächlich hilft, ist beim Ausschließen. Wenn nichts die Verbindung von Ihrem Standort annimmt, kann der Handshake nicht gelingen, und das verengt die Suche vor allem anderen auf Erreichbarkeit.

UDP-Stille hat mehrere Erklärungen

UDP-Protokolle dürfen Pakete, die nicht authentifiziert sind, legitimerweise ignorieren, daher ist eine ausbleibende Antwort kein Urteil. Sie kann Filterung auf dem Pfad bedeuten, einen geschlossenen Endpunkt oder einen Dienst, der bewusst still bleibt, bis er etwas Gültiges empfängt. Stille als geschlossenen Port zu lesen, schickt Leute zu Firewall-Regeln, während der eigentliche Fehler im Profil liegt. Wiederholen Sie die Sonde aus einem anderen Netz, bevor Sie irgendeinen Schluss ziehen.

Die Mehrdeutigkeit ist eine Eigenschaft des Protokolls und keine Lücke im Werkzeug. Sagen Sie es klar, wenn Sie das Ergebnis berichten, denn eine selbstsichere falsche Antwort ist schlimmer als eine unsichere richtige.

Die Vertrauensentscheidung bleibt Ihre

Ein offener Port trifft die Vertrauensentscheidung nicht, daher ist ein Scannerergebnis kein Grund, Zertifikatsprüfungen abzuschalten. Diese Prüfung existiert, um zu beantworten, ob Sie den beabsichtigten Peer erreicht haben, und ein Scanner hat das nicht beantwortet. Verwenden Sie das echte Profil und den echten Client des Betreibers für Identität und Authentifizierung und lassen Sie danach die Prüfeinstellungen genau so, wie sie waren.

Wenn der Scan offen sagt und der Handshake scheitert, liegt der interessante Teil des Fehlers im Handshake, nicht im Scan.

Prüfen Sie den Austausch, dann die Route

Sobald die Authentifizierung gelingt, prüfen Sie die nächsten Stufen getrennt: Datenzuordnung, installierte Routen und Anwendungszugriff. Jede kann scheitern, während die vorige gesund aussah, und jede hat ihre eigenen Belege. Client- und Listener-Protokolle mit engen Mitschnitten oder Zählern zu korrelieren ergibt eine Pfaddiagnose, die wiederholtes Scannen nie liefert. Halten Sie Profil und Endpunkt beim Vergleich von Netzen fest und notieren Sie, wo die Aushandlung stoppt.

Halten Sie auch den Diagnoseumfang autorisiert. Systeme zu sondieren, die Ihnen nicht gehören, ist keine Fehlersuche, was das Werkzeug auch über das Ergebnis sagt.

Der Scan beantwortet Erreichbarkeit. Authentifizierung braucht ein Anmeldedatum, und die Route braucht ein Paket. Ein Scanner kann einen offenen Port melden, während der Dienst jede Anmeldung ablehnt, und er kann einen geschlossenen Port melden, während eine gültige Sitzung aus einem anderen Netz funktioniert. Behandeln Sie das Ergebnis als eine Beobachtung über einen Pfad und prüfen Sie dann das Anmeldedatum und den Rückweg getrennt.