Types de nœuds TCP/ IP et connexion client

Lorsque vous créez un domaine multisite qui est routé sur plusieurs sous-réseaux, vous pouvez supposer que le fait de placer un contrôleur de domaine de sauvegarde sur un site distant garantira que les clients de ce site seront validés localement. Le but, bien sûr, est double: réduire le trafic qui sortira du réseau local sur une liaison coûteuse et s’assurer que les connexions client ne sont pas retardées par la vitesse (ou l’absence de celle-ci) de la connexion WAN. L’installation d’un contrôleur de domaine local peut en effet fonctionner, mais ce succès sera-t-il dû à la conception ou par accident ?
Malheureusement, il n’y a aucun moyen de spécifier le contrôleur de domaine qui validera un client donné, que ce client exécute Windows NT Server, Windows NT Workstation ou Windows 9x. Les versions précédentes de Windows fonctionneront de la même manière, à condition qu’elles utilisent la pile TCP/IP 32 bits ou une pile TCP/IP 16 bits compatible WINS.
Dans cet exercice quotidien, nous vous donnerons un aperçu des processus impliqués. Nous expliquerons également pourquoi un contrôleur de domaine situé dans un autre pays sur une liaison de modem lente peut être celui choisi par une machine cliente pour traiter sa demande d’ouverture de session.
Contexte
Pour ceux d’entre vous qui ne sont pas familiers avec le concept de domaines Windows NT, voici un rappel rapide : Un domaine NT est un ensemble de serveurs compatibles réseau et d’autres ordinateurs qui partagent des informations de sécurité et de compte communes. Le domaine permet une administration centralisée des utilisateurs, des ordinateurs et du réseau. Les informations de sécurité sont conservées dans une base de données centrale sur un serveur désigné et configuré en tant que contrôleur de domaine principal (PDC) et sont répliquées vers d’autres serveurs spéciaux, désignés et configurés en tant que contrôleurs de domaine de sauvegarde (BDC). Un seul serveur peut être le PDC à la fois, mais ce rôle spécial peut être transféré à n’importe quel BDC selon les besoins. Lorsqu’un client exécutant TCP/IP tente de se connecter à ce domaine NT, la demande d’ouverture de session est traitée par l’un des contrôleurs de domaine du réseau appartenant au même domaine.
WINS
Les serveurs WINS conservent une liste de tous les clients compatibles WINS sur le réseau. Les serveurs WINS conservent également une liste de contrôleurs de domaine identifiés comme étant de type < 1C >. Pour des raisons qu’ils ne connaissent que, les concepteurs de WINS ont décidé qu’il devrait y avoir une limite de 25 entrées dans la liste < 1C >, ce qui signifie que les contrôleurs de domaine suivants n’apparaîtront pas sur cette liste. Cette liste est fournie aux clients lorsqu’ils tentent de trouver un contrôleur de domaine pour traiter leur demande d’ouverture de session.

L’ordre dans lequel les contrôleurs de domaine apparaissent dans la liste suit cette logique:

1. Entrées de contrôleur de domaine enregistrées auprès du serveur WINS, dans l’ordre de la plus récente actualisation à la moins récente actualisation
2. Entrées de contrôleur de domaine obtenues à partir de la réplication avec d’autres serveurs WINS
3. La première entrée est toujours le PDC

Nœuds
Lors de la configuration de TCP/IP sur un client, l’une des options que vous pouvez voir (selon sur l’installation) est le type de nœud. Le type de nœud fait référence à la façon dont le client trouve un contrôleur de domaine pour traiter ses demandes d’ouverture de session.
Il existe quatre types de nœuds en TCP/IP:

• Nœud B (nœud de diffusion) : Lorsqu’un client doit trouver un contrôleur de domaine, il effectue une diffusion. Le premier contrôleur de domaine à répondre se verra confier la tâche de gérer la demande d’ouverture de session.
• Nœud P (nœud point à point) : Dans cet environnement, les requêtes de nom vont directement au serveur WINS.
• Nœud M (nœud multi-homed) : Un environnement de nœud m utilise d’abord le nœud b, puis, si nécessaire, le nœud p pour résoudre les noms.
• Nœud H (nœud hybride) : Un environnement de nœud h utilise d’abord le nœud p, puis le nœud b si le service de noms n’est pas disponible.

Examinons plus en détail chaque type de nœud.
Nœud B
Le mode nœud b utilise des messages de diffusion pour l’enregistrement et la résolution des noms. Par exemple, si un ordinateur nommé NT_PC1 souhaite communiquer avec un ordinateur nommé NT_PC2, NT_PC1 envoie un message de diffusion indiquant qu’il recherche NT_PC2. Il attend ensuite une heure spécifiée pour que NT_PC2 réponde.
Le nœud B a deux problèmes majeurs:

• Dans un environnement volumineux, il charge le réseau avec des messages de diffusion.
• En règle générale, les routeurs ne transfèrent pas les messages de diffusion, de sorte que les ordinateurs des côtés opposés d’un routeur n’entendent jamais les demandes.

Des exemples d’ordinateurs sur le réseau qui peuvent être des clients à nœud B incluent les ordinateurs exécutant MS-DOS, Windows 3.1 ou Windows pour les groupes de travail sur lesquels le logiciel client WINS n’est pas installé. Les serveurs possibles incluent des serveurs réseau basés sur des blocs de messages serveur (SMB), tels que IBM LAN Server, DEC PATHWORKS, AT & T StarLAN et LAN Manager pour les systèmes OS/2 ou UNIX.
Nœud P
Le mode nœud p résout les problèmes que le nœud b ne résout pas. Dans un environnement à nœud p, les ordinateurs ne créent ni ne répondent aux messages diffusés. Tous les ordinateurs s’enregistrent auprès du serveur WINS, qui est chargé de connaître les noms et adresses des ordinateurs et de s’assurer qu’aucun nom en double n’existe sur le réseau.

Dans cet environnement, lorsque NT_PC1 veut communiquer avec NT_PC2, il interroge le serveur WINS pour l’adresse de NT_PC2. Dès réception de l’adresse, NT_PC1 passe directement à NT_PC2 sans diffusion. Puisque les requêtes de nom vont directement au serveur WINS, le nœud p évite de charger le réseau avec des messages de diffusion. Comme les messages de diffusion ne sont pas utilisés et que l’adresse est reçue directement, les ordinateurs peuvent se trouver sur les côtés opposés des routeurs.
Les problèmes les plus importants avec le nœud p sont:

• Tous les ordinateurs doivent être configurés pour connaître l’adresse du serveur WINS.
• Si le serveur WINS est en panne, les ordinateurs qui en dépendent pour résoudre les adresses ne peuvent accéder à aucun autre système du réseau.

Nœud M
Le mode nœud m a été créé principalement pour résoudre les problèmes associés au nœud b et au nœud p. Dans un environnement à nœud m, un ordinateur tente d’abord l’enregistrement et la résolution avec le nœud b. Si cela échoue, il passe au nœud p. Les avantages comprennent:

• Le nœud M peut croiser des routeurs
• Puisque le nœud b est toujours essayé en premier, les ordinateurs du même côté d’un routeur continuent de fonctionner comme d’habitude si le serveur WINS est en panne
• En théorie, l’utilisation du nœud m devrait augmenter les performances du réseau local

Nœud H
Le mode nœud h résout les problèmes les plus importants associés aux messages de diffusion et aux opérations en environnement routé. Ce mode est une combinaison de nœud b et de nœud p qui utilise les messages de diffusion en dernier recours. Le mode nœud h fait plus que modifier l’ordre d’utilisation du nœud b et du nœud p : Si le serveur WINS est en panne, ce qui rend les messages de diffusion nécessaires, l’ordinateur continue d’interroger le serveur WINS. Lorsque le serveur WINS peut être atteint à nouveau, le système revient au nœud p. Le nœud H peut également être configuré pour utiliser le fichier LMHOSTS après l’échec de la résolution du nom de diffusion.
Puisque le nœud p est utilisé en premier, aucun message de diffusion n’est généré si le serveur WINS est en cours d’exécution et les ordinateurs peuvent se trouver sur les côtés opposés des routeurs. Si le serveur WINS est en panne, le nœud b est utilisé, de sorte que les ordinateurs du même côté d’un routeur continuent de fonctionner comme d’habitude.
Autres combinaisons
Une autre variante, connue sous le nom de nœud b modifié, est également utilisée dans les réseaux Microsoft afin que les messages puissent passer par les routeurs. Le nœud b modifié n’utilise pas le mode nœud p ou un serveur WINS. Dans ce mode, b-node utilise une liste d’ordinateurs et d’adresses qui sont stockés dans un fichier LMHOSTS. Si une tentative de nœud b échoue, le système recherche dans LMHOSTS un nom, puis utilise l’adresse associée pour traverser le routeur. Cependant, chaque ordinateur doit avoir cette liste, ce qui crée une charge administrative car la liste doit être tenue à jour et distribuée. Windows pour les groupes de travail 3.11 et le gestionnaire de réseau local 2.x utilisait un tel système de nœud b modifié. Windows NT utilise cette méthode si les serveurs WINS ne sont pas utilisés sur le réseau. Dans Windows NT, certaines extensions ont été ajoutées à ce fichier pour le rendre plus facile à gérer, mais le nœud b modifié n’est pas une solution idéale.

Certains sites peuvent nécessiter les modes nœud b et nœud p. Bien que cette configuration puisse fonctionner, les administrateurs doivent faire preuve d’une extrême prudence et ne l’utiliser que pour les situations de transition. Étant donné que les hôtes de nœud p ignorent les messages de diffusion et que les hôtes de nœud b s’appuient sur les messages de diffusion pour la résolution des noms, les deux hôtes peuvent potentiellement être configurés avec le même nom NetBIOS, ce qui entraîne des résultats imprévisibles. En outre, si un ordinateur configuré pour utiliser le nœud b a un mappage statique dans la base de données WINS, un ordinateur configuré pour utiliser le nœud p ne peut pas utiliser le même nom d’ordinateur.
Les ordinateurs exécutant Windows NT peuvent être configurés en tant qu’agents proxy WINS pour faciliter la transition vers l’utilisation de WINS. Les clients réseau basés sur Windows (ordinateurs Windows NT, Windows 95 ou Windows pour les groupes de travail 3.11 compatibles WINS) peuvent utiliser WINS directement. Les ordinateurs non-WINS compatibles avec les nœuds b (comme décrit dans les RFC 1001 et 1002) peuvent accéder aux WINS via des mandataires. Un proxy WINS est un ordinateur compatible WINS qui écoute les messages de diffusion de requêtes de nom, puis répond aux noms qui ne se trouvent pas sur le sous-réseau local. Les mandataires sont des ordinateurs à nœud p.
Lors de la configuration de TCP, vous ne trouverez aucun moyen de définir le type de nœud. Le type de nœud est défini par défaut lors de la configuration TCP. Les types de nœuds TCP/IP Windows 95 par défaut sont:
Si DHCP = False, et WINS est désactivé, alors Type de nœud b-node(0x01)
Si DHCP=False, et WINS est défini manuellement, alors Type de Nœud h-node(0x08)
Si DHCP = True, et DHCP définit WINS, alors Type de nœud h-node(0x08)
Si DHCP = True, et WINS est défini manuellement, alors Type de Nœud h-node (0x08)
Si DHCP = True, et WINS est désactivé, puis Type de nœud b- node(0x01)
Si les options de serveur WINS sont fournies via DHCP, le Type de nœud doit être défini à l’aide de l’option DHCP 46; cependant, la définition locale d’un serveur WINS sur le client remplacera ces deux options car les serveurs WINS définis localement définissent automatiquement votre type de nœud sur h-node.
Le type de nœud peut être modifié manuellement en modifiant le registre Windows 95. L’emplacement existe sous le sous-arbre HKEY_LOCAL_MACHINE sous la sous-clé
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\MSTCP\Node Type

NodeType peut être ajouté en tant que valeur de chaîne sous MSTCP s’il n’existe pas déjà.
La demande d’ouverture de session
Maintenant, regardons ce qui se passe après que le client a entré le nom d’utilisateur, le mot de passe et les informations de domaine et cliqué sur OK dans la fenêtre d’invite d’ouverture de session (avant que la demande d’ouverture de session ne soit traitée). Windows 9x et Windows NT se comportent légèrement différemment, je vais donc en discuter séparément.
Client Windows 9x
Le client tente de trouver un contrôleur de domaine d’une manière définie par le type de nœud avec lequel il a été configuré. Voici une séquence d’événements très simplifiée:

1. Un client à nœud b diffusera une requête. Si un serveur ne répond pas, l’ouverture de session échouera.
2. Un client à nœud p demandera la liste < 1C > au serveur WINS. Il diffusera ensuite une requête à chacun des serveurs de la liste < 1C > à tour de rôle, en commençant par le premier (le PDC).
3. Les clients nœud m et nœud h effectuent ces deux opérations dans l’ordre décrit ci-dessus, sauf que, si le nom du groupe de travail du client est le même que le domaine du compte auquel l’ouverture de session est tentée, la recherche WINS pour les contrôleurs de domaine sur le sous-réseau local est ignorée. À condition que le serveur WINS soit actif et accessible, cela signifie que le premier contrôleur de domaine de la liste < 1C > à répondre traitera toujours la demande d’ouverture de session.

Comme mentionné ci-dessus, pour vous assurer que le client est validé par le contrôleur de domaine local, vous devez donner au nom du groupe de travail le même nom que le domaine représenté par ce contrôleur de domaine. Cependant, si vous souhaitez utiliser des groupes de travail dans l’environnement de bureau, cette méthode de validation locale peut ne pas être acceptable. Dans ce cas, le type de nœud doit être défini sur m pour s’assurer que le client diffuse initialement sur le sous-réseau local afin qu’il y ait une meilleure chance que le contrôleur de domaine local réponde en premier. Notez que ce n’est pas une règle dure et rapide. Le contrôleur de domaine doit seulement être un peu occupé – ce que les serveurs de sites distants sont souvent parce qu’il est habituel pour les administrateurs de placer un seul contrôleur de domaine sur un site distant — et un contrôleur de domaine non local plus réactif pourrait entrer en premier.
Alternativement, WINS pourrait être installé sur le contrôleur de domaine local et les clients pourraient l’utiliser comme serveur WINS principal. Cette méthode peut être une bonne idée si les utilisateurs accèdent rarement à des ressources en dehors de la branche locale, mais c’est une charge supplémentaire pour le serveur, qui fournit probablement des services de fichiers et d’impression, DHCP, SQL, Exchange et d’autres tâches.

Si le nom du groupe de travail est différent du domaine du compte, l’utilisation de m-node augmentera les chances d’obtenir un service local de la demande d’ouverture de session.
Client Windows NT
L’ouverture de session Windows NT est quelque peu différente de l’ouverture de session Windows 9x — le poste de travail NT a un ID de machine dans un domaine. Ainsi, le client passe par quatre étapes pour la validation de la connexion. Tout d’abord, le client de poste de travail NT valide son ID de machine avec les contrôleurs de domaine du domaine de ressources, puis il envoie des informations de connexion utilisateur pour validation de passage. Le contrôleur de domaine du domaine de ressources transmet les informations d’ouverture de session à un contrôleur de domaine du domaine du compte. Le contrôleur de domaine de ressource transmet ensuite les informations d’authentification de l’utilisateur (reçues du contrôleur de domaine de compte) à l’utilisateur.
Que les utilisateurs y soient connectés ou non, les clients de la station de travail NT passent par la validation de l’ID lors de l’initialisation et si nécessaire ultérieurement (par exemple, si quelqu’un se connecte à la machine NT avec le profil local mis en cache car le contrôleur de domaine de ressources est en panne).
Vient d’abord la résolution des noms des contrôleurs de domaine. Le client de poste de travail NT doit localiser un domaine de ressources – contrôleur de domaine. Le processus de découverte utilisé par un client de poste de travail NT pour trouver un contrôleur de domaine de ressources est le même que celui utilisé par le contrôleur de domaine de ressources pour établir une connexion de confiance avec un contrôleur de domaine de compte.
Ensuite, l’ID de la machine NT est validé. Le client de poste de travail NT envoie toujours une diffusion d’ouverture de session locale au Domaine de ressources < 1C > avant d’envoyer des demandes d’ouverture de session en monodiffusion aux contrôleurs de domaine de ressources qui sont obtenues à partir de WINS.
Le client valide l’ID de la machine de la station de travail NT – avec le premier contrôleur de domaine du domaine de ressources pour répondre à la demande d’ouverture de session.
Le client de poste de travail NT demande au contrôleur de domaine de ressource d’énumérer la liste de domaines approuvés. Les noms de domaine obtenus sont affichés dans la liste déroulante Domaine de la fenêtre d’ouverture de session.
Le client de poste de travail NT transmet les informations d’identification de connexion utilisateur au contrôleur de domaine de domaine de ressource et demande une authentification de passage.

Le contrôleur de domaine de ressource transmet les informations d’identification de connexion utilisateur au contrôleur de domaine de compte avec lequel il a établi une connexion de confiance et lui demande d’authentifier l’utilisateur. Il transmet ensuite les informations de validation au client du poste de travail NT.
Le client NT Workstation obtient le nom du contrôleur de domaine de compte du contrôleur de domaine de ressource pour se connecter et exécuter le script/profil d’ouverture de session, s’il a été configuré.
L’utilisateur NT est maintenant connecté au domaine du compte, a exécuté un script d’ouverture de session et a établi des connexions réseau appropriées aux répertoires personnels.
Bien sûr, si l’ID de la machine est enregistré avec un domaine en dehors du sous-réseau local ou si l’utilisateur se connecte à un domaine qui n’a pas de contrôleur de domaine sur le sous-réseau local, le processus d’ouverture de session nécessitera une communication via le réseau étendu. S’il s’agit d’un lien lent, le processus d’ouverture de session sera étendu.
Conclusion
Avec les clients Windows 9x, l’authentification locale est obtenue en rendant le nom du groupe de travail identique à celui de l’ouverture de session ou du compte, du domaine ou en utilisant le mode b ou le nœud m pour s’assurer que la demande d’ouverture de session est diffusée localement en premier. De toute évidence, le nœud b n’est pas très polyvalent et cela entraînera un échec de la connexion si le contrôleur de domaine local ne répond pas rapidement.
Avec les clients Windows NT, il devrait y avoir un contrôleur de domaine de ressources et un contrôleur de domaine de compte dans le segment local. (Il peut s’agir d’un seul serveur si les domaines de ressource et de compte sont les mêmes.)
Vous pouvez encore améliorer le processus en disposant de plusieurs serveurs WINS et en pointant les clients vers le serveur WINS qui enregistrera le contrôleur de domaine local ou le plus proche dans la liste < 1C >.

La carrière informatique de Richard Charrington a commencé lorsqu’il a commencé à travailler avec des PC — à l’époque où ils étaient connus sous le nom de micro-ordinateurs. Débutant en tant que programmeur, il s’est frayé un chemin jusqu’aux sommets élevés d’un administrateur de systèmes Windows NT, et il a fait à peu près tout le reste. Richard travaille avec Windows depuis avant qu’il ait une interface graphique appropriée et avec Windows NT depuis qu’il était LANManager. Maintenant entrepreneur, il s’est glissé dans l’écriture de scripts pour Windows NT et a construit des utilitaires d’administration automatique très utiles.

Les auteurs et éditeurs ont pris soin dans la préparation du contenu contenu dans les présentes, mais n’offrent aucune garantie expresse ou implicite d’aucune sorte et n’assument aucune responsabilité pour les erreurs ou omissions. Aucune responsabilité n’est assumée pour tout dommage. Ayez toujours une sauvegarde vérifiée avant d’apporter des modifications.