Archiv der Kategorie: DirectAccess

Teil 27: Vorbereitung von DirectAccess

Veröffentlicht am von
Antworten

Vorbereitung von DirectAccess: Systeme und Protokolle

Für die Vorbereitung von DirectAccess ist es wichtig, einige wenige Begriffe zu kennen. Im folgenden Abschnitt möchte ich die Konfiguration der Systeme und Protokolle für mein einfaches Netzwerk so kurz wie möglich beschreiben. Nachdem ich alle notwendigen Informationen zusammengetragen habe, werde ich DirectAccess installieren und konfigurieren.

Als Referenz für die Vorbereitung von DirectAccess verwende ich DirectAccess in Windows Server. Für die Kapazitätsplanung hilft DirectAccess Capacity Planning.

IPv6 / IPv4 Übergangstechnologien

  • 6to4: Wird verwendet, wenn der DirectAccess-Client eine öffentliche IPv4-Adresse bezieht. Der Client darf sich nicht hinter einem NAT-Gerät befinden. Das dabei verwendete Protokoll 41 ist häufig durch die Internet Provider blockiert. Ich werde 6to4 nicht verwenden und mittels Gruppenrichtlinie deaktivieren.
  • Teredo: Funktioniert 6to4 nicht, wird der Verbindungsaufbau mittels Teredo versucht. Teredo überprüft zuerst hinter welchem NAT-Gerät sich der DirectAccess-Client befindet, verpackt dann den IPv6-Verkehr und startet die Kommunikation. Teredo verwendet den UDP-Port 3544.
    • Vorteil: Ermöglicht DirectAccess hinter einem NAT-Gerät (Router)
    • Nachteil: zwei öffentliche IP-Adressen am externen Netzwerk-Adapter des DirectAccess-Servers notwendig
  • IP-HTTPS: IPv6-Pakete werden in HTTPS eingekapselt. IP-HTTPS verwendet den TCP-Port 443. Weil der Port 443 (jede https-Webseite) eigentlich überall erlaubt ist, funktioniert IP-HTTPS in den meisten Fällen. Wird das Häkchen bei „Use force tunneling“ aktiviert, wird ausschließlich IP-HTTPS verwendet. In diesem Fall kann 6to4 und Teredo deaktiviert werden.
    • Vorteil: Funktioniert (fast) immer
    • Nachteil: IPsec und HTTPS-Verschlüsselt (nur bei Windows 7) und dadurch etwas langsamer als Teredo, weil die Pakete doppelt ver- und entschlüsselt werden müssen; Verwaltung von Zertifikaten
  • ISATAP: Um aus dem IPv4-Intranet DirectAccess-Clients verwalten zu können, ist ISATAP notwendig. Dafür wird am internen Computer ein ISATAP-Adapter mit einer auf der IPv4-Adresse basierenden IPv6-Adresse erstellt (mehr Informationen später).
    • Vorteil: Zugriff auf die DirectAccess-Clients (z.B. durch den Helpdesk)
    • Nachteil: Konfigurationsaufwand; von Microsoft nicht empfohlen
  • DNS64: DNS64 wird am DirectAccess-Server ausgeführt und löst für die DirectAccess-Clients interne Namen in IPv4-Adressen auf. Dafür verwendet er seine eigene DNS-Konfiguration. Es ist keine Konfiguration notwendig.
  • NAT64: NAT64 übersetzt den Verkehr von öffentlichen IP-Adressen zu privaten und zurück. NAT64 übersetzt den Verkehr von IPv6 zu IPv4 und zurück. Es ist auch für NAT64 keine Konfiguration notwendig.

Verwendete Systeme:

  • Active Directory Domain Services: Es können nur Domänen-Computer DirectAccess-Clients sein. Für die Konfiguration der Clients werden ausschließlich Gruppenrichtlinien verwendet. Für die Zielgruppenfilterung werde ich Sicherheitsgruppen für Server und Clients erstellen. Der DirectAccess-Server kommt in eine eigene OU, damit dieser Server keine anderen Gruppenrichtlinien erhält.
  • Active Directory Certificate Services: Für die Kommunikation mittels IP-HTTPS und für die Webseite des NLS (Network Location Server) sind Zertifikate notwendig. Weil für IP-HTTPS die CRL extern erreichbar und hochverfügbar sein muss, empfiehlt sich ein Zertifikat von einem Drittanbieter, um dessen bestehende Infrastruktur nutzen zu können. Ich werde meine PKI für den NLS und IP-HTTPS verwenden, weil ich keinen „echten“ Internetzugang in der Laborumgebung habe. (Siehe Hosting the Windows Server 2012 Base Configuration Test Lab with Windows Server 2012 Hyper-V)
    Weiterlesen →