Je me suis fait une petite maquette directaccess sur server 2012. Le but de cette architecture est d'avoir une ferme DirectAccess de serveur 2012 en NLB.
Cette première partie concerne la mise en place d'un seul serveur DirectAccess. La mise en place de la ferme sera effectuée plus tard.
Voici l'architecture
L'ip du DC est 192.168.11.1
L'ip de la PKI (qui fait egalement office de nls) est 192.168.11.20
Enfin le serveur directaccess a l'ip interne 192.168.11.11. En externe, le serveur a les ip 178.22.145.226 et 178.22.145.227.
Il y a un firewall en bridge devant le serveur directaccess.
Le domaine est labda.local.
Maintenant que l'architecture est présentée commençons l'installation du serveur EDGE1.
Un record isatap a ete crée pointant sur 192.168.11.11, et le record isatap a ete supprime de la liste bloquée.
Au passage, pourquoi isatap est un record dns bloqué par defaut? Car si jamais un poste se nomme isatap, il va s'enregistrer dans le DNS est devenir le routeur Isatap du reseau. Cela peut entrainer des attaques de Man-In-The-Middle.
Ensuite passons vraiment a l’installation de directaccess. On commence par installer la feature.
L'url pour IPHTTPS est da35094.cloud1.fr
L'url du NLS est nlsda.labda.local
Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress da35094.cloud1.fr -ClientGPOName "labda.local\DirectAccess Clients GPO" -ServerGPOName "labda.local\DirectAccess Servers GPO" -InternalInterface LAN -InternetInterface INTERNET -NLSURL https://nlsda.labda.local –Force –PassThru
Petite remarque, il va trouver le certificat IPHTTPS correspondant tout seul, comme un grand!
Choisissons la CA a utiliser pour les tunnels IPSec. (merci a Benoît SAUTIERE pour cette joli technique ;) )
$CA = (Get-ChildItem Cert:\\LocalMachine\Root | Where {$_.Subject -like "CN=labda*"})
Set-Daserver -IPSecRootCertificate $CA -PassThru
Vérifions que tout est bien installe avec un get-daserver.
OK, tout est la! Tiens TeredoState : Disabled... On y reviendra plus tard!
Verifions aussi le NLS.
Parfait, passons maintenant a la configuration du client et on supprime le filtrage WMI
Choix du groupe :
Add-DAClient –SecurityGroupNameList “labda.local\GG_DA”
Set-DAClient –OnlyRemoteComputers Disabled
Il ne reste plus qu'a tester sur notre windows 8!!
Premièrement verifions la table NRPT. Netsh na sh eff
Maintenant testons d’accéder a un partage réseau.
OK ca marche!
Bon, en theorie, si je ping dc.labda.local, je resous l'ip isatap! Vérifions
C'est quoi cette ip? C'est pas une isatap... Ca finit par l'ipv4 du contrôleur de domaine... Bon ben ca doit être une ip DNS64... Et donc ça veut dire qu'il fait du NAT64...
Vérifions ce qu'il se passe avec un trace réseau. (Wireshark veut pas s'installer sur Server 2012, on va donc utiliser network Monitor)
On voit bien que la requete relayée par le serveur directaccess ne demande qu'un record IPv4.
De plus, on voit egalemement qu'un ping envoyé par un client directaccess (donc en IPv6) , est relaye par le serveur directaccess en IPv4. Nat64 en action!
Ca me pose un leger probleme. Microsoft a toujours dit que Nat64 et DNS64 étaient des processus gourmands... Cela me parait étrange que maintenant le Nat64 soit pas default s'il n'y a pas d'ipv6 sur l'interface interne du serveur....
Mais moi je suis tetu et je veux mes résolutions en ISATAP! Comment faire... tout simplement ne plus utiliser le seveur UAG en tant que DNS dans la table NRPT, donc plus de Nat64 et de DNS64...
Et maintenant, la table NRPT ressemble a ca :
On voit que 192.168.11.1 est devenu fd06:5990:21b1:7777::c0a8:b01 : c'est l'adresse DNS64
Bon, on va pinger dc.labda.local.
Et voila, c'est bien l'ip Isatap!
Autre point interessant. Si je fais un ipconfig /all, je vois que je suis connecte en IPHTTPS. Ce n'est pas normal, cela devrait etre en Teredo, vu que Teredo est préféré (sous UAG/2008) a IPHTTPS
Regardons l’état de l'interface teredo.
Étrange elle est dans sa configuration par défaut. Si on reprend notre get-daserver du début, on remarque que TeredoState : Disabled. Essayons de l'activer.
set-daserver -TeredoState enabled
On update nos GPO, et après : miracle teredo is working.
Par contre directAccess ne marche plus trop, faut que je creuse pourquoi...
EDIT : IP-HTTPS est desormais prefere car server 2012 peut utiliser une null encryption. Ce qui veut dire que le flux n'est cryptee qu'une seule fois (par ipsec). Cela ameliore donc nettement les performances de IPHTTPS. Bon a savoir!
Et voila c'est fini pour aujourd'hui. Prochaine étape, NLB!
Tweeter Suivre @sbe35094
Aucun commentaire:
Enregistrer un commentaire