CoursDocuments

Réseau Cisco

Comptes Rendus des TPs Re seaux 

TP : 

TP 1 – Déploiement de réseaux IP sous Linux et MS Windows TP 2 – Partage d’une connexion en utilisant SQUID & IPTABLES TP 3 – Déploiement des services DHCP et DNS TP 4 – Déploiement de réseaux IP sous IOS Cisco TP 5 – Configuration de LANs & Interconnexion de niveau 2sous IOS Cisco 

2012/2013 

TP – Déploiement de réseaux IP sous Linux et MS Windows 

Objectifs : – Configuration d’adresses IP statiques. – Configuration d’un routage statique / dynamique (RIP,OSPF). – Familiarisation avec les commandes, les fichiers et les interfaces de configurations propres aux systèmes d’exploitation : Linux, MS Windows. – Diagnostic du fonctionnement d’un réseau. 

Barème : 3+5+2+3+2.5+2.5+2 

Environnement matériel et logiciels 

Pour les besoins des différentes manipulations (sous Linux et sous MS Windows), des machines virtuelles en réseau sont installées sur un même ordinateur de travail (en utilisant VMware). Au total vous disposez de 4 machines en réseau, parmi lesquelles trois sont des machines Linux virtuelles. Ces 4 machines sont désignées respectivement par les noms suivants : OpenSuse, Fedora, Ubuntu et Windows. Pour la machine Windows il s’agit d’une version « MS Windows 2008 Server » (La version Server est utile pour la partie relative à la configuration du routage dynamique). 

Pour connecter en réseau ces différentes machines, et à chaque fois que le TP le nécessite vous pouvez éditer les réseaux (sous VMware : Edit>Virtual Network Editor). A cet effet, tous les réseaux virtuels (VMnet) seront internes (Host-only). Désactiver l’affectation dynamique des adresses IP (par VMware) et fixer l’adresse réseau et le masque pour chaque réseau édité. En outre pour chaque machine virtuelle, fixer les interfaces réseaux (en se positionnant sur l’onglet relative à une machine virtuelle et avec le bouton droit > setting). 

Pour ce qui est de la machine Windows, éditer la configuration réseau des interfaces VMnet en accédant à leurs propriétés comme vous le feriez pour une interface réelle. 

Dans tout le TP et pour chaque manipulation vous devez préciser les privilèges nécessaires (U : simple-utilisateur, S : super-utilisateur) pour réaliser chaque manipulation. 

Configuration d’adresses IP statiques 

1) Nous allons commencer par configurer les 4 machines sur un même réseau IP (VMnet1 par exemple) en utilisant l’adresse privée 192.168.0.0 et en appliquant le masque par défaut. Le tableau suivant précise l’adresse de chacune des machines : Nom de la machine Adresse IP Login Password/root password Windows 192.168.0.65 Administrateur windows Fedora 192.168.0.1 fedora fedora Ubuntu 192.168.0.129 ubuntu ubuntu OpenSuse 192.168.0.190 opensuse opensuse TP RL / II2-ENSI Page :1 

Sous Linux, utiliser la commande ifconfig 

  1. Pour connaître les interfaces réseaux disponibles et toutes les informations associées. Privilège (U ou S) : U Commande tapée sur la machine OpenSuse : /sbin/ifconfig -a 
  2. Proposer une classification (résumé) des informations ainsi obtenues. 

eth0 le réseau dont la machine est connectée Link encap: Ethernet : l’interface est Ethernet HWaddr … : l’adresse MAC de la machine unique a chaque carte ethernet . inet addr : adresse IP de la machine Open SUSE Bcast : l’adresse brodcast. Mask : le masque du reseau BROADCAST : la machine supporte le broadcast RUNNING : l’interface est prête pour accepter des données. MULTICAST : l’interface Ethernet supporte le multicasting MTU (Maximum Transmission Unit) c’est la taille de chaque paquet reçu par la carte Ethernet. Metric : prend des valeurs entieres qui définissent la priorité de la machine (ce la n’a un sens que lors du routage des paquets) RX Packets : paquets reçus TX Packets : paquets transmis collision : nombre de collisions 

  1. pour configurer l’adresse IP de chaque machine Linux Privilège (U ou S) : S Commande tapée sur la machine OpenSuse : ifconfig eth6 192.168.0.190 
  2. pour visualiser les nouveaux paramètres de configuration (de l’interface configurée uniquement). Privilège (U ou S) : U Commande tapée sur la machine OpenSuse : /sbin/ifconfig -a Sous Windows, 
  3. utiliser la commande ipconfig pour connaître les interfaces réseaux disponibles et toutes les informations associées. 

Privilège (U ou S) : U Commande tapée sur la machine: 

ipconfig 

  1. utiliser « Centre réseau et partage » ou « Panneau de configuration » pour configurer l’adresse IP de la machine Windows7. Privilège (U ou S) : U Enchainement des fenêtres/boutons : 

Fenêtres Boutons Centre réseau et partage Gérer les connexions réseaux Connexions réseau Bouton droit souris -> propriétés Protocol internet version 4 propriétés 

Commandes utiles pour le suivi du fonctionnement 

2) En plus de certaines des commandes déjà utilisées, il existe d’autres commandes et des utilitaires couramment utilisés pour le suivi du fonctionnement du réseau et le diagnostic de certains dysfonctionnements pouvant affecter le réseau. Nous retrouvons dans les différents systèmes étudiés les commandes ping, arp et netstat. Il est aussi possible d’installer un analyseur réseau tel que Wireshark. L’objectif est d’apprendre à donner une interprétation à différentes réponses possibles aux commandes ping, arp et netstat et à utiliser un analyseur réseau. a. Avant tout appel à la commande ping, grâce à la commande arp, visualiser le contenu de la table ARP (sur une quelconque des machines Linux). Quel est le résultat obtenu ? 

Table vide 

  1. Qu’en est-il pour la machine Windows ? Quel est la nature des entrées qui existent ? 

Contient quelque adresses qui sont des adresses statiques. 

TP RL / II2-ENSI Page :2 

  1. Lancer sous Wireshark une nouvelle capture. Utiliser la commande ping pour vérifier que la machine OpenSuse peut joindre la machine Fedora. Réutiliser la commande arp pour visualiser le contenu de la table ARP sur ces deux machines. Grâce à Wireshark, identifier les messages échangés. Que peut-on conclure. Fedora ARP 192.168.0.190 ether 00:0c:29c:e6:90:fd c eth0 Open SUSE ARP 192.168.0.1 ether 00:0c:29:65:c7:c5 c eth6 Wireshark: Broadcast ARP how has ARP is at ICMP request ICMP reply On peut conclure que si une station tente pour la première fois de joindre une autre alors le premiers message émis et un message en broadcast (ARP how has) pour localiser le destinataire. Destinataire localisé, la station commence a émettre. d. Arrêter toute commande ping, sur la machine OpenSuse, vérifier qu’une entrée correspondante à la machine 

Fedora figure dans la table ARP. Lancer une nouvelle capture sur Wireshark. Utiliser à nouveau la commande ping pour vérifier que la machine OpenSuse peut joindre la machine Fedora. Grâce à Wireshark, identifier les 2 premiers messages échangés. Que peut-on conclure. Le résultat de wireshark : 192.168.0.190 192.168.0.1 ICMP ping request 192.168.0.1 192.168.0.190 ICMP ping reply Donc on peut remarquer l’absence du message de l’identification du destinataire, maintenant une connexion est présente entre les deux stations. e. Arrêter toute commande ping, relancer une nouvelle capture sur Wireshark et grâce à la commande ifconfig, désactiver l’interface réseau de Fedora, puis effectuer le test d’accessibilité à Fedora à partir de Ubuntu. Dans cette question nous supposons que la table ARP de Ubuntu ne contient pas de correspondance MAC-IP relative à la machine Fedora (sinon l’effacer grâce à arp –d). Privilège (U ou S) : S Commandes de désactivation de l’interface réseau sur Fedora : 

ifconfig eth10 down f. Quel est le message retourné par la commande ping

Résultat de la commande Ping à partir Ubuntu lorsque la table ARP sur Ubuntu ne contient pas la correspondance entre l’adresse IP et l’adresse MAC de Fedora : Destination host unreachable 

  1. Arrêter toute commande ping, relancer une nouvelle capture sur Wireshark et grâce à la commande ifconfig, réactiver l’interface réseau de Fedora, puis effectuer le test d’accessibilité à Fedora à partir de Ubuntu, ne pas arrêter ce test. Pendant le test, désactiver l’interface de Fedora. Notons que la table ARP de Ubuntu contient la correspondance MAC-IP relative à la machine Fedora. Quel est le résultat retourné par la commande ping ? Détailler votre réponse en se référant aux messages capturés par Wireshark. Pas de message de type ICMP, donc la machine Fedora n’est plus accessible. 
  2. Donner une interprétation aux résultats des deux questions précédentes (2.f et 2.g). TP RL / II2-ENSI Page :3 

2.f le résultat retourner par la commande ping implique que la machine Fedora n’est pas connectée au réseau alors que la machine ubuntu est bien connecté au réseau 

  1. En gardant l’interface réseau de Fedora désactivée, quel est le résultat de la commande ping exécutée sur Fedora pour tester l’accessibilité de Ubuntu. Est-ce que cette commande a engendré l’envoi d’un message ICMP ? Expliquer. Résultat de la commande Ping à partir Fedora : Network unreachable Elle n’engendre pas l’envois d’un message ICMP Explication : Ce message signifie que la machine Fedora n’est pas connectée au réseau . 
  2. Quelles sont les informations relatives au trafic réseau fournies par la commande netstat. Préciser les options utilisées pour obtenir ces informations (sous Windows et Linux). 

Sous Window Netstat Protocol adresse Local + port adresse destination Etat Sous Linux Netstat –a Protocol Received Sent local address foreign address state 

Subdivision en sous-réseaux 3) Le masque réseau : 255.255.255.192 est utilisé sur les 4 machines. 

  1. Configurer en conséquence les différentes interfaces réseaux. Privilège (U ou S) : S Commande tapée sur la machine OpenSuse : ifconfig eth6 192.168.0.190 netmask 255.255.255.128 
  2. Quel est le résultat des commandes exécutées sur OpenSuse : ping 192.168.0.129 et ping 192.168.0.65 ? Expliquer. La première commande ping est réussie car les deux stations sont dans le même sous-réseau La deuxième commande ping ne passe pas car les deux stations appartiennent à deux sous-réseaux séparés. 
  3. Sous VMware, créer 3 réseaux VMnet correspondant aux 3 sous-réseaux (192.168.0.0, 192.168.0.64, 

192.168.0.128). Sur Windows, configurer une seconde interface ayant l’adresse 192.168.0.62 et sur Ubuntu, configurer aussi une seconde interface ayant l’adresse 192.168.0.126. En fonction de l’adresse de chaque interface et sous VMware, vous devez vous assurer que chaque interface est bien connectée au réseau VMnet approprié. A cet effet et avant de procéder à ces opérations de configuration, décrire à travers une figure appropriée le plan d’adressage de tout le réseau en précisant le VMnet associé à chaque sous réseau. 

TP RL / II2-ENSI Page :4 

  1. Quel est le résultat des commandes suivantes exécutées sur OpenSuse ? Expliquer. ping 192.168.0.62 : destination host unreachable ping 192.168.0.126 : réussie Explications : Les deux machines open suse et windows 1 (adresse ip 192.168.0.62) n’appartiennent pas au même sous-réseau. Alors que open suse et ubuntu 2 (192.168.0.129) appartiennent au même sous-réseau. 

Routage statique 

4) Dans cette question on s’intéresse à la configuration du routage statique à travers la saisie des routes appropriées. a. Grâce à la commande route, consulter la table de routage de chacune des machines. Privilège (U ou S) : U Commande tapée sur la machine Windows : Route PRINT Privilège (U ou S) : S Commande tapée sur la machine OpenSuse : …route…………………………………….. 

  1. Grâce à la commande route, rajouter les routes nécessaires pour que toute machine puisse joindre tout autre machine. Privilège (U ou S) :U Commande(s) tapée(s) sur la machine Windows : ……route ADD 192.168.0.128 mask 255.255.255.192 192.168.0.126 ……………………………………………….. Privilège (U ou S) : S Commande(s) tapée(s) sur la machine Fedora : …route add –net 192.168.0.64 netmask 255.255.255.192 gw 192.168.0.62………………… … route add –net 192.168.0.128 netmask 255.255.255.192 gw 192.168.0.62…………… Privilège (U ou S) : S. Commande(s) tapée(s) sur la machine Ubuntu : ……route add –net 192.168.0.0 netmask 255.255.255.192 gw 192.168.0.65…………………………………. Privilège (U ou S) : S Commande(s) tapée(s) sur la machine OpenSuse : ……route add –net 192.168.0.0 netmask 255.255.255.192 gw 192.168.0.129…………………… …… route add –net 192.168.0.64 netmask 255.255.255.192 gw 192.168.0.129………………………. 

Même avec les routes rajoutées, certains tests d’accessibilité échouent car les machines Windows et Ubuntu ne réalisent pas la redirection (Forwarding) des paquets IP d’un sous-réseau à un autre. Nous allons donc devoir l’activer sur ces deux machines. 

  1. Sur la machine Windows, grâce à la commande regedit mettre à 1 le registre IPEnableRouter (puis redémarrer la machine, suspendre les machines virtuelles pour pouvoir revenir sur le même état après le redémarrage de la machine Windows). Pour un système Windows Server, il est aussi possible d’utiliser sous <Démarrer>/<Outils d’administration>/<Gestionnaire de serveur> pour la configuration d’un routeur (le redémarrage n’est plus alors nécessaire). 

TP RL / II2-ENSI Page :5 

  1. Sur la machine Ubuntu, echo « 1 » > /proc/sys/net/ipv4/ip_forward e. Sur Fedora, en utilisant Wireshark, lancer une capture de trames puis tester l’accessibilité de OpenSuse. A quelle interface correspond l’adresse MAC destination de la trame transportant le message icmp-echo ? ……………00 :ef :ac :00 :c7 :c5………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 
  2. Sur la machine Fedora, taper la commande : 

traceroute 192.168.0.190 Reporter le résultat de la commande. A quoi sert cette commande (remarque : l’équivalent de cette commande sous MS Window est tracert). ……1 192.168.0.62 (192.168.0.62) 1.725 ms 0.163 ms 0.092 ms ……………………………… ……2 192.168.0.62 2761.722 ms 2996.009 ms …………………………… ……traceroute nous permet de suivre le chemin qu’un paquet de données va prendre pour aller d’une machine a une autre……………………………………………………………………………………………………………………………………………… 

Principaux fichiers de configuration réseau 

5) Sous Linux, le paramétrage effectué grâce aux commandes ifconfig et route est systématiquement perdu du moment où la machine est éteinte. La valeur de ip_forward elle aussi revient à zéro. Il en est de même, sous MS- Windows pour les routes saisies par la commande route. Par ailleurs il est utile de pouvoir désigner les machines par des noms plutôt que des adresses. La question suivante a pour objectif de rendre effectif un paramétrage donné lors du redémarrage du service réseau ou de la machine. 

TP RL / II2-ENSI Page :6 

  1. Sur la machine Windows, écrire un fichier .bat pour l’ajout des routes nécessaires. Le fichier doit être lancé au démarrage de la machine. Contenu du fichier .bat et Enchainement des fenêtres/boutons : ……………………………………………………………………………………………………………………………………………………………………………………… 

…………………………………………………………………………………………………………………………………………………. ………………………………….. …………………………………………………………………………………………………………………………………………………………….. ………………………. 

…………………………………………………………………………………………………………………………………………………………….. ………………………. 

…………………………………………………………………………………………………………………………………………………………….. ………………………. 

…………………………………………………………………………………………………………………………………………………………….. ………………………. …………………………………………………………………………………………………………………………………………………………………………….. ………. 

  1. Sur chacune des machines Linux, consulter les fichiers : 

Fichier activation routage : /etc/sysctl.conf Positionner net.ipv4.ip_forward à 1 Fichier script de démarrage réseau (Fedora) :/etc/init.d/network……………………………………………………………….. Fichier script de démarrage réseau (Ubuntu) : /etc/init.d/networking…………………………………………………………. Fichier script de démarrage réseau (OpenSuse) : /etc/init.d/network…………………………………………………………. 

Pour le paramétrage des interfaces il existe un premier outil (traditionnel) d’installation ifup et un second outil NetworkManager qui permet plus facilement de gérer différents types de connexion ( par exemple wifi). Nous allons utiliser le premier outil. Au cas où vous désirez utiliser le second pour une interface donnée, il suffit de ne pas paramétrer cette interface avec les fichiers traditionnelles et la paramétrer par le fichier /etc/NetworkManger/system- connections/eth<x>. 

  1. Mettre-à-jour les fichiers de configuration suivants, qui maintiennent le paramétrage des interfaces réseau : 

Fichier configuration d’une interface <x> (Fedora) : /etc/sysconfig/network-scripts/ifcfg- eth<x> (cf. ifcfg-lo pour se familiariser avec la syntaxe) : ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… Fichier configuration d’une interface (Ubuntu) : /etc/network/interfaces 

(cf. l’exemple en commentaire pour se familiariser avec la syntaxe la syntaxe) : ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Fichier configuration d’une interface <x> (OpenSuse) : /etc/sysconfig/network/ifcfg- eth<x> (inutile de reporter les modifications) 

  1. Mettre-à-jour le fichier qui maintient les routes statiques. 

Fichier de routage (Fedora) : /etc/sysconfig/static-routes 

(cf. l’exemple en commentaire pour se familiariser avec la syntaxe la syntaxe) : ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

TP RL / II2-ENSI Page :7 

Fichier de routage (Ubuntu) : /etc/network/interfaces (cf. l’exemple en commentaire pour se familiariser avec la syntaxe la syntaxe) : ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… Fichier de routage (OpenSuse) : /etc/sysconfig/network/routes (cf. l’exemple en commentaire pour se familiariser avec la syntaxe la syntaxe) : ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

  1. Quel est l’utilité du fichier /etc/hosts (sous Windows il existe un fichier équivalent : \windows\system32\drivers\etc) ? ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Routage Dynamique 

6) Supprimer toutes les routes saisies dans la section « routage statique » et invalider la redirection de paquet IP effectuée dans cette même section. Nous supposons que les interfaces sont déjà configurées suivant le dernier plan d’adressage (masque réseau 255.255.255.192). Aux sous-réseaux et aux interfaces déjà créés, nous allons rajouter un sous-réseau et deux autres interfaces pour créer un cycle dans le réseau : sur Fedora rajouter une interface Ethernet ayant l’adresse 192.168.0.193 et sur OpenSuse rajouter une interface Ethernet ayant l’adresse 192.168.0.254. 

Les protocoles de routage interne dynamique RIP et OSPF seront étudiés au second semestre (dans le cadre du cours « Réseaux Informatiques »). Des manipulations plus étendues sont prévues dans le cadre de ce cours. 

  1. Sur la machine Windows (version Server), utiliser l’outil « Routage et accès distant » ou « Gestionnaire de 

serveur » pour configurer la machine entant que routeur RIP. 

Sur une station de travail (version non serveur) il est aussi possible de lancer un écouteur RIP 

TP RL / II2-ENSI Page :8 

Pour les besoins du routage dynamique et sur les machines Linux, nous allons utiliser le logiciel Quagga dont le langage de commande est très proche de celui de IOS de Cisco avec quelques légères différences. Contrairement à l’IOS qui intègre toutes les fonctionnalités de façon monolithique, Quagga fait appel à plusieurs démons (programmes) qui doivent être lancées en tâche de fond : Zebra est le programme de gestion des interfaces, ripd, ospfd, ripngd, ospf6d, bgpd sont des démons (un par protocole) de routage. L’administrateur système peut se connecter sur l’un de ces démons par telnet en local (127.0.0.1) en précisant un numéro de port défini pour chacun de ces programmes. Afin de configurer le routage RIP, sur une machine Linux, effectuer les manipulations suivantes : 

  1. Associer un nom aux routeurs Linux (Ubuntu/Fedora/OpenSuse) et des mots de passe. A cet effet, vérifier que le le fichier /etc/quagga/zebra.conf contient les lignes suivantes, sinon le créer (dans le cas du routeur Ubuntu). hostname Ubuntu 

password zebra enable password zebra Lancer ou relancer le service zebra sudo service zebra restart (sur Fedora et OpenSuse) et sudo service quagga restart (sur Ubuntu) se connecter et visualiser les informations relatives aux interfaces et à la table de routage. telnet 127.0.0.1 2601 (2601:port zebra) enable 

show interfaces show interface <nom_interface> show ip route c. Sur le routeur Ubuntu, éditer le fichier /etc/quagga/ripd.conf: 

hostname Ubuntu password <mot_de_passe> Se connecter et configurer le routage RIP. telnet 127.0.0.1 2602 (2602:port ripd) … enable 

configure terminal router rip version 2 network 192.168.0.64/26 network 192.168.0.128/26 end Pour sauvegarder de façon permanente la configuration, vous pouvez utiliser la commande : copy running-config startup-config d. Reprendre ces différentes opérations sur les routeurs Fedora et OpenSuse. Alors que sur Ubuntu, ripd est lancé en lançant quagga, sur Fedora et sur OpenSuse, il faut préalablement lancer ripd : sudo service ripd start 

visualiser les tables de routage des différentes machines et vérifier qu’elles contiennent toutes les routes possibles. e. Afin d’observer les changements dynamiques de routes, désactiver sur Ubuntu l’interface 192.168.0.129. Quelles sont les changements ayant eu lieu dans les différentes tables de routage. 

TP RL / II2-ENSI Page :9 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… Réactiver l’interface 192.168.0.129. 7) Dans cette question nous allons configurer le routage OSPF sur les routeurs OpenSuse et Fedora. Nous allons garder le routage RIP sur Fedora, Ubuntu et sur la machine Windows. Les routes RIP seront redistribuées à travers l’OSPF. a. Nous supposons que le fichier /etc/quagga/zebra.conf est déjà créé. Sur les routeurs OpenSuse et Fedora, éditer le fichier /etc/quagga/ospfd.conf (idem que pour la configuration du rip). Se connecter au routeur ospf telnet 127.0.0.1 2604 (2604:port ospfd) 

Passer en mode configuration et configurer le routage OSPF. enable 

configure terminal router ospf network 192.168.0.64/26 area 0 network 192.168.0.128/26 area 0 end b. En étant connecté au routeur zebra sur OpenSuse, visualiser les routes. Quels sont les sous-réseaux qui ne sont plus accessibles. 

……………………………………………………………………………………………………………………………………………………………………………………… 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

  1. Afin de remédier à cette situation nous allons redistribuer les routes. Sur le routeur Fedora redistribuer les routes RIP à travers OSPF : 

enable configure terminal router ospf redistribute rip metric 20 d. Visualiser la table de routage de OpenSuse des différents routeurs. Quel est le résultat obtenu ? ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

TP RL / II2-ENSI Page :10 

TP – Partage d’une connexion en utilisant SQUID & IPTABLES 

Objectifs : SQUID est un proxy (mandataire) capable de réaliser : 

– la translation d’adresses permettant l’utilisation d’une seule adresse routable, – l’optimisation de la bande passante en utilisant un mécanisme de cache (notamment utile lorsque les utilisateurs accèdent aux mêmes objets statiques), – le contrôle et le filtrage de l’accès, particulièrement, l’authentification qui n’est pas possible avec IPTABLES. IPTABLES est un firewall logiciel capable de réaliser les fonctions de translation d’adresses et de filtrage, mais aussi, il permet la modification de champs dans les entêtes TCP/IP. Grâce à IPTABLES, il est possible de réaliser la translation d’adresses indépendamment des protocoles applicatifs (contrairement à SQUID qui se limite à des protocoles bien déterminés comme HTTP ou FTP). Grâce Il est aussi possible de réaliser la translation d’adresse sur l’adresse source mais aussi sur l’adresse destination (ce qui n’est pas le cas avec SQUID). IPTABLES et SQUID peuvent être utilisés conjointement pour mettre en place un serveur proxy transparent. Sans chercher à couvrir toutes les possibilités qu’offrent ces deux outils, à travers un certain nombre de manipulations, nous allons nous familiariser avec ces deux outils et apprendre à utiliser et mettre en place certaines configurations usuelles : 

– mise en place d’un serveur proxy SQUID pour le partage d’une connexion à l’Internet, – configuration du cache SQUID, – authentification et filtrage avec SQUID, – consultation des fichiers logs et – utilisation d’IPTABLES pour rendre un proxy transparent, pour améliorer les possibilités de filtrage et pour permettre l’accès à partir de l’internet à un serveur ayant une adresse privée. 

Barème : 2.5 par question. 

Environnement matériel et logiciels Quatre machines dont trois virtuelles, en réseau, sont installées sur un même ordinateur de travail (en utilisant VMware) : trois machines Linux et une MS Windows Server. Ces machines sont les mêmes utilisées que pour le TP déploiement des réseaux IP avec les mêmes mots de passe. Il faut savoir que dans le cadre d’une exploitation réelle, la configuration matérielle de la machine (en termes notamment d’espace mémoire et d’espace disque), sur laquelle est déployé un serveur proxy SQUID influe considérablement sur les temps de réponses de ce serveur. Configurer les différentes machines comme le décrit la figure suivante (appliquer le masque par défaut) : 

– Squid1 devrait être la machine Fedora, Squid2 la machine OpenSuse et le client 192.168.1.2 la machine Ubuntu, – Paquetages SQUID et IPTABLES installés à la fois sur Squid1 et Squid2 – Serveur Web (IIS) installés à la fois sur 193.95.0.1 (Windows Server), – Le paquetage htpasswd pour la gestion des mots de passe, – Navigateur Web installé sur toutes les machines, – Serveur Telnet installé sur Fedora. Nous allons commencer par se familiariser avec certains fichiers et effectuer certaines vérifications. 

TP RL/ II2-ENSI Page :1 

1) Consulter le fichier /etc/squid/squid.conf 

Chercher dans ce fichier la directive cache_dir afin de déterminer l’emplacement du répertoire de cache, la taille du cache (en Mo), le nombre de répertoires et de sous répertoires. Il est possible de trouver cette directive plusieurs fois, la taille totale est alors la somme des différentes occurrences. Afin d’accélérer les temps de recherche, SQUID essaie de répartir les objets qu’il place dans le cache de manière uniforme dans plusieurs répertoires. Il utilise une fonction de répartition (fonction de « hash ») qui indique dans quel répertoire se trouve un objet. La recherche dans ce répertoire se fait donc plus rapidement, car les objets sont répartis de manière équilibrée dans tous les répertoires du cache, qui devraient donc être relativement peu « peuplés ». Il utilise un découpage à deux niveaux, les répertoires du deuxième niveau étant répartis dans les répertoires du premier niveau. 

SQUID est incapable de démarrer si les répertoires de caches ne sont pas créés. Grâce à la commande ls vérifier que ces répertoires sont bien créés. Il est possible aussi de les créer ou de les reconstruire (par exemple, à la suite d’un arrêt brutal de squid, le cache peut devenir « corrompu » et doit être reconstruit) en tapant : rm -rf /var/spool/squid/* // si déjà créés 

squid -z 

En ayant consulté squid.conf, préciser les informations suivantes : 

Chemin vers le répertoire de Swap : …/var/spool/squid… 

Taille du répertoire de Swap : ………………100 MO…………………………. Noms des répertoires : ……00…01 …02 …03 jusqu’à …0F……………………………. Noms des sous-répertoires :………chaque répertoire contient des fichiers allant de 00 jusqu’à F6 …….. ………………………………………………………………………………………………………………………………………………………………………………. 

Déterminer si SQUID est déjà lancé en utilisant l’une des commandes suivantes : Fedora# ps aux | grep [s]quid ou Fedora# /etc/init.d/squid status 

Une première configuration simple 

2) Nous allons permettre à toutes les machines du réseau 192.168.0.0 d’accéder à l’internet (représenté par le serveur Web 193.95.0.1) via Squid1. A cet effet et dans le fichier squid.conf, reproduire les définitions suivantes : 

############################## # SERVEUR PROXY CACHE – Squid1 ############################## 

# Port du proxy 

http_port 192.168.0.2:8080 

# # Paramétrage du cache 

cache_dir ufs /var/spool/squid 100 16 256 cache_log /var/log/squid/cache.log 

# Taille mémoire vive utilisée pour cache, augmenter si trop de messages Warning #“Exceeded cache_mem…” cache_mem 16 MB 

# régler cache_mem_low et cache_mem_high qui sont les valeurs limites de remplissage du # cache mémoire. Par défaut les valeurs sont 75 % et 90 %. A 90 % le cache se vide # jusqu’à 75 %. 

# Taille maximale des objets stockés dans le cache maximum_object_size 4 MB 

TP RL/ II2-ENSI Page :2 

# Taille minimale des objets stockés dans le cache minimum_object_size 0 KB 

# # Messages d’erreurs du proxy en français (pas forcement nécessaire), vérifier que le # répertoire existe et le consulter. error_directory /usr/share/squid/errors/fr 

# # Nom visible dans les messages d’erreurs visible_hostname Squid1 

# Déclaration des ACL (Access Control List) acl localhost src 127.0.0.1/32 

acl reseau1 src 192.168.0.0/24 acl all src all #Internet 

# # Protocoles d’accès au cache et ports (ne pas définir les ports à interdire # # et à autoriser présenterait une faille de sécurité) acl manager proto cache_object 

acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports … # # Autorisation d’accès 

# Accès au manager à partir de localhost seulement http_access allow manager localhost 

http_access deny manager 

# Interdiction des ports douteux http_access deny !Safe_ports 

# # Autorisation d’accès direct aux services du proxy http_access allow localhost 

http_access allow reseau1 http_access deny all 

Des règles multiples de http_access sont comparées par des OU, elles sont traitées dans l’ordre d’écriture et se terminent dès qu’une correspondance est établie. Tous les éléments d’une même entrée d’accès sont associés par un ET. 

Lancer Wireshark sur Fedora. Démarrer/redémarrer SQUID : 

/etc/init.d/squid restart 

A partir de OpenSuse (Squid2 considéré en tant que client) et travers le navigateur tenter d’accéder à l’URL : http://193.95.0.1/. Que faut-il réaliser comme paramétrage pour que l’accès puisse se réaliser ? ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Remarque importante : dans tous le TP ne pas accéder à des pages HTML (inutilement) tant que ceci n’a pas été demandé. Cette recommandation est importante pour garder la mémoire cache à un état bien déterminé et pouvoir ainsi obtenir les résultats escomptés. 

Après avoir réalisé un premier accès à travers le navigateur (à partir de OpenSuse), décrire les messages échangés entre la machine cliente et le serveur Squid1 d’une part et entre le serveur Squid1 et le serveur Web d’autre part. A cet effet TP RL/ II2-ENSI Page :3 

compléter Arrêter la capture la figure de ci-dessus. trame. 

Il n’est pas demandé de représenter les messages de fermeture de connexions TCP. 60170 8080 

http ://193.95.0.1/HTTP/1.1 

54448 SYN http80 

SYN Ack Ack 

GET http/1.1 

http OK 

TCP [Ack] 

http FIN TCP [ Fin , Ack] 

Authentification 

Dans pour authentifier cette question les nous utilisateurs nous intéressons d’un proxy à SQUID. la fonction Elles d’authentification. font appel à l’un Il des existe programmes plusieurs suivants méthodes

disponibles – ldap_auth : se base sur le protocole Linux Lightweight Directory Access – ncsa_auth : utilise un fichier de noms d’utilisateur et de mots de passe de style NCSA – smb_auth : utilise un serveur SMB comme SAMBA ou Windows NT – msnt_auth : utilise l’authentification de domaine Windows NT – PAM : utilise les modules Linux « Pluggable Authentication Modules » – getpwam : utilise le fichier passwd de Linux. 4) Dans ce qui suit nous allons utiliser ncsa_auth. 

Créer un fichier password 

touch /etc/squid/passwd 

Ajouter un utilisateur grâce à htpasswd: 

htpasswd -b /etc/squid/passwd <nom> <mot de passe> 

Dans le fichier squid.conf, au lieu de http_access allow reseau1 

Utiliser les directives suivantes : 

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd acl pass proxy_auth REQUIRED 

http_access allow pass reseau1 

TP RL/ II2-ENSI Page :4 

Valider le bon fonctionnement de cette règle. 

Autres règles de filtrage (question bonus) 

Afin de limiter le nombre de connexions différentes qu’un utilisateur peut effectue, rajouter dans /etc/squid/squid.conf 

# Nombre maximal de sessions simultanées à partir de différentes adresses IP à 1 (pour # un même utilisateur)« -s » pour un fonctionnement strict (sinon aléatoire) acl maxauth max_user_ip -s 1 

# Nombre de connexion simultanés limité à 5 acl numconn maxconn 5 # duree de validite de l’authentification authenticate_ttl 30 minute 

# Règles d’accès http_access deny maxauth http_access deny reseau1 numconn http_access allow pass reseau1 Valider le bon fonctionnement de ce paramétrage. Décrire les tests effectués. 

Autres restrictions typiques : # ACL pour une restriction journalière/horaire : # M:Monday T:Tuesday W:Wednesday H:Thursday F:Friday A:Saturday S:Sunday acl semaine time MTWHF 08:30-17h30 

# ACL de restrictions par mot passant dans l’url (utilisation d’un fichier contant les # mots interdits)) 

acl mots_interdits urlpath_regex « /etc/squid/mots_interdits » 

# ACL de restrictions par url (utilisation d’un fichier contenant les URLs interdites) acl urls_interdites url_regex « /etc/squid/url_interdites » 

# # Application, par le refus, de ces ACLs http_access deny !semaine 

http_access deny mot_interdit http_access deny urls_interdites 

Tester le bon fonctionnement de ces règles et donner une autre alternative à la règle qui permet la restriction journalière/horaire avec authentification et uniquement à partir du réseau1 en utilisant « allow » et non « deny ». Tester le bon fonctionnement de cette règle. 

Proxy transparent 

Dans cette question nous cherchons à mettre en place un proxy transparent. Suivant ce mode de fonctionnement, l’authentification n’est plus possible. Seul HTTP (port 80) est supporté en mode transparent. Grâce à un tel mode, il n’est plus nécessaire de paramétrer les navigateurs avec l’adresse IP/port du proxy. 4) Le proxy est supposé être installé sur la machine qui joue le rôle de la passerelle par défaut. Sur Squid1 : 

– activer le routage : 

echo « 1 » > /proc/sys/net/ipv4/ip_forward Grâce à IPTABLES, rediriger le port 80 vers le port de SQUID (8080) 

iptables -t nat -I PREROUTING -p TCP –dport 80 -j REDIRECT –to-port 8080 – Reste à résoudre le problème suivant : le client envoie une requête HTTP directe à un serveur httpd et non à un proxy. Les méthodes utilisées ne sont pas les mêmes. Afin que le proxy fonctionne de façon transparente, il faut rajouter au niveau de la directive http_port le terme « transparent »: 

##Port du proxy 

http_port 192.168.0.2:8080 transparent 

Décrire le reste des opérations à réaliser pour le test du fonctionnement du proxy transparent et réaliser ce test. 

TP RL/ II2-ENSI Page :5 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Hiérarchie de caches et liaison inter-cache La fonction cache permet d’éviter de ramener un document plusieurs fois. 

Un document est généralement stocké dans le cache en fonction (particulièrement) de : une date d’expiration (en-tête HTTP expire), 

une durée de vie estimée à partir des dates de dernière modification (en-tête HTTP Last- Modified), la fréquence d’utilisation du document (LFU : « Least Frequently Used »), 

un rapport entre un paramètre coût (le temps de réponse du serveur d’origine) et la taille du document, les documents ayant le plus petit rapport sont supprimés d’abord (GDS : « Greedy Dual Size »). Les documents dynamiques ne doivent jamais être cachés (CGI, PHP,..). Lorsqu’un document est supprimé tous les documents aussi récents ou moins récents sont supprimés. 

Afin d’augmenter les performances des proxy-caches, une coopération entre caches peut-être configurée. Les caches SQUID peuvent être organisés suivant une hiérarchie de caches. Exemple : 

On distingue particulièrement 2 types de relations de parenté : les relations hiérarchiques « parent » où un parent (considéré comme père) répond à son fils s’il possède le document, sinon, il cherche le document et le délivre au fils; les mises à jour s’effectuent en cascade : un père est un point de concentration. les relations transversales « sibling », dans ce cas, si le document n’est pas dans le cache du parent (considéré comme frère) la requête n’est pas relayée, le cache origine de la requête doit lui-même chercher l’objet. Cette relation est particulièrement intéressante dans le cas où les frères sont proches. Le taux de succès des accès au cache risquent d’être très aléatoires. Ces relations de parenté devraient être instaurées entre caches en cas d’homogénéité de communauté (réseau de caches thématiques). Les endroits dans le réseau (où devraient figurer les caches) et le dimensionnement des caches sont des éléments de configuration qui font partie des problèmes à traiter dans la mise en œuvre d’une hiérarchie de caches. 

5) Nous allons commencer par configurer Squid1 entant que cache père et Squid2 en tant que cache fils. Pour simplifier la manipulation, préparer les fichiers squid.conf (de Squid1 et Squid2) de façon à réduire les contrôles d’accès (pas d’authentification …). 

Remarque : la version de Squid sur Squid2 est différente de celle de Squid1, les mêmes directives déjà étudiées existent, les paramètres par défaut sont différents. Sans devoir réécrire le fichier squid.conf sur Squid2 modifier le fichier existant en agissant sur les directives appropriées. 

Dans le fichier squid.conf de Squid2, taper la directive suivante (le port utilisé par le protocole inter-cache ICP, directive icp_port, est supposé être configuré à 3010) : 

TP RL/ II2-ENSI Page :6 

cache_peer 192.168.1.1 parent 8080 3130 

Sur Squid1 et dans le fichier squid.conf activer le port 3130 icp_port 3130 

Vider le cache de Squid1 et Squid2 (grâce à la commande de reconstruction, cf. plus haut). Effectuer une requête d’accès depuis Ubuntu à l’URL http://193.95.0.1/lien1. Consulter le fichier access.log de Squid2 et de Squid1. Reproduire les lignes traduisant les différents événements conséquents à l’accès à la page. ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

……………………………………………………………………………………………………………………………………………………………………………………… 

A partir d’un navigateur sur OpenSuse accéder à l’URL http://193.95.0.1/lien1. Consulter le fichier access.log de Squid1. Reproduire les lignes traduisant les différents événements conséquents à l’accès à la page. 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Nous allons maintenant configurer Squid2 entant que cache frère de Squid1. Garder le cache de Squid1 non vide. Ensuite, dans le fichier squid.conf de Squid2, taper la directive suivante : 

cache_peer 192.168.1.1 sibling 8080 3010 

A partir d’un navigateur sur Ubuntu accéder à l’URL http://193.95.0.1/lien1 et ensuite à l’URL http://193.95.0.1/lien2. Décrire le résultat obtenu pour chacun de ces accès. Illustrer ces résultats. ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

IPTABLES : généralités Alors que SQUID est capable de réaliser la translation d’adresse et le contrôle d’accès au niveau applicatif, IPTABLES réalise ces fonctions aux niveaux réseaux et transport. Il est incapable d’exploiter pas les particularités des protocoles applicatifs. De plus, il ne met pas en œuvre un mécanisme de cache. Néanmoins, grâce à IPTABLES il est possible de réaliser la translation d’adresses sans être limité à des protocoles applicatifs bien déterminés (comme c’est le cas pour SQUID). En outre, en plus de la translation d’adresse qui s’effectue généralement du coté client, un autre type de translation d’adresse du coté serveur est aussi possible (sur lequel nous reviendrons dans la suite du TP). 

TP RL/ II2-ENSI Page :7 

Avant d’aborder les manipulations, il est nécessaire de connaître les notions de base régissant le fonctionnement de IPTABLES. La couche réseau Linux présente plusieurs points d’accès (en anglais hook). Netfilter (module système destiné au filtrage) dispose de fonctions de rappel (callback) sous la forme de suites d’instructions qui précisent les traitements à réaliser lorsqu’un événement survient. IPTABLES permet la configuration de Netfilter. La figure suivante précise les points d’accès existants. 

Il est ainsi possible d’agir avant (PREROUTING), durant (FORWARD) ou après le routage (POSTROUTING), il est aussi possible d’agir sur les paquets issus des processus locaux (OUTPUT) ou sur les paquets destinés à ces processus (INPUT). A ces points d’accès sont associées des chaines de traitements désignées par les termes précisés ci-avant. Ces chaines sont regroupées en 3 tables : FILITER pour le filtrage, NAT pour la translation d’adresses et MANGLES pour pouvoir modifier certains des entêtes TCP/IP. 

Une chaîne est une liste de règles. Si les conditions de la règle s’appliquent sur un paquet, la règle précise la cible (ACCEPT, DROP, REJECT, SNAT, DNAT, MASQUERADE, LOG un saut vers une chaîne utilisateur), sinon, la règle suivante de la chaîne est examinée. Le tableau suivant donne une description des différentes cibles prédéfinies. 

CIBLE DESCRIPTION 

ACCEPT un paquet envoyé vers cette cible sera accepté et pourra poursuivre son cheminement au travers des couches réseaux. 

DROP Cette cible permet de jeter des paquets 

REJECT Permet d’envoyer une réponse à l’émetteur pour lui signaler que son paquet a été refusé 

MASQUERADE Cible valable uniquement dans la chaîne POSTROUTING de la table NAT. Elle change l’adresse IP de l’émetteur par celle courante de la machine pour l’interface spécifiée. Cela permet de masquer des machines et de faire par exemple du partage de connexion 

SNAT Également valable pour la chaîne POSTROUTING de la table NAT seulement. Elle modifie aussi la valeur de l’adresse IP de l’émetteur en la remplaçant par la valeur fixe spécifiée. 

DNAT Valable uniquement pour les chaînes PREROUTING et OUTPUT de la table NAT. Elle modifie la valeur de l’adresse IP du destinataire en la remplaçant par la valeur fixe spécifiée 

LOG Demande au noyau d’enregistrer des informations sur le paquet courant. 

Arrêter Squid Sur OPenSuse et Fedora. 

TP RL/ II2-ENSI Page :8 

6) Nous sauvegarder, allons commencer les restaurer par et fixer présenter la politique quelques par défaut commandes : utiles pour visualiser les règles, les supprimer, les – Pour lister les règles courantes des chaines de la table FILTER, taper iptables –L 

– Pour vider les chaines, taper Iptables –F – Pour sauvegarder les règles courantes, taper : iptables-save > /etc/iptables-save – Pour restaurer iptables-restore les règles à partir du fichier < /etc/iptables-save /etc/iptables-save, taper : Vider les chaines, lister à nouveau les règles et vérifier que la politique par défaut pour les différentes chaines est ACCEPT (Policy ACCEPT) : politique permissive. Il est possible d’agir sur la politique par défaut (qui sera appliquée en dernier ressort si aucune règle ne s’applique) : 

iptables -P INPUT –j ACCEPT iptables -P OUTPUT –j ACCEPT iptables -P FORWARD –j ACCEPT Pour instaurer une politique restrictive il suffit de remplacer dans les lignes (ci-dessus) ACCEPT par DROP. 

IPTABLES : exemple de filtrage 

7) Activer tout autre le équipement routage sur

OpenSuse et mettre-à-jour les tables de routages pour que tout équipement puisse pinger sur echo « 1 » > /proc/sys/net/ipv4/ip_forward Nous voulons interdire qu’un équipement dans le réseau 192.168.1.0 puisse « pinguer » sur un équipement se trouvant dans le réseau 192.168.0.0. A cet effet et sur OpenSuse, saisir la règle suivante : 

iptables –A FORWARD –p icmp –icmp-type echo-request –s 192.168.1.0/24 –d 192.168.0.0/24 -j REJECT 

Vérifier qu’avant la saisie de la règle, le ping pouvait se faire et qu’après la saisie ceci n’est plus possible. Est-ce qu’il est possible de pinger à partir de Fedora sur l’adresse 192.168.1.2 ? Expliquer. 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

IPTABLES : Translation de l’adresse source 

SQUID n’effectue pas la translation des adresses sources pour permettre aux stations locales de « pinguer » sur l’extérieur (trafic ICMP). Ce même problème se pose pour d’autres trafics tels que POP ou SMTP. Dans ce qui suit, nous allons utiliser IPTABLES pour permettre aux stations dans les réseaux 192.168.0.0 de « pinguer » sur des machines externes (193.95.0.1). Rajouter sur OpenSuse une route par défaut à travers 192.168.0.2. 

8) Sur le serveur Squid1 saisir la règle suivante : 

iptables –t nat –A POSTROUTING –s 192.168.0.0/24 –p icmp –icmp-type echo-request -j SNAT -–to-source 193.95.0.2 Expliquer à quoi correspond cette règle. 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

……………………………………………………………………………………………………………………………………………………………………………………… 

Visualiser les règles des chaines de la table NAT en tapant : iptables –L POSTROUTING –t nat 

Vérifier qu’il est possible de pinger à partir d’OpenSuse sur 193.95.0.1. 

TP RL/ II2-ENSI Page :9 

IPTABLES : translation de l’adresse destination 

Il est possible de permettre l’accès à une machine ayant une adresse privée à partir de l’extérieur (l’internet) en utilisant la translation le l’adresse destination (utile, par exemple, pour une caméra, munie d’un serveur Web, à domicile à laquelle on veut accéder à partir d’un quelconque endroit sur l’Internet). A cet effet nous allons réserver le port 2222 pour désigner la machine interne (la caméra avec son serveur Web) ayant comme adresse IP 192.168.1.2 (OpenSuse). Vérifier que le serveur Web est bien activé sur OpenSuse. 

9) Sur le serveur Fedora activer le routage. Sur OpenSuse, créer une route par défaut à travers 192.168.0.2. Saisir la règle suivante : 

iptables –t nat –A PREROUTING –s 0.0.0.0/0 –-protocol tcp -–dport 2222 -j DNAT –-to 192.168.0.1:80 

Expliquer à quoi correspond cette règle. A partir d’un navigateur sur Windows, accéder à l’URL 193.95.0.2 :2222 . 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

IPTABLES : « statefull Inspection » (question bonus) 

Dans ce qui suit nous cherchons à permettre aux utilisateurs du réseau 192.168.1.0 de pouvoir effectuer un telnet sur les machines qui se trouvent dans le réseau 192.168.0.0 sans que ces derniers ne puissent faire un telnet sur les machines du réseau 192.168.1.0. Vérifier que le telnet est bien activé sinon l’activer sur Fedora. Vérifier que le routage est bien activé sur OpenSuse. Créer les routes nécessaires pour permettre aux machines des réseaux 192.168.0.0 et 192.168.1.0 d’échanger des paquets. Vider toutes les règles iptables sur OpenSuse mais aussi Fedora et Ubuntu). 10) Sur OpenSuse, saisir les règles suivantes : Iptables –P FORWARD –j DROP iptables -A FORWARD -p TCP -s 192.168.1.0/24 -d 192.168.0.0/24 –dport 23 -j ACCEPT iptables -A FORWARD -p TCP -s 192.168.0.0/24 –sport 23 -d 192.168.1.0/24 -j ACCEPT Est-ce qu’il est possible d’effectuer à partir de 192.168.1.2 un ping sur 192.168.0.2 (Fedora). Est-ce qu’il est possible d’effectuer à partir de 192.168.1.2 un telnet sur 192.168.0.2 (Fedora). Quel est le problème qui se pose ? ……………………………………………………………………………………………………………………………………………………………………………………… 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… IPTABLES permet le suivi des «communications» en se basant sur les états suivants: 

NEW : premier paquet, – ESTABLISHED : réponse et suivants relatifs à une même communication, – RELATED : signifie que le paquet initie une nouvelle connexion, mais qu’il est associé avec une communication existante, comme un transfert de données FTP ou une erreur ICMP. – INVALID : signifie que le paquet n’est associé à aucune connexion connue Remplacer la dernière règle par (vider et re saisir) 

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT 

Quel est l’intérêt de cette règle ? 

……………………………………………………………………………………………………………………………………………………………………………………… 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

TP RL/ II2-ENSI Page :10 

TP – Déploiement des services DHCP et DNS 

Objectifs : – Déploiement du service DHCP. – Configuration d’un relai DHCP. – Déploiement du service DNS (primaire, secondaire et cache). – Configuration du service DDNS. – Test du fonctionnement de ces services. – Sous Linux et MS et Windows Server. 

Barème : 2.5 par question. 

Environnement matériel et logiciels 

– 4 machines dont 3 virtuelles, en réseau, installées sur un même ordinateur de travail (en utilisant VMware) : 3 machines Linux, une MS Windows Server (les mêmes que pour les TP précédents). – Configurer les différentes machines comme le décrit la figure suivante (appliquer le masque par défaut). 

– Paquetages BIND et DHCP et relais DHCP sur les machines Linux. – Paquetage relais DHCP sur Fedora. – Paquetage DNS et DHCP sur le serveur MS Windows. – Wireshark sur les différentes machines. 

DHCP : généralités 

DHCP (Dynamic Host Configuration Protocol) permet l’attribution automatiquement aux clients des paramètres réseaux (adresse IP, masque, passerelle par défaut, serveurs DNS, serveur et fichier de boot …). DHCP est dérivé du protocole BOOTP, les clients BOOTP sont aussi servis par un serveur DHCP. Pour des raisons de tolérance aux pannes et de performance, plusieurs serveurs DHCP peuvent être déployés de manière redondante. Un découpage de la plage d’adresses doit alors être effectué. La figure suivante décrit les messages échangés lors d’une acquisition de la configuration réseau entre un client et un serveur. 

TP RL/ II2-ENSI Page :1 

Configuration d’un serveur/client DHCP sous Linux 

1) Sur Ubuntu éditer le fichier /etc/dhcp3/dhcpd.conf ddns-update-style none; option domain-name « notrezone.com »; # log-facility local7 indique un fichier de log de niveau debug dans /var/log/syslog # Il est possible de créer un fichier à part en ajoutant dans #/etc/rsyslog.d/50-default.conf la ligne: # local7.* /var/log/dhcpd3.log # vérifier que ceci a été bien effectué sur Ubuntu log-facility local7; subnet 192.168.0.0 netmask 255.255.255.0 { 

# Passerelle par défaut option routers 192.168.0.2; # Masque de sous-réseau option subnet-mask 255.255.255.0; # Adresse de diffusion option broadcast-address 192.168.0.255; # Etendue de la plage DHCP range 192.168.0.150 192.168.0.200; #option domain-name-servers 192.168.0.1; # Durée du bail par défaut sans demande express du client default-lease-time 600; # Durée du plus long bail possible max-lease-time 7200; } Si le fichier dhcpd.leases n’est pas déjà créé alors effectuer (l’emplacement de ce fichier diffère selon les versions): touch /var/lib/dhcp3/dhcpd.leases 

Démarrer/Redémarrer le serveur dhcp (/etc/init.d/dhcp3-server start). 

Remarque : il est possible de lancer DHCP sur une seule interface précise en utilisant le binaire dhcpd3 et en lui fournissant le nom de l’interface en paramètre. Lancer Wireshark sur 192.168.0.1. 

Sur OpenSuse, acquérir une adresse grâce à la commande : #dhcpcd eth0 

Vérifier qu’une adresse a été bien obtenue. 

Pour qu’à chaque redémarrage, l’obtention d’une adresse devient systématique, il suffit de configurer le client DHCP : éditer (le créer si nécessaire) le fichier /etc/sysconfig/network/ifcfg-eth0 et modifier BOOTPROTO : 

STARTMODE=onboot BOOTPROTO= dhcp 

Redémarrer le service réseau. 

/etc/init.d/network restart 

Lancer une capture wireshark sur Fedora. 

Est-ce que le client DHCP a obtenu une adresse IP ? Grâce à Wireshark, préciser les adresses source et destination de chaque message DHCP. Dans chacun de ces messages, justifier le recours éventuel aux adresses 0.0.0.0 et 255.255.255.255. 

TP RL/ II2-ENSI Page :2 

Ip source Ip destination Message DHCP 0.0.0.0 255.255.255.255 DHCPDiscover 192.168.0.1 192.168.0.152 DHCPOffer 

0.0.0.0 255.255.255.255 DHCPRequest 192.168.0.1 192.168.0.152 DHCPAck Le client a eu recours aux adresse 0.0.0.0 et 255.255.255.255 parce que initialement il n’a pas d’adresse IP donc il utilise comme adresse propre l’adresse neutre 0.0.0.0 et puisqu’il ne connait pas l’adresse du serveur alors il envoi en diffusion les deux messages en utilisant l’adresse de diffusion 255.255.255.255. Consulter le fichier dhcp.leases. Quelles sont les informations qu’il maintient. 

le fichier dhcp.leases maintient l’adresse IP du client et la date du début et la date de la fin d’une session et des données du client. Lease 192.168.0.152 { Starts n date heure ; Ends n date heure ; Binding state active; Next binding state free; Hardware Ethernet 00:06:AA:E3:04:0B; Uid … Client-hostname “”; Hostname “”; }…………………………………………………………………………………………………………………………………………………. 

Déterminer l’adresse MAC de la machine cliente qui vient d’obtenir dynamiquement une adresse IP. Supposons que cette adresse est : 00:06:AA:E3:04:0B, sur la machine serveur DHCP, éditer dhcpd.conf et rajouter : host Ordi1 { 

hardware ethernet 00:06:AA:E3:04:0B; fixed-address 192.168.0.3; } 

Relancer le serveur DHCP et du coté client DHCP réacquérir une adresse. Vérifier que l’adresse est bien 192.168.0.3. 

Configuration d’un serveur/client DHCP sous MS Windows 

2) Sur la machine Windows Server, lancer le serveur DHCP (à rajouter en tant que rôle, grâce à « Démarrer>Outils d’administration>Gestionnaire de serveur » ). Suivre les différents onglets pour paramétrer le serveur DHCP. Fixer l’étendu à 192.168.1.150 – 192.168.1.200. Lors de l’installation du rôle de DHCP un premier paramétrage du serveur est sollicité. Il est possible par la suite de revenir sur la configuration et le paramétrage du serveur à travers l’outil de configuration de DHCP (sous « Démarrer>Outils d’administration>DHCP»). N.B. : la configuration du serveur DHCP nécessite l’installation et la configuration préalable du service « Active Directory » ce qui est déjà fait et la configuration des de l’interface réseau sur laquelle le serveur se met à l’écoute. 

TP RL/ II2-ENSI Page :3 

A Noter aussi qu’il est possible d’associer une adresse IP à une adresse MAC grâce à « Réservations ». Tester le fonctionnement du serveur en utilisant comme client la machine Fedora dont l’une de ses deux interfaces est au réseau 192.168.1.0. Sur cette machine utiliser la commande cliente pour acquérir une adresse IP : #dhclient eth<?> 

Configuration d’un relais DHCP sous Linux 

3) Dans cette question nous cherchons à ce que le serveur DHCP sur Windows puisse servir aussi le réseau 192.168.0.0. 

A cet effet, la machine Fedora entre les deux réseaux doit être configurée en tant que routeur. Ne pas oublier de fixer la route par défaut sur la machine Windows à l’adresse 192.168.1.2. 

Rajouter sur le serveur DHCP de la machine Windows, une nouvelle étendue 192.168.0.210-192.168.0.220 avec comme routeur par défaut pour cette étendue 192.168.0.2. Relancer ce serveur. 

Cependant les messages DHCP en diffusion ne traversent pas le routeur mis en place. De plus, le Serveur DHCP doit pouvoir déterminer le réseau auquel appartient le client pour lui allouer une adresse dans la plage appropriée. Pour ce faire, nous devons utiliser un agent de relais DHCP. 

Nous allons aussi utiliser la machine OpenSuse en tant que relai DHCP. Après avoir configuré convenablement le paramétrage de la machine 192.168.0.3, lancer l’agent relais DHCP en lui indiquant l’adresse du serveur : #dhcrelay3 192.168.1.1 -d 

-d : option debug Arrêter le serveur DHCP sur la machine Ubuntu, Cette machine sera utilisée en tant que client DHCP. 

Vérifier que le client Ubuntu a pu obtenir une adresse IP et en utilisant Wireshark, retrouver les différents messages échangés entre : le client, l’agent relais, le routeur et le serveur DHCP. Préciser le type (selon le protocole DHCP), l’adresse source et destination de chaque message. 

Source Destination Message Client BROADCAST 0.0.0.0 255.255.255.255 DHCP Discover Agent relai 192.168.0.3 192.168.0.2 DHCP Discover Routeur ->serveur 192.168.1.2 192.168.1.1 DHCP Discover Serveur -> routeur 192.168.1.1 192.168.1.2 DHCP Offer Routeur -> agent relai 192.168.0.2 192.168.0.3 DHCP Offer Agent relai -> client 192.168.0.3 192.1968.0.212 DHCP Offer Client BROADCAST 0.0.0.0 255.255.255.255 DHCP Request Agent relai -> routeur 192.168.0.3 192.168.0.2 DHCP Request Routeur -> serveur 192.168.1.2 192.168.1.1 DHCP Request Serveur -> routeur 192.168.1.1 192.168.1.2 DHCP Ack Routeur -> Agent relai 192.168.0.2 192.168.0.3 DHCP Ack Agent relai -> Client 192.168.0.3 192.168.0.212 DHCP Ack 

……………………………………………………………………………………………………………… TP RL/ II2-ENSI Page :4 

DNS : généralités Le DNS, «Domain Name System», permet d’établir la correspondance entre les noms de machines et leurs adresses IP. 

Le système met en œuvre une base de données distribuée au niveau mondial, gérée par l’interNIC et les organismes délégués : NIC (Network Information Center) … Au départ a été utilisé un fichier, appelé hosts, contenant de telles correspondances. Ce fichier existe toujours dans les différents systèmes d’exploitation (sous Unix : etc/hosts, sous MS- Windows : \windows\system32\drivers\etc\hosts), mais il est lourd à gérer à l’échelle de l’Internet. 

L’espace de nom est organisé sous forme arborescente. Un domaine est un sous arbre de l’espace de nommage. Une zone est une partie d’un domaine gérée par un serveur de nom. Le système DNS est basé sur la décentralisation de sa propre administration. Un serveur de nom, ayant autorité sur une zone, peut déléguer un sous-domaine d’une zone, ce sous-domaine ne fait plus alors partie de cette zone. Un serveur peut gérer plusieurs zones. 

Par ailleurs, un serveur DNS est capable de retourner un nom à partir d’une adresse IP. Il applique les mêmes principes que pour la résolution des noms. A cet effet, il utilise la sous-arborescence in-addr.arpa (voir figure ci- dessous). 

La résolution d’un nom peut se faire de manière récursive ou de manière itérative. Suivant le mode récursif, le serveur consulté prend à son tour le rôle de résolveur (client) et doit retourner soit une réponse valide soit un message d’erreur. Les requêtes envoyées par les clients sont en général récursives. Au niveau d’un serveur, si des redirecteurs ont été configurés et si le serveur est incapable d’effectuer la résolution de lui même, alors il envoie une requête récursive au premier de la liste des redirecteurs. Si le serveur n’a pas de redirecteurs, le mode utilisé est celui itératif. Le serveur consulté retourne alors soit la réponse, soit une références à un autre serveur « susceptible » de disposer de l’information demandée, soit enfin, un message d’erreur. 

Pour une même zone, il est utile d’avoir plus d’un serveur autoritaire (contre des problèmes de défaillance, de surcharge ou encore de sécurité), les données sont enregistrées sur un serveur dit primaire (master) et copiées vers d’autre(s) serveurs dit secondaires (slave). Un serveur peut être primaire pour des zones et secondaire pour d’autres. Un résolveur (client) ne voit pas la différence entre le primaire et le secondaire. Un serveur secondaire interroge périodiquement le serveur primaire et met à jour les données. Dans une requête itérative les serveurs « susceptibles » de disposer de l’information demandée sont retournés dans un ordre aléatoire (répartition de charge). 

Il est utile de prévoir un serveur cache (hint) pour accélérer les résolutions de noms. Il est souvent associé à la zone racine (non incluses les zones sur lesquelles un serveur est autoritaire). Le cache est entièrement stocké en mémoire (pas sur disque). 

TP RL/ II2-ENSI Page :5 

TP RL/ II2-ENSI Page :6 

Configuration d’un serveur primaire sous Linux 

Le nom et l’emplacement des fichiers de configuration peuvent changer d’une version à une autre du service DNS (named/bind9) et peuvent être fixés par l’administrateur. 4) Sur la machine OpenSuse, éditer le fichier /etc/named.conf. Ce fichier référence les fichiers de zone. 

options { directory « /var/lib/named »; allow-transfer { none; }; }; zone « notrezone.com » { type master; file « notrezone.zone »; }; zone « 0.168.192.in-addr.arpa » { type master; file « notrezone0.rev »; }; //Pour la résolution de l’adresse 127.0.0.1, on ajoute : zone « 0.0.127.in-addr.arpa » { type master; 

file « local.rev »; }; 

les fichiers de zone (ceux indiqués par la directive file) représente la BDD et comporte des enregistrements de ressources ou RR (« Resource Records »). Il existe différents types de RR : 

– SOA : « Start Of Authority » donne les informations relatives à la zone (serveur principal d’une zone, numéro de série …) – NS : liste des serveurs de nom pour le domaine – A : correspondance nom → adresse IPv4 d’un hôte – A6 : correspondance nom → adresse IPv6 – PTR : correspondance adresse IPv4 →nom d’un hôte – CNAME : alias ou nom canonique – HINFO : description de la machine (Système d’exploitation … en ASCII) – MX : serveur de mail pour du domaine – … Structure d’un SOA 

NomDomaine IN SOA NonServeur AdresseMail (Infos) 

Avec Infos : 

▪ Serial: numéro de version du fichier 

▪ Refresh : durée (en seconde) au bout de laquelle un secondaire doit interroger le primaire pour savoir si la zone a changé (il est aussi possible d’utiliser la directive « notify yes » lors de la déclaration d’une zone dans named.conf 

▪ Retry : durée des essais en cas d’échec du refresh (si non raffraichie) 

▪ Expire : durée maximale qu’un secondaire garde les infos 

▪ TTL : « Time To Live » du RR 

Sur la machine OpenSuse, éditer le fichier /var/lib/named/notrezone.zone $TTL 86400 //@ désigne le nom de domaine formulé dans named.conf 

TP RL/ II2-ENSI Page :7 

@ IN SOA opensuse.notrezone.com. root.notrezone.com.( 20111211 ; Serial 

28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS opensuse.notrezone.com. IN NS fedora0.notrezone.com. localhost IN A 127.0.0.1 ubuntu.notrezone.com. IN A 192.168.0.1 fedora0 IN A 192.168.0.2 opensuse IN A 192.168.0.3 MSserver IN A 192.168.1.1 fedora1 IN A 192.168.1.2 Sur la machine OpenSuse, éditer le fichier /var/lib/named/notrezone0.rev $TTL 86400 @ IN SOA opensuse.notrezone.com. root.notrezone.com. ( 20111211 

28800 14400 3600000 86400 ) IN NS opensuse.notrezone.com. IN NS fedora0.notrezone.com. 1.0.168.192.in-addr.arpa. IN PTR ubuntu.notrezone.com. 2.0.168.192.in-addr.arpa. IN PTR fedora0.notrezone.com. 3.0.168.192.in-addr.arpa. IN PTR opensuse.notrezone.com. Sur la machine 192.168.0.3, éditer le fichier /var/ lib/named/local.rev $TTL 86400 @ IN SOA opensuse.notrezone.com. root.notrezone.com. ( 20111211 

28800 14400 3600000 86400 ) IN NS opensuse.notrezone.com. IN NS fedora0.notrezone.com. 1 IN PTR localhost 

Que faut-il rajouter de plus dans named.conf pour tenir compte de la résolution inverse relative aux adresses 192.168.1.1 et 192.168.1.2. Décrire toutes les manipulations supplémentaires pour permettre cette résolution inverse. On doit ajouter la partie suivante au fichier named.conf : zone « 1.168.192.in-addr.arpa » { type master; 

file « notrezone1.rev »; }; et par conséquent et sur la machine Open SUSE on doit créer un fichier notrezone1.rev /var/named/notrezone1.rev qui contient les données suivantes : $TTL 86400 @ IN SOA opensuse.notrezone.com. root.notrezone.com. ( 20111211 28800 14400 3600000 86400 ) IN NS opensuse.notrezone.com. IN NS fedora0.notrezone.com. 1.1.168.192.in-addr.arpa. IN PTR MSserver.notrezone.com. 2.1.168.192.in-addr.arpa. IN PTR Fedora1.notrezone.com. 

Démarrer/redémarrer le serveur named (/etc/init.d/named). 

TP RL/ II2-ENSI Page :8 

Configuration d’un client et tests du serveur sous Linux 

5) Sur la machine Fedora, éditer le fichier /etc/resolv.conf. Ce fichier précise le ou les serveurs DNS, le nom de 

domaine … 

nameserver 192.168.0.3 Grâce à la commande man découvrir les principales fonctions de nslookup et de dig. Préciser les commandes utilisées pour tester le fonctionnement du serveur primaire. 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Configuration d’un serveur secondaire sous Linux 

6) Sur le serveur primaire (sur OpenSuse), autoriser les transferts (soit par défaut dans option, soit dans la définition des zones) : 

allow-transfer { 192.168.0.2; }; 

Sur la machine Fedora, éditer le fichier /etc/named.conf. 

options { 

directory « /var/named/slaves »; }; zone « notrezone.com » { type slave; file « notrezone.zone »; masters {192.168.0.3;}; }; zone « 0.168.192.in-addr.arpa » { type slave; file « notrezone0.rev »; masters {192.168.0.3;}; }; 

Vérifier que les fichiers /var/named/slaves/notrezone.zone et /var/named/notrezone0.rev ont été automatiquement créés. 

Configuration d’un serveur cache sous Linux 

7) A défaut de pouvoir joindre les serveurs racines, sur la machine Ubuntu nous allons configurer un serveur DNS cache en faisant appel au serveur DNS sur OpenSuse en tant que serveur racine (il ne pourra en fait réaliser que des résolutions sur la zone notrezone.com). La version de named (bind 9.7.1), installée sur Ubuntu, utilise un fichier /etc/bind/named.conf qui subdivise la configuration en 3 fichiers (inclus dans named.conf) : – Le premier fichier est /etc/bind/named.conf.option, dans ce fichier nous retrouvons la configuration des options. Particulièrement une option importante est celle qui consiste à déclarer les redirecteurs. Vous pouvez préciser le serveur DNS de votre fournisseur en tant que redirecteur de façon à ce que les requêtes soient envoyées à ce serveur de manière récursive. 

TP RL/ II2-ENSI Page :9 

options { 

forwarders { 193.95.66.10; } 

Cette option ne sera pas testée. 

Le deuxième fichier, /etc/bind/named.conf.local, est relatif à la prise en charge des zones associées aux adresses privées. Dans ce TP Nous n’allons pas nous intéresser à ce fichier. 

Le troisième fichier est /etc/bind/named.conf.default-zones, c’est à ce niveau que nous allons déclarer un cache sur la zone racine : zone « . » { 

type hint; file « /etc/bind/dbtp.root »;}; 

Le fichier dbtp.root a été créé pour les besoin du TP mais le vrai fichier devrait être /etc/bind/db.root (aussi, communément appelé named.ca ou aussi root.hint). Editer le fichier db.root. Que contient-il ? 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Lancer le serveur DNS (/etc/init.d/bind9 start). Grâce à la commande nslookup ou dig vérifier le bon fonctionnement du cache (remarque : sous nslookup, il est possible de sélectionner un serveur DNS à tester grâce à la commande server sans devoir agir sur le fichier resolv.conf). Est-ce que la réponse est « Authoritative » ? 

……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

Configuration d’un serveur DNS sou MS Windows Server 

8) Installer un serveur DNS primaire sur 192.168.1.1 (à rajouter en tant que rôle grâce à « Démarrer>Outils d’administration>Gestionnaire de serveur »). L’outil de configuration se trouve sous « Démarrer>Outils d’administration>DNS». 

Le nom de la machine Windows a été préalablement initialisé comme faisant partie du domaine notrezone.com. Automatiquement, lors de l’installation du DNS, la machine Windows devient un serveur DNS primaire sur les zones notrezone.com et la zone inverse relative à l’adresse réseau 192.168.1.0 (à laquelle appartient la machine Windows). 

En se positionnant sur « Zones de recherche directes>notrezone.com » et avec le bouton droit, rajouter les hôtes (les enregistrements de type A) correspondants aux différentes adresses de la maquette du TP (garder la création automatique de l’enregistrement PTR pour la résolution inverse cochée). 

En se positionnant sur « Zone de recherche inversées » et avec le bouton droit, créer la zone inverse correspondant à l’adresse réseau 192.168.0.0. Rajouter les pointeurs (PTR) correspondants aux différentes adresses du réseau 192.168.0.0. Avec la commande nslookup tester le bon fonctionnement du serveur. 

Comme vous l’auriez remarqué il est aussi possible de créer des zones sur lesquelles le serveur peut fonctionner en tant que serveur secondaire ou cache mes ces possibilités ne seront pas testées dans le présent TP. 

Nous allons plutôt tester la possibilité de déléguer une sous domaine de notrezone.com à un serveur DNS sur Fedora. Le domaine délégué sera appelé « delegue ». A cet effet, en se positionnant sur notrezone.com et avec le bouton droit, sélectionner « Nouvelle délégation… ». Fournir le nom : fedora1.notrezone.com (préalablement, assurez-vous que cet hôte (RR de type A) a été déjà ajouté dans la zone notrezone.com). Sur le serveur Fedora créer une zone delegue.notrezone.com pour laquelle le serveur fonctionne en tant que serveur primaire. Ajouter un 

TP RL/ II2-ENSI Page :10 

RR de type A dont le nom est tp.delegue.notrezone.com et l’adresse IP 192.168.0.10. Avec la commande nslookup sélectionner le serveur DNS de Windows et tester la résolution de tp.delegue.notrezone.com. 

Configuration d’un serveur DDNS sous Linux 

Une machine cliente DHCP se voit attribuer une adresse IP dynamiquement, il est possible de configurer le serveur DHCP afin qu’il mette à jour automatiquement le serveur DNS en transmettant les informations concernant le client. Une autre alternative possible est que la mise à jour se fasse par le client DHCP. Lorsque c’est le serveur DHCP qui le réalise, on a l’enchainement suivant : (1)DHCPDISCOVER (2) DHCPOFFER (3) Ajout de l’enregistrement de type A (4) Ajout de l’enregistrement de type PTR (5)DHCPREQUEST (6) DHCPACK 

9) Une clé d’authentification a été déjà générée (avec rndc-confgen) en exécutant la commande rndc-confgen. Cette clé a été copiée dans les deux fichiers dhcpd.conf et named.conf. Plus précisément, les directives à rajouter dans ces deux fichiers sont : 

  1. i) Fichier dhcpd.conf (sur OpenSuse) : 

#Spécifier le type de mise à jour du DNS et l’autoriser ddns-update-style interim; ddns-updates on; ddns- domainname « notrezone.com » ddns-rev-domainname « 0.168.192.in-addr.arpa » #Bloquer la mise a jour du dns directement par les client ignore client-updates; # Les lignes qui suivent relatives à la directive key ont été obtenues avec #rndc-confgen key « rndc-key »{ 

algorithm hmac-md5 ; secret « Teet61tarbQJHCNDofgZXQ== » } ; #Adresse du serveur Named et clé à utiliser pour chaque zone zone notrezone.com. { primary 192.168.0.3 ; key rndc-key ; } ; zone 0.168.192.in-addr.arpa. { primary 192.168.0.3 ; key rndc-key ; } ; 

  1. ii) Fichier named.conf (sur OpenSuse) # La même clé que précédemment key « rndc-key »{ 

algorithm hmac-md5 ; secret « Teet61tarbQJHCNDofgZXQ== » } ; 

TP RL/ II2-ENSI Page :11 

# Donner les autorisations en fonction de la clé controls {inet 192.168.0.3 allow {any; } keys { « rndc-key » ; }; }; et dans chaque zone où on veut permettre le DDNS, rajouter la ligne : allow-update { key rndc.key; }; 

notify yes ; 

Une fois ces deux fichiers configurés, lancer les services named et dhcpd (éventuellement les arrêter préalablement): /etc/init.d/dhcpd start /etc/init.d/named start Pour les tests la machine Ubuntu sera utilisée en tant que client. Editer le fichier /etc/dhcp3/dhclient.conf et rajouter les lignes suivantes : 

Send fqdn.fqdn « ddnsname.notrezone.com » Send fqdn.encoded off ; Send fqdn.server-update off ; Sur la machine OpenSuse faite ping sur ddnsname.notrezone.com. Vous pouvez aussi tester le fonctionnement du DDNS avec nslookup. Editer les fichiers de zones (notrezone.zone et notrezone0.rev), avec un retard de quelques minutes les enregistrements correspondant à ddnsname.notrezone.com devraient figurer dans ces fichiers. 

TP RL/ II2-ENSI Page :12 

TP – Déploiement de réseaux IP sous IOS Cisco 

Objectifs : 

– – 

Configuration d’un accès WAN (LS, FR). Configuration d’un routage statique / dynamique (RIP ou OSPF). Familiarisation avec les commandes de configurations propres au système IOS Cisco. 

Barème : 5 par question. 

Environnement logiciels et maquette 

Le simulateur « Packet Tracer » (ou GNS). 

On considère le réseau décrit par la figure ci-dessus. 

Site 0 Site 1 

Pour chaque site (site 0 et site 1), est prévu un commutateur Fast Ethernet (Switch 0 et Switch 1), A chacun de ces commutateurs est relié un PC (PC0 et PC1) et un routeur (Router0 et Router1). Choisir des routeurs avec des ports séries ou rajouter les modules nécessaires. A travers leur interface série (serial2/0), les deux routeurs sont reliés par une liaison null-modem (« Serial DTE »)). Le plan d’adressage est décrit comme suit : 

Nom de la machine/interface PC0 PC1 Router0/FastEthernet Router0/serial2/0 Router1/FastEthernet Router1/serial2/0 

Adresse IP 10.0.0.1/16 10.1.0.1/16 10.0.255.254/16 10.255.255.5/30 10.1.255.254/16 10.255.255.6/30 Configuration de l’adressage, du protocole PPP et et d’un routage statique 1) Décrire la suite de commandes qu’il faut taper sur chacun des routeurs pour la configuration de l’adressage d’une 

interface (au choix). 

>enable # ip address 10.255.255.5 255.255.255.252 

# configure terminal #no shutdown 

# interface fastethernet 0/0 #ip address 10.0.255.254 255.255.0.0 #no shutdown #exit #interface serial 2/0 

Procéder à la configuration de l’adressage de toutes les interfaces. Sur la liaison point à point il faut prévoir un protocole de liaison. A cet effet, nous allons utiliser le protocole PPP, sur chacun des routeurs et en passant en mode configuration de l’interface serial0, taper : Router(config-if)#encapsulation ppp Fixer la vitesse d’horloge en tapant sur chacun des routeurs la commande suivante : Router(config-if)#clock rate 56000 

TP RL/ II2-ENSI Page :1 

Utiliser la commande show interface pour s’assurer qu’administrativement une interface est activée, qu’au niveau physique l’interface fonctionne correctement et que la configuration logique (ex. encapsulation) ou protocolaire est correcte. Quelle est le message retourné concernant ces informations lorsque tout fonctionne correctement. 

1 Serial 2/0 is up , line protocol is up ( connected ) 

Quelle est le message retourné si d’un coté il y a une encapsulation PPP et de l’autre une encapsulation HDLC. 

1 Serial 2/0 is up, line protocol is down (disabled) 

Remettre l’encapsulation PPP des deux cotés. Et fixer le débit à 128 Kb/s. Sur une liaison PPP, il est possible d’authentifier une extrémité par l’autre ou aussi d’activer l’authentification dans les deux sens. Pour permettre au Router0 d’authentifier Router1 (utilisateur = site1 et mot de passe psite1) suivant le protocole PAP, il suffit de tapez sur Router 0 les commandes suivantes : Router(config)#username site1 password 0 psite1 Router(config)#interface serial 2/0 Router(config-if)#ppp authentification pap 

et sur le Router1, il faut taper les commandes suivantes : Router(config)#interface serial 2/0 Router(config-if)# ppp pap sent-username site1 password 0 psite1 

1 Vérifier avec le mot de passe correcte et un mot de passe in correcte le fonctionnement de la connexion. 

2) Depuis PC0 il n’est pas possible de joindre PC1 car certaines routes manquent ? La commande pour visualiser les 

routes est : Router#show ip route 

Pour rajouter une route utiliser la commande (utiliser ? pour déterminer la suite des paramètres) : 

Router(config)#ip route … 

Décrire les routes à rajouter sur les deux routeurs. Que faut-il aussi prévoir sur les deux PC. Vérifier que les deux PC arrivent à « pinguer » entre eux. ####Routeur 0### ####Routeur 1### 

#conf t #conf t 

5 #ip route 10.1.0.0 255.255.0.0 10.255.255.6 # ip route 10.0.0.0 255.255.0.0 10.255.255.5 

Sous reseau destinetion masque passerelle 

On doit ajouter à chaque station PC0 et PC1 

PC0 10.0.255.254 

PC1 10.1.255.254 

……………………………………………………………………………………………………………………………………………………………………………………… 

Interconnexion de deux sites via un réseau « Frame Relay » Les sites 0 et 1 ainsi qu’un troisième site (site 2) sont connectés à un réseau « Frame Relay » (FR). A cet effet, le routeur Router0 (respectivement Router 1) est connecté, via l’interface série serial 3/0, à un réseau FR (cloud-PT). Sur le site 2, se trouve un troisième routeur Router2 connecté d’une part au réseau FR et d’autre part à un commutateur Fast Ethernet (Switch 2). Au commutateur est relié un PC (PC2). Pour la connexion au réseau FR choisir une liaison « Serial DCE ». Le reste du plan d’adressage est décrit comme suit : 

Nom de la machine/Interface Router0/serial3/0 Router1/serial3/0 Router2/serial3/0 Router2/FastEthernet PC2 

Adresse IP 10.3.255.254/16 10.3.255.253/16 10.3.255.252/16 10.2.255.254/16 10.2.0.1/16 

TP RL/ II2-ENSI Page :2 

La transmission sur un réseau FR s’effectue à travers des circuits virtuels VCs désignés localement par un DLCI « Data Link Connection Identifier ». Dans cette manipulation nous allons utiliser des CVs permanents (PVCs). Lors de la de configuration du réseau FR il faut initialiser les différents PVCs (dans la réalité ceci se fait en s’adressant à l’opérateur). Sur le simulateur cliquer sur le Cloud-PT et pour chaque interface séries (chacune correspondant à un site) définir deux VCs allant vers les deux autres sites. La définition d’un VC se fait en précisant le numéro de DLCI, son nom ainsi que le type de commutateur FR auquel on est raccordé (choisir la norme Q.933a). Sur le réseau FR (cloud FR) les interfaces séries sont numérotées de 0 à 2), supposons que le site <i> et connecté au port série<i> on aura : 

être passé en mode configuration de l’interface serial 3/0, dans le cas du router0) : Router(config-if)ip address 10.3.255.254 255.255.0.0 Router(config-if)encapsulation frame-relay Router(config-if) frame-relay interface-dlci 101 Router(config-if)frame-relay interface-dlci 102 Router(config-if)frame-relay lmi-type q933a Router(config-if) clock rate 56000 Configurer de même les routeurs Router1 et Router2. Le réseau frame relay fournit à chaque routeur un mapping entre les adresses IP distantes et le DLCI local permettant de joindre ces adresses (de la même façon que le protocole ARP fournit la correspondance entre les adresses IP et les adresses MACs). Visualiser ce « mapping » grâce à la commande : Router#show frame-relay map Des statistiques relatives aux différents VCs peuvent êtres obtenues grâce à la commande Router#show frame-relay pvc Visualiser la table de routage et vérifier que les trois routeurs arrivent à se joindre via le réseau FR. 

Reste à associer les DLCI de part et d’autre de chaque VC. Ceci se fait, sous l’onglet « Frame Relay », comme suit : 

3) Pour configurer une interface connectée à un réseau FR, commençons par taper les commandes suivantes (après 

TP RL/ II2-ENSI Page :3 

Site 0 Site 1 

Site 2 

Routage dynamique RIP Nous pouvons remarquer à ce stade que PC0 et PC1 n’arrivent pas à joindre PC2. En gardant les routes statiques déjà saisies et en ayant sur chaque PC une route par défaut correspondante au routeur du site où se trouve le PC, nous allons activer le routage RIP. 

4) Sur chaque routeur, taper les commandes de configuration de RIP. Par exemple sur Router0 : 

Router(config)#router rip 

Router(config-router)# version 2 Router(config-router)#network 10.3.0.0 Router(config-router)#network 10.255.255.4 A noter que sur ce routeur (Router0), il est inutile d’activer le RIP sur le réseau 10.0.0.0 car il n y a pas d’autres routeurs RIP, ni même une station sur laquelle nous pouvons activer un écouteur RIP pour apprendre les routes (sur une station, nous nous limitons à la route par défaut). Visualiser la table de routage sur Router0. Depuis ce routeur et pour joindre le PC1, est-ce l’ICMP-echo passe par la liaison PPP ou par le réseau FR. Pourquoi il en est ainsi ? 

2 L’ICMP-echo passe par la liaison PPP par ce que l’algorithme rip fonctionne de telle sort qu’il choisit le plus court chemin qui est la chemin PPP dans notre cas car en rip les liaisons sont pondérées. 1 Désactiver l’interface correspondante à la route suivie par Router0 pour joindre 10.1.0.0. Vérifier que la table de 

routage change et passe par la route alternative. 

Désactiver les routes statiques sur les différents routeurs. Nous allons étendre le réseau en rajoutant un quatrième site (site 3) comportant : un commutateur Fast Ethernet (Switch3), un PC (PC3) connecté au Switch3 et un routeur Router3 ayant une interface Fast Ethernet connectée au au Switch3 et deux interfaces Gigabit Ethernet connectées aux routeurs Router0 et Router1 (rajouter les interfaces Gigabit si nécessaire). Le reste du plan d’adressage est comme suit 

Nom de la machine/Interface Router0/Giga Ethernet 6/0 Router1/Giga Ethernet 6/0 Router3/Giga Ethernet 6/0 Router3/Giga Ethernet 7/0 Router3/Fast Ethernet 0/0 PC3 

Adresse IP 10.255.255.9/30 10.255.255.14/30 10.255.255.10/30 10.255.255.13/30 10.4.255.254/16 10.4.0.1/16 

Pourquoi le Router0 passe par une liaison série à 128 Kb/s (correspondant à PPP ou FR) pour joindre PC1 et ne passe pas par l’interface Gigabit Ethernet. Conclusion. 

Le Routeur0 passe par une liaison série à 128 Kb/s pour joindre PC1 et ne passe pas par l’interface Gigabit Ethernet car l’algorithme du fonctionnement de rip affecte à la liaison Gigabit Ethernet une valeur supérieure à celle des liaisons 128 kb/s. On peut conclure que le rip privilège les liaisons ayant un débit plus faible à ceux ayant un débit plus élévé. Routage dynamique OSPF (bonus) 

Désactiver le routage RIP. Nous allons configurer le routage OSPF. Suivant Ce protocole, l’AS peut être découpé en aires. La décomposition que nous retenons est la suivante : 

Aire Réseaux 0 10.255.255.4 10.255.255.8 10.255.255.12 1 10.0.0.0 10.1.0.0 10.2.0.0 10.3.0.0 2 10.4.0.0 

5) Sur chaque routeur, taper les commandes de configuration d’OSPF, par exemple sur Router0 : 

Router(config)#router ospf 1 

Router(config-router)#network 10.0.0.0 ? 

A.B.C.D OSPF wild card bits (valeur inverse du masque) 

TP RL/ II2-ENSI Page :4 

Router(config-router)#network 10.0.0.0 0.0.255.255 area 1 Router(config-router)#network 10.3.0.0 0.0.255.255 area 1 Router(config-router)#network 10.255.255.4 0.0.0.3 area 0 Router(config-router)#network 10.255.255.8 0.0.0.3 area 0 Visualiser la table de routage sur Router0. Depuis ce routeur, par quelle interface passe le routeur pour joindre le PC1. Pourquoi ? Que peut-on conclure en comparaison avec le RIP. ………………………………………………………………………………………………………………………………………………………………………………. ………………………………………………………………………………………………………………………………………………………………………………. ………………………………………………………………………………………………………………………………………………………………………………. ………………………………………………………………………………………………………………………………………………………………………………. 

Commandes utiles pour la visualisation de certaines informations d’état (le cours « réseaux informatiques », est un pré requis pour une interprétation avancée de ces informations) Router# show ip ospf interface … Router# show ip ospf database Router# show ip ospf neighbor Router(config-router)#router-id … 

TP RL/ II2-ENSI Page :5 

TP – Configuration de LANs & Interconnexion de niveau 2 sous IOS Cisco 

Objectifs : 

– Mise en place d’un réseau local d’entreprise comportant des Hubs et des commutateurs (Switchs) Ethernet et des points d’accès Wifi. – Utilisation de plusieurs supports pour augmenter la capacité d’interconnexion entre deux commutateurs (norme IEEE802.1ad ou suivant la terminologie CISCO à l’EtherChannel). – Pontage et configuration du « Spanning Tree » pour prévenir l’apparition de boucles (norme IEEE 802.1D). – Configuration de VLANs et le « tagging » ( norme IEEE802.1Q ou suivant terminologie CISCO : trunking). – Configuration du routage entre VLANs grâce à un commutateur de niveau 3. – Familiarisation avec les commandes IOS Cisco pour l’ensemble des manipulations réalisées. 

Barème : 3+4.5+1.5+6+3+2 

Environnement logiciel Le simulateur « Packet Tracer » sera utilisé pour les manipulations prévues par ce TP. Pour les besoins de test du fonctionnement du réseau, nous aurons aussi besoin de mettre en œuvre un plan d’adressage IP très simple avec des instructions qui seront fournies par l’énoncé même. L’étude de l’adressage IP sera faite dans un autre TP à part. 

Câblage, configuration et test d’un réseau 1) Connecter 2 PCs « Generic » (PC0, PC1) à un HUB « Generic ». Connecter le HUB (Hub0) au port FastEthernet0/1 d’un un commutateur CISCO série 3560-24PS (Switch0). Connecter deux autres 2 PCs (PC2, PC3) au Switch0 en utilisant respectivement les ports FastEthernet0/2 et FastEthernet0/3. Connecter le port RS232 du PC3 au port console du Switch0. Vérifier l’état des LEDs (vertes) des deux cotés. Il est à remarquer qu’une LED clignote lorsqu’une trame passe par le port associé. 

  1. Quelle est la nature du lien entre le HUB et le commutateur. ………le lien entre le hub le commutateur est un lien point à point ………………………… 
  2. Configurer les adresses IP des quatre PC : c. Grâce à la commande ping, vérifier que tout PC est capable de joindre tout autre PC. 

– PC0 : adresse IP =10.0.1.0, masque = 255.0.0.0 – PC1 : adresse IP =10.0.1.1, masque = 255.0.0.0 – PC2 : adresse IP =10.0.1.2, masque = 255.0.0.0 – PC3 : adresse IP =10.0.1.3, masque = 255.0.0.0 d. Grâce à la commande ping, vérifier que tout PC est capable de joindre tout autre PC. e. Depuis PC0 taper la commande : 

PC>ping -t 10.0.1.2 

Une fois que le commutateur a effectué l’auto-apprentissage des adresses MAC, quelles sont, en théorie, les LEDs qui devraient continuer à clignoter ? 

TP RL / II2-ENSI/ A. ELLEUCH Page :1 

……les Leds qui devraient continuer à clignoter sont les leds entre hub – pc1 , hub – pc0, hub – commutateur et commutateur pc2 ………………………………………………………………………………………………………………….. 

  1. Justifier votre réponse (N.B. : le simulateur ne produit pas le résultat exact). ……Le commutateur envoie le message qu’à la machine destination alors que le HUB diffuse le message vers toutes les stations qu’y sont connectés. …………………………………………. Remarque : Il est possible de faire passer un port du commutateur en mode « monitoring » pour qu’il reçoive l’ensemble des trames passant par le commutateur. Cette possibilité ne figure pas dans le simulateur. Pour information, les commandes sont les suivantes : Switch(config)#monitor session 1 source vlan 1 Switch(config)#monitor session 1 destination interface FastEthernet 0/3 

Configuration du commutateur 

2) L’accès au commutateur peut se faire via une console à travers le lien : [port console du commutateur<-> port série RS232 du PC] en utilisant un émulateur de terminal (Hyperterm ou minicom). Dans le cas de Packet Tracer l’équivalent de cette console est obtenu grâce à l’onglet Terminal sur un PC. Garder les paramètres par défaut (9600 bits/s …). Il est aussi possible d’obtenir cette même console à travers l’onglet CLI du commutateur. 

  1. Taper les commandes suivantes : 

Switch> enable Swtich# show interfaces FastEthernet 0/1 Swtich# show interfaces FastEthernet 0/2 b. Pour chacun des deux ports, est-ce que le protocole CSMA/CD est activé ? Expliquer et justifier votre réponse. …la commande show interfaces FastEthernet 0/x prouve le fonctionnement en Half-Duplex du port 1 du switch et le fonctionnement en Full-duplex du port 2.Or la détection de collisions n’a de sens qu’en mode Half-Duplex, car en mode Full-Duplex la transmission et la réception sont gérées par deux circuits séparés…………………………………………………………………………………………………………………………………………………………………………………………………… 

Donc le CSMA/CD doit être activé sur le port 1 et désactivé sur le port 2 du switch. …………………… 

  1. Est-ce que ces deux ports ont une même adresse MAC (qui serait celle du commutateur) ? Justifier votre réponse ……Non, chaque port a sa propre adresse MAC pour le bon fonctionnement de l’algorithme de spanning tree…………………………………………………………………………………………………………………………………………….. 
  2. Taper les commandes suivantes : 

Switch#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#interface FastEthernet 0/3 Switch(config-if)#? e. Quelles sont les commandes à taper pour activer le CSMA/CD sur le port FastEthernet 0/1 ? 

enable configure terminal interface FastEthernet 0/1 duplex half ……………………………………………………… 

  1. Si nous configurons le port FastEthernet 0/1 du Switch0 en « full-duplex », le port devient dans une situation dite de «duplex mismatch». Ceci se produit aussi lorsqu’une carte réseau d’un PC est configurée en «half-duplex» alors que le port du commutateur auquel est connecté le PC est en «full-duplex». Décrire les conséquences d’un « duplex mismatch » (N.B. : le simulateur ne produit pas le résultat exact du «duplex mismatch»). ………les LEDs entre le HUB et le switch deviennent rouge alors il n’y a pas de transmission. Les conséquences du duplex mismatch sont l’augmentation des collisions mais le réseau continu à fonctionner car les erreurs sont transmises au niveau supérieure. …………………………………………………… 
  2. En étant en mode utilisateur décrire la série de commande pour désactiver le port auquel est connecté le PC2. TP RL / II2-ENSI/ A. ELLEUCH Page :2 

1 1 1 

enable configure terminal interfaces fasethernet 0/2 shutdown 

  1. Quel est en conséquence l’état « administratif » de l’interface. 

……interface non admistrable : administratively down………………………………………………………… ………………………………………………………………………………………………………………………………………………………………………………. 

  1. Vérifier que PC2 ne répond plus à une commande ping depuis un autre PC. Réactiver le port en question. 

3) Il est possible d’augmenter la capacité d’interconnexion entre deux commutateurs en utilisant plusieurs liens sur lesquels le trafic est équilibré. A cet effet, nous allons rajouter un autre commutateur 3560-24PS (Switch1). Les deux commutateurs seront reliés par deux liens en utilisant les ports FastEthernet 0/23 et 0/24 de part et d’autre. 

  1. Pour regrouper les deux interfaces FastEthernet 0/23 et 0/24 de façon à ce qu’elles apparaissent logiquement comme un seul lien, taper les commandes suivantes (sur les deux commutateurs) : 

Switch(config)#interface range FastEthernet 0/23- 24 Switch(config-if-range)#channel-group 1 mode on Switch(config-if-range)#end b. Vérifier que les deux interfaces sont groupées en tapant : 

Switch#show interfaces etherchannel 

Switch#show interfaces etherchannel FastEthernet0/23: Port state = 1 Channel group = 1 Mode = On Gcchange = – Port-channel = Po1 GC = – Pseudo port-channel = Po1 Port index = 0 Load = 0x0 Protocol = – Age of the port in the current state: 00d:00h:00m:53s 

FastEthernet0/24: Port state = 1 Channel group = 1 Mode = On Gcchange = – Port-channel = Po1 GC = – Pseudo port-channel = Po1 Port index = 0 Load = 0x0 Protocol = – Age of the port in the current state: 00d:00h:00m:53s —- Port-channel1:Port-channel1 Age of the Port-channel = 00d:00h:00m:53s Logical slot/port = 2/1 Number of ports = 2 GC = 0x00000000 HotStandBy port = null Port state = 

–More– ……………………………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

  1. Rajouter un 5ème PC (PC4) connecté au nouveau commutateur et lui associer l’adresse IP 10.0.1.4. Vérifier que ce PC est joignable depuis les autres PC. 

Pontage & Spanning Tree 4) Dans cette question nous nous intéressons au pontage et à l’utilisation du Spanning Tree. 

  1. Quel est le commutateur racine du « Spanning Tree » ? Préciser son identité (Priorité+adresse MAC). Pour répondre à cette question, utiliser la commande : Swtich# show spanning-tree ………le switch 0 est la racine …………………………………………………… ……… Root ID Priority 32769…………………………………………… ……………………………Address 0001.C75D.3226……………………… ……………………………This bridge is the root…………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 
  2. Pourquoi ce n’est pas l’autre commutateur. ……ce n’est pas l’autre commutateur, car ce commutateur a l’adresse MAC la plus petit entre les deux. ……………………………………………………………………………………………………………………………………………… Remarque : la priorité combine une valeur par défaut à la valeur du VLAN (pour l’instant, nous avons un seul VLAN : 1 par défaut). 
  3. Pour changer la racine il suffit de réduire la valeur de la priorité du commutateur non racine. Réduire cette priorité à la valeur juste en dessous. switch enable configure terminal #spanning-tree vlan 1 priority 4096. 
  4. Vérifier que le commutateur est devenu la racine de l’arbre. ………root ID priority 286………………………………………………………………………… 
  5. En plus de l’EtherChannel, nous allons rajouter un autre lien entre les deux commutateurs, ce lien est relié de part et d’autre au port FastEthernet 0/22 de chacun des deux commutateurs, ce qui crée un cycle. Quel est le commutateur racine. 

TP RL / II2-ENSI/ A. ELLEUCH Page :3 

……le commutateur 1 est encore la racine……………………………………… 1 ……………………………………………………………………………………………………………………………………………………………………………………… 

  1. Quel est le port désactivé (bloqué) par le « Spanning Tree ». 1 …………les ports désactivés sont les ports 0/23 et 0/24 ………………………………………………………………………… 

……………………………………………………………………………………………………………………………………………………………………………………… 

L’état d’une interface peut être à l’un des états suivants : 

– DSB – “the port has been manually disabled or failed to pass diagnostics”. – BLK – “the port receives STP BPDUs, but will not forward any packets”. – LSN – “STP perceives that the port should no longer be blocked because of some topology change. It transmits BPDUs, but forwards no packets.” – LRN – if after transmitting BPDUs for a set amount of Forward Delay seconds, no contradictory information is learned, the port address table is cleared and addresses begin to be learned and then forwarding begins. All ports that are going to change states from blocking to forwarding will have done so after: MaxMessAge + (2 * Switch Forward Delay)” – FWD – port begins forwarding packets normally. – Link Down h. Désactiver le port non bloqué par le « Spanning Tree ». i. Vérifier que l’autre port passe à l’état FWD. j. Est-ce qu’il passe immédiatement à cet état ? Expliquer ? ………non, il passe par les états suivants LSN–>LRN–>FWD………………………………………………………… ………………….. ……………………………………………………………………………………………………………………………………………………………………………………… 

Réactiver le port que vous venez de désactiver. j. Maintenant nous allons désactiver le « Spanning Tree » grâce à la commande : 

Switch(config)#no spanning-tree vlan 1 k. Bien que le simulateur ne produise pas systématiquement l’effet réel de ce qui se produit à la suite de cette commande, décrire ce qui devrait se passer à la suite de cette commande. ………à la suite de cette commande il y a apparition d’u cycle entre les deux commutateur donc chaque message ne passe plus d’un vlan à un autre il reste bloqué entre les deux commutateurs jusqu’à ce que les buffers se chargent ce qui va générer un erreur……………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………………………………… 

  1. Réactiver le « le Spanning Tree ». Supprimer l’EtherChannel et ne garder que le lien entre les ports FasEthernet 

0/22. Configuration de VLANs 5) Dans cette question nous nous intéressons à la configuration des VLANs 

  1. Taper la commande suivante : 

Swtich# show vlan 1 A quel VLAN appartiennent les différents PCs ? 

……Ils appartiennent au vlan 1. ……………………………………………………………… 

  1. Nous voulons que PC0, PC1 et PC2 soient dans un premier VLAN (vlan 1) et le reste dans un second VLAN (vlan 2). A cet effet, il suffit de faire passer, sur Switch0, le port associé à PC3 et le port le reliant à Switch1 sur vlan 2. Nous allons commencer par taper les commandes suivantes : 

Sur Switch0 Switch(config)#interface fastEthernet 0/3 Switch(config-if)#switchport mode access Switch(config-if)#switchport access vlan 2 Switch(config)#interface fastEthernet 0/22 Switch(config-if)#switchport mode access TP RL / II2-ENSI/ A. ELLEUCH Page :4 

Switch(config-if)#switchport access vlan 2 

  1. Vérifier que les PC d’un même VLAN arrivent à communiquer entre eux bien que ces deux derniers sont dans un même VLAN. d. Cependant avec une telle configuration il n’est plus possible de relier sur le Switch1 des PCs appartenant au vlan 1, pour que ceci soit possible, il faut effectuer le « tagging » ou selon la terminologie de Cisco le «trunking ». En quoi consiste cette technique ? ……c’est un multiplexage de réseau Independent, qui permet de savoir à quel VLAN appartient un routeur ou pc…………………………………………………………………………………………………………………………………………………………… 
  2. A cet effet taper les commandes suivantes (sur chacun des routeurs) : 

Switch(config)#interface fastEthernet 0/22 Switch(config-if)#switchport mode trunk Switch#show interfaces trunk 

NB.: sur les routeurs réels il est possible de choisir le protocole de tagging : Switch(config-if)#switchport trunk encapsulation dot1q 

  1. Vérifier que depuis PC3 il est possible de joindre PC4. 

Nous rajouterons, dans la question qui suit, un point d’accès relié à Switch1 et appartenant vlan1, nous pourrons ainsi vérifier que seuls les équipements d’un même VLAN arrivent à communiquer entre eux. 

Configuration d’un point d’accès 

6) Dans cette question nous nous intéressons à la configuration d’un point d’accès WiFi. a. Réaliser les opérations suivantes : – Rajouter un point d’accès AP0 et le relier au Switch1 (le VLAN par défaut est vlan 1). 

– Rajouter un PC (PC5). Eteindre PC5 puis supprimer la carte Fast Ethernet. Rajouter une carte Wifi Linksys. Remettre sous tension. Affecter à PC5 l’adresse 10.0.1.5 masque 255.0.0.0. – Sur AP0, fixer le SSID à Wifi et la clé WEP à 9876543210. Paramétrer le SSID et la clé sur PC5. – Vérifier que PC5 arrive à joindre les PCs de vlan 1. 

Avec le simulateur il n’est pas possible de faire fonctionner le WDS « Wireless Distribution Service » pour relier deux points d’accès à travers un lien sans fils, auquel cas, un AP est comparable à un répéteur. 

  1. Nous allons donc relier un second point d’accès (AP1) à travers un lien filaire dans VLAN 1, comme le montre la figure ci-dessous. Rajouter ce second point d’accès et un PC (PC6) dans vlan 1, avec le SSID wifi et la clé WEP 9876543210. c. Vérifier que PC6 arrive à joindre les PCs du vlan 1. d. Pour une telle configuration, est-ce que les points d’accès sont comparables à des répéteurs ou à des ponts ? Justifier votre réponse. ……pour une telle configuration les point d’accès sont comparable à des répéteurs car ils ne lient pas des réseaux distincts ………………………………………………………………………………………………………………………………………………… 

………………………………………………………………………………………………………………………………………………………………………………………… 

AP1 AP0 

TP RL / II2-ENSI/ A. ELLEUCH Page :5 

Configuration d’un commutateur de niveau 3 en tant que routeur (question bonus) 

7) Le commutateur 3560 est un commutateur de niveau 3, il peut donc fonctionner en tant que routeur. Nous allons donc l’utiliser pour réaliser le routage entre les réseaux 10.0.0.0/8 et 192.168.0.0/24. A cet effet, il faut configurer une interface vlan dans chaque VLAN et lui assigner une adresse IP. Sur le Switch0 taper les commandes suivantes : Switch(config)#interface vlan 1 Switch(config)#ip address 10.0.1.254 255.0.0.0 Switch(config-if)# no shutdown Switch(config-if)# exit Switch(config)#interface vlan 2 

Switch(config)#ip address 192.168.0.254 255.255.255.0 Switch(config-if)# no shutdown Remarque : avec Packet tracer 5.3 il faut explicitement activer le routage de niveau 3 : Switch(config)#ip routing 

Modifier l’adresse de PC3 et PC4 et leur fixer la passerelle par défaut comme suit : – PC3 : 192.168.0.3 masque 255.255.255.0, passerelle : 192.168.0.254 – PC4 : 192.168.0.4 masque 255.255.255.0, passerelle : 192.168.0.254 

Fixer la passerelle de PC0, PC1, PC2 et PC5 à 10.0.1.254. Vérifier que depuis PC0, PC1, PC2 et PC5 il est possible de joindre PC3. Pour pouvoir joindre PC4, il faut sur le Switch1, configurer les interfaces vlan 1 et vlan 2 et leur associer une adresse IP : Switch(config)#interface vlan 1 Switch(config)#ip address 10.0.1.253 255.0.0.0 Switch(config-if)# no shutdown Switch(config-if)# exit Switch(config)#interface vlan 2 Switch(config)#ip address 192.168.0.253 255.255.255.0 Switch(config-if)# no shutdown Fixer la passerelle de PC4 à 192.168.0.254 ou 192.168.0.253. 

TP RL / II2-ENSI/ A. ELLEUCH Page :6 

 

télécharger gratuitement cours de Réseau Cisco

Articles similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Bouton retour en haut de la page

Adblock détecté

S'il vous plaît envisager de nous soutenir en désactivant votre bloqueur de publicité