SSTP vs. OpenVPN: derselbe Port 443, anderes Protokoll

Beide Optionen können hinter TCP 443 liegen, deshalb halten viele sie für austauschbare Endpunkte. Das sind sie nicht: ein SSTP-Server spricht PPP innerhalb von HTTPS, während ein OpenVPN-Server sein eigenes Protokoll über TLS oder einen rohen UDP-Strom spricht. Richtet man einen Client auf den Port des anderen, entsteht eine Verbindung, die nie zu einer Anmeldeaufforderung gelangt. Die Entscheidung dreht sich darum, welchen Client und welchen Transport du unterstützen kannst, nicht um die Nummer.

Ein gemeinsamer Port ergibt kein gemeinsames Protokoll

Der TLS-Handshake kann abgeschlossen werden und trotzdem nirgendwohin führen, weil sich Client und Server danach uneinig sind, was als Nächstes zu sagen ist. In einem Paketmitschnitt sieht man einen sauberen Handshake, gefolgt von Anwendungsdaten, die die Gegenseite zurückweist oder ignoriert. Dieses Muster ist die Signatur einer Protokollunverträglichkeit und nicht einer Firewall-Sperre.

Weder ein umbenanntes Profil noch ein anderer Menüeintrag macht das eine aus dem anderen. Eine SSTP-Verbindung wird in den Windows-VPN-Einstellungen mit einer Serveradresse und den Anmeldedaten des Betreibers erstellt, während eine OpenVPN-Verbindung den Client und die passende Konfigurationsdatei braucht. Microsofts SSTP-Spezifikation beschreibt Ersteres und beschreibt keinen OpenVPN-Handshake.

Port 443 ist eine Richtlinien-Bequemlichkeit. Er passiert Netzwerke, die wenig anderes erlauben, und das ist ein echter Vorteil, aber er sagt nichts darüber, welches Protokoll dahinter läuft.

SSTP tunnelt PPP innerhalb von HTTPS

Der Name beschreibt den Aufbau: PPP-Rahmen, die in einer HTTPS-Sitzung transportiert werden, also TLS darunter und ein Zertifikat, das der Client prüfen kann. Windows enthält das als nativen VPN-Typ, sodass ein verwalteter Laptop oft ohne zusätzliche Software außer dem vom Betreiber gelieferten Profil verbinden kann.

Andere Plattformen sind eine andere Geschichte. Ein Linux- oder macOS-Client braucht eine gepflegte Implementierung, und diese unterscheiden sich darin, was sie unterstützen und wie sie Fehler melden. Prüfe den Client, den du tatsächlich nutzen willst, statt anzunehmen, dass die in Windows eingebaute Fähigkeit übertragbar ist, und bestätige, dass der Servername im Profil zu dem Zertifikat passt, das der Server vorlegt.

SSTP ist normalerweise nur TCP. Dieser eine Transport beeinflusst, wie es sich auf einer verlustreichen Strecke verhält, weil die Wiederholung sowohl im Tunnel als auch darunter stattfindet.

OpenVPN bringt einen eigenen Client und eine Transportwahl mit

OpenVPN liefert einen eigenen Client und ein Profil, was dir Diagnosen gibt, die ein nativer Windows-Dialog nicht offenlegt. Der Server kann auf UDP oder TCP lauschen, und die Konfiguration des Betreibers entscheidet, welche Variante dein Client nutzen muss. Ein Profil, das auf den falschen Transport zeigt, scheitert vor der Authentifizierung.

Die Authentifizierung hängt genauso von der Konfiguration ab. Ein Deployment kann nur Zertifikate verlangen, Zertifikate plus Benutzername und Passwort oder einen zweiten Faktor obendrauf, und der Client muss genau zu dieser Anordnung passen. Dass eine Verbindung die TLS-Phase erreicht, sagt nicht, welche Anmeldedaten sie als Nächstes abfragt.

UDP ist der übliche Standard, weil es vermeidet, einen zuverlässigen Strom in einen anderen zuverlässigen Strom zu schachteln. Der TCP-Modus existiert für Netzwerke, die UDP blockieren, und er funktioniert, aber starker Verlust kann ihn schlechter wirken lassen als den UDP-Pfad, den er ersetzt hat. Wähle TCP, wenn du musst, nicht weil es zuverlässiger klingt.

Wähle nach Client, Transport und Support

Drei Fragen klären die meisten dieser Entscheidungen. Braucht jedes Client-Gerät eine Verbindung, die ohne zusätzliche Software funktioniert? Erlaubt das Netzwerk, auf das du angewiesen bist, UDP, oder ist TCP 443 der einzige Ausgang? Und wer unterstützt den Client, seine Updates und seine Wiederherstellung, wenn ein Profil abläuft?

Wenn du beide vergleichst, teste auf demselben Gerät und im selben Zugangsnetz. Wenn der SSTP-Endpunkt und der OpenVPN-Endpunkt verschiedene Server oder verschiedene Standorte sind, enthält dein Ergebnis diese Routen und Maschinen, statt das Protokoll zu isolieren. Das ist der häufigste Weg, auf dem solche Vergleiche eine selbstsichere, aber falsche Antwort liefern.

Bestätige dann, welche du tatsächlich aufgebaut hast, bevor du irgendetwas anderes untersuchst:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

Wie auch immer, schließe damit ab, die Ressource und das DNS zu testen, die du brauchst, statt Erfolg beim Tunnelzustand zu erklären. Beide Protokolle lassen sich so konfigurieren, dass sie nur ausgewählten privaten Verkehr tragen, und ein verbundener Tunnel ohne funktionierende Namensauflösung sieht wie ein kaputtes VPN aus, wenn es in Wahrheit ein Split-Tunnel- oder DNS-Design ist.

In einem verwalteten Bestand entscheiden Profilverteilung und Update-Support die Frage meist lange bevor irgendein Transport-Benchmark es tut.