SSTP-Schichten erklärt: Was das innere Paket noch verrät

Zwei Tatsachen über SSTP werden in den meisten Erklärungen zu einer verschmolzen, und genau diese Verschmelzung macht Mitschnitte verwirrend. Das Anwendungspaket überlebt innerhalb des geschützten Kanals, und die TCP-Verbindung, die diesen Kanal trägt, behält durchweg ihre eigenen Adressen. Über die Leitung geht ein Träger samt seiner Fracht, niemals ein Ersatz für eines von beiden. Gehen Sie den Stapel von außen nach innen durch und beschriften Sie jede Grenze, die Sie überqueren.

Beginnen Sie beim äußeren Träger

Das Erste auf der Leitung ist eine gewöhnliche TCP-Verbindung zu Port 443 mit echten Adressen, die Router weiterleiten. Diese Verbindung ist es, die die Netzwerkadressübersetzung übersteht und die ein Zugangsanbieter zählen kann. Der Schutz der Nutzdaten entfernt den Träger nicht, und er verbirgt weder Volumen noch Zeitverhalten.

Alles nach diesem Punkt wird getragen statt geroutet. Der Träger arbeitet weiter, auch wenn der innere Austausch scheitert.

Folgen Sie der Kapselung nach innen

Innerhalb des geschützten Kanals liegt ein SSTP-Steueraustausch, dann eine PPP-Sitzung, dann das Netzwerkpaket, das der Client zugestellt haben will. Jede Schicht hat ihre eigene Aushandlung, ihre eigenen Fehlermeldungen und ihre eigene Zustandsmaschine. Ein Fehler kann daher aus einem Blickwinkel wie ein TLS-Fehler und aus einem anderen wie ein PPP-Fehler aussehen. Liest man die Schichten der Reihe nach, zeigt sich, welche Zustandsmaschine stehen blieb.

Ein einzelner Mitschnitt zeigt selten den ganzen Stapel. Äußere Header sind nur außerhalb des Endpunkts sichtbar und innere erst nach der Entkapselung. Diese Asymmetrie kommt von Ihrem Standort, nicht vom Protokoll.

Das folgende Diagramm gruppiert die Schichten, damit man überhaupt über sie sprechen kann. Es ist kein Byte-Layout, es verspricht keinen Datensatz pro Paket und es sagt nichts darüber, wie viele kryptografische Operationen eine Implementierung ausführt.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Beschriften Sie den Beobachter, bevor Sie einen Mitschnitt lesen

Zwei Mitschnitte einer Sitzung beantworten verschiedene Fragen, und die Schnittstelle, auf der sie entstanden, entscheidet welche. Auf dem Zugangspfad sehen Sie den Träger und die TLS-Datensätze, und Sie können Größen und Abstände messen, ohne eine innere Adresse zu sehen. Am Endpunkt ist das innere Paket nach der Entkapselung gewöhnlicher Verkehr unter der privaten Weiterleitungsrichtlinie.

Notieren Sie Schnittstelle und Richtung auf jedem Mitschnitt, bevor Sie ihn auswerten. Eine Spur von einem physischen Adapter wird die Adressen der inneren Anwendung nie als gewöhnliche äußere Felder zeigen, und dieses Fehlen als Verschlüsselungsfehler zu lesen ist ein häufiger Fehler. Eine Spur aus dem Inneren des Tunnels zeigt überhaupt keinen Träger, kann also keine Frage zur Sicht des Anbieters beantworten. Dieselbe Disziplin gilt für Endpunkt-Protokolle, die die Reihenfolge der Aushandlung festhalten und nicht die Inhalte.

Behalten Sie die Prüfungen, die das Diagramm nicht beweisen kann

Die Schichtreihenfolge belegt nicht, dass ein Einsatz das Serverzertifikat prüft, eine unterstützte TLS-Version aushandelt oder das Konto autorisiert. Jedes davon ist eine Konfigurationsentscheidung, die unabhängig von der Kapselung scheitert.

Prüfen Sie sie mit einem Client, der berichtet, was er ausgehandelt hat, statt aus einer Zeichnung zu schließen. Beginnen Sie mit dem TLS-Handshake, dann dem SSTP-Austausch, dann PPP, und halten Sie bei der ersten Stufe an, die einen Fehler meldet. Der erste Befehl gibt Kette und ausgehandelte Version aus, der zweite listet die in einem Mitschnitt vorhandenen Handshakes auf.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"