Activer le routage sur Linux

Le problême est le suivant, vous avez un poste sous linux, avec deux interfaces eth0 et eth1 par exemple..

vous souhaitez que le poste se comporte comme un routeur afin de rediriger les paquets vers les interfaces appropriées.

Vous aurez beau mettre les ip que vous voulez et les routes statiques que vous voulez, cela ne marchera pas tant que vous n'aurez pas déverouillé le forwarding

La commande est simple :

echo 1 > /proc/sys/net/ipv4/ip_forward

après cela votre poste est capable de router ;-)

Installation d'un serveur DNS sous Linux/Ubuntu

Sur internet, toutes les machines sont communiquent et sont identifiées par des adresses ip. Cependant on comprend aisément qu'il est beaucoup plus facile de retenir des adresses de site tels que http://forum.ubuntu-fr.org/ que son adresse ip 80.82.17.133.

C'est pourquoi il existe des serveurs DNS (domain Name Server) qui vont traduire les noms en adresses IP et inversement.

Sans entrer dans le détail, car DNS est un service complexe. Quand votre poste va demander l'adresse ip d'un poste (local ou distant) a partir de son nom, il va interroger son serveur DNS.

Le client va faire une requet ittérative au serveur : C'est à dire qu'il demande une réponse complète. Le serveur doit alors donner à son client uné réponse pleinement qualifiée pour se faire il va regarder dans son cache pour savoir si il dispose directement de l'adresse demandé par son client. Si il possède cette adresse il l'a fourni directement, par contre si il ne la possède pas, il va devoir interroger les serveurs racines ou "." par le biais de requetes récursives.

Il va interroger "." pour savoir quel est le serveur qui gere la zone .org Quand il saura quel serveur gere la zone .org, il va demander à ce dernier qui gère le domaine ubuntu-fr quand il saura quel serveur gère le domaine ubuntu.fr, il va lui demander de lui fournir l'adresse ip du poste forum

Grace a toutes ces requetes récursives aux differents serveur DNS le serveur DNS local pour alors répondre à la requète ittérative de son client.

Cet article à pour but de décrire brievement l'installation de mon serveur DNS sous Ubuntu, par le biais de Bind9.

Le But est d'installer un serveur DNS en local sur un poste serveur Linux/Ubuntu grace à bind9

donc comme on s'en doute la première chose à faire est d'installer le paquet bind9

sudo apt-get install bind9

quand le service est installé on va aller editer le fichier de configuration de bind qui est /etc/bind/named.conf

Mieux que des grands discours voici mon fichier named.conf

pctest@pctest:/etc/bind$ vi named.conf

include "/etc/bind/named.conf.options"; zone "." {

        type hint;         file "/etc/bind/db.root"; }; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "localhost" {         type master;         file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" {         type master;         file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" {         type master;         file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" {         type master;         file "/etc/bind/db.255"; }; zone "appart.lan" {         type master;         file "/etc/bind/db.appart.lan"; }; zone "1.168.192.in-addr.arpa" {         type master;         file "/etc/bind/db.appart.lan.inv"; }; zone "2.168.192.in-addr.arpa" {         type master;         file "/etc/bind/db.appart.lan2.inv"; }; // zone "com" { type delegation-only; }; // zone "net" { type delegation-only; }; // From the release notes: //  Because many of our users are uncomfortable receiving undelegated answers //  from root or top level domains, other than a few for whom that behaviour //  has been trusted and expected for quite some length of time, we have now //  introduced the "root-delegations-only" feature which applies delegation-only //  logic to all top level domains, and to the root domain.  An exception list //  should be specified, including "MUSEUM" and "DE", and any other top level //  domains from whom undelegated responses are expected and trusted. // root-delegation-only exclude { "DE"; "MUSEUM"; }; include "/etc/bind/named.conf.local";

Comme on peut le voir j'ai décidé d'appeler mon domaine appart.lan, mais on a le choix de mettre n'importe quoi en local...

on a donc une zone de recherche directe : la zone "appart.lan" et une zone de recherche inversée : la zone zone "1.168.192.in-addr.arpa" (l' autre zone est lorsque j'utilise mon serveur comme routeur et donc que je gère une autre plage d'adresse ip 192.168.2.0)

On voit que chaque zone fait référence à un fichier de configuration. Ce fichier va regrouper tous les pointeurs que la zones pourra gerer.

Dans mon exemple j'ai donc dut creer 2 fichiers :

sudo touch /etc/bind/db.appart.lan
sudo touch /etc/bind/db.appart.lan.inv

le nom de ces fichiers est totalement libre, il faut juste que le nom soit le meme que dans le named.conf

Une fois crées, on s'attaque à la configuration de ces fichiers:

voici mon /etc/bind/db.appart.lan

$TTL 3h @       IN      SOA     ns.appart.lan. hostmaster.appart.lan. (                                 2007030701                                 8H                                 2H                                 1W                                 1D ) @       IN      NS      ns.appart.lan. @       IN      MX      10      mail.appart.lan. ns              IN      A       192.168.1.101 mail           IN      A       192.168.1.101 pctest          IN      A       192.168.1.101 Pasc              IN      A       192.168.1.102 pcsalon         IN      A       192.168.1.103 laptop          IN      A       192.168.1.105 www             IN      CNAME   pctest 

brievement,

on indique le serveur DNS qui gère la zone.

Les valeurs qui suivent sont :

  1. le numéro de série (souvent on met la date courante suivie d'un numéro d'ordre); AAAAMMJJxx.
  2. le temps de rafraichissement (refresh; ici, 8 heures); la valeur recommandée est de 24 heures.
  3. le temps entre deux essais (retry; ici, 2 heures); la valeur recommandée est de 2 heures.
  4. le temps d'expiration (expire; ici, 1 semaine); la valeur recommandée est de 1000 heures.
  5. la valeur TTL minimum (minimum; ici, 1 jour); la valeur recommandée est de 2 jours.

Enfin on insère les pointeurs qui reoudront les nom en ip... j'ai même rajouté un alias www pointe vers pctest, autrement dit quand on cherchera dans mon reseau local à joindre www.appart.lan le serveur dns cherchera en fait pctest.appart.lan c'est à dire 192.168.1.101

Passons au fichier /etc/bind/db.appart.lan.inv qui gère la zone inverse... Comme on s'en doute ce fichier va servir à résoudre les adresses ip en noms. voici mon fichier :

$TTL 3h @       IN      SOA     ns.appart.lan. hostmaster.appart.lan. (                                 2007030701                                 8H                                 2H                                 1W                                 1D ) @       IN      NS      ns.appart.lan. @       IN      MX      10      mail.appart.lan. 101             IN      PTR     ns.appart.lan. 101             IN      PTR     mail.appart.lan. 101             IN      PTR     pctest.appart.lan. 102             IN      PTR     pasc.appart.lan. 103             IN      PTR     pcsalon.appart.lan. 105             IN      PTR     laptop.appart.lan.

Quand les fichiers sont prêts il n'y à pas de raison que notre serveur DNS ne fonctionne pas. bien sur après l'avoir redémmaré pour prendre en compte nos modifs:

sudo /etc/init.d/bind9 restart

On peut alors faire quelques tests :

Je vous laisse le soin de configurer votre connexions sur votre OS préféré pour utiliser le serveur DNS que vous venez d'installer...

Prenons par exemple un Client Windows (hé oui il faut aussi en faire un peu ... :-) )

Faisons Démarrer/executer/cmd

on utilise nslookup..

Microsoft Windows XP version 5.1.2600 (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Bart>nslookup Serveur par dÚfaut :  ns.appart.lan Address:  192.168.1.101 > pctest.appart.lan Serveur :  ns.appart.lan Address:  192.168.1.101 Nom :    pctest.appart.lan Address:  192.168.1.101 > laptop.appart.lan Serveur :  ns.appart.lan Address:  192.168.1.101 Nom :    laptop.appart.lan Address:  192.168.1.105

On voit bien que notre serveur utilise les pointeurs qu'on lui a indiqué pour résoudre les noms...

a notre grande surprise on se rend compte qu'il résoud même les noms en dehors du réseau local. C'est normal il va demandé au serveurs racines qui sont définit dans son fichier db.root

A partir de là notre DNS fonctionne bien...

si vous vous sentez triste d'utiliser les serveurs racines, rien ne vous empêche d'utiliser les Serveurs DNS de votre FAI

dans ce cas il y a plusieurs solutions moi je les ai rajoutés dans /etc/bind/named.conf.options car si vous regardez bien dans le named.conf ce fichiers est déclarer de base au départ include "/etc/bind/named.conf.options";

Donc dans ce fichiers on peut mettre nos redirecteurs

options {         directory "/var/cache/bind";         // If there is a firewall between you and nameservers you want         // to talk to, you might need to uncomment the query-source         // directive below.  Previous versions of BIND always asked         // questions using port 53, but BIND 8.1 and later use an unprivileged         // port by default.         // query-source address * port 53;         // If your ISP provided one or more IP addresses for stable         // nameservers, you probably want to use them as forwarders.         // Uncomment the following block, and insert the addresses replacing         // the all-0's placeholder.          forwarders {                 212.27.53.252;                 212.27.54.252;          };         auth-nxdomain no;    # conform to RFC1035 };  

et voila à partir de la et après avoir relancé le daemon notre serveur DNS redirigera ces requetes sur ses redirecteurs plutot que les racines... On peut tout à fait verifier ca sur une capture de trame...

Allez je suis gentils je vous la fait ;-)

Grace au magnifique Wireshark ancienement ethereal on obtient ceci

On voit bien dans le screen que la premiere requete concernant Google, notre server DNS ne l'a pas en local, et demande donc l'adresse au serveur de mon fai

Mais pour la deuxième requête, www.free.fr, notre serveur DNS donne tout de suite la réponse à son client, car il l'a possède dejà en cache

A venir : je vous montrerai bientôt coment rendre le serveur DNS dynamique. C'est à dire que couplé au dhcp, les clients s'enregistrent seuls dans le DNS. Même si leur IP change, l'enregistrement DNS se met à jour, ce qui n'etais pas le cas jusqu'a maintenant.

«précédente page 31 sur 32 suivante