Nmap-Rohscan scheitert über VPN, aber -sT-Verbindung funktioniert?

Eine Seite lädt durch den Tunnel, während ein Portscan den Host als nicht erreichbar meldet, und der erste Verdacht ist, dass die VPN etwas blockiert. Meist blockiert sie nichts Neues. Die beiden Tests verlangen vom Betriebssystem unterschiedliche Fähigkeiten, und nur einer davon braucht Rohzugriff auf Pakete. Klären Sie, welche Fähigkeit versagt hat, bevor Sie den Tunnel anfassen.

Trennen Sie die Fähigkeit vom Tunnel

Eine gewöhnliche Anwendung bittet den Kernel, eine TCP-Verbindung zu öffnen, und der Kernel führt den Handshake ohne besondere Rechte aus. Ein Rohscan baut Pakete selbst, was je nach Plattform einen Raw-Socket oder einen Capture-Treiber erfordert. Das sind Berechtigungs- und Treiberfragen, und sie bestehen unabhängig davon, ob eine VPN verbunden ist.

Diese Unterscheidung erklärt die übliche Asymmetrie. curl gelingt, weil der Socket-Pfad funktioniert, während der SYN-Scan scheitert, weil der Prozess keinen Raw-Socket auf der Tunnel-Schnittstelle öffnen kann. Sie erklärt auch den umgekehrten Fall, in dem ein Rohscan gefiltert meldet, weil der Pfad die Sonde verwirft, während der Anwendungspfad intakt bleibt.

Keines der Ergebnisse beschreibt den entfernten Dienst. Beide beschreiben einen Pfad unter einer Methode, also halten Sie die Methode an die Schlussfolgerung gebunden.

Führen Sie die Verbindungsprüfung auf einem freigegebenen Host aus

Wählen Sie den einen Host, den Ihre Aufgabe abdeckt, und verwenden Sie dann den Modus, der keinen Rohzugriff braucht. Das Beispielziel hier ist 198.51.100.24, Dokumentationsraum, der für solche Illustrationen reserviert ist.

Eine Zeile, ein Host, ein Port, keine Discovery-Phase:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT wählt eine vollständige TCP-Verbindung, durchläuft also denselben Kernelpfad wie eine Anwendung und braucht keinen Capture-Treiber. -Pn überspringt die Host-Erkennung; nmap führt für Ziele im lokalen Segment dennoch eine Auflösung auf Verbindungsschicht durch, das Flag verspricht also keinen ausbleibenden Vorabverkehr. --unprivileged weist nmap an, anzunehmen, dass es keine Roh- oder Sniffing-Rechte hat, was die Methode ändert und nichts gewährt.

Lesen Sie jedes Flag als eine Änderung, nicht als Reparatur

Behandeln Sie jede Option als Aussage über die Methode. Weder -sT noch -Pn oder --unprivileged fügt eine Route hinzu, öffnet eine entfernte Firewall oder prüft ein Zertifikat. Ein Verbindungsscan vollendet außerdem einen echten Handshake, den der Dienst protokolliert, sodass eine freigegebene Prüfung und ein nicht freigegebener Durchlauf vom Server aus gleich aussehen, außer in Umfang und Tempo. Optionen zu stapeln, bis sich die Ausgabe ändert, ist der Weg, auf dem ein Methodenproblem als Netzwerkbefund festgehalten wird.

Wenn die Ausgabe geschlossen sagt, hat etwas mit einem Reset geantwortet, und das ist ein anderer Befund als Stille. Wenn die Ausgabe gefiltert sagt, hat ein Gerät die Sonde oder ihre Antwort verworfen, und die VPN kann nebensächlich sein. Notieren Sie den genauen Wortlaut, denn ein Urteil der Discovery-Phase und ein Fehler auf Sondenebene deuten auf verschiedene Schichten.

Ist ein privilegierter Modus wirklich nötig, entscheidet der Plattformverantwortliche, ob Recht, Treiber und Schnittstellenanordnung unterstützt werden. Dasselbe Kommando zu erhöhen ändert seine Methode nicht.

Bleiben Sie beim Transportergebnis und testen Sie dann den Dienst

Ein abgeschlossener Handshake beantwortet eine Frage zu einer Adresse, einem Port, einer Quelle und einem Zeitpunkt. Er beweist nicht, dass das Backend gesund ist, denn ein Load Balancer oder Forward-Proxy kann die Verbindung annehmen, während die Anwendung dahinter ausgefallen ist.

Folgen Sie mit dem eigenen Client des Dienstes, damit TLS-Identität und Anwendungsverhalten als getrennte Fakten beobachtet werden:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

Eine weitere Gewohnheit hält das Ergebnis brauchbar. Notieren Sie das genaue Kommando, die verwendete Quelladresse und die Zeit, denn ein Transportergebnis ohne diesen Kontext lässt sich weder reproduzieren noch vergleichen.

Nennt das Zertifikat einen Host, den Sie nicht erwartet haben, hat der Transport funktioniert und das Routing war nie das Problem; der Fehler liegt im virtuellen Hosting oder im DNS. Scheitert der Handshake, notieren Sie den lokalen Fehlertext, statt über den Tunnel zu verallgemeinern. Halten Sie den Umfangshinweis neben dem Ergebnis fest, denn die nächste Person muss wissen, welche Methode es erzeugt hat.