jeudi 30 août 2012

Windows Server 2012 - DirectAccess Part 2

Accrochez-vous, il va y avoir de l'IPV6

Aujourd'hui, nous allons rajouter un prefix IPV6 dans notre LAN : 2abc::/64
Pour simplifier, le "dernier octet" sera identique au dernier octet de l'ipv4.
Le dc aura l'ip 2abc::1/64
Edge1 aura l'ip 2abc::11/64 (et non pas 2abc::B/64, je simplifie au maximum ;) )
J'ai également supprimer le record ISATAP.




Regardons les différences que cela entraîne.
Déjà dans l'ip obtenu pour les client directaccess. Celle-ci est basée sur le prefix IPv6 en interne. Il vaut donc mieux éviter d'utiliser l'ipv6 monprefix:1000::/64 dans nos reseaux ipv6 sinon il y aura des petits soucis de routage par défaut ;)



S'il n'y a pas d'ipv6 sur le lan du serveur directaccess, le prefix qu'utilise le serveur directaccess pour les ips des clients est base sur l'ip 6to4.


Bien sur, cette fois-ci les résolutions dns sont en IPV6.


Le dns dans la table NRPT pointe sur l'ipv6 interne du serveur et non plus une ipv6 basée sur le prefix 6to4.


Bien sur les gpo ont été mises a jour pour permettre d'ouvrir des tunnels IPSec sur le prefix 2abc::/48


Et voila, c'est tout pour l'ajout d'IPV6!

mercredi 29 août 2012

Windows Server 2012 - DirectAccess Part 1

Hello,

Je me suis fait une petite maquette directaccess sur server 2012. Le but de cette architecture est d'avoir une ferme DirectAccess de serveur 2012 en NLB.

Cette première partie concerne la mise en place d'un seul serveur DirectAccess. La mise en place de la ferme sera effectuée plus tard.

Voici l'architecture



L'ip du DC est 192.168.11.1
L'ip de la PKI (qui fait egalement office de nls) est 192.168.11.20
Enfin le serveur directaccess a l'ip interne 192.168.11.11. En externe, le serveur a les ip 178.22.145.226 et 178.22.145.227.
Il y a un firewall en bridge devant le serveur directaccess.
Le domaine est labda.local.

Maintenant que l'architecture est présentée commençons l'installation du serveur EDGE1.

Un record isatap a ete crée pointant sur 192.168.11.11, et le record isatap a ete supprime de la liste bloquée.



Au passage, pourquoi isatap est un record dns bloqué par defaut? Car si jamais un poste se nomme isatap, il va s'enregistrer dans le DNS est devenir le routeur Isatap du reseau. Cela peut entrainer des attaques de  Man-In-The-Middle.

Ensuite passons vraiment a l’installation de directaccess. On commence par installer la feature.
L'url pour IPHTTPS est da35094.cloud1.fr
L'url du NLS est nlsda.labda.local

Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress da35094.cloud1.fr -ClientGPOName "labda.local\DirectAccess Clients GPO" -ServerGPOName "labda.local\DirectAccess Servers GPO" -InternalInterface LAN -InternetInterface INTERNET -NLSURL https://nlsda.labda.local –Force –PassThru



Petite remarque, il va trouver le certificat IPHTTPS correspondant tout seul, comme un grand!
Choisissons la CA a utiliser pour les tunnels IPSec. (merci a Benoît SAUTIERE pour cette joli technique ;) )

$CA = (Get-ChildItem Cert:\\LocalMachine\Root | Where {$_.Subject -like "CN=labda*"})
Set-Daserver -IPSecRootCertificate $CA -PassThru


Vérifions que tout est bien installe avec un get-daserver.



OK, tout est la! Tiens TeredoState : Disabled... On y reviendra plus tard!
Verifions aussi le NLS.


Parfait, passons maintenant a la configuration du client et on supprime le filtrage WMI
Choix du groupe :

Add-DAClient –SecurityGroupNameList “labda.local\GG_DA”
Set-DAClient –OnlyRemoteComputers Disabled

Il ne reste plus qu'a tester sur notre windows 8!!
Premièrement verifions la table NRPT. Netsh na sh eff


Maintenant testons d’accéder a un partage réseau.


OK ca marche!

Bon, en theorie, si je ping dc.labda.local, je resous l'ip isatap! Vérifions


C'est quoi cette ip? C'est pas une isatap... Ca finit par l'ipv4 du contrôleur de domaine... Bon ben ca doit être une ip DNS64... Et donc ça veut dire qu'il fait du NAT64...
Vérifions ce qu'il se passe avec un trace réseau. (Wireshark veut pas s'installer sur Server 2012, on va donc utiliser network Monitor)
On voit bien que la requete relayée par le serveur directaccess ne demande qu'un record IPv4.


De plus, on voit egalemement qu'un ping envoyé par un client directaccess (donc en IPv6) , est relaye par le serveur directaccess en IPv4. Nat64 en action!


Ca me pose un leger probleme. Microsoft a toujours dit que Nat64 et DNS64 étaient des processus gourmands... Cela me parait étrange que maintenant le Nat64 soit pas default s'il n'y a pas d'ipv6 sur l'interface interne du serveur....

Mais moi je suis tetu et je veux mes résolutions en ISATAP! Comment faire... tout simplement ne plus utiliser le seveur UAG en tant que DNS dans la table NRPT, donc plus de Nat64 et de DNS64...



Et maintenant, la table NRPT ressemble a ca :


On voit que 192.168.11.1 est devenu fd06:5990:21b1:7777::c0a8:b01 : c'est l'adresse DNS64
Bon, on va pinger dc.labda.local.



Et voila, c'est bien l'ip Isatap!

Autre point interessant. Si je fais un ipconfig /all, je vois que je suis connecte en IPHTTPS. Ce n'est pas normal, cela devrait etre en Teredo, vu que Teredo est préféré (sous UAG/2008) a IPHTTPS



Regardons l’état de l'interface teredo.



Étrange elle est dans sa configuration par défaut. Si on reprend notre get-daserver du début, on remarque que TeredoState : Disabled. Essayons de l'activer.
set-daserver -TeredoState enabled


On update nos GPO, et après : miracle teredo is working.


Par contre directAccess ne marche plus trop, faut que je creuse pourquoi...


EDIT : IP-HTTPS est desormais prefere car server 2012 peut utiliser une null encryption. Ce qui veut dire que le flux n'est cryptee qu'une seule fois (par ipsec). Cela ameliore donc nettement les performances de IPHTTPS. Bon a savoir!

Et voila c'est fini pour aujourd'hui. Prochaine étape, NLB!


lundi 27 août 2012

VMWare 5.1... Enfin du neuf au niveau du reseau!!

Avec la nouvelle release ESX 5.1, de nouvelles fonctionnalites reseau apparaisent! Des fonctionnalités que l'on attendait depuis longtemps!!!

Premierement, support du protocole LACP. On l'attendait vraiment depuis un moment. Plus obligé de faire des port-channel en static (ou trunk suivant les constructeurs ;) ) pour profiter de toute la bande passante. En plus couplé a du VPC (ou distrbuted trunking suivant les constructeurs ;) ), on va pouvoir enfin utiliser le vrai potentiel des nos équipements réseau! En même temps avec la sortie de server 2012 et son teaming de carte intégré, vmware était bien obligé de faire quelque chose! A vérifier si c'est supporté par les switchs standard

Deuxièmement, BPDU filter au niveau des VMs. Dans un monde de vm hosted, c'est plutôt cool. Avec du BPDU Gard, ça pouvait vraiment être destructeur...

Troisièmement, Network Health Check. Permettra de vérifier si les switchs physiques sont bien configures! Permet de voir si les vlans, la MTU et les teaming. Je vois pas trop ce qu'il vérifie pour les teaming mais bon, on verra bien quand des docs sortiront.

Sinon les autres améliorations sont :
  • Distributed Port – Auto Expand. Pour résumer permet de modifier la politique d'association des uplinks a la VM. Inutile, désormais il y a LACP! (Enfin faut quand même gros switchs si on veut de la redondance :) )
  • MAC Address Management. Permet de mettre n'importe quel OUI dans la mac de la VM. Utile pour les tres gros déploiement, enfin les vraiment tres gros gros deploiement... Avec un domaine de broadcast énorme...
  • Port Mirroring (RSPAN and ERSPAN)
  • NetFlow Version 10 (faut bien concurrencer hyper-v 3)
  • SNMP v3 support
  • Backup des confs des VDS
En conclusion, c'est du tout bon! Reste plus qu'a savoir un truc, qu'est-ce qui est supporté avec des switchs standard?

A bientôt!

samedi 25 août 2012

Comment fonctionne la Freebox TV

Bon ce matin j'ai enfin pris un peu de temps pour voir ce qui se passait entre la freebox et la freebox TV.

J'ai donc connecte un Ciscon 3560 entre la box et le boitier tv.
La box est connectée au port fa0/9
Le boitier TV est connecte au fa0/11
Mon poste capturant le trafic est sur le port fa0/2

J'ai configure un port mirroring sur le port du boitier TV.


J'ai desactive tout ce qui pouvait faire du bruit sur le port mirroring

  • Le cdp
  • Le spanning-tree
  • Le keepalive
  • Le DTP
Et la j'ai commence mon port mirroring.... et je ne voyais rien.... bizarre....

J'ai donc connecte la freebox tv directement a mon portable pour voir si la freebox tv envoyait des paquets. 
Je recevais bien des paquets DHCP. En les examinant plus attentivement, j'ai vu que ces paquets étaient taggues avec le vlan 100! Les paquets sortant de la freebox TV sont donc taggues...



Ok donc c'est ça le problème. J'ai configure les ports en mode trunk et créé le vlan 100.



Et voila, ça marche! 
Bon maintenant on va analyser tout ça... Malheureusement c'est moins intéressant que je ne le pensais... pas d'IGMP pour des abonnements aux chaines.... Juste de l'ESP et du flux vidéo. 

Je pense que l'ESP est une sorte de canal de contrôle pour que free sache quel flux vidéo envoyer a la Freebox... Le flux ESP est entre la freebox et le boitier TV. Chose intéressant, il n'y a pas d'ISAKMP, directement ESP

Le flux Vidéo est toujours le même flux UDP (même port source/destination) qu'importe les chaines regardées... Le flux Vidéo est entre la freebox et le boitier TV.

J'image donc que toute l’intelligence d'abonnement multicast se situe plutôt entre la box et le backbone de Free... La box doit être le vrai client IGMP.

Et bien voila c'est tout, un peu déçu quand même, je m'attendais a du bon flux multicast, peut-être en IPv6 vu que c’était Free! Et non, rien de tout ca... 

A bientôt pour de nouvelles aventures, je l’espère plus intéressantes!! (surement DirectAccess sur une ferme Server 2012 )

vendredi 24 août 2012

C'est parti!

Et bien encore un blog de plus sur l'IT. Ce blog parlera principalement des technologies Microsoft Lync, Forefront UAG/TMG et bien sur, un peu de Cisco.
De bref passage de firewalls Netasq ou de Load-Balancer F5 peuvent survenir...
Et je ne sais toujours pas si je ferai mes articles en francais ou en anglais...

See you soon!