(0) exportieren Drucken
Alle erweitern
2 von 2 fanden dies hilfreich - Dieses Thema bewerten.

Remotezugriff (DirectAccess, Routing und Remotezugriff): Übersicht

Veröffentlicht: Februar 2012

Letzte Aktualisierung: März 2012

Betrifft: Windows Server 2012

Eine Übersicht über die Remotezugriffstechnologie in Windows Server 2012, neue und geänderte Funktionen und Links zu zusätzlichen Ressourcen.

Der Remotezugriff kombiniert zwei Netzwerkdienste in einer vereinheitlichten Serverrolle in Windows Server 2012:

In Windows Server 2008 R2 wurde DirectAccess eingeführt, ein neues Remotezugriffsfeature, das Verbindungen mit Unternehmensnetzwerkressourcen ohne herkömmliche VPN-Verbindungen (virtuelles privates Netzwerk) ermöglicht. DirectAccess unterstützt nur solche Clients, die Windows 7 Enterprise und Windows 7 Ultimate in einer Domäne ausführen. RRAS (Windows Routing- und RAS-Server) stellt herkömmliche VPN-Konnektivität für Legacyclients, nicht in der Domäne enthaltene Clients und VPN-Clients von Drittanbietern bereit. Darüber hinaus bietet RRAS Standort-zu-Standort-Verbindungen zwischen Servern. RRAS in Windows Server 2008 R2 kann nicht auf demselben Edgeserver wie DirectAccess installiert werden und muss getrennt von DirectAccess bereitgestellt und verwaltet werden.

Windows Server 2012 kombiniert das DirectAccess-Feature und den RRAS-Rollendienst in einer neuen vereinheitlichen Serverrolle. Diese neue Remotezugriffs-Serverrolle ermöglicht die zentrale Verwaltung, Konfiguration und Überwachung sowohl von DirectAccess- als auch von VPN-basierten Remotezugriffsdiensten. Darüber hinaus bietet DirectAccess in Windows Server 2012 mehrere Updates und Verbesserungen im Zusammenhang mit Bereitstellungsblockierungen und vereinfachter Verwaltung.

DirectAccess ist auch in Windows Server 2012 Essentials verfügbar und ermöglicht ebenfalls nahtlose Konnektivität zum Unternehmensnetzwerk von einem beliebigen Remotestandort mit Internetanschluss aus, ohne dass dazu eine VPN (Virtual Private Network)-Verbindung hergestellt werden muss.

Weitere Informationen zu DirectAccess in Windows Server 2012 Essentials finden Sie unter Konfigurieren von DirectAccess in Windows Server 2012 Essentials.

Die neue einheitliche Serverrolle für DirectAccess und RRAS bietet einen zentralen Ort für die Konfiguration und Verwaltung bei der Bereitstellung von Remotezugriffsservern. Windows Server 2012 umfasst folgende Verbesserungen im Vergleich zu DirectAccess und RRAS unter Windows 7.

  • Gleichzeitige Verwendung von DirectAccess und RRAS

  • Einfachere DirectAccess-Bereitstellung

  • PKI-Bereitstellung als Voraussetzung für DirectAccess nicht mehr erforderlich

  • Integrierte NAT64- und DNS64-Unterstützung für den Zugriff auf auf IPv4 beschränkte Ressourcen

  • Unterstützung von DirectAccess-Servern hinter NAT-Geräten

  • Einfachere Netzwerksicherheitsrichtlinie

  • Lastenausgleichsunterstützung

  • Unterstützung mehrerer Domänen

  • NAP-Integration

  • Unterstützung von OTP (Token-basierte Authentifizierung)

  • Automatisierte Unterstützung der Tunnelerzwingung

  • IP-HTTPS-Interoperabilität und -Leistungsverbesserungen

  • Unterstützung von DirectAccess mit ausschließlicher Remoteverwaltung (manage-out) durch Clients

  • Unterstützung mehrerer Standorte

  • Server Core-Unterstützung

  • Windows PowerShell-Unterstützung

  • Benutzerüberwachung

  • Serverbetriebsstatus

  • Diagnose

  • Kontoführung und Berichte

  • Standort-zu-Standort-VPN mit IPsec-Tunnelmodus und IKEv2

Sowohl DirectAccess als auch RRAS bieten Sicherheitsfunktionen, um den Server vor bösartigem eingehenden Datenverkehr zu schützen. Zuvor haben die Einstellungen dieser Sicherheitsfunktionen einen Konflikt miteinander verursacht, wenn beide Dienste auf demselben Server ausgeführt wurden, wobei entweder die Funktionsfähigkeit von DirectAccess oder RRAS beeinträchtigt wurde.

DirectAccess verwendet IPv6 (Internetprotokoll Version 6)-Übergangstechnologien, um Clientverbindungen herzustellen. RRAS verwendet den Internetschlüsselaustausch in der Version 2 (IKEv2) und die Internetprotokollsicherheit (IPsec) und konfiguriert Paketfilter für eingehenden und ausgehenden Datenverkehr, um Pakete, die auf Übergangstechnologien zurückgreifen, auszusortieren. Das hat zur Folge, dass der DirectAccess-Datenverkehr blockiert wird, wenn RRAS installiert ist und der VPN-Zugriff mithilfe von IKEv2 erfolgt.

DirectAccess bietet IPsec-Schutz vor Denial-of-Service-Angriffen (DoSP), um Ressourcen in Unternehmensnetzwerke zu schützen. DoSP unterbindet jeglichen IPv4- und solchen IPv6-Datenverkehr, der nicht durch IPsec geschützt ist. Ausnahmen stellen ICMPv6-Pakete dar. Das Ergebnis ist, dass alle IPv4-Pakete und nicht durch IPsec geschützte IPv6-Pakete, die durch RRAS weitergeleitet werden, blockiert werden, wenn DirectAccess installiert ist.

Die vereinheitlichte Serverrolle für DirectAccess und RRAS unter Windows Server 2012behebt diese Probleme durch eine Änderung der IKEv2-Richtlinien zum Zulassen des Datenverkehrs der IPv6-Übergangstechnologie und durch Änderung von IPsec-DoSP zum Zulassen von VPN-Datenverkehr. Dank dieser Änderungen ist es nun möglich, DirectAccess und RRAS auf demselben Server einzusetzen.

Windows Server 2012 beinhaltet Features, um die Bereitstellung vor allem für kleine und mittelgroße Unternehmen zu erleichtern. Zu diesen neuen Features gehören vereinfachte Voraussetzungen, Wegfall der Notwendigkeit einer vollständigen PKI-Bereitstellung, integrierte Zertifikatbereitstellung und Wegfall der Anforderung für zwei aufeinander folgende öffentliche IPv4-Adressen. Die einzelnen Features werden in den folgenden Abschnitten genauer behandelt.

Administratoren können DirectAccess nun mithilfe eines neuen Assistenten für die ersten Schritte bereitstellen. Dieser Assistent vereinfacht die Konfiguration enorm. Der Assistent für die ersten Schritte hilft dabei, die Komplexität von DirectAccess zu überwinden, und sorgt so für eine automatisierte Einrichtung mithilfe einiger einfacher Schritte. Der Administrator muss nicht mehr über die technischen Details der IPv6-Übergangstechnologien und der NLS (Network Location Server)-Bereitstellung Bescheid wissen.

Eines der größten Bereitstellungshindernisse für DirectAccess unter Windows 7 ist der Bedarf an einer Public Key-Infrastruktur (PKI) für die zertifikatbasierte Server- und Clientauthentifizierung. DirectAccess greift auf IPsec-AuthIP-Richtlinien zur Authentifizierung und Sicherung des Datenverkehrs von mit dem Internet verbundenen Clients zurück. Zur Authentifizierung von Domänenressourcen mithilfe von Kerberos muss der Client zunächst eine Verbindung mit DNS-Servern und Domänencontrollern (DCs) herstellen.

DirectAccess unter Windows 7 ermöglicht diese Verbindung durch die Implementierung zweier Authentifizierungsmethoden in den AuthIP-Richtlinien. Der IPsec-Infrastrukturtunnel wird mithilfe eines Computerzertifikats als erste Authentifizierungsmethode und Benutzer-NTLM als zweite Methode erstellt. Nachdem der Tunnel erstellt wurde und ein DC verfügbar ist, kann der Client ein Kerberos-Token abrufen und einen IPsec-Intranettunnel mithilfe des Computerzertifikats und Kerberos als erste und zweite Authentifizierungsmethode erstellen.

Diese Implementierung setzt voraus, dass dem DirectAccess-Server und allen Clients Computerzertifikate zur gegenseitigen Authentifizierung zur Verfügung gestellt werden. Die Verwaltung einer internen PKI wird von vielen kleinen und mittelständischen Unternehmen als schwer angesehen. Bei DirectAccess unter Windows Server 2012 ist die PKI-Bereitstellung optional, um die Konfiguration und Verwaltung zu erleichtern.

Diese Funktion basiert auf der Implementierung eines HTTPS-basierten Kerberos-Proxys. Clientauthentifizierungsanfragen werden an einen Kerberos-Proxydienst gesendet, der auf dem DirectAccess-Server läuft. Der Kerberos-Proxy sendet anschließend im Auftrag des Clients Kerberos-Anfragen an Domänencontroller.

Der neue Assistent für die ersten Schritte bietet Administratoren eine benutzerfreundliche Möglichkeit zur automatischen Konfiguration dieser Lösung. Bei dieser vereinfachten DirectAccess-Bereitstellung sind Konfigurationsoptionen auf Benutzerebene, beispielsweise Tunnelerzwingung, Netzwerkzugriffsschutz (NAP)-Integration und zweistufige Authentifizierung, nicht verfügbar. Für diese Bereitstellungsmethode ist nur ein IPsec-Tunnel nötig. Darüber hinaus bestehen die folgenden Anforderungen.

  • In der Firewall des DirectAccess-Servers muss der TCP-Port 443 offen sein.

  • Der DirectAccess-Server muss über ein Serverauthentifizierungszertifikat für TLS verfügen, das von einer bei den DirectAccess-Clients vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt wurde. Dabei kann es sich um eine öffentliche Zertifizierungsstelle handeln, für die keine interne PKI-Bereitstellung erforderlich ist. Wenn kein Zertifikat zur Verfügung steht, wird das erforderliche IP-HTTPS- und KDC-Proxyzertifikat automatisch als selbstsigniertes Zertifikat beim DirectAccess-Servereinrichtungsvorgang konfiguriert.

Um den Zugriff auf interne auf IPv4 beschränkte Ressourcen zu ermöglichen, bietet DirectAccess unter Windows Server 2012 systemeigene Unterstützung für ein Gateway für die Protokollübersetzung (NAT64) und Namensauflösung (DNS64), um die IPv6-Kommunikation von einem DirectAccess-Client zu IPv4 für die internen Server zu konvertieren. Auf IPv4 beschränkte Intranetcomputer können keine Verbindungen zu DirectAccess-Clients zur Remoteverwaltung initiieren, da die per NAT64 erstellte Übersetzung für den durch den DirectAccess-Client initiierten Datenverkehr unidirektional ist.

Es bestehen hauptsächlich drei Fälle, in denen IPv6-DirectAccess keinen Vollzugriff auf Unternehmensressourcen im Intranet zulässt.

  • Bei Intranetservern, die nicht vollständig IPv6-kompatibel sind und nur IPv4 unterstützen, etwa Windows Server 2003-Dateiserver

  • Bei Umgebungen, in denen IPv6 im Netzwerk vom Administrator deaktiviert wurde

  • Bei Anwendungen, die auf IPv6-kompatiblen Servern laufen, etwa Windows Server 2008, die selbst jedoch nicht IPv6-kompatibel sind, etwa solche, die Datenverkehr über die IPv6-Schnittstelle nicht entgegennehmen und nicht darauf antworten können

Zum Zugriff auf diese Ressourcen über DirectAccess muss die Protokollübersetzung zwischen dem DirectAccess-Server und den internen auf IPv4 beschränken Ressourcen erfolgen, wobei danach eine Übersetzung für Antworten an DirectAccess-Clients zurück in IPv6 erfolgt. NAT64 empfängt IPv6-Datenverkehr vom Client und wandelt ihn in IPv4-Datenverkehr für das Intranet um. NAT64 kommt zusammen mit DNS64 zum Einsatz. DNS64 fängt DNS-Anfragen von Clients ab und sendet Antworten, nachdem IPv4-Antworten in zugehörige IPv6-Mappings in NAT64 umgewandelt wurden.

noteHinweis
Vor DirectAccess unter Windows Server 2012 kann die Protokollübersetzung für DirectAccess nur durch die Bereitstellung von DirectAccess unter Microsoft Forefront Unified Access Gateway bereitgestellt werden.

Der DirectAccess-Setup-Assistent konfiguriert Protokollübersetzungskomponenten einfach im Hintergrund, ganz ohne administrative Interaktion. Administratoren müssen sich nicht mit Konfigurationsoptionen auseinandersetzen. Der Setup-Assistent aktiviert NAT64 und DNS64 automatisch, wenn der internen Schnittstelle des DirectAccess-Servers eine IPv4-Adresse zugewiesen wird. Zur Unterstützung dieser Funktionalität konfiguriert der Setup-Assistent ein IPv6-Netzwerkpräfix für NAT64. Der Assistent weist das NAT64-Präfix automatisch zu und übernimmt es für alle IPv4-Bereiche im Unternehmen.

Für einen Windows Server 2008 R2-DirectAccess-Server sind zwei Netzwerkschnittstellen mit zwei der externen Schnittstelle zugeordneten aufeinander folgenden IPv4-Adressen erforderlich. Dies ist erforderlich, damit er als Teredo-Server agieren kann. Damit Clients hinter einem NAT-Gerät einen Teredo-Server und die Art des NAT-Geräts erkennen können, sind für den Teredo-Server zwei aufeinander folgende IPv4-Adressen erforderlich.

Diese Anforderung stellt für kleine und mittelständische Unternehmen ein Problem dar, die keinen Zugang zu aufeinander folgende, öffentliche IPv4-Adressen haben. In Zukunft kann sich dies zu einem potenziellen Bereitstellungshindernis entwickeln, da der verfügbare IPv4-Adressbereich zunehmend ausgeschöpft ist. DirectAccess unter Windows Server 2012 bietet die Möglichkeit, den DirectAccess-Server hinter einem NAT-Gerät mit Unterstützung für eine Netzwerkschnittstelle oder mehrere Netzwerkschnittstellen bereitzustellen. Dadurch erübrigt sich die Voraussetzung einer öffentlichen IPv4-Adresse.

Wenn der Remotezugriffsdienste-Setup-Assistent für die ersten Schritte oder der Setup-Assistent für den Remotezugriff ausgeführt wird, überprüft dieser den Status der Netzwerkschnittstellen des Servers und stellt so fest, ob sich der DirectAccess-Server hinter einem NAT-Gerät befindet. Bei dieser Konfiguration wird nur IP over HTTPS (IP-HTTPS) bereitgestellt. Das IP-HTTPS-Protokoll ist eine IPv6-Übergangstechnologie, die einen sicheren IP-Tunnel über eine sichere HTTP-Verbindung ermöglicht.

DirectAccess unter Windows Server 2008 R2 nutzt zwei IPsec-Tunnel, um die Verbindung zum Unternehmensnetzwerk herzustellen. Der DirectAccess-Client benötigt zum Zugriff auf Infrastrukturressourcen wie DNS, DC und Verwaltungsserver den Infrastrukturtunnel. Diese Infrastrukturserver sind alle in der IPsec-Richtlinie für Infrastrukturtunnel als Endpunkte aufgeführt. Anschließend ermöglicht der Intranettunnel den Zugriff auf alle anderen Intranetressourcen im Unternehmen.

Die in der Infrastrukturtunnelrichtlinie aufgeführten Endpunkte müssen regelmäßig aktualisiert werden, damit Infrastrukturänderungen übernommen werden, etwa dann, wenn DNS-Server oder Domänencontroller zum Produktionsnetzwerk hinzugefügt oder daraus entfernt werden. Clients können die Verbindung zur Domäne verlieren, wenn ihre IPsec-Richtlinien nicht aktualisiert werden und die aktuellen Serverendpunkte der Infrastruktur widerspiegeln. Dieser Verbindungsverlust führt dazu, dass sie auch keine Gruppenrichtlinienaktualisierungen mehr empfangen können, um den Fehler zu beheben.

Unter Windows Server 2012 bietet das vereinfachte DirectAccess-Modell eine Möglichkeit, DirectAccess über einen IPsec-Tunnel bereitzustellen, wodurch dieses Problem behoben wird. Jedoch unterstützt das vereinfachte Modell bestimmte Funktionen nicht, die auf die zertifikatbasierte Authentifizierung zurückgreifen. Beispiele hierfür sind die zweistufige Authentifizierung mit Smartcards, Multisite und die NAP-Integration. Unternehmen, die DirectAccess mit vollständigem Funktionsumfang benötigen, müssen auch weiterhin auf das Modell mit zwei Tunneln zurückgreifen.

Wenn das Zwei-Tunnel-Modell für die vollständige Funktionalität erforderlich ist, steht eine zusätzliche Funktion zur Verfügung, die es Administratoren ermöglicht, die Liste mit den durch den Infrastrukturtunnel zugänglich gemachten Servern zu aktualisieren. Neue Domänencontroller und SCCM (System Center Configuration Manager)-Server werden gesucht und zur Liste hinzugefügt. Server, die nicht mehr existieren, werden aus der Liste entfernt, und Einträge für Server mit geänderter IP-Adresse werden aktualisiert.

DirectAccess unter Windows Server 2008 R2 stellt keine vollständige Lösung mit hoher Verfügbarkeit bereit und ist auf Bereitstellungen mit einem Server beschränkt. Für eine begrenzte Hardwareredundanz kann DirectAccess in einem Hyper-V-Failovercluster konfiguriert werden, das für die Hyper-V-Livemigration konfiguriert ist. Es kann jedoch nur jeweils ein Serverknoten online sein.

DirectAccess-Installationen haben sich schnell so weit entwickelt, dass ein einzelner Server nicht mehr genügend Rechenleistung zur Verfügung stellen kann. Damit sich Unternehmen an sich ändernde Auslastungsanforderungen anpassen können, benötigen sie die Flexibilität, schnell und transparent zusätzliche Server bereitstellen zu können. Außerdem muss der Netzwerkadressenserver, der zur internen und externen Erkennung verwendet wird, stets zur Verfügung stehen, damit größere Ausfälle von mit dem Intranet verbundenen DirectAccess-Clients verhindert werden können.

DirectAccess unter Windows Server 2012 behebt diese Probleme durch die integrierte Unterstützung für den Windows-Netzwerklastenausgleich (Network Load Balancing, NLB), um eine hohe Verfügbarkeit und Skalierbarkeit für DirectAccess und RRAS-VPN zu erreichen. Die NLB-Konfiguration kann über die Oberfläche des neuen Bereitstellungsassistenten sehr einfach vorgenommen und automatisiert werden. Das Setup bietet auch integrierte Unterstützung für externe hardwarebasierte Lastenausgleichslösungen von Drittanbietern.

ImportantWichtig
DirectAccess unter Windows Server 2012 bietet mithilfe des Netzwerklastenausgleichs eine grundlegende Failoverlösung für bis zu acht Knoten. Obwohl die Serverauslastung auf alle NLB-Knoten verteilt wird, werden bestehende Verbindungen nicht automatisch anderen Servern zugewiesen, wenn ein Server nicht mehr verfügbar ist.

Mit dem DirectAccess-Setup-Assistenten in Windows Server 2008 R2 kann DirectAccess nur für eine einzelne Domäne konfiguriert werden. Das bedeutet, dass Remoteclients von einer anderen Domäne als der des DirectAccess-Servers den Dienst nicht nutzen können. Zudem können Remoteclients nicht remote über DirectAccess auf Anwendungsserver zugreifen, wenn sich diese in einer anderen Domäne befinden.

Administratoren können zwar die Unterstützung für mehrere Domänen in Windows Server 2008 R2 manuell konfigurieren, die Bereitstellung erfordert jedoch eine manuelle Bearbeitung der DirectAccess-Richtlinien nach dem Setup. DirectAccess unter Windows Server 2012 bietet integrierte Unterstützung mehrerer Domänen, um den Remoteclientzugriff auf Unternehmensressourcen in verschiedenen Domänen zu ermöglichen.

DirectAccess unter Windows Server 2008 R2 hat die Integration des Netzwerkzugriffsschutzes (Network Access Protection, NAP) durch Anforderung eines Integritätszertifikats für die IPsec-Peerauthentifizierung des Intranettunnels unterstützt. Ein Integritätszertifikat ist ein Zertifikat, das die Systemintegritäts-Objektbezeichner (Object Identifier, OID) enthält. Ein NAP-Client kann ein Integritätszertifikat nur von einer Integritätsregistrierungsstelle (Health Registration Authority, HRA) abrufen, wenn er die Systemintegritätsanforderungen des NAP-Integritätsrichtlinienservers erfüllt.

Für die Integration von NAP in DirectAccess unter Windows Server 2008 R2 muss der Administrator die Gruppenrichtlinienobjekte und Richtlinien manuell bearbeiten, die vom DirectAccess-Setup-Assistenten nach der Bereitstellung von DirectAccess erstellt wurden. Mit DirectAccess unter Windows Server 2012 kann eine NAP-Integritätsprüfung direkt über die Setupbenutzeroberfläche konfiguriert werden. Diese Funktion automatisiert die Richtlinien- und GPO-Modifikationen, die zur NAP-Integration benötigt werden. Die NAP-Integritätsprüfung kann über den Remotezugriffs-Setup-Assistenten erzwungen werden.

noteHinweis
Zwar vereinfacht der neue Setup-Assistent die NAP-Integration in DirectAccess, automatisiert jedoch nicht die eigentliche NAP-Bereitstellung. Der Administrator muss die NAP-IPsec-Erzwingung und die HRA-Infrastruktur getrennt konfigurieren.

Viele Organisationen stellen für eine höhere Sicherheit eine zweistufige Authentifizierung mit einem Einmalkennwort (One-Time Password, OTP) bereit und erzwingen dessen Eingabe bei Remotezugriffen. DirectAccess unter Windows Server 2008 R2 hat Unterstützung für die zweistufige Authentifizierung mit Smartcards bereitgestellt, die Integration in OTP-Anbieterlösungen wie RSA SecurID war jedoch nicht möglich. Dies verhinderte die Bereitstellung von DirectAccess in Organisationen, die ein solches Sicherheitsniveau voraussetzten.

DirectAccess unter Windows Server 2012 unterstützt die zweistufige Authentifizierung mit Smartcards oder tokenbasierten OTP-Lösungen. Für dieses Feature ist eine PKI-Bereitstellung erforderlich. Ist diese Option also im DirectAccess-SSetup-Assistenten ausgewählt, wird die Option Computerzertifikate verwenden automatisch aktiviert und erzwungen.

Neben der Unterstützung für die Standardauthentifizierung mithilfe von Smartcards kann DirectAccess die Trusted Platform Module (TPM)-basierten Funktionen virtueller Smartcards in Windows Server 2012 verwenden. Das Trusted Platform Module auf Clientcomputern kann als virtuelle Smartcard für die zweistufige Authentifizierung verwendet werden, wodurch Aufwand und Kosten einer Smartcardbereitstellung entfallen.

Standardmäßig können DirectAccess-Clients gleichzeitig auf das Internet, das Unternehmensintranet und lokale LAN-Ressourcen zugreifen. Da nur Verbindungen zum Unternehmensintranet über die DirectAccess-IPsec-Tunnel gesendet werden, wird das als Konfiguration mit getrennten Tunneln bezeichnet. Getrenntes Tunneln bietet dem Benutzer beim Zugriff auf Internetressourcen optimale Leistung, verzichtet dabei aber nicht auf starke Sicherheit für den Internetdatenverkehr.

Das getrennte Tunneln stellt zwar kein Sicherheitsrisiko dar, in einigen Organisationen wird jedoch zwingend vorausgesetzt, dass der gesamte Datenverkehr zur Überprüfung durch das IDS über einen Unternehmensproxy geleitet wird. Mit Legacy-VPN-Verbindungen besteht für Benutzer die Möglichkeit, eine Brücke für den Datenverkehr zwischen Netzwerken herzustellen, etwa zwischen einem Heimnetzwerk und einem Unternehmensnetzwerk, sodass der Client im Prinzip als Router fungiert. Aus diesem Grund ist es üblich, dass Administratoren getrenntes Tunneln für VPN-Verbindungen deaktivieren und somit den gesamten Netzwerkdatenverkehr über die VPN-Verbindung leiten. Dies führt zu einer verminderten Leistung beim Zugriff auf Internetressourcen, da der gesamte Datenverkehr den VPN-Tunnel durchlaufen und anschließend über einen Proxy in das Internet geleitet werden muss. Darüber hinaus wird bedeutend mehr Bandbreite im Unternehmensnetzwerk beansprucht.

Das wahrgenommene Sicherheitsrisiko bei getrenntem Tunneln besteht in einem DirectAccess-Szenario nicht, da IPsec-Regeln, durch die DirectAccess aktiviert wird, die Authentifizierung durch den Clientendpunkt erfordern. Wenn ein anderer Endpunkt versucht, über den DirectAccess-Client zu kommunizieren, wird dieser nicht als authentifizierte Quelle erkannt, sodass IPsec die Verbindung verhindert. Da jedoch einige Organisationen zwingend voraussetzen, dass jeglicher Datenverkehr zur Überprüfung über den Unternehmensproxyserver geleitet wird, stellt die DirectAccess-Option zur Tunnelerzwingung diese Möglichkeit zur Verfügung.

Die Option zur Tunnelerzwingung wurde in DirectAccess unter Windows Server 2008 R2 bereitgestellt, erforderte jedoch manuelle Schritte zur Aktivierung über die Gruppenrichtlinieneinstellung. DirectAccess unter Windows Server 2012 integriert die Option zur Tunnelerzwingung zur Automatisierung der erforderlichen Einstellungen in den Setup-Assistenten und die Verwaltungsoberfläche. Sollte die Option zur Tunnelerzwingung aktiviert werden, kann der DirectAccess-Client nur das IP-HTTPS-Protokoll für Verbindungen nutzen. Außerdem verwendet er zur Übersetzung von IPv6-Ressourcen, die an den IPv4-Proxyserver gesendet werden, standardmäßig den DirectAccess-Server als NAT64-/DNS64-Server.

In bestimmten Netzwerken können Internetfirewalleinstellungen Clientverbindungen über die IPv6-Übergangstechnologien IP6-zu-IP4 und Teredo verhindern. IP-HTTPS ist eine IPv6-Übergangstechnologie, die mit Windows 7 eingeführt wurde und sicherstellen soll, dass DirectAccess-Clients selbst dann eine Verbindung mit dem Unternehmensnetzwerk herstellen können, wenn alle anderen IPv6-Übergangstechnologien versagen. IP-HTTPS weist einem IPv4-Host eine eindeutige, global routingfähige IPv6-Adresse zu, kapselt die IPv6-Pakete für die Übertragung über einen HTTPS-Tunnel in IPv4 und leitet IPv6-Datenverkehr zwischen dem Host und anderen global routingfähigen IPv6-Knoten weiter.

Windows Server 2012 beinhaltet verschiedene Verbesserungen der Implementierung von IP-HTTPS. Änderungen an der Technologie ermöglichen IP-HTTPS-Clients, Informationen zur Proxykonfiguration abzurufen und sich im Bedarfsfall bei einem HTTP-Proxy zu authentifizieren. Die Anforderung zur Bereitstellung von Clientzertifikaten für sämtliche IP-HTTPS-Clients unter Windows 7 wurde entfernt.

IP-HTTPS erstellt eine SSL/TLS-Verbindung zwischen dem Client und dem Server und leitet den IP-Datenverkehr anschließend über diese Verbindung. Diese Daten werden von IPsec verschlüsselt. Somit erfolgt eine doppelte Verschlüsselung: einmal durch IPsec und anschließend noch einmal durch SSL. Dies führt im Vergleich zu den anderen IPv6-Übergangstechnologien IP6-zu-IP4 und Teredo zu einer schlechten Leistung und damit zu einer negativen Benutzererfahrung und schränkt darüber hinaus die Skalierbarkeit des DirectAccess-Servers ein.

DirectAccess unter Windows Server 2012 beinhaltet mehrere Leistungsverbesserungen für IP-HTTPS. Dadurch wird die Skalierbarkeit erhöht und der Aufwand in Zusammenhang mit dieser Verbindungsmethode reduziert. Diese Verbesserungen setzen sich aus Änderungen beim Stapelsendeverhalten und den Stapelempfangspuffern, weniger Sperrungskonflikten und der Option zur Implementierung von SSL mit NULL-Verschlüsselung zusammen.

IP-HTTPS läuft in einem System- und nicht in einem Benutzerkontext. Dieser Kontext kann zu Verbindungsproblemen führen. Wenn sich ein DirectAccess-Clientcomputer beispielsweise im Netzwerk eines Partnerunternehmens befindet, das einen Proxy für den Internetzugriff nutzt und außerdem keine automatische WPAD-Erkennung verwendet, muss der Benutzer Proxyeinstellungen manuell konfigurieren, um auf das Internet zugreifen zu können. Diese Einstellungen werden in Internet Explorer einzeln pro Benutzer konfiguriert und können daher nicht auf intuitive Art für IP-HTTPS abgerufen werden. Wenn der Proxy außerdem eine Authentifizierung erfordert, gibt der Client Anmeldeinformationen für den Internetzugriff an, IP-HTTPS jedoch stellt die zur DirectAccess-Authentifizierung nötigen Anmeldeinformationen nicht zur Verfügung. In Windows Server 2012 werden diese Probleme durch ein neues Feature behoben. Der Benutzer kann IP-HTTPS so konfigurieren, dass das Protokoll hinter einem nicht mit WPAD konfigurierten Proxy funktioniert. IP-HTTPS fordert die für die Authentifizierung nötigen Proxyanmeldeinformationen an, stellt sie zur Verfügung und leitet sie an den DirectAccess-Server weiter.

Beim Konfigurieren von IP-HTTPS in DirectAccess auf dem Server können Sie ein von einer Zertifizierungsstelle ausgestelltes Zertifikat verwenden oder angeben, dass DirectAccess automatisch ein selbstsigniertes Zertifikat generieren soll.

DirectAccess-Clients stellen immer eine Verbindung mit dem Unternehmensintranet her, wenn eine Internetverbindung verfügbar ist, selbst dann, wenn kein Benutzer angemeldet ist. Das ermöglicht IT-Administratoren die Verwaltung von Remotecomputern zum Patchen und Herstellen der Richtlinientreue außerhalb des Büros. Einige Kunden sehen dies als den hauptsächlichen Vorteil von DirectAccess an und entscheiden sich dafür, ihre bestehende Remotezugriffslösung zur Benutzerkonnektivität beizubehalten, während DirectAccess lediglich für die Remoteverwaltung zum Einsatz kommt.

DirectAccess unter Windows Server 2008 R2 bietet keine automatisierte Methode zum Beschränken der Bereitstellung auf die ausschließliche Remoteverwaltung. Administratoren müssen die vom Setup-Assistenten erstellten Richtlinien manuell bearbeiten. DirectAccess unter Windows Server 2012 bietet Unterstützung für eine Konfiguration mit ausschließlicher Remoteverwaltung (manage-out). Dies erfolgt mithilfe eines Bereitstellungs-Assistenten, der die Erstellung von Richtlinien auf solche Richtlinien beschränkt, die für die Remoteverwaltung von Clientcomputer benötigt werden. In dieser Bereitstellung sind Konfigurationsoptionen auf Benutzerebene, beispielsweise Tunnelerzwingung, NAP-Integration und zweistufige Authentifizierung, nicht verfügbar.

noteHinweis
Die Unterstützung der ausschließlichen Remoteverwaltung erfordert eine ISATAP-Bereitstellung oder Verwaltungsserver mit v6-Adressen.

DirectAccess-Server können an mehreren Standorten bereitgestellt werden, um die Kapazität zu erhöhen und einen effizienteren Zugriff auf die nächstgelegenen Einstiegspunkte für Intranetressourcen zu bieten. Dies funktioniert gut, wenn Clients an ihren jeweiligen Standorten bleiben und sich nicht an verschiedene Standorte innerhalb des Unternehmens begeben müssen. Die Einrichtung von DirectAccess für mehrere Standorte erfordert jedoch gute Planung, wenn Clients zwischen Standorten wechseln, damit gewährleistet ist, dass die Verbindung über die DirectAccess-Server immer über die effizienteste Route erfolgt.

In einer Umgebung mit mehreren Standorten gibt es viele Hürden, die es zu überwinden gilt. So muss zum Beispiel sichergestellt werden, dass der Client den nächstgelegenen IP-HTTPS-Server, Teredo-Server, DNS-Server und Domänencontroller findet. DirectAccess unter Windows Server 2012 bietet eine Lösung, die die Bereitstellung mehrerer DirectAccess-Einstiegspunkte an verschiedenen geografischen Standorten ermöglicht. Darüber hinaus können Clients unabhängig von ihrem physischen Standort effizient auf Ressourcen im Unternehmensnetzwerk zugreifen.

DirectAccess-Server mit Windows Server 2012 können in einer Bereitstellung für mehrere Standorte konfiguriert werden, die Remotebenutzern an geografisch verteilten Standorten das Herstellen einer Verbindung mit dem am nächsten gelegenen Einstiegspunkt ermöglicht. Bei Clientcomputern mit Windows 8 können Einstiegspunkte automatisch zugeordnet oder vom Client manuell ausgewählt werden. Für Clientcomputer mit Windows 7 können Einstiegspunkte statisch zugewiesen werden. Windows 7-Clients können ebenfalls von der automatischen Auswahl des Einstiegspunkts profitieren, falls in der Organisation eine Lösung für den Lastenausgleich des globalen Servers (Global Server Load Balancing, GSLB) eingesetzt wird. Datenverkehr in der Bereitstellung für mehrere Standorte kann mit einem externen globalen Lastenausgleich verteilt und ausgeglichen werden.

Bei Server Core handelt es sich um eine Serverinstallationsoption, die weniger Speicherplatz-, Wartungs- und Verwaltungsbedarf hat und die Angriffsfläche des Betriebssystems reduziert. Das Server Core-System unterstützt keine grafische Benutzeroberfläche, sodass Administratoren Befehlszeilen- oder Remoteverwaltungstools für alle erforderlichen Konfigurationsaufgaben verwenden müssen.

Eine Server Core-Installation unterstützt nur eine bestimmte Teilmenge der Funktionen einer vollständigen Installation von Windows Server. Außerdem bietet sie derzeit keine Unterstützung für das DirectAccess-Feature und keine Serverrolle für den Remotezugriff. Eine Windows Server 2012-Server Core-Installation unterstützt die vereinheitlichte Serverrolle für DirectAccess und RRAS.

Die neue Remotezugriffs-Serverrolle wird von Windows PowerShell in Windows Server 2012 vollständig unterstützt. Sie kann für die Installation, Konfiguration und Überwachung verwendet werden. Die Remotezugriff-Serverrolle kann auch per Remoteserververwaltung konfiguriert werden.

In DirectAccess in Windows Server 2008 R2 fehlt eine vollständige Skripting- und Befehlszeilenschnittstelle für Konfigurationsoptionen. Windows Server 2012 bietet vollständige Windows PowerShell-Unterstützung für Setup, Konfiguration, Verwaltung, Überwachung und Problembehandlung der Remotezugriffs-Serverrolle.

Überwachungs- und Diagnosefunktionen für RRAS-Server und DirectAccess sind in Windows Server 2008 R2 eingeschränkt. Bei DirectAccess umfassen die Überwachungsfunktionen lediglich die einfache Systemüberwachung des DirectAccess-Diensts und dessen Komponenten. Die verfügbaren Überwachungsdaten und -statistiken sind für Administratoren von geringer Bedeutung und Relevanz.

Dank der in Windows Server 2012 eingeführten Benutzer- und Serversystemüberwachung kann der Administrator das Verhalten der DirectAccess-Clients und -Verbindungen nachvollziehen. Mithilfe der Überwachungskonsole können die Auslastung des DirectAccess-Servers, die Benutzeraktivität und der aktuelle Ressourceneinsatz nachverfolgt werden. Der Administrator verwendet diese Informationen zur Identifizierung von potenziell unerwünschtem und unangemessenem Nutzungsverhalten. Darüber hinaus kann in der Überwachungskonsole die Diagnoseablaufverfolgung aktiviert werden.

Benutzerüberwachung

Administratoren von Remotezugriffslösungen müssen nicht nur nachvollziehen können, welche Benutzer verbunden sind, sondern auch, auf welche Ressourcen diese Zugreifen. Sollten sich Benutzer darüber beschweren, dass ein bestimmter Server oder eine bestimmte Dateifreigabe beim Remotezugriff nicht verfügbar ist, hat der Administrator derzeit keine Möglichkeit, zu überprüfen, ob andere Benutzer über die Remotezugriffskonsole erfolgreich auf die Ressource zugreifen können. In der Regel sind deshalb verschiedene Tools und Anwendungen erforderlich, um Probleme wie das, wenn ein bestimmter Benutzer übermäßig Bandbreite in Anspruch nimmt, zu behandeln.

Auf das Dashboard wird über die neue RAS-Server-Verwaltungskonsole zugegriffen, indem im Navigationsbereich die Registerkarte "Dashboard" ausgewählt wird. Auf dem Dashboard sind der allgemeine Betriebsstatus sowie Remoteclientaktivität und -status zu sehen. Darüber hinaus kann sich der Administrator direkt auf dem Dashboard Standardberichte anzeigen lassen.

Das Überwachungsdashboard zeigt eine Zusammenfassung des Remoteclientverbindungsstatus für die folgenden Elemente an. Die Informationen werden anhand der relevanten Systemmonitorzähler- und Kontoführungsdaten generiert.

  • Gesamtanzahl an aktiven verbundenen Remoteclients – einschließlich aller DirectAccess- und VPN-Remoteclients

  • Gesamtanzahl an aktiven verbundenen DirectAccess-Clients – nur die Gesamtanzahl an über DirectAccess verbundenen Clients

  • Gesamtanzahl an aktiven verbundenen VPN-Clients – nur die Gesamtanzahl an über VPN verbundenen Clients

  • Gesamtanzahl an eindeutigen Benutzern – einschließlich aller DirectAccess- und VPN-Benutzer, auf Grundlage der aktiven Verbindungen

  • Gesamtanzahl an kumulativen Sitzungen – die Gesamtanzahl an über den RAS-Server erfolgten Verbindungen seit dem letzten Serverneustart

  • Maximale Anzahl an verbundenen Remoteclients – die maximale Anzahl an gleichzeitig mit dem Remotezugriffsserver verbundenen Remotebenutzern seit dem letzten Serverneustart

  • Gesamtmenge an übertragenen Daten – der gesamte ein- und ausgehende Datenverkehr des Remotezugriffsservers für DirectAccess und VPN seit dem letzten Serverneustart

    1. Eingehender Datenverkehr – Gesamtmenge an Byte/Datenverkehr in Richtung des Remotezugriffsservers/-gateways

    2. Ausgehender Datenverkehr – Gesamtmenge an Byte/Datenverkehr vom Remotezugriffsserver/-gateway

In einer Clusterinstallation werden für die Remoteclientaktivität und die Statuszusammenfassung auf dem Remoteclientdashboard die Gesamtwerte für alle der Clusterknoten angezeigt.

Administratoren erhalten eine Liste aller aktuell verbundenen Remotebenutzer und können darüber hinaus eine Liste aller Ressourcen aufrufen, auf die gerade zugegriffen wird, indem sie auf einen bestimmten Remotebenutzer klicken. Administratoren können sich Remotebenutzerstatistiken anzeigen lassen, indem sie in der Remotezugriffs-Verwaltungskonsole auf den Link zum Remoteclientstatus klicken. Die Benutzerstatistiken können per Kriterienauswahl mithilfe der folgenden Felder gefiltert werden:

 

Feldname

Wert

Benutzername

Der Benutzername oder das Alias des Remotebenutzers. Zur Auswahl von Benutzergruppen können Platzhalter wie "contoso\*" oder "*\administrator" verwendet werden. Falls keine Domäne angegeben ist, wird "*\username" angenommen (bei Kommentar [A5]: Diese Tabelle in das Dokument mit dem Überwachungsszenario verschieben).

Hostname

Der Name des Computerkontos des Remotebenutzers. Alternativ kann eine IPv4- oder IPv6-Adresse verwendet werden.

Typ

Entweder DirectAccess oder VPN. Wenn DirectAccess ausgewählt wird, werden alle Remotebenutzer, die über DirectAccess verbunden sind, aufgeführt. Wenn VPN ausgewählt wird, werden alle Remotebenutzer, die über VPN verbunden sind, aufgeführt.

ISP-Adresse

Die IPv4- oder IPv6-Adresse des Remotebenutzers.

IPv4-Adresse

Die interne IPv4-Adresse des Tunnels, der den Remotebenutzer mit dem Unternehmensnetzwerk verbindet.

IPv6-Adresse

Die interne IPv6-Adresse des Tunnels, der den Remotebenutzer mit dem Unternehmensnetzwerk verbindet.

Protokoll//Tunnel

Die Übergangstechnologie des Remoteclients – Teredo, IP6-zu-IP4 oder IP-HTTPS für DirectAccess-Benutzer, PPTP, L2TP, SSTP oder IKEv2 für VPN-Benutzer

Aufgerufene Ressource

Alle Benutzer, die auf eine bestimmte Unternehmensressource oder einen bestimmten Unternehmensendpunkt zugreifen. Bei dem diesem Feld entsprechenden Wert handelt es sich um den Hostnamen/die IP-Adresse des Servers/Endpunkts.

Server

Der RAS-Server, mit dem Clients verbunden sind. Dies ist nur für Clusterbereitstellungen und Bereitstellungen für mehrere Standorte relevant.

Diese Funktion ermöglicht Administratoren die Verwaltung und Überwachung des Status von Remotezugriffsinstallationen über eine zentrale Überwachungskonsole. Das Feature benachrichtigt Administratoren immer dann, wenn ein Problem festgestellt wird, das Aufmerksamkeit benötigt. Die Benutzeroberfläche stellt ausführliche Diagnoseinformationen und Schritte zur Lösung des Problems zur Verfügung.

Der Dashboard-Knoten der Konsolenstruktur zeigt den Status des RAS-Servers an, einschließlich des Status der Remotezugriffsinfrastruktur und zugehöriger Komponenten, sowie Informationen dazu, ob die Konfiguration ordnungsgemäß auf die Einstiegspunkte verteilt wurde.

Der Serverbetriebsstatus-Knoten der Konsolenstruktur zeigt den Status des RAS-Servers an, einschließlich des Status der Remotezugriffsinfrastruktur und zugehöriger Komponenten. Per Klick auf eine bestimmte Komponente können Administratoren Zustand, Änderungsverlauf und Überwachungsdaten für die jeweilige Komponente sehen.

Wenn Remotezugriffsserver in ein Cluster oder eine Installation mit mehreren Standorten eingebunden werden, werden alle Server im Cluster oder der Installation asynchron ausgewertet und mit ihrem Gesamtstatus dargestellt. Administratoren können in der Serverliste einen Bildlauf durchführen und die Ansicht erweitern und reduzieren, um DirectAccess- und VPN-Serverkomponenten aufzurufen.

Die Remotezugriffskomponenten, für die Statusmonitore im Bereich für den Serverbetriebsstatus angezeigt werden, sind im Folgenden aufgeführt.

  • IP6-zu-IP4

  • Domain Name System

  • DNS64

  • Domänencontroller

  • IP-HTTPS

  • IPsec

  • ISATAP

  • Kerberos

  • Verwaltungsserver

  • NAT64

  • Netzwerkadapter

  • Netzwerkadressenserver

  • Netzwerksicherheit (IPsec-DoSP)

  • Dienste

  • Teredo

  • Lastenausgleich

  • VPN-Adressierung

  • VPN-Konnektivität

Die Problembehandlung bei Remotezugriffs-Konnektivitätsfehlern für RRAS und DirectAccess kann aufgrund der aktuell stark eingeschränkten Protokollierungsfunktionen sehr kompliziert sein. Administratoren fordern in der Regel Momentaufnahmen des Netzwerkmonitors und RRAS-Ablaufverfolgungsinformationen zur Problembehandlung an, da die Protokolle der Ereignisanzeige nicht sehr hilfreich sind.

Windows Server 2012 beinhaltet die folgenden Verbesserungen des Diagnosefeatures für die Remotezugriffsproblembehandlung:

  • Ausführliche Ereignisprotokollierung für DirectAccess

    Administratoren haben nun Zugriff auf eine bessere Ereignisprotokollierung, um Probleme zu identifizieren und Kapazitäts- und Leistungsanalysen durchzuführen. Die Ereignisprotokolle sind standardisiert, damit die Konsistenz mit anderen Netzwerkkomponenten gewährleistet ist.

  • Ablaufverfolgung und Paketerfassung

    Die integrierte Ablaufverfolgung erleichtert es Administratoren, mit nur einem Klick Ablaufprotokolle und Netzwerkpakete zu erfassen. Die Ablaufverfolgung mit Paketerfassung und die Protokollkorrelation werden im Rahmen eines Vorgangs ausgeführt, wenn der Administrator im Aufgabenbereich auf die Aufgabe Ablaufverfolgung starten klickt.

  • Protokollkorrelation

    Diese Funktion bietet über nur einen Klick eine automatisierte Erfassung und Korrelation von Protokollen für verschiedene DirectAccess-Komponenten, wobei die Funktion "Unified Tracing" von Windows zum Einsatz kommt. Die von verschiedenen Komponenten erfassten Ereignisse werden in einer einzelnen Datei per Korrelation der Aktivitäts-IDs konsolidiert. Bei Aktivitäts-IDs handelt es sich um GUIDs, die eine bestimmte Aufgabe oder Aktion bezeichnen. Wenn eine Komponente ein Ereignis erfasst, weist sie diesem eine Aktivitäts-ID zu. Die Komponente leitet anschließend entweder diese ID oder ein Übertragungsereignis, das der ID zugeordnet ist, an die Komponente weiter, die die nächste Aufgabe im Szenario übernimmt, die ihre Aktivitäts-ID Protokollereignissen zuordnet. Über die Analyse der entstandenen Ablaufverfolgungsdatei kann die Beziehung zwischen verschiedenen für ein Szenario relevanten Komponenten rekonstruiert werden.

  • Aktivieren/Aufrufen von Protokollen

    Die Ablaufverfolgung kann über den Aufgabenbereich des Überwachungsdashboards oder eine Befehlszeile aktiviert werden, worüber auch Protokolliergrad, Schlüsselwörter und Filter gesteuert werden können. Die generierten Unified Tracing-ETL-Dateien können mithilfe des Netzwerkmonitors gelesen und aufgerufen werden.

Ein Windows Server 2012-RAS-Server kann eine vorhandene RADIUS-Serverbereitstellung oder eine interne Windows-Datenbank (WID) für die Kontoführung nutzen. Informationen und Verlaufsdaten zu Auslastung und Serverstatus sind über die Systemmonitorzähler verfügbar und werden im WID-Kontoführungsspeicher gespeichert. Immer wenn eine Verbindung zum RAS-Server aufgebaut oder die Verbindung getrennt wird, werden alle Remotebenutzerstatistiken (einschließlich der Endpunkte, auf die zugegriffen wurde) im Kontoführungsspeicher als eine Benutzersitzung gespeichert. So kann später zu Berichts- und Prüfzwecken auf Sitzungsdaten zugegriffen werden.

Mithilfe der in der Remotezugriffs-Serverrolle bereitgestellten Kontoführungs- und Berichtsfunktionen können unter anderem bestimmten Metriken gemessen werden. Verfügbare Metriken: die Anzahl der mit einem bestimmten DirectAccess-Server verbundenen Benutzer und die Gesamtmenge der übertragenen Bytes. Administratoren können benutzerdefinierte Berichte erstellen, um Muster bei Datenverkehr und Nutzung zu bestimmen, einschließlich des Verlaufs dieser Muster.

DirectAccess- und RRAS-Berichtsfunktionen ermöglichen Administratoren, ausführliche Nutzungsberichte für verschiedene Statistiken zu erstellen, etwa Remotebenutzerstatistiken, Serververfügbarkeit und Auslastung. Der Speicher für die Posteingangskontoführung wird zur Erstellung des Nutzungsberichts verwendet. Damit Nutzungsberichte generiert werden können, muss die Posteingangskontoführung zu einer lokalen WID-Datenbank aktiviert werden. Die NPS-/RADIUS-Kontoführung kann nicht zur Erstellung von Berichten verwendet werden.

Der Nutzungsbericht enthält Angaben zum Nutzungsverlauf, etwa welche Benutzer Remoteverbindungen hergestellt haben, auf welche Ressourcen sie zugegriffen haben, die Gesamtanzahl an eindeutigen Benutzern und die größte entstandene Serverauslastung. Der Administrator kann einen bestimmten Zeitraum für den Bericht festlegen, sodass nur entsprechende Daten ausgegeben werden.

Die übergreifende Konnektivität ist ein Windows Server 2012-Feature, das Netzwerkkonnektivität bereitstellt, um Diensthostinganbietern das Migrieren ihrer Anwendungen und Infrastrukturen zur Cloud zu ermöglichen. Die Funktion bringt eine Standort-zu-Standort-IKEv2-VPN-Konnektivitätslösung mit Tunnelmodus und eine dazugehörige Verwaltungsoberfläche mit. In Windows Server 2008 R2 wurde die IKEv2-Unterstützung in RRAS für VPN-Verbindungen eingeführt. Ein IKEv2-VPN erweist sich bei der Umstellung von VPN-Clients von einem Netzwerk auf ein anderes oder von drahtlos auf kabelgebunden als robust. Der Einsatz von IKEv2 und IPsec erlaubt die Unterstützung strenger Authentifizierungs- und Verschlüsselungsmethoden. RRAS unter Windows Server 2012bietet zusätzliche Featureverbesserungen, um IKEv2 für Standort-zu-Standort-VPN-Verbindungen zu aktivieren.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.