Warum SSL-VPN und Site-to-Site-VPN keine Gegensätze sind

Bitten Sie zwei Administratoren, dasselbe VPN zu beschreiben, und der eine antwortet vielleicht „SSL-VPN“, während der andere „Site-to-Site“ sagt, als wären die beiden konkurrierende Optionen in einem Menü. Sie sind Antworten auf verschiedene Fragen, und sie als Alternativen zu behandeln erzeugt Vergleiche, die sich nicht auflösen lassen. Das eine Etikett sagt, welche Endpunkte verbunden werden; das andere sagt, was den Verkehr zwischen ihnen trägt. Halten Sie die Achsen getrennt, und der größte Teil der Debatte verschwindet.

Zwei Etiketten, zwei getrennte Fragen

Die Topologie beantwortet, wer sich womit verbindet. Ein Fernzugriffsdesign bindet einzelne Benutzer oder Geräte an ein Gateway an, meist mit Identität pro Benutzer und einem Adresspool. Ein Site-to-Site-Design verbindet zwei Netzwerke über Gateways, sodass die interessante Identität das Peer-Gateway ist und nicht die Person an der Tastatur. Das sind unterschiedliche Betriebsprobleme, von der Adressplanung bis zu der Frage, wer um 2 Uhr nachts den Zugang entziehen kann.

Der Mechanismus beantwortet, wie der Tunnel aufgebaut und authentifiziert wird. IPsec mit IKEv2, ein TLS-basiertes Produkt, das IP in sich trägt, und ein browserorientiertes Anwendungsportal sind Mechanismusentscheidungen, und jede hat ihre eigene Aushandlung, ihre Cipher-Suiten und ihre Fehlermodi. Keine davon impliziert eine Topologie, und eine Topologie wählt keinen Mechanismus.

Setzen Sie die beiden Achsen in eine Tabelle, und die Verwirrung wird sichtbar, weil jede Zelle des Rasters gefüllt werden kann. Was das Raster nicht kann, ist Ihnen zu sagen, welche Kombination Ihr Anbieter geliefert hat, da Produktnamen beide Achsen zu einer Marketingphrase zusammenziehen.

Woher der Kategorienfehler kommt

Anbieter verkauften „SSL-VPN“ jahrelang als Gegenteil von „IPsec-VPN“, was einen Mechanismusvergleich wie eine Topologiewahl aussehen ließ. Der Ausdruck ist auch nach seinen eigenen Maßstäben schlecht gealtert, denn heutige Designs nutzen unterstützte TLS-Versionen, und der Name SSL überlebt vor allem als Produktkategorie.

Aus derselben Zusammenziehung folgen zwei verwandte Mythen. Der erste ist, dass IPsec Site-to-Site bedeutet; IKEv2 wurde auch für Client-zu-Gateway-Beziehungen entworfen, sodass sich ein einzelner Laptop mit IPsec verbinden kann. Der zweite ist, dass ein TLS-basiertes Produkt nur Fernzugriff bedeutet; OpenVPN wird routinemäßig eingesetzt, um Verkehr zwischen zwei Standorten zu übertragen, und seine TLS-Nutzung konzentriert sich auf den Steuerungs- und Authentifizierungsaustausch statt auf eine Browsersitzung.

Ein nützlicher Test für jede Beschreibung: Wenn das Ersetzen eines Wortes sowohl die Endpunkte als auch das Protokoll ändert, vermischt der Satz die Achsen. „SSL-VPN versus Site-to-Site“ besteht diesen Test nicht, weil der erste Begriff eine Mechanismusfamilie und der zweite eine Topologie benennt.

Beschreiben Sie ein Deployment so, dass es vergleichbar ist

Schreiben Sie vier Felder und füllen Sie sie aus: Endpunkte, Mechanismus, Authentifizierung und Zugriffsoberfläche. Eine Filialverbindung könnte als IKEv2-Gateway-Paar zwischen zwei benannten Präfixen mit Zertifikatsauthentifizierung und ohne Portal auf Benutzerebene gelesen werden. Ein Fernzugriffsdienst könnte als TLS-basierter Client gelesen werden, der Adressen pro Benutzer zuweist, beim Login einen zweiten Faktor verlangt und nur eine interne DNS-Zone veröffentlicht.

Diese Sätze sind vergleichbar, wie Produktnamen es nicht sind. Zwei Fernzugriffsdesigns lassen sich an derselben Benutzerarbeitsweise und demselben Widerrufspfad messen, und zwei Standort-zu-Standort-Designs an derselben Präfixliste, Verkehrspolitik und Fehleranforderungen. Die Etiketten organisieren den Vergleich; sie ersetzen ihn nicht.

Die Terminologie hat auch einen veröffentlichten Anker. Das IETF-Dokument zur VPN-Terminologie trennt mehrere Dienstmodelle, darunter Fernzugriff und Site-to-Site, von den Mechanismen, mit denen sie aufgebaut werden, und genau diese Unterscheidung geht immer wieder verloren.

Lesen Sie das ausgehandelte Protokoll, nicht den Produktnamen

Das Etikett auf der Schachtel legt nicht fest, worauf sich ein laufender Tunnel geeinigt hat. Fragen Sie den Peer direkt auf der TLS-Seite und lesen Sie die Protokollversion und die Cipher, die der Handshake erzeugt hat, statt der Version im Prospekt.

openssl s_client -connect vpn.example.net:443 -tls1_3 -brief

Für ein IPsec-Gateway kommt die entsprechende Beobachtung aus der eigenen Statusausgabe der Implementierung, die die verwendeten IKE- und ESP-Vorschläge meldet. So oder so ist der Punkt derselbe: Die Mechanismusachse muss aus der laufenden Sitzung gelesen werden, weil Client und Gateway sich auf etwas Älteres einigen können, als jeder der beiden Administratoren erwartet hat.

ipsec statusall | grep -E "IKE|ESP"

Danach bleiben die Fragen, die kein Etikett beantwortet. Welche Protokollversionen noch akzeptiert werden, wie die Identität des Gateways validiert wird, welcher Algorithmus-Satz erlaubt ist, wer einen bestimmten Benutzer für eine bestimmte Ressource autorisiert und was den Zugang widerruft, wenn ein Gerät verloren geht. Ein Topologiediagramm und ein Mechanismenname sind der Anfang dieser Liste, kein Ersatz für sie.

Behalten Sie also die beiden Etiketten, aber nutzen Sie sie für das, was sie sind: eine kurze Art zu sagen, welche Endpunkte verbunden werden und wie der Tunnel aufgebaut wird. In dem Moment, in dem eines benutzt wird, um das andere auszuschließen, hat die Beschreibung aufgehört, irgendetwas zu beschreiben.