Outils pour utilisateurs

Outils du site


bind_opensuse

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

bind_opensuse [2007/12/15 09:50]
tyrtamos créée
bind_opensuse [2007/12/15 09:51] (Version actuelle)
tyrtamos
Ligne 1: Ligne 1:
-====== ​Qui est connecté à mon serveur ftp? ======+====== ​Serveur de nom DNS "Bind v 9.3" ​======
  
-[testé sur vsftp installé sur debian etch] 
  
-[origineune discussion sur le forum: [[http://​forum.debian-fr.org/​viewtopic.php?​t=9493&​start=0]] ]+===== Remarques préalables: =====
  
-**//EN CONSTRUCTION//​**+1- pour un simple réseau domestique composé de 1, 2 ou 3 machines, vous n'avez pas vraiment besoin de serveur de nom local! La mise à jour des fichiers hosts (/etc/hosts pour linux et c:​\windows\system32\drivers\etc\hosts pour windows) suffit largement. L'​inconvénient est alors que vous devez mettre à jour tous les fichiers hosts de toutes les machines de votre réseau à chaque modification. A noter que dans ce cas, si vous avez des hôtes virtuels sur votre serveur web, vous devez les inscrire aussi dans tous vos fichiers hosts. Un autre inconvénient est que, d'​après mes essais, le serveur dns local est plus rapide que les fichiers hosts pour la résolution de nom. Concrètement,​ ce problème peut être contourné en utilisant plutôt les adresses ip locales fixes quand on veut copier de grands volumes de données avec les fichiers hosts, afn de gagner sur le temps de résolution de nom.
  
-On utilise la ligne suivante (en console sous root):+2- il m'a été signalé que pour les courriers, certains FAI posent problème si on utilise ​un autre serveur de nom que le leur. Dans ce cas, et sauf si vous changez de FAI pour cela, le retour aux fichiers hosts est la solution.
  
-  # lsof -i :21  -u^root -u^nobody | mawk '{print ​ $3 " ​  ​"$2" ​   "​$8}'​ | sort -u |  | grep -v '​USER'​+3Avant de chercher des infos n'importe où sur internet, commencez par lire le manuel de la suse 10.1 (voir "liens utiles" ​sur ce site).qui contient tout un chapitre (le 20) sur le système de noms de domaines, et en particulier sur les serveurs de nom.
  
 +4- Ce qui suit est destiné à des amateurs: pour apprendre, comprendre et s'​amuser. Les professionnels auront plus d'​exigences de fiabilité (serveur secondaire par exemple) et de sécurité.
  
-Cela donne si les utilisateurs "​tyrtamos"​ et "​jeanpaul"​ sont connectés ​à partir de la machine "​192.168.0.99":​+===== Problème ​à résoudre =====
  
-  jeanpaul ​  ​5103 ​    192.168.0.215:​ftp->​192.168.0.99:​1105 +Installer et configurer un serveur de nom (DNS) au sein de votre réseau local permettant d'​accéder à votre serveur web par son nom (au lieu de son adresse ip) et de façon plus rapide et plus facile à gérer que par les simples fichiers "​hosts"​.
-  tyrtamos ​  ​5089 ​    ​192.168.0.215:​ftp->​192.168.0.99:​1103+
  
-Commentaires:+Caractéristiques du réseau considéré à titre d'​exemple:
  
-  ​c'est "​mawk"​ qu'il faut prendre (remplace awk)+    ​OS: suse v 10.1
  
-  ​le "​-u^root"​ évite la ligne correspondant au processus d'​écoute ​du serveur+    ​nom du serveur: "​nesti"​
  
-  ​le "​-u^nobody"​ évite toutes les lignes correspondant aux processus d'​autorisation de chaque connexion+    ​adresse ip locale du serveur: 192.168.0.200
  
-  ​le "​$3"​ donne l'​identifiant,​ le "​$2"​ donne le pid et le "​$8"​ donne l'IP appelante+    ​adresse ip locale du routeur ​et de la passerelle internet: 192.168.0.1
  
-  ​le "sort -u" ​fait le tri, mais permet surtout ​de supprimer les doublons de la liste obtenue+    ​zone: "lan" ​pour pouvoir appeler ​le serveur: par http://​nesti.lan. Le choix de "​lan"​ est volontaire: il ne doit pas correspondre à une terminaison connue sur internet (comme "​com"​ par exemple). Mais cela peut être n'​importe quoi d'​autre,​ y compris "​machin.truc.bidule"​.
  
-  ​* le "grep" ​permet d'​éviter la ligne qui correspond aux libellés des colonnes fournis ​par lsof (sinonon a une ligne: ​"USER PID NODE")+    ​* le serveur web possède des hôtes virtuels avec des sites "perso" ​indépendants dont, par exemplel'​hôte ​"tyrtamos" ​qu'on voudrait appeler par: http://​tyrtamos.nesti.lan,​ et pas seulement par http://​nesti.lan/​~tyrtamos. Idem avec des sous-domaines comme http://​linux.nesti.lan qui appelle, par exemple, le site placé à /​srv/​www/​htdocs/​linux.
  
-Amélioration possible: il est inutile de répéter le nom de la machine ​serveur. Il faudrait que la colonne:+    * serveur ​dns choisibind version 9.3 (exactement 9.3.2-17)
  
-  nestidebian.local:​ftp->​192.168.0.99:​1103+    * Choix d'un serveur dns "​maître"​ sur la machine serveur web nesti.
  
-devienne:+    * Pas de serveur esclave.
  
-  192.168.0.99:​1103+A quoi correspond la notion de zône ? Tout simplement à la partie du réseau dans laquelle votre serveur de nom a la totale autorité ! D'où notre choix de "​lan"​ qui ne peut être desservi par aucun autre serveur de nom sur internet.
  
-On devrait pouvoir faire ça par une expression régulière.+===== Mode opératoire =====
  
-La commande est assez lente à cause de la tentative de convertion adresse IP -> nom de domaine. Si on ne veut que les adresses IP, on utilise l'​option "​-n"​ de "​lsof",​ et la réponse est très rapide. 
  
-Avec tout cela, on a bien la liste demandée: les utilisateurs connectés à un moment donné au serveur ftp, avec l'​IP ​de leur machine.+==== 1-Création des fichiers ​de zône du serveur DNS ====
  
-Mais je ne sais pas ce que ça donne si on configure vsftp avec des utilisateurs virtuels. Dans mes essaismon vsftp est configuré ​avec les utilisateurs ayant un compte linux sur la machine qui a le serveur ftp.+On devrait pouvoir configurer Bind avec yastmais yast pose des questions que je n'ai comprises qu'​après avoir configuré ​à la main... Et l'aide contextuelle de yast sur le sujet est très insuffisante.
  
-En complétant par une recherche dans le fichier log, on devrait pouvoir dire depuis combien ​de temps la connexion est active, et donner la liste des fichiers téléchargés (dans les 2 sens).+Fichier ​de config de bind: /​etc/​named.conf = on n'y touche pas.
  
 +On introduit les compléments dans le fichier "/​etc/​named.conf.include"​ existant déjà, mais livré vide.
 +
 +Nouveau contenu du fichier /​etc/​named.conf.include:​
 +
 +<​code>​
 +zone "​lan"​ in {
 +    type master;
 +    file "​master/​lan";​
 +    };
 +
 +zone "​0.168.192.in-addr.arpa"​ in {
 +    type master;
 +    file "​master/​0.168.192.in-addr.arpa";  ​
 +    };  ​
 +</​code>​
 +
 +On créé ainsi une zône appelée "​lan"​. Elle pourrait être "​machin.lan"​ auquel cas le serveur serait appelé http://​nesti.machin.lan,​ mais cette complexité est inutile ici.
 +
 +La déclaration de cette zone "​lan"​ nécessite les 2 déclarations ci-dessus, la 1ère qui va décrire la correspondance:​
 +
 +  * nom -> adresse_ip (dans le fichier "​lan"​)  ​
 +
 +et la seconde la correspondance inverse:
 +
 +  * adresse_ip -> nom (dans le fichier "​0.168.192.in-addr.arpa"​)  ​
 +
 +Le répertoire dans lequel se trouvent les fichiers .zone est indiqué dans le fichier /​etc/​named.conf,​ dans: option {...directory="/​var/​lib/​named"​...}. Vous noterez que par rapport à la version précédente,​ nous avons placé les fichiers zône "​master"​ dans /​var/​lib/​named/​master.
 +
 +Il faut maintenant créer les 2 fichiers zône.
 +
 +Contenu du 1er fichier /​var/​lib/​named/​master/​lan à créer (les numéros de lignes ne font pas partie du fichier!):
 +
 +<​code>​
 +   1. $TTL 3h
 +   2. @        IN   ​SOA ​  ​ns.lan. ​  ​root.localhost. (
 +   ​3. ​                 20060806001 ​ ; numéro de série dernière modif (=date renversée + numéro d'​ordre)  ​
 +   ​4. ​                 12H          ; durée du cycle de rafraichissement
 +   ​5. ​                 2H           ; Période avant nouvelle tentative
 +   ​6. ​                 1W           ; Durée d'​expiration
 +   ​7. ​                 1D )         ; Durée de vie du cache infos négat.
 +   8. @        IN   ​NS ​   ns.lan.
 +   9. ns       ​IN ​  ​A ​    ​192.168.0.200
 +  10. nesti    IN   ​A ​    ​192.168.0.200
 +  11. *.nesti ​ IN   ​A ​    ​192.168.0.200
 +</​code>​
 +
 +Quelques commentaires sur cette abominable syntaxe:
 +
 +    * ligne 2 et 8: à défaut d'une directive "​$ORIGIN",​ absente ici, le "​@"​ est remplacé par le nom de domaine de la commande "​zone"​ du fichier named.conf.include,​ c'est à dire "​lan"​.
 +
 +    * ligne 2: le nom root.localhost est une adresse mail. Le 1er point rencontré est automatiquement remplacé par un "​@"​. Vous mettez l'​adresse que vous voulez. Elle sera appelée par bind en cas de besoin.
 +
 +    * ligne 3: c'est un numéro utilisé pour renseigner le serveur dns secondaire des modifications du serveur primaire et qui déclenche des mises à jours. Le choix fait ici est de donner une date renversée + numéro d'​ordre,​ mais cela pourrait être un simple nombre qu'on incrémente à chaque modif.
 +
 +    * ligne 4 à 7: ce sont des temps de réaction nécessaires au fonctionnement de bind.
 +
 +    * ligne 2, 8 et 9: "​ns.lan"​ (adresse ip = 192.168.0.200) est donc ainsi désigné comme étant le serveur de nom qui a pleine autorité sur la zône "​lan"​
 +
 +    * ligne 10: c'est la correspondance principale "nom -> adresse ip".
 +
 +    * ligne 11: signifie que l'​appel à http://​nimportequoi.nesti.lan appellera 192.168.0.200. C'est une fonction peu documentée,​ mais très pratique: cela vous permettra de modifier vos hôtes virtuels dans apache sans avoir à modifier vos fichiers zône !  Cela correspond aussi au "​wildcard"​ de dyndns.org.
 +
 +    * remarque générale: ne pas oublier les "​."​ à la fin de certains noms! En fait, le point indique que le nom est à prendre tel quel. En l'​absence de point, le nom est complété du nom de zone ("​.lan"​ ici). Par exemple, "​nesti"​ devient "​nesti.lan",​ mais "​nesti."​ devient "​nesti"​ tout court, et "​nesti.lan"​ devient "​nesti.lan.lan"​!!! Attention aux erreurs.
 +
 +Bien sûr, si vous avez d'​autres machines, et même d'​autres serveurs web dans votre réseau local, il faut les inscrire de la même façon à la suite. par exemple:
 +
 +<​code>​
 +albert ​   IN   ​A ​    ​192.168.0.99
 +*.albert ​ IN   ​A ​    ​192.168.0.99  ​
 +arthur ​   IN   ​A ​    ​192.168.0.55
 +*.arthur ​ IN   ​A ​    ​192.168.0.55
 +</​code>​
 +
 +Contenu du 2ème fichier /​var/​lib/​named/​master/​0.168.192.in-addr.arpa à créer (les numéros de lignes ne font pas partie du fichier!):
 +
 +<​code>​
 +$TTL 3h
 +@   ​IN ​ SOA ns.lan. ​ root.localhost. (  ​
 +                20060806001
 +                12H
 +                2H
 +                1W
 +                1D )
 +@   ​IN ​ NS  ns.lan.
 +200 IN  PTR ns.lan.
 +200 IN  PTR nesti.lan.
 +</​code>​
 +
 +NB: le "​200"​ correspond au dernier chiffre de l'​adresse ip de la machine "​nesti"​ qui porte le serveur de nom et le serveur apache.
 +
 +Comme pour le fichier "​lan",​ il faut inscrire les autres machines de votre réseau local de la même façon. Par exemple:
 +
 +<​code>​
 +99 IN  PTR albert.lan.
 +55 IN  PTR arthur.lan.  ​
 +</​code>​
 +
 +On recharge les nouvelles données dans le serveur bind avec (dans une console sous root):
 +
 +  # /​etc/​init.d/​named reload  ​
 +
 +Pour relancer bind, vous pouvez aussi désactiver et réactiver named dans l'​éditeur de niveaux d'​exécution (yast -> système).
 +
 +==== 2-Configuration des machines clientes du réseau local ====
 +
 +=== Machine linux: ===
 +
 +On identifie les serveurs de nom à utiliser dans le fichier /​etc/​resolv.conf ou avec yast.
 +
 +Contenu de ce fichier:
 +
 +<​code>​
 +nameserver 192.168.0.200  ​
 +nameserver 192.168.0.1
 +search lan  ​
 +</​code>​
 +
 +192.168.0.200 est le serveur dns maître de la zone lan (=qui a pleine autorité sur les adresses "​xxx.lan"​).
 +
 +192.168.0.1 est l'​adresse du routeur, qui renvoie aux serveurs dns donnés par le fournisseur d'​accès à l'​établissement de la connexion internet. On peut indiquer à la place les vraies adresses des serveurs dns du fournisseur d'​accès internet. Si on met l'​adresse du routeur, c'est parce que c'est le routeur qui gère la connection adsl et qui donc connait les adresses du serveur dns du fournisseur d'​accès.
 +
 +On a l'​impression en faisant cela que le serveur de nom qu'on vient de mettre en place en local ne sera utilisé que pour votre réseau local "​*.lan"​ et que les autres serveurs de nom (ceux de votre FAI) seront utilisés pour tout le reste: c'est faux. il vous suffit de ne laisser que votre serveur dns local pour vérifier qu'il suffit pour tout. Mais s'il est en panne, ou si votre machine serveur dns est éteinte, les machines de votre réseau doivent continuer à pouvoir se connecter à internet en utilisant les serveurs dns secondaires.
 +
 +=== Machine windows: ===
 +
 +Plutôt que d'agir sur les fichiers de configuration,​ il vaut mieux utiliser les programmes de configuration:​ connection -> propriété de connection -> tcp/ip -> serveurs de nom. On met en 1er l'​adresse ip locale de votre serveur dns 192.168.0.200,​ et en 2ème l'​adresse ip locale du routeur ou à défaut les adresses ip externes des serveurs dns de votre fournisseurs d'​accès.
 +
 +=== Vérification:​ ===
 +
 +Pour être sûr que votre machine windows utilise bien votre serveur dns local, vous pouvez supprimer les correspondances dans le fichier hosts, et même arrêter netbios-samba. De ce fait, si vous pouvez atteindre encore votre serveur web, c'est que votre serveur dns local fonctionne.
 +
 +Au sein du réseau local, et à partir de n'​importe quelle machine ainsi configurée (windows ou linux), un appel à http://​nesti.lan appelle le serveur apache de la machine nesti. De même si le serveur apache a des sites persos (hôtes virtuels): http://​tyrtamos.nesti.lan,​ ou des sous-domaines (hôtes virtuels) http://​linux.nesti.lan.
 +
 +Vous pouvez vérifier la rapidité d'​accès de la manière suivante: en arrêtant le serveur dns et en configurant le fichier hosts de la machine cliente, faite un ping. Comparez avec celui que vous obtenez quand le serveur dns fonctionne. Vous pouvez aussi essayer cela avec des copies d'un grand volume de données entre vos machines.
bind_opensuse.txt · Dernière modification: 2007/12/15 09:51 par tyrtamos