TP réalisation réseau complet avec : routeurs (linux, Cisco) ; liaisons Ethernet et série (ppp) ; DNS ; DHCP ; HTTP ; Proxy tranparent

De Wiki de Romain RUDIGER
Aller à : navigation, rechercher

Participants : Benoît FARRE, Romain RÜDIGER, Nicolas Turpault, Alexandre Germonneau, Julien Bonnec, Jonathan Pares, Mohamed Zeineddine, Sylvain David et Benjamin Poncelet.

Période : 10/08.

Introduction

Ce Rapport présente tous les aspects du réseau que nous avons imaginé.

Vous trouverez dans un premier temps un schéma complet du réseau ainsi qu'une description de celui-ci. Dans un second temps la description de la réalisation de chaque partie de ce réseau avec :

  • description des fonctionnalités de cette partie ;
  • description de la mise en place de cette partie :
  • script(s) ;
  • fichier(s) de configuration ;
  • problèmes éventuels rencontrés.
  • conclusion.

Le réseau

Schéma du réseau

Schéma du réseau créé.

Description du réseau

Ce réseau consiste en la mise en place de deux zones (1: 10.0.0.0 et 2: 192.168.2.0). Les machines de ces deux zones sont reliées respectivement à un commutateur ayant deux VLAN (une pour chaque zone).

Les 2 zones sont reliées entre-elles par une liaison point à point série entre un routeur Cisco et un routeur "Linux". Ces 2 zones sont également reliés à 2 routeurs sans fil (WRT1 et WRT3).

Il est possible aux zones d'effectuer une navigation sur Internet (HTTP et HTTPS) en passant par un proxy transparent par la machine 9.

Il serait tout à fait possible d'imaginer que ces deux zones sont en fait deux entreprises distinctes et que toutes les machines constituent une partie du réseau public "Internet". Il faudrait bien sûr affecter des adresses IP publiques aux zones (10/24 ainsi que 192.168/24).

La mise en place

Le lien inter zone série ppp entre le Cisco et le PC11

Fonctionnalités

Créer un lien inter zone série en ppp en utilisant un routeur Cisco et un PC Linux.

Mise en place

Configuration du routeur Cisco

Current configuration : 1138 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname Cisco2621
!
enable password 7 14141B180F0B
!
ip subnet-zero
!
!
no ip domain-lookup
!
interface FastEthernet0/0
 description vers proxy internet PC6
 ip address 66.0.0.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description zone 1 vers PC7
 ip address 169.0.0.2 255.255.255.252
 duplex auto
 speed auto
!
interface Async65
 ip address negotiated
 encapsulation ppp
 async mode dedicated
!
ip default-gateway 66.0.0.1
no ip classless
ip route 10.0.0.0 255.255.255.0 169.0.0.1
ip route 88.0.0.0 255.255.255.252 Async65
ip route 192.168.2.0 255.255.255.0 Async65
no ip http server
no ip pim bidir-enable
!
line con 0
 exec-timeout 0 0
 password 7 13061E010803
 login
line aux 0
 modem InOut
 speed 115200
 flowcontrol hardware
line vty 0 4
 password 7 13061E010803
 login
!
no scheduler allocate
end

Configuration du PC11

  • On utilise ici pppd pour se connecter au Cisco via une liaison ppp. On modifie donc le fichier /etc/ppp/options.
# /etc/ppp/options
# 
ttyS0
115200
lock
passive
noauth
persist
local
88.0.0.2:88.0.0.1

Il faut alors relancer ppp pour prendre en compte la configuration.

 /etc/init.d/ppp start
  • Mais il est aussi possible de lancer directement pppd sans utiliser le fichier de configuration via cette ligne de commande :
/usr/sbin/pppd ttyS0 115200 debug lock passive noauth nodetach persist local 88.0.0.2:88.0.0.1

Problèmes

Lors de la mise en place du protocole de routage OSPF, les trames OSPF d'échange d'information ne traversent pas ce lien, il y avait donc une rupture entre la zone 1 et 2. Il semble que ce soit le fait que le port AUX du Cisco soit en mode passif...

Conclusion

La mise en place du lien PPP est complexe du fait que l'on utilise deux périphériques réseaux différents: PC Linux Debian et un routeur CISCO. La configuration du routeur CISCO fut laborieuse ainsi que pour le PC Debian lors de notre tentative d'ajout du protocole OSPF sur le lien. La configuration de routes statiques fut en revanche plus simple et sans trop de difficultés.

Le lien inter zone WiFi

Fonctionnalités

Le lien inter zone wifi consiste à créer 4 zones wifi à travers quatre routeurs WRT (Voir Schéma partie 2.1). Le routeur WRT permet de partager une connexion Internet vers des ordinateurs via 4 ports ethernet et une liaison à la norme sans fil IEEE 802.11B/G.

Mise en place

La mise en place du lien inter zone wifi se compose de plusieurs étapes. Au début, il fallait télécharger les images (Kamikaz 2.4) pour les routeurs et les installer. Pour le faire, il fallait aller dans le site de téléchargement des images de OpenWRT et télécharger Kamikaz 2.4:

http://downloads.openwrt.org/kamikaze/docs/openwrt.html

Avant le début de l'installation de l'image, il fallait configurer l'interface qui va être reliée au routeur :

ifconfig eth0 192.168.1.2

Ensuite il fallait lancer tftp (tftp sert à envoyer de fichiers au routeur) :

tftp 192.168.1.1  //Lancement de la connexion avec le WRT
tftp>trace       //Pour tracer les événements qui se passent lors du transfert
tftp>binary     //Pour préciser la nature des données transférées
tftp>rexmt 1
tftp>put <image> //Tout en branchant le WRT

En parallèle on lance un ping vers 192.168.1.1. On attend la fin du transfert de l'image, puis l'installation physique de cette image (power clignotant dans le WRT, pas de ping "Destination Host Unreachable")... On rebrancher le WRT après, et on attend son démarrage. L'étape suivante consiste à préciser un mot de passe en lançant Telnet. On lance SSH après en entrant le nouveau mot de passe. Il est temps maintenant de modifier les fichiers de configuration :

ssh root@192.168.1.1   //Connexion en ssh au WRT en mode admin
cd /etc               //Répertoire contenant le répertoire config 
cp -R config/ config-copy/ //Faire une sauvegarde des fichiers de configuration avant de les modifier
cd config             //Répertoire contenant le fichiers de configuration
vi network            //Premier fichier à modifier

On change la "##LAN configuration" pour fixer une adresse aux ports Ethernet du routeur.

## LAN configuration
   config interface lan
                    option type bridge
                    option ifname "eth0.0"
                    option proto static
                    option ipaddr monAdresse /*dépend du routeur que l'on configure, voir les adresses sur le schéma  
                                               2.1*/
                    option netmask 255.255.255.0

On fait la même procédure pour l'interface WiFi (wl0).

Après on doit modifier dans le fichier Wireless le type d'accès de l'interface WIFI (wl0) (access point, ad-hoc, station). Dans notre cas on choisit access-point et ad-hoc. Pour le faire dans "option-mode" on met soit ap soit adhoc (suivant le routeur) tout en précisant un SSID. Il faut faire attention puisque parfois il existe des types qui ne peuvent pas fonctinner ensemble.

Pour récupérer des fichiers qui se trouvent sur le pc :

scp userpc@adressePC:/path . /*Path: c'est le répertoire contenant les fichiers. "." c'est le répertoire courant
                               sur le WRT (normalement /etc/config)*/

On répète la même procédure pour les autres routeurs tout en précisant à chaque fois les adresses précises et le mode d'accès.

Conclusion

La configuration des routeurs WRT nous a permis de créer quatre zones Wi-Fi dans notre réseau. L'étape la plus dure dans ce travail était la première phase : l'installation des images sur les routeurs. La modification des fichiers de la configuration devait prendre en compte les adresses précises de chaque interface ainsi que les SSID de chaque zone.

Le serveur proxy HTTP

Fonctionnalités

Le but est d'offrir un accès HTTP vers l'internet, le proxy de l'école ne voulant pas nous répondre directement, nous avons mis en place un serveur Proxy HTTP transparent écrit en Perl fourni par Rémi LEHN ainsi que quelques règles IPTables.

Mise en place

Les règles IPTables

Voici les règles mises en place :

  • PREROUTING :
    • nat des requêtes DNS (tcp et udp) de notre réseau vers le serveur DNS de l'école.
    • redirection des requêtes HTTP(port 80 en tcp) et HTTPS(port 443 en tcp) vers le serveur proxy Perl qui va faire les requêtes au serveur proxy de l'école.
  • POSTROUTING :
    • masquer les IPs sources "internes" des paquets sortants sur l'interface "WEB" (eth0) par l'adresse IP de cette interface pour les ports DNS, HTTP, HTTPS et le proxy de l'école.
  • OUTPUT :
    • Par sécurité pour ne pas risquer d'envoyer des paquets sur le réseau de l'école, filtrage des paquets ayant comme adresse IP source une adresse "interne".
# Generated by iptables-save v1.3.8 on Wed Oct 22 13:02:49 2008
*nat
:PREROUTING ACCEPT [12:752]
:POSTROUTING ACCEPT [4:286]
:OUTPUT ACCEPT [3:201]
-A PREROUTING -p tcp -m tcp --dport 53 -m comment --comment "DNAT dns vers dns.polytech.univ-nantes.prive" -j DNAT --to-destination 172.19.0.4:53 
-A PREROUTING -p udp -m udp --dport 53 -m comment --comment "DNAT dns vers dns.polytech.univ-nantes.prive" -j DNAT --to-destination 172.19.0.4:53 
-A PREROUTING -p tcp -m multiport --dports 80,443 -m comment --comment "DNAT http/https vers proxy local (port tcp 3130)" -j REDIRECT --to-ports 3130 
-A POSTROUTING -o eth0 -p udp -m udp --dport 53 -j MASQUERADE 
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 53 -j MASQUERADE 
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 80 -j MASQUERADE 
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 443 -j MASQUERADE 
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 3128 -j MASQUERADE 
COMMIT
# Completed on Wed Oct 22 13:02:49 2008
# Generated by iptables-save v1.3.8 on Wed Oct 22 13:02:49 2008
*filter
:INPUT ACCEPT [420:87782]
:FORWARD ACCEPT [823:484061]
:OUTPUT ACCEPT [467:419795]
-A OUTPUT -s 1.2.3.1 -o eth0 -j DROP 
-A OUTPUT -s 10.0.0.0/255.255.255.0 -o eth0 -j DROP 
-A OUTPUT -s 169.0.0.0/255.255.255.252 -o eth0 -j DROP 
-A OUTPUT -s 192.168.2.0/255.255.255.0 -o eth0 -j DROP 
COMMIT
# Completed on Wed Oct 22 13:02:49 2008

Le proxy HTTP en perl

Le script perl par Rémi LEHN en écoute sur la boucle local port tcp 3130 :

#!/usr/bin/perl
#

use HTTP::Daemon;
use HTTP::Status;
use LWP::UserAgent;
use URI;

my $ua = LWP::UserAgent->new;
$ua->timeout(10);
$ENV{'http_proxy'} = 'http://172.19.1.12:3128/';
$ENV{'HTTP_PROXY'} = $ENV{'http_proxy'};
$ua->env_proxy;

my $d = HTTP::Daemon->new(LocalPort => 3130) || die;

print "Please contact me at: <URL:", $d->url, ">\n";

while (my $c = $d->accept) {
    if(!(my $pid = fork)) {
      while (my $req = $c->get_request) {

          my $uri = new URI($req->uri);
          unless(length($uri->scheme) > 0) {
            $req->uri('http://'.$req->header('Host').$req->uri);
          }

          warn "--- Requête : ---\n".$req->as_string."-----\n";

          my $res = $ua->request($req);

          warn "--- Réponse : --- ".$res->status_line." ---\n\n";
        
          $c->send_response($res);
      }
      exit(0);
    }
    $c->close;
    undef($c);
}

Conclusion

La mise en place du serveur Proxy fut complexe. Les régles IPTABLES nous ont permis de faire de la translation d'adresses (NAT) et la translation de ports (PAT). L'aide de Rémi LEHN nous a franchement aidé en ce qui concerne le script Perl.

Les routeurs frontaux de chaque zone

Fonctionnalités

Chaque routeur se doit d'assurer la liaison de deux routes :

  • Connexion à un routeur Wifi ;
  • Connexion à un autre routeur.

Ces routeurs sont les passerelles des réseaux privés qui contiennent les différents serveurs mis en place (sauf le proxy).

Deux configurations ont été effectuées sur ces routeurs :

  • Un premier routage statique a tout d'abord été mis en œuvre ;
  • Enfin dans un second temps un routage dynamique utilisant le protocole OSPF fut déployé.

Mise en place

Configuration du PC7 en routage Statique

Voici la configuration statique de la machine 7 par laquelle passe tout le trafic depuis et à destination de la Zone 1. Les trois interfaces de la machine sont utilisées :

  • une sur le réseau 10.0.0.0/24 qui la relie à la Zone 1.
  • une sur le réseau 169.0.0.0/30 qui la relie au Routeur Cisco.
  • une sur le réseau 128.0.0.0/30 qui la relie au routeur Wifi WRT4.

La passerelle par défaut est le routeur Cisco.

  • config-routeur7.sh
#eth0 lien A vers Zone1
ifconfig eth0 10.0.0.1/24
#eth1 lien C vers Cisco
ifconfig eth1 169.0.0.1/30
#eth2 vers WRT
ifconfig eth2 128.0.0.1/30

route add -net 169.0.0.0/30 eth1
route add -net 128.0.0.0/30 eth2

route add -net 88.0.0.0/24 gw 169.0.0.2
route add -net 81.0.0.0/24 gw 128.0.0.2
route add -net default gw 169.0.0.2

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

Configuration du PC12 en routage OSPF

Afin de déployer le routage OSPF sur cette machine Linux, il était nécessaire de se munir du paquet Quagga qui offre de nombreuses implémentations de protocole de routage sous Linux. Une fois ce paquet obtenu, nous avons cherché comment transformer PC12 en routeur OSPF. Nous avons activé le démon ospfd de Quagga afin d'appliquer ce routage. Puis nous avons configuré ospfd.conf comme ceci :

  • ospfd.conf
password silr2k
!
!
!
interface eth0
!
interface eth1
!
router ospf
 network 172.0.0.0/30 area 0.0.0.0
 network 173.0.0.0/30 area 0.0.0.0
 network 192.168.2.0/24 area 0.0.0.0
!
line vty
!

log stdout

Ne restait plus alors qu'à s'occuper de zebra.conf (le fichier de configuration du démon Zebra que lance Quagga).

  • zebra.conf
password silr2k
log file /var/log/zebra.log
log syslog
!
interface eth0
 ipv6 nd suppress-ra
!
interface eth1
 ipv6 nd suppress-ra
!
interface eth2
 ipv6 nd suppress-ra
!
interface lo
!
ip forwarding
!
!
line vty
!

Configuration du PC11 en routage OSPF

Comme pour le PC12, il faut installer Quagga. Voici donc les fichiers de configuration du PC11.

  • ospfd.conf
password admin
log stdout
!
!
!
interface eth1
!
interface ppp0
!
router ospf
 network 88.0.0.0/24 area 0.0.0.0
 network 173.0.0.0/30 area 0.0.0.0
!
line vty
!
  • zebra.conf
password admin
log file /var/log/zebra/zebra.log
log syslog
!
interface eth1
 ipv6 nd suppress-ra
!
interface ppp0
 ipv6 nd suppress-ra
!
ip forwarding
!
!
line vty
!

Conclusion

Les serveurs DHCP

Fonctionnalités

Le but est de donner dynamiquement la configuration IP des postes clients de la zone concernée.

Mise en place

Configuration du serveur DHCPD de la zone 1

Version du serveur dhcpd : 3

ddns-update-style none;

option routers 10.0.0.1;
option domain-name "zone1.priv";
option domain-name-servers 10.0.0.3, 10.0.0.5;

default-lease-time 600;
max-lease-time 7200;

log-facility local7;

subnet 10.0.0.0 netmask 255.255.255.0 {
	range 10.0.0.2 10.0.0.6;
	option routers 10.0.0.1;
}

host ns2.zone1.priv {
  hardware ethernet 00:1a:a0:d9:ce:65;
  fixed-address 10.0.0.5;
  option routers 10.0.0.1;
}

host ns1.zone1.priv {
  hardware ethernet 00:1a:a0:d9:ca:da;
  fixed-address 10.0.0.3;
  option routers 10.0.0.1;
}

resolv.conf :

search zone1.priv
nameserver 10.0.0.3
nameserver 10.0.0.5

Mise en place du serveur DHCPD de la zone 2

Utilisation du paquet dhcp3-server

resolv.conf:

search zone2.prive
nameserver 192.168.2.1
nameserver 192.168.2.2

Configuration du réseau:

ifconfig eth1 192.168.2.4
ip route flush all
route add -net 192.168.2.0/24 dev eth1 
route add  default gw 192.168.2.254


Contenu du fichier /etc/dhcp3/dhcpd.conf

authoritative;

option domain-name "zone2.prive";
option domain-name-servers 192.168.2.1, 192.168.2.2;
option routers 192.168.2.254;

default-lease-time 600;
max-lease-time 7200;
subnet 192.168.2.0 netmask 255.255.255.0 {
	range 192.168.2.100 192.168.2.150;
}

host ns1.zone2.prive  {
  hardware ethernet 00:1a:a0:d9:d4:97;
    fixed-address 192.168.2.1;
    }

host web.zone2.prive  {
  hardware ethernet 00:1a:a0:d9:d0:46;
  fixed-address 192.168.2.8;
}

host ns2.zone2.prive  {
  hardware ethernet 00:1a:a0:da:54:8e;
  fixed-address 192.168.2.2;
}

Conclusion

La configuration d'un serveur DHCP est relativement simple et très bien documenté sur le Web. On peut décrire deux grandes parties dans dans la configuration du serveur:

  • La configuration d'une plage d'adresse, du masque, du bail,...
  • L'ajout des blocs nécessaires aux machines devant posséder en permanence la même adresse IP en indiquant leurs adresses MAC. (Fastidieux si beaucoup de machines sont demandeuses de ce service).

Les serveurs DNS

Fonctionnalités

Il y a quatre serveurs DNS sur ce réseau. Deux noms de domaine sont utilisés : zone1.priv et zone2.prive.

Nous utilisons un serveur principal et un serveur secondaire pour chaque zone.

Mise en place

Voici les fichiers de configuration pour la zone1

Le serveur dns principal a l'ip 10.0.0.3 et le secondaire l'ip 10.0.0.5.

named.conf master

zone "zone1.priv" {
	type master;
	notify yes;
	file "/etc/bind/db.zone1.priv";
	forwarders{};
};

zone "0.0.10.in-addr.arpa" {
	type master;
	file "/etc/bind/db.zone1.priv.inv";
	forwarders{};
};

named.conf.options master

	forwarders {
		10.0.0.3;
		10.0.0.5;
		172.19.0.4;
	};

	allow-transfer {
		10.0.0.5;
	};

allow-transfer, ip autorisée a récupérer la configuration du master, donc l'ip du serveur dns secondaire.

db.zone1.priv

$TTL    604800
@ IN SOA ns1.zone1.priv. root.zone1.priv.  (
        200810082  ; Serial  -> N° de série à incrémenter à chaque modif
                   ;            de ce fichier. Ce N° est utilisé par les
                   ;            serveurs esclaves pour lui indiquer qu'il
                   ;            doit mettre à jour sa base. Par commodité
                   ;            ce n° est une date à l'envers.
        604800     ;Refresh ->  A l'expiration du délai Refresh exprimé en
                   ;            secondes, le serveur excalve va entrer en
                   ;            communication avec le maitre et si il ne
                   ;            le trouve pas, il fera une nouvelle
                   ;            tentative au bout du délai Retry et si au
                   ;            bout du délai Expire il considerera que le
                   ;            serveur n'est plus disponible.
        86400      ; Retry
        2419200    ; Expire
        604800 )   ; Minimum -> Durée de vie minimum du cache en secondes

;** Pour le master
	NS	ns1.zone1.priv.		;Nom du serveur
	NS	ns2.zone1.priv.		;Nom du serveur dns esclave
ns1	A	10.0.0.3                ;Serveur de noms master
ns1	HINFO	"DNS master" "test ns1" ;Infos

;** Les lignes suivantes définissent la table entre les noms et les IP
routeur         A       10.0.0.1
ns2             A       10.0.0.5
dhcp            A       10.0.0.7

db.zone1.priv.inv

$TTL    604800
@       IN      SOA     ns1.zone1.priv. root.zone1.priv.  (
	20081008
	604800
	86400
	2419200
	604800 )

	NS      ns1.zone1.priv.
	NS      ns2.zone1.priv.

1	PTR     routeur.zone1.priv.
3	PTR	ns1.zone1.priv.
5	PTR	ns2.zone1.priv.
7	PTR	dhcp.zone1.priv.

Configuration du serveur DNS secondaire Le serveur dns secondaire a l'ip 10.0.0.5

named.conf

zone "zone1.priv" {
       type slave;
       file "db.zone1.priv";
       masters {10.0.0.3; };
};

zone "0.0.10.in-addr.arpa" {
       type slave;
       file "db.zone1.priv.inv";
       masters {10.0.0.3; };
};

named.conf.options

allow-notify { 10.0.0.3; };

Voici les fichiers de configuration pour la zone 2

Contenu du fichier /etc/bind/named.conf

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

zone "zone2.prive" {
	type master;
	notify yes;
	file "/etc/bind/db.zone2.prive";
	forwarders{};
};

zone "2.168.192.in-addr.arpa" {
       type master;
       notify yes;
       file "/etc/bind/db.zone2.prive.inv";
       forwarders{};
};

Contenu du fichier /etc/bind/db.zone2.prive

$TTL	604800
@	IN	SOA	ns1.zone2.prive. ns2.zone2.prive. (
		3		; Serial
		604800		; Refresh
		86400		; Retry
		2419200		; Expire
		604800 )	; Negative Cache TTL
;

	NS	ns1.zone2.prive.
	NS	ns2.zone2.prive.

ns1	A	192.168.2.1                  
ns1	HINFO	"NS ZONE2" "Debian Testing"  ;Info complèmentaire



web	A	192.168.2.8
dhcp	A	192.168.2.4
ns2	A	192.168.2.2

Contenu du fichier /etc/bind/db.zone2.prive.inv

$TTL    604800
@ 	IN      SOA     ns1.zone2.prive. ns2.zone2.prive.  (
		20041122        
		604800        
		86400        
		2419200        
		604800 )      

	NS	ns1.zone2.prive.  
1	PTR	ns1.zone2.prive.
2	PTR     ns2.zone2.prive.
8	PTR	web.zone2.prive.
4	PTR	dhcp.zone2.prive.

Contenu du fichier named.conf.options

options{
   allow-transfer { 192.168.2.2; };
   forwarders
   {
	172.19.0.4;
	10.0.0.3;
	10.0.0.5;
   };
};

Configuration du serveur DNS secondaire Le serveur dns secondaire a l'ip 192.168.2.2

named.conf

zone "zone2.prive" {
       type slave;
       file "db.zone2.prive";
       masters {192.168.2.1; };
};

zone "2.168.192.in-addr.arpa" {
       type slave;
       file "db.zone2.prive.inv";
       masters {192.168.2.1; };
};

named.conf.options

options{
   allow-notify { 192.168.2.1; };
   directory "/var/cache/bind"
};


Problèmes

Aucun problème rencontré pour la zone1, un problème sur le serveur secondaire de la zone2 a été rencontré, il s'agissait d'un oubli de ligne, le serveur secondaire refuse de démarrer si l'option directory n'est pas mise. La consultation du fichier syslog a permit de facilement trouver les erreurs.

Conclusion

La difficulté majeur est de réussir à configurer le serveur DNS primaire puisque ensuite le serveur DNS secondaire n'est qu'une réplication de la configuration du primaire.

Le serveur HTTP

Mode de fonctionnement sommaire d'un serveur HTTP

Au moment de son démarrage, Apache (le serveur HTTP qu'on va utiliser) charge le fichier de configuration de notre machine locale (ici la machine 8, adresse IP : 192.168.2.8/24, zone 2 privée)et se met en attente des requêtes sur son interface réseau.

Lorsque qu'on utilise un navigateur web (un client HTTP comme Mozilla Firefox par exemple) et que l'on clique sur un lien ou qu'on rentre directement l'adresse URL dans la barre d'adresse, on effectue une requête :

ETAPE 1 :le client se connecte au serveur (voir documentation DNS).

ETAPE 2 : le client effectue une requête HTTP sur le serveur lui demandant une page par la méthode GET du protocole HTTP.

ETAPE 3 : Après l'analyse de la requête, le serveur renvoie la page concernée sous forme de code dont on peut spécifier le format de données.

ETAPE 4 : le serveur ferme la connexion.

ETAPE 5 : le client l'analyse et construit alors l'affichage à partir du code reçu.

Nous avons présenté succinctement le fonctionnement général du protocole HTTP et d'un serveur HTTP. Dans la suite de notre exposé, nous allons voir en détail, l'installation du serveur APACHE 2.

Installation et configuration du serveur APACHE 2

Apache est composé de plusieurs paquets, ces derniers sont listés et décrit succinctement ci-dessous.


Liste des paquets pour APACHE 2


Bibliothèque, le serveur et ses outils


libapr1 : Apache's Portable Runtime Library, bibliothèque de fonctions standards portables.

apache2 : Paquet contenant le serveur.

apache2.2-common : Paquet contenant les modules standards apache2, qui incluent le support SSL.

apache2-utils : Paquet contenant les outils pour le serveur web.


Le MPM : Multi-Processing Module (module multi-traitements)


Le MPM estc' indispensable, c'est le moteur du serveur, la manière dont il intercepte les requêtes. Il en existe plusieurs.

apache2-mpm-prefork : c'est le modèle traditionnel pour Apache2 version sans thread, il intercepte les requêtes à la manière d'Apache 1.3, c'est utile pour éviter la mise en thread pour la compatibilité avec les bibliothèques non-thread-safe.

apache2-mpm-worker : Modèle à processus haute vitesse pour Apache2 version avec thread, il est beaucoup plus rapide que la version traditionnelle.

Il existe aussi d'autres paquets, qui sont des modules que l'on peut rajouter. Ils permettent la prise en charge simplifiée des différentes technologies comme PHP5, PERL ou PYTHON, mais cela dépasse dans le cadre de notre TP.


Installation


On télécharge et on installe les paquets qui nous intéressent :

apt-get install apache2 apache2-mpm-prefork

Ensuite nous lançons le serveur si ce dernier n'est pas déjà lancé :

/etc/init.d/apache2 start

Vérification de son fonctionnement


Pour vérifier son bon fonctionnement, j'ouvre le navigateur et me rend sur http://localhost/. On peut voir une page qui m'informe que le serveur marche correctement (It works !).

Mais attention, il est aussi nécessaire de faire la même opération (avec http://192.168.2.8/) à partir d'un autre poste du réseau car une mauvaise configuration du fichier ports.conf peut être commise. (voir fichier ports.conf après)


Configuration


Maintenant que le serveur est installé et fonctionne correctement, je vais regarder rapidement sa configuration.

Les fichiers de configuration sont dans le répertoire /etc/apache2/, ces fichiers sont listés et décrit de façon très brève ci-dessous :

httpd.conf : c'est le fichier utilisé par apache1, il est conservé vide dans apache2 pour assurer la rétrocompatibilité.

envvars : c'est le fichier utilisé pour définir des variables d'environnement propres à apache.

ports.conf : c'est le fichier où on indique les ports que Apache doit écouter, dans notre cas c'est Listen 80 car nous écoutons que le port correspondant à HTTP. On peut aussi préciser l'interface sur laquelle on écoute (si on est connecté aussi au réseau de polytech par l'intermédiaire du réseau B et qu'on ne veut pas répondre aux requêtes venant sur cette interface) . Dans notre cas, il suffit juste de mettre :

Listen 192.168.2.8:80
Listen 127.0.0.1:80

apache2.conf : c'est le fichier principal de configuration. (Le fichier par défaut convient très bien pour le cadre limité de notre TP mais si on veut le modifier ce n'est pas un problème car il est très bien documenté).

conf.d : c'est un répertoire qui contient plusieurs petits fichiers qui seront analysés par apache. Le seul fichier par défaut est charset,il spécifie l'encodage à utiliser par défaut.

mods-available : ce fichier contient la liste des modules d'apache installés.

mods-enabled : ce fichier contient la liste des modules utilisés ;

sites-available : ce fichier contient la liste des vhosts (hôtes virtuels) installés ;

sites-enabled : ce fichier contient la liste des vhosts (hôtes virtuels) utilisés.

Conclusion

La mise en place d'un serveur HTTP est très simple surtout pour la cas de notre TP mais peut être un peu plus complexe si on veut rajouter des modules supplémentaires ou gérer plusieurs hôtes virtuelles.

Conclusion

Ce TP a été une expérience très enrichissante aussi bien sur un plan technique que humain. Nous avons dû nous mettre d'accord et trouver des solutions aux problèmes causés par le réseau que nous avons conçu. Pour concevoir un tel réseau, le travail en équipe était primordial. Sur un plan technique, nous avons mis en pratique les services primaires des réseaux Ethernet classique tel que DNS, DHCP, Routage dynamique, HTTP ...

Une déception subsiste; nous n'avons pas tester les performances du réseau. Aucune sécurité n'a été mise en place. Notre déploiement se limitait au bon fonctionnement des serveurs et protocoles utilisés.