IPsec vs. SSL

VPNs als Disaster-Recovery-Strategie

05.12.2006 | Autor / Redakteur: Justin Korelc, Ed Tittel / Andreas Donner

Disaster-Recovery-Strategien haben das Ziel, die Geschäftskontinuität unter allen Umständen aufrecht zu erhalten. Sollte der Ausfall von Kommunikationskanälen zu den Bedrohungsszenarios eines Unternehmens zählen, ist im Rahmen einer durchdachten Disaster-Recovery-Planung unbedingt auch ein Failover-Kommunikationsmechanismus vorzusehen.

Netzwerke müssen vor Schaden bewahrt werden. Nicht nur drastische Katastrophen wie Naturgewalten, Terrorangriffe oder Pandemien, auch kleinere Unglücke können die IT-Infrastruktur eines Unternehmens und damit die Datenverfügbarkeit gefährden. Für den Notfall müssen deshalb detaillierte Disaster-Recovery-Pläne erstellt werden. Falls eine Hauptdatenübertragungsverbindung ausfällt, ist ein VPN als Failover-Mechanismus ein geschickter Zug. Ein solcher Mechanismus ist wegen der vielen verschiedenen VPN-Optionen leicht zu implementieren.

Unter den zahlreichen, bei VPN-Frameworks verwendeten Tunneltechniken gibt es zwei Protokolle, die bei den sicheren VPN-Techniken dominieren: IPsec und Secure Sockets Layer/Transport Layer Security (SSL/TLS). Ihre relativen Stärken hängen davon ab, wie sie in der Infrastruktur eingesetzt werden, welche Geräte angeschlossen und welche veränderlichen Verfügbarkeitslevels gefordert sind.

IPsec und VPN: die Stärken

Häufig ist IPsec bereits in Routing-Equipment und Gateway-Server-Lösungen integriert. Mit einem IPsec-fähigen Router kann ein Unternehmen eine der vielen Failover-Maßnahmen einführen und verschiedene Levels von Verfügbarkeit und Redundanz realisieren.

IPsec-fähige Geräte erleichtern viele spezielle Verbindungskonfigurationen und unterstützen Leased-Line-Installationen mit Multipfadredundanz, hoher Verfügbarkeit und kostengünstigen WAN-Extranet-Verbindungen. Primäre Kreisläufe erlauben es, doppelte Routing-Devices mit oder ohne Sicherungsverbindungen (Backup Links) einzusetzen, um VPN-Clients und VPN-Gateways mit minimalen Betriebsunterbrechungen zu verbinden.

IPsec und VPN: die Schwächen

Mobile Mitarbeiter sind eine ständige Herausforderung für IPsec-VPN-Lösungen. Die Infrastruktur wurde eigentlich entworfen, um Site-to-Site-Verbindungen optimal zu realisieren. Um richtig zu funktionieren, benötigen IPsec-Lösungen somit oft eine standortspezifische Konfiguration sowohl für die Clients als auch für den Server. Daher sind eine Vorkonfiguration und ein ausführliches Austesten absolut notwendig. Diese Inflexibilität führt häufig dazu, dass IPsec- durch SSL-VPN-Lösungen ersetzt werden, welche wesentlich leichter über jeden Webbrowser von fast jeder Computerplattform aus bedienbar sind.

Mit der ständig wachsenden Forderung nach Mobilität der Belegschaft und der Endanwender ist die IPsec-Infrastruktur mittlerweile unpraktisch geworden, weil sie zu kompliziert zu implementieren und zu kostspielig zu verwalten ist. Außerdem begrenzen inkompatible proprietäre Erweiterungen und Implementierungen in der IPsec-Infrastruktur die allgemeine Flexibilität, Skalierbarkeit und Kapazität des Systems.

Andererseits wird im Businesssektor IPsec häufig in Geräten wie der 7200-Router-Serie von Cisco eingesetzt. Diese Router unterstützen auch Generic Routing Encapsulation, was neue Möglichkeiten bei der Verbindung von Netzwerken eröffnet und auch als VPN-Tunnel-Verbindungen im Fall eines Notfalls verwendet werden kann.

SSL und VPN: die Stärken

SSL-VPN-Lösungen sind im Allgemeinen universeller einsetzbar als die IPsec-Alternativen. SSL ist auf sehr vielen Plattformen als Standard implementiert. Im Gegensatz zu Microsoft Windows inhärentem Vertrauen auf LT2P für IPsec funktionieren SSL-Implementierungen auch auf BSD, Linux, OS X und Solaris-Plattformen – ein Vorteil für Business-to-Client-Verbindungen, falls nicht zueinanderpassende Geräte, Protokolle und Prozeduren zum Einsatz kommen.

Mit hoch flexiblen SSL-VPN-Konfigurationen ist der Datenverkehr mobiler Mitarbeiter am leichtesten zu realisieren. Dies hat mehrere Gründe: Erstens sind sie leicht zu implementieren und zu verwalten, zweitens sind SSL-VPNs optimal für Geräte geeignet, die keine Fernwartung zur Verfügung stellen (wie Heim-PCs, PDAs, Smartphones usw.). Drittens funktionieren SSL-VPNs auf fast allen erdenklichen Geräten, die über einen Webbrowser aufs Internet zugreifen. SSL ist auch bei NAT-Verbindungen viel besser geeignet als IPsec (obwohl viele moderne Implementierungen IPsec-Adressierungsprobleme beheben), da keine kritischen Informationen in den SSL-Paketen beim Adress- oder Port-Übersetzungsprozess verloren gehen.

Einige VPN-Lösungen (z.B. OpenVPN) können standortspezifische Informationen an die Clients senden, beispielsweise DNS-Serveradressen und bevorzugte clientseitige Einstellungen. Dies sorgt bei Failover-Maßnahmen für Transparenz, Geschwindigkeit und Flexibilität. Client-Verbindungen können im Notfall auf alternative Gateways umgeleitet werden. Ist das Hauptgateway wieder online, werden die Client-Verbindungen zurückgeleitet. Eine manuelle Neukonfigurierung der Clients ist in diesem Fall nicht notwendig.

SSL und VPN: die Schwächen

SSL-VPNs produzieren einen Overhead mit zusätzlichen Ebenen bei der Kapselung. Es kann zudem wesentlich komplizierter sein, Verbindungsprobleme zu diagnostizieren, wenn Tunnel-/Verbindungsgeräte in den Aufbau von VPN-Verbindungen involviert sind. In der Regel werden bei VPN-Verbindungen die IP- und Ethernet-Frame-Header innerhalb der SSL-Protokolldateneinheit eingeschlossen, die wiederum innerhalb des TCP- oder UDP-Protokolls gekapselt wird. Diese Anordnung ist für langsame Verbindungen und konservative Ressourcen wenig ideal. Hier ist die systemspezifische Leistung einer im Kernel integrierten IPsec-Lösung besser.

Fazit

IPsec- und SSL-VPN-Techniken passen sich an ähnliche Anforderungen unterschiedlich gut an, jede mit Vor- und Nachteilen. IPsec- und SSL-Lösungen funktionieren auf unterschiedlichen Niveaus von Integration, Interoperabilität und Implementierung, wenn es darum geht, Failover-VPN-Konnektivität zu liefern. Die Wahl der besten Technologie hängt damit von den Umständen und Szenarios ab, die ein Unternehmen in seinem Disaster-Recovery-Plan unterbringen möchte.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)



Spamschutz 

Bitte geben Sie das Resultat dieser Rechenaufgabe (Addition) ein:
Kommentar abschicken

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2001335)