Tunneling

Das Tunneling oder Kapselung ist eine Technik, die es erlaubt, beliebige Datenpakete aus einem LAN über ein anderes Netzwerk zu verschicken. Dabei spielt die Adressierung und das im LAN verwendete Übertragungsprotokoll keine Rolle. Das heißt, durch das Tunneling ist es möglich, zwei oder mehrere LANs transparent über ein WAN zu koppeln.

Figure 1: Koppelung von zwei LANs durch einen Tunnel

Tranzparenz bedeutet hierbei, daß die kommunizierenden Stationen in den verbundenen LANs nicht mit der Verwaltung und dem Aufbau des Tunnels betraut sind. Diese Aufgabe wird in jedem LAN von einem extra Tunnel-Server übernommen. Die Stationen in den LANs arbeiten so, als ob sie alle an einem einzigen LAN angeschlossen wären.

IP-Tunneling über das Internet beruht darauf, daß dem zu transportierenden Paket ein neuer IP-Kopf vorangestellt wird (IP in IP, RFC 2004). Dieser Kopf wird in einem Server des LANs oder des ISPs erzeugt, der den Ausgangspunkt des Tunnels bildet. Der Kopf enthält als Quelladresse die Adresse dieses Rechners und als Zieladresse einen Server, der den Endpunkt des Tunnels bildet und das transportierte Paket wieder entpackt, also den Tunnel-Kopf entfernt. Dieses Paket wird dann wie gewohnt im Ziel-LAN seinem Empfänger zugestellt.

Der Tunnel verhält sich also wie eine bidirektionale Direktverbindung zwischen den beiden Tunnel-Servern.

Das Tunneling-Verfahren ist in Schicht 3 des ISO/OSI-Basisreferenzmodells angesiedelt. Dadurch stellt es selber keine Zugriffskontrollmechanismen zur Verfügung. Es bildet aber die Grundlage für einige Schicht-2-Protokolle, die diese Mechanismen implementieren.

Ein erster Standard für das Tunneling ist Generic Routing Encapsulation (GRE), RFC 1701 und RFC 1702. Dabei handelt es sich um eine Richtlinie, wie die Tunnel-Pakete aufgebaut sein sollen.

Figure 2: Aufbau eines GRE-Paketes zum Transport von IP-Paketen

In einem GRE-Paket werden drei Abschnitte unterschieden: ein Tunnel-Kopf, der das Tunnelziel enthält, ein GRE-Kopf, der Informationen über das verwendete Tunnel-Protokoll und Verschlüsselungsalgorithmen enthält, und die Nutzlast (Payload), also das zu transportierende LAN-Paket. Abbildung 2 zeigt den Aufbau eines solchen GRE-Paketes. Als Beispiel ist hier die Kapselung eines IP-Paketes gewählt. Mit GRE-Paketen lassen sich aber auch beliebige andere Netzwerkprotokolle tunneln.

PPTP, L2F und L2TP

Die Protokolle, die in diesem Abschnitt vorgestellt werden, arbeiten auf Schicht 2 des ISO/OSI-Basisreferenzmodells. Somit sind sie in der Lage Zugriffskontrollmechanismen bereit zu stellen, die eine Sicherung des Datenverkehrs in einem VPN ermöglichen.

Das Point-to-Point Tunneling Protocol (PPTP) das von Microsoft und anderen führenden Unternehmen der Netzwerkbranche entwickelt wurde, wurde 1996 der Internet Engineering Task Force (IETF) als Standardprotokoll für das Internet-Tunneling vorgeschlagen. PPTP ist eine Erweiterung des Point-to-Point Protocol (PPP). PPTP kapselt PPP-Pakete in IP-Paketen, so können Protokolle wie IP, IPX und NetBEUI über das Internet getunnelt werden. Für die Zugangskontrolle werden das Password Authentification Protocol (PAP) und das Challenge Handshake Protocol (CHAP) verwendet. Als Verschlüsselungsalgorithmen dienen die Rivest´s Cipher 4 (RC4) und der Data Encryption Standard (DES) mit Schlüsseln zwischen 40 und 128 Bit Länge.

PPTP ermöglicht also den Aufbau eines sicheren Tunnels, in dem die Daten verschlüsselt transportiert werden. Da PPTP mit PAP und CHAP auch einen gesicherten Verbindungsaufbau und Authentifizierung unterstützt, kann es sowohl auf der Seite eines ISP, zur Verbindung von LANs, als auch auf Anwenderseite zur Anbindung von mobilen Rechnern, verwendet werden. Dabei kann der Anwender eine PPP-Verbindung zu seinem ISP aufbauen, die noch nicht gesichert ist. Dann wird entweder der Tunnel vom ISP aufgebaut, wenn dieser PPTP unterstützt, oder der Anwender kann, wenn PPTP auf seinem eigenen Rechner installiert ist, den Tunnel selbst aufbauen. Nach erfolgreicher Initialisierung des Tunnels nimmt PPTP die Quellpakete entgegen, verschlüsselt sie und gibt sie dann gemäß der GRE weiter.

Ein PPTP-Paket setzt sich aus vier Schichten zusammen. Die oberste Schicht bildet ein Zustellungs-Kopf, der aus dem Netzwerkprotokoll des WAN besteht, über das das VPN aufgebaut wird. Darauf folgt als zweite Schicht ein IP-Kopf, der grundlegende Informationen über das IP-Datagramm enthält, wie die Paketlänge und die Absender- und Empfängeradresse. Die dritte Schicht enthält einen GREv2-Kopf. GREv2 stellt eine für PPTP entwickelte Erweiterung des GRE-Kopfes dar. Er enthält Informationen über die Art der Pakete, die gekapselt wurden und PPTP spezifische Daten über die Verbindung zwischen dem Client und dem Server. Die letze Schicht, das Nutzlast-Datagramm, enthält die eigentlichen Datenpakete. Im Fall von PPP sind das die PPP-Pakete, die zwischen Client und Server ausgetauscht werden. In diesen PPP-Paketen befinden sich dann die zu transportierenden IP-, IPX- oder NetBEUI-Pakete. Zur Veranschaulichung zeigt Abbildung 3 die aktiven Protokollschichten während einer PPTP-Verbindung.

Figure 3: Aktive Protokollschichten während einer PPTP-Verbindung

Das Layer 2 Forwarding (L2F) von der Firma Cisco Systems stellt ein ähnliches Protokoll dar, das mit PPTP die Grundlage für das Layer 2 Transport Protocol (L2TP) eine Weiterentwicklung beider Systeme bildet. L2F unterstützt verschiedene Protokolle und mehrere unabhängige, parallele Tunnel. Die Benutzeridentifizierung ist allerdings etwas schwächer als bei PPTP und eine extra Verschlüsselung der Daten ist nicht vorgesehen.

L2TP unterscheidet sich nur in wenigen Punkten von PPTP. Zum einen ist hier zu nennen, daß L2TP, wie das L2F, mehrere Tunnel unterstützt, zum anderen liegt die Kontrolle über den Endpunkt eines Tunnels nicht wie bei PPTP beim Anwender, sondern wird vom ISP vorgegeben. Eine ausführliche Erläuterung der Unterschiede zwischen PPTP und L2TP findet sich in.

IPSec

IP Security (IPSec) ist eine neuere Technik, die PPTP langfristig als VPN-Standard ablösen soll, da sie ein höheres Maß an Sicherheit als PPTP garantieren kann. IPSec arbeitet auf IPv4 und soll fester Bestandteil von IPv6 werden. Bei IPSec handelt es sich um ein Paket von Protokollen (RFC 1825 - 1829), die für Authentifizierung, Datenintegrität, Zugriffskontrolle und Vertraulichkeitsbelange innerhalb des VPN zuständig sind. IPSec besitzt zwei verschiedene Betriebsmodi: den Transportmodus und den Tunnelmodus.

Figure 4: Aufbau von IPSec-Paketen in den verschiedenen Betriebsmodi

Transportmodus:: Im Transportmodus verschlüsselt IPSec nur den Datenteil des zu transportierenden IP-Paketes. Der Original-IP-Kopf bleibt dabei erhalten und es wird ein zusätzlicher IPSec-Kopf hinzugefügt. Der Vorteil dieser Betriebsart ist, daß jedem Paket nur wenige Bytes hinzugefügt werden. Dem gegenüber steht, daß jede Station im VNP IPSec beherrschen muß, was eine Neukonfiguration von bestehenden Netzen nötig macht. Außerdem ist es für Angreifer möglich, den Datenverkehr im VNP zu analysieren, da die IP-Köpfe nicht modifiziert werden. Die Daten selbst sind aber verschlüsselt, so daß man nur feststellen kann, welche Stationen wieviele Daten austauschen, aber nicht welche Daten.
Tunnelmodus:: Im Tunnelmodus wird das komplette IP-Paket verschlüsselt und mit einem neuen IP-Kopf und IPSec-Kopf versehen. Dadurch ist das IPSec-Paket größer als im Transportmodus. Der Vorteil besteht hier darin, daß in den LANs, die zu einem VPN verbunden werden sollen, je ein Gateway so konfiguriert werden kann, daß es IP-Pakete annimmt, sie in IPSec-Pakete umwandelt und dann über das Internet dem Gateway im Zielnetzwerk zusendet, das das ursprüngliche Paket wiederherstellt und weiterleitet. Dadurch wird eine Neukonfiguration der LANs umgangen, da nur in den Gateways IPSec implementiert sein muß. Außerdem können Angreifer so nur den Anfangs- und Endpunkt des IPSec-Tunnels feststellen.

Wie Abbildung 4 zeigt, wird der IPSec-Kopf hinter dem IP-Kopf eingefügt. Er kann zwei Komponenten enthalten, die einzeln, unabhängig voneinander oder zusammen eingesetzt werden können: den Authentifizierungskopf (Authentification Header, AH) und den Encapsulating Security Payload (ESP). Der AH sichert die Integrität und Authentizität der Daten und der statischen Felder des IP-Kopfes. Er bietet jedoch keinen Schutz der Vertraulichkeit. Der AH benutzt eine kryptographische Hashfunktion (keyed-hash function) und keine digitale Signatur, da diese Technik zu langsam ist und den Datendurchsatz im VPN stark reduzieren würde. Der ESP schützt die Vertraulichkeit, die Integrität und Authentizität von Datagrammen. Er schließt aber die statischen Felder des IP-Kopfes bei einer Integritätsprüfung nicht ein.

IPSec verwendet das Diffie-Hellman Schlüsselaustauschverfahren zur Identitätsprüfung. Die benutzten kryptographischen Hashfunktionen sind unter anderem HMAC, MD5 und SHA. Als Verschlüsselungsalgorithmen dienen zum Beispiel DES und IDEA, Blofish und RC4. Weiterführende Informationen und genaue Beschreibungen dieser Verfahren finden sich in.

SOCKS v5

SOCKS v5 ist eigentlich das von der IETF eingeführte Standardprotokoll zum sicheren Passieren einer Firewall. In Kombination mit der Secure Socket Layer (SSL) bildet es die Grundlage für den Aufbau hochsicherer VPNs, die mit jeder Firewall kompatibel sind.

SOCKS v5 arbeitet auf Schicht 5 des ISO/OSI-Basisreferenzmodells. Aus diesem Grund bietet es weit bessere Zugriffskontrollmöglichkeiten als Protokolle, die auf tieferen Schichten arbeiten, da es mehr Informationen über die laufenden Anwendungen zur Verfügung hat.

Figure 5: Einordnung der VPN-Protokolle im ISO/OSI-Basisreferenzmodell

SOCKS v5 identifiziert einzelne Benutzer und leitet den gesamten Datenverkehr über eine Firewall. So ist es möglich, die Zugriffsrechte innerhalb des VPN für jeden Benutzer individuell zu konfigurieren, ohne neue Anwendungen extra anpassen zu müssen.

Durch ihre Ansiedlung in Schicht 5 des ISO/OSI-Basisreferenzmodells sind SOCKS v5 und SSL die einzigen Protokolle, die mit VPN-Protokollen niedrigerer Schichten zusammenarbeiten können.

Nachteile des Einsatzes von SOCKS v5 sind die geringere Geschwindigkeit, da alle Daten eine Firewall passieren müssen, und die Notwendigkeit entsprechender Programme auf jedem Rechner im VPN, die einen Verbindungsaufbau durch die Firewall ermöglichen.

RADIUS (Remote Authentication Dial-In User Service)

RADIUS (RFC 2058, RFC 2059) ist kein VPN-Protokoll im eigentlichen Sinne, sondern ein zusätzlicher Dienst, der die Verwaltung und Sicherung von Wählzugängen zu einem VPN erleichtert und verbessert. Den Aufbau eines VPN mit RADIUS-Servern zeigt Abbildung 6. RADIUS arbeitet mit einer Client-/Server-Architektur, wobei RADIUS den Server darstellt und der ISP-Server oder der Firmen-Server den Client.

Figure 6: Aufbau eines VPN mit RADIUS-Servern

RADIUS stellt Mechanismen zur Benutzeridentifizierung über PAP und CHAP, zur Zugriffskontrolle über eine eigene RADIUS-Datenbank und zur Verwaltung von dynamischen IP-Adressen bereit. Zur Kommunikation zwischen dem RADIUS-Server und dem ISP-Server wird das User Datagram Protocol (UDP) benutzt. Das Format der RADIUS-Pakete ist in RFC 2058 beschrieben.

RADIUS wird im allgemeinen in Kombination mit anderen VPN-Protokollen wie zum Beispiel L2F eingesetzt. Eine ausführliche Beschreibung der Zusammenarbeit dieser beiden Protokolle findet sich bei.

Konfigurationen von VPNs

Dieser Abschnitt befaßt sich mit der Konfiguration und dem Aufbau von VPNs für verschiedene Anwendungsbereiche. Anhand von Beispielen soll gezeigt werden, welche Netzwerkstrukturen sich für welche Einsatzgebiete besonders gut eignen. Ferner werden die Einsatzmöglichkeiten der in Abschnitt 2 beschriebenen Protokolle unter Einbeziehung des Sicherheitsaspektes angeführt.

End-to-End-VPNs

End-to-End-VPNs stellen eine direkte Verbindung zwischen mehreren Arbeitsrechnern dar. Eingesetzt werden kann diese Art der VPNs zum Beispiel, um Bankkunden über das Internet sicher mit einem Buchungsrechner zu verbinden, oder um mehreren Wissenschaftlern an verschiedenen Standorten die Arbeit an einem gemeinsamen Projekt zu erleichtern.

Figure 7: Zwei Beispiele für den Aufbau von End-to-End-VPNs

Zu beachten ist hierbei, daß auf jedem der an das VPN angeschlossenen Rechner ein entsprechendes VPN-Protokoll installiert sein muß, da die Arbeitsrechner direkt untereinander und nicht über zwischengeschaltete VPN-Server verbunden werden.

Besonders geeignete Protokolle für den Aufbau von End-to-End-VPNs sind L2F, L2TP und IPSec, wobei IPSec für Anwendungen, die ein Höchstmaß an Sicherheit erfordern, am besten geeignet ist. Bei dieser Konfiguration ergibt sich aber immer das Problem der Verwaltung des Netzwerks. Im Fall der Online-Banking-Anwendung wird die Verwaltung vom Bankrechner übernommen, da keine Notwendigkeit des Datenaustausches einzelner Kunden untereinander besteht. Im Fall der verteilten Projekte dagegen muß jede der angeschlossenen Stationen die Zugriffe von allen anderen Rechnern selbst verwalten, da der Austausch von Daten der einzelnen Projektteilnehmer untereinander möglich sein muß.

Site-to-Site-VPNs

Site-to-Site-VPNs stellen die klassische VPN-Variante dar. Hierbei werden mehrere LANs an verschiedenen Standorten verbunden. Diese Konfiguration eignet sich zum Beispiel, um Firmennetze zusammenzuschließen (Abbildung 8), Krankenhäuser zum Datenaustausch zu verbinden, oder Forschungsnetze mit mehreren Forschungsgruppen aufzubauen.

Figure 8: Site-to-Site-VPN zur Verbindung verschiedener Firmenstandorte

Bei Site-to-Site-VPNs unterscheidet man zwischen Intranet VPNs und Extranet VPNs, die verschiedenen Sicherheitsanforderungen genügen müssen.

Intranet VPNs

Unter Intranet VPNs versteht man Netze, die zur Erweiterung interner LANs dienen. Ein typisches Beispiel ist die in Abbildung 8 gezeigte Anwendung. Hierbei wird davon ausgegangen, daß jede der angeschlossenen Parteien den anderen voll vertraut, und daß alle Ressourcen im Netz allen Parteien zugänglich sein sollen. Daher wird bei diesem VPN-Typ, bei einem Mindestmaß an Sicherheit, großer Wert auf die Geschwindigkeit gelegt. Um die Datensicherheit zu erhöhen, können Zugriffsbeschränkungen auf Benutzerebene eingesetzt werden.

Als Protokoll kann hier zum Beispiel IPSec im Transportmodus eingesetzt werden. Dabei sind die transportierten Daten auf ihrem Weg durch das Internet durch eine Verschlüsselung geschützt und es werden nur wenige zusätzliche Byte für den IPSec-Kopf benötigt.

Extranet VPNs

Bei Extranet VPNs legt man im Vergleich zu Intranet VPNs weit größeren Wert auf die Sicherheit. Extranet VPNs werden zum Beispiel eingesetzt, um das interne Netzwerk einer Firma mit den Netzen von Geschäftspartnen und Zulieferern zu verbinden. Hierbei muß das VPN gewährleisten, daß jeder Teilnehmer nur auf die für ihn bestimmten Ressourcen Zugriff erlangen kann.

Das Datenaufkommen in Extranet VPNs ist im allgemeinen auch geringer als in Intranet VPNs, so daß man zur Realisierung ohne weiteres Lösungen einsetzen kann, die bei geringerer Geschwindigkeit ein Höchstmaß an Sicherheit bieten. Hierzu kann SOCKS v5 und SSL verwendet werden, da diese Kombination in Verbindung mit einer geeigneten Firewall auch Kontrolle über die Zugriffe einzelner Anwendungen erlaubt.

End-to-Site-VPNs

End-to-Site-VPNs oder Remote-Access VPNs dienen in erster Linie zur Anbindung von Außendienstmitarbeitern an ein internes Firmennetz. Eine solche Konfiguration zeigt Abbildung 9. Der Hauptvorteil eines solchen Netzes besteht darin, daß sich die Mitarbeiter über einen beliebigen POP des ISPs der Firma in das Netz einwählen können. Dadurch können die meist sehr hohen Kosten für Fernverbindungen reduziert werden, und das Unternehmen ist nicht gezwungen, eigene Modem-Bänke zu unterhalten und zu administrieren.

Figure 9: End-to-Site-VPN zur Anbindung von mobilen Mitarbeitern an ein Firmennetz

Für den Aufbau von End-to-Site-VPNs eignen sich im besonderen adressunabhängige VPN-Protokolle wie PPTP, da der Großteil der ISPs mit dynamischen IP-Adressen arbeitet. Auf Seiten der Sicherheit wird bei diesem VPN-Typ großer Wert auf die Identifizierung der einzelnen mobilen Mitarbeiter gelegt, um das Firmennetz gegen Angriffe Dritter abzusichern. Hierzu kann ein RADIUS-Server verwendet werden, der dann unabhängig vom benutzten VPN-Protokoll eine zusätzliche Benutzeridentifizierung anhand einer eigenen Datenbank vornehmen kann. Alternativ ist auch hier eine Konfiguration mit SOCKS v5 in Kombination mit einem solchen RADIUS-Server vorstellbar.

Ausblick

VPNs versetzen Unternehmen in die Lage, auf einfache und kostengünstige Weise Netzwerke aufzubauen, bestehende Netze zu erweitern und Außendienstmitarbeiter anzubinden und dabei bestehende WAN wie das Internet zu nutzen. VPNs stellen eine billigere Alternative zu klassischen Wählleitungen dar und vereinfachen so die Administration von Netzwerken, da sie die sonst nötigen Modem-Bänke ersetzen können.

Aber trotz all dieser Vorteile können die Sicherheitsfragen, die diese neuen Netze aufwerfen nicht unbeachtet bleiben. Bei einem Datenaustausch über ein öffentliches Netz, wie dem Internet, besteht immer die Gefahr von Angriffen. Es ist also immer nötig, die Daten zu verschlüsseln und die Zugangspunkte zu den VPNs abzusichern.

Hier zeigt sich, wo zur Zeit noch die Schwächen der bestehenden VPN-Implementierungen liegen. Eine Betrachtung der auf dem Markt befindlichen Protokolle erweckt den Eindruck, daß jeder Hersteller seine eigenen Verschlüsselungsalgorithmen, Schlüsselaustausch- und Benutzeridentifizierungsverfahren verwendet. Die Kompatibilität scheint dabei unbeachtet zu bleiben. Und tatsächlich ist diese Inkompatibilität der Systeme das Argument, das heute viele Unternehmen vom Einsatz moderner VPN-Lösungen abhält.

Die aussichtsreichsten Anwärter als VPN-Standards sind PPTP und IPSec. Viele Experten bescheinigen vor allem IPSec beste Zukunftschancen im Hinblick auf die bevorstehende Einführung von IPv6.