Direct Access - Funktionsprinzip

Die meisten VPNs, die Administratoren und Anwender heute können, funktionieren derart, das der Anwender bei Bedarf die VPN-Verbindung nach der Anmeldung am PC manuell aufbaut. Der PC nutzt eines der bekannten Verfahren (PPTP, L2TP, SSTP) um einen verschlüsselten Tunnel zu einem Zugangspunkt aufzubauen. Er bekommt nach erfolgreicher Anmeldung eine IPv4-Adresse vom VPN-Server. Dies kann eine Adresse aus dem LAN des VPN-Servers sein und der VPN-Server agiert eher wie eine "Bridge". Es kann aber auch ein eigenes Subnetz sein und das VPN-System agiert als Router.

Direct Access ist IPV6

Für den Einsatz von DA ist ein grundlegendes Verständnis von IPV6 erforderlich. Lesen Sie daher bitte vorher die Seiten IPV6 und insbesondere IPv6 im LAN.

IT Free Training: Windows 7 Direct Access
http://itfreetraining.com/70-680/windows-7-Direct Access/

Unterstützung durch Net at Work:
Nutzen Sie doch einfach unter Know-how bei Windows Zertifizierungsstellen (Siehe Firmen CA und Private CA) und Direct Access.
Wir können Sie aktiv unterstützen. Rufen Sie einfach unter 0800-MSXFAQ (0800-638 28 96) an.

Es wurde schon viel über den neuen Ansatz geschrieben, wie mobile Clients ganz einfach "Always on" mit dem Firmennetzwerk verbunden sein können. Und das ganz ohne den Aufbau und Abbau von VPN Verbindungen. Stark vereinfacht werden hierbei einfach zwei Kommunikationspartner per IPV6 verbunden und die IPv6-Möglichkeiten der Authentifizierung und Verschlüsselung (vgl. IPSEC) genutzt. Wenn Sie nun sagen, dass das ja nicht geht, da viele Internetverbindungen und auch ihre Internetanbindung als auch das interne LAN doch nur mit IPV4 arbeitet, so vergessen sie, dass es sehr wohl funktionierende Methoden gibt um IPV6 über IPV4 zu transportieren und umgekehrt. Und genau das ist auch der Trick von Direct Access.

Für den Anwender erfolgt dies alles transparent. Er ist faktisch "immer" mit der Firma verbunden, wen er eine geeignete Internet-Verbindung nutzen kann. Im Gegensatz zum klassischen VPN nutzt Direct Access aber eine "Split-Tunnel" Konfiguration, d.h. trotz Verbindung zum Intranet der Firma kann ich auch noch im Internet arbeiten und lokale Ressourcen verwenden. Umgekehrt ist der Client natürlich auch aus dem Firmennetzwerk heraus immer zu "erreichen", wenn er eingeschaltet ist. Das macht es natürlich für die Software und Patch-Verteilung einfacher, da nicht erst darauf gewartet werden muss, dass der Anwender ein VPN aufbaut.

Zur Sicherheit kommen hier Zertifikate zum Einsatz, d.h. ehe die ersten Nutzdaten übertragen werden, haben sich die Systeme gegenseitig authentifiziert. Wenn also diese Überprüfung der Zertifikate keine Schwachstellen enthält, dann ist es sehr unwahrscheinlich, dass die Sicherheit gefährdet ist. Wie immer dürfte der PC und der Anwender davor selbst das größere Problem darstellen. Ein Angreifer kann vermutlich nur versuchen, die Bandbreite durch Pakete zu belasten.

Direct Acces mit IPv4 und IPv6

Wer bislang Windows Routing und RAS-Server kannte, der hat sehr oft sich das Leben einfach gemacht und dem Client einfach IP-Adressen aus dem LAN zugewiesen, an dem auch der RRAS-Server angeschlossen war. Der VPN-Zugang war dann eher eine "Bridge". DirectAcces hingegen ist ein echter IPv6-Router und die Clients werden in ein bei der Einrichtung anzugebenen IP-Subnetz angebunden.

Bei Windows 2008 war sogar noch ein internes IPv6-Deployment zumindest auf dem ersten Teilstück erforderlich und wer nur per IPv4 erreichbare Server nutzen wollte, musste sogar noch ein DNS64/NAT64-Gateway aufbauen. Das ist in Windows 20012DA enthalten.

In dem Beispiel gibt es den Client, der über das Internet und den Router/Firewall bei der Firma zum Direct Access Server kommt. Diese Strecke wird in den meisten Fällen noch IPv4 sein. IPv4 dient aber nur als Transportmittel, um IPv6-Pakete in einen HTTPS-Datenstrom zu verstecken, der die Verbindung zwischen dem Client und dem Netzwerk herstellt.

Die IPv6-Adresse des Clients kommt dabei vom Direct Access-Server, der dazu den violetten Bereich verwaltet. Danke IPv6 sollte es hier sicher keine Adressknappheit geben. Der Direct Access-Server hat aber noch einen zweiten Pool, den er später für die Erreichbarkeit von IPv4-Servern im LAN benötigt.

Ein klassischer Verbindungsaufbau einer Software auf dem Client zu einem Server durchläuft folgende Schritte:

• DA verbindet sich
  Der Client baut eine Verbindung per IPHTTP zum DA-Server auf, der nach erfolgter Anmeldung dem Client eine IPv6-Adresse auf das IPHTTP-Interface zuweist. Zudem weiß der Client nun auch, wie er Hosts in internen Domänen aufzulösen hat.
• Eine Clientsoftware sucht Kontakt zum Server
  Das muss zwingend über DNS-Namen gehen. Nur dann kann der Client per DNS den DA-Server fragen. Der DA-Server fragt dann den internen DNS-Server nach einer IPv6-Adresse. Wenn hier eine Antwort kommt, dann geht DA von einer IPv6-Installation aus, und gibt die Adresse einfach weiter. Viel wahrscheinlicher ist aber, dass der Server nur eine IPv4-Adresse hat und der DNS-Server diese dem DA-Server liefert.
• DNS64 setzt um
  Da der DA-Client immer nur mit IPv6-Zielen reden kann, muss der DA-Server die IPv4-Adresse zu einer IPv6-Adresse umsetzen. Er nutzt dazu die IPv6-Adressen seines NAT64-Pool und gibt diese an den Client. Wenn Sie auf dem DAClient einen PING auf den Namen machen und sich die gelieferte IPv6-Adresse anschauen, dann erkennen Sie, dass die IPv4-Adresse am Ende hexadezimal eincodiert ist.
• Client startet TCP-Verbindung
  Die Software auf dem Client, die natürlich "IPv6" unterstützten muss, startet nun eine IP-Verbindung zum Server über die IPv6-Adresse. Diese Paket landet aber beim NAT64-Modul des DA-Servers, der die Zieladresse durch die IPv4-Adresse des Servers ersetzt und auch als Quelladresse die IPv4-Adresse des DA-Servers nutzt.
  Antworten des Server gehen also an die interne IPv4-Adresse des DA-Servers und es ist die Aufgabe von NAT64 diese Pakete wieder in IPv6 umzusetzen und an den Client zu senden.

Vielleicht hilft diese kurze Beschreibung beim Verständnis, wie Direct Access mit IPv4-Zielen im Intranet arbeiten kann.

Direct Access mit IPv6 im Firmen-Lan

Ich habe es im vorherigen Kapitel schon angedeutet, dass die Umsetzung mit DNS64/NAT64 nur erfolgt, wenn das Zielsystem per IPv4 zu erreichen ist. Es soll aber auch schon Firmen geben, die in ihrem internen Netzwerk neben den privaten Adressen (10.x.x.x/172.16.x.x-172.31.x.x und 192.168.x.x) auch parallel schon IPv6 nutzen. Firmen haben mit der Nutzung dieser privaten Adressen selten das Problem, dass Sie zu wenig IP-Adressen haben. Die IPv4-Knappheit beschäftigt die Internet Provider und Carrier viel intensiver. Aber auch als Firma kann ein IPv6-Netzwerk Vorteile bringen.

Insbesondere wen Verbindungen zu anderen Firmen/Partnern aufgebaut werden sollen oder Zukäufe erfolgen. Dann kann es nämlich ganz schnell passieren, dass zwei Firmen überlappende IP-Adressbereiche habe. Wer dann versucht mit doppelten NAT diese Firmen zu koppeln, wird ganz schnell merken, dass RPC und Trusts das z.B. gar nicht mögen und die Namensauflösung auch nicht besonders einfach ist. Eine Anpassung der IP-Adressen einer Firma ist aber auch nicht mal eben gemacht. Hier kann IPv6 dann punkten.

Kommt nun in dieser Umgebung Direct Access zum Einsatz, dann muss nicht mehr mit NAT64 und DNS64 gearbeitet werden, wenn die Zielsystem auch native per IPv6 zu erreichen sind. Das fängt schon damit an, dass der Client nach dem Namen fragt und der DNS-Server einen AAAA-Adresse ausliefert. Dann setzt Direct Access gar nichts mehr um. Das bedeutet dann aber auch, dass die Subnetze von Direct Access in ihrem internen IPv6-Routing aufgenommen werden müssen und der DA-Server ein IPv6-Router ist.

Ohne nun jemand mit IPv6-Erfahrung zu viel vorweg zu nehmen, muss man das IPv6-Client-Subnetz in den IPv6-Routing-Tabellen eintragen. Je nach Umsetzung ihrer internen IPv6-Landschaft kann das auch per "Publishing" durch den DA-Server selbst erfolgen. IPv6 hat hie durchaus eine gewisse Dynamik. Über das "Neighbourhood discovery protocol" (NDP) kann jeder Router seine "Routes" im angeschlossenen Subnetz verkünden. Und das macht auch Direct Access, wie ein ""netsh interface ipv6 show route" anzeigt.

Die Spalte "Publish" zeigt in der 9ten Zeile, dass das Direct Access-Subnetz über diesen Server "erreichbar" ist.