Bonjour,
 
Nous avons 3 serveurs dans notre réseau. Chaque serveur est livrée avec 2 voire 3 cartes réseau.
Il s'agit d'un serveur de fichier sous Linux+Samba+Winbind, et de 2 serveurs de domaine en Windows Server 2003 R2.
Les serveurs Windows s'occupent de gérer AD et le DNS en primaire et secondaire, le DNS fait partie de AD.
Nous n'avons pas de serveur WINS.
Tous les postes (y compris les serveurs) ont leur stack IP qui active Netbios over TCP/IP.
 
Le LAN principal est en classe 192.168.1.x.
Nous avons décidé d'utiliser les secondes cartes réseau pour avoir un réseau privatif entre les serveurs (backup des volumes ressources user etc).
Nous avons opté simplement pour une classe d'adresse en 193.169.2.x !!!
Nous ne voulons surtout pas de routage entre les deux réseaux.
La gateway par défaut doit rester celle du réseau LAN principal pour pouvoir joindre le routeur etc.
 
Pour pouvoir distinguer dans le DNS les deux réseaux, nous avons appelé les machines sur le LAN principal toto, titi, tata, et sur le LAN secondaire gate-toto, gate-titi, gate-tata.
 
Donc, nous avons une notation qui ressemble à celle-ci:

etc
 
Sous Windows, nous avons un gros gros souci qui semble venir du DNS Microsoft et non pas du stack IP lui-même.
 
Sous Unix, aucun problème. Surtout qu'il y a un moyen simple de lui dire "ceci est la gateway par défaut" (default route). Le netstat -rn est exemplaire et simple en ce sens.
 
Sous MS, nous avons dû forcer les métriques des gateway sinon, c'est le réseau secondaire qui devenait la gateway par défaut. Le netstat -rn montre bien la gateway par défaut vers le LAN principal (192.168.1.x metric 1, 193.169.2.x metric 2).
Sous MS, on a forcé la gateway secondaire pour correspondre avec l'adresse de la carte réseau sur 193.169.2.x, normal.
 
On a tenté de forcer les adresses de tous les serveurs dans le fichier hosts windows (system32/drivers/etc). Cela améliore les choses en local sur les serveurs dans une boîte DOS. Lorsqu'on tape ping toto ou ping gate-toto, tout est bien résolu.
 
En revanche, quand on fait un nslookup, et que l'on demande qui est toto et gate-toto, seul gate-toto est bien référencé ET UNIQUE. Alors que pour toto (ou toto.my.dom), le DNS nous donne deux adresses IP et bien entendu, pas dans l'ordre qui nous intéresse! Il nous donne 193.169.2.100,192.168.1.100...
 
Cela ne semble pas gêner les stations clientes, qui, recevant les deux adresses, se débrouillent. Les stations clientes ne voient pas du tout le LAN secondaire.
 
Par contre, cela pose de gros soucis pour tout ce qui est accès distant sur les serveurs (remote, ssh, etc). Comme si les requêtes arrivaient avec l'adresse sur le LAN principal (normal) et repartait dans le LAN secondaire puisque les enregistrements du DNS l'identifie en premier sur le LAN secondaire. Mais pourquoi? Puisque la gateway est correctement positionnée???
 
Nous avons essayé de corriger toutes les entrées du DNS Windows à la main pour bien distinguer toto de gate-toto, et de ne pas avoir d'enregistrement qui comportent les 2 adresses. Cela marche un temps, puis le DNS remet de lui-même la double notation   ???
 
J'ai la désagréable sensation que AD corrige automatiquement les modifs que nous effectuons à la main dans le DNS. Comme le DNS est intégré à AD, et que AD positionne à différents endroit les deux adresses réseau attributées aux serveurs (de domaine), c'est comme si AD remettait d'office le double adressage.
 
Auriez-vous une piste afin de garantir l'unicité DNS? 1 nom -> 1 adresse, 1 adresse -> 1 nom.
Cordialement.
Mikee.

Ouvre les propriétés de tes cartes réseaux "secondaires", puis propriétés de TCP/IP, puis bouton avancé, onglet DNS, décoche "enregistrer les adresses de cette connexion dans le systeme DNS".

Salut!
 
Ah ben ouais! Pas con du tout...    
 
Précision: on avait ajouté dans le DNS la seconde plage d'adresse (193.169.2.x) dans une autre zone de recherche inversée, ça, ça se passe bien.
Par contre, pour la recherche directe sur my.dom, on rentrera donc nos adresses du réseau secondaire "à la main" en créant des nouveaux hotes et basta?!
 
Ca marchera finement comme ça et le système ne viendra plus interférer avec des éléments entrés manuellement?
J'ai bon?!
 
Merci beaucoup pour la réponse, a+

Oui ca devrait etre bon, mais bon s'embeter a créer une nouvelle zone DNS juste pour les liaisons inter-server c'est je trouve s'embeter pour pas grand chose, bosser directement sur les IP ça marche bien aussi et c'est moins lourd.

Re!
 
Fondamentalement, je suis tout à fait d'accord avec toi, d'autant que (comme je le mentionnais) on a marqué toutes ces adresses spéciales serveurs dans tous les fichiers hosts des différentes machines (sous différents OS).
 
Ce, pour être sûr qu'en cas de défaillance du DNS (justement!), les serveurs puissent continuer à exécuter leurs scripts sans être embêtés.
 
Mais on s'est aussi dit que si l'on rajoutait des machines exotiques qui participent à ce sous-réseau, cela serait beaucoup moins chi... de lui dire: "Tiens le DNS est là, débrouille-toi!!!"
 
Note bien que ce n'est pas la gestion de la nouvelle zone en tant que tel qui nous pose problème. Mais tu as raison, si d'aventure les problèmes persistent, je vire tout et laisse seulement les IP et les hosts qui correspondent.
 
A+

Pour info, pour gerer les priorités des connexions, tu peux le faire de la manière suivante :
depuis l'explorateur, se positionner dans \panneau de config\connexion réseau
Puis aller depuis le menu dans \avancée\paramètres avancés
Et modifier l'ordre des connexion prioritaire...
 
Je sais pas si ça peut t'aider, dans ton cas...
Redis-moi, ça m'intéresse...  
A+

Salut à toutes et à tous, merci à Pollo et Helvetik pour vos réponses avisées.
 
Pour clore le sujet, puisque maintenant ça fonctionne pour nous! A savoir, les connexions depuis l'extérieur sont à nouveau possibles, preuve que les routages suivent la bonne route! Et dans le DNS les adresses sont dans le bon ordre.
 
Ma conclusion personnelle sur le sujet, c'est que vous avez tous les deux raisons!!! L'ordre de présentation des connexions réseau semble primordial pour le serveur lui-même. Et débrancher l'inscription d'une connexion réseau dans le DNS semble essentiel pour le reste du réseau.
 
Et qu'en plus, on a pu programmer un reboot serveur, donc il faut au moins les trois pour que tout rendre dans l'ordre!!!
Voilou, @tchô

Nikel !
 
A bientôt,
 
Hel