Date post: | 05-Apr-2015 |
Category: |
Documents |
Upload: | rudi-franke |
View: | 118 times |
Download: | 9 times |
Microsoft DirectAccess
mit Forefront UAGJörg Riether
Micrsoft DirectAccess - Das VPN der
Zukunft?
DirectAccess•Immer online - kein „VPN“ mehr
nötig
•komplett via GPO´s administrierbar
•Kommunikation läuft über IPv6-over-IPsec
•Externe Win7 Ent/Ult Maschine ist von Corporate aus erreichbar, noch bevor sich ein Benutzer anmeldet
DirectAccess mit Forefront UAG
•NAT64 und DNS64 kommen zum Einsatz
•Kein W2008R2 DC/DNS im Netzwerk nötig, nur die UAG Maschine muss W2008R2 sein. Ohne UAG ist das anders, siehe http://technet.microsoft.com/en-us/library/dd637780(WS.10).aspx
•Native IPv4-Clients können von extern aus via IPv6 erreicht werden.
DirectAccess - mal eben installiert
und alles funktioniert?
Annahme
•Im Unternehmensnetzwerk kommt zum aktuellen Zeitpunkt reines IPv4 zum Einsatz
•DNS Server sind mindestens auf Windows 2003 und dynamische DNS-Aktualisierungen sind zugelassen
Vorbereitungen•DA/UAG W2008R2 Maschine mit
zwei NICs bereitstellen
•interne PKI muss ausgerollt werden
•spezielle Zertifikatsvorlagen müssen erstellt werden
•Zertifikatssperrliste muss konfiguriert und extern wie intern verfügbar gemacht werden
Vorbereitungen (2)•Maschinenzertifikate für DA-Clients
ausrollen
•SSL-Zertifikat für DA/UAG-Server ausrollen
•hochverfügbaren Network Location Server (NLR) bereitstellen (ein IIS mit HTTPS reicht aus)
•SSL-Zertifikat für NLS Server ausrollen
Vorbereitungen (3)• zwei öffentliche IPv4 IP-Adressen auf dem
öffentlichen NIC bereitstellen (Teredo bedingt, um die Art des NAT zu bestimmen, http://www.faqs.org/patents/app/20080240132#ixzz0eqN70TBH)
• ...diese IPv4 IP-Adressen müssen numerisch aufeinander folgend sein (Windows Teredo-Implementations bedingt)
• ...und mussten anfangs auch nach lexikographischen Regeln aufeinander folgend gültig sein (zumindest zur „early adopter“-Zeit)
Vorbereitungen (4)•Die öffentliche NIC muss ein
Gateway besitzen, sollte aber keinen öffentlichen DNS Server eingetragen haben (DNS64 Konflikt, http://technet.microsoft.com/en-us/library/dd857262.aspx)
•Etwaige interne Routen müssen ergo manuell via ,route -p add ...‘ oder ,netsh inerface ipv4 add route..‘ hinzugefügt werden.
Ein paar Dinge im Detail
PKI
•eine erreichbare Zertifikatssperrliste ist ein K.O.-Kriterium für DA und muss sauber konfiguriert sein (http://technet.microsoft.com/en-us/library/ee649168(WS.10).aspx)
•Spezielle Vorlagen für DA-Clients und SSL-Server müssen angelegt werden (http://technet.microsoft.com/en-us/library/ee649249(WS.10).aspx)
NLS•Der Network Location Server ist ein
Instrument des DA-Clients. Der DA-Client versucht, den NLS zu erreichen um zu testen, ob er sich intern oder extern von Corporate befindet. Der NLS muss einfach nur eine Website aktiviert haben (Inhalt völlig egal) und ein von der CA vertrautes SSL Zertifikat besitzen.
All diese Schritte müssen komplett
erledigt sein.
Erst dann hat es Sinn, den UAG-DA
Assistenten überhaupt
auszuführen.
Es geht los.
“Aha, wir möchten also gemäß Anleitung jetzt mal eben ISATAP aus
der globalen DNS-Sperrliste entfernen und
einen A-Eintrag erstellen?”(http://technet.microsoft.com/en-us/library/ee649158(WS.10).aspx)
Und was hat das für Konsequenzen
für unser Netzwerk?
Jeder Vista, Windows 7 und Windows 2008
Rechner im gesamten Netzwerk fährt seine
virtuellen ISATAP Interfaces hoch und
benutzt sie auch, wenn er kann.
“...naja, das muss ja nichts bedeuten.”
Pingen wir doch mal irgendeinen (IPv4)
Rechner…
...na also, alles ganz normal. Oder etwa doch
nicht?
Na dann pingen wir mal einen anderen IPv4 Rechner. Diesmal zufällig einen, wo Windows Vista, Windows 7 oder Windows 2008 installiert ist.
oh.
...war das etwa gerade IPv6-ISATAP-
Kommunikation? Das sah aber bis vor einer Minute noch ganz anders aus!
“Ach, das ist sicher nichts. Das muss sicher
irgendwas mit dieser lokalen Auto-
Konfiguration zu tun haben…..”
oh.
“Na ja. Macht ja nichts weiter. Meine Vista,
Windows 7, Windows 2008 Systeme
kommunizieren ab jetzt eben untereinander
über IPv6.”
Ist doch super!
Das war ja einfach.
Oder etwa doch nicht?
“Warum funktionieren auf einmal einige
Programme im Netzwerk nicht mehr? Spontan fällt uns hier Ontrack Powercontrols
auf.”
“Die werden doch sicher so schlau
sein, IPv4 zu benutzen, wenn sie mit IPv6 noch
nicht klarkommen?!”
“Und wenn ich nach nur einem Tag schon
einen Fall im Testlabor bemerke,
wie viele sind es dann in meinem ganzen
Netzwerk?”
Fragen wir doch mal den Hersteller....
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/
thread/fc13f4b7-80fc-476c-8e99-22ced474102a
Yaniv Naor, Microsoft, 10. Januar 2010
„Hi,Legally we are not allowed to
explicitly publish which applications are compatible
and which are not.
As to Microsoft products, I know that
Office Communication Server doesn't work with IPv6“
Aha. Und nun?
ISATAP
•muss nicht zwangsläufig über DNS aktiviert werden
•Der entsprechende Testlabor-Client für ISATAP muss lediglich den Host „ISATAP“ irgendwie auflösen können, völlig egal, wie. Dies kann auch über einen einfachen hosts Eintrag passieren.
Sie wollen aber ISATAP unbedingt im DNS
haben?•Man kann ISATAP pro Rechner
selektiv deaktiveren. „netsh interface isatap set state disbabled“ deaktiviert ISATAP auf dem entsprechenden Rechner, auch, wenn ISATAP via DNS, WINS oder hosts aufgelöst werden kann.
„....das will ich aber nicht bei allen
meinen Clients machen müssen!“
Beispiel Powercontrols
•Es reicht aus, auf dem Windows 2008 Server, ISATAP zu deaktivieren. Ab dann werden auch ISATAP-aktivierte Clients automatisch in IPv4 zurück gezwungen, wenn Sie versuchen mit dem Server zu sprechen.
MUSS ich ISATAP im Netzwerk
zwingend aktivieren, wenn ich DirectAccess
mit UAG benutzen möchte?
Nein.
•Dank UAG´s NAT64 und DNS64 müssen Sie das nicht unbedingt. Behalten Sie aber die Performance bei hohen DA-Clientzahlen im Auge. Das sagt Microsoft. Ich selbst habe dazu keine Erfahrungswerte
•Es gibt aber zu diesem Thema einen Thread von mir: http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/94863ffa-7880-4552-a32a-1b89435ec39f
Empfehlung für die ersten Versuche mit
DA•Legen Sie ganz am Anfang noch keinen
A Eintrag für ISATAP in Ihrem AD-DNS an.
•Fangen Sie klein an. Aktvieren Sie nur auf den Rechnern, welche Sie zum Testen aktiv nutzen wollen einen ISATAP-Eintrag in der lokalen hosts Datei.
...na dann weiter mit dem
DirectAccess Assistenten...
Ein DA-Client nimmt Verbindung
auf...
DA-Client (Windows 7 Enterprise &
Ultimate)startet irgendwo
extern, hinter einem NAT-Router.
Der UAG/DA Client geht diese Schritte:
1. Bin ich etwa intern? Prüfe via NLS.
2. Nein? Schön, dann bin ich extern.
3. direkt im Internet / kein NAT: nutze 6to4
4. hinter NAT und UDP geht: nutze Teredo
5. hinter NAT, aber UDP blockiert: nutze HTTPS-Tunnel über reines TCP-443
Der erste IPsec Tunnel wird bereits vor der
Benutzeranmeldung etabliert.
DA-ClientDA-Client
Tunnel 1: DA-ClientTunnel 1: DA-Client
UAGUAG
Auth: Computerzertifikat + ComputeraccountGPOs, Patches, komplettes Client-Management
Benutzeranmeldung...
Der externe DA-Client macht einen
Ping auf einen IPv4-Host im
Corpnet.
...zu kryptisch?- nein, eigentlich gar
nicht!
c2=194, 19=25, 74=116, 8d=141...macht zusammen:
194.25.116.141
8001= NAT64/DNS64 ist am Werk
ac=172, 10=16, 64=100, 01=1...macht zusammen:
172.16.100.1
Direkt vom UAG Team-Blog
Ping auf einen ISATAP-Host
(Vista, Win7 oder W2008)
ISATAP ist am Werk.Kein NAT64/DNS64 notwendig.
DNS
Name Resoltion Policy Table (NRPT)•Feature von Win7 / 2008
•DNS-Server-Policies werden ermöglicht (Welcher DNS-Server ist bei Anfrage X zu befragen und welcher bei Anfrage Y)
NRPT•kann Anfragen beispielsweise
an zsphaina.msft an den UAG-DNS, alle anderen Anfragen aber an den DNS des Clients übergeben.
•kann Ausnahmen zulassen (NLS)
NLS
...leiten wir doch mal eine 6to4-IPv6-Adresse aus einer IPv4-Adresse
ab.
Wenn das hier...
..Ihre IPv4 Adresse ist..
..so ist das hier (in 6to4 Notation)...
..Ihre IPv6 Adresse!
Konnektivität
Wie sehe ich aktive
Verbindungen auf dem UAG Server?
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/f08439c6-5ada-
4ad0-9de8-f19f6c98aa84
Windows Advanced Firewall GUI auf dem UAG
Server
,netsh advfirewall monitor show
mmsa‘ auf dem UAG-Server
,netsh advfirewall monitor show
mmsa‘ auf dem DA-Client
Stolpersteine
HTTP/S Interface auf dem UAG kann
nicht starten. Timeout.
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/e2589ac4-e225-
422a-a822-3d4975323199
Lösung: Server neu installieren.
Oh Ja. Natürlich. Nicht nur UAG.
Der ganze Server bitte einmal neu.
Externe DA Clients vom Corpnet aus verwalten. RDP,
Antivirus, AD, alles gut. Aber ich kann
keine c$ shares verbinden.
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/
thread/a237fdab-887a-42c3-a7bf-b6c4d10c8442
Viele Roadwarriors, welche über WWAN
reinkommen, bekommen keinen
DirectAccess Aufbau zustande.
Warum das?
http://social.technet.microsoft.com/
Forums/en/windowsserver2008r2networking/thread/e036afe6-bf91-4bba-9d6f-
acea7fcf8436
Der DA-Client sieht sich direkt im Internet, kein
NAT, schaltet also direkt auf 6to4.
Prüft aber nicht, ob 6to4 eventuell blockiert wird.
Microsoft sagt dazu:
“The 6to4 protocol provides no way of discovering if it is blocked on a network: the interface comes online whenever a global IPv4 address is present. “
Viele WWAN Provider lassen
aber 6to4 Verkehr nicht zu. Und nun?
6to4 via GPO deaktivieren.
Oder selektiv mit ,netsh interface
6to4 set state disabled‘.
Performance
•Verglichen mit einer direkten PPTP Verbindung (auf einen Astaro 625 Cluster) ist eine direkte Teredo wie auch IP-HTTPS Verbindung zu DirectAccess bei einem SMB-Transfer ca. 40% langsamer. Dies muss natürlich nicht überall so sein. Aber bei uns ist es so.
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/94863ffa-7880-4552-
a32a-1b89435ec39f
Performance
•Am UAG Server wird es kaum liegen (DELL R710, 15K-SAS-Platten, Raid 10, 16 Gig, Dual XEON 5520, auf dem Server läuft nur UAG, sonst nichts)
Sie wollen nur mit IP-HTTPS arbeiten und haben gerade eine Idee, etwaige
Performance betreffend?
...Sie denken daran, dass wir ja HTTPS
haben und theoretisch IPsec
deaktivieren könnten?
Durchaus machbar. Nicht via Assistent aber via
GPO (Windows Firewall mit erweiterter Sicherheit)
In diesem Fall würde die Authentifizierung
nach wie vor über IPsec laufen, die
Verschlüsselung im Tunnel aber nicht
mehr.
Aber...•Vergessen Sie diesen Tweak
auf keinen Fall jemals.
•Sollte in Zukunft jemand beispielsweise 6to4 aktivieren, würde ALLES unverschlüsselt über das Netz gehen.
Wir haben solch einen Tweak nicht
ausprobiert und können ergo auch
keine Benchmarkangaben
machen.
Die Idee an sich stammt ebenso wenig
von uns - John Craddock hat diese Möglichkeit auf der
TechEd Europe geäußert.
Unser Fazit
UAG mit DA ist sowohl für die IT als auch für die
Benutzer ein kleiner Segen.
Der Implementationsaufwand
darf aber keinesfalls unterschätzt werden.
Danke.
Ich verspreche, ich verlasse die
folgende Abendveranstaltung erst, wenn ich ALLE Fragen beantwortet
habe.
PS – sehr wichtige Links
• Deep dive into UAG DirectAccess (Tweaking the GPOs) http://blogs.technet.com/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx
• When Good Network Location Servers Go Bad – Preparing Against NLS Failure http://blogs.technet.com/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx
• Designing a DNS Infrastructure for Forefront UAG DirectAccess http://technet.microsoft.com/en-us/library/ee428856.aspx
• Designing Your Intranet for Corporate Connectivity Detection http://technet.microsoft.com/en-us/library/ee809088.aspx
• Network Location Awareness http://technet.microsoft.com/en-us/library/cc753545(WS.10).aspx