Microsoft zufolge gehören VPNs schon bald der Vergangenheit an. Stattdessen setzt der Hersteller auf IPv6. ZDNet zeigt, wie man sich einen Direct-Access-Zugang über IPv4 schafft und welche Beschränkungen dadurch wegfallen.
Das klassische VPN könnte schon bald der Vergangenheit angehören, zumindest wenn sich Microsofts Direct-Access-Strategie durchsetzt: Anstelle einer Einwahl über einen VPN-Client sollen Rechner automatisch beim Hochfahren Zugriff auf die Firmenrechner erhalten. Der mobile Client ist immer erreichbar, beispielsweise für Updates oder Helpdesksupport über Remote Desktop. Einzige Voraussetzung ist eine Internetverbindung.
Auch die Anbindung über NAT aus einem privaten Netzwerk heraus macht keine Probleme. Client-Management-Konzepte, etwa Intels vPro[1], können mit einer VPN-freien Anbindung wesentlich effizienter realisiert werden.
Microsoft setzt dabei lobenswerterweise auf IPv6 als Transportprotokoll und auf IPSec zum Schutz der mobilen Clients und des Firmennetzwerks. Mit einer nativen IPv6-Anbindung entfällt die Notwendigkeit von NAT- und VPN-Verbindungen vollständig. Einen direkten IPv6-Zugang bieten heute nur wenige Provider an. Außerdem erfordert die Tatsache, dass jeder Rechner mit einer öffentlichen IPv6-Adresse im Internet steht, völlig neue Sicherheitskonzepte.
Beide Probleme adressiert Microsoft mit seinem Direct-Access-Konzept[2], das in Windows Server 2008 R2[3] und Windows 7[4] realisiert ist. Um IPv6 in einem IPv4-Netzwerk zu tunneln, gibt es mehrere Möglichkeiten. Dabei setzt Microsoft auf das Protokoll Teredo[5], das maßgeblich von den Redmondern mitentwickelt wurde und zwischenzeitlich im RFC4380[6] standardisiert ist. Teredo ist auch für andere Betriebssysteme wie Linux und Mac OS verfügbar, so dass sie mit Microsoft Direct Access als Unternehmensserver und als mobile Clients grundsätzlich genutzt werden können. Die bekannteste Implementierung für Linux und Mac OS ist Miredo[7].
Bildergalerie
So installiert man Microsoft Direct Access[8]
» zur Bildergalerie ...[8]Die 6to4-Tunnelung hat allerdings den Nachteil, dass sie nur von Rechnern genutzt werden kann, die eine öffentliche IPv4-Adresse besitzen. Bei einer Anbindung über einen NAT-Router mit privater IPv4-Adresse ist nichts zu machen. Nur wer einen 6to4-fähigen Router besitzt, etwa die Fritzbox 7270 mit aktueller Laborfirmware, kann seinen NAT-Router so konfigurieren, dass das gesamte Heimnetz IPv6-fähig wird. Wie das geht, zeigt der Artikel AVM bringt das Internet von morgen auf die Fritzbox[13].
Teredo hingegen tunnelt das IPv6-Protokoll in UDP-Pakete. So wird es möglich, IPv6 auch hinter einem NAT-Router ohne IPv6-Unterstützung, in einem öffentlichen WLAN oder über den stark eingeschränkten NAT-Internetzugang deutscher UMTS-Anbieter[14] zu tunneln. Die Microsoft-Lösung schafft also einen Zugang von überall, sofern die Firewall den Teredo-Traffic über UDP-Port 3544 nicht absichtlich blockt.
Teredo und 6to4 dürfen nicht mit 6over4[15] und Isatap[16] verwechselt werden. Letztere sind Tunnelmechanismen, die ein VPN schaffen, in dem alle teilnehmenden Rechner untereinander mit einer linklokalen Adresse mit dem IPv6-Prefix FE80 kommunizieren. Linklokale Adressen sind ein neues Konzept von IPv6. Sie sind "noch privater" als private IPv4-Adressen wie 192.168.0.1. Private IP-Adressen werden normalerweise innerhalb eines Intranets geroutet, zum Beispiel zwischen zwei Unternehmensstandorten. Linklokale Adressen werden überhaupt nicht geroutet und automatisch zusätzlich zu einer öffentlichen oder privaten IPv6-Adresse an einen Netzwerkadapter gebunden. Das ermöglicht unter anderem die Autokonfiguration. So kann ein Rechner mit der Multicastadresse eines Routers kommunizieren, um weitere Konfigurationsdaten zu erhalten.
Microsoft hat mit der Wahl von Teredo im Hinblick auf Zukunftssicherheit und praktischer Verfügbarkeit die richtige Entscheidung getroffen. Wenn das Internet in einigen Jahren nach und nach auf IPv6 umgestellt wird, muss man sich mit den Sicherheitsimplikationen von öffentlichen IPv6-Adressen für jeden Rechner ohnehin auseinandersetzen. Die Schaffung eines linklokalen VPNs hätte die Sicherheitsprobleme erst einmal ausgeklammert.
In einem linklokalen IPv6-VPN kann man zwar testen, wie gut Outlook und Exchange über IPv6 zusammenarbeiten, würde aber dann später auf sicherheitsrelevante Einschränkungen stoßen, die in einem geschützten Netz nicht auftreten. Eine Realisierung von Direct Access mit privaten, aber nicht linklokalen Adressen ist jedoch möglich, wenn sich Sicherkonzepte mit öffentlichen IPv6-Adressen kurzfristig nicht realisieren lassen.
Direct Access bietet heute eine Lösung, die grundsätzlich jedermann verwenden kann, um Unternehmensnetz und mobile Rechner über öffentliche IPv6-Adressen miteinander zu verbinden. Wenn sich die native IPv6-Anbindung ins Internet nach und nach durchsetzt, kann man auf die IPv6-in-IPv4-Tunnelung verzichten. Die Sicherheitskonzepte können unverändert übernommen werden.
Wer sich heute an Direct Access heranwagt, kann dies allerdings in der Regel nur innerhalb von Pilotprojekten realisieren. Die IPv6-Verbindung zwischen mobilen Clients und Servern dürfte an der ein oder anderen Stelle zu Schwierigkeiten führen. Ebenso lassen sich Vista- und XP-Clients nicht per Direct Access einbinden. Kleine und mittelgroße Unternehmen haben unter Umständen Probleme, die nötige Infrastruktur bereitzustellen. Neben einem Domain-Controller mit Windows Server 2008 R2 ist als Gateway ein weiterer Rechner erforderlich, der auch als virtuelle Maschine realisiert werden kann. Dieses Gateway benötigt zwei aufeinanderfolgende öffentliche IPv4-Adressen zur exklusiven Nutzung. Allein diese Voraussetzung lässt sich in mittelständischen Unternehmen oft nicht kurzfristig schaffen.
Microsoft wird ein Direct-Access-Pilotprojekt selbst ausrollen, um zu testen, ob die teilnehmenden Mitarbeiter über IPv6 genauso gut an alle Dienste im Unternehmen herankommen wie über IPv4. Diesem Umstand ist es offensichtlich zu verdanken, dass Direct Access in einer ersten Variante für Microsofts eigene Unternehmensgröße ausgelegt ist. Auf der Client-Seite sieht man das daran, dass Direct Access nur mit der Enterprise- und der Ultimate-Version möglich ist. Windows 7 Professional reicht nicht aus.
Um Direct Access zu installieren, sind einige Voraussetzungen nötig. Serverseitig benötigt man eine PKI-Infrastruktur in Form der Active Directory Certificate Services. Dabei ist ein Auto-Enrollment zu empfehlen, das allen Clients automatisch Zertifikate verschafft, sobald sich das erste Mal ein Benutzer im Intranet an einer Domain anmeldet. Erforderlich ist darüberhinaus ein IIS-Webserver mit öffentlicher IPv4-Adresse im Internet. Er kann von überall erreicht werden und entscheidet, ob ein Rechner mit Zertifikat überhaupt über Teredo Zugang zu den IPv6-Adressen im Intranet bekommt. Außerdem veröffentlicht er die Certificate Revocation List (CRL), die erforderlich ist, wenn einem Mitarbeiter kurzfristig der Zugang entzogen werden muss.
Wenn man sich mit Active-Directory-Domänen, der Microsoft PKI und dem IIS ein wenig auskennt, dann ist ein Testszenario schnell aufgesetzt. Im ZDNet-Testlabor gelingt eine Installation ausgehend von nackter Hardware ohne Betriebssystem innerhalb vier Stunden. Der Release Candidate von Windows Server 2008 R2 wird dabei vom USB-Stick auf einen Rechner mit SSD installiert. Das spart leicht eine Stunde. Den Domain Controller setzt ZDNet auf dem physischen Rechner auf. Das Teredo-Gateway und der öffentliche Webserver werden auf einer einzigen Hyper-V-Maschine installiert. Microsoft empfiehlt allerdings beide Dienste auf zwei getrennten Servern zu installieren. Das erfordert eine weitere öffentliche IPv4-Adresse.
Der Domain Controller ist schnell eingerichtet. Die Certificate Services werden einfach nur installiert. Für ein Proof-of-Concept von Direct Access sind an den PKI-Diensten keine weiteren Einstellungen erforderlich. Der DNS-Server für die Active-Directory-Domäne muss aus dem Internet per IPv4 erreichbar sein. Empfehlenswert für den DNS-Server ist ferner, dass er über eine öffentliche IPv6-Adresse aufgerufen werden kann. Dazu entfernt ZDNet mit dem Befehl dnscmd /config /globalqueryblocklist wpad Teredo und Isatap aus der globalen DNS-Blockliste. Der Testclient und der Intranet-Testserver bekommen das nötige Zertifikat über das Certificate-MMC manuell. Das geht schneller als das Aufsetzen von Auto-Enrollment.
Die mindestens zwei aufeinander folgenden öffentlichen IPv4-Adressen lassen sich im ZDNet-Labor nicht kurzfristig beim Provider ordern und vom Administrator ins Labor-Netzwerk routen. Daher simuliert ZDNet das gesamte Internet mit einem Consumer-Ethernet-Switch. Um Direct Access zu testen, reicht es aus, wenn über diesen Switch Client und Teredo-Gateway mit dem scheinbar öffentlichen IPv4-Adressraum 130.107.0.0/16 kommunizieren können. Dieses Vorgehen empfiehlt Microsoft in einem Laborkonfigurationsvorschlag[17].
Microsoft Direct Access ist kein Dienst wie die Routing and Remote Access Services[18], die unter anderem für die VPN-Einwahl zuständig sind. Direct Access besteht nur aus einer MMC-Steuerkonsole, die vorhandene Dienste wie das Teredo-Gateway, die Certificate Services, IPv6-Routing, Internet Information Server, Network Location Services und Network Access Protection miteinander kombiniert. Diese Dienste gibt es allesamt auch schon in Windows Servern vor 2008 R2. Um sie für Direct Access nutzen zu können, müssen jedoch ihre aktuellen Varianten verwendet werden.
Die Direct-Access-Steuerkonsole, siehe Bild 1[19], wird im Server-Manager des Teredo-Gateways als Feature hinzugefügt. Sie leitet Schritt für Schritt durch das Setup. Nicht erfüllte Voraussetzungen, etwa zwei öffentliche IPv4-Adressen auf dem Gateway oder mindestens zwei Netzwerkkarten, findet der Wizard umgehend, siehe Bild 3[20]. Die Tatsache, dass die Firewall in der Standard-Konfiguration keinen Teredo-Traffic durchlässt, beanstandet das Setup mit einer Warnung. Die Installation kann trotzdem fortgesetzt werden. Das Problem lässt sich später durch Öffnung von UDP-Port 3544 beseitigen.
In einem ersten Schritt bestimmt man eine Active-Directory-Security-Gruppe, die die Computer enthält, welche grundsätzlich Direct Access benutzen dürfen, siehe Bild 2[21]. Im zweiten Schritt, siehe Bild 4[22], bestimmt man, welche Adapter des Teredo-Gateways ins Intranet und ins Internet zeigen. Anschließend gibt man mindestens je einen DNS-Server und einen Anmeldeserver für das Active-Directory an, siehe Bild 5[23], die aus dem Internet erreichbar sind.
Der DNS-Server muss eine öffentliche IPv4-Adresse besitzen. Der Anmeldeserver bekommt eine erreichbare IPv6-Adresse. Eine öffentliche IPv4-Adresse hätte es auch getan. Das wäre dann allerdings die vierte, die man in einer von Microsoft empfohlenen Konfiguration exklusiv für Direct Access bereitstellen muss. Die IPv6-Adresse des Anmeldeservers kann öffentlich oder privat, aber nicht linklokal sein. Der Anmeldeserver ist über das Computerzertifikat geschützt. Ihn können nur Rechner benutzen, die über ein Firmenzertifikat verfügen. Nach der Anmeldung können auch Benutzerzertifikate zur Authentifizierung eingesetzt werden. Das konfiguriert man im vierten Schritt, siehe Bild 6[24]. So ist sichergestellt, dass nur berechtigte Benutzer von berechtigten Computern Zugriff auf erlaubte Server erhalten.
Der Wizard erleichtert die Einrichtung deutlich. Unter anderem erstellt er die Group Policy, die erforderlich ist, dass die Teredo-Interfaces der Clients richtig konfiguriert werden und sich am richtigen DNS-Server die Adressen für Teredo-Gateway und Anmeldeserver abholen. Ein bisschen Arbeit bleibt jedoch. Die grundsätzliche Teredo-Funktionalität am Client schaltet man mit dem Befehl netsh interface teredo set state enterpriseclient frei. Bis die Group Policy am Client angekommen ist, dauert es eine Weile. Wer nicht warten will, nutzt den Befehl gpupdate /force. Manchmal mag der mittlerweile völlig unzutreffend bezeichnete "TCP/IP-NetBIOS-Hilfsdienst" Änderungen in der IP-Konfiguration nicht sofort erkennen. In diesem Fall hilft mit man dem Befehl sc control iphlpsvc paramchange nach.
Einen Server im Intranet erreicht man nur, wenn er über IPv6-Konnektivität und ein gültiges Zertifikat verfügt. Seine IPv4-Adresse macht ihn über Direct Access nicht erreichbar. So soll es im Endeffekt auch sein. Direct Access ist konsequent auf das Internetprotokoll der Zukunft ausgelegt. Kompatibilitätsballast aus der heutigen IPv4-Zeit kann bei Bedarf einfach abgeworfen werden. Mit Serverdiensten von Microsoft wird es unter IPv6 sicherlich nicht zu Problemen kommen, wenn der IPv6-Ping funktioniert. Interessant ist es vor allem, zu testen, wie sich Third-Party-Applikationen auf der Client- und Serverseite mit IPv6 verhalten.
Gleiches gilt für das Zusammenspiel von Routern, Netzwerkmanagementsystemen, Security-Appliances und anderen Komponenten mit Clients, die mobil nur über IPv6 erreichbar sind. Die ein oder andere Überraschung wird dabei nicht ausbleiben.
Mit Direct Access bietet Microsoft ein überraschend gut durchdachtes zukunftsorientiertes Konzept. Unternehmen können auf diese Weise Schritt für Schritt zu einem VPN-freien IPv6-Netzwerk migrieren, ohne dass zu irgendeinem Zeitpunkt eine "harte Umstellung" erfolgen muss. Ein gleichzeitiger Betrieb einer VPN-Einwahl und von Direct Access ist problemlos möglich. Dabei ergibt sich jedoch eine größere Angriffsfläche.
Für viele Unternehmen sind die technischen Voraussetzungen, die für Direct Access erforderlich sind, allerdings nicht kurzfristig zu schaffen: Benötigt werden mindestens zwei Servern mit Windows Server 2008 R2, mindestens zwei, besser vier, öffentliche IPv4-Adressen sowie Clients mit Windows 7 in der Enterprise- oder Ultimate-Edition.
Ebenso gibt es kein Konzept für die Erreichbarkeit von Intranet-Servern mit Unix-Betriebssystemen. Die PKI-Infrastruktur von Microsoft ist zwar einfach und komfortabel zu verwalten, jedoch steht noch keine integrierte Lösung zur Verfügung, um die Microsoft-Zertifikate über Netfilter (iptables) per IPSec an die IPv6-Interfaces von Linux zu binden und Zugriffsregeln durchzusetzen.
In puncto Interoperabilität sollte Microsoft noch nachbessern. Das ist natürlich nicht ganz einfach, da die grundlegenen Funktionsweisen der unter anderem für die Zugangssicherung auf IP-Ebene zuständigen Filter-Layer Windows Base Filtering Engine[25] und Netfilter (Linux) recht unterschiedlich sind. Ansonsten werden Router-Hersteller ähnliche Konzepte entwickeln und die Marktführerschaft übernehmen, wie es bei der VPN-Einwahl der Fall ist. Die VPN-Einwahl realisieren Unternehmen heutzutage meist über ihre Router oder Security-Gateways. Das hat allerdings meist den Grund, dass Microsofts PPTP-Protokoll[26] Sicherheitsprobleme nachgesagt werden. Sie sind in aktuellen Windows-Versionen jedoch nur noch dadurch bedingt, dass ein "schwaches" Passwort Einbrüche ermöglicht.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = http:/
[20] = http:/
[21] = http:/
[22] = http:/
[23] = http:/
[24] = http:/
[25] = http:/
[26] = http:/