1.1 Présentation et Avantages
DirectAccess permet de se connecter à distance au réseau de son entreprise. Cependant cela diffère d’une connexion VPN puisqu’il n’y a pas besoin d’établir une connexion dans le gestionnaire de connexion. Une fois connecté l’utilisateur accède au réseau comme s’il était à son entreprise.Grâce à DirectAccess, il est possible de manager facilement le parc d’ordinateurs d’une entreprise puisque les mises à jour des GPO ou les mises à jour software par exemple, se feront indépendamment de la connexion ou non d’un utilisateur. L’ordinateur client est donc constamment à jour avec les normes de sécurité de l’entreprise. L’interconnexion entre les postes se fait donc de façon bilatéral.
IPsec et IPv6 qui sont utilisés pour DirectAccess permettent notamment une encryption des données en utilisant différents algorithmes comme AES ou 3DES. Ainsi les communications restent protégées. Mais il est aussi possible de décider à quelles applications ou quels serveurs auront accès les utilisateurs. Il existe trois types d’accès au réseau :
- Un accès total à la totalité des ressources du réseau. Les données ne sont alors cryptées que lorsqu’elles passent par Internet.
- Un accès sélectif : l’administrateur décide à quel serveur l’utilisateur doit se connecter.
- Un accès limité mais sécurisé de bout en bout par IPsec. Cette méthode nécessite l’implémentation d’IPv6 et d’IPsec dans le réseau de l’entreprise.
Une des forces de DirectAccess est de séparer le trafic intranet et internet à contrario d’une connexion VPN qui fait passer tout le trafic dans la connexion VPN ce qui peut ralentir la connexion mais aussi toutes celle du réseau interne de l’entreprise.
Voici maintenant comment se déroule une connexion client en en tant que client DirectAccess.
Tout d’abord le poste client détecte qu’il est connecté à un réseau. Puis il essaie de se connecter à un site du réseau interne de l’entreprise qui est spécifié lors de la configuration de DirectAccess. Si la connexion a lieu alors le poste client est déjà connecté au réseau interne et la procédure de connexion se stoppe. Sinon l’ordinateur vérifiera s’il est connecté à internet. Ensuite le poste client se connecte au serveur DirectAccess en IPv6 avec IPsec. Si ces solutions sont impossibles alors il sera utilisé des méthodes de transitions telles que 6TO4 ou Teredo. Si un proxy ou un firewall est détecté la connexion se fera alors via IP-HTTPS qui propose une connexion en SSL (Secure Sockets Layer). Une fois la session IPsec établie, le serveur et l’ordinateur s’authentifient mutuellement grâce aux certificats. Enfin le serveur DirectAccess vérifie que l’utilisateur appartient au groupe autorisé à l’utilisation des connexions DirectAccess (dans Active Directory).
Toute ces opérations ont lieu de façon transparente et sans aucune intervention de l’utilisateur.
Petite précision le système d’exploitation client utilisé pour faire du DirectAccess est Windows 7.
1.2 IPv6 et encapsulation
DirectAccess est basé nativement sur le couple IPv6 / IPsec. Bien évidemment, la technologie IPv4 étant encore massivement répandue et IPv6 n’étant pas près de la remplacer avant plusieurs années, des technologies ont été mises au point afin d’encapsuler des paquets IPv6 dans des paquets IPv4.En fonction du type de réseau il est préférable d’utiliser certaines technologies.
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) : elle s’utilise afin de connecter des clients en IPv6 dans un intranet en IPv4. ISATAP se chargera de générer une adresse IPv6 à partir de l’adresse IPv4. Cette adresse IP sera constituée : :0:5EFE:w.x.y.z où w.x.y.z représente l’adresse IPv4 et d’un préfixe situé juste avant qui dépendra de la nature de la connexion. Ce préfixe peut être de trois types : link-local, site-local et global en fonction qu’il s’agisse d’une connexion sur le même sous réseau, dans le même intranet ou sur internet. Cette transition ne peut s’effectuer que dans un réseau interne.
Il existe trois méthodes de transition pour les connections à partir d’Internet.
6TO4 : Cette transition permet de connecter des sites et des hôtes en IPv6 dans un réseau internet en IPv4. L’adressage sera constitué ainsi : 2002:WWXX:YYZZ:: ou WWXX:YYZZ correspond à l’adresse IPv4 en hexadécimal.
Dans un réseau 6TO4 il est possible de rencontrer :
- Un hôte 6TO4 : c’est un poste configuré en IPv6 ou IPv4 avec une adresse configurée en 6TO4.
- Un routeur 6TO4 : il permet de transférer le trafic en 6TO4 entre des hôtes en 6TO4 ou un autre routeur en 6TO4 ou même encore un relais 6TO4.
- Un relais 6TO4 : il se comporte comme un routeur à la différence qu’il fait transiter le trafic 6TO4 d’un réseau en IPv4 vers des hôtes dans un réseau nativement en IPv6.
Teredo : 6TO4 requièrent une adresse IPv4 publique au bout du tunnel créé. Ce qui engendre un problème lorsqu’il y a la présence d’un NAT. Aussi le protocole 6TO4 n’est pas forcément implémenté sur les NAT pour des raisons économiques ou alors parce qu’il est impossible de les mettre à jour en ajoutant 6TO4 par exemple. Pour pallier à ce problème Teredo encapsule les paquets IPv6 dans des messages IPv4 UDP.
L’adressage avec Teredo est composé de plusieurs parties :
La première est toujours la même et sur 32bits il s’agit du préfixe : 2001::/32
La seconde contient sur 32 bits l’adresse public IPv4 du serveur Teredo qui a configuré l’adresse.
La troisième partie contient des flags sur 16 bits. Puis on retrouve sur 16 bits le numéro du port UDP qui a été assigné au client par le NAT. Enfin sur 32 bits il y a l’adresse publique IPv4 du NAT (Sur les deux dernières parties tous les bits sont inversés).
Dans une infrastructure utilisant Teredo, il est possible de rencontrer :
- Un client Teredo qui possède un accès internet au travers d’un NAT en IPv4.
- Un serveur Teredo qui se chargera seulement de la configuration initial du tunnel Teredo.
- Un relais Teredo : il permet de transférer les paquets d’un réseau IPv4 vers le réseau IPv6.
- Un relais pour hôtes spécifiques Teredo : il peut connecter directement des réseaux IPv4 encapsulant de l’IPv6 et des réseaux IPv6 au réseau internet IPv4 sans passer par un relais Teredo. La connexion vers le réseau IPv4 peut se faire vers une adresse IPv4 publique ou privée (derrière un NAT).
IP-HTTPS : C’est un nouveau protocole pour Windows 7 et Windows Server 2008 R2. Elle est utilisée lorsque les machines sont connectées dans des réseaux qui ne laissent passer que le HTTPS (par exemple derrière un firewall ou un proxy). Les paquets IPv6 sont encapsulés dans une session HTTPS en IPv4. Cependant les performances sont légèrement inférieures que lors de l’utilisation d’une autre méthode d’encapsulation. Attention : afin de résoudre les problèmes de connectivité avec ce protocole, il est nécessaire de créer une règle dans le firewall pour laisser le serveur IP-HTTPS répondre aux messages Echo Request.
Teredo est IP-HTTPS ne seront utilisés que si ISATAP et 6TO4 ne sont pas utilisables.
Toutes ces méthodes de transmission sont chargées de faire du tunneling automatiquement.
2.1 L’infrastructure
Ci-dessous, l’architecture qui sera utilisée au cours de la suite de l’article. C’est l’architecture minimale pour utiliser DirectAccess.
Ainsi, elle est composée de plusieurs parties :
Il y a un contrôleur de domaine (DC), il aura les rôles de serveur DHCP et DNS et s’occupera de la gestion des certificats.
Nous retrouvons aussi un serveur DirectAccess et un serveur applicatif qui servira également de serveur NLS (Network Location Server) et qui montrera que l’on a accès au réseau interne.
Le serveur NLS est un serveur Web qui va héberger une URL de localisation accessible via HTTPS seulement depuis l’intranet de l’entreprise.
Ces trois premiers serveurs sont situés dans le même réseau « lab.supinfo.com ».
Enfin, un serveur simulera internet avec les rôles DNS, DHCP et server Web. En outre, un client sera configuré en tant que client DirectAccess.
Le client sera connecté de deux façons. Soit directement connecté au serveur qui simulera internet. On emploiera alors la transition 6TO4. Soit connecté derrière un routeur. Il sera alors utilisé les méthodes Teredo ou IP-HTTPS.
Tous les serveurs sont sous Windows Server 2008 R2 et le client est sous Windows 7 Ultimate.
Le serveur DirectAccess possédera deux cartes réseaux.
2.2 Configuration du contrôleur de domaine
Préambule :Certains paramètres comme les IP sont à adapter en fonction de l’infrastructure, ici ils suivent la maquette présentée plus haut. Toutes les étapes ne sont pas forcément détaillées lorsqu’il s’agit de configuration basique.
Configuration basique :
Tout d’abord, nous allons configurer dans les paramètres IPv4 de la connexion réseau l’adresse IP : 10.0.0.1 et le masque par défaut : 255.255.255.0. Puis, il faut ajouter le suffixe DNS souhaité à la connexion dans l’onglet DNS des paramètres avancés. Enfin, il est approprié de renommer le serveur.
Ensuite, nous devons créer le domaine avec dcpromo.exe avec un niveau fonctionnel de forêt Windows Server 2008 R2, le reste des paramètres reste par défaut.
Le rôle de serveur DHCP doit être ajouté. Tous les paramètres sont laissés par défaut, nous allons seulement désactiver le mode DHCPv6 et configurer une étendue DHCP (par exemple de 10.0.0.20 à 10.0.0.40 pour la configuration de tests utilisée ici).
Toujours avec les paramètres par défaut et seulement en autorisant les mises à jour dynamiques sécurisées ou non, une zone de recherche directe doit être conçu à partir du panneau de configuration du serveur DNS. Puis, deux enregistrements de type A seront ajoutés. Un qui sera lié au serveur DirectAccess et un autre pour le serveur applicatif.
Un nouveau groupe global de sécurité doit être créé afin d’appliquer les paramètres liés aux clients DirectAccess.
Afin de tester notre infrastructure il convient de ne pas oublier de rajouter un utilisateur.
La gestion des certificats :
Ici, le service de certificats Active Directory doit être adjoint afin de sécuriser les données qui vont transférer au travers d’Internet. Les certificats sont les premières choses que les clients DirectAccess vont récupérer.
Le rôle est ajouté en suivant les paramètres par défaut.
Nous allons maintenant configurer un nouveau modèle de certificats afin de pouvoir exporter les clés privées. Pour cela il convient de créer une MMC avec le composant enfichable « Modèle de certificats ». Il est nécessaire de dupliquer le modèle « Serveur Web » en choisissant comme version « Windows Server 2008, Edition Entreprise ».
Il suffit ensuite de nommer ce nouveau modèle. Puis d’inscrire dans l’onglet « sécurité » les ordinateurs du domaine et les utilisateurs authentifiés.
Il ne faut pas oublier d’autoriser l’exportation de clés privées dans l’onglet « Traitement de la demande ».
Enfin, dans « Autorité de certification » dans les outils d’administration, le modèle qui vient d’être créé doit être inséré en passant par « modèle de certificats » puis « nouveau modèle de certificats à délivrer ».
Il s’agit maintenant de pouvoir vérifier la validité d’un certificat sur internet, où que l’on soit connecté.
Il va falloir ajouter deux extensions.
Dans « autorité de certification », nous devons configurer les propriétés du serveur. Dans l’onglet « extension », il faut choisir d’en ajouter une nouvelle du type : http://crl.supinfo.com/crld/ dans lequel crl.supinfo.com est l’adresse du serveur DirectAccess. Il est nécessaire d’insérer ces trois variables :
http://crl.supinfo.com/crld/
Après avoir validé, nous allons cocher ces deux options :
Tandis que la première extension va permettre de rendre accessible vers l’extérieur les CRL (listes de révocations des certificats), la seconde permettra de les publier sur un partage. Pour rappel, une CRL est une liste qui met en évidence les certificats qui sont considérés comme invalides ; par exemple pour quelqu’un ayant quitté l’entreprise. Lorsqu’un certificat est révoqué, une nouvelle liste est créée ou une CRL Delta. Cette dernière est une petite liste qui va énumérer les derniers certificats révoqués depuis la dernière liste de révocation.
Il suffit d’en ajouter une deuxième, qui cette fois sera du type : \\da\crldist$\
En revanche, les options à cocher sont ici : « Publier les listes de révocations des certificats à cet emplacement » et « Publier les listes de révocations des certificats différentielles à cet emplacement ».
Dernière étape sur les certificats pour le contrôleur de domaine : il va falloir éditer la « Default Domain Policy » afin qu’elle gère les certificats.
Il suffit d’aller dans : Configuration d’ordinateur => Stratégies => Paramètres Windows => Stratégies de clé publique => Paramètres de demande automatique de certificat et de faire « Nouveau ». Il faut choisir ensuite le modèle Ordinateur.
Configuration réseau avancée :
Il reste maintenant deux étapes dans la configuration du contrôleur de domaine.
Il est approprié de configurer le pare-feu afin d’autoriser les messages ICMP Echo Requests. C’est important si l’on souhaite utiliser le mode d’encapsulation Teredo.
Une fois de plus il faut éditer la « Default Domain Policy » :
Configuration d’ordinateur => Stratégies => Paramètres Windows => Pare-feu Windows avec Fonctions Avancées.
Quatre règles sont créées, deux règles entrantes et deux règles sortantes. Dans chaque type de règles, nous devons en créer une avec comme protocole ICMPv4 et une autre avec ICMPv6.
Chacune des règles autorisera les paquets ICMP Echo Requests et la connexion.
Le serveur DirectAccess va être enregistré dans le serveur DNS comme hôte ISATAP. Cet enregistrement permettra à la fonctionnalité ISATAP d’attribuer automatiquement une adresse IPv6 aux postes clients. Pour que cela fonctionne il va falloir supprimer ISATAP de la « global query block list ». Cette liste bloque par défaut les fonctionnalités WPAD et ISATAP qui ne sont pas utilisées afin d’éviter tout risque de sécurité.
Afin de reconfigurer cette liste, il est nécessaire d’ouvrir une invite de commande et de taper :
dnscmd /config /globalqueryblocklist wpad
2.3 Configuration du serveur DirectAccess
Préambule :Ici, il ne s’agit pas de configurer totalement le serveur mais simplement toutes les fonctions de base comme le point de distribution des certificats car celui-ci sera nécessaire pour tous les clients DirectAccess, y compris le serveur applicatif. La configuration à proprement parler de DirectAccess aura lieu plus tard.
Configuration basique :
Pour commencer, il est nécessaire configurer les deux cartes réseaux. La première qui concerne le réseau interne et la seconde qui donnera sur l’extérieur (internet). En reprenant le schéma on obtient la configuration suivante.
Il ne faut pas oublier de rajouter le suffixe DNS et l’adresse du serveur DNS.
Puis la seconde carte réseau va être configurée avec les adresses définies dans le schéma. Il est indispensable d’avoir deux adresses IP consécutives afin d’utiliser DirectAccess.
Avec un suffixe DNS qui lui est propre.
Enfin, le serveur doit rejoindre le domaine et l’on est obligé de changer son nom. Cela s’effectue dans les propriétés système.
Il est important aussi d’installer le rôle Serveur Web (IIS) avec les paramètres par défaut.
La gestion des certificats (suite) :
Précédemment lors de la configuration du contrôleur de domaine, des chemins d’accès pour la distribution des certificats avaient été générés, il va maintenant falloir créer ce point de distribution.
Il faut donc ouvrir le gestionnaire des services internet IIS dans les outils administratifs. Dans le dossier Sites, un répertoire virtuel doit être ajouté en passant par le menu « afficher les répertoires virtuels ». Puis il suffit de choisir l’alias souhaité et de sélectionner le dossier à partager. Ici, il s’agit de CRLDist car c’est le nom qui a été configuré précédemment sur le contrôleur de domaine.
Une fois le répertoire virtuel créé, nous devons autoriser la possibilité de l’explorer en cliquant sur activer dans « exploration de répertoire ».
Ensuite, il est nécessaire de partager ce dossier (attention à reprendre le nom utilisé précédemment dans le contrôleur de domaine : « CRLDist$ ») dans les options de partage du dossier. Enfin, nous sommes obligés de configurer les permissions dans l’onglet de partage et dans l’onglet de sécurité afin de donner à l’ordinateur DC (le contrôleur de domaine), le contrôle total afin qu’il puisse déposer les listes de révocation.
Dernière étape sur la configuration des certificats, nous allons publier la CRL. Pour cela, il faut sur le contrôleur de domaine dans l’outil : « Autorité de certification » effectuer la publication via « Certificats révoqués ».
Pour vérifier le bon fonctionnement, il convient d’accéder au partage. L’arborescence obtenue doit être la suivante :
Configuration avancée :
Maintenant, le serveur doit effectuer une demande de certificat, cela permettra ainsi de tester la récupération de certificats.
Pour cela une nouvelle MMC doit être créée avec le composant enfichable « Certificats », puis il faut logiquement choisir : un compte d’ordinateur => ordinateur local puisque l’on effectue une demande pour cet ordinateur.
Puis il suffit d’effectuer une demande de certificat dans le dossier « Personnel » et de choisir le modèle qui a été créée précédemment sur le contrôleur de domaine.
Il est demandé des informations complémentaires, il suffit d’adjoindre un type nom commun pour le nom du sujet et dans autre nom, un type DNS. La valeur est identique pour les deux champs, il s’agit de celle entrée plus tôt dans les enregistrements de type A et correspondant au serveur DirectAccess (dans cette infrastructure de test il s’agit de da.supinfo.com).
2.4 Configuration serveur applicatif
Configuration basique :Tout d’abord, nous allons effectuer une configuration IP sur la carte réseau. D’après notre schéma et l’enregistrement de type A effectué précédemment, le serveur aura pour IP : 10.0.0.3 et pour masque : 255.255.255.0.
De plus, il est approprié d’indiquer le suffixe DNS dans les paramètres avancés comme effectué précédemment.
Il ne faut pas oublier de changer le nom du serveur et de lui faire rejoindre le domaine.
Il est nécessaire maintenant de créer un partage de fichier afin de montrer qu’il est possible d’accéder à des ressources du réseau interne. Il suffit de créer un dossier, de mettre un fichier test à l’intérieur et de faire un clic droit (partager => personnes spécifiques) et de cliquer sur partager dans la fenêtre qui s’ouvre.
La dernière chose à effectuer dans cette partie est l’installation du rôle Serveur Web (IIS) avec les paramètres par défaut.
Configuration avancée :
Comme pour le serveur DirectAccess, nous devons aussi effectuer une demande de certificats, la méthode sera donc identique, il suffit simplement de changer le nom commun et le nom de type DNS par ceux correspondants (ici : nls.lab.supinfo.com).
Afin de pouvoir accéder en HTTPS, une liaison doit être créée. Avec IIS Manager, il est indispensable d’ajouter cette liaison via le panneau « action » situé sur le site web par défaut. Enfin, le choix du certificat qui donne l’authentification au serveur est primordial.
Pour savoir quel certificat choisir, on regarde dans les propriétés de celui-ci.
2.5 Configuration serveur simulant internet
Préambule :La première partie de l’architecture, c’est-à-dire le réseau de l’entreprise, est configurée. Pour compléter l’infrastructure de tests, nous ajoutons un serveur qui va simuler internet et auquel va se connecter le poste client. Cela permettra de démontrer qu’il a accès au réseau interne bien qu’étant connecté à un réseau extérieur.
Configuration basique :
Comme pour chaque poste nous allons effectuer une configuration IP et du suffixe DNS :
Nous devons maintenant installer les rôles serveur Web, DNS et DHCP afin que le serveur puisse attribuer des adresses IP au poste clients qui s’y connecte comme un fournisseur d’accès internet.
Nous sommes obligés d’ajouter trois enregistrements de type A. Comme pour le contrôleur de domaine il est approprié de créer ces enregistrements dans une zone de recherche directe. Il y aura deux zones principales : isp.ext.com et supinfo.com. La première concerne l’accès au site web du serveur et la seconde le serveur DirectAccess ainsi que la connaissance de la CRL (Certificate Revocation List).
Le dernier est identique au précédent, seul le nom : « crl » change.
Enfin, il est possible de passer à l’installation du rôle DHCP.
Puis de configurer une nouvelle étendue.
2.6 Configuration poste client
Configuration basique :Pour l’instant, il va simplement falloir le connecter au réseau de l’entreprise. Cela permet aussi de vérifier que le DHCP fonctionne bien.
Il est maintenant nécessaire que le poste client appartienne au domaine. Ensuite, en utilisant Active Directory, nous allons ajouter cet ordinateur en tant que membre du groupe de sécurité qui a été créé lors de la configuration du contrôleur de domaine.
Nous avons aussi la possibilité de vérifier plusieurs choses :
- Que le certificat a bien été récupéré.
- Que l’on a accès aux données du réseau comme le partage de fichiers ou les pages web.
2.7 Installation et configuration DirectAccess
Maintenant que l’infrastructure est en place il est temps de passer à l’installation de DirectAccess. DirectAccess étant une fonctionnalité et non pas un rôle, il est obligatoire de passer par « Ajouter des fonctionnalités » dans le gestionnaire de serveur.
Par ailleurs, nous n’oublieront pas d’ajouter les fonctionnalités requises lorsque cela est demandé. Elles concernent la gestion des stratégies de groupe qui est importante, notamment pour le déploiement.
A présent, nous devons lancer « Gestion DirectAccess » dans les Outils d’Administration.
En cliquant sur installation, l’utilitaire donne accès à l’interface de configuration.
L’interface est très simple d’utilisation et tout est vraiment expliqué afin de réaliser sa configuration très facilement étape par étape.
Tout d’abord nous allons ajouter les postes client qui auront accès à cette fonctionnalité. C’est ici que vous allez choisir le groupe de sécurité précédemment créé :
Lors de l’étape 2, les interfaces réseau qui sont attribuées au réseau internet et au réseau interne vont être choisies, puis nous allons sélectionner les certificats.
Il existe le certificat racine (ici : lab-dc-ca) et le certificat qui permettra de sécuriser les données c’est-à-dire celui qui propose l’authentification au serveur (celui qui avait été déjà remarqué précédemment).
Lors de l’étape 3, l’adresse du serveur « Emplacement réseau », autrement dit le serveur NLS (Network Location Server), est demandée.
Puis l’assistant va montrer l’adresse IPv6 liée au contrôleur de domaine (ici : 2002:836b:2:1:0:5efe:10.0.0.1). Il est intéressant de remarquer qu’il s’agit d’une IP, basée sur une transition ISATAP. Il y a un préfixe : 2002:836b:2:1 et un identifiant ISATAP : 0:5efe:10.0.0.1 qui contient l’adresse IPv4.
Ici aucune configuration n’est nécessaire, cette étape permet de référencer les serveurs DNS et les contrôleurs de domaine afin que les bonnes résolutions de noms aient lieu.
L’écran suivant correspond au contrôle de bureau à distance ce qui n’est pas le cas dans notre infrastructure.
L’étape 4 concerne les données auxquels auront accès les clients DirectAccess, plusieurs possibilités existent. Soit il n’y a aucune restrictions, soit l’accès est limité à certains serveurs qui seront sélectionnés ou encore limités mais selon des règles IPsec.
Dans cette infrastructure, les postes clients auront accès à tout en cliquant sur « terminer ».
Nous avons désormais la possibilité d’enregistrer cette configuration et de quitter l’assistant, un message résumant la configuration s’affiche.
Tout de suite lors d’une commande « ipconfig » sur le serveur DirectAccess, nous remarquons plusieurs changements de la configuration réseau.
Des nouvelles cartes sont apparues. En fait il s’agit surtout de blocs concernant l’encapsulation, notamment 6TO4 qui sera principalement utilisé ou encore Teredo et IPHTTPS dans le cas où 6TO4 serait inutilisable. Chaque bloc contient une adresse IPv6 associée. Il est à noter que le quatrième bloc contient l’adresse IPv6 du serveur DirectAccess en interne c’est-à-dire configuré en tant qu’hôte ISATAP.
Lors de la configuration DirectAccess, l’assistant a détecté que les ordinateurs du réseau étaient connectés en IPv4. Il est donc essentiel que tous les serveurs soient configurés en tant qu’hôte ISATAP. Pour cela il est nécessaire de forcer ce changement via la commande suivante :
« sc control iphlpsvc paramchange »
Sur le poste client, une commande « ipconfig » montre qu’une fois les stratégies de groupes mises à jour, le poste client possède sa propre adresse IPv6 configurée en tant qu’hôte ISATAP.
On peut pinger le contrôleur de domaine et constater que les réponses reçues viennent d’une adresse IPv6.
3. Tests
3.1 Depuis Internet
Première partie du test, on connecte le poste client au serveur internet. Tout d’abord nous avons la possibilité de vérifier que l’on a accès au réseau internet via la page web : http://inet.isp.ext.com puis de vérifier l’accès au site du réseau interne avec l’url : « http://app.lab.supinfo.com ».
Enfin la vérification de l’accès au dossier partagé créé est facilement réalisable.
Avec la commande « ipconfig », un certain nombre de modifications ont constatées. Le bloc 6TO4 est actif. Dans cette interface, l’adresse IP de la passerelle est la même que celle du serveur DirectAccess. Le suffixe DNS est pourtant bien celui du réseau internet.
3.2 Depuis le routeur/firewall
Préambule :Afin de simuler un routeur/firewall, nous avons mis en place un poste avec Windows 7. Cet ordinateur contient deux cartes réseau. La première, configurée par le serveur DHCP du serveur internet, la seconde étant configurée pour partager sa connexion internet dans l’onglet partage des propriétés de la carte réseau. Une dernière commande est appliquée afin de désactiver la transition 6TO4 : « netsh interface 6to4 set state state=disabled ». Cela permet de simuler un routeur/firewall en forçant l’utilisation de Teredo et IP-HTTPS.
Teredo :
Puis on connecte le poste client au routeur. Ici aussi, on peut attester que la connexion aux différents sites ou partage de fichiers a bien lieu.
Pour ce qui est de la configuration IP, il est à noter que l’interface Teredo est alors active.
Contrairement aux adresses IP des autres interfaces, celle-ci commence par 2001 au lieu de 2002, cela fait partie du système d’adressage Teredo.
IP-HTTPS :
Afin de vérifier le bon fonctionnement de l’interface IPHTTPS, nous désactiverons Teredo via la commande : « netsh interface teredo set state disabled ».
L’interface Teredo disparaît alors lorsque l’on effectue un « ipconfig » et l’adresse IPv6 du client se trouve donc dans le bloc « iphttps interface ».
NB : Pour réactiver l’interface Teredo nous exécuterons la commande : « netsh interface teredo set state enterpriseclient ».
Conclusion
Il a donc été vu tout au long de cet article que DirectAccess n’était pas qu’une simple connexion VPN. Cette fonctionnalité dispose de nombreux atouts. Bien que devant être utilisée avec de l’IPv6, elle intègre toutes les méthodes de transition IPv6 <-> IPv4 afin de pouvoir être mise en place dans n’importe quelle architecture sans devoir effectuer de changements. Il est vrai que le point le plus difficile à aborder est la gestion des certificats. Mais avec un assistant de configuration très accessible, DirectAccess permet un accès instantané et surtout transparent (sans intervention de l’utilisateur) au réseau de l’entreprise où que l’on soit, tout en permettant d’être à jour avec les normes de sécurité de l’entreprise. Il peut donc être couplé avec NAP (Network Access Protection). Direct Access présente donc de nombreux avantages d’installation mais aussi d’utilisation sans présenter d’inconvénients. Direct Access représente donc plus qu’une alternative aux connexions VPN, il est l’avenir de la connexion à distance en entreprise avec une plus grande sécurité, un déploiement (via les GPO) et un accès simplifiés, sans compter le maintien d’un parc informatique aux normes de l’entreprise malgré la non-présence physique de l’ordinateur dans l’entreprise.
