Windows 7 et Windows Server 2008 R2

  • Article

BranchCache et DirectAccess : amélioration de l'expérience des succursales

Gary Olsen

Alors que le grand public découvre finalement Windows Server 2008 R2 et Windows 7, quelques élus travaillent avec le code RC (Release Candidate) depuis le mois de mai et avec la version RTM (Release To Manufacturing) depuis le mois d'août. Quel que soit votre cas, vous avez sans doute constaté l'effervescence qui règne dans le monde de l'informatique depuis quelques semaines ou quelques mois. Peut-être même avez-vous été invité à une réunion de présentation de Windows 7, comme moi (mon beau-fils en a organisé une, mais seulement parce qu'une copie du logiciel lui était offerte gracieusement par Microsoft). Même si vous avez réussi à vous tenir à l'écart de toute cette effervescence, vous n'aurez pas pu éviter de remarquer tous les reportages dans les médias louant ou critiquant les nouvelles fonctionnalités de ces produits, tous deux issus d'une nouvelle arborescence de code et constituant de nouveaux systèmes d'exploitation à part entière.

BranchCache et DirectAccess, incontestablement les joyaux de ces versions, sont des fonctionnalités pour le moins dignes d'intérêt. Avec BranchCache, Microsoft souhaite permettre aux employés de succursales de bénéficier de la même expérience d'utilisation de fichiers que leurs homologues travaillant au siège social. Avec DirectAccess, Microsoft cible les utilisateurs distants qui se connectent à des réseaux d'entreprise par le biais de réseaux privés virtuels (VPN, Virtual Private Networks).

Comme c'est souvent le cas avec Microsoft, les fonctionnalités les plus excitantes ne sont disponibles que sur les nouveaux produits. Dans le cas présent, on ne peut implémenter BranchCache que sur les clients Windows 7 et les serveurs Windows Server 2008 R2. Examinons en détail ces nouvelles fonctionnalités.

BranchCache

BranchCache améliore l'expérience de succursale en mettant localement en cache les fichiers couramment utilisés, sur un serveur Windows Server 2008 R2 ou sur des stations de travail utilisateur, plutôt que de contraindre les utilisateurs à accéder aux fichiers par le biais de partages réseau hébergés de manière centralisée. BranchCache est une excellente fonctionnalité, mais il y a toute de même quelques points à souligner.

Il est possible de déployer BranchCache en mode cache distribué ou en mode cache hébergé (voir la Figure 1). On configure le mode par le biais de la Stratégie de groupe ; par conséquent, l'utilisation du mode hébergé dans un bureau et du mode distribué dans un autre bureau nécessite d'implémenter deux stratégies et de planifier les structures d'unités d'organisation en conséquence. Microsoft recommande de déployer le mode cache distribué dans les sites de 50 clients ou moins, mais tout dépend de la vitesse et de la bande passante de la liaison de réseau étendu, ainsi que d'autres facteurs. Le mode cache distribué requiert davantage d'espace disque et éventuellement davantage de mémoire et autres ressources. À un certain stade, il sera donc plus bénéfique d'utiliser le mode cache hébergé, en particulier s'il existe un serveur 2008 R2 sur le site. En outre, le mode cache distribué ne peut fonctionner que sur un sous-réseau local. En conséquence, si un site comporte plusieurs sous-réseaux, un client sur chaque sous-réseau devra mettre en cache le fichier pour que d'autres clients sur ce sous-réseau puissent le télécharger. Le mode cache hébergé, quant à lui, peut desservir plusieurs sous-réseaux du site, ce qui constitue un autre atout en sa faveur.

Figure 1 Une succursale peut utiliser BranchCache en mode distribué ou hébergé.

En mode cache distribué, aucun serveur de fichiers ne réside dans la succursale. Au lieu de cela, grâce à l'application d'une stratégie, tous les ordinateurs des utilisateurs sont des clients BranchCache, c'est-à-dire qu'ils ont tous la possibilité de mettre en cache des documents que d'autres utilisateurs du site de succursale peuvent télécharger (à condition de posséder la version actuelle).

Par exemple, supposons que Caroline demande un document nommé Reports.docx à un serveur de fichiers compatible BranchCache du site central. BranchCache envoie des métadonnées décrivant le contenu du fichier. Des hachages des métadonnées sont ensuite utilisés pour rechercher le contenu sur le sous-réseau local. Si la recherche est infructueuse, une copie est mise en cache sur le disque dur local de Caroline. Plus tard dans la journée, Bruno a besoin de modifier le fichier Report.docx. Il contacte donc le partage sur le serveur de fichiers du siège social afin d'en obtenir une copie et de la modifier. Le serveur de fichiers retourne les métadonnées, puis le client recherche le contenu, qu'il trouve et télécharge à partir de l'ordinateur de Caroline. Cette opération s'effectue de manière sécurisée, à l'aide d'une clé de chiffrement dérivée des hachages dans les métadonnées. Le lendemain, Sandrine doit modifier ce même document. Le processus est identique, mais elle ouvrira la copie mise en cache sur l'ordinateur de Bruno. Là encore, les informations de version sont conservées sur le serveur. Les clients contactent le serveur afin de déterminer s'il existe une copie de la version la plus récente sur leur site.

Il s'agit de l'un des trois scénarios BranchCache applicables lorsque des utilisateurs travaillent sur divers documents. Les deux autres scénarios sont les suivants :

  • Un employé de succursale souhaite obtenir à partir du serveur de fichiers du siège social un document qui n'est mis en cache sur aucun ordinateur local. L'utilisateur reçoit une copie, qui est ensuite mise en cache localement.
  • Un employé de succursale souhaite obtenir à partir du serveur de fichiers un document qui est mis en cache sur le site local, mais l'ordinateur est éteint. Le client obtient une nouvelle copie à partir du serveur de fichiers et il la met en cache sur son PC. Toute demande ultérieure mène à cette copie, qui est la copie en cache la plus récente.

Dans tous les cas, les documents sont également enregistrés sur le serveur de fichiers du siège social. De cette façon, si Caroline revient et souhaite accéder au document mais que l'ordinateur de Sandrine (qui contient désormais la version la plus récente) est éteint, elle obtiendra le document à partir du serveur du siège social.

Avec le mode cache hébergé, on configure un serveur de fichiers Windows 2008 R2 dans la succursale avec BranchCache en installant la fonctionnalité BranchCache et en configurant la Stratégie de groupe de sorte que les clients utilisent le mode cache hébergé. La procédure décrite pour le mode cache distribué est également valable pour le mode hébergé, mais les fichiers sont mis en cache sur un serveur BranchCache configuré localement plutôt que sur les ordinateurs des utilisateurs.

Remarque : les métadonnées de contenu conservées par le serveur de fichiers sur le site du siège social sont envoyées à chaque client lorsqu'un fichier est demandé à partir d'un serveur compatible BranchCache. Elles servent à déterminer si un client ou serveur local (selon le mode cache utilisé) possède la copie la plus récente.

Le serveur compatible BranchCache sur le site de succursale peut servir à d'autres fins, par exemple en tant que serveur Web ou WSUS (Windows Server Update Services). Dans ces cas-là, certaines considérations doivent être prises en compte, comme décrit dans le Guide de déploiement de Microsoft BranchCache et le Guide pour premiers utilisateurs de Microsoft BranchCache.

Configuration de BranchCache

Pour configurer BranchCache, vous devez comprendre le fonctionnement des objets de stratégie de groupe et comment les configurer dans votre structure d'unité d'organisation de façon à affecter les ordinateurs de chaque site. Souvenez-vous que tous les serveurs impliqués dans le scénario BranchCache doivent être des serveurs Windows Server 2008 R2, et tous les clients des ordinateurs Windows 7. Voici la procédure à suivre :

Étape 1. Installez la fonctionnalité BranchCache par le biais du Gestionnaire de serveur.

 

Étape 2. Si vous utilisez BranchCache sur un serveur de fichiers, vous devez installer le rôle Services de fichiers en plus de BranchCache pour les fichiers distants (voir la Figure 2).

Figure 2 Une installation BranchCache requiert l'activation des Services de fichiers et de BranchCache pour les rôles de fichiers distants.

Étape 3. Configurez un objet de stratégie de groupe BranchCache. Accédez à Configuration de l'ordinateur | Stratégies | Modèles d'administration | Réseau | BranchCache. Cinq paramètres vous sont proposés :

  • Activer BranchCache. Cette option doit être activée pour toute la mise en cache de succursale (voir la Figure 3). Notez que le fait d'activer BranchCache sans activer les paramètres de stratégie de mode cache hébergé ou distribué contraint les clients Windows 7 locaux à mettre les fichiers en cache localement. Ceci est utile si plusieurs utilisateurs utilisent un même ordinateur.

     

Figure 3 Dans la Console de gestion des stratégies de groupe, activez BranchCache pour la mise en cache de succursale.

  • Définir le mode cache distribué BranchCache. Cette option s'applique à tous les clients dans l'objet de stratégie de groupe.
  • Définir le mode cache hébergé BranchCache. Spécifiez le serveur devant héberger le cache. Ces rôles s'excluent mutuellement. Vous ne pouvez en configurer qu'un seul pour le site.
  • Configurer BranchCache pour fichiers réseau. Si cette option est désactivée ou n'est pas configurée, un seuil de latence de 80 ms est défini. Si la demande de fichier prend plus de 80 ms, le fichier est envoyé dans le cache. Activez ce paramètre et modifiez la valeur de latence selon les besoins.
  • Définir le pourcentage d'espace disque utilisé pour le cache des ordinateurs clients. La valeur par défaut est de 5 pour cent du disque de l'utilisateur. Il vous faudra expérimenter quelque peu afin d'obtenir un bon compromis entre l'espace requis par l'utilisateur et la mise à disposition du cache. Cela peut présenter un problème si vous avez des configurations de disques qui varient énormément en termes de taille, car certains auront une capacité de mise en cache supérieure à d'autres.

Set Disk Space

 

Étape 4. Configurez le paramètre d'objet de stratégie de groupe « Serveur LanMan » dans la stratégie BranchCache. Dans la même zone de l'objet de stratégie de groupe de l'étape 3, accédez au paramètre Serveur LanMan et observez les propriétés « Publication de hachage pour BranchCache ». Les trois options disponibles sont les suivantes :

  • Désactiver la publication de hachage sur tous les dossiers partagés.
  • Autoriser la publication de hachage pour tous les dossiers partagés.
  • Autoriser la publication de hachage uniquement pour les dossiers partagés sur lesquels BranchCache est activé.

Les serveurs qui exécutent le rôle de serveur Services de fichiers sur des serveurs 2008 R2, qui doivent être des serveurs de contenu BranchCache, doivent également exécuter le rôle Services de fichiers réseau BranchCache et la publication de hachage doit être activée. BranchCache est également activé individuellement sur les partages de fichiers. La publication de hachage peut être activée individuellement sur un serveur (par exemple pour une configuration de serveur n'appartenant pas à un domaine) ou sur des groupes de serveurs par le biais de la Stratégie de groupe. Ainsi, BranchCache peut être activé sur tous les dossiers partagés, activé sur certains dossiers partagés, ou désactivé entièrement.

 

Étape 5. Configurez le paramètre d'objet de stratégie de groupe dans le Pare-feu Windows de façon à autoriser le port TCP 80 entrant (appliqué à l'ordinateur client).

Étape 6. Une fois que vous avez tout configuré, et si le partage de fichiers existe avec les fichiers des utilisateurs, accédez à Gestionnaire de serveur | Services de fichiers | Gestion du partage et du stockage. Le volet central répertorie les partages. Cliquez avec le bouton droit sur le partage et sélectionnez Propriétés, puis cliquez sur Avancé. Sous l'onglet Mise en cache, activez BranchCache (voir la Figure 4). Remarque : si l'option BranchCache n'est pas disponible, cela signifie que la fonctionnalité BranchCache n'a pas été installée correctement ou que la stratégie a la valeur « désactivée », comme mentionné précédemment.

Figure 4 Activez le partage de fichiers avec BranchCache à l'aide des contrôles Gestion du partage et du stockage.

Configuration des clients BranchCache

Par défaut, tous les clients Windows 7 sont activés pour BranchCache, ce qui signifie qu'il n'y a rien à activer sur le client lui-même. Cependant, certaines étapes liées au client sont requises :

  • Configurez les paramètres du pare-feu. Bien que cela ait été mentionné plus haut, il existe d'autres exigences pour le mode cache hébergé. Reportez-vous aux documents BranchCache de Microsoft répertoriés à la fin de cet article.
  • Les clients doivent appartenir à une unité d'organisation qui contient une stratégie qui active BranchCache et définit le mode cache à utiliser. Là encore, reportez-vous aux documents répertoriés à la fin de cet article pour plus de détails.

BranchCache : les avantages

Voici ce qui me plaît à propos de BranchCache :

  • Elle peut utiliser BITS (Background Intelligent Transfer System) pour activer le transfert de fichiers en arrière-plan si l'utilisateur est connecté, même si l'application se ferme. Ceci est très pratique pour les succursales connectées par le biais de liaisons lentes. En cas de nécessité de redémarrage d'un système, le transfert de fichier se poursuit une fois le redémarrage terminé. Bien entendu, pour que cela fonctionne les applications doivent être écrites de façon à tirer parti de BITS.
  • BranchCache est configurable par le biais de l'utilitaire en ligne de commande Netsh et est bien documenté sur le site BranchCache pour Windows Server R2 de TechNet.
  • Vous pouvez surveiller les performances de BranchCache à l'aide de compteurs pour le client, le serveur de fichiers et l'hôte de cache. Non seulement ces compteurs sont utiles pour le diagnostic de performances, mais ils constituent en outre l'unique moyen de savoir si le client obtient réellement une copie mise en cache.
  • L'environnement BranchCache est contrôlable par le biais de la Stratégie de groupe.

BranchCache : les inconvénients

BranchCache est une fonctionnalité incontournable, mais il convient de noter les inconvénients suivants :

  • Étant donné que le mode cache distribué convertit chaque station de travail en un serveur de fichiers, les ordinateurs clients qui hébergent de nombreux fichiers à accès fréquent peuvent subir une dégradation de leurs performances. Des tests devront être effectués afin d'évaluer l'impact réel.
  • Dans certains cas, les clients peuvent nécessiter un espace disque supplémentaire afin que les tailles des caches soient suffisantes.
  • Les clients de mise en cache seront maintenant en concurrence avec leurs homologues pour l'obtention des ressources réseau.
  • Des retards peuvent survenir durant le processus de mise en cache initial ou lorsqu'un fichier n'est pas disponible dans le cache. Seuls les clients Windows 7 et les serveurs Windows Server 2008 R2 pouvant participer, un déploiement complet de cette fonctionnalité peut prendre du temps.

Si vous pouvez justifier la mise en service d'un serveur de fichiers dans la succursale, pourquoi ne pas utiliser des partages DFS (Distributed File System) ? Plutôt que de gérer des fichiers mis en cache, vous pouvez utiliser la fonctionnalité DFS-R (Distributed File System-Replication) pour répliquer les fichiers et maintenir un espace de noms avec DFS. Peut-être trouverez-vous des avantages à la mise en cache des fichiers réseau, et peut-être la fonctionnalité BranchCache sera-t-elle efficace sur les partages DFS. Ou peut-être identifierez-vous une limite de performances au-delà de laquelle le cache est plus efficace que DFS-R. D'un autre côté, l'impact sur le serveur pour BranchCache serait inférieur à celui d'une configuration DFS complète. En résumé, il vous faudra étudier vos besoins et examiner les options disponibles avec BranchCache. Bien entendu, chaque environnement est différent et des problèmes peuvent survenir dans certaines succursales tandis que d'autres en seront épargnées. Il n'existe pas de solution unique adaptée à toutes les solutions.

DirectAccess

Avec DirectAccess, Microsoft résout les problèmes d'expérience VPN auxquels les utilisateurs font face depuis Windows 2000, même avec les nombreuses améliorations apportées depuis l'implémentation initiale. Un client configuré avec DirectAccess peut accéder à un site intranet depuis un emplacement distant sans avoir à établir de lien VPN manuellement. En outre, à leur grande satisfaction, les employés du département informatique peuvent gérer les ordinateurs distants par le biais d'une connexion Internet plutôt que par le biais du VPN. Même sans DirectAccess, un utilisateur distant peut tirer parti de la nouvelle fonctionnalité de reconnexion automatique VPN. Ainsi, si je travaille à domicile, connecté à l'intranet de ma société, et que la liaison Internet est interrompue, le VPN rétablit la connexion dès qu'Internet est de nouveau disponible, sans m'inviter à me reconnecter et à réentrer mes informations d'identification comme ce serait le cas (et de manière répétée) sans DirectAccess.

En fait, du point de vue de l'utilisateur, DirectAccess est invisible. Lorsqu'un utilisateur sur un client activé clique sur la liaison intranet, DirectAccess gère la connexion et la déconnexion. Les utilisateurs ne sont pas obligés d'ouvrir le Gestionnaire de connexions, d'entrer leurs informations d'identification, d'attendre la connexion, et ainsi de suite.

Pendant que la connexion distante est active, l'utilisateur dispose d'une configuration de « tunnel fractionné » par défaut (voir la Figure 5). Cela permet d'avoir un accès simultané à l'intranet, au réseau local (afin de pouvoir utiliser des périphériques tels que des imprimantes) et à Internet. Dans un scénario VPN ordinaire sans le tunnel fractionné, pour se connecter à Internet il faut d'abord parcourir l'intranet, puis traverser la passerelle réseau d'entreprise afin d'obtenir la connectivité. De plus, je n'ai aucun accès à mon réseau local (bien que des solutions de contournement soient possibles). Là encore, DirectAccess est supérieur aux solutions VPN traditionnelles, dans le sens où il est conçu pour offrir à l'utilisateur distant une expérience semblable à celles des employés travaillant « au bureau ».

 

Figure 5 DirectAccess active une configuration de tunnel fractionné pour bénéficier d'une connectivité simultanée au réseau d'entreprise et à Internet.

Du point de vue du département Informatique, une fois l'ordinateur connecté à Internet (souvenez-vous que DirectAccess est toujours activé s'il est installé), les correctifs, stratégies et autres mises à jour sont très faciles à appliquer et sécurisés par le biais de connexions IPsec.

Exigences liées à DirectAccess

Dans une configuration DirectAccess de base, le serveur DirectAccess se trouve sur le réseau de périmètre et procure aux utilisateurs distants une connectivité aux ressources internes, y compris aux serveurs d'applications, autorités de certification, système DNS et contrôleurs de domaine. Les autorités de certification et serveurs d'applications doivent être configurés de façon à accepter le trafic IPv6. Voici les composants essentiels d'une configuration DirectAccess :

  • Dans le domaine Active Directory, les clients DirectAccess ne pourront accéder qu'à des contrôleurs de domaine Windows 2008 ou 2008 R2.
  • Les définitions de Stratégie de groupe doivent appliquer des paramètres DirectAccess pour :
    • identifier les clients DirectAccess ;
    • configurer la table de stratégie de résolution de noms ;
    • supprimer le protocole ISATAP (Intra-Site Automatic Tunneling Address Protocol) de la liste de restriction globale DNS.
  • Le serveur DirectAccess doit :
    • être membre du domaine Active Directory ;
    • s'exécuter sur Windows Server 2008 R2 ;
    • avoir deux cartes réseau configurées (une pour la connectivité intranet et l'autre pour la connectivité Internet) ;
    • avoir deux adresses IPv4 statiques consécutives résolvables de manière externe ;
  • être installé avec la « fonctionnalité » de gestion DirectAccess (par le biais du Gestionnaire de serveur) et configuré par le biais de l'Assistant Installation.

 

  • Le serveur Web/IIS active la fonctionnalité qui détermine si les ressources intranet sont accessibles. Les serveurs d'applications doivent être configurés de façon à autoriser l'accès par les clients compatibles DirectAccess.
  • Pour une utilisation avec l'autorité de certification requise, installez les Services de certificats Active Directory et émettez des certificats pour l'authentification.
  • Un réseau IPv6 natif ou des technologies de transition doivent être disponibles sur l'ensemble de l'intranet.
  • À l'aide de stratégies IPsec pour l'authentification sécurisée et le chiffrement des connexions DirectAccess, le client s'authentifie avant que l'utilisateur n'ouvre une session.
  • Vous trouverez les exceptions de pare-feu nécessaires dans le Guide pour les premiers utilisateurs de DirectAccess.

Comme vous pouvez le voir, DirectAccess n'est pas pour les débutants. L'exigence IPv6 en elle-même génèrera sans doute quelques inquiétudes (et exigera de la plupart des organisations qu'elles implémentent des technologies de transition), mais Windows Server 2008 R2 possède bien tous les composants. De plus, vous devez activer la sécurité par le biais d'une infrastructure à clé publique, fournir des services d'authentification et configurer l'identification IPv6 auprès des serveurs d'applications. Avant d'exécuter l'Assistant Installation de DirectAccess, vous devez également configurer les groupes de sécurité, établir les stratégies de pare-feu, configurer le système DNS et remplir quelques autres conditions requises.

Serveur DirectAccess

Le serveur DirectAccess effectue plusieurs fonctions, définies par le biais de l'Assistant Installation de DirectAccess du Gestionnaire de serveur (voir la Figure 6).

Figure 6 Lancement de l'installation de DirectAccess par le biais du Gestionnaire de serveur.

L'Assistant DirectAccess effectue quatre tâches essentielles. À l'aide de l'Assistant, vous allez :

  1. identifier les clients devant être compatibles avec DirectAccess. Vous pouvez ici répertorier des groupes de sécurité d'autres domaines ou forêts, si des approbations sont configurées. Vous devez définir des groupes de sécurité appropriés avant d'exécuter l'Assistant ;
  2. définir la connectivité et la sécurité (certificats) pour le serveur DirectAccess. Vous identifierez l'interface réseau qui se trouve du côté Internet et celle connectée à l'intranet. Installez l'autorité de certification et créez les certificats avant d'exécuter l'Assistant Installation de DirectAccess. Vous devez en outre définir la stratégie de cartes à puce ;
  3. identifier le serveur DNS, le contrôleur de domaine et, éventuellement, la gestion d'autres serveurs d'infrastructure utilisés dans l'environnement DirectAccess. Vous devez également identifier un serveur hautement disponible comme serveur d'emplacement réseau. Ce rôle peut être rempli par le serveur DirectAccess ;
  4. identifier les serveurs d'applications configurés de façon à accepter les connexions avec des clients DirectAccess. La valeur par défaut est aucune autorisation de bout en bout supplémentaire, mais vous pouvez sélectionner des options de sécurité basées sur une stratégie IPsec.

DNS et la table de stratégie de résolution de noms

Comme noté précédemment, les clients DirectAccess peuvent accéder directement à l'intranet. Pour cela, vous devez implémenter la table de stratégie de résolution de noms, qui définit les serveurs DNS par espace de noms DNS plutôt que par interface réseau. Cela s'apparente un peu au fonctionnement du transfert conditionnel sur les serveurs Windows 2003 et 2008, où vous pouvez définir des espaces de noms DNS avec l'adresse IP appropriée pour se connecter au serveur. La table de stratégie de résolution de noms permet à un client d'éviter l'itération DNS normale et d'accéder directement au serveur DirectAccess.

Le principe de fonctionnement de la table de stratégie de résolution de noms est le suivant (voir la Figure 7) :

  1. Une demande de requête de nom correspond à un espace de noms configuré pour l'intranet configuré, pointant vers le serveur DirectAccess.
  2. La table de stratégie de résolution de noms contient l'adresse IP et le nom de domaine complet du serveur DirectAccess. Lorsque l'adresse IP est utilisée, la connexion au serveur DNS est chiffrée afin de sécuriser la connexion.
  3. Lorsque le nom de domaine complet est utilisé, il doit être résolu par le biais d'Internet et trouver le serveur DNS d'entreprise.
  4. Si le client envoie une demande de résolution de nom pour un espace de noms qui n'est pas défini dans la table de stratégie de résolution de noms (tel que www.microsoft.com), la demande suit la procédure normale de résolution de nom par le biais d'Internet.

Figure 7 Le table de stratégie de résolution de noms permet de définir des serveurs DNS par espace de noms DNS plutôt que par interface.

 

La table de stratégie de résolution de noms est configurée durant l'installation de DirectAccess dans la page Installation du serveur d'infrastructure et l'Assistant renseigne l'adresse IPv6 du serveur DNS. Stratégie de résolution de noms, un nouveau paramètre de Stratégie de groupe dans Windows Server 2008 R2, définit des paramètres de stratégie tels que IPsec, serveur DNS et la solution de résolution de secours appliquée lorsque l'espace de noms ne se trouve pas sur le réseau interrogé. Vous trouverez ce paramètre dans Configuration de l'ordinateur | Paramètres Windows | Stratégie de résolution de noms (notez que vous devez entrer les espaces de noms de domaine en les faisant commencer par un point « . », par exemple .emea.corp.net).

Vous pouvez exposer le contenu de la table de stratégie de résolution de noms à l'aide de la commande Netsh : Netsh name show policy.

Cette commande permet d'afficher les espaces de noms définis.

Exclusions de pare-feu

Les exclusions de pare-feu varient selon la façon dont vous implémentez le réseau IPv6 et selon que vous utilisez ou non des technologies de transition. En outre, le Pare-feu Windows devra être configuré de manière appropriée sur tout serveur de fichiers ou d'applications auquel les clients distants se connectent. La Figure 8 et la Figure 9 ci-dessous illustrent des exclusions de pare-feu, respectivement pour les pare-feu du côté Internet et intranet du serveur DirectAccess. Bien évidemment, vous ne devez définir des exclusions que pour les technologies que vous utilisez. (Notez que bien que la Figure 9 mentionne IPv4+NAT-PT, cela n'est pas implémenté par Windows 2008 R2.)

 

Figure 8 Paramètres de pare-feu pour le pare-feu Internet

Technologie de transition Protocole à autoriser
Teredo UDP 3544
6to4 Protocole IP 41
IP-HTTPS TCP 443
IPv6 natif ICMPv6, Protocole 50

 

 

Figure 9 Paramètres de pare-feu pour le pare-feu intranet

 

Protocole Technologie IPv6
ISATAP IPv6 natif IPv4 + NAT-PT
Protocole 41 X    
TCP   X X
UDP   X X
ICMPV6   X  
Toute connectivité IPv6   X  
UDP 500 IKE/AuthIP   X X

 

Connectivité - IPv6

Le protocole IPv6 permettant aux clients DirectAccess de maintenir une connectivité continue aux ressources sur le réseau d'entreprise, ils doivent tous exécuter ce protocole. Même si vous disposez d'un réseau IPv6 à implémentation complète, l'activation de la connectivité distante peut exiger l'utilisation d'une technologie de transition qui autoriserait le client DirectAccess à se connecter à des ressources IPv4 en encapsulant IPv6 dans des paquets IPv4. Parmi ces technologies, citons 6to4, IP-HTTPS et Teredo.  ISATAP est également une technologie d'encapsulation, mais elle est utilisée uniquement en interne. Je ne rentrerai pas ici dans les détails, mais la Figure 10 illustre les options de connectivité de base.

 

Figure 10  Options de connexion préférables pour les clients DirectAccess

 

Si l'élément suivant est assigné au client : Méthode de connectivité préférable :
Adresse IPv6 à routage global Adresse IPv6 à routage global
Adresse IPv4 publique 6to4
Adresse IPv4 privée (NAT) Teredo
Si le client ne peut pas se connecter à l'aide des méthodes ci-dessus IP-HTTPS

* Source : Microsoft*

Du côté intranet, sans IPv6 natif, DirectAccess autorise l'utilisation d'ISATAP, qui génère une adresse IPv6 à partir d'une adresse IPv4 et implémente sa propre découverte de voisin. ISATAP utilise les clients compatibles DirectAccess pour accéder aux ressources sur un réseau IPv4. Par exemple, lorsqu'un client ISATAP démarre, il doit trouver un routeur ISATAP. Pour cela, il émet une requête DNS pour ISATAP.<nom_domaine>. Par exemple, pour Corp.net il recherche ISATAP.corp.net. Le système DNS de Windows 2008 implémente GlobalQueryBlockList, une fonctionnalité de sécurité supplémentaire qui inclut ISATAP par défaut et qui le force à ignorer toute demande ISATAP.<nom_domaine>. Par conséquent, vous devez effacer ISATAP de la liste. Pour cela, utilisez la commande DNSCMD ou créez une entrée dans le Registre.

À l'invite de commande, entrez dnscmd /config /globalqueryblocklist wpad et appuyez sur la touche Entrée. Cette commande permet de définir GlobalQueryBlockList comme contenant uniquement WPAD (ce qui supprime ISATAP). En guise d'alternative, vous pouvez naviguer jusqu'à la clé de Registre

HKLM:\System\Current Control Set\Services\DNS\Parameters. Modifiez GlobalQueryBlockList et supprimez ISATAP.

Vous pouvez également implémenter 6to4 individuellement sur les hôtes ou sur un réseau entier et transmettre des paquets IPv6 sur un réseau IPv4. Chose intéressante, si 6to4 est implémenté pour un réseau entier, il requiert une seule adresse IPv4. Il ne prend pas en charge le trafic entre des hôtes IPv4 et IPv6-uniquement.

Teredo prend également en charge le routage de paquets IPv6 vers des réseaux IPv4, mais il est utilisé lorsque le client se trouve derrière un serveur NAT non configuré pour IPv6. Il stocke les paquets IPv6 dans le datagramme IPv4 qui autorise le transfert à partir du serveur NAT.

Windows 7 et Windows Server 2008 R2 ont implémenté un protocole nommé IP-HTTPS qui met en tunnel les paquets IPv6 dans un paquet IPv4 HTTPS. Bien que IP-HTTPS présente des performances inférieures à celles des autres protocoles, vous pouvez ajouter des serveurs IP-HTTPS supplémentaires afin d'améliorer quelque peu les performances. IP-HTTPS est un protocole relativement facile à activer afin de bénéficier de la connectivité réseau IPv6-sur-IPv4.

Lors de la conception de la configuration des clients DirectAccess, vous pouvez utiliser DNS et la table de stratégie de résolution de noms pour séparer le trafic Internet et intranet, ou utiliser le « tunneling forcé » pour obliger tout le trafic à traverser le tunnel. Le tunneling forcé, qui requiert IP-HTTPS, peut être activé par le biais du paramètre de Stratégie de groupe Configuration de l'ordinateur\Stratégies\Modèles d'administration\Réseau\Connexions réseau\Router tout le trafic par le biais du réseau interne. Cette stratégie doit s'appliquer aux clients DirectAccess. J'ai mentionné précédemment que les clients DirectAccess pouvaient accéder aux ressources locales lorsqu'ils étaient connectés à Internet. Cela est également valable pour les clients IP-HTTPS, mais si l'utilisateur tente d'accéder à des sites Internet, par exemple, il sera routé à travers l'intranet.

La complexité de la configuration et les exigences liées au protocole IPv6 constituent indiscutablement les inconvénients de DirectAccess, mais ils sont plus que compensés par les améliorations en termes d'expérience utilisateur et de facilité de gestion des clients distants pour le département Informatique.

Grandes espérances

Le nombre de travailleurs distants, qu'ils se trouvent dans une succursale, à domicile ou en déplacement, est en constante augmentation. BranchCache et DirectAccess constituent de sérieux atouts pour les employés de succursales et autres travailleurs distants, et les administrateurs et responsables informatiques seraient sages d'envisager leur implémentation. Leur installation n'est certes ni aisée ni rapide, et les options et fonctionnalités disponibles sont nombreuses. De plus, ces fonctionnalités ne concernent que les clients Windows 7 et les serveurs Windows Server 2008 R2, ce qui aura très certainement un impact sur le calendrier d'implémentation. Les administrateurs et responsables informatiques feraient bien d'étudier la documentation Microsoft disponible et de configurer ces fonctionnalités dans un laboratoire de test afin de s'assurer de leur succès.

Contenu associé

 

Gary Olsenest ingénieur en logiciels système auprès du WTEC (Worldwide Technical Expert Center) de Hewlett-Packard Services à Atlanta, Ga., et travaille dans le secteur de l'informatique depuis 1981. Il est titulaire de la certification Microsoft MVP pour les Services d'annuaire et fondateur/président de l'Atlanta Active Directory Users Group. Il contribue fréquemment à Redmond Magazine.