configuration réseau domaine sur plusieurs sites

[grome]

Bonjour,


J'ai un petit soucis de config réseau et comme mes compétences sont très limitées je me permets de vous l'exposer.

J'ai un domaine géré par deux serveurs windows 2000 avec des postes clients en windows XP pro. Certains postes clients sont distants mais gràce à ipcop et aux différent Vpn que j'ai monté les postes distants sont bien enregistrés sur le domaine. Seulement voilà, ces postes ne sont pas visibles depuis le site principal, par contre lorsque je suis sur un site distant je vois toutes les ressources réseau (poste, imprimantes ...) du site principal. Je pense que c'est un problème d'adressage et que c'est lié à divers choix que j'ai fait. Je m'explique

Le site principal est adressé de la manière suivante :

ip : 192.168.1.xxx
masque : 255.255.255.0

Les serveurs ont une ip fixe. les postes clients recoivent une ip du service DHCP des serveurs windows 2000. Le DHCP de l'ipcop est desactivé

les sites distants sont adressés de la manière suivante :

ip : 192.168.5.xxx
masque : 255.255.255.0

sur les sites distant les postes recoivent leur adresse IP du DHCP de leur ipcop.
Pour pouvoir les enregistrer sur le domaine et faire en sorte que lorsque l'utilisateur se logue le serveur l'autorise à se connecter, j'ai mis en dns, l'adresse du serveur du site principal.

Comment faire pour que le site principal puisse voir (dans l'explorateur windows par exemple) les postes distants ?


Merci d'avance et bonne année 2006 !!!

[jdh]

Ce pb est vu et revu sur le site ...

Windows peut utiliser 2 systèmes de répérage des "ressources" : WINS pour les serveurs NT et DNS pour les serveurs >=2K.

WINS fonctionne soit avec des serveurs WINS (2K peut l'être) soit par broadcast (donc ne fonctionne pas au delà d'un routeur au sens large = l'IPCOP).

Les PC du site distant peuvent voir le ou les serveurs centraux car ils sont enregistrés mais ne peuvent les renseigner sur leur état (voire leur partage).

Le serveur DHCP naturel est l'IPCOP et fournit en conséquence comme DNS lui-même alors qu'il faudrait qu'il fournisse en 1 le serveur DNS central et en 2 l'IPCOP. Il pourrait fournir en option "netbios-name-servers" (et/ou "netbios-dd-server" et/ou "netbios-node-type 8") le serveur 2K maitre comme serveur WINS.

Je suppose qu'il faut modifier en conséquence le fichier de conf du DHCP d'IPCOP ... sans doute hors interface graphique (hé hé hé !).

Merci de nous retourner le résultat de tes essais ...

[Franck78]

... sans doute hors interface graphique (hé hé hé !).

Et bien non, l'interface d'IPCop permet de créer les options non prévues de base, sans bidouille directe sur le fichier de conf

[grome]

oui je viens juste de le voir j'ai repéré les champs je vais faire les tests cet après midi.

J'ai compris le principe. Merci beaucoup.

[grome]

Bon ok çà fonctionne

J'ai mis l'option netbios-dd-server avec pour valeur l'adresse ip de mon serveur sur le site principal. Ce serveur fait tourner wins.

Désormais je vois les postes des sites distants sur le reseau du site principal.

Mince avec tout çà j'imagine qu'il doit y avoir un peu de traffic quand même.

Merci beaucoup.

[Koj]

La liste des machines c'est le Master Browser qu'il l'a, et son accolyte le "backup master browser" (si ma mémoire est bonne) soit 2 machines au hasard dans le reseau (voir la méthode d'élection des master browser sur la KB MS).
Qui dit master browser = dit netbios = dit "passe pas les routers".

En général on desactive le service browser que les postes et on force un serveur W2K a être Master Browser.

Moi je me pose plutot la question du : "a quoi ca te sert de voir tes machines dans My Network Place ?"

Mieux vaut ne pas les voir et publier dans active directory les dossiers partagées, voir ne rien faire du tout car si on reste logique on centralise les documents sur un serveur Samba ou Windows et on met un antivirus dessus et surtout on le backup ! Donc ca sert pas à grand chose de mettre Wins et configurer IPCOP, partager des trucs en vrac sur le reseau et les perdres au 1er crache disque. A la limite je comprendrai s'il y avait des vieilles app qui ne marche pas sans Wins.... (erck)

++

Koj

[jdh]

Je conteste l'affirmation "netbios = ne passe pas les routeur".

Autrefois (avant Win95), il y avait le protocole "réseau" NetBeui qui était (comme DLC) un protocole "réseau" non routable et donc limité au sein d'un réseau local. Depuis Win95, Microsoft utilise par défaut TCP/IP qui est un protocole "réseau" routable bien évidemment.

Netbios est un protocole "données" et non réseau donc il n'y a pas de notion "routable ou non".

Netbios est un protocole de description de "ressources" disponibles : chaque client ou serveur Windows peut être "serveur" au sens de Netbios et permettant un partage de fichier ou d'imprimante (cf notation UNC "\\machine\partage").

Avec Win2K et ActiveDir, Microsoft a résolu le pb ch... datant de Windows NT en mettant dans ActiveDir la liste des ressources disponibles sur l'ensemble du réseau. Du coup, un client de serveur ActiveDir n'a plus besoin de serveur WINS qui gérait cette liste de ressources.

Avec Windows NT, chaque client utilisait soit un système de broadcast (qui ne passe pas les routeurs du fait de l'adresse utilisée et non du protocole réseau) soit un serveur WINS.

De plus, un client d'ActiveDir accède à beaucoup plus de nouvelles "ressources" au travers du service DNS fourni naturellement par le premier serveur Win2K avec ActiveDir.

Dans le cas d'un site distant sans serveur Win2K relié à un site central avec serveur(s) Win2K, il y a donc 2 problèmes à résoudre :
- permettre l'accès au DNS du serveur ActiveDir : ce qui se fait en fournissant l'ip du serveur ActiveDir comme serveur DNS (au prix d'une résolution distante DNS à chaque fois);
- definir le mode de fonctionnement "Serveur WINS" (si le premier système DNS ne suffit pas) : ce qui se fait avec l'option 44=netbios-name-server du serveur DHCP.

Peut-être que Grome pourrait nous renseigner sur les actions qu'il a accompli pour résoudre son pb (sachant que "netbios-dd-server" n'est pas la bonne réponse mais plutôt "netbios-name-server").


Sinon la remarque sur l'inutilité de faire des partage sur de simple client me parait assez juste. Je dirais même que c'est stupide car les serveurs sont faits pour faire des partages. Cependant, certains systèmes de déploiements notamment d'antivirus, peuvent utiliser le partage administratif C$. D'où l'intéret de la manoeuvre.

Je pense qu'il doit y avoir des systèmes bien plus efficace pour connaitre quels micros sont actifs à l'instant t (ce qui me semble la vraie question cachée de Grome).

[grome]

Ok globalement j'ai compris, alors avant de commencer, oui il y a raison qui me pousse à faire cette config, bonne je sais pas, mais il y en a une.

Commencons,

Dans le cas d'un site distant sans serveur Win2K relié à un site central avec serveur(s) Win2K, il y a donc 2 problèmes à résoudre :
- permettre l'accès au DNS du serveur ActiveDir : ce qui se fait en fournissant l'ip du serveur ActiveDir comme serveur DNS (au prix d'une résolution distante DNS à chaque fois);

C'est ce que je fais aussi, c'est pas terrible mais ca fonctionne bien. Juste quelques secondes de plus à l'ouverture de session, après c'est plus ou moins transparent.

- definir le mode de fonctionnement "Serveur WINS" (si le premier système DNS ne suffit pas) : ce qui se fait avec l'option 44=netbios-name-server du serveur DHCP.

Bien c'est mon cas, sauf que je n'arrive pas à entrer l'option netbios-name-servers dans mon ipcop distant. Dans l'interface graphique j'ai mis l'option. Dans l'autre champ j'ai mis l'adresse ip de mon serveur wins (serveur win2k sur le site principal). Ipcop me répond : Cette option est inconnue: netbios-name-servers je me suis basé aussi sur http://www.delafond.org/traducmanfr/man/man5/dhcp-options.5.html

Peut-être que Grome pourrait nous renseigner sur les actions qu'il a accompli pour résoudre son pb (sachant que "netbios-dd-server" n'est pas la bonne réponse mais plutôt "netbios-name-server").

J'ai desactivé l'autre option : netbios-dd-server [ip server] mais je n'arrive pas à mettre netbios-name-servers

Je pense qu'il doit y avoir des systèmes bien plus efficace pour connaitre quels micros sont actifs à l'instant t (ce qui me semble la vraie question cachée de Grome).

Perdu je vous explique, mais ne rigolez pas. Sur mon deuxième serveur j'ai un logiciel qui tourne en TSE. Sauf que les utilisateurs distants aimeraient bien pouvoir imprimer sur leur imprimante. Donc comment faire pour installer l'imprimante sur le serveur si je ne vois même pas les postes distans.

Je suis en train d'étudier la possibilité d'installer la partie graphique sur leur poste, la base de données étant hébergée par SQL SERVER sur le serveur principal. Cependant à travers le vpn je vais créer du traffic et je ne suis pas sur que ce soit viable. Enfin je vais tester.

[jdh]

Merci d'abord de nous indiquez ce qui t'a permis de résoudre ton pb ! C'est assez rare pour le noter.

* Résolution DNS :

- Site central : le serveur DNS étant l'ActiveDir, tout se passe bien pour les clients locaux;
- Site distant : les clients ont besoin de résoudre le nom de domaine de l'ActiveDir, le plus simple est de leur fournir comme DNS le serveur ActiveDir. Il y a 2 ennuis : la résolution réclame un soupcon de temps supplémentaire et ne fonctionne plus si le vpn tombe. La solution est de disposer d'un serveur DNS sur le site distant qui est "esclave" du serveur DNS ActiveDir.

* Serveur WINS :

En principe, WINS n'est pas forcément nécessaire mais ... La doc de dhcpd.conf parle bien de l'option "netbios-name-servers" : on peut aussi utiliser le n° correspondant : 44 = netbios-name-servers. Cela devrait fonctionner ... Mais normalement il n'y en a plus besoin ... ce que tu sembles confirmer puisque cela fonctionne.


Concernant TSE, j'ignorais que le serveur devait connaitre l'imprimante locale pour imprimer dessus. Je pensais qu'il y avait une redirection faite par le client TSE vers l'imprimante de son choix.

Il est clair que si tu as une application qui est capable d'exploiter un lien vers un SQL distant, il est vraisemblable que le traffic sera inférieur au traffic standard d'un client TSE (~10 à 15kb min).

Il ne faut pas oublier aussi qu'un vpn est assez lent en terme de débit du fait du temps nécessaire au cryptage.

[grome]

Merci d'abord de nous indiquez ce qui t'a permis de résoudre ton pb ! C'est assez rare pour le noter.

En fait mon problème n'est pas tout à fait résolu, j'ai refait des tests hier après midi. Il apparait que la résolution wins ne se fait que sur un mon site de test, pour les autres sites cela ne fonctionne pas. J'utilise bien sur la même option avec la même valeur. J'y reveindrai dans un instant

* Résolution DNS :
- Site distant : les clients ont besoin de résoudre le nom de domaine de l'ActiveDir, le plus simple est de leur fournir comme DNS le serveur ActiveDir. Il y a 2 ennuis : la résolution réclame un soupcon de temps supplémentaire

C'est exact mais pas trop génant pour nous.

et ne fonctionne plus si le vpn tombe.

C'est encore exact, c'est pourquoi la fiabilité et la tenue du vpn sont pour nous très importante.

La solution est de disposer d'un serveur DNS sur le site distant qui est "esclave" du serveur DNS ActiveDir.

J'ai bien pensé à çà mais alors qu'en est-il de la résolution de nom pour Internet. Celle ci va passer par le vpn alors qu'ipcop pourrait s'en charger. Il doit surement y avoir un moyen de séparer les deux.

* Serveur WINS :
En principe, WINS n'est pas forcément nécessaire mais ... La doc de dhcpd.conf parle bien de l'option "netbios-name-servers" : on peut aussi utiliser le n° correspondant : 44 = netbios-name-servers. Cela devrait fonctionner ... Mais normalement il n'y en a plus besoin ... ce que tu sembles confirmer puisque cela fonctionne.

Pas tout à fait en fait. J'ai essayé le 44 seul dans le champ et ca marche pas mieux. J'ai laissé le netbios-dd-server, par contre lors de mes test d'hier, j'ai remarqué que la résolutions wins est longue. Le poste met du temps a apparaitre sur le réseau. C'est pas vraiment satisfaisant, même si dans le principe ca fonctionne

Concernant TSE, j'ignorais que le serveur devait connaitre l'imprimante locale pour imprimer dessus. Je pensais qu'il y avait une redirection faite par le client TSE vers l'imprimante de son choix.
Il est clair que si tu as une application qui est capable d'exploiter un lien vers un SQL distant, il est vraisemblable que le traffic sera inférieur au traffic standard d'un client TSE (~10 à 15kb min).

je me suis trop avancé car en fait l'appli n'est pas configurable en sql server, je le pensais mais en fait non. Elle fonctionne juste sur des fichiers mdb (access donc). Donc je suis un peu coincé et je vais pour le moment continuer à la faire tourner en TSE.

Il ne faut pas oublier aussi qu'un vpn est assez lent en terme de débit du fait du temps nécessaire au cryptage.

oui bien sur, d'ou l'importance, je pense, d'avoir quand même du matériel correcté dimensionner pour cette tâche.