Archives de catégorie : IPV6

My new favorite IT book

I’m a DirectAccess enabled guy that discovered IPv6 through DirectAccess. There are so many thing to learn about IPv6. With Windows Server 2012 to be released this year, it was time for a new edition of the Microsoft Undestanding IPv6 of Joseph Davies alias Cable guy.

 

BOOK

 

Why this book is my new favorite IT book, because now it cover Windows 8 / Windows Server 2012 and DirectAccess. If you want to learn more on IPv6 and one of my favorite Windows 8 feature. If you plan to Deploy DirectAccess, order this book, it worth!

 

BenoîtS – Simple and Secure by Design but Business compliant

IPv6, le changement, c’est le 6 juin 2012

Il y a près d’un an, les grands acteurs de l’Internet avaient organisé un test grandeur nature d’IPv6 sur Internet (http://www.worldipv6day.org/). Ce test n’ayant avait pour objectif de valider la capacité de ces grandes infrastructures à offrir leurs services en IPv4 et en IPv6. Les résultats ayant été plus que positif, les tests intermédiaires ont été jugés inutiles. On passe donc à la vitesse supérieure avec le World IPv6 Launch day.

 

Le 6 juin 2012, les grands acteurs de l’Internet proposeront leurs services en IPv4 et en IPv6. Donc le futur, c’est le 6 juin 2012.

World_IPv6_launch_banner_512

 

Dans ce domaine, la France est assez bien représentée.

 

BenoitS – Simple and Secure by Design but Business compliant

DirectAccess et Symantec Endpoint Protection

La suite Symantec Endpoint Protection inclus un pare-feu nommé “Proactive Threat Protection”. Avec DirectAccess, les choses se compliquent car en remplaçant le pare-feu de Windows par un autre, il faut reproduire le même paramétrage. Pour l’essentiel des informations, tout est résumé ici : http://technet.microsoft.com/en-us/library/ee382257(WS.10).aspx.

 

Le premier point, c’est que SEP s’interface bien avec la WIndows Filtering Platform en prenant soin de ne pas remplacer le module ConSecRuleRuleCategory. C’est en effet celui-ci qui est chargé des tunnels IPsec nécessaires à DirectAccess.

SEP0

 

Une fois SEP installé et actif, DirectAccess fonctionne mais pas exactement comme on l’attend. Lorsque le client dispose d’une connectivité Internet directe, c’est le protocole 6to4 qui doit être utilisé. Dans le cas d’une connectivité Internet au travers d’un mécanisme de translation d’adresses, c’est le protocole Teredo qui doit être utilisé. IPHTTPS ne devant être utilisé qu’en dernier recours. Pourtant, quelque soit le type de connectivité réseau, c’est toujours le protocole IPHTTPS qui est utilisé par le client DirectAccess.

 

Après un peu de recherches, ce comportement est normal car la configuration pare-défaut de FEP bloque l’utilisation des protocoles de transition vers IPv6.

SEP1

 

En désactivant ces deux règles, les protocoles de transition 6to4 et Teredo sont de nouveau opérationnel.

 

Benoits – Simple and Secure by Design but Business compliant.

Le prix des adresses IPv4 publiques flambent!

C’est connu, l’IANA (Internet Assigned Numbers Authority), a alloué ses derniers blocs d’adresses IPv4 aux différents registars. On ne dispose donc plus de marge de manœuvre sur Internet pour l’affectation des adresses IPv4.

 

Lorsque nous nous connectons à Internet, il est nécessaire de disposer d’une adresse IPv4 publique directement ou indirectement (translation d’adresse). Problème, dès lors que la ressource devient rare, le prix flambe. Le cours de l’adresse IPv4 va donc flamber et Microsoft y contribue à sa manière avec le rachat des adresses IPv4 détenues par Nortel. Le rachat serait estimé à sept millions et demie de dollars. Ceci établit le cours de l’adresse IPv4 publique à environ onze dollars et vingt-cinq cents. Il est presque certain que Microsoft va très rapidement réutiliser ces adresses pour étendre les possibilités de ses services dans le Cloud.

 

Si on recherche un peu du coté des détendeurs des premiers blocs d’adresses IPv4 sur Internet, on va trouver un certain nombre de sociétés américaines qui sont assises sur une manne financière conséquente.

 

Nous sommes prévenus. Le cout de la connectivité Internet  va augmenter. Il faudra donc nous préparer à devoir utiliser une connectivité IPv6 très prochainement. IPv6 entrera donc dans l’entreprise par la porte de l’Internet (de manière sécurisée, cela va de soit! )

 

Benoits – Simple and Secure by Design but Business compliant.

IPv6 learning roadmap

IPv6 fait peur. Pourtant, un jour il faudra bien y passer et donc se former. Coté Microsoft, on peut attaquer le problème avec le “Pilier de toute bibliothèque Ikea”, à savoir l’ouvrage de Joes Davis.

image

C’est efficace mais terriblement assommant. Après, il y a une approche mois radicale, à savoir le IPv6 learning Roadmap. Microsoft y a regroupé un ensemble de ressources afin de pouvoir monter en compétence sur le sujet.

 

Bonne lecture.

 

Benoits – Simple and Secure by Design  but Business compliant!

Faut-il désactiver IPV6?

La couche réseau IPV6 est nativement intégrée au système d’exploitation depuis la génération Windows VISTA/ Windows Server 2008.

Le support d’IPV6 au sein même des produits Microsoft n’est pas encore complet. Autant l’implémentation “dual stack” ne pose pas de problème, autant, un certain nombre de produits ne sont pas supportés en implémentation “IPV6 Only”. De ce fait, la tentation est grande pour désactiver la couche réseau IPV6.

La question semblant revenir souvent, Stéphane PAPP a publié un billet fort intéressant: Arguments contre l’inactivation d’IPv6. On y apprend entre autre que :

  • La désactivation de la couche réseau IPV6 est assez simple mais sa réactivation est nettement plus complexe
  • Microsoft n’a pas testé le fonctionnement de ses systèmes d’exploitation dans un contexte ou IPV6 est désactivé, que ce soit partiellement ou totalement

Conclusion, il est plus que recommandé de conserver IPV6 activé.

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Tip troubleshooting DirectAccess et IPV6

Dans des configurations un peu complexes de DirectAccess, il peut qu’on soit amené à ne pencher plus avant sur IPV6 et plus particulièrement sur le routage IPV6. Lorsque le client DirectAccess ne peut accéder au réseau interne, cela peut avoir plusieurs causes :

  • Routage IPV6 défaillant
  • Résolution de noms DNS défaillante
  • Name Resolution Policy Table incomplète

 

Si on suspecte une problématique de résolution de noms DNS au travers de la Name Resolution Policy Table, le meilleur moyen reste d’accéder à votre serveur DNS IPV6. Normalement, une invite de commande avec “\\” suivi de l’adresse IPV6 devrait suffire?

image

Perdu! il faut utiliser sa forme “littérale” et cela fonctionne tout de suite mieux :

image

Pour transformer une adresse IPV6 en adresse littérale, il faut :

  1. Positionnant la séquence de caractères « \\ » comme préfixe (c’est un chemin UNC après tout!)
  2. Remplaçant les caractères « : » par « -»
  3. Puis suffixer le tout avec « .ipv6-literal.net »

 

 

Qu’est ce que cela prouve?

  1. Que le routage IPV6 n’est pas en cause
  2. Qu’il est bien possible d’accéder à notre réseau interne en IPV6
  3. Que le tunnel IPSEC “Utilisateur” est bien opérationnel

 

Conclusion : Mon problème est purement DNS. Causes probables :

  • Le serveur DNS est inaccessible
  • Le serveur DNS n’écoute pas sur son interface IPV6
  • La ressource à laquelle j’essaie d’accéder n’a pas d’enregistrement AAAA dans le DNS interne

 Note : Si on veut tester la connectivité depuis Internet Explorer, ce n’est pas la même notation. Il suffit simplement d’encadrer l’adresse IPV6 par des crochets pour que cela fonctionne.

Benoîts – Simple and Secure by Design (j’insiste sur le Secure)

DirectAccess coté client

Je finalise actuellement un post plus complet sur DirectAccess mais déjà les premiers résultats sont encourageants. Pour la mise en œuvre, cela demande un peu de travail. J’ai une plateforme qui fonctionne, reste maintenant à la documenter et expliquer le tout. Ce sera l’objet d’un prochain Post (prévoir beaucoup de temps pour le lire!)

Ce qui choque un peu, c’est de mettre un serveur directement sur Internet (le serveur Direct Access) mais on ne peut y échapper, IPV6, c’est la connectivité directe, donc pas de pare-feu ou translation d’adresse.

 

Quand la partie serveur est opérationnelle, coté client, c’est une simple GPO qui fait tout le travail. Je reviendrai sur le contenu de ces GPO ultérieurement. Voyons à quoi ressemble la configuration réseau pour commencer. Ma connexion Ethernet indique bien une connexion Internet mais on constate deux nouvelles interfaces (6to4 et IPHTTPS). La première est utilisée pour les encapsulations IPV6 en IPV4 sur les réseaux où on ne dispose pas de connectivité IPV6.Pour la seconde, c’est pour le cas où on ne dispose que d’une connectivité IP au travers d’un proxy (sans authentification).

DA0

Le véritable test, cela reste quand même de ‘”pinger” le contrôleur de domaine depuis depuis Internet (c’est le propre de la connectivité IPV6). Et bien, il répond mon DC! Etant donné que je suis en 6To4, les flux sont encapsulés, donc le TRACERT ne nous indique rien entre la source et la destination.

DA1

Le test final reste tout de même d’accéder à un serveur de fichiers situé dans mon réseau d’entreprise alors que je suis à l’extérieur. J’avais monté un lecteur réseau, il a été automatiquement remonté. J’ai accédé à mon fichier sans me poser de question. A aucun moment, on ne m’a parlé de VPN. DirectAccess, c’est transparent pour l’utilisateur final.

DA2

 

 

Dès que j’ai un peu de temps, je vais publier la mise en œuvre détaillée.  Pour monter la maquette, prévoyez un Hyper-V avec 8Go de mémoire vive comprenant :

  • Contrôleur de domaine
  • Serveur applicatif interne
  • Serveur DirectAccess
  • Serveur Web Internet
  • Poste client
  • Serveur Proxy ISA Server

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)