Je pense que toute personne ayant commencé à se renseigner sur DirectAccess sera d’accord avec moi : c’est une fonctionnalité de Windows 7 Entreprise ou Intégrale couplé à Windows Server 2008 R2 vraiment intéressante pour 2 raisons :

  • Du côté de l’utilisateur, l’usage du poste de travail de l’entreprise est exactement le même à l’extérieur de l’entreprise : pas de client VPN à utiliser, l’accès aux applications se fait de la même façon que lorsque le poste est connecté sur le LAN de l’entreprise.
  • Du côté de l’administration système / réseaux, le poste de l’utilisateur est accessible depuis le système d’information à partir du moment où la machine nomade dispose d’une connectivité à Internet (au travers d’une box ADSL, en 3G…). Ce poste nomade redevient donc la propriété logique des équipes IT (qui ont perdu depuis longtemps le contrôle physique de ces PC nomades)

Au-delà de ce premier constat très positif sur DirectAccess, certaines personnes et équipes IT / réseaux peuvent être inquiétées par certains des prérequis imposés dans une infrastructure dont un en particulier : la présence d’IPv6 .

Je ne vais pas vous refaire dans cet article une nouvelle explication du  « pourquoi IPv6 n’est pas vraiment un prérequis problématique », pour cela je vous encourage à lire un billet précédent :

Ce billet est en fait un complément au billet cité ci-dessus afin d’ajouter et expliquer comment Forefront UAG peut encore plus simplifier la mise en oeuvre de DirectAccess dans des environnements avec des serveurs ne parlant pas IPv6.

Reprenons rapidement les différentes méthodes de transitions existantes dans Windows Server 2008 / 2008 R2 / Windows 7 dans un petit schéma récapitulatif :


Ici, il demeure un cas qui n’est pas traité : le serveur  ou le poste client qui ne dispose pas d’une couche IPv6, c’est-à-dire :
- Tous les systèmes antérieurs à Windows Server 2008 : 2003 R2, 2003, 2000, NT, certains Unix..
- Tous les systèmes clients antérieurs à Windows Vista : Windows XP, 2000, NT…

C’est ici qu’interviennent d’autres méthodes de transitions du mode IPv6 vers le monde IPv4.

Première option : NAT-PT


Comme le montre le schéma, un équipement NAT-PT permet de transformer des flux IPv6 en flux IPv4 (parfois l’inverse)
Néanmoins, il subsiste certains points noirs :

  • NAT-PT n’est pas un standard (RFC 2766 resté en draft), déprécié (RFC 4966)
  • L’IETF travaille sur un remplaçant (cf. NAT64/DNS4 encore en draft, voir plus bas)
  • Seulement quelques implémentations de NAT-PT
  • Montée en charge pouvant être difficile
  • Nécessite DNS-ALG (DNS Application Layer Gateway)
  • Pas de sécurité de bout en bout
    • Impossible de faire de l’IPsec de bout en bout, ce qui limite les scénarios possible de mise en œuvre de DirectAccess
      Bref c’est plutôt à réservé à des sociétés ayant déjà des équipements réseaux intégrant ces mécanismes et ayant des ingénieurs réseaux compétents sur le paramétrage IPv4/IPv6.

Seconde option : NAT64/DNS64

Forefront UAG (Unified Access Gateway) intègre les mécanismes NAT64/DNS64 de transition d’IPv6 vers IPv4 et complète ainsi les mécanismes déjà présents dans Windows Server 2008 R2.

Forefront UAG est  la solution Microsoft permettant tous les types d’accès distants (VPN, reverse proxy, VPN standards, VPN SSL…) au système d’Informations dont DirectAccess. DirectAccess qui va être enrichi par Forefront UAG sur différents points tels que la haute disponibilité, la montée en charge (scale-out) et les mécanismes de transition IPv4/IPv6

Plus d’informations sur Forefront UAG en vidéo (durée : 15 min)

Alors du coup, comment fonctionne NAT64/DNS64 dans Forefront UAG ?

Et bien cela, nous allons le découvrir dans la seconde partie de cet article publiée très prochainement ;-)

Tags: