Depuis Windows 7 et Windows Server 2008 R2 (et les versions plus récentes), il est possible de faire une capture réseau avec netsh.exe

Voici comment prendre cette trace et comment l’analyser.

1. Prendre une capture réseau avec NETSH.exe

Tout d’abord, cette fonctionnalité n’existe que depuis Windows 7 et 2008 R2. Donc il est inutile d’essayer avec Vista, 2008, XP et 2003.

Pour prendre la capture il faut :

- Ouvrir une invite de commande avec privilèges élevés (exécuter en tant qu’administrateur)

- Lancer la commande suivante “netsh trace start capture=yes [persistent=yes]”

Dans cette commande, nous précisons capture=yes (sans espace dans la commande) pour capturer le trafic réseau sur l’ensemble des interfaces de la machine.

Le commutateur persistent=yes permet de prendre une trace au redémarrage d’une machine ce qui peut être très pratique.

Par défaut les captures sont sauvegardées dans C:\Users\<compte admin>\AppData\Local\Temp\NetTraces\NetTrace.etl

- Pour arrêter la capture, il suffit d’entrer la commande “netsh trace stop”

Penser à attendre que les traces soient corrélées, puis récupérer le fichier netTrace.etl

2. Comment lire une trace netTrace.etl ?

Par défaut Microsoft Network Monitor 3.4 est capable de lire les traces *.etl.

Cela nécessite quelques paramétrages pour que la lecture soit intelligible.

En effet, si la trace est directement ouverte, voici le type d’affichage :

Les descriptions apparaissent avec le commentaire “Windows stub parser: Requires full Common parsers. See the "How Do I Change Parser Set Options(Version 3.3 or before) or Configure Parser Profile (Version 3.4)"

Pour lire le contenu de manière correcte il faut aller dans OPTIONS :

Puis sélectionner l’onglet PARSER PROFILES et sélectionner dans la liste WINDOWS, et enfin, très important, cliquer sur SET AS ACTIVE pour activer l’affichage

Ensuite la vue est correcte pour la colonne description de l’outil Netmon

Ensuite, il est possible d’utiliser les filtres de Netmon pour maquer les vues et avoir ainsi une lecture plus facile.

Note: les traces réseau *.etl prises avec netsh.exe peuvent aussi être lues avec l’outil Microsoft Message Analyzer.

3. Autres options des captures avec NetSH.exe

- Utilisation des scenarii :

Il est possible d’ajouter à la capture des “providers WMI” qui vont collecter des informations sur les état des composants Windows, comme le pare-feu Windows, l’état du Wi-Fi, IPSec, etc. Pour cela il est intéressant de sélectionner un scenario pour la capture :

“netsh trace show scenarios” affiche la liste des scenarii disponibles et leur description :

Pour capture une trace réseau avec les ‘providers’ WMI (par exemple pour les scenarii NetConnection et WFP-IPSec), il faut alors utiliser la commande “netsh trace start scenario=NetConnection,WFP-IPSec capture=yes”.

Note : pour chainer les scenarii, il faut utiliser “,” (une virgule) comme séparateur, sans espace entre les scenarii et la virgule.

- Options de capture :

Il est possible de modifier le comportement par défaut des captures netsh avec les commutateurs suivants :

Alors bonnes captures !

Description :

Erreur 7054 avec le message suivant : "le nombre maximal d'ouverture de session autorise sous licence est atteint sur ce système. Veuillez recommencer ultérieurement." ("The system has reached its licensed logon limit. Please try later.") lorsqu'un administrateur essaye de prendre le contrôle à distance d'une session sur un Terminal Server Windows Server 2003.

Cette erreur peut survenir avec des licences d'accès (CAL) "par utilisateur" (Per User), et ce bien qu'un serveur de licence Terminal Server soit disponible, activé et correctement configuré.

L'origine de cette erreur est liée au certificat x509 utilisé par le serveur de licence Terminal Server qui a été activé par Internet (Activation Automatique). Ce certificat est signé avec un algorithme qui n'est pas correctement géré par le serveur Terminal Server 2003. Ce problème ne se produit pas avec Terminal Server Windows Server 2008 et versions ultérieures.

Solution :

- Installer le rôle TS/RDS (Remote Desktop Services ou Services de Bureau à Distance) Licensing sur un serveur 2008 SP2 ou 2008 R2 SP1 (après avoir installé tous les correctifs de sécurité via WSUS ou Windows Update).

- Activer le serveur de licence TS/RDS uniquement par téléphone. En effet, si l'activation est effectuée via Internet, le serveur de licence RDS/TS aura un certificat x509 du type "CN=Microsoft Assurance Designation Root 1 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" au lieu d'un certificat auto-signé. C'est ce certificat (CN=Microsoft Assurance Designation Root 1 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US) qui ne doit pas être téléchargé et installé.

- Ensuite il ne faut surtout pas activer le pack de licence "par utilisateur" via la procédure Automatique (Internet) pour 2003 mais uniquement via téléphone. Sinon le "mauvais" certificat sera dynamiquement téléchargé et installé depuis Internet.

- Enfin, il faut forcer les serveurs TSE 2003 à pointer sur ce serveur de licence TS/RDS après avoir purgé les certificats X509 en cache.

Pour forcer l'utilisation d'un serveur de licence TS :

- soit par stratégie de groupe dans "configuration ordinateur / Stratégie / Modèles d'administration / Composants Windows / Services Bureau à distance / Hôte de la session Bureau à distance / Gestionnaire de licences" avec "Définir le mode de concession de licences des services Bureau à distance" et "Utiliser les serveurs de licences Bureau à distance indiqués".

- soit dans le registre du serveur TSE 2003 dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers, créer une sous-clé pour le serveur de licence, soit en spécifiant le nom NetBIOS, soit le nom FQDN, soit l'adresse IP fixe. Par exemple cela donnerait pour un serveur de licence nommé RDSL2K8 :

Pour purger le certificat du serveur de licence TS/RDS stocké par le serveur TSE 2003

Il est recommandé de sauvegarder (exporter) les clés de registre avant de les modifier et/ou supprimer.

Il faut supprimer les trois valeurs suivantes, sur le TSE 2003, dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters , puis redémarrer le serveur TSE 2003 afin qu'il obtiennent les nouveaux certificats à partir du serveur de licence TS/RDS:

- REG_DWORD Certificate

- REG_DWORD X509 Certificate

- REG_DWORD X509 Certificate ID

Pour s'assurer que le serveur TSE a récupéré un certificat 'valide'

- double cliquer sur la valeur "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\X509 Certificate" et dans l'affichage du contenu le nom du serveur de licence TS/RDS doit apparaître et non pas un nom du type " Washington".

- Voici un exemple de certificat "correct" :

- Voici un exemple de certificat qui pose problème :

En respectant toutes les étapes, il sera possible de prendre le contrôle d'une session utilisateur par un administrateur sur un TS 2003.

Fonctionnement d’un serveur DNS avec des zones intégrées AD

les entrées DNS qui sont stockées et répliquées dans des zones intégrées Active Directory sont considérées comme des objets de la classe dnsNode.

Où sont stockées les zones DNS

Avec un serveur DNS Windows, les zones DNS peuvent être stockées dans des ‘fichiers à plat’ ou dans des partitions de l’Active Directory.

Pour les fichiers à plat, ces derniers sont stockés par défaut dans %windir%\System32\Drivers\etc, dans des fichiers dont l’extension est *.dns. Ces zones ne sont pas répliquées entre les contrôleurs de domaine et restent locales au serveur DNS.

Pour les zones DNS intégrées AD, elles sont stockées dans l’une des trois partitions Active Directory suivantes :

• ForestDNSZones (1 partition par forêt)
• DomainDNSZones (1 par domaine)
• La partition du domaine par défaut (1 par domaine).

Historiquement une zone DNS intégrée dans l’Active Directory, en niveau de fonctionalité compatible Windows 2000, ne pouvait être stockée que dans la partition du domaine par défaut (par exemple dans CN=MicrosoftDNS,CN=System,DC=contoso,DC=com). Cette partition est aussi nommée "legacy"

Depuis Windows Server 2003, il est possible de déplacer les zones DNS intégrées dans les trois conteneurs possibles.

Le changement se fait via l’interface graphique de la console de gestion du DNS, via les propriétés d’une zone DNS, ou, via la commande "dnscmd /ZoneChangeDirectoryPartition" (pour plus d'information "dnscmd /ZoneChangeDirectoryPartition /?") :

Enregistrements dynamiques versus statiques

Par défaut,il faut distinguer les enregistrements statiques (créés manuellement via la console de gestion DNS ou DNSCMD.exe), des enregistrements dynamiques (enregistrés par le client DNS, par le serveur DHCP, via les fonctions de dnsapi.dll).

Les enregistrements statiques n'ont pas d'information de temps (Timestamp ou Horodateur).

Les enregistrements dynamiques ont une information de temps qui permet de détecter leur obsolescence. Il faut que sur la zone DNS les enregistrements dynamiques soient autorisés : il existe trois options.

• La première option "Aucun" (None) ne permet pas les mises à jour dynamiques.
• La deuxième option "Non sécurisé et sécurisé" (Non secure - Secure) permet les mises à jour dynamiques sans authentifier le client DNS qui procède à la mise à jour.
• La troisième option "Sécurisé uniquement" (Secure only) implique que le client DNS soit authentifié avant d'être autorisé à procéder à la mise à jour dynamique.

Pour que le Timestamp des entrées DNS soit exploité, il faut définir des options de vieillissement (par zone DNS).

Pour visualiser le Timestamp d'un enregistrement DNS : via la console de gestion du DNS, après avoir sélectionné dans le menu "Affichage" l'option "Affichage detaillé" :

L'édition des propriétés de l'enregistrement, si dynamique, laisse apparaitre l'option "Supprimer cet enregistrement lorsqu'il deviendra périmé".

Options de vieillissement

Cette option se définit par zone DNS (zone de recherche directe ou inverse), dans les propriétés de la zone, via le bouton "vieillissement" (Aging) en définissant deux intervalles : "non-actualisation" (no-refresh) et "actualisation" (refresh).

Cette option est répliquée sur l'ensemble des serveurs DNS qui sont contrôleur de domaine.

L'intervalle "non-actualisation" est l'espace de temps pendant lequel l'enregistrement DNS est considéré comme valide sans qu'il soit nécessaire de le rafraîchir.

L'intervalle "actualisation" indique l'espace de temps pendant lequel l'enregistrement doit être rafraîchit pour rester valide.

Un enregistrement est considéré comme obsolète lorsqu'il dépasse la durée cumulé du "non-actualisation" et 'actualisation", soit par défaut 14 jours.

Passé le délai de 14 jours (par défaut) l'enregistrement est éligible à la suppression par le Scavenging.

Fonctionnement du Scavenging

Cette option n'est pas activée par défaut sur les serveurs DNS. L'activation se fait par serveur DNS : via l'option "Activer le nettoyage automatique des enregistrements obsolètes"

La recommandation est de l'activer sur un ou deux serveurs DNS maximum par forêt ou domaine (en fonction des conteneurs dans lesquels les enregistrements DNS sont stockés) Active Directory.

La fréquence de nettoyage est par défaut de 7 jours. Par conséquent, tous les 7 jours, le Scavenging va énumérer tous les enregistrements dynamiques (et jamais les enregistrements statiques) qui ont dépassé l'intervalle de "actualisation"+"non-actualisation" (en fonction des paramètres de vieillissement définis par zone DNS).

Ensuite le scavening supprime les enregistrements obsolètes en positionnant l'attribut dNSTombstoned=TRUE pour les objets dnsNode.

Un événement est ajouté dans le journal DNS ID 2501 : le nombre d'entrées supprimées est indiqué.

Que se passe-t-il après le scavenging ?

Par défaut le service serveur DNS n'affiche pas les objets dnsNode dont l'attribut dNSTombstoned=TRUE.

Pourtant, ces objets dnsNode restent dans l'Active Directory et sont visibles avec ADSIEdit.msc ou LDP.exe.

Ce n'est qu'après un intervalle de temps que l'objet dnsNode sera supprimé de l'Active Directory :

• 1 semaine par défaut pour Windows Server 2003
• 2 semaines par défaut à partir de Windows Server 2008 et versions ultérieures.

Lors de cette suppression l'attribut isDeleted de l'objet dnsNode sera passé à TRUE, et l'objet sera définitivement supprimé par le Garbage Collector au bout de 60 ou 180 jours (en fonction de l'attribut tombstoneLifetime de l'objet CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com).

Si l'objet dnsNode n'est pas immédiatement supprimé (isDeleted=TRUE) c'est pour laisser la possibilité de réutiliser l'objet dans deux cas :

• La machine (ou le service DHCP) envoie une mise à jour dynamique.
• Une entrée statique est créée avec le même nom.

Références

DNS Scavenging internals (or what is the dnsTombstoned attribute) for AD Integrated zones

Don't be afraid of DNS Scavenging. Just be patient.

1. Introduction

Dans le cadre du déploiement de stations de travail Windows Vista et/ou 7 et de serveurs Windows Server 2008 et/ou 2008 R2, IPv6 est installé par défaut. Pour autant votre infrastructure n’est pas forcément prête pour IPv6. Aussi seuls les plans d'adressage IPv4 sont en place dans l'environnement réseau. Vous avez la tentation de neutraliser IPv6. Cet article a pour but de définir quels sont les impacts et limites (au niveau du support) de désactiver IPv6, d'une part, ou comment prioriser les flux IPv4 par rapport à ceux IPv6, d'autre part.

2. Laisser ou retirer IPv6 ?

2.1    Position officielle de Microsoft sur la supportabilité d'IPv6

Microsoft ne recommande pas la désactivation du protocole IPv6, lorsque décoché dans les options d'une interface réseau, ou lorsque IPv6 est désactivé dans le registre (clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6).
Depuis Windows Vista et Windows Server 2008, IPv6 fait partie intégrante du système d'exploitation. De plus, le groupe produit n'a pas testé la désactivation d'IPv6.

Certains composants utilisent nativement IPv6 :
- Remote Assistance
- Windows Meeting Space (P2P)
- Homegroup
- DirectAccess
- Client Side Caching (offline files) et BranchCache (Windows Server 2008 R2 et Windows 7)

Ainsi en cas de désactivation d'IPv6, le support Microsoft sera limité. La première action demandée par le support est … la réactivation d'IPv6.

Par ailleurs certaines applications, autres que Microsoft, peuvent aussi avoir des prérequis sur IPv6.

2.2    Fonctionnement d'IPv6

Formation d'une adresse IPv6 : contrairement à IPv4, il n'existe pas d'adresse APIPA, mais une adresse IPv6 peut être formée soit à partir d'informations locales (adresse MAC de l'interface), soit par un bail DHCPv6, soit par un préfixe attribué par un équipement réseau.

• Configuration automatique par l'hôte d'une adresse 'local-link' pour chaque interface :
  • Découverte des routeurs (sollicitation des routeurs et analyse des messages d'annonce des routeurs) qui permet de  déterminer les adresses des routeurs voisins, les adresses 'stateless', les préfixes 'on-link' et autres paramètres de configuration.
  • Trois types de configuration :
    • STATELESS : la configuration de l'adresse IPv6 est basée sur la réception des messages  d'annonce des routeurs :
      • Managed Address Configuration : flag à 0
      • Other Stateful Configuration : flag à 0
      • Une ou plusieurs informations de préfixes
      • Autonomous : flag à 1
    • STATEFUL : la configuration est basée sur le protocole de configuration des adresses, comme DHCPv6, qui permet d'obtenir les paramètres de configuration. Un hôte utilise l'auto configuration STATEFUL quand il reçoit un message d'annonce d'un routeur (ou sans routeurs sur un lien local) :
      • sans option d'information de préfixe
      • Managed Address Configuration : flag à 1
      • Other Stateful Configuration : flag à 1
    • BOTH : la configuration de l'adresse IPv6 est basée sur la réception des messages  d'annonce des routeurs :
      • Managed Address Configuration : flag à 1
      • Other Stateful Configuration : flag à 1
      • Autonomous : flag à 1
  • Statut des adresses auto configurées :
    • Tentative : en cours de vérification si cette adresse est bien unique, pendant ce temps l'adresse peut recevoir des messages multicast
    • Valid : l'adresse peut être utilisée  pour recevoir du trafic unicast.
    • Preferred : l'adresse est valide et unique et peut être utilisée pour tout type de communication. Cette adresse reste dans ce statut le temps définit par le champ "preferred lifetime" correspondant à l'option d'information du préfixe du message d'annonce du routeur, ou l'option d'adresse DHCPv6 IA
    • Deprecated : Cette adresse est valide et unique. Elle n'est pas utilisée prioritairement pour les nouvelles communications. Les communications existantes continuent de transiter par cette interface.
    • Invalid : l'adresse n'est valide et ne peut pas être utilisée. La transition s'effectue lorsque la période définie par le flag 'lifetime' expire.
  • Processus d'auto configuration :
    • Tentative d'adresse locale (local-link) dérivée du préfixe local FE80::/64 et de l'identifiant EUI-64 dérivé de l'interface.
    • Vérification s'il n'existe pas de dupliqua de l'adresse avec envoi d'un message  "Neighbor Solicitation"
    • Si un message "Neighbor advertisement" est reçu (réponse au "Neighbor Solicitation") ceci indique qu'un autre hôte est dans le même processus et donc le processus d'auto configuration s'arrête. Dans ce cas il faut procéder à une configuration manuelle.
    • Si pas de message "Neighbor advertisement" reçu l'adresse est considérée comme unique et valide. Cette adresse est enregistrée pour l'adaptateur.

Exemple :

Wireless LAN adapter Wireless Network Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Intel(R) WiFi Link 5300 AGN Physical Address. . . . . . . . . : 00-21-6A-15-89-46 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2a01:e35:2f31:a90:8c9a:89e0:c75f:5ada(Preferred) => Ceci est une adresse IPv6 publique Temporary IPv6 Address. . . . . . : 2a01:e35:2f31:a90:b4f5:1d4c:3801:97d8(Preferred) Link-local IPv6 Address . . . . . : fe80::7c9a:89e0:c75f:5adb%11(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.100.25(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Monday, March 14, 2011 08:46:29 Lease Expires . . . . . . . . . . : Tuesday, March 15, 2011 02:46:29 Default Gateway . . . . . . . . . : fe80::224:d4ff:fead:6c9a%11 192.168.100.254 DHCP Server . . . . . . . . . . . : 192.168.100.254 DNS Servers . . . . . . . . . . . : 192.168.100.254 NetBIOS over Tcpip. . . . . . . . : Enabled Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : contoso.com Description . . . . . . . . . . . : Intel(R) 82567LM Gigabit Network Connection Physical Address. . . . . . . . . : 00-22-68-10-42-61 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::c0e:3ae3:e603:a029%10(Preferred) => Ceci est une adresse 'privée' non routable, non enregistrable dans le DNS IPv4 Address. . . . . . . . . . . : 8.8.7.11(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.128 Lease Obtained. . . . . . . . . . : Sunday, March 13, 2011 11:04:29 Lease Expires . . . . . . . . . . : Tuesday, March 15, 2011 14:14:41 Default Gateway . . . . . . . . . : 8.8.7.1 DHCP Server . . . . . . . . . . . : 8.8.7.9 DHCPv6 IAID . . . . . . . . . . . : 234889832 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-76-C7-5E-00-22-68-10-43-61 DNS Servers . . . . . . . . . . . : 8.8.7.3 8.8.7.8 NetBIOS over Tcpip. . . . . . . . : Enabled

• Tableau des préfixes IPv6 :

Estimation de l'impact d'avoir des adresses IPv6 :
-    il y aura plus de requêtes DHCP liées à IPv6.
-    Il n'est pas possible de désactiver la mécanique de recherche de serveur DHCP v4 par rapport à v6. Autrement dit, il n'est pas possible de débrayer uniquement DHCPv6.

2.3    Comment prioriser les flux IPv6 ?

Si IPv6 n'est pas utilisé (sur les réseaux internes, et non pas dans la zone Internet), il est possible d'optimiser le fonctionnement de Windows en priorisant par exemple IPv4. Ceci ne désactive pas IPv6, mais son utilisation devient secondaire (résolution DNS, etc.).

Pour cela il faut modifier sur les postes de travail Windows Vista et Windows 7, mais aussi sur les serveurs Windows Server 2008 et Windows Server 2008 R2 :

• la valeur DisabledComponents à 0x20
• dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters, comme décrit dans l'article KB929852.

2.4    Comment bloquer les enregistrements IPv6 dans les zones DNS ?

Pour bloquer un enregistrement AAAA dans les zones DNS (correspondant à une adresse IPv6) :

• Sur une interface réseau, éditer les propriétés IPv6
• Cliquer ensuite sur le bouton Advanced.
• Décocher l'option "enregistrer cette adresse de connexion dans le DNS" (Register this connection's address in DNS), puis sur OK    

Note : les adresses avec un préfixe FE80::/64 sont des adresses automatiques 'local link', non routables, et qui ne s'enregistrent pas dans le DNS.

2.5    Impact d'IPv6 ?

En synthèse :

• Contrairement à IPv4, les adresses IPv6 en fonction de leur préfixe, sont routables ou pas. Pour être plus précis, certaines adresses sont routables uniquement pour des réseaux internes, et d'autres vers des réseaux externes (voir tableau des préfixes IPv6).
• Par défaut toute machine avec le protocole IPv6 activé aura automatiquement une adresse commençant par FE80:: si les routeurs, commutateurs, ou DHCPv6 ne sont pas configurés pour IPv6. Cette adresse n'est pas routable. Elle n'est pas enregistrée dans le DNS.
• Si aucun scope DHCPv6 n'est configuré pour IPv6, alors aucune adresse IPv6 ne sera délivrée aux utilisateurs. Toutefois, par un mécanisme de découverte des clients, en fonction de certains équipements réseau, type routeurs, des adresses IPv6 peuvent être constituées par les clients.
• Les autres composants liés à IPv6 sont :
  • ISATAP : (Intra-Site Automatic Tunnel Addressing Protocol) est un mécanisme IPv6 de transition qui permet de transmettre des paquets IPv6 entre des machines ayant aussi le protcole IPv4, via ce dernier. https://en.wikipedia.org/wiki/ISATAP
  • TEREDO : permet d'encapsuler des paquets IPv6 dans des paquets IPv4 (via UPD). Ceci permet d'acheminer les paquets via des NAT. https://en.wikipedia.org/wiki/Teredo_tunneling
  • 6TO4 : permet de transmettre des paquets IPv6 via IPv4 sans utiliser de tunnels comme Teredo ou ISATAP. https://en.wikipedia.org/wiki/6to4
• Impact sur la volumétrie des flux, si IPv6 n'est pas implémenté au niveau des équipements réseau : faible, lié essentiellement aux requêtes DHCPv6 (non débrayable) et aux messages "Neighbor Solicitation".

2.6    Comment paramétrer les machines Vista/7/2008/2008R2 pour prioriser IPv4

2.6.1    Modification du registre sur les machines (Vista / 7 / 2008 / 2008 R2)

Aller dans HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP6\Parameters
Créer une valeur REG_DWORD : DisabledComponents à 0x20
Ne pas oublier que ceci est pris en compte au redémarrage de la machine.

2.6.2    Utilisation des stratégies de groupe Active Directory

Utiliser les fichiers contenus dans l'archive :

• Ajout des modèles de stratégie sur un contrôleur de domaine 2008 / 2008 R2
  • IPv6Configuration.admx – Copier ce fichier dans %SYSTEMROOT%\PolicyDefinitions sur le PDC Emulator
  • .\en-US\IPv6Configuration.adml – Copier ce fichier dans %SYSTEMROOT&\PolicyDefinitions\en-US sur le PDC Emulator
  • .\fr-FR\IPv6Configuration.adml – Copier ce fichier dans %SYSTEMROOT&\PolicyDefinitions\fr-FR sur le PDC Emulator

Attention : dans le cadre de l'utilisation des modèles de stratégies de groupe centralisées, il faut aussi copier les fichiers ici :

• IPv6Configuration.admx : copier ce fichier dans \\domaine\sysvol\domaine\policies\PolicyDefinitions
• .\en-US\IPv6Configuration.adml : copier ce fichier dans \\domaine\sysvol\domaine\policies\PolicyDefinitions\en-US 
• .\fr-FR\IPv6Configuration.adml : copier ce fichier dans \\domaine\sysvol\domaine\policies\PolicyDefinitions\fr-FR

Pour configurer la stratégie de groupe, il faut via la console de gestion des stratégies de groupe (GPMC) pour configurer les paramètres IPv6 :

• Aller dans Configuration Ordinateur > Stratégies > Modèles d'Administration > Réseau > IPv6 Configuration
• Editer la stratégie "IPv6 Configuration Policy"    
• Activer la stratégie, puis dans la liste déroulante choisir "Prefer IPv4 over IPv6"    

• Ajout des modèles de stratégie sur un contrôleur de domaine 2003
  • A partir des exemples du chaptire 5, créez le fichier adm qui correspond à la langue du contrôleur de domaine et via la GPMC :
    • Aller dans Configuration Ordinateur / Modèles d'administration puis via un clic droit, charger le fichier *.adm    
    • Ensuite dans Configuration Ordinateur / Modèles d'administration / Réseau / IPv6.
    • Dans le menu Affichage, choisir l'option Filtrage. Décocher les deux options : "afficher uniquement les paramètres de stratégie configurés" et "N'afficher que les paramètres de stratégie pouvant être entièrement gérés"    
    • Cocher l'option "activer", et dans la liste déroulante "Prioriser IPv4 par rapport à IPv6"

2.7    Interfaces 6TO4 dynamiquement créées

Lorsque nous utilisons une adresse IPv4 correspondant à une plage dite “publique” au sens RFC 1918, l’interface 6TO4 est dynamiquement créée. Attention : ces interfaces, dont l’adresse IPv6 commence avec le préfixe 2002::, s’enregsitrent dans le DNS avec des entrées HOST (AAAA). La conséquence est que les résolutions de nom se font par défaut prioritairement via IPv6 : ceci peut générer de la latence dans la résolution de nom et affecter la performance de vos applications.

Détail des plages d’adresse IPv4 considérées comme privées par la RFC 1918 :

Quelles sont les solutions pour bloquer, le cas échéant, les interfaces 6TO4 ?

2.7.1 Désactivation de l’interface 6to4 via une stratégie de groupe

La stratégie de groupe à paramétrer est la suivante :

- Computer configuration
   - Stratégies
      - Modèles d’administration
         - Réseau
            - Paramètres TCPIP
               - Technologies de transition IPv6
                  - Stratégie : “Etat 6to4” à positionner en “désactivé”

Attention, une fois appliquée la stratégie ne sera prise en compte par les machines qu’à leur redémarrage.

2.7.2 Désactivation de l’interface 6to4 via NETSH

Il est aussi possible d’utiliser la commande NETSH suivante pour désactiver l’interface 6to4 : “netsh interface 6to4 set state disabled”. Remarque : penser à lancer cette commande à partir d’un cmd ouvert avec élévation de privilège. Attention ce paramètre requiert un redémarrage de la machine pour effectivement être pris en compte.

2.7.3 Désactivation de l’interface 6to4 via le regsitre

Il est aussi possible de créer ou modifier la valeur REG_DWORD "Enable6to4" à 3 dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iphlpsvc\config. Attention ce paramètre requiert un redémarrage de la machine pour effectivement être pris en compte.

3    Conclusion

Pour rester dans un environnement recommandé par le support Microsoft, il ne faut donc pas désactiver IPv6, mais plutôt prioriser les flux IPv4.

Sur des postes Windows 7, Windows Vista et les serveurs Windows Server 2008 et 2008 R2, l'activation de la valeur DisabledComponents à 0x20, suivit d'un redémarrage, permet de ne pas avoir de soucis. Pour autant certains flux IPv6 persisteront comme les messages de découvertes et les requêtes DHCPv6.

De plus, afin d'anticiper une possible évolution de votre infrastructure, le fait de ne pas désactiver IPv6 permettra de minimiser les opérations lors de l'implémentation de scope DHCPv6 (par exemple) ou la mise en place de DirectAccess.

Enfin, lorsque la couche IPv6 est installée sur un poste Windows XP ou un serveur Windows Server 2003 (R2), il n’est pas possible de prioriser les flux IPv4. Ainsi les requêtes DNS se feront toujours d’abord sur des adresses IPv6 (enregistrements AAAA) puis sur des adresses IPv4 (enregistrements A) ce qui peut occasionner des latences. La valeur DisabledComponents n’existe pas pour XP ou 2003.

4    References

Concernant les préfixes IPv6, je recommande l'excellent article : https://technet.microsoft.com/en-us/library/dd392266(WS.10).aspx 
Concepts sur les passerelles IPv4/IPv6 : https://technet.microsoft.com/en-us/library/dd379548(WS.10).aspx 
Article intéressant sur la nécessité de laisser IPv6 avec Windows Server 2008 R2 : https://technet.microsoft.com/en-us/magazine/2009.07.cableguy.aspx

5. Modèles pour les stratégies de groupe

5.1. Windows Server 2008 et Windows Server 2008 R2 :

• Fichier IPv6Configuration.admx :

• Fichier fr-FR/IPv6Configuration.adml :

• Fichier en-US/IPv6Configuration.adml :

5.2. Windows Server 2003 (R2)

• Fichier IPv6-EN.adm :

• Fichier IPv6-FR.adm :

Suite à l'article "Fonctionnement des enregistrements dans des zones DNS intégrées Active Directory", voici une méthode pour mettre en place de l'audit et interpréter les résultats

Activation de l'audit sur les serveurs DNS (contrôleurs de domaine)

Pour que l’activation des audits soit opérationnelle, elle doit s’effectuer sur le contrôleur de domaine/serveur DNS et au niveau de la zone DNS.

Pour Windows 2003

- Se connecter sur un contrôleur de domaine.
- Cliquer sur Démarrer / Outils d'administration / Stratégie de sécurité du domaine
- Naviguer dans Stratégies locales, puis Stratégie d'audit
- Définir pour la stratégie Auditer l'accès au service d'annuaire en Réussite et Echec
- Refermer la console
- Rafraichir la stratégie via la commande gpupdate /force.

Pour Windows 2008 et versions ultérieures

- Ouvrir une invite de commande, avec les privilèges élevés, sur un contrôleur de domaine.
- Entrer les commandes suivantes :
Auditpol /set /category: “DS Access” /Success:Enable
Auditpol /set /category: “DS Access” /Failure:Enable

- Rafraichir la stratégie via la commande gpupdate /force.

Activer l'audit au niveau de la zone DNS

Identifier dans quel conteneur de l'Active Directory, la zone DNS est stockée

Les zones DNS, dans un Active Directory en mode fonctionnel 2000, sont obligatoirement stockées dans la partition du domaine.
Avec un niveau fonctionnel 2003 et ultérieur, il est possible de stocker les zones DNS dans des partitions 'applicatives' : ForestDNSZones et DomainDNSZones.
L'outil DNSCMD.exe permet d'identifier où se trouve la zone DNS.

La ligne de commande est : "DnsCmd <Serveur> /ZoneInfo <NomDeLaZone>" : dans l'exemple "DnsCmd contoso-dc1 /ZoneInfo contoso.com"

Modifier ou vérifier les permissions pour la mise en place de l'audit dans l'AD

- Ouvrir la console ADSIEdit.msc et pointer sur un contrôleur de domaine qui a les droits d’écriture sur la partition Active Directory dans laquelle est stockée la zone DNS à auditer.
- Faire un clic droit sur ADSI Edit, et choisir "Connexion" (Connect to..)

o Dans le champ "Nom" (Name), entrer par exemple Domaine, DomainDNSZones ou ForestDNSZones.
o Dans le champ "Point de connexion" (Connection Point) entrer le Distinguished Name de la partition dans laquelle la zone DNS est hébergée (voir point précédent avec dnscmd.exe). Par exemple DC=DomainDNSZones,DC=contoso,DC=com
o Cliquer sur OK

- Pour sélectionner la partition :

o Si la zone est stockée dans la partition du domaine par défaut:

Domain [(dc name).contoso.com]
   DC=contoso,DC=com
      CN=System
         CN=MicrosoftDNS

o Si la zone est stockée dans la partition applicative DomainDNSZones :

Domain(DNSZones) [(dc name).contoso.com]
   DC=DomainDNSZones,DC=contoso,DC=com
      CN=MicrosoftDNS

o Si la zone est stockée dans la partition applicative ForestDNSZones :

ForestDNSZones [(dc name).contoso.com]
   DC=ForestDNSZones,DC=contoso,DC=com
      CN=MicrosoftDNS

- Dans le conteneur CN=MicrosoftDNS vous allez trouver un sous-conteneur DC=<MaZoneDNS> (DC=contoso.com dans l'exemple)    

- Editer les propriétés du conteneur de la zone DNS.
- Dans l'onglet Sécurité, cliquer sur le bouton Paramètres avancés.
- Sélectionner l'onglet Audit et cliquer sur le bouton Ajouter.
- Entrer ensuite "Tout le monde" (Everyone) puis sur le bouton Vérifier les noms. Une fois le groupe vérifié, cliquer sur OK.

o Ecrire toutes les propriétés
o Supprimer
o Supprimer la sous-arborescence

- Cliquer sur Ok.

Collecter les événements d'audit sur les contrôleurs de domaine/DNS

Identifier le contrôleur de domaine sur lequel la suppression de l'entrée DNS a été supprimée

 

Pour cela il faut faire une requête sur les contrôleurs de domaine : par exemple si l'entrée détruite est "testdel2" alors la commande sera "repadmin /showobjmeta <nom-d'un-DC> <DN de l'objet>", soit par exemple "repadmin /showobjmeta contoso-dc1 DC=testdel2,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com"

Dans cet exemple, il est possible de déterminer que l'enregistrement testdel2 a été supprimé sur le contrôleur de domaine CONTOSO-VDC2 le 22 avril 2013 à 17h42'16".

Dans l'affichage de la ligne dNSTombstone, il faut récupérer le nom du contrôleur de domaine qui a modifié cet attribut. C'est sur ce contrôleur de domaine que l'entrée d'audit pourra être récupérée, en fonction du jour et de l'heure affichée.

Analyse de l'événement d'audit correspondant à la suppression de l'entrée DNS

Par la suite, il faut se connecter sur le contrôleur de domaine correspondant à l'événement 4662 (Windows Server 2008 et ultérieurs) ou 566 (Windows Server 2003), à la date et l'heure de la suppression pour visualiser correctement les détails de l'audit :

En surligné, nous avons le détail de l'enregistrement DNS supprimé et le compte utilisé pour faire la suppression. Dans l'exemple c'est le compte CONTOSO\dhcpsrvaccount qui a supprimé l'enregistrement testdel2.

Comment utiliser LDP.exe pour rechercher les objets dnsNode dont l'attribut dNSTombstoned est à TRUE

- Démarrer LDP.exe (outil des Support Tools Windows Server 2003, présent par défaut en 2008 R2). Attention, sur Windows Server 2008 et versions suivantes, lancer l'outil avec élévation de privilèges. 
- Choisir "Connexion / Connecter" (Connection / Connect) et entrer le nom d'un contrôleur de domaine sur lequel se connecter.
- Choisir "Connexion / Lier" (Connection / Bind) et entrer un compte member du groupe Administrateurs de l'Entreprise ou Administrateurs du Domaine en fonction de l'emplacement où la zone DNS est stockée dans l'Active Directory.
- Choisir "Affichage / Arborescence" (View / Tree) et entrer le DistinguishedName de la zone DNS, par exemple : DC=DomainDNSZones,DC=contoso,DC=com si la zone DNS est contenue dans la partition applicative DomaineDNSZones
- Dans la partie gauche de l'outil, double cliquer sur la racine de l'arborescence jusqu'à afficher la zone DNS.
- Une fois la zone DNS sélectionnée, via un clic droit, choisir l'option "Rechercher" (Search):     

Entrer comme filtre de recherche : (dNSTombstoned=TRUE), puis penser à sélectionner l'option de scope "sous-arborescence" (Subtree) puis cliquer sur "Exécuter" (Run).

Voici un exemple de résultat :

En sélectionnant dans la partie gauche de LDP un objet marqué comme supprimé, il est possible (via un double clic) d'afficher plus de détails :

Ceci nous indique quand le contrôleur de domaine à pris en compte le changement pour cet objet, ce qui correspond au moment de la suppression. L'intérêt peut être de réduire la période de temps à analyser pour collecter les événements 4662 ou 566.

Un enregistrement DNS peut être supprimé via l'une de ces méthodes : 

Scavenging :

Opération de nettoyage automatique de la base de donnée DNS, par serveur DNS => regarder dans les propriétés d'un serveur DNS via la console dnsmgmt.msc, onglet Avancé, option Activer le nettoyage automatique des enregistrements obsolètes)

Normalement pour le scavenging, il y a un événement dans le journal DNS, ID 2501 qui indique si le nettoyage a eu lieu, et qui donne des informations sur la quantité d'enregistrements nettoyés. Si l'événement 2501 correspond à l'audit 566/4662, alors cela signifie que l'enregistrement a été supprimé par le scavenging.

Dans ce cas seul l'attribut dNSTombstoned est marqué à TRUE

Suppression Manuelle via les fonctions de dnsapi.dll

Via la console DNS, en ligne de commande avec DNSCMD.exe, ou via une application/script.

Dans ce cas seul l'attribut dNSTombstoned est changé à TRUE.

Mise à jour dynamique

Lorsque une mise à jour dynamique avec un TTL=0 est effectuée. l'enregistrement DNS est supprimé.

Dans l'exemple d'une trace réseau ci-dessus nous avons la suppression de l'enregistrement IPv4 (A) par la machine elle-même lors de la mise à jour dynamique à jour de son entrée IPv6.

Du coup l'événement 4662 (566) indique que c'est le compte machine qui a supprimé son propre enregistrement :

Dans ce cas seul l'attribut dNSTombstoned est marqué à TRUE.

Suppression manuelle de l'objet dnsNode

Par exemple via LDAP (initié en utilisant ADSIEDIT.msc ou LDP.exe).

Dans ce cas, l'attribut dNSTombstoned n'est pas modifié, mais l'attribut isDeleted est passé à TRUE et l'objet dnsNode est renommé et déplacé dans un conteneur caché "Deleted Objects" :

Dans ce cas précis l'entrée 4662/566 sera légèrement différente ;

Définir la taille du journal d'événement Sécurité

Les audits sont stockés dans le journal d'événement Sécurité qui peut être très verbeux. Il est donc conseiller d'augmenter la taille du journal Sécurité pour obtenir au moins 1 jour d'historique. A défaut, il faudrait exporter via un script de manière régulièrement les événements 566 ou 4662 afin de pouvoir effectuer les opérations d'investigation.

Pour rappel : sous Windows Server 2003, la somme de la taille des journaux d'événements (tous confondus) ne doit pas dépasser 300 Mo afin d'éviter que certains événements ne soient correctement inscrit, ou, engendrer la corruption des journaux d'événements.

Dans certains cas il peut être utile voir indispensable de capturer le trafic réseau émis/reçu par une machine dés le démarrage du système (avant même l’ouverture de session Windows).

Sur les plateformes Windows 7 / Windows 2008 R2 il suffit d’exécuter la commande suivante pour lancer une capture du trafic dés le démarrage du système :

netsh trace start capture=yes persistent=yes

Plus d’information sur l’utilisation de Netsh dans ce contexte ICI.

Voici donc la marche à suivre pour les autres plateformes :

Prérequis :

SRVANY.EXE (Outils du Ressource Kit Windows 2003 - )

INSTSRV.EXE (Outils du Ressource Kit Windows 2003)

NETMON 3.4  : Installer Network Monitor 3.4 en mode « complet/full » .

“Install.bat” :

Le but de ce script est de créer un service et de l’associer avec le script “StartCap.bat” qui démarre une capture.

(Copier les commandes ci-dessous vers un nouveau document texte puis enregistrer le fichier sous le nom « Install.bat » )

@Echo off

c:\NMbootcap\INSTSRV.EXE NMBootCap c:\NMbootcap\SRVANY.EXE

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NMBootCap\Parameters /v Application /t REG_SZ /d c:\NMbootcap\startcap.bat

“StartCap.bat” :

Le but de ce script est de démarrer une capture du trafic sur toutes interface réseau disponible .

(Copier les commandes ci-dessous vers un nouveau document texte puis enregistrer le fichier sous le nom « StartCap.bat » )

Nmcap /network * /capture /file c:\NMBootCap\capture.chn:5M /TerminateWhen /Timeafter 10 min

Procédure :

1- Créer un répertoire « C:\NMBootCap », Copier tous les fichiers vers ce répertoire. (srvany.exe, instsrv.exe, install.bat, startcap.bat)

2- Ouvrir une invite de commande avec les droits d’administrateur local et exécuter la commande suivante :

C:\NMBootcap\Install.bat

A ce stade , notre Service “NMBootCap” est créé. Dés son démarrage une capture du trafic est lancée tel que définie dans le fichier “startcap.bap” .

3- Pour vérifier le bon déroulement de l’opération, via le gestionnaire de services, tenter de démarrer « NMbootCap ».

Lors du démarrage du service un fichier « C:\NMBootCap\capture.cap » doit être créé.

4- Redémarrer le système.

Arrêt de la capture :

Une fois lancée, la capture s’arrêtera automatiquement 10 minutes après le démarrage du service (comme configuré dans le fichier « StartCap.bat »)

Les données sont enregistrés dans des fichiers « chainés » de 5 Mo chacun (c:\NMBootCap\capture.cap, capture(1).cap, …).

“Nmcap /network * /capture /file c:\NMBootCap\capture.chn:5M /TerminateWhen /Timeafter 10 min”

Une autre méthode pour arrêter la capture  :

1- Arrêter le service NMBootCap via la commande « net stop NMBootCAP »

2- Puis « Tuer » le processus « nmcap.exe » via le gestionnaire de taches Windows.

Attention cette méthode rends inutilisable le dernier fichier de capture en cours d’écriture au moment de l’arrêt du processus nmcap.exe. Veiller donc à ce que la séquence intéressante ait bien été enregistrée dans un fichier de capture chainé distinct. (Pour accélérer la création de nouveaux fichiers de capture, vous pouvez générer du trafic en lançant une copie de fichier volumineux au travers du réseau par exemple.)

Plus d’informations  :

L’Art de Prendre des traces réseau en ligne de commande : https://blogs.technet.com/b/windows_networking_fr/archive/2010/10/15/l-art-de-prendre-des-traces-r-233-seau-en-ligne-de-commande.aspx

How to create a User-Defined Service : https://support.microsoft.com/kb/137890/en-us

Capturing a trace at Boot Up :https://blogs.technet.com/b/netmon/archive/2010/01/04/capturing-a-trace-a-boot-up.aspx

Souvent vous souhaitez avoir la possibiltié de faire des traces réseau sans avoir à charger une interface graphique complexe, ou créer des raccourcis sur un poste de travail pour que l'utilisateur puisse manuellement actionner une capture.

Voici donc quelques conseils pour capturer une trace réseau en utilisant Network Monitor 3.4 disponible ici : https://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en via l'exécutable nmcap.exe

Quelques conseils pour les traces réseau :

- Ne pas faire de trace dont la taille dépasse les 250/300 Mo. En effet, il devient ensuite très compliqué de lire ces traces tant elles sont volumineuses.
- Ne pas hésiter à jouer avec les filtres sur les interfaces réseau, les adresses IP ou les protocoles selon les besoins.
- En fonction de vos besoins, ou de vos contraintes, choisir des traces réseau circulaires ou chaînées.
- Identifier les interfaces réseau via la commande : "Nmcap /displaynetworks"

Trace circulaire :

Vous avez besoin de faire une capture sur une lognue période de temps et vous n'avez pas des tera de stockage à disposition. Dans ce cas une capture réseau circulaire s'impose.

Voici un exemple : "NMCap /network * /capture /file <chemin>\nom_de_la_trace.cap:250M /StopWhen /KeyPress x"

/network : permet de spécifier l'interface réseau à tracer. En cas de doute, mettez "*"
/file : indique le chemin et le nom du fichier circulaire dans lequel la trace sera sauvegardé
.cap est caractéristique d'une trace circulaire
:250M indique ici que la taille maximum de la trace (buffer) est de 250 Mo. La valeur par défaut est 20 Mo.
/StopWhen indique la condition d'arrêt de la capture réseau qui doit être suivit de la condition elle-même : "/KeyPress x" qui indique que le fait de presser la touche x suffit à arrêter la trace. On peut lui préférer une condition de temps du type : "/Timeafter 10 min" qui stipule qu'après 10 minutes, la trace s'arrête.

Trace chaînée :

Vous avez besoin de prendre une trace précise qui peut durer un certain temps, mais il faut que vous puissiez sauvegarder l'ensemble du trafic. Attention, prévoir de l'espace disque pour stocker les traces !

Voici un exemple : "NMCap /network * /capture ipv4.address == 192.168.1.1 /file <chemin>\nom_de_la_trace.chn:250M"

/network : permet de spécifier l'interface réseau à tracer. En cas de doute, mettez "*"
/file : indique le chemin et le nom du fichier circulaire dans lequel la trace sera sauvegardé
ipv4.address == 192.168.1.1 indique qu'un filtre sur l'adresse IPv4 est en place.
.chn est caractéristique d'une trace chaînée. Vous aurez donc des fichiers comme suit : nom_de_la_trace.cap, nom_de_la_trace(1).cap, nom_de_la_trace(2).cap, etc.
:250M indique ici que la taille maximum de la trace (buffer) est de 250 Mo. La valeur par défaut est 20 Mo.

Liste des filtres les plus utiles :

ipv4.address == w.x.y.z : permet de filter sur une adresse IPv4
dns or ldap or http : permet de filtrer les protocoles DNS, LDAP ou HTTP
tcp.port == 80 : permet de filtrer sur le port 80

Entre les filtres il est possible de mettre des conditions du style 'AND' voire 'OR' et encore 'NOT'. Par exemple vous souhaitez analyser uniquement le traffic SMB entre un poste de travail et un serveur, les options de filtres peuvent être les suivantes : SMB AND ipv4.address == w.x.y.z OR ipv4.address == a.b.c.d

Outil complémentaire très utile : NM3EventCap

 Cet outil disponible sur le site Codeplex. Regardez bien les pré-requis (runtime C#). Cet outil, il faut le noter est compatible sur les plateformes 32 bits (x86) et 64 bits (amd64 et x64) mais pas Itanium.

- Exemple de commande : "NM3EventCap_v1.0.exe c:\ms\2066.cap 2066 -b 256 -c -n 0"

–n x : où x correspond au numéro de l'interface réseau
2066 : exemple de numéro d'événement (peut importe qu'il soit dans le ournal système ou application ou encore sécurité) qu'il faut indiquer pour arrêter la trace réseau.
–b : est la taille de la trace en Mo (attention ne pas dépasser 300Mo sinon c'est difficilement lisible). La valeur par défaut est 100 Mo
–c : permet de chaîner les traces réseau au lieu d'utiliser une trace circulaire (attention : ceci implique que l'espace disque soit suffisant. Ce commutateur est facultatif).

- Note : laisser le cmd ouvert pendant toute la capture.

Pour plus d'informations :

Sur Netmon, : https://blogs.technet.com/b/netmon

Sur la méthode pour avec WIndows 7 et/ou Windows Server 2008 R2 faire une trace réseau dès le boot de la machine : https://blogs.technet.com/b/mrsnrub/archive/2009/09/10/capturing-network-traffic-in-windows-7-server-2008-r2.aspx

Bonjour,

Comme annoncé, voici des informations sur l’implémentation du composant de répartition de charge réseau (NLB) dans Windows. NLB est principalement utilisé pour les fermes de serveur Web ou de serveur ‘Terminal Serveur’. L’idée est de répartir les connexions entrantes entre les différents membres en prenant en compte soit l’affinité (pour les sessions Terminal Server, il est par exemple préférable de se reconnecter au même serveur TS en cas de déconnexion temporaire), soit de l’équilibrage de charge pure sans autre condition que la répartition des connexions. NLB n’est pas un produit aditionnel car inclus dans les ditributions de Windows Server. Le présent document permet de choisir en connaissance de cause l’architecture qui convient pour l’implémentation NLB, et non pas la gestion au quotidien du NLB.

1. Modes de fonctionnement de NLB pour Windows 2000 et 2003

Network Load Balancing peut être configuré selon l'un des quatre modes disponibles. Ce post décrit les modèles avec les avantages et les inconvénients ainsi que les différents scenarii.

1.1 Une seule carte réseau (Unicast)

Description

Une simple interface réseau peut avoir deux, ou plus, adresses IP associées à l'adresse MAC du cluster : une pour le trafic du cluster (par exemple les accès clients ou les battements de cœur – heartbeat – du cluster), et une autre dédiée au trafic hors cluster (par exemple administration des serveurs).

Points clés

· L'adresse MAC initiale de l'adaptateur est désactivée.
· L'adresse MAC du cluster NLB (générée avec un début type 02-BF puis une partie propre au cluster NLB) remplace cette adresse.
· Cette interface réseau devient l'adaptateur du cluster.
· L'adresse MAC du cluster résout à la fois l'adresse IP dédiée et l'adresse IP du cluster.
· Parce que tous les nœuds partagent la même adresse MAC, et parce que l'adresse MAC originelle n'est plus utilisée, la communication ordinaire entre les nœuds n'est plus possible. Toutefois, le serveur est toujours capable de prendre en compte le trafic issu d'un autre subnet dans lequel le cluster se trouve, et du même subnet si l'adresse MAC des paquets IP est différente de l'adresse MAC du cluster.

Scenarii

Serveurs de l'intranet – Pour les serveurs à faible volumétrie.
Serveurs Web – plus particulièrement pour les serveurs Web avec peu ou pas d'interaction avec des serveurs backend (contenu statique par exemple), et pas de nécessité d'interagir avec d'autres membres du cluster.

Avantages

· Une seule interface réseau est requise. Il est inutile d'installer une autre carte réseau.
· Nécessite le moins de configuration car Unicast est l'option par défaut.
· Fonctionne avec tous les routeurs.

Inconvénients

· La communication entre les nœuds d'un cluster n'est pas possible.
· La performance globale peut en souffrir sachant que le trafic du cluster et le trafic dédié au membre utilisent le même adaptateur réseau.
· Comme la communication du cluster et du membre transitent par la même interface réseau, il existe potentiellement un risque que le trafic de la communication du membre soit sniffée.

1.2 Plusieurs cartes réseau (Unicast)

Description

Deux ou plusieurs interfaces réseau avec une ou plusieurs adresses sont associées à une adresse MAC par carte réseau. Une carte est dédiée au trafic du cluster (accès clients et battements de cœur) et une autre carte réseau gère le trafic dédié (gestion distante du serveur ou accès à des ressources dans le back end).

Points clés

La première carte réseau est celle du cluster.

· L'adresse MAC originelle de la carte est désactivée.
· L'adresse MAC du cluster NLB (générée avec un début type 02-BF puis une partie propre au cluster NLB) remplace cette adresse
· Si l'adresse IP de la carte réseau dédiée est utilisée, elle est aussi résolue par l'adresse MAC du cluster.
· La carte réseau du cluster gère le trafic client vers cluster au travers de l'adresse IP virtuelle (par exemple l'adresse IP primaire). Si l'adresse IP dédiée est utilisée, la carte réseau peut aussi gérer le trafic en provenance d'autres segments réseau, ou du même segment si l'adresse IP utilisée correspond à une autre adresse MAC que celle du cluster.

La deuxième interface réseau est la carte réseau dédiée.

· L'adresse IP de cette interface correspond à l'adresse MAC de la carte réseau.
· La couche NLB est désactivée sur cette interface réseau.
· Cette carte réseau gère le trafic spécifique au serveur, incluant les connexions venant du même segment réseau dans lequel se trouve le serveur, ou d'autres.

Scenarii

Pour les serveurs Web Internet qui ont besoin d'accéder à des ressources en back end (type SQL). Les requêtes clients transitent par l'interface réseau du cluster, et contactent les ressources du back end via la carte réseau dédiée permettant d'améliorer les performances et la sécurité.
Pour les serveurs Intranet fortement sollicités : serveurs qui requièrent un temps de réponse optimal.
Par exemple Application Center 2000 a besoin d'une interface réseau dédiée au back end, pour la gestion du serveur et pour le trafic de réplication.

Avantages

· Améliore la performance globale à partir du moment où le trafic du cluster et celle de la carte dédiée transitent par des interfaces réseau distinctes.
· Permet la connexion entre les membres du cluster NLB.
· Fonctionne avec tous les routeurs.
· Améliore la sécurité sachant que les trafics du cluster et avec le back sont distincts.

Inconvénients

· Nécessite une deuxième carte réseau sur le serveur.

1.3 Une seule interface réseau (Multicast)

Description

Une simple interface réseau peut avoir deux, ou plus, adresses IP associées à l'adresse MAC du cluster : une pour le trafic du cluster (par exemple les accès clients ou les battements de cœur – heartbeat – du cluster), et une autre dédiée au trafic (par exemple administration des serveurs).

Points clés

· Le NLB génère automatiquement une adresse MAC pour la carte réseau de type 03-BF-xxxx.
· L'adresse MAC originelle de la carte réseau est retenue.
· L'adresse MAC correspond à l'adresse IP du cluster.
· L'adresse MAC originelle correspond à l'adresse IP dédiée du serveur.
· Parce que les deux adresses MAC il n'y a pas de contrainte de trafic.

Scenarii

Pour les serveurs Internet répliqués : serveurs internet qui répliquent des informations entre eux, sur un même segment réseau.

Avantages

· Une seule interface réseau est nécessaire.
· Permet la communication interne entre les membres du cluster.

Inconvénients

· Parce qu'il n'y a qu'une seule carte réseau, la performance globale du trafic peut s'en ressentir car tout transite par la même carte réseau.
· Certains routeurs peuvent ne pas supporter l'utilisation d'une adresse MAC pour le multicast qui correspond à une adresse IP unicast. Voir un peu plus loin pour la partie relative aux routeurs.
· Le trafic du cluster et dédié au serveur transitent par la même interface réseau, ce qui peut potentiellement présenter un risque (par exemple tout le trafic interne et externe utilisant la même interface réseau, il est potentiellement possible de sniffer les paquets).

1.4 Plusieurs interfaces réseau (Multicast)

Description

Deux ou plusieurs interfaces réseau associées à une ou plusieurs adresses IP ou une ou plusieurs adresses MAC par carte réseau. Une carte réseau est dédiée au trafic du cluster NLB. Les autres sont pour le trafic réseau dédié (accès aux ressources par exemple ou gestion distante).

Points clés

La première carte réseau est celle du cluster NLB.

· L'adresse MAC originelle est retenue pour la carte réseau.
· L'adresse MAC du cluster est associée à l'adresse IP du cluster (générée automatiquement par le NLB du type 03-BF-xx-xx-xx ou 01-BF-xx-xx-xx si IGMP est activé).
· Si l'adresse IP du cluster est utilisée (normal pour du multicast), cette adresse IP correspond à l'adresse MAC originelle de la carte réseau.
· La carte réseau du cluster, peut toutefois gérer le trafic client vers cluster, et le trafic spécifique du serveur, et ce pour le trafic en provenance du même segment réseau ou d'un autre segment.

La deuxième carte réseau est celle pour la communication dédiée du serveur.

· L'adresse IP correspond à l'adresse MAC par défaut de la carte réseau.
· Network Load Balancing est désactivé pour cette carte réseau.
· Cette carte réseau est dédiée au trafic du serveur incluant tous les segments réseau.

Scenarii

Ce modèle est idéal pour les clusters pour lesquels la communication interne est nécessaire, et dans lequel le trafic réseau est conséquent.

Avantages

· Optimise la performance globale car utilise plusieurs interfaces réseau.
· Permet la communication entre les membres du cluster.
· Les trafics du cluster et du serveur utilisent des interfaces réseaux distinctes améliorant la sécurité.

Inconvénients

· Nécessite une deuxième carte réseau.
· Certains routeurs ne permettent pas l'utilisation d'une adresse MAC de multicast associée à une adresse IP unicast.

2 Fonctionnement d'un cluster NLB

2.1 Communication interne du cluster NLB

Par défaut, chaque nœud d'un cluster informe ses partenaires de sa présence au travers d'un heartbeat. Ce heartbeat est envoyé sous forme de broadcast lorsque le cluster NLB est en mode Unicast, ou via Multicast, lorsque le cluster NLB est en mode Multicast. Ce heartbeat est envoyé toutes les secondes. Par défaut le protocole Ethernet de ce battement de cœur (heartbeat) est 0x886F (voir Chapitre 5.2)

Il est possible de modifier la fréquence via la valeur REG_DWORD AliveMsgPeriod dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parametres\Interface\{GUID}.

Il est aussi possible de modifier le nombre de non réception du heartbeat avant de considérer que le partenaire n'est plus présent dans le cluster NLB, qui par défaut est de 5, via la valeur REG_DWORD AliveMsgTolerance dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parametres\Interface\{GUID}.

2.2 Fonctionnement de la répartition de charge

Pour calculer la répartition de charge, l'adressage IP du cluster NLB se fait en 60 parts (buckets). Chaque membre du cluster (nœud) est en charge d'un certain nombre de buckets.

Tous les paquets entrant sont "hashed" dans le but de déterminer à quel bucket ils correspondent. Le nœud qui est en charge du bucket en question va accepter le paquet entrant. Les autres nœuds vont rejeter ce paquet (suppression) au niveau du filtre pilote NLB.

Ceci implique qu'un cluster NLB de 32 membres (le maximum), chaque membre ne pourra avoir qu'une ou deux connexion possible (1 ou 2 buckets).

Voici un exemple d'identification du Bucket (en jaune ci après) :

La commande ici est "wlbs filter <protocole> <IPclient>[:port] <IPcluster>[:port]"

2.3 Convergence

Lorsqu'un membre du cluster joint ou quitte le cluster NLB, une opération de convergence est lancée. Cette opération de convergence consiste dans la répartition des différents "buckets" entre les membres actifs du cluster NLB.

Lorsqu'une opération de type "drain", "disable" et "enable", le calcul de convergence est aussi lancé.

Pendant l'opération de convergence le battement de cœur sera inférieur à une seconde afin de permettre un calcul plus rapidement des membres actifs dans le cluster et ainsi la nouvelle répartition des buckets.

Voici les statuts pour la convergence envoyé via le heartbeat (voir chapitre 5.2) :

- 1 : convergence normale
- 2 : convergence calculée
- 3 : convergence en court

2.4 Affinités des clients

La gestion des affinités permet d'indiquer au cluster NLB comment procéder pour la ventilation du trafic entrant pour le cluster NLB en fonction des clients

None

Ce mode permet la meilleure répartition entre les différentes connexions TCP/UDP sur le cluster NLB. Dans ce cas, seule l'adresse IP du cluster et le port qui doivent être utilisés pour initier la connexion sont utilisés.

Single

Ce mode, essentiellement utilisé avec les serveurs Web en SSL, permet pour un même client d'ouvrir plusieurs sessions simultanées sur un même nœud. Dans ce cas, l'adresse IP est la seule utilisée pour les opérations de hashing (ventilation des connexions).

Class C

L'adresse IP est utilisée en considérant qu'elle est de classe C, comme par exemple 192.168.1.10.

3 Interaction du cluster NLB avec les équipements réseau

3.1 Les commutateurs (switches)

(Pour plus d'informations voir l'article KB193602)

Le but d'un commutateur (switch) est de réduire les broadcasts des paquets en apprenant l'adresse MAC (switch de niveau 2) ou l'adresse IP (switch de niveau 3) pour chaque port. Il permet ainsi de transférer directement les paquets sur les bons ports. Sachant que NLB implique que tous les membres du cluster puissent directement être joints via l'adresse MAC ou IP du cluster, il se peut que tous les membres du cluster ne puissent pas recevoir tous les paquets (limitation des switch de niveau 3). Il y a deux méthodes pour palier ceci :

Note : en mode multicast, le cluster utilise une adresse MAC de multicast qui correspond à une adresse IP unicast. De même en mode unicast, l'adresse MAC unicast pointe sur une adresse IP unicast. Les switches n'associent pas les adresses MAC multicast à un port et par conséquent le switch envoie les paquets vers cette adresse MAC sur tous les ports.

Masquer l'adresse MAC

Le paramètre par défaut pour le mode unicast du NLB est de masquer l'adresse MAC (MaskSourceMac=1). Ceci force le cluster à utiliser une MAC adresse virtuelle lorsqu'il envoie les paquets au switch. Le switch enregistre cette adresse MAC virtuelle et l'associe à un port, mais renvoie les paquets à l'adresse MAC du cluster, c’est-à-dire sur tous les ports du switch.

Si le switch n'a pas d'adresse MAC associé à un port, il envoie les paquets sur tous les ports. C'est ce que l'on appelle "port flooding" qui permet d'adresser les membres du cluster connectés sur ce switch. Dans ce cas le switch agit comme un hub.

Toutefois, si d'autres machines sont connectées sur ce switch, il est possible de minimiser le "port flooding" en isolant la configuration cluster NLB dans un VLAN ou un hub. Dans ce cas la configuration à une meilleure bande passante et élimine ainsi toutes les collisions. Le seul inconvénient est que cela ne fonctionne qu'avec les switch de niveau 2.

3.2 Les Hubs

Reconfigurer la valeur MaskSourceMAC=0 sur tous les membres du cluster. Connecter tous les membres sur le hub et connecter le hub à un switch. Ceci permet au switch d'apprendre les adresses MAC du cluster NLB, éliminant ainsi le "port flooding" sans avoir à recourir à un VLAN. Cette configuration est limitée par la bande passante du hub. Toutefois ceci minimise les collisions et fonctionne avec les switches de niveau 2 et de niveau 3.

Si vous disposez d'une autre interface réseau pour le front end connectée sur le même segment réseau, il suffit de connecter cette interface directement sur le switch.

3.3 Les routeurs

Le NLB peut fonctionner de deux manières : unicast et multicast.

Le support de l'unicast est activé par défaut, afin de s'assurer que cela puisse fonctionner avec tous les routeurs.

Vous pouvez choisir d'implémenter le mode multicast ce qui permet d'éviter d'avoir une deuxième interface réseau pour les connexions internes du cluster. Si les clients NLB doivent accéder au cluster (configuré en mode multicast) via un routeur, il faut être sûr que le routeur accepte les réponses ARP (Address Resolution Protocol) correspondant à l'adresse IP du cluster (unicast) avec une adresse MAC de type multicast dans le payload de la structure ARP. ARP est un protocole TCP/IP qui utilise un broadcast restreint sur le réseau afin de résoudre les adresses IP. Ceci permet à un routeur de faire correspondre l'adresse IP primaire du cluster et des autres adresses (multihomed) à l'adresse MAC. Si le routeur n'a pas n'a pas de prérequis en ce sens, il est possible d'utiliser une entrée ARP statique dans le routeur, ou de laisser le cluster NLB dans sa configuration unicast par défaut.

Certains routeurs requièrent d'avoir une entrée ARP statique parce qu'ils ne supportent pas une résolution d'une adresse IP unicast en MAC multicast. Par exemple, les routeurs Cisco requièrent une entrée ARP pour chaque adresse IP virtuelle. Cisco enregistre les différentes adresses MAC dans des CAM (Content Addressable Memory). Comme le NLB utilise le multicast de niveau 2 pour délivrer les paquets, l'interprétation par Cisco des RFC est stricte : les adresses IP multicast sont uniquement pour le multicast. Par conséquent le routeur ne voit pas d'adresse IP multicast, et donc ne peut pas créer automatiquement les entrées ARP dans le CAM, et c'est pourquoi il faut les ajouter manuellement.

3.4 Les pare-feu (firewalls)

Si le pare-feu agit aussi comme proxy du trafic client, il va identifier que toutes les connexions proviennent de la même adresse IP, et si la règle du NLB est configuré en affinité "single", tout le trafic réseau sera dirigé vers le même membre du cluster. Pour contourner ceci, il faut débrayer la translation d'adresse (proxying) sur le pare-feu, ou changer le mode d'affinité à "none".

4 Questions fréquentes

Le NLB fonctionne-t-il correctement avec les commutateurs ?

Comme le NLB utilise des adresses IP et MAC virtuelles, il peut y avoir des associations incorrectes par les commutateurs avec les adresses MAC (niveau 2) ou les IP (niveau 3) d'un cluster NLB en fonction des ports utilisés. Il existe plusieurs méthodes pour prévenir ce phénomène :

- L'une d'elle est de connecter les nœuds sur un Hub qui lui-même est connecté au commutateur (de niveau 2 ou 3)

- L'autre est de masquer l'adresse MAC du NLB (commutateurs de niveau 2 exclusivement). Cette option a pour effet que le commutateur lorsqu'il doit envoyer les paquets au cluster NLB le fera sur tous les ports. C'est ce que l'on appelle "port flooding". L'effet peut être limité si le cluster NLB est confiné dans un vLAN ou via un hub.

Le NLB fonctionne-t-il correctement avec les routeurs ?

NLB est compatible en mode Unicast avec tous les routeurs. Toutefois, lorsque le mode Multicast est implémenté, il peut y avoir des limitations avec des équipements type CISCO. Dans ce cas, il faut sur le routeur ajouter des entrées ARP statiques.

NLB est-il compatible avec les réseaux token-ring ?

Non car il n'est pas possible d'avoir plusieurs machines ayant la même adresse MAC.

Est-il possible d'avoir sur un même nœud plusieurs interfaces réseau déclarées dans NLB ?

En Windows 2000 ce n'est pas possible

En Windows Server 2003, la réponse est oui si les interfaces sont dans des clusters NLB distincts. Il n'est pas possible d'avoir deux, ou plus, interfaces réseau sur un même serveur qui soient déclarées dans le même cluster NLB.

Un nœud disposant d'une seule interface réseau peut-il fonctionner dans un cluster NLB

Oui, un nœud disposant d'une seule interface réseau peut fonctionner dans un cluster NLB. Toutefois, si le mode de fonctionnement est Unicast, ce nœud ne sera pas à même de 'communiquer' avec les autres nœuds du cluster NLB.

Est-il possible d'utiliser NLB sur une carte réseau avec du Teaming ?

Oui sous certaines conditions. Il faut en effet que sur la carte réseau virtualisée par le Team, il soit possible de modifier l'adresse MAC. Dans ce cas il faut faire référence à l'article KB278431.

NLB fonctionne-t-il avec des serveurs Web qui sont 'multihomed' ?

Oui car il est possible d'associer plusiers adresses IP à plusieurs serveurs Web et d'utiliser NLB pour répartir le trafic entre.

Un seul serveur répond-il à la connexion TCP 'handshake' ?

Un seul nœud du NLB répond au TCP handshake d'une connexion entrante. Cela signifie qu'un client qui se connecte sur le cluster NLB va contacter l'un des nœuds, établir sa connexion TCP et démarrer sa session. Ensuite le client restera avec la session sur ce nœud jusqu'à la fin de la session ou la déconnexion.

Comment configurer un cluster NLB sur VMWare ESX ?

Avec un serveur ESX, le VMkernel envoie un paquet RARP à chaque action particulière (par exemple, qu'une machine virtuelle est démarrée, lors d'une bascule du teaming, effectue certaines opérations type VMotion, etc.). Le paquet RARP notifie le switch de l'adresse MAC de la machine virtuelle. Dans un environnement de cluster NLB, cela revient à donner l'adresse MAC de l'interface réseau du cluster NLB aussitôt que le nœud du cluster NLB démarre. Ceci peut avoir pour cause que tout le trafic entrant passe par un seul et unique port du switch vers un seul des nœuds du cluster NLB.

Afin de prévenir cette mécanique, voici les étapes à effectuer sur le(s) serveur(s) ESX afin qu'il(s) n'envoie(nt) pas de paquet RAPR lorsqu'une machine virtuelle démarre.

1> Implémenter la solution cluster NLB en mode Multicast. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

2> Débrayer Net.NotifySwitch

3> Ajouter une adresse MAC statique correspondant à l'adresse IP virtuelle. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006525

Pour plus d'informations : https://www.vmware.com/files/pdf/implmenting_ms_network_load_balancing.pdf

5 Gestion et administration

5.1 WLBS.exe

Filtre

Il est possible de vérifier quel nœud va traiter une connexion entrante sur un port précis :

Par exemple pour déterminer sur quel nœud d'un cluster NLB (ayant pour IP 172.16.1.118) un client (adresse IP 172.16.1.19) va se connecter au port 80 pour accéder à une page web : " wlbs filter TCP 172.16.1.19 172.16.1.118:80"

Le résultat est présenté ainsi :

5.2 Comment capturer dans une trace réseau les paquets relatifs aux heartbeat ?

Par défaut, le pilote NLB est avant le pilote tcpip.sys et par conséquent, tout le trafic concernant le heartbeat n'est pas transmis par la couche NLB à la couche TCP. Il faut par conséquent activer une clé de registre pour autoriser la couche NLB à transférer tous les paquets à la couche TCP :

Il faut positionner la valeur NetmonAliveMsgs (REG_DWORD) à 1. Ensuite, pour que cela soit pris en compte, il faut recharger la configuration du NLB (en ligne de commande : "nlb reload")

- Pour Windows 2003 Server la clé de registre (REG_DWORD) est du type : HKLM/System/CCS/Services/WLBS/Parameters/Interface/<GUID>/NetmonAliveMsgs
- Pour Windows 2000 la clé de registre(REG_DWORD) est du type : HKLM/System/CCS/Services/WLBS/Parameters/NetmonAliveMsgs

Exemple de trace réseau relative au heartbeat :

- Heartbeat 'normal' :

- Heartbeat "extended" :

6 References

Network Load Balancing : Frequently Asked Questions for Windows 2000 and Windows Server 2003

https://technet.microsoft.com/en-us/library/cc758834.aspx

Troubleshooting NLB :

https://download.microsoft.com/download/3/2/3/32386822-8fc5-4cf1-b81d-4ee136cca2c5/NLB_Troubleshooting_Guide.htm

Considérations générales :

https://technet.microsoft.com/en-us/library/cc778400(WS.10).aspx
https://technet.microsoft.com/en-us/library/cc758834(WS.10).aspx
https://technet.microsoft.com/en-gb/library/bb742455.aspx
https://www.microsoft.com/windows2000/docs/NLBtech2.doc

Articles de la base de connaissance :

193602 Configuration options for WLBS hosts connected to layer 2 switches
https://support.microsoft.com/default.aspx?scid=kb;EN-US;193602

247297 Network Load Balancing Connection to a Virtual IP Address Not Made Across a Switch
https://support.microsoft.com/default.aspx?scid=kb;EN-US;247297

323437 How To Configure Network Load Balancing Parameters in Windows Server 2003
https://support.microsoft.com/default.aspx?scid=kb;EN-US;323437

Prochainement vous y trouverez des informations utiles pour répondre à la plupart de vos questions génériques sur les technologies comme le NLB (Network Load Balancing), les Offline Files, WebDAV, les particularités liées aux nouvelles versions de Windows.

Les membres de l'équipe française de support 'Windows Networking' veulent vous partager leurs recommandations et leur expérience, en se basant sur les problèmes généralement rencontrés. Nous ne manquerons pas de vous donner le plus régulièrement possible des informations sur les mises à jour les plus recommandées impactant les composants réseau.

N’hésitez pas à vous abonner au fil RSS et à nous partager vos commentaires, nous serons heureux de vous répondre !

L’équipe de Support Windows Networking.