Déployer plusieurs serveurs d'accès à distance dans un déploiement Multisite

S'applique à: Windows Server 2012 R2, Windows Server 2012

Windows Server 2012 combine DirectAccess et le réseau privé virtuel (VPN) du service Routage et accès distant (RRAS) dans un rôle Accès à distance unique. L’accès à distance peut être déployé dans plusieurs scénarios d’entreprise. Cette vue d'ensemble fournit une introduction au scénario d'entreprise pour déployer des serveurs d'accès à distance dans une configuration multisite.

Description du scénario

Dans un déploiement multisite deux ou plusieurs serveurs d'accès distant ou des clusters de serveurs sont déployés et configurés comme points d'entrée différents dans un emplacement unique ou dans des emplacements géographiques disparates. Déploiement de plusieurs points d'entrée dans un seul emplacement permet la redondance de serveur ou l'alignement des serveurs d'accès distant avec l'architecture réseau existante. Le déploiement par emplacement géographique garantit une utilisation efficace des ressources, comme les ordinateurs clients distants peuvent se connecter aux ressources réseau internes à l'aide d'un point d'entrée le plus proche de leur. Le trafic sur un déploiement multisite peut être distribué et équilibré avec un équilibrage de charge global externe.

Un déploiement multisite prend en charge les ordinateurs clients exécutantWindows 8ouWindows 7. Les ordinateurs clients exécutantWindows 8identifier automatiquement un point d'entrée ou l'utilisateur peut sélectionner manuellement un point d'entrée. L'attribution automatique se produit dans l'ordre de priorité suivant :

1. Utilisez un point d'entrée sélectionné manuellement par l'utilisateur.

2. Utilisez un point d'entrée identifié par un équilibrage de charge global externe si une est déployée.

3. Utilisez le point d'entrée le plus proche identifié par l'ordinateur client à l'aide d'un mécanisme de détection automatique.

Prise en charge pour les clients qui exécutent Windows 7 doit être activée manuellement sur chaque point d'entrée et sélection d'un point d'entrée par ces clients n'est pas pris en charge.

Conditions préalables

Avant de commencer le déploiement de ce scénario, prenez connaissance des conditions essentielles :

• Déployer un serveur DirectAccess unique avec des paramètres avancésdoit être déployé avant un déploiement multisite.

• Les clients Windows 7 seront toujours se connecter à un site spécifique. Ils ne seront pas en mesure de se connecter au site plus proche en fonction de l'emplacement du client (contrairement à Windows 8, les clients windows 8.1).

• Modification des stratégies en dehors de la console de gestion DirectAccess ou les applets de commande PowerShell n'est pas pris en charge.

• Une Infrastructure à clé publique doit être déployée.

  Pour plus d’informations, voir : Mini-module de Guide de laboratoire de test : PKI de base pour Windows Server 2012.

• Le réseau d'entreprise doit être compatibles IPv6. Si vous utilisez le protocole ISATAP, vous devez le supprimer et utiliser le protocole IPv6 natif.

Dans ce scénario

Le scénario de déploiement multisite comprend plusieurs étapes :

1. Déployer un serveur DirectAccess unique avec des paramètres avancés: Un serveur d'accès à distance unique avec des paramètres avancés doit être déployé avant de configurer un déploiement multisite.

2. Planifier un déploiement Multisite: Pour créer un déploiement multisite à partir d'un seul serveur un certain nombre de planification supplémentaires étapes sont nécessaires, notamment le respect des conditions préalables multisites et planification de groupes de sécurité Active Directory, objets de stratégie de groupe (GPO), DNS et paramètres du client.

3. Configurer un déploiement Multisite— Il s'agit d'un nombre d'étapes de configuration, y compris la préparation de l'infrastructure Active Directory, la configuration du serveur d'accès à distance existante et l'ajout de plusieurs serveurs d'accès distant en tant que points d'entrée au déploiement multisite.

4. Dépanner un déploiement multisite: Cette section décrit un nombre d'erreurs les plus courantes qui peuvent se produire lors du déploiement de l'accès à distance dans un déploiement multisite.

Cas pratiques

Un déploiement multisite offre les avantages suivants :

• Amélioration des performances, un déploiement multisite permet aux ordinateurs clients l'accès aux ressources internes à l'aide de l'accès à distance pour se connecter à l'aide du point d'entrée le plus proche et le plus approprié. Client accéder efficacement aux ressources internes, et la vitesse du client Qu'internet demande acheminé via DirectAccess est améliorée. Le trafic entre des points d'entrée peut être équilibré à l'aide d'un équilibrage de charge global externe.

• Facilité de gestion — Multisite permet aux administrateurs d'aligner le déploiement de l'accès à distance à un déploiement de sites Active Directory, fournissant une architecture simplifiée. Paramètres partagés peuvent aisément être définis sur les serveurs de point d'entrée ou des clusters. Paramètres d'accès à distance peuvent être gérés à partir des serveurs dans le déploiement ou à distance à l'aide des outils d'Administration de serveur distant (RSAT). De plus, la totalité du déploiement multisite peut être analysé à partir d'une seule console de gestion de l'accès à distance.

Fonctionnalités et rôles inclus dans ce scénario

Le tableau suivant répertorie les rôles et les fonctionnalités utilisées dans ce scénario.

Configuration matérielle requise

La configuration matérielle requise pour ce scénario comprend les éléments suivants :

• Au moins deux ordinateurs l'accès à distance dans un déploiement multisite. Configuration matérielle requise pour ces ordinateurs est décrites dansDéployer un serveur DirectAccess unique avec des paramètres avancés.

• Pour tester le scénario, au moins un ordinateur exécutantWindows 8et configuré comme un client DirectAccess est requis. Pour tester le scénario pour les clients qui exécutent Windows 7, au moins un ordinateur exécutant Windows 7 est nécessaire.

• Pour équilibrer le trafic entre les serveurs de point d'entrée, un équilibreur de charge global externe tiers est requis.

Configuration logicielle requise

La configuration logicielle requise pour ce scénario comprend les éléments suivants :

• Configuration logicielle requise pour un déploiement sur un seul serveur. Pour plus d'informations, consultez Déployer un serveur DirectAccess unique avec des paramètres avancés.

• En plus de la configuration logicielle requise pour un serveur unique, il existe de nombreuses exigences multisite-spécifiques :

  • Exigences d'authentification IPsec, l'authentification par certificat d'ordinateur dans un déploiement multisite DirectAccess doit être déployé à l'aide d'IPsec. L'option permettant d'effectuer l'authentification IPsec à l'aide du serveur d'accès distant en tant que proxy Kerberos n'est pas pris en charge. Une autorité de certification interne est requise pour déployer les certificats IPsec.

  • Exigences de serveur d'emplacement réseau et IP-HTTPS, le serveur emplacement réseau doit être émis par une autorité de certification et les certificats requis pour IP-HTTPS. La possibilité d'utiliser des certificats émis automatiquement et auto-signés par le serveur d'accès à distance n'est pas pris en charge. Les certificats peuvent être émis par une autorité de certification interne ou par une autorité de certification externe tiers.

  • Conditions requises pour Active Directory, au moins un site Active Directory est requis. Le serveur d'accès à distance doit se trouver dans le site. Temps de mise à jour plus rapide, il est recommandé que chaque site dispose d'un contrôleur de domaine accessible en écriture, bien que ce ne soit pas obligatoire.

  • Exigences de groupe de sécurité — requises sont les suivantes :

    • Un groupe de sécurité est requis pour tous lesWindows 8de tous les domaines, les ordinateurs clients. Il est recommandé de créer un groupe de sécurité unique de ces clients pour chaque domaine.

    • Un groupe de sécurité unique contenant des ordinateurs Windows 7 est requis pour chaque point d'entrée configuré pour prendre en charge les clients Windows 7. Il est recommandé d'avoir un groupe de sécurité unique pour chaque point d'entrée dans chaque domaine.

    • Les ordinateurs ne doivent pas être inclus dans plusieurs groupes de sécurité contenant des clients DirectAccess. Si les clients sont inclus dans plusieurs groupes, la résolution de noms pour les demandes du client ne fonctionnera pas comme prévu.

  • Exigences de stratégie de groupe, stratégie de groupe peut être créé manuellement avant de configurer l'accès à distance ou créés automatiquement lors du déploiement de l'accès à distance. Conditions requises sont les suivantes :

    • Un objet de stratégie de groupe client unique est requis pour chaque domaine.

    • Un serveur de stratégie de groupe est requis pour chaque point d'entrée, dans le domaine dans lequel se trouve le point d'entrée. Si plusieurs points d'entrée sont situés dans le même domaine, il y aura plusieurs serveurs de stratégie de groupe (un pour chaque point d'entrée) dans le domaine.

    • Une stratégie de groupe du client Windows 7 unique est requis pour chaque point d'entrée activée pour la prise en charge du client Windows 7, pour chaque domaine.

Problèmes connus

Les éléments suivants sont des problèmes connus lors de la configuration d'un scénario multisite :

• Plusieurs points d'entrée dans le même sous-réseau IPv4: ajout de plusieurs points d'entrée dans le même sous-réseau IPv4 entraînera un message de conflit d'adresse IP et l'adresse DNS64 pour le point d'entrée ne sera pas configuré comme prévu. Ce problème se produit lorsque IPv6 n'a pas été déployée sur les interfaces internes des serveurs sur le réseau d'entreprise. Pour éviter ce problème, exécutez la commande Windows PowerShell suivante sur tous les serveurs d'accès distant actuels et futurs :

  Set-NetIPInterface –InterfaceAlias <InternalInterfaceName> –AddressFamily IPv6 –DadTransmits 0
  

• Si l'adresse publique spécifié pour les clients DirectAccess pour se connecter au serveur d'accès à distance comporte un suffixe inclus dans NRPT, DirectAccess peut ne pas fonctionner comme prévu. Assurez-vous que la table possède une exemption pour le nom public. Dans un déploiement multisite, les exemptions doivent être ajoutées pour les noms de tous les points d'entrée publics. Notez qu'if force le tunneling est activé ces exemptions sont ajoutées automatiquement. Elles sont supprimées si le tunneling forcé est désactivé.

• Lorsque vous utilisez l'applet de commande Windows PowerShellDisable-DAMultiSiteles paramètres WhatIf and Confirm n'ont aucun effet et Multisite sera désactivé etWindows 7stratégie de groupe sera supprimé.

• LorsqueWindows 7clients à l'aide de DCA dans un déploiement Multisite sont mis à niveau versWindows 8l'Assistant connectivité réseau ne fonctionnera pas. Ce problème peut être résolu avant la mise à niveau du client en modifiant leWindows 7GPO à l'aide des applets de commande Windows PowerShell suivantes :

  Set-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant" -ValueName "TemporaryValue" -Type Dword -Value 1 Remove-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant" 
  

  Dans le cas où le client a déjà été mis à niveau, puis déplacez l'ordinateur client à leWindows 8groupe de sécurité.

• Lorsque vous modifiez les paramètres de contrôleur de domaine à l'aide de l'applet de commande Windows PowerShellSet-DAEntryPointDCsi le paramètre ComputerName spécifiée est un serveur d'accès à distance dans un point d'entrée autre que le dernier ajouté au déploiement Multisite, un avertissement s'affiche indiquant que le serveur spécifié ne sera pas mis à jour jusqu'à la prochaine actualisation de la stratégie. L'ou les serveurs réel qui n'a pas été mis à jour peuvent être consulté à l'aide de laétat de la Configurationdans lestableau de bordde laConsole de gestion de l'accès distant. Cela n'entraîne pas de problèmes fonctionnels, toutefois, vous pouvez exécutergpupdate /forcesur l'ou les serveurs qui n'a pas mis à jour pour obtenir l'état de configuration mis à jour immédiatement.

• Lorsque multisite est déployé dans un réseau de d'entreprise IPv4 uniquement, modification interne modifications le DNS64 adresse préfixe IPv6 réseau également, mais ne met pas à jour l'adresse sur les règles de pare-feu qui autorise les requêtes DNS pour le service DNS64. Pour résoudre ce problème, exécutez les commandes Windows PowerShell suivantes après la modification du préfixe IPv6 de réseau interne :

  $dns64Address = (Get-DAClientDnsConfiguration).NrptEntry | ?{ $_.DirectAccessDnsServers -match ':3333::1' } | Select-Object -First 1 -ExpandProperty DirectAccessDnsServers $serverGpoName = (Get-RemoteAccess).ServerGpoName $serverGpoDc = (Get-DAEntryPointDC).DomainControllerName $gpoSession = Open-NetGPO -PolicyStore $serverGpoName -DomainController $serverGpoDc Get-NetFirewallRule -GPOSession $gpoSession | ? {$_.Name -in @('0FDEEC95-1EA6-4042-8BA6-6EF5336DE91A', '24FD98AA-178E-4B01-9220-D0DADA9C8503')} |  Set-NetFirewallRule -LocalAddress $dns64Address Save-NetGPO -GPOSession $gpoSession
  

• Si DirectAccess a été déployé lorsqu'une infrastructure ISATAP était présente, lors de la suppression d'un point d'entrée qui était un hôte ISATAP, l'adresse IPv6 du service DNS64 sera supprimée à partir de l'adresse de serveur DNS de tous les suffixes DNS dans la table NRPT.

  Pour résoudre ce problème, dans leinstallation du serveur d'InfrastructureAssistant, sur leDNSpage, supprimez les suffixes DNS qui ont été modifiés et les ajouter à nouveau avec les adresses de serveur DNS corrects, en cliquant surdétectersur laadresses de serveur DNSboîte de dialogue.