Agent de relais DHCP

Le but de ce billet est d'installer un agent de relais DHCP sur un routeur Linux/Ubuntu

Vous avez configuré votre serveur DHCP, pour qu'il fournisse des adresses IP à tous votre réseau, et vous avez même été plus loin , puisque votre DHCP gère même plusieurs sous réseaux...

Par exemple 192.168.1.0/24 et 192.168.2.0/24

votre DHCP est situé sur le sous réseau 192.168.1.0/24 et attribue très bien les adresses à tous les postes de son sous réseau.

Mais le problême, c'est que le sous réseau 192.168.2.0/24 est situé derrière un routeur. (un routeur Linux ... Ouf on a de la chance ;-) )

On remarque alors que ce sous réseau ne se fait pas attribuer d'addresse IP par notre serveur.

Que se passe t'il ??

c'est pourtant Simple ;-)

la base d'une requete DHCP est le suivant:

1/ Lorsque le client DHCP démarre, il n'a aucune connaissance du réseau, du moins, en principe. Il envoie donc une trame "DHCPDISCOVER", destinée à trouver un serveur DHCP. Cette trame est un "broadcast", donc envoyé à l'adresse 255.255.255.255. N'ayant pas encore d'adresse IP, il adopte provisoirement l'adresse 0.0.0.0. Comme ce n'est pas avec cette adresse que le DHCP va l'identifier, il fournit aussi sa "MAC Address".

 

2/ Le, ou les serveurs DHCP du réseau qui vont recevoir cette trame vont se sentir concernés et répondre par un "DHCPOFFER". Cette trame contient une proposition de bail et la "MAC Address" du client, avec également l'adresse IP du serveur. Tous les DHCP répondent et le client normalement accepte la première réponse venue.

 

3/ Le client répond alors par un DHCPREQUEST à tous les serveurs (donc toujours en "Broadcast") pour indiquer quelle offre il accepte.

4/ Le serveur DHCP Concerné répond définitivement par un DHCPACK qui constitue une confirmation du bail. L'adresse du client est alors marquée comme utilisée et ne sera plus proposée à un autre client pour toute la durée du bail.

(cf : Le site de Caleca )

Une requete DHCP est donc un broadcast : et comme vous le savez tous, les routeurs bloquent les broadcast, afin d'isoler les sous réseau en domaine de broadcast.

Donc forcement notre requete DHCP est bloquée et éliminée par notre routeur.

Heureusement il existe une solution :

Installer un service relai DHCP.

Sous Linux c'est dhcp-relay

sudo apt-get install dhcp3-relay

Le script d'installation vous demande alors quel serveur dhcp vous voulez écouter... Mettez ici l'IP de votre serveur.

Le script vous demande sur quelles interfaces ecouter, Ne mettez rien, et il écoutera sur toutes les interfaces.

Vous pouvez de toute facon modifer ces options en éditant le fichier /etc/default/dhcp3-relay

 # Defaults for dhcp3-relay initscript # sourced by /etc/init.d/dhcp3-relay # installed at /etc/default/dhcp3-relay by the maintainer scripts # # This is a POSIX shell fragment # # What servers should the DHCP relay forward requests to? SERVERS="192.168.1.101" # On what interfaces should the DHCP relay (dhrelay) serve DHCP requests? INTERFACES="eth0 eth1" # Additional options that are passed to the DHCP relay daemon? OPTIONS=""

Voila à présent votre routeur va écouter les requetes dhcp et les rediriger vers les bonnes interfaces... autrement dit toutes puisque c'est un broadcast ;-)

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.

Installation d'un serveur DHCP sous Linux/ubuntu

Un serveur DHCP, en plus de fournir la configuration IP "de base" (Adresse et masque), peut aussi transmettre un nombre plus ou moins grand de paramètres supplémentaires

l'ip du poste le masque de sous réseau la passerelle les serveurs DNS et Wins

Tout d'abord il faut installer le service dhcp3 sur notre distribution préférée... sudo apt-get install dhcp3-server

Une fois installé , il faut éditer le fichiers /etc/dhcp3/dhcpd.conf:

voici mon fichiers avec mes configurations persos:

#Mon Serveur DHCP #Mon domaine option domain-name "appart.lan"; 
#Le serveur Wins option netbios-name-servers 192.168.1.101; #Les serveurs DNS option domain-name-servers 192.168.1.101, 212.27.53.252; #Mon routeur passerelle #option routers 192.168.1.254; #Le bail default-lease-time 21600; #Les sous réseaux #Le sous reseau 192.168.1.0 subnet 192.168.1.0 netmask 255.255.255.0 {  range 192.168.1.110 192.168.1.115; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.254; } #le sous reseau 192.168.2.0 subnet 192.168.2.0 netmask 255.255.255.0 {  range 192.168.2.110 192.168.2.115; option subnet-mask 255.255.255.0; option broadcast-address 192.168.2.255; option routers 192.168.2.100; } #Configuration des IP fixes #Mon PC B@rtounet host Bartounet  {  hardware ethernet 00:08:54:37:8b:3f;  fixed-address 192.168.1.100; } #Le portable host Laptop { hardware ethernet 00:11:95:48:87:7A; fixed-address 192.168.1.105; } #PC de Pasc host Pasc { hardware ethernet 00:e0:4d:0f:37:ef; fixed-address 192.168.1.102; } #PC de Salon host PCSALON { hardware ethernet 00:0f:ea:84:4a:c8; fixed-address 192.168.1.103;

Si le poste est un routeur avec deux interfaces réseaux, il faut prendre soin de configurer les interfaces qui seront à lécoute des requetes DHCP Pour cela il faut editer le fichier /etc/default/dhcp3-server

# Defaults for dhcp initscript # sourced by /etc/init.d/dhcp # installed at /etc/default/dhcp3-server by the maintainer scripts # # This is a POSIX shell fragment # # On what interfaces should the DHCP server (dhcpd) serve DHCP requests? #       Separate multiple interfaces with spaces, e.g. "eth0 eth1". INTERFACES="eth0 eth2"

après cela n'oubliez pas de redemarrer le daemon dhcp

sudo /etc/init.d/dhcp3-server restart

«précédente page 11 sur 11