Warum ändern sich Portscan-Ergebnisse hinter einem VPN-Ausgang?

Führen Sie dieselbe Portprüfung von einer Büroleitung und von einem VPN-Ausgang aus, und die beiden Antworten können sich über eine Adresse uneinig sein, die niemand geändert hat. Diese Lücke kommt von der Route und davon, welcher Host geantwortet hat, nicht davon, ob der Dienst läuft. Drei Fragen trennen diese Erklärungen: was die Sonde tatsächlich gefragt hat, welcher Host sie beantwortet hat und was Ihr eigener Server aufgezeichnet hat. Arbeiten Sie sie in dieser Reihenfolge durch und schreiben Sie jede Antwort auf, bevor Sie zur nächsten gehen.

Reparieren Sie die Sonde, bevor Sie zwei Läufe vergleichen

Ein Zustandswort ist nur mit einem anderen Zustandswort vergleichbar, wenn beide aus demselben Experiment stammen. Fünf Felder legen es fest: die Quelladresse, die die Gegenseite gesehen hat, das aufgelöste Ziel, der Port, der Scantyp und die Zeit. Ändern Sie eines davon, und Sie haben ein zweites Experiment durchgeführt, statt das erste zweimal zu messen.

Prüfen Sie die Quelle vor allem anderen, denn ein VPN-Client kann laufen, während der Verkehr die physische Schnittstelle noch immer verlässt. Fragen Sie die Gegenseite, was sie sieht, und fragen Sie dann den Kernel, welche Schnittstelle er gewählt hat:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Zwei Adressen in verschiedenen Netzen bedeuten, dass die Erklärung bereits in der Hand liegt, und der Rest dieser Prüfungen wird sie nur bestätigen. Wenn sie übereinstimmen, erfassen Sie die Sonde mit gesetztem Ursachen-Flag, damit der Zustand an eine Erklärung gebunden zurückkommt, statt allein als bloßes Wort dazustehen. Der Scantyp gehört ebenfalls in diesen Datensatz, denn er beschreibt, was gefragt wurde, nicht was zurückkam. Ein Zustand ohne Quelle, ohne Methode und ohne Zeitstempel lässt sich mit nichts vergleichen:

nmap -sT -p 443,8443 --reason 203.0.113.20

Bewahren Sie diese Ausgabe neben dem Datensatz auf und nicht in einem Scrollback-Puffer, den die nächste Person nicht sehen kann. Zwei ehrliche Scans, die sich uneinig sind, sind nur dann ein Streit, wenn niemand die Bedingungen aufgeschrieben hat. Sind die Bedingungen festgelegt, stimmen die Ergebnisse entweder überein und die Frage ist geschlossen, oder sie unterscheiden sich, und der Unterschied ist eine Tatsache über den Pfad.

Finden Sie heraus, welcher Host den Handshake abgeschlossen hat

Ein abgeschlossener Handshake beweist, dass irgendein Host ihn abgeschlossen hat, und dieser Host muss nicht der Prozess sein, den Sie im Sinn haben. Ein Load Balancer, ein Reverse Proxy oder ein SYN-Proxy können antworten, bevor der echte Server beteiligt ist, was gewöhnliches Design und kein Symptom ist. Ein gültiges Zertifikat für den erwarteten Namen grenzt das auch nicht ein, denn ein Zertifikat beschreibt eine Dienstbeziehung und sagt nichts darüber, welche Maschine die Verbindung beendet hat.

Die Nmap-Referenz zu Portzuständen behandelt das als grundlegend: Ein Zustand hält fest, was eine Sonde von ihrem Absendeort aus beobachten konnte, nicht eine Eigenschaft des Ports. Liest man ein Zustandswort so, wirken zwei Läufe, die sich widersprachen, plötzlich stimmig statt widersprüchlich, während die Frage von „ist der Port offen“ zu „wer stand davor“ wandert.

Beantworten Sie die zweite Frage im Backend statt von außen. Ein Frontend, das Verbindungen annimmt und dann seinen Upstream nicht erreicht, erzeugt genau das äußere Bild eines gesunden Dienstes mit einer langsamen Anwendung. Nur der eigene Datensatz des Upstreams trennt die beiden Fälle:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

Die Logzeile zeigt die Clientadresse, die die Anwendung wirklich gesehen hat, und der zweite Befehl zeigt, ob der Prozess, der Port 443 hält, Ihre Anwendung ist oder etwas davor. Wenn die beiden sich darüber uneinig sind, welche Adresse verbunden hat, betrachten Sie zwei Beine einer Anfrage, und das Ticket sollte das sagen.

Prüfen Sie Ihre eigenen Regeln, bevor Sie den Tunnel beschuldigen

Absichtliche Politik ist der häufigste Grund, warum ein Port in einem Netz antwortet und in einem anderen nicht, und sie ist die uninteressanteste verfügbare Erklärung. Zugriffsregeln existieren, um eine Quelle zuzulassen und den Rest zu verwerfen, also ist ein Wechsel des Ausgangs genau das Ereignis, für das sie geschrieben wurden. Ein anderer Zustand durch ein VPN zeigt daher nicht, dass der Anbieter den Verkehr inspiziert. Er zeigt, dass Ihre Quelladresse jetzt eine andere ist, was eine viel kleinere Behauptung ist.

Diese Regeln sind auf dem Server lesbar, also lesen Sie sie, statt über die Netzmitte zu spekulieren. Listen Sie die Filterregeln auf, die einen der beiden Adressbereiche erwähnen, und prüfen Sie dann, ob die Verbindung überhaupt den Daemon erreicht hat:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

Ein leeres zweites Ergebnis ist informativ, denn nichts hat den Daemon erreicht, und die Frage gehört zu einem Filter, einer Sicherheitsgruppe oder dem Pfad selbst. Ein Treffer bedeutet, dass der Dienst Ihre Quelle gesehen und seine Antwort gewählt hat, und diese Entscheidung steht normalerweise in einer Regel, die Sie lesen können. Keines der Ergebnisse stützt eine Geschichte über den Anbieter, und beide sind billiger zu prüfen als ein Paketmitschnitt.

Lesen Sie Transport, Zertifikat und Antwort getrennt

Drei Schichten erzeugen drei Beobachtungen, und eine Sonde, die eine davon testet, kann über die anderen beiden nicht berichten. Halten Sie sie als getrennte Zeilen im Datensatz fest, statt sie zu einem einzigen Urteil zu falten, denn jede Zeile scheitert auf ihre eigene Weise, und der Fehlermodus sagt Ihnen, wo Sie als Nächstes suchen müssen.

Ein Befehl erzeugt die ersten drei Zeilen gegen einen Dienst, den Sie kontrollieren. Legen Sie seine Ausgabe in den Datensatz neben dem Scan und nicht in eine Chatnachricht:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Lesen Sie die Ausgabe der Reihe nach: Der Handshake beantwortet die Transportfrage, der Zertifikatsbetreff die Namensfrage und der Antwortkörper die Anwendungsfrage. Wenn die Handshake-Zeile gelingt und die Antwortzeile nicht, haben Sie ein Frontend mit einem defekten Upstream und keinen blockierten Port. Das ist ein anderes Ticket als das, das Sie geöffnet haben, und es lohnt sich, das klar zu sagen.

Schließen Sie ab, indem Sie vier Tatsachen ins Ticket schreiben: Quelladresse, Scantyp, den Host, der geantwortet hat, und die Zeit. Alles, was ein späterer Vergleich braucht, lebt in diesen vier, und wer den Fall als Nächstes aufnimmt, hat nicht Ihre Terminalhistorie. Wenn Sie nicht alle vier ausfüllen können, ist der Lauf nicht fertig.