Wenn zwei sich streiten, freut sich der dritte. Wenn Fachleute über VPNs reden, geht es häufig darum, ob IPSec oder SSL die bessere Variante darstellt. Doch beim Anwender sind oft andere Fragen entscheidend - vor allem die nach Produktivität, einfacher Handhabung und Sicherheit. Jede Organisation legt dabei Wert auf ihre eigene Gewichtung.
Was die Produktivität anbelangt, so geht es heute darum, was ein VPN zu einer optimalen Nutzung
der Leitungsstruktur beisteuern kann und zur Verbesserung der Ausfallsicherheit. Ein wesentlicher
Aspekt ist dabei die Intelligenz des VPN-Systems: Ist es immun gegen Unterbrechungen? Kann es
multiple Wege – zum Beispiel MPLS (Multiprotocol Label Switching) und Internet-VPN – gemeinsam
nutzen? Sicherheitsanforderungen und Produktivitätserfordernisse lassen sich elegant kombinieren,
wenn ein VPN zwischen zwei Standorten mehr als einen physikalischen Weg nutzt. Die Kombination von
MPLS und Internetprovider ist hier häufig anzutreffen. Aber auch beliebige Zusammenstellungen von
DSL, UMTS und ISDN mit Leased Line oder MPLS helfen, die Bandbreitenanforderungen kostenoptimal
abzudecken.
Jeder VPN-Tunnel kann also mehrere physikalische Transportwege nutzen. Für jeden Transport
entscheidet der Administrator frei über die zu verwendende Kapselung für das ESP-Protokoll
(Encapsulated Security Payload), die verwendete Block-Chiffre und ob er Datenkompression aktiviert
oder deaktiviert. So lassen sich unterschiedliche Sicherheitsstufen je nach verwendetem
Transportweg umsetzen. In Verbindung mit einer Verkehrsklassifikation durch die Firewall kann der
Verkehr selektiv auf die einzelnen Transporte aufgeteilt werden. Zudem gibt es die Möglichkeit,
zusätzliche Transporte bei Bedarf zu aktivieren, zum Beispiel einen UMTS- oder ISDN-Uplink. Er wird
nur bei einem Ausfall der anderen Transportwege benötigt.
Kann das VPN Störungen schnell erkennen und eine Verbindung unmittelbar wieder herstellen?
Lösungen für dieses Problem sind etwa die Erkennung von Störungen durch aktives Probing sowie der
Austausch von Statusinformationen zwischen den VPN-Endstellen und anschließend die automatische
Wiederherstellung der Verbindung. Eine weitere Möglichkeit ist das Umschwenken des Verkehrs auf
eine alternative Route. Dabei findet unter Umständen eine Repriorisierung des weitergeleiteten
Applikationsverkehrs statt, wenn sich die verfügbare Bandbreite und die Leitungsauslastung
ändern.
Die früher wichtige Frage nach der maximalen Anzahl unterstützter Tunnel wird dagegen beinahe
obsolet. Viel relevanter ist: Wie viele Gegenstellen können angeschlossen werden? Ein Vorteil
neuester IPSec-VPNs nämlich ist, dass zwischen zwei Standorten nur ein Tunnel aufgebaut werden
muss, unabhängig davon, wie viele Netze verbunden werden. Dies spart Ressourcen, verbessert die
Übersichtlichkeit und verringert die Anzahl von möglichen Fehlerquellen.
Viele auf dem Markt verfügbare VPN-Implementierungen glänzen nicht unbedingt durch einfache
Administrierbarkeit und gute Diagnostik. Zahlreiche Unternehmen mussten daher schon die Erfahrung
machen, dass Konfigurations- und Betriebskosten nicht proportional steigen, sondern exponentiell
zur Anzahl der Gateways.
Ein wichtiges Hilfsmittel für die IT-Abteilung sind einfach nutzbare, aussagekräftige grafische
Tools. Dies betrifft nicht nur die Überwachung und Auswertung. Zeitgemäße Managementzentren leisten
mehr: Ein schönes Beispiel ist die Möglichkeit, den Aufbau eines VPN-Tunnel-Verbunds einfach mit
Hilfe von Drag and Drop mit der Maus zwischen den visualisierten VPN-Endpunkten in beliebigen
Topologien ermöglichen (Bild 1). Auch multiple Transporte können hier durch mehrfaches Ziehen
zwischen Standorten einfach angelegt werden. Organisationen verwalten damit selbst global verteilte
Infrastrukturen mit einem minimalem Personalaufwand.
Auch im Bereich Security gibt es große Unterschiede zwischen verschiedenen VPNs. Organisationen
mit besonders hohen Sicherheitsanforderungen – wie beispielsweise Behörden – fordern für ihre VPNs
den Einsatz selbst gewählter Verschlüsselungsverfahren. Damit stellen sie sicher, dass niemand –
nicht einmal die VPN-Herstellerfirmen – die Sicherheit kompromittieren oder auf Daten zugreifen
kann. Entsprechend fortschrittliche VPN-Systeme bieten IPSec-Standard-Interoperabilität mit den
Produkten anderer Hersteller. Phion gehört zu den Unternehmen, die zusätzlich noch eine proprietäre
Variante anbieten. Diese nutzt das ESP-Protokoll, aber einen modifizierten Key-Exchange, der im
Vergleich zu Internet-Key-Exchange (IKE) durch einen Pre-Handshake bei zertifikatsbasierter
Authentisierung weniger anfällig für Denial-of-Service-Attacken (DoS) ist.
Zudem erlauben diese Systeme die Hinzugabe eines ESP-Counter-Copy-Datenblocks hinter die
Payload, einen so genannten NOHASH-Modus. Dies führt zu Performance-Steigerungen auf
x86-Architekturen, ohne dabei die Sicherheit zu kompromittieren. Das Verfahren ist vergleichbar mit
dem AES-GCM Verfahren, das auch darauf abzielt, rechenintensives Hashing zu vermeiden.
VPN-Varianten dieser Art bieten zusätzliche Features an, die innerhalb von nativem IPSec nicht
nutzbar sind. Dazu gehört die Unterstützung von proprietären Blockchiffren. Diese werden gemäß
API-Vorlage in reinem C programmiert und können in weiterer Folge als binärer Blob in der
VPN-Konfiguration integriert werden. Dadurch ist gewährleistet, dass der Hersteller für den
Anwender keine spezifischen Softwareanpassungen vornehmen muss und der Hersteller die Chiffre nicht
zu kennen braucht. Zudem steht ein zusätzliches Kommunikationsprotokoll zwischen den Endgeräten zur
Verfügung, um Informationen über die aktuelle Leitungsqualität auszutauschen.
Die Themen Produktivität und Benutzerfreundlichkeit haben in der jüngeren Vergangenheit massiv
zur Verbreitung von SSL-VPN-Lösungen beigetragen. Zwei Wünsche können als Haupttreiber dieser
Entwicklung gelten: Erstens der Wunsch, auch hinter fremden Firewalls frei arbeiten zu können
(Szenario eines Consultants, Servicetechnikers oder Vertriebsmitarbeiters), zweitens der Wunsch,
keinen Client-Rollout an den Endgeräten bewerkstelligen zu müssen. Differenziert betrachtet,
verschwimmen mittlerweile aber die Unterschiede zwischen IPSec- und SSL-basierten Lösungen. Das
frühere Konnektivitätsdefizit von IPSec ist durch Kapselungstechniken von ESP sowohl in UDP als
auch TCP gelöst. Bei TCP lässt sich zudem ein SSL-Handshake simulieren, sodass auch hochsichere
IPSec-Clients die Firewall oder den HTTP-Proxy durchtunneln.
Die Vorteile des klientenlosen Zugangs beim SSL-VPN sind dagegen in der Praxis kaum noch
relevant: Bei gehobenen Ansprüchen wie etwa dem transparenten Netzzugang oder Health-Checks am
Endpoint muss ebenfalls ein Client auf dem Endgerät installiert werden – sei es vor der
Erstverbindung oder während die Erstverbindung aufgebaut wird. Damit verbleiben als eigentliche
Pluspunkte von SSL-VPNs jene Einsatzbereiche, für die häufig kein Client verfügbar ist oder nicht
installiert werden kann, wie etwa beim Kiosk-PC, dem PDA oder dem Smartphone oder auch bei auch
weniger verbreiteten Betriebssystemen. Als Konsequenz ist man dann funktionell jedoch auf ein
simples HTTPs-Zugangsportal beschränkt. Der größte Minuspunkt von SSL-VPNs im transparenten Einsatz
ist dagegen die geringe Leistungsfähigkeit, bedingt durch das Übereinanderlegen von TCP als äußerem
Kapselungsprotokoll und TCP als dominantem transportierten Anwendungsprotokoll.
Wer also denkt, dass VPN im Jahr 2007 eine voll ausgereizte Technik sei, irrt. Speziell im
Bereich Skalierbarkeit, Betriebskosten und Kommunikationsoptimierung ergeben sich große
Unterschiede zwischen den Produkten. Und selbst bei den angebotenen Security-Features gibt es große
Unterschiede zwischen VPNs von der Stange und VPNs für individuelle Ansprüche.