Lors du déploiement de Direct Access, le gros de l’attention est communément porté sur la configuration des accès de l’extérieur vers l’intérieur ; ce qui est tout naturel dans la mesure où il s’agit de l’utilisation principale de la solution.
Cependant, Direct Access peut également permettre les accès depuis votre LAN vers les clients connectés depuis l’extérieur, ce qui peut s’avérer extrêmement utile par exemple dans les scénarios d’assistance à distance de vos utilisateurs : il s’agit de la fonction dite de “manage out”
Une problématique peut alors vite émerger : comme vous le savez forcément si vous vous êtes déjà intéressés au sujet, Direct Access ne fonctionne qu’en IPv6 et repose sur des technologies de transition (IPHTTPS, 6to4, teredo… selon les scénarios, le premier étant de loin le plus utilisé) pour que les clients qui passent par internet (donc quasi systématiquement en IPv4) puissent dialoguer votre LAN (lui aussi très souvent en IPv4).
Par contre, la seule possibilité concernant les flux du LAN vers l’extérieur est le déploiement du routage ISATAP, avec tous ses inconvénients.
Par ailleurs, dans le cadre d’un déploiement multisite ou utilisant du load-balancing (très fréquent en entreprise pour des raisons de haute disponibilité), Microsoft ne supporte plus ce type de routage (cf. https://technet.microsoft.com/en-us/library/dn464274(v=ws.11).aspx#bkmk_isa ).
La seule solution restante est donc l’IPv6 natif.
Comme il n’est généralement pas envisageable d’entreprendre une migration complète de votre infrastructure réseau vers IPv6 simplement pour répondre à cette problématique, la solution d’un ou plusieurs serveurs « de rebond » dédiés à l’accès vers les clients externes reste la plus pratique, à défaut d’être la plus élégante. Il peut également tout à fait s’agir directement de vos serveurs SCCM ou de toute autre solutions de prise en main à distance dont vous disposeriez.
Ces serveurs seront configurés avec des adresses IPv6 statiques, leur permettant de communiquer avec votre infrastructure DirectAccess.
I Attribution des IPv6
Sur un des serveur Direct Access, lancez un shell powershell en tant qu’administrateur et exécutez la commande
|
(Get-DAServer).InternalIPv6Prefix |
Le préfixe IPv6 interne de votre déploiement Direct Access est donc ici xxxx:yyyy:967b:1::/64
Nous allons l’utiliser pour définir arbitrairement les IPv6 statiques de vos différents serveurs Direct Access et serveurs Manage Out :
xxxx:yyyy:967b:1::1 (premier serveur Direct Access)
xxxx:yyyy:967b:1::2 (second serveur Direct Access)
[…]
xxxx:yyyy:967b:1::10 (premier serveur de Manage Out)
xxxx:yyyy:967b:1::11 (second serveur de Manage Out)
etc.
Il reste ensuite à les attribuer à chaque serveur, de facon tout à fait classique :
Ouvrez les propriétés de la carte réseau concernée (carte « LAN » ou unique sur vos serveurs DA) puis sélectionnez le protocole IPv6 et cliquez sur Properties :
Indiquez l’IPv6 du serveur, le prefix length 64 et cliquez sur OK.
II Création des routes
Afin que les serveurs de Manage-Out puissent communiquer avec les clients DirectAccess, il est ensuite nécessaire de leur ajouter des routes statiques. En effet, selon le serveur DirectAccess auquel un client est connecté, il obtiendra une adresse IPv6 avec un préfixe distinct et le serveur de ManageOut a besoin de savoir par quel serveur DirectAccess il doit passer pour pouvoir atteindre le client.
Il est possible d’obtenir ce préfixe en exécutant la commande suivante sur n’importe lequel des serveurs DirectAccess :
|
(Get-DAServer).ClientIPv6Prefix |
On obtient ici le préfixe xxxx:yyyy:967b:1000::/59. Le préfixe client a une longueur de 59 bits.
Néanmoins ce dernier est subdivisé en préfixes de 64 bits et chacun d’entre eux est affecté à un serveur DirectAccess. Ainsi, selon l’exemple ci-dessus, les clients connectés au premier serveur DirectAccess obtiendront le préfixe xxxx:yyyy:967b:1000::/64, ceux connectés au second serveur auront le préfixe xxxx:yyyy:967b:1001::/64 etc.
Il est donc nécessaire d’ajouter autant de route que de serveur DirectAccess sur chaque serveur de Management.
Pour ce faire, on exécute les commandes suivantes :
|
Netsh int ipv6 add route xxxx:yyyy:967b:1000::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1::1 Netsh int ipv6 add route xxxx:yyyy:967b:1001::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1:: 2 |
III Ajout du serveur de Management à Direct Access
Le serveur de Manage-Out doit ensuite être ajouté aux serveurs de Management dans Direct Access.
Cela présente par ailleurs un intérêt majeur : il devient ainsi accessible même lorsqu’uniquement le tunnel infrastructure est monté, c’est-à-dire même si l’utilisateur n’a pas ouvert de session sur son PC.
Il devient alors envisageable de gérer à distance le déploiement de paquets, la synchronisation de console antivirus avec une gestion dans le LAN etc.
Pour réaliser cette opération, se rendre dans la console « Remote Access Management » puis dans le menu « DirectAccess and VPN » en ayant pris soin de sélectionner la ferme DirectAccess (« Load Balanced Cluster »). Ensuite, il est nécessaire de cliquer sur le bouton « Edit » de l’étape 3.
Dans l’onglet « Management », faites un clic-droit sur la liste de serveurs et sélectionnez « Add ».
Entrez le FQDN du serveur de manage-out et cliquez sur OK
Cliquez sur Finish.
Enfin, cliquez sur Refresh Management Servers :
Vous devriez maintenant pouvoir accéder à vos clients depuis le LAN, en utilisant leur nom DNS ou leur IPv6 directement.
Attention toutefois, les clients connectés via DirectAccess ont le profil de firewall Windows « public » actif, il peut donc être nécessaire d’ouvrir les ports dont vous aurez besoin pour ce profil !
