Version 1.1
Copyright © 2004 L'équipe Freeduc-Sup
Permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU (GNU Free Documentation License), version 1.1 ou toute version ultérieure publiée par la Free Software Foundation sans section invariante, sans texte de première de couverture, ni texte de quatrième de couverture. Une copie de la licence est fournie dans la section intitulée "GNU Free Documentation License".
| Revision History | |
|---|---|
| Revision 1.0 | Septembre 2007 |
Abstract
Ensemble de documents réalisés pour la freeduc-sup.
Table of Contents
hosts/etc/inittabList of Figures
List of Examples
Table of Contents
Abstract
Le document présente la suite de protocoles TCP/IP.
Ce document sert d'introduction à l'ensemble des cours et TP sur les différents protocoles
TCP/IP est l'abréviation de Transmission Control Protocol/Internet Protocol. Ce protocole a été développé, en environnement UNIX, à la fin des années 1970 à l'issue d'un projet de recherche sur les interconnexions de réseaux mené par la DARPA (Defense Advanced Research Projects Agency) dépendant du DoD (Department of Defense) Américain.
TCP/IP ,devenu standard de fait, est actuellement la famille de protocoles réseaux qui gère le routage la plus répandue sur les systèmes informatiques (Unix/Linux, Windows, Netware...) et surtout, c'est le protocole de l'Internet.
Plusieurs facteurs ont contribué à sa popularité :
Maturité, Ouverture, Absence de propriétaire, Richesse (il fournit un vaste ensemble de fonctionnalités), Compatibilité (différents systèmes d'exploitation et différentes architectures matérielles), et le développement important d'Internet.
La famille des protocoles TCP/IP est appelée protocoles Internet, et a donné son nom au réseau du même nom. Leurs spécifications sont définies dans des documents du domaine public appelés RFC (Request For Comments - Appels à commentaires). Ils sont produits par l'IETF ( Internet Engineering Task Force) au sein de l'IAB (Internet Architecture Board).
La RFC 826, par exemple, définit le protocole ARP.
Bien que le protocole TCP/IP ait été développé bien avant que le modèle OSI apparaisse, ils ne sont pas totalement incompatibles. L'architecture OSI est définie plus rigoureusement, mais ils disposent tous deux d'une architecture en couches.
Les protocoles TCP et IP ne sont que deux des membres de la suite de protocoles TCP/IP qui constituent le modèle DOD (modèle en 4 couches). Chaque couche du modèle TCP/IP correspond à une ou plusieurs couches du modèle OSI (Open Systems Interconnection) défini par l'ISO (International Standards Organization) :
Des relations étroites peuvent être établies entre la couche réseau et IP, et la couche transport et TCP.
TCP/IP peut utiliser une grande variété de protocoles en couche de niveau inférieur, notamment X.25, Ethernet et Token Ring. En fait, TCP/IP a été explicitement conçu sans spécification de couche physique ou de liaison de données car le but était de faire un protocole adaptable à la plupart des supports.
Les protocoles TCP/IP se situent dans un modèle souvent nommé "famille de protocoles TCP/IP".
Les protocoles TCP et IP ne sont que deux des membres de la suite de protocoles IP.
IP est un protocole qui se charge de l'acheminement des paquets pour tous les autres protocoles de la famille TCP/IP. Il fournit un système de remise de données optimisé sans connexion. Le terme « optimisé » souligne le fait qu'il ne garantit pas que les paquets transportés parviennent à leur destination, ni qu'ils soient reçus dans leur ordre d'envoi. La fonctionnalité de somme de contrôle du protocole ne confirme que l'intégrité de l'en-tête IP. Ainsi, seuls les protocoles de niveau supérieur sont responsables des données contenues dans les paquets IP (et de leur ordre de réception).
Le protocole IP travaille en mode non connecté, c'est-à-dire que les paquets émis par le niveau 3 sont acheminés de manière autonome (datagrammes), sans garantie de livraison.
Le datagramme correspond au format de paquet défini par le protocole Internet. Les cinq ou six (sixième facultatif) premier mots de 32 bits représentent les informations de contrôle appelées en-tête.
La longueur théorique maximale d'un datagramme IP est de 65535 octets. En pratique la taille maximale du datagramme est limitée par la longueur maximale des trames transportées sur le réseau physique. La fragmentation du datagramme (définie dans le 2ème mot de 32 bits) devient alors nécessaire dès que sa taille ne lui permet plus d'être directement transporté dans une seule trame physique. Les modules internet des équipements prennent en charge le découpage et le réassemblage des datagrammes.
Le protocole Internet transmet le datagramme en utilisant l'adresse de destination contenue dans le cinquième mot de l'en-tête. L'adresse de destination est une adresse IP standard de 32 bits permettant d'identifier le réseau de destination et la machine hôte connectée à ce réseau.
Dans un réseau TCP/IP, on assigne généralement une adresse IP à chaque hôte. Le terme d'hôte est pris dans son sens large, c'est à dire un "noeud de réseau". Une imprimante, un routeur, un serveur, un poste de travail sont des noeuds qui peuvent avoir également un nom d'hôte, s'ils ont une adresse IP.
TCP est probablement le protocole IP de niveau supérieur le plus répandu. TCP fournit un service sécurisé de remise des paquets. TCP fournit un protocole fiable, orienté connexion, au-dessus d'IP (ou encapsulé à l'intérieur d'IP). TCP garantit l'ordre et la remise des paquets, il vérifie l'intégrité de l'en-tête des paquets et des données qu'ils contiennent. TCP est responsable de la retransmission des paquets altérés ou perdus par le réseau lors de leur transmission. Cette fiabilité fait de TCP/IP un protocole bien adapté pour la transmission de données basée sur la session, les applications client-serveur et les services critiques tels que le courrier électronique.
La fiabilité de TCP a son prix. Les en-têtes TCP requièrent l'utilisation de bits supplémentaires pour effectuer correctement la mise en séquence des informations, ainsi qu'un total de contrôle obligatoire pour assurer la fiabilité non seulement de l'en-tête TCP, mais aussi des données contenues dans le paquet. Pour garantir la réussite de la livraison des données, ce protocole exige également que le destinataire accuse réception des données.
Ces accusés de réception (ACK) génèrent une activité réseau supplémentaire qui diminue le débit de la transmission des données au profit de la fiabilité. Pour limiter l'impact de cette contrainte sur la performance, la plupart des hôtes n'envoient un accusé de réception que pour un segment sur deux ou lorsque le délai imparti pour un ACK expire.
Sur une connexion TCP entre deux machines du réseau, les messages (ou paquets TCP) sont acquittés et délivrés en séquence.
UDP est un complément du protocole TCP qui
offre un service de datagrammes sans
connexion qui ne garantit ni la remise ni l'ordre des paquets
délivrés. Les sommes de contrôle des données sont facultatives dans le
protocole UDP. Ceci permet d'échanger des données sur des réseaux à
fiabilité élevée sans utiliser inutilement des ressources réseau ou du
temps de traitement. Les messages (ou paquets UDP) sont transmis de
manière autonome (sans garantie de livraison.).
Le protocole UDP prend également en charge l'envoi de données d'un unique expéditeur vers plusieurs destinataires.
Ex: TFTP(trivial FTP) s'appuie sur UDP, DHCP également, Windows utilise UDP pour les Broadcast en TCP-IP
ICMP est un protocole de
maintenance utilisé pour les tests et les diagnostics, qui
véhicule des messages de contrôle. Il permet à deux systèmes d'un réseau
IP de partager des informations d'état et d'erreur.
La commande ping utilise les paquets ICMP de demande d'écho et de réponse à un écho afin de déterminer si un système IP donné d'un réseau fonctionne. C'est pourquoi l'utilitaire ping est utilisé pour diagnostiquer les défaillances au niveau d'un réseau IP ou des routeurs.
RIP est un protocole de routage dynamique qui permet l'échange d'informations de routage sur un inter-réseau. Chaque routeur fonctionnant avec RIP échange les identificateurs des réseaux qu'il peut atteindre, ainsi que la distance qui le sépare de ce réseau (nb de sauts=nb de routeurs à traverser). Ainsi chacun dispose de la liste des réseaux et peut proposer le meilleur chemin.
Le protocole ARP permet de déterminer l'adresse physique (ou MAC) d'un noeud à partir de son adresse IP en effectuant une diffusion du type "qui est X2.X2.X2.X2 ? "
Pour désigner les informations transmises et leur enveloppe, selon le niveau concerné, on parle de message(ou de flux) entre applications, de datagramme (ou segment) au niveau TCP, de paquet au niveau IP, et enfin, de trames au niveau de l'interface réseau (Ethernet ou Token Ring).
Les protocoles du niveau application les plus connus sont :
HTTP (Hyper Text Transfer Protocol) permet l'accès aux documents HTML et le transfert de fichiers depuis un site WWW
FTP (File Transfer Protocol) pour le transfert de fichiers s'appuie sur TCP et établit une connexion sur un serveur FTP
Telnet pour la connexion à distance en émulation terminal, à un hôte Unix/Linux.
SMTP (Simple Mail Transfer Protocol) pour la messagerie électronique (UDP et TCP)
SNMP (Simple Network Management Protocol) pour l'administration du réseau
NFS (Network File System) pour le partage des fichiers Unix/Linux.
Les applications réseaux fonctionnent sur le modèle client/serveur. Sur la machine serveur un processus serveur (daemon) traite les requêtes des clients. Client et serveur dialoguent en échangeant des messages qui contiennent des requêtes et des réponses.
Prenons par exemple telnet.
Une fois le datagramme transmis à l'hôte destinataire, il doit parvenir à l'utilisateur (si le système est multi-utilisateur) et à l'application visée (si le système est multi-tâches).
sur la machine cliente, l'utilisateur (usager ou programme) effectue une requête vers une machine IP serveur sur le réseau. (par exemple telnet host ou ftp host ). Cela se traduit par la réservation d'un port de sortie TCP ou UDP et l'envoi d'un paquet IP à la machine serveur. Ce paquet contient un message TCP ou UDP avec un numéro de port correspondant à l'application demandée sur le serveur.
sur le serveur, la requête est réceptionnée par le pilote IP, aiguillée vers TCP ou UDP puis vers le port demandé. Le processus serveur correspondant est à l'écoute des appels sur ce port (par ex: le daemon telnetd traite les requêtes telnet, le daemon ftpd traite les requêtes ftp).
processus client et processus serveur échangent ensuite des messages.
Des numéros de port (entre 0 et 1023) sont réservés pour les applications « standards : les ports « bien connus » (Well Known Ports), ils ont été assignés par l'IANA. Sur la plupart des systèmes ils peuvent être seulement employés par des processus du système (ou root) ou par des programmes exécutés par les utilisateurs privilégiés (liste complète : http://www.iana.org/assignments/port-numbers ou dans le fichier /etc/services y compris sous Windows).
D'autres numéros de port sont disponibles pour les applications développées par les utilisateurs (1024 à 65535).
On identifie le protocole de communication entre applications par un numéro de protocole etl'application par un numéro de port.
Par exemple, les serveurs HTTP dialoguent de manière traditionnelle par le port 80 :
http ://www.sncf.com/index.htm <=> http :// www.sncf.com:80/index.htm
Les numéros de protocole et de port sont inclus dans le datagramme.
Une fois la connexion établie entre le client et le serveur, ceux-ci peuvent s'échanger des informations selon un protocole défini selon l'applicatif. Le client soumet des requêtes auxquelles répondra le serveur.
Ce mode de communication s'appuie sur la couche "socket". Cette couche est une interface entre la couche présentation et transport. Elle permet la mise en place du canal de communication entre le client et le serveur. On peut schématiquement dire qu'un socket fournit un ensemble de fonctions. Ces fonctions permettent à une application client/serveur d'établir un canal de communication entre 2 ou plusieurs machines, qui utilisent un protocole de transport (TCP ou UDP) et un port de communication.
Service réseau | N° de Port | Type | Commentaire |
ICMP | 7 | TCP/UDP | Commandes Ping |
Netstat | 15 | TCP/UDP | Etat du réseau |
FTP | 21 | TCP | Transfert de fichiers |
SSH | 22 | TCP/UDP | SSH Remote Login Protocol |
Telnet | 23 | TCP | Connexion via terminal réseau |
SMTP | 25 | TCP | Envoi de courrier |
DNS | 53 | TCP/UDP | Serveurs de noms de domaine |
HTTP | 80 | TCP | Serveur Web |
Pop3 | 110 | TCP | Réception de courrier |
nntp | 119 | TCP | Service de news |
ntp | 123 | UDP | Protocole temps réseau |
nbname | 137 | TCP/UDP | Service de Nom Netbios |
netbios-ssn | 139 | TCP/UDP | Service de Session Netbios |
imap | 143 | TCP/UDP | Protocole d'accès messagerie Internet |
SNMP | 161 | UDP | Administration de réseau |
Abstract
Le document présente l'adressage IP sur un réseau local et en environnement routé
Ce document sert d'introduction à l'ensemble des cours et TP sur les différents protocoles
Mots clés : Adresse physique (MAC), Adresse IP, masque, sous-réseau, sur-réseau, CIDR
Deux cartes réseaux qui communiquent s'échangent des messages (suite de bits) appelés trames (frame). Tous les postes connectés au même câble reçoivent le message, mais seul celui à qui il est destiné le lit.
Comment sait-il que cette trame lui est adressée ?
Car il reconnaît l'adresse de destination, contenue dans la trame comme étant la sienne.
Comment sait il qui lui a envoyé la trame ?
Car la trame contient aussi l'adresse de l'émetteur.
Au niveau de la couche liaison, les noeuds utilisent une adresse dite « physique » pour communiquer. L'adresse correspond à l'adresse de la carte réseau. On parle d'adresse physique, d'adresse MAC (Medium Access Control) ou d'adresse de couche 2 (référence au modèle OSI).
Cette adresse est identique pour les réseaux Ethernet, Token Ring et FDDI. Sa longueur est de 48 bits soit six octets (par exemple : 08-00-14-57-69-69) définie par le constructeur de la carte. Une adresse universelle sur 3 octets est attribuée par l'IEEE à chaque constructeur de matériel réseau. Sur les réseaux CCITT X.25, c'est la norme X.121 qui est utilisée pour les adresses physiques, qui consistent en un nombre de 14 chiffres.
L'adresse MAC identifie de manière unique un noeud dans le monde. Elle est physiquement liée au matériel (écrite sur la PROM), c'est à dire à la carte réseau.
L'adresse d'une carte réseau correspond à l'adresse d'un poste et d'un seul. Or les postes sont généralement regroupés en réseau.
Comment identifier le réseau auquel appartient le poste ?
Il faut une adresse logique qui soit indépendante de l'adresse physique.
C'est ce que propose le protocole IP et le protocole IPX.
Pourquoi identifier le réseau ?
Pour permettre à 2 postes qui ne sont pas connectés au même réseau de communiquer.
Cela est impossible avec une adresse MAC, il faut une adresse de niveau supérieur, comme nous le verrons un peu plus loin et surtout avec le routage IP.
Le message véhiculé par la trame va contenir une autre adresse destinataire dont un des objectifs sera de définir le réseau destinataire du message. On appelle le message contenu dans une trame un paquet.
Ce qu'il nous faut savoir à ce stade, c'est qu'une machine sait que le paquet n'est pas destiné au réseau si l'adresse réseau de destination est différente de la sienne, dans ce cas elle envoie le paquet à une machine spéciale (la passerelle ou routeur) dont le rôle est d'acheminer les paquets qui sortent du réseau.
Cette adresse dite logique du noeud (car elle est attribuée par logiciel à un hôte, plus précisément à une carte réseau) contenue dans le paquet est l'adresse IP, est définie indépendamment de toute topologie d'ordinateur ou de réseau. Son format reste identique quel que soit le support utilisé.
Les machines (hôtes) d'un réseau TCP/IP sont identifiées par leur adresse IP.
Toute machine sur un réseau IP a donc 2 adresses, une adresse MAC et une adresse IP.
Les processus de niveaux supérieurs utilisent toujours l'adresse IP et donc lorsqu'un processus communique avec un autre processus, il lui envoie un message dont l'adresse destinataire est une adresse IP, mais pour pouvoir atteindre la carte réseau du destinataire, il faut connaître son adresse MAC. Le rôle du protocole ARP (Adress Resolution Protocol) est d'assurer la correspondance entre l'adresse IP et l'adresse MAC.
Les réseaux connectés au réseau Internet mondial doivent obtenir un identificateur de réseau officiel auprès du bureau de l'Icann de l'Inter-NIC (Network Information Center) afin que soit garantie l'unicité des identificateurs de réseau IP sur toute la planète. Une adresse est attribuée au réseau privé dont l'administrateur en fait la demande auprès du NIC (http://www.nic.fr).
Après réception de l'identificateur de réseau, l'administrateur de réseau local doit attribuer des identificateurs d'hôte uniques aux ordinateurs connectés au réseau local. Les réseaux privés qui ne sont pas connectés à Internet peuvent parfaitement utiliser leur propre identificateur de réseau. Toutefois, l'obtention d'un identificateur de réseau valide de la part du centre InterNIC leur permet de se connecter ultérieurement à Internet sans avoir à changer les adresses des équipements en place.
Chaque noeud (interface réseau) relié à l'Internet doit posséder une adresse IP unique.
Les adresses IP sont des nombres de 32 bits qui contiennent 2 champs :
Un identificateur de réseau (NET-ID): tous les systèmes du même réseau physique doivent posséder le même identificateur de réseau, lequel doit être unique sur l'ensemble des réseaux gérés.
Un identificateur d'hôte (HOST-ID): un noeud sur un réseau TCP/IP est appelé hôte, il identifie une station de travail, un serveur, un routeur ou tout autre périphérique TCP/IP au sein du réseau.
La concaténation de ces deux champs constitue une adresse IP unique sur le réseau.
Pour éviter d'avoir à manipuler des nombres binaires trop longs, les adresses 32 bits sont divisées en 4 octets. Ce format est appelé la notation décimale pointée, cette notation consiste à découper une adresse en quatre blocs de huit bits. Chaque bloc est ensuite converti en un nombre décimal.
Chacun des octets peut être représenté par un nombre de 0 à 255.
Ex : 130.150.0.1
Exemple :
L'adresse IP 10010110110010000000101000000001 est d'abord découpée en quatre blocs :
10010110.11001000.00001010.00000001 puis, chaque bloc est converti en un nombre décimal pour obtenir finalement 150.200.10.1
= >4 nombres entiers (entre 0 et 255) séparés par des points.
= >4 octets
L'écriture avec les points est une convention, le codage en machine est binaire.
La communauté Internet a défini trois classes d'adresses appropriées à des réseaux de différentes tailles. Il y a, a priori, peu de réseaux de grande taille (classe A), il y a plus de réseaux de taille moyenne (classe B) et beaucoup de réseaux de petite taille (classe C). La taille du réseau est exprimée en nombre d'hôtes potentiellement connectés.
Le premier octet d'une adresse IP permet de déterminer la classe de cette adresse.
Les adresses disponibles (de 0.0.0.0 à 255.255.255.255) ont donc été découpées en plages réservées à plusieurs catégories de réseaux.
Pour éviter d'avoir recours aux organismes NIC à chaque connexion d'un nouveau poste, chaque société se voit attribuer une plage d'adresse pour son réseau. Le nombre d'adresses disponibles dans chaque plage dépend de la taille du réseau de la société. Les grands réseaux sont dits de classe A (IBM, Xerox , DEC, Hewlett-Packard), les réseaux de taille moyenne sont de classe B (Microsoft en fait partie !), et les autres sont de classe C.
Par exemple, l'adresse d'un poste appartenant à un réseau de classe A est donc de la forme :
0AAAAAAA.xxxxxxxx.xxxxxxxx.xxxxxxxx, avec A fixé par le NIC et x quelconque.
Exemple
IBM a obtenu l'adresse 9 (en fait, on devrait dire 9.X.X.X, mais il est plus rapide de n'utiliser que la valeur du premier octet). 9 est bien de classe A car 9d=00001001b
Cela signifie que chaque adresse IP du type 00001001.xxxxxxxx.xxxxxxxx.xxxxxxxx, avec x prenant la valeur 0 ou 1, fait partie du réseau d'IBM.
Malgré ces possibilités d'adressage, la capacité initialement prévue est insuffisante et sera mise à défaut d'ici quelques années. L'IPNG (Internet Protocol Next Generation) ou Ipv6 devrait permettre de résoudre ces difficultés en utilisant un adressage sur 16 octets noté en héxadécimal.
L'adresse IP se décompose, comme vu précédemment, en un numéro de réseau et un numéro de noeud au sein du réseau.
Afin de s'adapter aux différents besoins des utilisateurs, la taille de ces 2 champs peut varier.
On définit ainsi les 5 classes d'adresses notées A à E:
ex. : Soit l'adresse IP suivante : 142.62.149.4
142 en décimal = 100011102 en binaire
Le mot binaire commence par les bits 102 donc il s'agit d'une adresse de classe B. Ou, plus simple : 142 est compris entre 128 et 191.
S'agissant d'une adresse de classe B, les deux premiers octets (a et b) identifient le réseau. Le numéro de réseau est donc : 142.62.0.0
Les deux derniers octets (c et d) identifient l'équipement hôte sur le réseau.
Finalement, cette adresse désigne l'équipement numéro 149.4 sur le réseau 142.62.
Les adresses réservées ne peuvent désigner une machine TCP/IP sur un réseau.
L'adresse d'acheminement par défaut (route par défaut.) est de type 0.X.X.X. Tous les paquets destinés à un réseau non connu, seront dirigés vers l'interface désignée par 0.0.0.0.
NB : 0.0.0.0 est également l'adresse utilisée par une machine pour connaître son adresse IP durant une procédure d'initialisation (DHCP).
L'adresse de bouclage(loopback): l'adresse de réseau 127 n'est pas attribuée à une société, elle est utilisée comme adresse de bouclage dans tous les réseaux. Cette adresse sert à tester le fonctionnement de votre carte réseau. Un ping 127.0.0.1 doit retourner un message correct. Le paquet envoyé avec cette adresse revient à l'émetteur.
Toutes les adresses de type 127.X.X.X ne peuvent pas être utilisées pour des hôtes. La valeur de 'x' est indifférente. On utilise généralement 127.0.0.1
L'adresse de réseau est une adresse dont tous les bits d'hôte sont positionnés à 0 (ex 128.10.0.0 adresse de réseau du réseau 128.10 de classe B). Elle est utilisée pour désigner tous les postes du réseau. On utilise cette adresse dans les tables de routage.
Les noms de réseaux de type :
X.Y.Z.0 (de 192.0.0.0 à 223.255.255.0) sont dits de classe C
X.Y.0.0 (de 128.0.0.0 à 191.255.0.0) sont dits de classe B
X.0.0.0. (de 1.0.0.0 à 126.255.255.254) sont dits de classe A
L'adresse de diffusion est une adresse dont tous les bits d'hôte sont positionnés à 1 (ex : 128.10.255.255 adresse de diffusion du réseau 128 de classe B).
Elle est utilisée pour envoyer un message à tous les postes du réseau.
Les adresses "privées"
Les adresses suivantes (RFC 1918) peuvent également être librement utilisées pour monter un réseau privé :
A 10.0.0.0 255.0.0.0
B 172.16.0.0 à 172.31.255.255 255.240.0.0
C 192.168.0.0 à 192.168.255.255 255.255.0.0
Aucun paquet provenant de ces réseaux ou à destination de ces réseaux, ne sera routé sur l'Internet (ces adresses sont néanmoins « routables » sur le réseau local).
Le rôle du masque de réseau (netmask) est d'identifier précisément les bits qui concernent le N° de réseau d'une adresse (il "masque" la partie hôte de l'adresse).
Un bit à 1 dans le masque précise que le bit correspondant dans l'adresse IP fait partie du N° de réseau ; à l'inverse, un bit à 0 spécifie un bit utilisé pour coder le N° d'hôte.
Ainsi, on a un masque dit "par défaut" qui correspond à la classe de ce réseau.
Exemple: dans un réseau de classe A sans sous-réseau, le premier octet correspond à l'adresse du réseau donc le netmask commence par 11111111 suivi de zéros soit 255.0.0.0.
D'où le tableau suivant :
Classe | Netmask |
A | 255.0.0.0 |
B | 255.255.0.0 |
C | 255.255.255.0 |
Ex : Si mon adresse IP est 149.127.1.110 alors je travaille avec une adresse de classe B. Mon N° de réseau est 149.127.0.0 et mon masque 255.255.0.0.
Les avantages de la segmentation en sous-réseau sont les suivants :
Utilisation de plusieurs media (câbles, supports physiques). La connexion de tous les noeuds à un seul support de réseau peut s'avérer impossible, difficile ou coûteuse lorsque les noeuds sont trop éloignés les uns des autres ou qu'ils sont déjà connectés à un autre media.
Réduction de l'encombrement. Le trafic entre les noeuds répartis sur un réseau unique utilise la largeur de bande du réseau. Par conséquent, plus les noeuds sont nombreux, plus la largeur de bande requise est importante. La répartition des noeuds sur des réseaux séparés permet de réduire le nombre de noeuds par réseau. Si les noeuds d'un réseau de petite taille communiquent principalement avec d'autres noeuds du même réseau, l'encombrement global est réduit.
Economise les temps de calcul. Les diffusions (paquet adressé à tous) sur un réseau obligent chacun des noeuds du réseau à réagir avant de l'accepter ou de la rejeter.
Isolation d'un réseau. La division d'un grand réseau en plusieurs réseaux de taille inférieure permet de limiter l'impact d'éventuelles défaillances sur le réseau concerné. Il peut s'agir d'une erreur matérielle du réseau (une connexion
Renforcement de la sécurité. Sur un support de diffusion du réseau comme Ethernet, tous les noeuds ont accès aux paquets envoyés sur ce réseau. Si le trafic sensible n'est autorisé que sur un réseau, les autres hôtes du réseau n'y ont pas accès.
Optimisation de l'espace réservé à une adresse IP. Si un numéro de réseau de classe A ou B vous est assigné et que vous disposez de plusieurs petits réseaux physiques, vous pouvez répartir l'espace de l'adresse IP en multiples sous-réseaux IP et les assigner à des réseaux physiques spécifiques. Cette méthode permet d'éviter l'utilisation de numéros de réseau IP supplémentaires pour chaque réseau physique.
Les masques de sous-réseaux (subnet mask) permettent de segmenter un réseau en plusieurs sous-réseaux. On utilise alors une partie des bits de l'adresse d'hôte pour identifier des sous-réseaux.
L'adressage de sous-réseau permet de définir des organisations internes de réseaux qui ne sont pas visibles à l'extérieur de l'organisation. Cet adressage permet par exemple l'utilisation d'un routeur externe qui fournit alors une seule connexion Internet.
Toutes les machines appartenant à un sous-réseau possèdent le même numéro de réseau.
On utilise le même principe que pour le masque par défaut sur l'octet de la partie hôte auquel on va prendre des bits. Ainsi, le masque de sous-réseau d'une adresse de classe B commencera toujours par 255.255.xx.xx
Pour connaître l'adresse du sous-réseau auquel une machine appartient, on effectue en réalité un ET logique entre l'adresse de la machine et le masque.
Adresse : 200.100.40.33 11001000.01100100.00101000.00100001
Masque : 255.255.255.224 11111111.11111111.11111111.11100000
Opération ET 11001000.01100100.00101000.00100000
=> La machine appartient au sous-réseau : 200.100.40.32
Nous voyons dans ce deuxième exemple que nous avons pris 2 bits sur le dernier octet de notre adresse. Ces 2 bits vont nous permettre de construire plusieurs sous-réseaux:
Ex : adresse : 192.0.0.131
Masque : 255.255.255.192
Conversion de l'adresse en binaire : 11000000 00000000 00000000 10000011
Conversion du masque en binaire : 11111111 11111111 11111111 11000000
Décomposition de l'adresse (R,H) : 11000000 00000000 00000000 10000011
La machine appartient au sous-réseau 192.0.0.128 et a l'adresse 3(11 en binaire)
Pour des raisons de commodité, on préférera réserver un octet entier pour coder le numéro de sous réseau. De même la théorie ne nous oblige pas à prendre les bits contigus d'un masque, même si c'est ce que nous utiliserons en pratique.
Important : pour parer à d'éventuels problèmes de routage et d'adressage, tous les ordinateurs d'un réseau logique doivent utiliser le même masque de sous-réseau et le même identificateur de réseau.
Le nombre théorique de sous-réseaux est égal à 2^n, n étant le nombre de bits à 1 du masque, utilisés pour coder les sous-réseaux.
Exemple :
Adresse de réseau : 200.100.40.0
Masque : 255.255.255.224
224 = 11100000 donc 3 bits pour le N° de sous-réseau et 5 bits pour l'hôte.
Le nombre de sous-réseaux est donc de : 23 =8.
Remarque : la RFC 1860 (remplacée par la RFC 1878) stipulait qu'un numéro de sous réseau ne peut être composé de bits tous positionnés à zéro ou tous positionnés à un.
Autrement dit, dans notre exemple, on ne pouvait pas utiliser le sous-réseau 0 et le sous-réseau 224. Le premier nous donnant une adresse de sous-réseau équivalente à l'adresse du réseau soit 200.100.40.0. Le deuxième nous donnant une adresse de sous-réseau dont l'adresse de diffusion se confondrait avec l'adresse de diffusion du réseau. Le nombre de sous-réseaux aurait alors été de seulement : 2^3-2 =6.
Il est donc important de savoir quelle RFC est utilisée par votre matériel pour savoir si les adresses de sous-réseau composées de bits tous positionnés à zéro ou tous positionnés à un sont prises en compte ou non.
Il faut donc maintenant trouver les adresses des sous-réseaux valides en utilisant les bits à 1 du masque.
Pour l'exemple précédent, il faut utiliser les 3 premiers bits:
000 00000 = 0
001 00000 = 32
010 00000 = 64
011 00000 = 96
100 00000 = 128
101 00000 = 160
110 00000 = 192
111 00000 = 224
On constate que le pas entre 2 adresses de sous-réseau est de 32 = 25 correspondant au nombre théorique d'hôtes par sous-réseau.
Il faut mettre tous les bits de la partie hôte à 1.
Cherchons l'adresse de diffusion des sous réseaux précédents.
Avec le masque 255.255.255.224
Pour le sous-réseau 200.100.40.32
32 = 001 00000 donc l'adresse de diffusion est 001 11111 = 63.
L'adresse de diffusion complète est donc 200.100.40.63
Pour le sous-réseau 200.100.40.64 l'adresse de diffusion est 200.100.40.95
...ETC ...
Avec le masque 255.255.255.129
Pour le sous-réseau 200.100.40.1 l'adresse de diffusion est 200.100.40.127
Pour le sous-réseau 200.100.40.128 l'adresse de diffusion est 200.100.40.254
Pourquoi 254 et pas 255 car avec 255 le dernier bit serait à 1 donc on serait dans le sous-réseau 10000001 , en décimal 129.
Le nombre de postes est égal à 2n, n étant le nombre de bits à 0 du masque permettant de coder l'hôte. A ce chiffre il faut enlever 2 numéros réservés :
tous les bits à zéro qui identifie le sous-réseau lui-même.
tous les bits à 1 qui est l'adresse de diffusion pour le sous-réseau.
Exemples :
Soit le masque 255.255.255.224
224 = 11100000 donc 3 bits pour le N° de sous-réseau et 5 bits pour l'hôte
le nombre de poste est donc de : 2^5 -2 =30 postes.
De même, avec le masque non contigu 255.255.255.129 le nombre de postes sera de 2^6-2 = 62 postes
En 1992 la moitié des classes B étaient allouées, et si le rythme avait continué, au début de 1994 il n'y aurait plus eu de classe B disponible et l'Internet aurait bien pu mourir par asphyxie ! Pour éviter la diminution des identificateurs de réseau, et la saturation des routeurs (nombre de routes trop important) les autorités d'lnternet ont conçu un schéma appelé adressage de sur-réseaux ( ou super-réseaux).
L'adressage de sur-réseaux par opposition à la segmentation en sous-réseaux, emprunte des bits de l'identificateur de réseau pour les attribuer aux identificateurs d'hôtes afin d'optimiser le routage.
Par exemple, au lieu d'allouer un identificateur de réseau de classe B, dans une entreprise comportant 2000 hôtes, InterNic alloue une plage séquentielle de 8 identificateurs de réseau de classe C. Chaque identificateur de réseau de classe C gère 254 hôtes pour un total de 2 032 identificateurs d'hôte.
Alors que cette technique permet de conserver des identificateurs de réseau de classe B, elle crée un nouveau problème.
En utilisant des techniques de routage conventionnelles, les routeurs d'lnternet doivent désormais comporter huit entrées (en RAM) dans leurs tables de routage pour acheminer les paquets IP vers l'entreprise. La technique appelée CIDR (Classless Inter-Domain Routing) permet de réduire les huit entrées utilisées dans l'exemple précédent à une seule entrée correspondant à tous les identificateurs de réseau de classe C utilisés par cette entreprise.
Soit les huit identificateurs de réseau de classe C commençant par l'identificateur de réseau 220.78.168.0 et se terminant par l'identificateur de réseau 220.78.175.0, l'entrée de la table de routage des routeurs d'lnternet devient :
Identificateur de réseau | Masque de sous réseau | Masque de sous réseau (en binaire) |
220.78.168.0 | 255.255.248.0 | 11111111 11111111 11111000 00000000 |
En effet 168 en binaire donne : 10101000
et 175 donne : 10101111
la partie commune porte bien sur les 5 1ers bits
d'où le masque : 11111000
Dans l'adressage de sur-réseaux, la destination d'un paquet est déterminée en faisant un ET logique entre l'adresse IP de destination et le masque de sous-réseau de l'entrée de routage. En cas de correspondance avec l'identificateur de réseau, la route est utilisée. Cette procédure est identique à celle définie pour l'adressage de sous-réseaux.
La notation CIDR définit une convention d'écriture qui spécifie le nombre de bits utilisés pour identifier la partie réseau (les bits à 1 du masque).
Les adresses IP sont alors données sous la forme :
142.12.42.145 / 24 <=> 142.12.42.145 255.255.255.0
153.121.219.14 / 20<=> 153.121.219.14 255.255.240.0
Dans cette écriture les nombres 24 et 20 représentent le nombre de bits consacrés à la codification du réseau (et sous réseau).
Remarque : Les RFC 1518 et 1519 définissent le CIDR (Classless Inter-Domain Routing).
Table of Contents
Abstract
Présentation des principaux fichiers de configuration du réseau et des commandes d'administration système et réseau.
Ce document présente les principaux fichiers de configuration d'une machine en réseau, et les commandes d'administration réseau.
Il est composé de 6 parties:
Les fichiers de configuration réseau
La commande ifconfig
La commande arp
La commande route
La commande netstat
La commande traceroute
Le fichier hosts donne un moyen d'assurer la
résolution de noms, de donner un nom FQDN à un hôte
Exemple de fichier hosts
127.0.0.1 localhost localhost.localdomain 192.168.1.1 uranus.foo.org uranus
Il permet d'affecter un nom logique à un réseau
localnet 127.0.0.0 foo-net 192.168.1.0
Cette option permet par exemple d'adresser un réseau sur son nom, plutôt que sur son adresse.
route add
foo-net au lieu de route
add -net
192.168.1.0.
Il donne l'ordre dans lequel le processus de résolution de noms est effectué. Voici un exemple de ce que l'on peut trouver dans ce fichier :
order hosts,bind
La résolution est effectuée d'abord avec le fichier
hosts, en cas d'échec avec le
DNS.
Il permet d'affecter les serveurs de noms.
Exemple
Nameserver 192.168.1.1 Nameserver 192.168.1.2 Nameserver 192.168.1.3
Ici le fichier déclare le nom de domaine et les 3 machines chargées de la résolution de noms.
Vous trouverez ces fichiers dans /etc/network/interfaces. Voici un exemple
qui contient 3 interfaces.
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# The loopback interface
# automatically added when upgrading
auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 192.168.90.1
netmask 255.255.255.0
network 192.168.90.0
broadcast 192.168.90.255
gateway 192.168.90.1
iface eth1 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
La commande ifconfig permet la configuration locale ou à distance des interfaces réseau de tous types d'équipements (unité centrale, routeur). Sans paramètres, la commande ifconfig permet d'afficher les paramètres réseau des interfaces.
La ligne de commande est :
ifconfig .interface
adresse
[parametres]
Exemple : ifconfig (affecte l'adresse
192.168.1.2 à la première interface physique).eth0
192.168.1.2
Voici les principaux arguments utilisés :
interface logique ou physique, il est
obligatoire,
up active l'interface
down désactive l'interface
mtu définit l'unité de transfert des
paquets
netmask affecter un masque de sous-réseau
broadcast définit l'adresse de broadcast
arp ou -arp activer ou
désactiver l'utilisation du cache arp de l'interface
metric paramètre utilisé pour l'établissement des
routes dynamiques, et déterminer le “ coût ”
(nombre de sauts ou “ hops ”) d'un chemin par le
protocole RIP.
multicast active ou non la communication avec des
machines qui sont hors du réseau.
promisc ou -promisc activer ou
désactiver le mode promiscuité de l'interface. En mode
promiscuous, tous les paquets qui
transitent sur le réseau sont reçus également par l'interface. Cela
permet de mettre en place un analyseur de trame ou de protocole.
Description du résultat de la commande ifconfig
eth0 :
eth0 Link encap:Ethernet HWaddr 00:80:C8:32:C8:1E
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:864 errors:0 dropped:0 overruns:0 frame:0
TX packets:654 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
Interrupt:10 Base address:0x6100
Explications :
Ligne 1: l'interface est de type Ethernet. La commande nous donne l'adresse MAC de l'interface.
Ligne 2 : on a l'adresse IP celle de broadcast, celle du masque de sous-réseau
Ligne 3 : l'interface est active (UP), les modes broadcast et multicast le sont également, le MTU est de 1500 octets, le Metric de 1
Ligne 4 et 5 : RX (paquets reçus), TX (transmis), erreurs, suppressions, engorgements, collision
Mode d'utilisation :
Ce paragraphe décrit une suite de manipulation de la commande ifconfig.
Ouvrez une session en mode console sur une machine.
1 - Relevez les paramètres de votre machine à l'aide de la commande ifconfig. Si votre machine n'a qu'une interface physique, vous devriez avoir quelque chose d'équivalent à cela.
Lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 RX packets:146 errors:0 dropped:0 overruns:0 frame:0 TX packets:146 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 eth0 Link encap:Ethernet HWaddr 00:80:C8:32:C8:1E inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:864 errors:0 dropped:0 overruns:0 frame:0 TX packets:654 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Interrupt:10 Base address:0x6100
2 - Désactivez les 2 interfaces lo et eth0
ifconfig lo
down
ifconfig eth0
down
3 - Tapez les commandes suivantes :
ping
localhost
ping
192.168.1.1
telnet
localhost
Aucune commande ne fonctionne, car même si la configuration IP est correcte, les interfaces sont désactivées.
4 - Activez l'interface de loopback et tapez les commandes suivantes :
ifconfig /* activation de l'interface
de loopback */lo
up
ping
ou telnet
localhost /* ça ne marche toujours pas */localhost
route add
/* on ajoute
une route sur l'interface de loopback */127.0.0.1
ping
ou
localhosttelnet
/* maintenant
ça marche */localhost
ping
/* ça ne
marche pas car il manque encore une route*/192.168.1.1
On peut déduire que :
pour chaque interface il faudra indiquer une route au protocole.
dans la configuration actuelle, aucun paquet ne va jusqu'à la carte, donc ne sort sur le réseau.
Voici le rôle de l'interface loopback. Elle permet de tester un programme utilisant le protocole IP sans envoyer de paquets sur le réseau. Si vous voulez écrire une application réseau, (telnet, ftp, ou autre), vous pouvez la tester de cette façon.
5 - Activez l'interface eth0 et tapez les commandes suivantes :
ifconfig /* activation de l'interface
*/eth0
up
route add
192.168.1.1
ifconfig /*
l'information Tx/Rx de l'interface eth0 vaut 0 */
/* Aucun paquet n'est encore passé par la carte.*/
ping
127.0.0.1
ifconfig /* on voit que
l'information Tx/Rx de lo est modifiée */
/* pas celle de eth0, on en déduit que les paquets */
/* à destination de lo ne descendent pas jusqu'à l'interface physique */
ping
/* test
d'une adresse locale */192.168.1.1
ifconfig /* Ici on peut
faire la même remarque. Les paquets ICMP */
/* sur une interface locale, ne sortent pas sur le réseau */
/* mais ceux de l'interface lo sont modifiés*/
ping
/* test
d'une adresse distante */192.168.1.2
ifconfig /* Ici les
paquets sont bien sortis. Les registres TX/RX de eth0 */
/* sont modifiés, mais pas ceux de lo */
6 -Réalisez les manipulations suivantes, nous allons voir le comportement de la commande ping sur les interfaces.
Sur la machine tapez la commande
192.168.1.1 ifconfig /* relevez les valeurs des registres TX/RX */
192.168.1.2 ping 192.168.1.1
192.168.1.1 ifconfig /* relevez les nouvelles valeurs des registres TX/RX */
/* il y a bien eu échange Réception et envoi de paquets*/
192.168.1.2 ping 192.168.1.3
192.168.1.1 ifconfig /* On voit que le registre Rx est modifié mais */
/* le registre Tx n'est pas modifié. La machine a bien reçu*/
/* le paquet mais n'a rien renvoyé */
192.168.1.2 ping 192.168.1.2
192.168.1.2 ifconfig /* aucun registre n'est modifié, donc les paquets */
/* ne circulent pas jusqu'à l'interface physique avec un ping*/
/* sur l'interface locale */
7 - le MTU (Message Transfert Unit) détermine l'unité de transfert des paquets.
Vous allez, sur la machine 192.168.1.1 modifier le MTU par défaut à 1500, pour le mettre à 300, avec la commande :
ifconfig eth0 mtu
300
Sur la machine d'adresse 192.168.1.2, vous allez ouvrir une session ftp et chronométrer le temps de transfert d'un fichier de 30 MO. Relevez le temps et le nombre de paquets transmis ou reçus (commande ifconfig, flags TX/RX).
Restaurez le paramètre par défaut sur la première machine.
Refaites le même transfert et comparez les chiffres. La différence n'est pas énorme sur le temps car le volume de données est peu important. Par contre la différence sur le nombre de paquets, elle, est importante.
Description de la commande
La commande arp permet de visualiser ou modifier la table du cache arp de l'interface. Cette table peut être statique et (ou) dynamique. Elle donne la correspondance entre une adresse IP et une adresse MAC (Ethernet).
A chaque nouvelle requête, le cache ARP de l'interface est mis à jour. Il y a un nouvel enregistrement. Cet enregistrement à une durée de vie (ttl ou Time To Live).
Voici un exemple de cache ARP obtenu avec la
commande arp -va :
? (192.168.1.2) at 00:40:33:2D:B5:DD [ether] on eth0 >Entries: 1 Skipped: 0 Found: 1
On voit l'adresse IP et l'adresse MAC correspondante. Il n'y a qu'une entrée dans la table. Voici les principales options de la commande arp :
arp -s (ajouter une entrée
statique), exemple : arp -s
192.168.1.2
00:40:33:2D:B5:DD
arp -d (supprimer une entrée),
exemple : arp -d
192.168.1.2
Voir la page man pour les autres options.
La table ARP et le fonctionnement du cache ARP.
Cela est réalisé par la configuration de tables ARP statiques.
Mode d'utilisation :
Attention à certaines interprétations de ce paragraphe. Il dépend de votre configuration. Soit vous êtes en réseau local avec une plage d'adresse déclarée, soit vous utilisez une carte d'accès distant.
Première partie :
Affichez le contenu de la table ARP avec
la commande arp
,-a
Supprimez chaque ligne avec la commande
arp , où
-d
@ip@ip est l'adresse IP
de chaque hôte apparaissant dans la table,
La commande arp -a ne
devrait plus afficher de ligne,
Faites un ping, sur une station du réseau local,
arp -a, affiche la
nouvelle entrée de la table,
Ouvrez une session sur Internet, puis ouvrez une session ftp
anonyme sur un serveur distant en utilisant le nom, par exemple
ftp.cdrom.com. Utilisez une adresse que vous
n'avez jamais utilisée, supprimez également tout gestionnaire de
cache.
Affichez le nouveau contenu de la table avec
arp .
Le cache ARP ne contient pas l'adresse Ethernet
du site distant, mais celle de la passerelle par défaut. Cela
signifie que le client n'a pas à connaître les adresses Ethernet
des hôtes étrangers au réseau local, mais uniquement l'adresse de
la passerelle. Les paquets sont ensuite pris en charge par les
routeurs.-a
Refaites une tentative sur le site choisi précédemment. Le temps d'ouverture de session est normalement plus court. Cela est justifié, car les serveurs de noms ont maintenant dans leur cache la correspondance entre le nom et l'adresse IP.
Deuxième partie :
La commande arp permet de diagnostiquer un dysfonctionnement quand une machine prend l'adresse IP d'une autre machine.
Sur la machine 192.168.1.1, faites un ping sur 2 hôtes du réseau 192.168.1.2 et 192.168.1.3,
A l'aide de la commande arp, relevez les adresses MAC de ces noeuds,
Modifiez l'adresse IP de la machine 192.168.1.2 en 192.168.1.3
relancez les 2 machines en vous arrangeant pour que la machine dont vous avez modifié l'adresse ait redémarré la première,
Sur la machine d'adresse 192.168.1.1, remettez à jour les tables ARP.
Quel est le contenu, après cela de la table ARP ?
Conclusion : vous allez avoir un conflit d'adresses. Vous allez pouvoir le détecter avec la commande arp. Autre problème, si vous faites un telnet sur 192.168.1.3, il y a de fortes chances pour que ce soit la machine qui était d'adresse 192.168.1.2, qui vous ouvre la session. Nous sommes (par une action volontaire bien sûr) arrivés à mettre la pagaille sur un réseau de 3 postes. Cette pagaille pourrait tourner vite au chaos sur un grand réseau, d'où la nécessité pour un administrateur de faire preuve d'une grande rigueur.
Où en suis-je ?
Exercice 1 :
Vous êtes sur un réseau d'adresse 192.168.1.0 avec une interface d'adresse MAC 00:40:33:2D:B5:DD,
Vous n'avez aucun fichier host sur votre machine,
Il n'y a pas de DNS
La passerelle par défaut est 192.168.1.9
Vous faites un ping
qui a une
interface d'adresse MAC 00:45:2D:33:C2 est localisée
sur Internet195.6.2.3
Le réseau fonctionne parfaitement et tout est parfaitement configuré
Cochez la bonne réponse:
A - On a dans la table arp ? (192.168.1.2) at 00:40:33:2D:B5:DD [ether] on eth0
B - On a dans la table arp ? (192.168.1.2) at 00:45:2D:33:C2 [ether] on eth0
C - On a dans la table arp ? (195.6.2.3) at 00:40:33:2D:B5:DD [ether] on eth0
D - On a dans la table arp ? (195.6.2.3) at 00: 00:45:2D:33:C2 [ether] on eth0
E - Il faut un fichier host, ou
DNS pour réaliser l'opération ping
demandée
F - Il n'est pas possible dans la configuration actuelle d'atteindre l'hôte 195.6.2.3
Réponse F, car la plage d'adresse 192.168.1.1 à 192.168.1.254 n'est pas routée sur l'Internet, sinon vous auriez l'adresse de la passerelle par défaut dans le cache ARP.
Exercice 2 :
Vous êtes sur un réseau d'adresse 192.5.1.0 avec une interface d'adresse MAC 00:40:33:2D:B5:DD,
Vous n'avez aucun fichier host sur votre machine,
Il n'y a pas de DNS,
La passerelle par défaut est 192.5.1.9
Vous faites un ping
dont
l'adresse IP est 195.6.2.3, et qui a une interface
d'adresse MAC 00:45:2D:33:C2www.existe.org
Le réseau fonctionne parfaitement et tout est parfaitement configuré
Cochez la bonne réponse:
A - On a dans la table arp ? (192.5.1.0) at 00:40:33:2D:B5:DD [ether] on eth0
B - On a dans la table arp ? (192.5.1.0) at 00:45:2D:33:C2 [ether] on eth0
C - On a dans la table arp ? (195.6.2.3) at 00:40:33:2D:B5:DD [ether] on eth0
D - On a dans la table arp ? (195.6.2.3) at 00: 00:45:2D:33:C2 [ether] on eth0
E - Il faut un fichier host, ou
DNS pour réaliser l'opération ping
demandée
F - Il n'est pas possible dans la configuration actuelle d'atteindre l'hôte 195.6.2.3
Réponse E, car la résolution de noms ne peut être effectuée
Exercice 3 :
Vous êtes sur un réseau d'adresse 192.5.1.0, sur une machine d'adresse 192.5.1.1, et une interface d'adresse MAC 00:40:33:2D:B5:DD,
Vous n'avez aucun fichier host sur votre
machine,
Il n'y a pas de DNS
La passerelle par défaut est 192.5.1.9, d'adresse MAC 09:44:3C:DA:3C:04
Vous faites un ping
, et qui a une
interface d'adresse MAC 00:45:2D:33:C2195.6.2.3
Le réseau fonctionne parfaitement et tout est parfaitement configuré
Cochez la bonne réponse:
A - On a dans la table arp ? (192.5.1.0) at 00:40:33:2D:B5:DD [ether] on eth0
B - On a dans la table arp ? (192.5.1.0) at 00:45:2D:33:C2 [ether] on eth0
C - On a dans la table arp ? (195.6.2.3) at 00:40:33:2D:B5:DD [ether] on eth0
D - On a dans la table arp ? (192.5.1.9) at 09:44:3C:DA:3C:04 [ether] on eth0
E - Il faut un fichier host, ou
DNS pour réaliser l'opération ping
demandée
F - Il n'est pas possible dans la configuration actuelle d'atteindre l'hôte 195.6.2.3
Réponse D, l'hôte a bien été trouvé, la table ARP a été mise à jour avec l'adresse IP de la passerelle par défaut et son adresse Ethernet.
La commande route a déjà été entrevue un peu plus haut, avec la commande ifconfig. Le routage définit le chemin emprunté par les paquets entre son point de départ et son point d'arrivée. Cette commande permet également la configuration de pc, de switchs de routeurs.
Il existe 2 types de routages :
- le routage statique
- le routage dynamique.
Le routage statique consiste à imposer aux paquets la route à suivre.
Le routage dynamique met en oeuvre des algorithmes, qui permettent aux routeurs d'ajuster les tables de routage en fonction de leur connaissance de la topologie du réseau. Cette actualisation est réalisée par la réception des messages reçus des noeuds (routeurs) adjacents.
Le routage dynamique permet d'avoir des routes toujours optimisées, en fonction de l'état du réseau (nouveaux routeurs, engorgements, pannes).
On combine en général le routage statique sur les réseaux locaux au routage dynamique sur les réseaux importants ou étendus.
Un administrateur qui dispose par exemple de 2 routeurs sur un réseau, peut équilibrer la charge en répartissant un partie du flux sur un port avec une route, et une autre partie sur le deuxième routeur.
Exemple de table de routage :
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 2 eth0 127.0.0.0 * 255.0.0.0 U 0 0 2 lo default 192.168.1.9 0.0.0.0 UG 0 0 10 eth0
Commentaire généraux :
Destination : adresse de destination de la route
Gateway : adresse IP de la passerelle pour atteindre la route, * sinon
Genmask : masque à utiliser.
Flags : indicateur d'état (U - Up, H - Host - G - Gateway, D - Dynamic, M - Modified)
Metric : coût métrique de la route (0 par défaut)
Ref : nombre de routes qui dépendent de celle-ci
Use : nombre d'utilisation dans la table de routage
Iface : interface eth0, eth1, lo
Commentaire sur la 3ème ligne :
Cette ligne signifie que pour atteindre tous les réseaux inconnus, la route par défaut porte l'adresse 192.168.1.9. C'est la passerelle par défaut, d'où le sigle UG, G pour gateway.
Ajout ou suppression d'une route :
route add [net | host] addr [gw passerelle]
[métric coût] [ netmask masque] [dev
interface]
- net ou
host indique l'adresse de réseau ou de
l'hôte pour lequel on établit une route,
- adresse de destination,
- adresse de la passerelle,
- valeur métrique de la route,
- masque de la route à ajouter,
- interface réseau à qui on associe la route.
Exemples :
route add 127.0.0.1
lo /* ajoute une route pour l'adresse 127.0.0.1
sur l'interface lo */
route add -net 192.168.2.0
eth0 /* ajoute une route pour le réseau
192.168.2.0 sur l'interface eth0 */
route add
saturne.foo.org /* ajoute une route
pour la machine machin sur l'interface eth0 */
route add default gw
ariane /* ajoute ariane comme route
par défaut pour la machine locale */
/* ariane est le nom d'hôte d'un routeur ou d'une passerelle */
/* gw est un mot réservé */
route add
duschmoll netmask
255.255.255.192
/* Encore un qui a créé des sous réseaux., Il s'agit ici d'une classe C */
/* avec 2 sous réseaux, il faut indiquer le masque. */
Suppression d'une route :
route del -net
192.168.1.0
route del -net
toutbet-net
Attention, si on utilise des noms de réseau ou des noms d'hôtes,
il faut qu'à ces noms soient associés les adresses de réseau ou des
adresses IP dans le fichier
/etc/networks pour les réseaux, et
/etc/hosts ou DNS pour les
noms d'hôtes.
Vous pouvez également voir l'atelier sur la mise en place d'un routeur logiciel.
Petite étude de cas :
Première partie - réalisation d'une maquette
On dispose de 2 réseaux (A et B) reliés par une passerelle. Le réseau A est également relié à Internet par un routeur. Le réseau A dispose d'un serveur de noms. Chaque réseau a deux machines.
Réseau Nom du réseau Machine Nom des machines
A metaux-net 192.3.2.2 platine
192.3.2.3 uranium
192.3.2.4 mercure(serveur de noms)
B roches-net 130.2.0.2 quartz
130.2.0.3 silex
La passerelle entre le réseau A et B a 2 interfaces :
- eth0 192.3.2.1
- eth1 130.2.0.1
Le réseau A, a une passerelle par défaut pour Internet 130.2.0.9, qui est l'interface d'un autre routeur.
On veut :
- que les stations de chaque réseau puissent accéder à Internet,
- que les stations de chaque réseau puissent communiquer entre-elles,
- que les stations du réseau B, utilisent le serveur de noms le moins possible.
On demande :
1 - d'expliquer comment seront configurés les postes du réseau B,
2 - de donner la configuration des fichiers suivants pour chaque
machine (hosts, resolv.conf,
fichier de configuration de carte).
3 - de donner la liste des routes à mettre :
- sur les postes du réseau B,
- sur les postes du réseau A,
- sur la passerelle qui relie les 2 réseaux,
- sur le routeur du réseau A.
La commande netstat, permet de tester la configuration du réseau, visualiser l'état des connexions, établir des statistiques, notamment pour surveiller les serveurs.
Liste des paramètres utilisables avec netstat :
Sans argument, donne l'état des connexions,
-a afficher toutes les informations sur
l'état des connexions,
-i affichage des statistiques,
-c rafraîchissement périodique de l'état du
réseau,
-n affichage des informations en mode
numérique sur l'état des connexions,
-r affichage des tables de routage,
-t informations sur les sockets
TCP
-u informations sur les sockets
UDP.
Etat des connexions réseau avec netstat, dont voici un exemple :
Proto Recv-Q Send-Q Local Address Foreign Address State Tcp 0 126 uranus.planete.n:telnet 192.168.1.2:1037 ESTABLISHED Udp 0 0 uranus.plan:netbios-dgm *:* Udp 0 0 uranus.plane:netbios-ns *:* Active UNIX domain sockets (w/o servers) Proto RefCnt Flags Type State I-Node Path unix 2 [ ] STREAM 1990 /dev/log unix 2 [ ] STREAM CONNECTED 1989 unix 1 [ ] DGRAM 1955
Explications sur la première partie qui affiche l'état des connexions :
Proto : Protocole utilisé
Recv-q : nbre de bits en réception pour ce socket
Send-q : nbre de bits envoyés
LocalAdress : nom d'hôte local et port
ForeignAdress : nom d'hôte distant et port
State : état de la connexion
Le champ state peut prendre les valeurs suivantes:
Established : connexion établie
Syn snet : le socket essaie de se connecter
Syn recv : le socket a été fermé
Fin wait2 : la connexion a été fermée
Closed : le socket n'est pas utilisé
Close wait : l'hôte distant a fermé la connexion; Fermeture locale en attente.
Last ack : attente de confirmation de la fermeture de la connexion distante
Listen : écoute en attendant une connexion externe.
Unknown : état du socket inconnu
Explications sur la deuxième partie qui affiche l'état des sockets (IPC - Inter Processus Communication) actifs :
Proto : Protocole, en général UNIX,
Refcnt : Nombre de processus associés au socket
Type : Mode d'accès datagramme (DGRAM), flux orienté connexion (STREAM), brut (RAW), livraison fiable des messages (RDM)
State : Free, Listening, Unconnected, connecting, disconnecting, unknown
Path : Chemin utilisé par les processus pour utiliser le socket.
Affichage et état des tables de routage avec
netstat : netstat -nr ou
netstat -r
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 * 255.255.255.0 U 1500 0 0 eth0 127.0.0.0 * 255.0.0.0 U 3584 0 0 lo
Explications sur la commande netstat
-r
Destination : adresse vers laquelle sont destinés les paquets
Gateway : passerelle utilisée, * sinon
Flags : G la route utilise une passerelle, U l'interface est active, H on ne peut joindre qu'un simple hôte par cette route)
Iface : interface sur laquelle est positionnée la route.
Affichage de statistiques avec netstat
-i
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags Lo 3584 0 89 0 0 0 89 0 0 0 BLRU eth0 1500 0 215 0 0 0 210 0 0 0 BRU
Explications sur la commande netstat
-i
RX-OK et TX-OK rendent compte du nombre de paquets reçus ou émis,
RX-ERR ou TX-ERR nombre de paquets reçus ou transmis avec erreur,
RX-DRP ou TX-DRP nombre de paquets éliminés,
RX-OVR ou TX-OVR recouvrement, donc perdus à cause d'un débit trop important.
Les Flags (B adresse de diffusion, L interface de loopback, M tous les paquets sont reçus, O arp est hors service, P connexion point à point, R interface en fonctionnement, U interface en service)
Exercices :
On donne les résultats de 3 commandes netstat ci-dessous, extraites de la même machine :
$ netstat
-nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
198.5.203.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo
0.0.0.0 198.5.203.3 0.0.0.0 UG 1500 0 0 eth0
$
netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
Tcp 0 127 uranus.toutbet:telnet 194.206.6.143:1027 ESTABLISHED
$ netstat
-i
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags
Lo 3584 0 764 0 0 764 89 0 0 0 BLRU
eth0 1500 0 410856 0 0 33286 210 0 0 0 BRU
On demande :
Quels sont les noms et adresse de la machine consultée ?
Quel type de session est-elle en train de supporter ?
A quoi correspond l'adresse 198.5.203.3?
Pourquoi une interface porte-t-elle les Flags BLRU et l'autre BRU ?
Quelle est la taille des paquets utilisée par la passerelle par défaut ?
La commande traceroute permet d'afficher le chemin parcouru par un paquet pour arriver à destination. Cette commande est importante, car elle permet d'équilibrer la charge d'un réseau, en optimisant les routes.
Voici le résultat de la commande traceroute
www.nat.fr, tapée depuis ma
machine.
traceroute to sancy.nat.fr (212.208.83.2), 30 hops max, 40 byte packets 1 195.5.203.9 (195.5.203.9) 1.363 ms 1.259 ms 1.270 ms 2 194.79.184.33 (194.79.184.33) 25.078 ms 25.120 ms 25.085 ms 3 194.79.128.21 (194.79.128.21) 88.915 ms 101.191 ms 88.571 ms 4 cisco-eth0.frontal-gw.internext.fr (194.79.190.126) 124.796 ms[] 5 sfinx-paris.remote-gw.internext.fr (194.79.190.250) 100.180 ms[] 6 Internetway.gix-paris.ft.NET (194.68.129.236) 98.471 ms [] 7 513.HSSI0-513.BACK1.PAR1.inetway.NET (194.98.1.214) 137.196 ms[] 8 602.HSSI6-602.BACK1.NAN1.inetway.NET (194.98.1.194) 101.129 ms[] 9 FE6-0.BORD1.NAN1.inetway.NET (194.53.76.228) 105.110 ms [] 10 194.98.81.21 (194.98.81.21) 175.933 ms 152.779 ms 128.618 ms[] 11 sancy.nat.fr (212.208.83.2) 211.387 ms 162.559 ms 151.385 ms[]
Explications :
Ligne 0 : le programme signale qu'il n'affichera que les 30
premiers sauts, et que la machine www du domaine nat.fr, porte le nom
effectif de sancy, dans la base d'annuaire du
DNS du domaine nat.fr. Cette machine porte l'adresse
IP 212.208.83.2. Pour chaque tronçon, on a également
le temps maximum, moyen et minimum de parcours du tronçon.
Ensuite, on a pour chaque ligne, l'adresse du routeur que le paquet a traversé pour passer sur le réseau suivant.
Ligne 4 et 5, le paquet a traversé 2 routeurs sur le même réseau 194.79.190.
Ligne 4, 5, 6, 7, 8, 9, 11, on voit que les routeurs ont un enregistrement de type A dans les serveurs de noms, puisqu'on voit les noms affichés.
Conclusion : depuis ma machine, chaque requête HTTP passe par 11 routeurs pour accéder au serveur www.nat.fr.
L'accès sur cet exemple est réalisé sur Internet. Un administrateur, responsable d'un réseau d'entreprise sur lequel il y a de nombreux routeurs, peut, avec cet outil, diagnostiquer les routes et temps de routage. Il peut ainsi optimiser les trajets et temps de réponse.
La commande dig remplace ce qui était la commande nslookup. Cette commande sert à diagnostiquer des dysfonctionnements dans la résolution de noms (Service DNS).
Utilisation simple de dig :
$ dig any freenix.org
; <<>> DiG 9.2.2 <<>> any freenix.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21163
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;freenix.org. IN ANY
;; ANSWER SECTION:
freenix.org. 92341 IN SOA ns2.freenix.org.\
hostmaster.freenix.org.\
2003042501\
21600\
7200\
3600000\
259200\
freenix.org. 117930 IN NS ns2.freenix.fr.
freenix.org. 117930 IN NS ns.frmug.org.
freenix.org. 117930 IN NS ns6.gandi.net.
;; AUTHORITY SECTION:
freenix.org. 117930 IN NS ns2.freenix.fr.
freenix.org. 117930 IN NS ns.frmug.org.
freenix.org. 117930 IN NS ns6.gandi.net.
;; ADDITIONAL SECTION:
ns2.freenix.fr. 16778 IN A 194.117.194.82
ns.frmug.org. 40974 IN A 193.56.58.113
ns6.gandi.net. 259119 IN A 80.67.173.196
;; Query time: 197 msec
;; SERVER: 213.36.80.1#53(213.36.80.1)
;; WHEN: Tue May 27 15:16:23 2003
;; MSG SIZE rcvd: 248
retourne les informations sur le domaine concerné.
Il est ensuite possible d'intérroger sur tout type d'enregistrement : SOA, MX, A, CNAME, PTR...
Table of Contents
Abstract
Résumé sur ARP - RFC 826
Chaque carte réseau possède une adresse physique MAC unique sur 48
bits (6 octets) . La communication entre machines ne peut donc avoir lieu
que lorsque celles-ci connaissent leurs adresses MAC. Pour envoyer les
paquets IP vers les autres noeuds du réseau, les noeuds qui utilisent les
protocoles TCP/IP traduisent les adresses IP de
destination en adresses MAC. Ainsi, lorsqu'un noeud
N1 du réseau TCP/IP X1.X1.X1.X1 veut
émettre un paquet TCP/IP (dans une trame Ethernet) vers
une machine N2 d'adresse IP
(X2.X2.X2.X2), il faut qu'il connaisse l'adresse Ethernet de
N2 (E2.E2.E2.E2.E2.E2). L'application émettrice ajoute
son adresse IP au paquet et l'application réceptrice peut utiliser cette
adresse IP pour répondre.
Sur les réseaux à diffusion, tels qu'Ethernet et Token-Ring, le protocole IP nommé ARP (Address Resolution Protocol) fait le lien entre les adresses IP et les adresses physiques (ou MAC).
Pour réaliser l'association @ip / @ Ethernet
l'émetteur N1 utilise le protocole
ARP dont le principe est le suivant :
L'émetteur envoie une trame Ethernet de diffusion (broadcast), c'est-à-dire où @destinataire : tous à 1 soit FFFFFFFFFFFF contenant un message ARP demandant
qui est X2.X2.X2.X2 ?
Toutes les machines IP du réseau local reçoivent
la requête. N2 qui a l'adresse X2.X2.X2.X2 se
reconnaît, et elle répond à N1 ie X1.X1.X1.X1 (dans une
trame destinée à E1.E1.E1.E1.E1.E1)
Pour accélérer la transmission des paquets et réduire le nombre de requêtes de diffusion ARP, chaque noeud dispose d'un cache ARP de résolution d'adresse. Chaque fois que le noeud diffuse une requête ARP et reçoit une réponse, il crée une entrée dans une table de correspondance stockée en mémoire cache (@ip / @ Ethernet).
Lorsque le noeud envoie un autre paquet IP, il cherche d'abord l'adresse IP dans son cache. S'il la trouve, il utilise alors l'adresse physique correspondante pour son paquet.
Quand un poste cherche l'adresse physique correspondant à une adresse IP qu'il connaît, le protocole ARP se met en oeuvre et réalise donc les tâches suivantes :
recherche dans le cache ARP de la machine si l'adresse IP du destinataire y figure, s'il la trouve, il ajoute alors l'adresse physique correspondante dans l'en-tête de la trame à émettre.
réalisation d'un broadcast (ARP request) sur le réseau en demandant à qui correspond l'adresse IP à résoudre : il diffuse un paquet ARP qui contient l'adresse IP du destinataire
les machines du réseau comparent l'adresse demandée à leur adresse et le noeud correspondant renvoie son adresse physique au noeud qui a émis la requête (ARP reply) .
stockage de l'adresse physique lorsque le destinataire répond dans le cache ARP de la machine
Remarque : chaque entrée de la table à une durée de vie limitée (2 minutes mini sous Windows).
Voici pour exemple ce que donne le programme
tcpdump avec la commande ping
192.168.1.2 à partir de la machine
uranus alors que la table ARP de
l'hôte uranus est vide :
13:17:14.490500 arp who-has 192.168.1.2 tell uranus.planete.net 13:17:14.490500 arp reply 192.168.1.2 is-at 0:40:33:2d:b5:dd 13:17:14.490500 uranus.planete.net > 192.168.1.2: icmp: echo request 13:17:14.490500 192.168.1.2 > uranus.planete.net: icmp: echo reply 13:17:15.500500 uranus.planete.net > 192.168.1.2: icmp: echo request 13:17:15.500500 192.168.1.2 > uranus.planete.net: icmp: echo reply
Explications :
Ligne 1, uranus demande qui est 192.168.1.2
(requête ARP) Le paquet est diffusé à tous les hôtes du
réseau.
Ligne 2 réponse ARP : je suis à l'adresse Ethernet 00:40:33:2d:b5:dd
Lignes 3 à 6 : échanges de paquets ICMP entre les 2 hôtes.
Table of Contents
Conditions de réalisation
Ce TP nécessite des machines Windows ou Linux reliées par un réseau Ethernet et TCP/IP, et disposant d'un routeur connecté à internet. L'adresse du réseau utilisé par ce TP est 10.69.0.0, mais peut être modifiée sans problème. Il faut disposer d'un analyseur de trames, les exemples utilisent Ethereal (http://www.ethereal.com/).
Ces tests peuvent être réalisés à partir d'un poste de travail Linux ou Windows
à partir de votre poste, ouvrez une fenêtre d'invite de commandes
quelle commande utilisez-vous pour afficher les informations concernant votre carte réseau ?
testez l'adresse IP de loopback pour vérifier que les liaisons définies par TCP/IP sont correctes : ping 127.0.0.1
testez avec l'adresse IP de votre poste
testez avec l'adresse du poste d'un voisin
testez avec l'adresse du réseau : 10.69.0.0 (notez le résultat)
Que signifient les réponses ?
testez avec l'adresse de broadcast sur ce réseau : 10.69.255.255 (notez le résultat)
Que signifient les réponses ?
testez une adresse IP non utilisée sur le réseau par exemple 10.69.0.99 (idem)
Que peut-on déduire de la réponse ? Le poste existe t-il ? Le poste n'est pas actif ?
testez l'adresse de la passerelle : 10.69.0.254
testez une adresse existante au delà de votre passerelle : 192.168.0.n (idem)
Comment expliquez vous votre résultat ? Pourquoi ce poste répond-il alors que son adresse réseau est différente de la vôtre ?
testez une adresse au hasard ne faisant pas partie du réseau : 200.110.20.37 (idem)
Que pouvez vous déduire du résultat ?
2 stations pour dialoguer doivent utiliser les adresses MAC, il faut donc un moyen pour passer de l'adresse IP à l'adresse MAC et vice versa. IP fournit pour cela le protocole ARP (Adress Resolution Protocol) et RARP (Reverse Adress Resolution Protocol)
Affichez le cache ARP : tapez la commande arp -aàl'invite de commandes
Notez le résultat
faites un ping sur une autre station
Affichez de nouveau le cache arp (notez le résultat)
Que contient le cache ARP à l'issue du PING ?
faites un ping sur l'adresse interne de votre passerelle internet (192.168.0.254)
affichez le cache arp (notez le résultat)
Que contient le cache ? Expliquez le résultat. Cela confirme-t-il vos hypothèses précédentes (question 1) ?
Décrivez les entrées du cache ARP
Utilisez les commandes pour obtenir de l'aide sur la commande arp : arp /? ou arp --help et man arp sous Liniux
videz le cache arp (notez l'instruction qu'il faut utiliser)
Sous Linux reprenez les opérations du paragraphe précédent, afin de mettre des informations en cache. Pour vider le cache vous utiliserez les instructions suivantes :
ifconfig eth0 down
arp -a /* vous constaterez qu'il n'y a plus rien en cache */
ifconfig eth0 up
A l'aide de la commande « man ifconfig », expliquez ce que font les commandes ifconfig eth0 down et ifconfig eth0 up.
Reprenons les manipulations une fois le cache vidé
notez l'adresse ethernet du poste voisin
ajoutez manuellement cette entrée arp dans la cache (donnez l'instruction qu'il faut passer)
affichez votre cache arp pour vérifier.
Quel est le type de l'entrée ?
testez cette entrée avec ping
Quelles sont les différentes possibilités de la commande ARP ?
utiliser la commande arp permettant de modifier l'adresse matérielle de la passerelle par défaut (donnez l'instruction qu'il faut utiliser)
(donnez lui par exemple 08-00-02-22-22-20 qui est une fausse adresse)
faites un ping sur votre passerelle (notez le résultat)
expliquez-le
faites un ping au delà de votre passerelle (notez le résultat)
expliquez-le
supprimez cette entrée incorrecte
quelle est l'instruction ?
Lancer ethereal et au besoin sélectionnez la
carte réseau sur laquelle vous souhaitez capturer le trafic (vérifiez
son adresse Mac)
Démarrer la capture : Capture/Start,activez le rafraîchissement temps réel et OK
générer du trafic réseau
- ouvrez une fenêtre d'invite de commande xterm
- faites un ping sur l'adresse ip de votre voisin
arrêter la capture des données réseau. Revenez au moniteur réseau « stop »
Analyser les données capturées
Le moniteur réseau vous affiche trois fenêtres.
Décrivez les types d'informations que vous obtenez dans chacune de ces fenêtres.
Mettre en évidence des données capturées
Menu Display/Colorize Display.
Ajouter une option name : NomName, filter : icmp
Choisissez les couleurs de fond et de texte et validez.
Afficher le détail des trames ICMP
dans la première fenêtre sélectionnez une trame ICMP dont la colonne de description contient l'entrée « REQUEST ».
dans la fenêtre de détails, cliquez sur le signe + devant ICMP (le contenu du paquet ICMP est mis en évidence et affiché selon la notation hexadécimale dans la fenêtre du bas)
dans la fenêtre détail, cliquez sur ICMP: Packet type = request
Quel nombre hexadécimal correspond à ICMP: packet type =request ?
cliquez sur identifier (notez sa valeur)
cliquez sur sequence number (notez sa valeur)
cliquez sur data
Les données reçues dans le message d'écho ( echo-request)doivent être renvoyées dans le message de réponse d'écho ( echo-reply).
Vérifiez-le.
dans le menu affichage, cliquez sur cherchez la trame suivante qui doit être une trame reply
sur la trame suivante notez le packet type, l'identifier et lesequence number comparez avec les valeurs précédentes, qu'en déduisez-vous ?
enregistrer la capture à des fins d'analyse ultérieure (File / Save As)
pour imprimer (File / Print)
démarrez une capture réseau
générez un flux réseau (avec ping)
arrêtez la capture
mettez en évidence les trames comportant le protocole ARP_RARP
Affichez le détail des trames ARP:request
- détail de frame : taille de la trame de base
- détail Ethernet : adresse destination
- l'adresse de destination est-elle l'adresse physique(MAC d'une machine ?
- quelle est la partie constructeur de l'adresse physique?
- quelle est l'adresse source ?
- quel est le type de trame ethernet ?
- combien d'octets contient la trame ?
- A quoi servent les 14 premiers octets ?
détail ARP_RARP
- adresse matérielle de l'expéditeur ?
- adresse IP de l'expéditeur ?
- adresse matérielle de la cible ?
- adresse IP de la cible ?
- pourquoi l'adresse matérielle de la cible contient-elle des FF ?
Affichez le détail de la trame ARP:Reply
- répétez les opérations précédentes et comparez
- expliquez le fonctionnement du protocole ARP.
Table of Contents
Abstract
Le document présente le routage IP sur un réseau local et en inter-réseau
Mots clés : routage, table de routage
Le routage dans Internet est similaire au mécanisme d'adressage du courrier.
Si vous adressez une lettre à un destinataire aux USA, à Los Angeles, dans l'état de Californie. Le bureau de poste de Belfort reconnaîtra que cette adresse n'est pas locale et transmettra le courrier au bureau français des PTT qui le remettra au service du mail US. Celui-ci s'en remettra à son bureau de la Californie, qui le transmettra au bureau de Los Angeles, qui connaît la localisation qui correspond à l'adresse dans la ville.
Avantages du système :
le bureau de poste local n'a pas à connaître toutes les adresses du monde
le chemin suivi peut être variable : chaque opérateur sait juste à qui remettre le courrier.
Le routage dans un réseau est identique :
Internet en entier est composé de réseaux autonomes qui s'occupent en interne de l'adressage entre leurs hôtes. Ainsi, tout datagramme arrivant sur un hôte quelconque du réseau destination sera acheminé à bon port par ce réseau seul.
Quand tous les hôtes participent au même réseau, chacun d'eux peut adresser des paquets aux autres sans difficulté. Par contre, si le destinataire est situé sur un autre réseau, le problème est de savoir où et à qui adresser le paquet puisque l'hôte expéditeur ne « voit » pas le destinataire.
On appelle passerelle (dans la terminologie TCP/IP) ou routeur un équipement qui fait le lien entre différents réseaux ou entre sous-réseaux. Ex de passerelle: un ordinateur équipé de plusieurs adaptateurs réseau peut être relié avec chacune d'elle à un réseau physiquement séparé.
Les paquets d'un réseau qui sont adressés à l'autre réseau doivent passer par la passerelle. D'où la nécessité pour chaque hôte de connaître, sur son réseau, l'adresse IP d'un ou de plusieurs routeurs qui servent de passage vers le ou les réseaux qu'ils ne connaît pas.
Mettre en place le routage consiste à configurer chaque hôte du réseau de façon à ce qu'il sache vers quelle adresse de son propre réseau il doit adresser un paquet qui concerne un autre réseau (ou sous-réseau). Ces destinataires intermédiaires sont des routeurs qui prennent en charge le paquet.
Les hôtes pouvant être nombreux, bien souvent chacun ne connaît que l'adresse d'une passerelle (routeur) par défaut et ce sera cette passerelle qui « connaîtra » les adresses des autres routeurs.
Comment faire transiter des paquets entre 2 machines séparées par plusieurs routeurs?
Simplement chaque routeur doit connaître l'adresse du routeur suivant que doit emprunter le paquet pour arriver à destination. Ainsi le paquet arrive en sautant de routeur en routeur jusqu'à destination.
Mais concrètement comment ça se passe ?
Voici comment un hôte expéditeur se comporte pour adresser un paquet à un destinataire :
Il extrait l'adresse de réseau, voire de sous réseau de l'adresse du destinataire et la compare à sa propre adresse de réseau ou de sous réseau. S'il s'agit du même réseau, le paquet est expédié directement au destinataire en mettant en oeuvre ARP.
S'il ne s'agit pas du même réseau, l'expéditeur cherche dans sa table de routage une correspondance destinataire final / destinataire intermédiaire (routeur). Il cherche, en quelque sorte, sur son réseau, un hôte capable de servir de facteur vers un autre réseau.
L'expéditeur cherche d'abord à trouver dans sa table de routage locale l'adresse IP complète du destinataire,
s'il ne la trouve pas il cherche l'adresse du sous réseau du destinataire,
s'il ne la trouve pas, il cherche enfin l'adresse du réseau,
s'il ne trouve aucune correspondance, l'expéditeur cherche dans sa table l'adresse d'une passerelle à utiliser par défaut, (route 0.0.0.0)
s'il échoue là encore, le paquet, décidément bien encombrant, est supprimé.
Si l'une de ces recherches aboutit, la machine émettrice construit le paquet avec l'adresse IP du destinataire hors réseau. Elle l'encapsule dans une trame ayant comme adresse MAC de destination l'adresse MAC du routeur. La couche 2 du routeur lit la trame qui lui est adressée et la transmet à la couche 3 IP. Celle-ci récupère le paquet et s'aperçoit que le paquet ne lui est pas adressé, elle consulte sa table de routage, décide sur quelle nouvelle interface réseau le paquet doit être transmis, encapsule le paquet dans une nouvelle trame, et ainsi de suite de passerelle en passerelle jusqu'à destination.
Les réseaux IP sont interconnectés par des routeurs IP de niveau 3 (appelés abusivement en terminologie IP des gateways ou passerelles).
Chaque hôte IP doit connaître le routeur par lequel il faut sortir pour pouvoir atteindre un réseau extérieur, c'est-à-dire avoir en mémoire une table des réseaux et des routeurs. Pour cela il contient une table de routage locale.
Dans une configuration de routage statique, une table de correspondance entre adresses de destination et adresses de routeurs intermédiaires est complétée « à la main » par l'administrateur, on parle de table de routage.
La table de routage d'un routeur comporte les adresses des réseaux de destination, le masque, les adresses des passerelles (routeurs intermédiaires) permettant de les atteindre, l'adresse de la carte réseau (interface) par laquelle le paquet doit sortir du routeur.
La commande Route permet d'afficher et de manipuler le contenu de la table de routage.
Considérons le schéma de réseau suivant :
La table de routage du routeur sera :
|
Destination |
Masque de Sous réseau |
Passerelle | Interface | |
|
192.168.10.0 |
255.255.255.0 |
192.168.10.99 |
192.168.10.99 |
sortie de la passerelle vers le sous-réseau 10 |
|
192.168.20.0 |
255.255.255.0 |
192.168.20.99 |
192.168.20.99 |
sortie de la passerelle vers le sous-réseau 20 |
|
192.168.30.0 |
255.255.255.0 |
192.168.30.99 |
192.168.30.99 |
sortie de la passerelle vers le sous-réseau 30 |
Ce réseau local est maintenant relié via un autre routeur à un 4ème réseau, le schéma devient :
La nouvelle entrée à ajouter dans la table de routage du routeur R1 sera :
|
Destination |
Masque de Sous réseau |
Passerelle | Interface | |
|
192.168.40.0 |
255.255.255.0 |
192.168.30.254 |
192.168.30.99 |
sortie de la passerelle vers le sous-réseau 40 via le routeur 192.168.30.254 |
Les échanges entre passerelles de chaque domaine de routage font l'objet de protocoles particuliers : EGP (Exterior Gateway Protocol) et BGP (Border Gateway Protocol) plus récent. Ces protocoles envoient les paquets vers des destinations en dehors du réseau local vers des réseaux externes (Internet, Extranet...).
Si l'hôte de destination se trouve sur le réseau local, les données sont transmises à l'hôte destination
Si l'hôte destination se trouve sur un réseau à distance, les données sont expédiées vers une passerelle locale qui route le paquet vers une autre passerelle et ainsi de suite de passerelle en passerelle jusqu'à destination.
La commande Tracert permet de suivre à la trace le passage de routeur en routeur pour atteindre un hôte sur le réseau. La commande Ping permet de vérifier la fiabilité d'une route donnée.
Les protocoles d'échange dynamique des tables de routage IP sur un réseau local sont RIP (Routing Information Protocol) et le protocole OSPF (Open Shortest Path First). Dans une configuration de routage dynamique, un protocole (RIP ou OSPF) est mis en oeuvre pour construire dynamiquement les chemins entre routeurs.
Le protocole RIP permet à un routeur d'échanger des informations de routage avec les routeurs avoisinants. Dès qu'un routeur est informé d'une modification quelconque de la configuration sur les réseaux (telle que l'arrêt d'un routeur), il transmet ces informations aux routeurs avoisinants. Les routeurs envoient également des paquets de diffusion générale RIP périodiques contenant toutes les informations de routage dont ils disposent. Ces diffusions générales assurent la synchronisation entre tous les routeurs.
Avec un protocole comme RIP, on peut considérer que les tables de routages des routeurs et passerelles sont constituées et mises à jour automatiquement.
Table of Contents
Abstract
L'adressage IPv4 sur 32 bits se révélant insuffisant (saturation prévue pour 2010) avec le développement d'Internet, l'IETF a proposé une nouvelle version du protocole IP en 1995 (RFC 1883) puis le standard IPv6 en 1998 (ou Ipng - ng pour "Next Generation", RFC 2460), afin de permettre l'adressage d'au moins un milliard de réseaux, soit quatre fois plus qu'IPv4.Pour permettre le déploiement d'IPv6 de la manière la plus flexible possible, la compatibilité avec IPv4 est garantie.Pour un point sur IPv6, vous pouvez consulter cet article :http://www.vnunet.fr/actualite/reseau/technologie/20051222008.
IPv6 apporte un certain nombre de nouvelles fonctionnalités :
Un plus grand espace d'adressage
Un entête simplifié et efficace
L'autoconfiguration
Le support de la mobilité
Un plus grand espace d'adressage , c'est la plus flagrante évolution mise en avant lorsqu'on parle d'IPv6. Il permettra de déployer de nouvelles applications nécessitant des communications de bout en bout (téléphonie mobile, vidéoconférence, applications en temps réel).
Un entête simplifié et efficace : l'entête IPv6 est de taille fixe. Les options de l'entête IPv4 ont disparues, elles sont remplacées par les extensions d'entête IPv6. Alors que les options d'entête IPv4 étaient examinées par tous les noeuds intermédiaires d'une communication, les extensions IPv6 ne seront gérées que par les équipements terminaux. Les équipements intermédiaires sont donc déchargés d'une partie des traitements. La gestion des paquets erronés est déléguée aux équipements d'extrémité et aux couches supérieures telles TCP ou UDP.
L'autoconfiguration : elle met en oeuvre un certain nombre de nouveaux protocoles associés à IPv6 (protocole de découverte des voisins, nouvelle version d'ICMP ...). L'autoconfiguration permet à un équipement de devenir complètement "plug and play". Il suffit de connecter physiquement la machine pour qu'elle acquière une adresse IPv6 et une route par défaut.
Le support de la mobilité : il a été introduit dès la conception d'IPv6. Cela se caractérise par le fait d'être connecté et de disposer de son environnement tout en se déplaçant et ce, sans interruption de service tout en conservant la même adresse IPv6. En pratique les données destinées à une machine qui a été déplacée sont automatiquement retransmises vers sa nouvelle position, son nouveau lieu de connexion, à l'échelle planétaire. Cela s'appliquera aux téléphones et ordinateurs portables, assistants personnels .., les utilisateurs pourront se connecter dans le train, la voiture... lors de leurs missions extérieures.
A noter : en 1996, un réseau expérimental a été créé pour tester le déploiement d'IPv6. Il s'agit du 6bone qui s'étend en Asie, Europe , Amérique et Australie. Depuis 1998 , les adresses distribuées par le 6bone avaient comme préfixe commun "3ffe" , depuis Janvier 2004 , ce sont des adresses dont le préfixe est "2001" qui sont distribuées.
En résumé : IPv6 possède un nouveau format d'en-tête IP, une infrastructure de routage plus efficace, et un espace d'adressage plus important. Pour permettre le déploiement d'IPv6 de la manière la plus flexible possible, la compatibilité avec IPv4 est garantie.
- les adresses IPv6 sont codées sur 128 bits (1 milliard de réseaux).
- le principe des numéros de réseaux et des numéros d'hôtes est maintenu.
- IPv6 est conçu pour interopérer avec les systèmes IPv4 (transition douce prévue sur 20 ans). L'adresse IPv6 peut contenir une adresse IPv4 : on place les 32 bits de IPv4 dans les bits de poids faibles et on ajoute un préfixe de 96 bits ( 80 bits à 0 suivis de 16 bits à 0 ou 1)
- IPv6 utilise un adressage hiérarchique (identification des différents réseaux de chaque niveau) ce qui permet un routage plus efficace.
- IPv6 est prévu pour les systèmes mobiles : auto-configuration, notion de voisinage (neighbor).
- IPv6 permet l'authentification et le chiffrement dans l'en-tête des paquets, ce qui permet de sécuriser les échanges. En effet IP v.6 intègre IPSec (protocole de création de tunnel IP avec chiffrement), qui garantit un contexte sécurisé par défaut.
- IPv6 intègre la qualité de service : introduction de flux étiquetés (avec des priorités)
- IPv6 prend mieux en charge le trafic en temps réel (garantie sur le délai maximal de transmission de datagrammes sur le réseau).
L'adressage IPv6 est structuré en plusieurs niveaux selon un modèle hiérarchique dit "agrégé". Cette composition devrait permettre une meilleure agrégation des routes et une diminution de la taille des tables de routage.
Un plan d'adressage hiérarchisé en trois niveaux a été défini pour les adresses IPv6 :
le niveau "public" (Global Routing prefix) utilise 48 bits décomposés comme suit :
- L'international: TLA (Top Level Aggregator) utilise les 16 premiers bits, ce préfixe est délivré aux grands opérateurs internationaux, par exemple RICE-NCC (Renater, Nerim ...) a la classe 2001:600/13
- Le National: Sub-TLA utilise les 13 bits suivants, il permet aux opérateurs internationaux de fournir des adresses aux opérateurs nationaux, par exemple 2001:660::/35 correspond à Renater.
- Les 6 bits suivants sont réservés pour des utilisations futures.
- Le NLA (Next Level Aggregator) utilise les 13 bits suivants, il permet aux opérateurs de délivrer des adresses à leurs clients, par exemple Renater a donné l'adresse 2001:0660:7701::/48 à l'université de Caen.
le niveau "site" SLA (Site Level Aggregator) utilise les 16 bits suivants, ils sont sous la responsabilité du site et permettent de créer des sous-réseaux (donc 65534 sous-réseaux possibles par site).
le niveau "interface" utilise 64 bits, ils correspondent à l'identifiant unique de l'interface sur le réseau. Sur les réseaux Ethernet, ils sont généralement fabriqués à partir de l'identifiant unique de l'interface : l'adresse MAC, mais ils peuvent également être générés aléatoirement pour des raisons de confidentialité.
Les adresses IPv6 sont codées sur 128 bits.
Les 128 bits de l'adresse sont divisés en 8 groupes de 16 bits représentés par 4 chiffres hexadécimaux et séparés par ":" .
Exemple d'adresse : 5800:10C3:E3C3:F1AA:48E3:D923:D494:AAFF
Dans IPv6 les masques sont exprimés en notation CIDR.
Il y a plusieurs façons de représenter les adresses IPv6.
Notation : "x:x:x:x:x:x:x:x" où x représente les valeurs hexadécimales des 8 portions de 16 bits de l'adresse.
A noter : les lettres peuvent être écrites aussi bien en majuscules qu'en minuscules.
Exemples d'adresse :
2001:0660:7401:0200:0000:0000:0edf:bdd7
3ffe:0104:0103:00a0:0a00:20ff:fe0a:3ff7
Notation : les zéros à gauche de chaque groupe peuvent être omis, un ou plusieurs groupes de zéros consécutifs se notent "::".
La séquence "::" ne peut apparaître qu'une seule fois dans une adresse.
L'adresse donnée en exemple peut donc s'écrire :
2001:660:7401:200::edf:bdd7
L'adresse IPv6 compatible IPv4
Elle est utilisée dans un contexte particulier : les tunnels 6 to 4 permettant de relier des réseaux IPv4 à des réseaux IPv6.
Soit une adresse IPv4 notée a.b.c.d , son équivalent IPv6 se notera :
0:0:0:0:0:0:0:a.b.c.d/96
ou en forme abrégée : ::a.b.c.d/96
Exemple :
::132.64.16.25
L'adresse IPv4 mappée
Un hôte IPv6 étant capable de communiquer aussi bien avec un hôte IPv4 qu'avec un hôte IPv6, il utilise des adresses IPv4 mappées pour communiquer avec les autres machines IPv4 et utilise des adresses IPv6 normale pour communiquer avec les autres machines IPv6. Ces adresses sont de la forme ::ffff:a.b.c.d .
Exemple :
:: ffff : 132.64.16.25
L'adresse de bouclage qui correspond à 127.0.0.1 en IPv4
0000:0000:0000:0000:0000:0000:0000:0001
L'adresse de bouclage ou localhost se note en abrégé :
::1
L'adresse indéterminée qui correspond à 0.0.0.0 en IPv4.
Elle caractérise l'absence d'adresse. Elle est utilisée lors de certaines phases d'initialisation. C'est une adresse transitoire. Elle se note 0:0:0:0:0:0:0:0 ou ::
Leur notation classique comme en IPV4 est impossible avec 128 bits, c'est donc la notation CIDR, plus simplement appelée notation "slash" qui est utilisée.
Exemple l'adresse fe80::20d:61ff:fe22:3476/64 a un masque de 64 bits , masque par défaut pour une adresse de type lien-local.
IPv6 supporte 3 types d'adresses: Unicast, Multicast et Anycast.
Les adresses unicast :
Elles désignent une et une seule machine.
Elles comportent une partie réseau "préfixe" et une partie hôte "suffixe":
La partie réseau ou préfixe est codée sur 64 bits : les 48 bits publics "Global Routing Prefix" et les 16 bits de site définissant le sous-réseau
La partie hôte ou suffixe est codée aussi sur 64 bits, fabriquée à partir de l'adresse MAC de l'interface, elle permet d'identifier la machine dans un réseau donné.
Prenons par exemple cette adresse fe80::20d:61ff:fe22:3476
fe80:: ,en réalité fe80:0000:0000:0000 correspond au préfixe ou partie réseau
20d:61ff:fe22:3476 correspond au suffixe ou partie hôte
Les adresses multicast :
Le protocole IPv6 généralise l'utilisation des adresses multicast qui remplacent les adresses de type "broadcast" (diffusion) qui n'existent plus en IPv6. La raison de cette disparition est que l'émission d'un paquet broadcast était très pénalisante pour toutes les machines se trouvant sur un même lien.
Une adresse multicast est une adresse désignant un groupe d'interfaces donné. Une interface est libre de s'abonner à un groupe ou de le quitter à tout moment, c'est donc moins pénalisant qu'en IPv4.
Le format des adresses multicast est le suivant :
ff01 : noeud local, les paquets ne quittent pas l'interface.
ff02 : lien local, les paquets ne quittent pas le lien .
ff05 : site local, les paquets ne quittent pas le site .
Voici un exemple intéressant d'utilisation d'adresse multicast qui vous permet de détecter les hôtes actifs sur le lien local :
# ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::20e:35ff:fe8f:6c99 eth2: 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.048 ms 64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=1 ttl=64 time=9.05 ms (DUP!) 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.045 ms 64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=2 ttl=64 time=3.33 ms (DUP!) 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.037 ms
Vous pouvez identifier 2 hôtes actifs fe80::20e:35ff:fe8f:6c99 (celui d'où est passée la commande) et fe80::20d:61ff:fe22:3476 (qui correspond à un autre poste du réseau local).
Les adresses anycast :
Anycast est un nouveau type d'adressage. Il identifie qu'un noeud, parmi un groupe de noeuds, doit recevoir l'information.
Une adresse anycast, comme une adresse multicast, désigne un groupe d'interfaces, à la différence qu'un paquet émis avec comme destinataire une adresse anycast ne sera remis qu'à un seul membre du groupe, par exemple le plus proche au sens de la métrique des protocoles de routage, même si plusieurs interfaces ont répondu au message. L'interface de destination doit spécifiquement être configurée pour savoir qu'elle est anycast.
Pour l'instant, une seule adresse anycast est utilisée, elle est réservée au routeur mais dans l'avenir, d'autres pourraient être définies.
La portée ou "scope" des adresses, est une nouvelle notion qui n'existait pas en IPv4.
En fait une interface ne possède pas une seule adresse IPv6 mais peut en avoir plusieurs.
Les quatre portées d'adresses sont :
Noeud-local : il s'agit de l'adresse de loopback . Elle est notée ::1/128.
Lien-local : adressage commun aux machines d'un même lien physique reliées entre elles sans routeur intermédiaire .Ces adresses ont comme préfixe fe80::/64. Seuls les équipements de la couche 2 du modèle OSI peuvent utiliser ces adresses pour communiquer entre eux. Cette adresse est obtenue par autoconfiguration "sans état".
Site-local : adressage commun des machines d'un même site.Par exemple, un site qui n'est pas encore relié à Internet peut utiliser ce type d'adresse. C'est un peu le concept des adresses privées en IPv4 (192.168.x.x ou 10.x.x.x). Une adresse site local a comme préfixe fec0::/48 suivi d'un champ de 16 bits permettant de définir des sous-réseaux.
Globale : ce sont des adresses dont le routage est effectué sans restriction. Leur préfixe est 2000::/3 , ce qui signifie qu'elles commencent par 001 en binaire. Concrètement, on utilise 2xxx ou 3xxx.
Par exemple 2001:7a8:4b09:1bff:feb1:defa est une adresse globale.
Le type d'adresse IPv6 est indiqué par les premiers bits de l'adresse qui sont appelés le "Préfixe de Format" (Format Prefix). L'allocation initiale de ces préfixes est la suivante :
Allocation | Préfixe | Usage |
Adresses Unicast globales | 010 | Adresses dont le routage est effectué sans restriction, utilisables sur Internet. |
Adresses Unicast expérimentales | 001 | |
Adresses "Lien local" | 1111 1110 1000 | Adresses d'un même lien physique,obtenues par autoconfiguration |
Adresses "Site Local" | 1111 1110 1100 | Adresses d'un même site |
Adresses Multicast | 1111 1111 | Elles remplacent les adresses "broadcast" d'IPv4 |
15 % de l'espace d'adressage est actuellement alloué. Les 85% restants sont réservés pour des usages futurs. En réalité sur les 128 bits, seulement 64 sont utilisés pour les hôtes (Interface ID).
Table of Contents
ping6
Ce programme est inclus dans le paquet "iputils", normalement déjà installé.
Exemples d'utilisation:
ping6 -I eth0 ::1 # ping de l'adresse de bouclage
ping6 -I eth0 ff02::1 # permet de voir tous les hôtes actifs sur le lien
ping6 -I eth0 fe80::20e:35ff:fe8f:6c99 #ping de l'adresse IPv6 d'un autre poste
Afficher l'adresse IPv6
- La commande ifconfig peut être utilisée:
ifconfig
ifconfig |grep inet6 # affiche uniquement les adresse IPv6
- La commande "ip -6 addr show" qui affiche uniquement les paramètres IPv6
# ip -6 addr show [dev interface ]
# ip -6 addr show
1: lo: LOOPBACK,UP mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0: BROADCAST,MULTICAST,UP mtu 1500 qlen 1000
inet6 2002:c000:201::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20d:61ff:fe22:3476/64 scope link
valid_lft forever preferred_lft forever
Montage et démontage des interfaces
# ip link set dev interface up
# ip link set dev interface down
Exemple:
# ip link set dev eth0 up
La commande ifconfig peut également être utilisée :
# ifconfig eth0 up
Configurer manuellement une adresse IPv6
Il peut être utile de configurer manuellement des adresses IPv6 , par exemple pour des routeurs ou des serveurs, pour les postes clients , l'autoconfiguration est préférable.
On peut utiliser les commandes "ifconfig" ou "ip -6"
# ifconfig eth0 inet6 add 3ffe:ffff:0:f101::1/64
# ip -6 add 3ffe:ffff:0:f101::1/64 dev eth0
A noter : pour enlever une adresse ip, remplacer simplement add par del , dans les 2 commandes.
Afin de rendre votre nouvelle adresse IPv6 permanente, vous devez ajouter la configuration IPv6 de votre interface dans le fichier
/etc/network/interfaces
en ajoutant par exemple :
iface eth0 inet6 static
address 3ffe:ffff:0:f101::1
netmask 64
Le paramètre gateway peut également être précisé dans le fichier interfaces.
Afficher la table de routage
# ip -6 route show [dev peripherique]
# ip -6 route show
# route -A inet6
# route -A inet6 |grep eth0 # pour afficher seulement ce qui concerne l'interface eth0
~$ sudo route -A inet6 Table de routage IPv6 du noyau Destination Prochain Hop Indic Metric Ref Utilis. Iface ::1/128 :: U 0 0 2 lo ::/96 :: U 256 0 0 sit0 2002:c000:201:0:20e:35ff:fe8f:6c99/128 :: U 0 0 2 lo 2002:c000:201::/64 :: UA 256 0 0 eth2 fe80::20e:35ff:fe8f:6c99/128 :: U 0 11 2 lo fe80::/64 :: U 256 0 0 eth2 ::/0 fe80::20d:61ff:fe22:3476 1 eth2
la ligne ::/0 désigne la route par défaut, ici il s'agit de l'adresse du routeur d'annonce (cf chapitre sur l'autoconfiguration).
la ligne 2002:c000:201::/64 désigne la route de l'interface de portée globale.
la ligne ff00::/8 désigne la route pour le trafic multicast.
la ligne fe80::/64 désigne la route de l'interface de portée lien-local
Ajouter une route
# route -A inet6 add reseauipv6/longueurprefixe gw adresseipv6 [dev peripherique]
# route -A inet6 add 2000::/3 gw 3ffe:ffff:0:f101::1 dev eth0
# ajoute une route pour toutes les adresses globales actuelles (2000::/3)
# ip -6 route add 2000::/3 via 3ffe:ffff::0:f101::1 dev eth0
# ajoute une route pour toutes les adresses globales actuelles (2000::/3)
# ip -6 route add 2000::/3 via 3ffe:ffff::0:f101::1 dev eth0
#ajout de cette route avec la commande ip -6
Pour supprimer une route , syntaxe identique pour les 2 commandes , remplacer simplement "add" par "del".
Commande traceroute6
Ce programme est inclus dans le paquet iputils-tracepath qu'il faudra éventuellement installer.
Son fonctionnement est similaire au traceroute d'IPv4 , par exemple :
# traceroute6 www.6bone.net
# traceroute6 2001:5c0:0:2::24
Commande tracepath6
Ce programme est également inclus dans le paquet iputils-tracepath
Son fonctionnement est similaire à traceroute6.
Le protocole de découverte des voisins (Neighbor Discovery) permet à un équipement de s'intégrer dans l'environnement de réseau local, c'est à dire le lien sur lequel sont physiquement transmis les paquets IPv6.La découverte des voisins ne consiste pas à établir une liste exhaustive de tous les équipements connectés au lien mais de gérer uniquement ceux avec lesquels il dialogue.
Fonctionnalités du protocole :
Résolution d'adresses
Le principe est très proche du protocole ARP d'IPv4. La principale différence vient de l'emploi de messages standards ICMP6 à la place de la définition d'un autre protocole. Comme pour ARP, une table de correspondance entre les adresses physiques et les adresses IPv6 est construite. Une requête de résolution d'adresse est une "sollicitation de voisin" véhiculée par un paquet ICMP6 dont l'adresse de destination est une adresse multicast.
Fonction d'inaccessibilité des voisins
Cette fonction appelée aussi "NUD" (Neighbor Unreachability Detection) n'existe pas en IPv4. Elle permet d'effacer dans le cache des voisins les entrées correspondants aux voisins inaccessibles (panne, changement d'adresse ...).
Si un routeur devient inaccessible, la table de routage peut être modifiée dynamiquement pour prendre en compte un autre routeur.
La configuration automatique
Le protocole de découverte des voisins est le successeur de l'ARP d'IPv4. Il participe à l'autoconfiguration , véritable atout d'IPv6.
- Découverte des routeurs : Elle permet aux équipements de découvrir les routeurs qui sont sur leur lien physique.
- Découverte des préfixes : L'équipement apprend le(s) préfixe(s) utilisé(s) sur le réseau en fonction des annonces faites par les routeurs et en y ajoutant l'identificateur d'interface de l'équipement, il construit son adresse IPv6. C'est le principe vu précédemment avec l'autoconfiguration.
- Detection des adresses dupliquées : Comme les adresses sont construites automatiquement, il existe des risques de duplication d'adresses. Un entête permet à l'interface de s'assurer qu'elle est la seule à posséder l'adresse qui lui a été attribuée.
Afficher le voisinage
ip -6 neigh show [dev péripherique]
Lorsque vous ne disposez que d'une interface réseau, inutile de la préciser. Voici un exemple de commande :
morph@ns1:~$ ip -6 neigh show morph@ns1:~$ ping6 -I eth2 fe80::20d:61ff:fe22:3476 PING fe80::20d:61ff:fe22:3476(fe80::20d:61ff:fe22:3476) from fe80::20e:35ff:fe8f:6c99 eth2: 56 data bytes 64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=1 ttl=64 time=6.08 ms 64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=2 ttl=64 time=3.06 ms 64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=3 ttl=64 time=3.10 ms --- fe80::20d:61ff:fe22:3476 ping statistics --- morph@ns1:~$ ip -6 neigh show fe80::20d:61ff:fe22:3476 dev eth2 lladdr 00:0d:61:22:34:76 router nud stale
0
On peut constater que le cache de voisinage est vide avant l'exécution du ping6 sur un autre poste. Le comportement de cette commande est donc très proche de la commande arp d'IPv4.
Pour afficher les autres possibilités :
ip -6 neigh help
Les messages du protocole
- Sollicitation du voisin ou Neighbor solicitation : ce message permet d'obtenir des informations d'un voisin, c'est-à-dire situé sur le même lien physique. Le message peut être envoyé au voisin soit explicitement (en unicast) soit vers l'adresse multicast associée à ce voisin. Dans le cas de la détermination d'adresse physique, il correspond à la requête ARP du protocole IPv4.
- Annonce du voisin ou Neighbor advertisement : ce message est émis en réponse à une sollicitation.
Vous pouvez visualiser l'échange des messages du protocole en faisant une capture de trames avec ethereal lors d'une commande "ping6" par exemple .
Il existe 3 types d'autoconfiguration :
L'autoconfiguration sans état ou "stateless" où seul le préfixe est donné à l'équipement qui aura la charge de générer le suffixe de l'adresse.
Dès qu'une interface est activée (démarrage de la machine par exemple) une adresse de type lien-local est automatiquement générée à partir de l'adresse MAC de l'interface
Exemple : une carte réseau d'adresse MAC 00:0D:61:22:34:76 aura l'adresse IPv6 suivante fe80::20d:61ff:fe22:3476
Le préfixe est fe80::, donc l'adresse est de type "lien-local".
Le suffixe est généré à partir de l'adresse MAC de la machine.
C'est ce type d'adresse qui est généré sur votre machine si vous avez le module IPv6 comme c'est le cas sous Linux avec le noyau 2.6 .
Vous pouvez vérifier si le module IPv6 est chargé simplement en faisant la commande:
#ifconfig |grep inet6
adr inet6: fe80::20d:61ff:fe22:3476/64 Scope:Lien
adr inet6: ::1/128 Scope:HôteVous pouvez voir que l'interface eth0 possède bien une adresse IPv6 fe80::20d:61ff:fe22:3476/64 qui correspond à une adresse de type lien-local et vous pouvez remarquer que la partie suffixe est bien dérivée de son adresses MAC.
L'interface de loopback possède également une adresse IPv6 ::1/128
Ce type d'adresse lien-local peut suffire pour les premiers tests.
L'autoconfiguration avec état ou "stateful" dans laquelle l'adresse est fournie par le démon Annonce du routeur .
Le démon radvd permet d'autoconfigurer toutes les interfaces du réseau avec un autre préfixe (par exemple celui qui vous aura été fourni par votre FAI ou celui que vous aurez choisi pour vos tests) en utilisant un routeur IPv6 où le démon "radvd" ou "Router Advertisement demon" est installé.
Ce démon doit être installé sur un des postes de votre réseau , celui qui servira plus tard de passerelle IPv6.
Pour installer radvd :
# apt-get install radvd
Vous devez ensuite créer le fichier
/etc/radvd.conf
En y mettant le préfixe que vous souhaitez donner aux interfaces du réseau , voici un exemple de fichier radvd.conf :
interface eth0
{
AdvSendAdvert on;
prefix 2002:c000:201::1/64
{
};
};
Ici , le préfixe sera 2002:c000:201::1/64 .
Vous devez ensuite redémarrer le démon radvd en faisant:
# invoke-rc.d radvd restart
Ajoutez ensuite la configuration IPv6 de votre interface dans le fichier
/etc/network/interfaces
:
iface eth0 inet6 static
address 2002:c000:201::1
netmask 64
Relancer ensuite le service networking.
Le démon radvd émet ensuite des annonces afin que les interfaces du lien s'autoconfigurent avec le préfixe reçu et le routeur pas défaut.
ifconfig |grep inet6
adr inet6: fe80::20d:61ff:fe22:3476/64 Scope:Lien
adr inet6: 2002:c000:201::1/64 Scope:Global
adr inet6: ::1/128 Scope:Hôte
Le routeur d'annonce a désormais une adresse IPv6 localhost ::1 ,une adresse lien local fe80::20d:61ff:fe22:3476/64 et une adresse globale 2002:c000:201::1/64 .
Pour la configuration des autres postes du réseau, il suffit de lancer la commande "dhclient ethx" sur cet autre poste pour récupérer les nouveaux paramètres.
En effectuant une capture de trames avec ethereal lors de l'exécution de la commande dhclient ,vous pourrez remarquer les différents messages du protocole :
- "Router solicitation" ou sollicitation du routeur: ce message est émis par un équipement au démarrage ou lors d'un renouvellement d'adresse avec "dhclient" pour recevoir plus rapidement des informations du routeur. Ce message est émis vers l'adresse IPv6 de multicast réservée aux routeurs du même lien ff02::2. Il est émis par l'adresse lien-local de l'équipement.
- "Router advertisement" ou annonce du routeur : ce message est émis périodiquement par les routeurs ou en réponse à un message de sollicitation du routeur. L'adresse source est celle du poste sur lequel le démon "radvd" a été configuré : par exemple notre routeur d'annonce fe80::20d:61ff:fe22:3476, l'adresse de destination est ff02::1 ce qui correspond à l'adresse multicast de sollicitation de lien-local.
Voici la configuration obtenue par le poste client après l'exécution de la commande "dhclient" .
$ sudo ifconfig |grep inet6 adr inet6: 2002:c000:201:0:20e:35ff:fe8f:6c99/64 Scope:Global adr inet6: fe80::20e:35ff:fe8f:6c99/64 Scope:Lien adr inet6: ::1/128 Scope:Hôte
Vous pouvez constater que ce poste a desormais également 3 adresses IPv6 (au lieu de 2 auparavant) car c'est le routeur d'annonce qui lui a envoyé le préfixe de son adresse globale, le suffixe étant calculé à partir de son adresse MAC : 2002:c000:201:0:20e:35ff:fe8f:6c99/64
Si le préfixe vous a été attribué par un FAI (ex Nérim qui fournit des adresses IPv6 natives) ou un "tunnelbroker" (par exemple Freenet6 , Sixxs )qui fournit des passerelles gratuites IPv6 via un tunnel, votre poste possède donc sa propre adresse IPv6 globale unique (avec la partie suffixe dérivée de l'adresse MAC) ,utilisable sur Internet.
Ce concept d'autoconfiguration peut donc vous permettre de paramétrer tout un réseau en ne configurant que le routeur d'annonce, les postes clients obtenant automatiquement leur propre configuration.
L'autoconfiguration avec DHCP6
Ce type de configuration dynamique, moins utile avec IPv6, ne sera pas détaillé pour l'instant.
Table of Contents
Par un fournisseur d'accès :
Pour l'instant en France (début 2006) seul Nerim fournit des adresses ipv6 natives http://www.nerim.fr/connectiviteenipv6.php
Toutefois une expérimentation est en cours depuis Juin 2005 pour les abonnés de Wanadoo : http://www.ipv6.wanadoo.fr/mxBB/.
Une pétition est en cours afin que le FAI free donne des adresses IPv6 natives à ses abonnés: http://ipv6pourtous.free.fr/faq/.
Utiliser une connexion via un tunnel 6to4
Un tunnel "6to4" permet de relier un réseau Ipv4 au réseau IPv6.
Du côté du réseau IPv4 , les trames IPv6 sont encapsulées dans des trames IPv4 et sont envoyées vers le relais 6to4 qui est chargé d'en extraire les trames IPv6 et de les envoyer vers le réseau IPv6.
Les principaux fournisseurs de tunnels 6to4 sont :
-Hurricane Electric http://www.tunnelbroker.net
-Freenet6 http://www.hexago.com
-Sixxs http://www.sixxs.net
Se relier à une passerelle ipv6
Contrairement aux tunnels "6to4", vous ne vous enregistrez pas auprès d'un fournisseur qui redirigera pour vous tout le trafic IPv6 encapsulé dans des trames IPv4. Votre adresse IPv6 est calculée d'après votre adresse IPv4 publique, les trames IPv6 seront dirigées vers une passerelle "6to4". Pour connaitre les passerelles disponibles :
Nous prendrons comme exemple une configuration avec Hurricane Electric
Vous devez d'abord faire une demande d'enregistrement auprès http://www.tunnelbroker.net
Vous recevrez rapidement par e-mail un compte et un mot de passe.Votre tunnel sera utilisable environ 24 heures après.
Voici un exemple de tunnel :
Vous y verrez notamment l'adresse du serveur IPv4: Server IPv4 address: 64.71.128.83
L'adresse client IPv4 correspond à votre adresse IPv4 publique.
Vous pouvez y voir aussi l'adresse IPv6 cliente qui vous a été attribuée et celle du serveur.
Vous pouvez également tester la connectivité IPv6 directement sur le site de Hurricane.
Configuration de votre poste
Vous devez commencer par configurer les interfaces virtuelle sit0 et sit1
L'interface sit0 correspond au serveur (fin du tunnel).
L'interface sit1 correspond à votre poste (début du tunnel).
fds@poste:~$ sudo ifconfig sit0 up fds@poste:~$ sudo ifconfig sit0 inet6 tunnel ::64.71.128.83 fds@poste:~$ sudo ifconfig sit1 up fds@poste:~$ sudo ifconfig sit1 inet6 add 2001:470:1F01:FFFF::E21/127
Vous vérifiez ensuite votre configuration :
fds@poste:~$ sudo ifconfig
eth0 Lien encap:Ethernet HWaddr 00:0D:61:22:34:76
inet adr:192.168.1.80 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::20d:61ff:fe22:3476/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:76430 errors:0 dropped:0 overruns:0 frame:0
TX packets:64327 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:19902751 (18.9 MiB) TX bytes:7892805 (7.5 MiB)
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:15509 errors:0 dropped:0 overruns:0 frame:0
TX packets:15509 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:1407434 (1.3 MiB) TX bytes:1407434 (1.3 MiB)
sit0 Lien encap:IPv6-dans-IPv4
adr inet6: ::127.0.0.1/96 Scope:Inconnu
adr inet6: ::192.168.1.80/96 Scope:Compat
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
sit1 Lien encap:IPv6-dans-IPv4
adr inet6: fe80::c0a8:150/64 Scope:Lien
adr inet6: 2001:470:1f01:ffff::e21/127 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:59 errors:0 dropped:0 overruns:0 frame:0
TX packets:60 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:9312 (9.0 KiB) TX bytes:6454 (6.3 KiB)
Vous pouvez vérifier les adresses attribuées à sit0 et sit1.
Vous devez ajouter ensuite une route pour le trafic IPv6 :
fds@poste:~$ sudo route -A inet6 add ::/0 dev sit1
Si vous passez par un routeur pour accéder à Internet:
Le trafic via un tunnel IPv4/IPv6 utilise le port 41.
Il vous faudra faire sur votre routeur une redirection du port 41 vers votre poste.
Si vous utilisez un firewall, vous devrez également autoriser le trafic pour le port 41.
Si cela ne suffit pas, déclarez votre poste en "DMZ Server" sur votre routeur.
Vérification de la connectivité IPv6
Faire un ping6 sur votre adresse cliente IPv6 et l'adresse du serveur IPv6 attribuées par le fournisseur.
fds@poste:~$ ping6 2001:470:1F01:FFFF::E21 PING 2001:470:1F01:FFFF::E21(2001:470:1f01:ffff::e21) 56 data bytes 64 bytes from 2001:470:1f01:ffff::e21: icmp_seq=1 ttl=64 time=0.036 ms 64 bytes from 2001:470:1f01:ffff::e21: icmp_seq=2 ttl=64 time=0.040 ms 64 bytes from 2001:470:1f01:ffff::e21: icmp_seq=3 ttl=64 time=0.042 ms --- 2001:470:1F01:FFFF::E21 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.036/0.039/0.042/0.005 ms fds@poste:~$ ping6 2001:470:1F01:FFFF::E20 PING 2001:470:1F01:FFFF::E20(2001:470:1f01:ffff::e20) 56 data bytes 64 bytes from 2001:470:1f01:ffff::e20: icmp_seq=1 ttl=64 time=282 ms 64 bytes from 2001:470:1f01:ffff::e20: icmp_seq=2 ttl=64 time=176 ms 64 bytes from 2001:470:1f01:ffff::e20: icmp_seq=3 ttl=64 time=175 ms --- 2001:470:1F01:FFFF::E20 ping statistics --- 4 packets transmitted, 3 received, 25% packet loss, time 3002ms rtt min/avg/max/mdev = 175.542/211.539/282.909/50.466 ms
Test avec un traceroute6:
fds@poste:~$ traceroute6 www.kame.net traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:470:1f01:ffff::e21, 30 hops max, 16 byte packets 1 2001:470:1f01:ffff::e20 (2001:470:1f01:ffff::e20) 178.21 ms 175.007 ms 175.476 ms 2 2001:470:1fff:2::26 (2001:470:1fff:2::26) 175.572 ms 175.387 ms 174.403 ms 3 3ffe:81d0:ffff:1::1 (3ffe:81d0:ffff:1::1) 177.057 ms 176.618 ms 176.773 ms 4 3ffe:80a::e (3ffe:80a::e) 177.253 ms 177.553 ms 177.583 ms 5 2001:2a0:0:bb0a::1 (2001:2a0:0:bb0a::1) 281.696 ms 281.596 ms 282.318 ms 6 2001:2a0:0:bb04::6 (2001:2a0:0:bb04::6) 282.771 ms 282.251 ms 282.777 ms 7 hitachi1.otemachi.wide.ad.jp (2001:200:0:1800::9c4:2) 368.275 ms 368.134 ms 377.678 ms 8 2001:200:0:1c04:230:13ff:feae:5b (2001:200:0:1c04:230:13ff:feae:5b) 379.844 ms 380.374 ms 379.987 ms 9 2001:200:0:4800::7800:1 (2001:200:0:4800::7800:1) 370.923 ms 371.113 ms 370.943 ms 10 orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) 368.135 ms 377.356 ms 378.27 ms
Quelques sites à tester: http://www.kame.net, http://www.tahi.org.
Test du site www.kame.net avec Mozilla, si vous voyez la tortue bouger, vous êtes bien en IPv6 :-).
Allez ensuite sur le site www.tahi.org qui vous permettra de surfer en www6 sur http://www6.tahi.org/ et de vérifier que votre connexion IPv6 est bien active.
Vous pouvez obtenir auprès de votre fournisseur de tunnel Hurricane une adresse 64 bits qui vous permettra de configurer automatiquement les postes de votre réseau local en IPv6 en utilisant de démon radvd.
Les 64 bits fournis correspondront à la partie réseau de l'adresse, la partie hôte de l'adresse sera fournie automatiquement au poste client grâce au service radvd.
Dans l'exemple ci-dessus, l'adresse obtenue est 2001:470:1F01:1908::/64
Il faut ensuite activer le routage IPv6, cette commande doit être effectuée en root.
root@poste:# echo 1 >/proc/sys/net/ipv6/conf/all/forwarding
Ajout de l'adresse /64 à votre interface eth0
A noter: si votre poste dispose de 2 interfaces eth0 et eth1, on peut reserver l'interface eth0 pour la connexion internet et eth1 pour la connexion au réseau local, dans ce cas il vous faudra configurer l'interface eth1 pour le routage IPv6.
root@poste:# ip -6 addr add 2001:470:1F01:1908::/64 dev eth0
Normalement votre poste/routeur a une nouvelle adresse IPv6:
root@poste:# ifconfig |grep inet6
adr inet6: 2001:470:1f01:1908::/64 Scope:Global
Configurer le démon radvd.
Si vous n'avez pas encore installé "radvd" sur votre poste qui fera office de routeur, il faut faire "apt-get install radvd".
Creéz ou modifiez le fichier /etc/radvd.conf en y mettant l'adresse 64 bits qui vous a été fournie (A noter : le fichier radvd.conf n'est pas créé lors de l'installation du paquet radvd):
interface eth0
{
AdvSendAdvert on;
prefix 2001:470:1F01:1908::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
Relancer le demon radvd:
root@poste:# invoke-rc.d radvd restart
Votre routeur est maintenant configuré.
Test sur un poste client de votre réseau local.
Aucune configuration n'est à faire sur les postes clients, c'est le principal atout d'IPv6 avec le concept d'auto-configuration.
Au démarrage, votre poste client doit avoir récupéré une nouvelle adresse IPv6 :
joelle@ns1:~$ ifconfig |grep inet6
adr inet6: 2001:470:1f01:1908:20e:35ff:fe8f:6c99/64 Scope:Global
adr inet6: fe80::20e:35ff:fe8f:6c99/64 Scope:Lien
adr inet6: ::1/128 Scope:Hôte
Vous pouvez y remarquer l'adresse 2001:470:1f01:1908:20e:35ff:fe8f:6c99/64, les 64 premiers bits (partie réseau) correspondent à l'adresse fournie par votre routeur, les 64 bits suivants (partie hôte) sont dérivés de l'adresse MAC de la carte réseau du poste client.
Si votre poste était déjà démarré, la commande dhclient ethx vous permettra également de récupérer la nouvelle adresse IPv6.
Vous pouvez normalement effectuer des ping6 sur votre routeur et sur des sites distants:
joelle@ns1:~$ ping6 2001:470:1f01:ffff::e21 PING 2001:470:1f01:ffff::e21(2001:470:1f01:ffff::e21) 56 data bytes 64 bytes from 2001:470:1f01:ffff::e21: icmp_seq=1 ttl=64 time=6.52 ms 64 bytes from 2001:470:1f01:ffff::e21: icmp_seq=2 ttl=64 time=3.02 ms joelle@ns1:~$ ping6 2001:470:1f01:ffff::e20 PING 2001:470:1f01:ffff::e20(2001:470:1f01:ffff::e20) 56 data bytes 64 bytes from 2001:470:1f01:1908::: icmp_seq=1 ttl=64 time=3.02 ms 64 bytes from 2001:470:1f01:1908::: icmp_seq=2 ttl=64 time=3.01 ms joelle@ns1:~$ ping6 www.kame.net PING www.kame.net(orange.kame.net) 56 data bytes 64 bytes from orange.kame.net: icmp_seq=1 ttl=54 time=391 ms 64 bytes from orange.kame.net: icmp_seq=2 ttl=55 time=387 ms joelle@ns1:~$ traceroute6 www.kame.net traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:470:1f01:1908:20e:35ff:fe8f:6c99, 30 hops max, 16 byte packets 1 2001:470:1f01:1908:: (2001:470:1f01:1908::) 6.333 ms 2.986 ms 2.962 ms 2 2001:470:1f01:ffff::e20 (2001:470:1f01:ffff::e20) 178.608 ms 193.581 ms 178.45 ms
Nous avons ici effectué un ping6 sur l'adresse de début de tunnel , de fin de tunnel, sur le site www.kame.net.
Si les ping6 fonctionnent bien, alors on peut considérer que votre poste client est bien configuré pour se relier au réseau IPv6.
Test de Mozilla sur votre poste client:
A la fin de la page affichée sur ce site, vous pouvez vérifier que votre client est bien connecté sur ce site avec l'adresse 2001:470:1f01:1908:20e:35ff:fe8f:6c99/64.
Autre site à tester :
Votre configuration Ipv6 est bien opérationnelle et le sera automatiquement pour tous les postes de votre réseau local.
Bien d'autres services pourront être testés comme dns pour IPv6 , ip6tables...
Table of Contents
Le document décrit l'installation d'un service de transfert de fichiers, la configuration du service inetd et quelques premiers aspects touchant à la sécurité des services sous GNU/Linux.
Mots clés : Telnet, FTP, ssh, sftp, scp, TCP-Wrapper
Vous devriez à la fin pouvoir :
utiliser le service FTP du serveur à partir d'un client quelconque du réseau
bénéficier du service ftp anonyme ou authentifié,
pouvoir filtrer l'accès provenant de tout ou partie du réseau avec TCP-Wrapper.
1) Telnet:
Telnet est un protocole qui permet l'émulation de terminal VTx à distance sur un serveur Unix/Linux.
2) FTP:
FTP est un protocole de communication qui permet le transfert de fichiers entre plusieurs machines.
3) Le daemon inetd:
Toute application fonctionnant sous TCP/IP est basée sur le modèle client/serveur. Par exemple quelqu'un se connectant via telnet à un hôte distant « active » chez l'hôte le service serveur telnetd.
Chaque serveur est sur une machine en attente d'une connexion sur un port particulier. Dans les premières versions d'Unix-TCP/IP chaque application (telnet, ftp,...) avait son propre serveur qui était lancé au démarrage de chaque machine comme un "daemon". Cette stratégie encombrait inutilement la table des processus (autant de serveurs que de services). Ces services sont dits fonctionnant en mode « autonome » ou « standalone ».
Le daemon INETD est un « super » serveur, à l'écoute sur plusieurs ports et qui se charge de recevoir les demandes de connexion de plusieurs clients (telnet, ftp,...) et de lancer le serveur correspondant à la demande. A son démarrage il consulte les fichiers:
- /etc/services qui contient la liste générale des services TCP/IP avec leur numéro de port et le protocole de transport associé.
- /etc/inetd.conf qui contient la liste des services activés sur une machine donnée
Dans les distributions récentes (Mandrake 10.x, RedHat 9.x...), inetd a été remplacé par xinetd. Le principe est très similaire, à la seule différence que, dans /etc/etc/xinetd.d, chaque service (telnet, ftp, pop3...) dispose de son propre fichier de configuration.
Certains services utilisables avec inetd ou xinetd comme telnet, ftp, pop3... sont difficilement sécurisables car les mots de passe transitent en clair sur le réseau. Ce problème sera vu ultérieurement avec les TPs sur la métrologie. Si ces services sont utilisables en l'état sur des petits réseaux isolés, il faudra éviter de les utiliser sur des réseaux reliés à Internet ou dans des environnements peu sûrs. Cependant, la tendance est au cryptage de ces services, grâce à SSL notamment. Il existe une version sécurisée de telnet, nommée telnet-ssl.
/etc/services :
ftp 21/tcp telnet 23/tcp smtp 25/tcp mail pop3 110/tcp # Post Office
etc...
ftp stream tcp nowait root /usr/sbin/ftpd ftpd #shell stream tcp nowait root /usr/sbin/rshd rshd #login stream tcp nowait root /usr/sbin/rlogind rlogind #exec stream tcp nowait root /usr/sbin/rexecd rexecd
Ici, il n'y a que le service ftp qui est activé par le serveur inetd. Les autres lignes sont en commentaires.
Ces services sont dits fonctionnant en mode « parallèle ».
Le principe est similaire, à la différence que vous avez un fichier de configuration global "/etc/xinetd.conf", et un fichier de configuration par service, en général dans le répertoire "/etc/xinetd.d/".
#
# Le fichier xinetd.conf
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
Le fichier /etc/xinetd.d/wu-ftpd
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
}
Le paramètre "disable", permet d'activer/désactiver le service.
le programme "in.ftpd", indique bien que le service est pris en charge par TCPWrapper (C'est le in qui l'indique, sinon, le binaire s'appellerait ftpd).
Les commentaires en haut du fichier indiquent que ce service ne prend pas en charge l'encryptage des mots de passe.
TCP-Wrapper est un outil de sécurité réseau qui permet de contrôler les accès, les tentatives de connexion sur une machine donnée. Il permet à tout instant de savoir (par journalisation syslogd) qui essaie d'accéder sur un ordinateur mais également de filtrer les accès. On peut par exemple sur une machine A interdire les connexions telnet venant d'une machine B tout en autorisant les connexions FTP venant de cette même machine B.
Principe de fonctionnement:
Exemple: Si inetd reçoit une demande de connexion sur le port 23 il va lancer telnetd.
Tcpwrapper sert d'enveloppe. Il vient « s'intercaler » entre le daemon inetd et le serveur à démarrer. Quand une demande de service TCP/IP (en réalité TCP ou UDP) arrive sur un port donné, inetd va lancer TCPD (daemon correspondant à Tcpwrapper) au lieu d'activer directement le service demandé (telnetd, ftpd, pop3...).
Tcpd prend en charge la requête et met en place ses mécanismes de contrôle. Il peut par exemple vérifier que les accès depuis la machine cliente sont autorisés. Une fois le traitement terminé il va (s'il y a autorisation) lancer son propre service in.telnetd, in.ftpd, in.imapd....
Sous Linux, tcpd est installé par défaut. On peut voir en consultant le fichier /etc/inetd.conf comment inetd active tcpd.
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
L'administrateur réseau va pouvoir utiliser 2 fichiers: /etc/hosts.allow et /etc/hosts.deny pour filtrer les accès à sa machine.
/etc/hosts.deny: on indique dans ce fichier les services et les hôtes pour lesquels l'accès est interdit.
/etc/hosts.allow: on indique dans ce fichier les services et les hôtes pour lesquels l'accès est autorisé.
Exemple:
# Fichier /etc/hosts.deny # interdit tous les accès ftp à la machine in.ftpd:ALL # Fichier /etc/hosts.allow # autorise les accès ftp venant de cli1 in.ftpd :cli1.archinet.edu
TCP-Wrapper utilise l'algorithme suivant :
Si une règle est applicable dans hosts.allow, alors cette règle est appliquée, sinon, Si une règle est applicable dans hosts.deny alors cette règle est appliquée, sinon, l'accès est autorisé.
Ce mode de fonctionnement induit la stratégie de sécurité à adopter :
décrire toutes les règles pour les couples (services/clients) qui sont autorisés,
interdire systématiquement tout le reste. Mettre par défaut ALL:ALL dans hosts.deny.
Les tentatives d'accès depuis des machines extérieures sont toutes enregistrées dans des fichiers particuliers. Ces enregistrements sont effectués par le processus syslogd qui, à son démarrage, lit le fichier /etc/syslog.conf pour trouver dans quel(s) fichier(s) il doit enregistrer les différentes tentatives d'accès.
# Log anything (except mail) of level info or higher. # Don't log private authentication messages # The authpriv file has restricted access. authpriv.* /var/log/auth.log auth,authpriv.none; /var/log/syslog
Feb 3 18:02:52 ns1 ftpd[1051]: FTP session closed Feb 3 18:03:31 ns1 syslogd 1.3-3: restart. Feb 3 18:07:34 ns1 in.ftpd[1057]: refused connect from cli1.archinet.edu Feb 3 18:07:46 ns1 in.ftpd[1058]: connect from ns1.archinet.edu Feb 3 18:10:57 ns1 login[1063]: LOGIN ON ttyp3 BY mlx FROM puce
Remarques:
La commande kill -HUP pid de sysklogd permet de redémarrer ce processus avec prise en compte des paramètres se trouvant dans /etc/syslog.conf. Il est aussi possible d'invoquer le script de lancement du service en lui passant l'argument restart : /etc/init.d/syslogd restart
Ouvrez le fichier /etc/inetd.conf, vérifiez que les lignes qui activent les démons telnet et ftp sont décommentées.
Vérifier qu'il n'y a aucune règle active dans les fichiers /etc/hosts.allow et /etc/hosts.deny (mettez les règles éventuelles en commentaire)
Pour l'activer manuellement utilisez la commande : /etc/init.d/inetd stop | start
1 - Créez un compte d'utilisateur.
2 - Sur la console, ouvrez une session sous le compte root.
3 - Vous devez pouvoir utiliser les commandes :
«#> ftp localhost » ou « ftp `hostname` » en vous authentifiant avec le compte que vous avez créé «#> telnet localhost » ou « telnet `hostname` » en utilisant le compte que vous avez créé. où `hostname` indique le nom d'hôte de votre machine.
Si ces commandes fonctionnent sur le serveur, réaliser les opérations à partir d'un client distant.
Vous pouvez vérifier le fonctionnement de « tcpwraper »
1 - Interdisez tout dans le fichier /etc/hosts.deny (mettre ALL:ALL à la fin du fichier). Attention, mettez plusieurs retours chariots (CR/LF) à la fin du fichier sinon la dernière ligne n'est pas lue. Vous avez des exemples dans "man 5 hosts_access" ou man "hosts.allow".
2 - Vérifiez que l'accès ftp est maintenant refusé, vérifiez les messages dans /var/log/syslog et /var/log/auth.log
Vous devriez voir, dans les fichiers de log (journaux) les demandes ftp rejetées par TCPWrapper.
Remettez le fichier hosts.deny dans son état initial.
Q - je ne peux pas accéder au serveur en utilisant le compte root.
R - Vous pouvez réaliser cette opération sur la console, mais par mesure de sécurité cette opération n'est pas possible à distance. Avec telnet, ouvrez une session sur un compte d'utilisateur standard, puis la commande « su ».
Q - Je n'arrive pas ouvrir de session Telnet ou FTP.
R - Vérifier le fichier de configuration « /etc/inetd.conf », puis que le serveur inet est bien lancé.
Q - J'ai modifié les fichiers host.allow et host.deny. Les modifications n'ont pas l'air d'être prises en compte.
R - Vérifiez la syntaxe des instructions utilisées dans ces fichiers, normalement la modification des règles est prise en compte dynamiquement sans avoir besoin de relancer le service. Insérez quelques lignes vides à la fin de ces fichiers.
Attention : les services telnet et ftp n'offrent aucune solution de sécurité sur les réseaux (transmission des données en clair). Sur un réseau qui n'est pas sûr vous ne devrez pas utiliser ces services.
Il y a d'autres fichiers de configuration qui permettent de sécuriser le service FTP. Ces fichiers, dans /etc, sont indépendants de TCP Wrapper. Regardez ftpaccess, ftpgroup, ftphosts, ftpusers et leurs pages de manuel. Avec ftpusers, vous pouvez autoriser/interdire l'accès pour un compte en particulier.
Sources de documentation complémentaires
Les pages du manuel de TCPWrapper. man syslog.conf ou man syslogd pour plus de renseignements.
Table of Contents
Abstract
Mode d'utilisation du serveur Unix/Linux. Environnement BTS Informatique deuxième année.
Objectif : Mettre à disposition un environnement à des utilisateurs, gérer les accès aux fichiers, les droits, l'environnement de travail, gérer les groupes..
Contexte : pour cet exercice, on imagine que l'on travaille dans une entreprise dont deux services sont connectés au réseau : le service Commercial, et le service Comptable. L'ambiance au sein du service de comptabilité est assez conviviale, et bien que toutes les informations traitées soient absolument secrètes (et donc interdites en accès à toute autre personne qu'un comptable), ces personnes ont l'habitude de partager leurs données. Concernant les commerciaux, au contraire, tous leurs travaux sont absolument secrets (échanges commerciaux, ristournes et remise, chiffre d'affaires, arrangements divers...)
Pré-requis : Documentation et exercice de Jean Gourdin : Document sur la site linux-keops.com
La séquence de log : lorsqu'un
utilisateur se logue, tout est géré par le programme
login. Ce programme va obéir aux PAM
(Pluggable Authentification Module), qui vont lui indiquer une suite
d'étapes à valider. Ce point, même si il est très intéressant, ne sera pas
étudié ici. Disons simplement que le fichier
/etc/passwd sera certainement lu (si on utilise une
authentification standard et locale, et pas du NIS, ou
du LDAP), et que diverses informations concernant
l'utilisateur seront ainsi récupérées : son nom, son répertoire home, son
programme de connexion.
Le contenu du fichier /etc/profile sera
exécuté (réglages génériques pour tous les utilisateurs). Selon le shell
de connexion, d'autres scripts seront utilisés : si il s'agit d'un shell
de login, et que le shell est bash, alors
~/.bash_profile ou
~/.bash_login ou ~/.profile
seront lus. A la déconnexion, ~/.bash_logout sera
exécuté.
Si il s'agit d'une connexion distante, d'un sous-shell, ou d'un
xterm, alors /etc/bash.bashrc puis
~/.bashrc seront exécutés.
Créez un schéma explicatif des fichiers lus, dans les 2 cas de figures suivants : connexion bash en local, et connexion bash autres (distantes, xterm, etc).
Décodez le contenu de ces fichiers sur votre machine.
Expliquez pourquoi la Debian n'offre pas la visualisation en couleurs des fichiers (ls). Dans votre bash, lancez un nouveau bash. Testez le ls.. Que se passe-t-il ?
Peut être avez vous remarqué le fichier
/etc/bash_completion.
Vous connaissez la complétion, mais celle-ci est encore supérieure : vous le découvrirez dans l'exercice suivant
Connectez-vous sur deux sessions (afin de comparer la différence), et sur l'une d'elles, activez la complétion étendue (tapez . /etc/bash_completion . Attention au point tout seul : très important pour que le script demandé s'exécute dans l'environnement courant, et non dans un fils (les réglages seraient alors perdus).
Testez la complétion étendue avec cd (tab), avec des commandes (apt-get i(tab)), ssh (tab), man ls(tab).
Que remarquez -vous ?
Comment faire pour bénéficier de tout ceci ?
Consultez vos propres fichiers de connexion
(.bash_profile, et
.bashrc). Modifiez
.bash_profile afin qu'il exécute
.bashrc (ainsi, .bashrc est
exécuté toujours, en shell de login ou autre). Puis, dans
.bashrc, dé commentez l'accès à
/etc/bash_completion.
Testez...
Extension de ces réglages à tous les nouveaux utilisateurs (ou 'du
bon usage de /etc/skel')
Dans le répertoire /etc/skel, vous trouverez le squelette de tous les nouveaux comptes : tout ce qui y est présent sera recopié par défaut dans le répertoire de chaque nouvel utilisateur
Quel est le contenu de ce répertoire ?
Modifiez le contenu de /etc/skel comme vous
venez de le faire pour vous. Créez un nouvel utilisateur
(adduser toto). Connectez vous avec toto, et vérifiez
ses réglages.
Imaginons maintenant que nous voulons que tous les nouveaux
utilisateurs se retrouvent avec une structure de home standard (par
exemple, avec un fichier 'mode d'emploi du réseau' et un sous répertoire
public_html déjà prêt pour la publication de pages
web :
Créez ce répertoire et un texte 'mode_d_emploi_du_reseau.txt' dans
le répertoire /etc/skel.
Créez deux nouveaux utilisateurs (foo et bar)
Observez leurs homes.
Gestion des droits : Vous avez certainement remarqué la commande umask. Cette commande définit les droits standards dont seront affublés vos fichiers. Les droits normaux sont 666 pour un fichier, et 777 pour un répertoire. Umask vient en soustraction pour le calcul des droits. L'emploi d'umask seul permet d'afficher la valeur d'umask, et umask XXXX permet de définir l'umask à XXXX.
Dans le contexte décrit, on peut proposer de résoudre le problème
par la création de deux groupes (commerciaux et comptables). Il semble
préférable de créer le home de chaque utilisateur dans
/home/NomDuGroupe, dans un souci de bonne
gestion.
Le comportement par défaut de création des comptes est piloté par
/etc/adduser.conf.
Selon la taille de la population d'utilisateurs à gérer, on pourra modifier ce fichier pour adapter la gestion à nos besoins. Dans notre cas, on utilisera des groupes : on créera des groupes, et on créera des utilisateurs dans ces groupes.
Modification du fichier
/etc/adduser.conf
Ce fichier définit le fonctionnement par défaut, il est suffisamment documenté pour que vous puissiez vous débrouiller seul. On peut y définir le shell de connexion proposé par défaut, le nom du répertoire contenant les home directories, l'endroit des squelettes, etc...
Expliquez ce que sont les LETTERHOMES, le rôle des directives
commençant par FIRST. Comment faire pour que les homes soient créées
dans un sous-répertoire de home portant le nom du groupe ? (tous les
homes des comptables dans un sous répertoire
/home/comptables)
L'ajout de groupes et d'utilisateurs se fait respectivement par les commandes addgroup et adduser. Consultez le man de ces commandes. Faites le réglage du adduser.conf correspondant, et testez l'ajout de deux groupes (testprofs et testetudiants), puis de quelques utilisateurs (profs et étudiants)
Testez ensuite le bon fonctionnement, en vous connectant en tant que certains de ces utilisateurs.
Supprimez ensuite tous ces utilisateurs, ainsi que leurs répertoires (man userdel)
Les commandes chmod, chown et chgrp permettent d'attribuer, de modifier des droits sur les objets du file system (fichiers et répertoires)
(faire un man)
D'autre part, un utilisateur peut appartenir à plusieurs groupes (un groupe principal, et d'autres additionnels)
Cela permet une certaine souplesse dans les droits, bien que seule l'utilisation des ACLs puisse permettre de tout gérer (au prix d'une dangereuse complexité).
Pour ajouter un utilisateur dans un groupe additionnel, utilisez adduser user groupAdditionnel.
Vous pourrez alors donner des droits à ce groupe, et l'OS évaluera les droits de chaque utilisateur par rapport à l'ensemble de ses groupes
Créez l'ensemble des comptes selon les régles définies en début de cet exercice : Les commerciaux (Bill, Bob, Carlos, Richard, Laura) et les comptables (Raymond, Georgette, Carlotta, Paula).
Ces utilisateurs peuvent avoir un site web (pensez à créer le
public_html). Le système de gestion de courrier
demande à avoir un répertoire MailDir dans chacun des homes.
Les chefs de services (Bill et Raymond) ont la possibilité d'alimenter le site web (création de pages...) tandis que les utilisateurs ne peuvent que consulter.
Table of Contents
Relevez dans /etc/services les ports utilisés par les services telnet, ftp, pop3, dns, smtp, http.
Installez et testez les services telnet et ftp à partir de votre poste puis à partir d'un autre poste. Utilisez les traces dans les journaux pour identifier les problèmes.
tail -f /var/log/syslog
Utilisez TcpWrapper pour autoriser/interdire le service telnet, le service ftp, tous les services. Vous testerez l'accès à partir de votre poste, d'un autre poste.
Attention : Pensez à relancer un service serveur chaque fois que vous avez modifié son fichier de configuration, ceci est vrai pour tous les services et ne sera plus répété. En général utilisez la manipulation suivante "/etc/init.d/NomDuService start | stop | status | restart"
Il est possible que le client ftp soit remplacé par un autre programme comme "lftp" par exemple. C'est ce programme qui sera utilisé dans le TP, vous adapterez si vous utilisez autre chose. Fondamentalement ça ne changera rien, mais lftp est beaucoup plus riche fonctionnellement que les clients ftp standard. Il supporte 6 méthodes d'accès ftp, ftps, http, https, hftp et fish.
La freeduc-sup est configurée pour ne pas supporter les transactions et protocoles "non-sûrs". Si vous utilisez un client autre comme une knoppix par exemple,vous devrez installer le support ssl.
apt-get install telnetd-ssl
Relevez le port utilisé par telnet dans le fichier /etc/services
Décommentez la ligne qui concerne telnet dans /etc/inetd.conf et relancez le service.
Vérifiez que le port est bien ouvert avec la commande netstat :
#> netstat -atup | grep LISTEN
Vérifiez que rien dans TCP-Wrapper n'interdit l'accès au service telnet.
# Mettre dans /etc/hosts.allow ALL:ALL
Testez l'accès au service telnet.
Interdisez tous les accès dans TCP-Wrapper, testez.
# Commentez toutes les lignes dans /etc/hosts.allow # Mettez dans /etc/hosts.deny ALL:ALL
En vous aidant des exemples donnés dans "man hosts.allow", autorisez l'accès pour une machine du réseau sur le service telnet, interdisez-le pour toutes les autres, testez.
L'accès authentifié est simple à mettre en oeuvre.
Relevez les ports utilisés par ftp dans /etc/services.
Activez le service dans inetd.conf et lancez le service.
Vérifiez que le port est bien ouvert avec la commande netstat
Vérifiez que rien n'interdit l'accès au service ftp dans les fichiers hosts.allow et hosts.deny
Faites un test en utilisant un compte système existant, par exemple "lftp localhost -u util" si util est votre compte.
Normalement c'est terminé, tout doit fonctionner. Si cela ne fonctionne pas, vérifiez que vous n'avez rien oublié, vérifiez aussi les fichiers de log (/var/log/daemon, /var/log/syslog, /var/log/messages)
La mise en place d'un service ftp anonyme demande plus de manipulations. Vous allez mettre l'environnement dans /home.
Vérifiez que le fichier /etc/passwd dispose bien d'un compte ftp :
knoppix@master:~/tmp$ grep ftp /etc/passwd ftp:x:1003:1003:Compte ftp anonyme:/home/ftp:/bin/true
sinon modifie les fichier "/etc/passwd" pour ajouter la ligne. Attention, prenez un "UID" libre.
Créez un compte de groupe dans le fichier /etc/group :
knoppix@master:~/tmp$ grep ftp /etc/group ftp:x:1003:
Utilisez la commande "pwconv" pour mettre à jour le fichier shadow.
Remarque si vous avez des problèmes d'accès sur le serveur ftp anonyme par la suite : Il s'agit peut être d'un problème de définition du compte dans le fichier "/etc/shadow". Vous pouvez pour cela utiliser plusieurs options : A) Première option 1 - taper "pwunconv" 2 - modifier le fichier "/etc/passwd" comme indiqué ci-dessus 3 - taper "pwconv" pour "recacher" les mots de passe. B) Deuxième option 1 - utiliser la commande "adduser ftp" qui va mettre les fichiers "/etc/passwd" et "/etc/shadow" à jour. Mettez un mot de passe bidon. 2 - taper "pwunconv" et supprimer le mot de passe du compte dans "/etc/passwd" (mettre "*" par exemple) 3 - remplacer aussi le shell "/bin/bash" par "/bin/true", enregistrer. 4 - taper "pwconv" pour "recacher" les mots de passe. 5 - supprimer /home/ftp (rm -rf /home/ftp) 6 - continuer la procédure ci-dessous.
Sous le compte root vous allez créer l'environnement pour le service ftp :
cd /home && mkdir -p ftp/lib ftp/bin ftp/pub ftp/incoming ftp/etc
On copie le programme ls dans ~ftp/bin. Vous pouvez en mettre d'autres, mais soyez prudent.
cp /bin/ls ftp/bin
Il reste à créer les comptes dans un fichier local passwd et group. On y met juste les comptes nécessaires pour l'utilisation des programmes mis dans ~ftp/bin.
root@master:/home# grep ftp /etc/group > ftp/etc/group root@master:/home# grep root /etc/passwd > ftp/etc/passwd root@master:/home# grep ftp /etc/passwd > ftp/etc/passwd
Vérifiez que vous avez bien les informations dans les fichiers ftp/passwd et ftp/group.
On change les permissions
chmod -R 111 ftp/bin ; chmod 111 ftp/etc; chmod 444 ftp/etc/*;\ chmod 555 ftp/pub; chmod 1733 ftp/incoming
On rajoute dans ~ftp/lib les librairies utilisées par les programmes mis dans ~ftp/bin. Vous avez, vous le programme "ls". Les librairies utilisées par le programme ls sont visibles avec la commande "ldd".
Si vous ajoutez d'autres programmes, il faudra y mettre également les bonnes librairies.
root@master:/home# ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x4001f000)
libc.so.6 => /lib/libc.so.6 (0x40031000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40141000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Il faut donc copier toutes ces librairies dans ~ftp/lib.
cp /lib/librt.so.1 /lib/libc.so.6 /lib/libpthread.so.0 /lib/ld-linux.so.2 ftp/lib
Voici donc ce que vous devriez avoir à la fin:
root@master:/home# ls -alR ftp root@mr:/home# ls -alR ftp ftp: total 28 drwxr-sr-x 7 root root 4096 2003-09-19 12:19 . drwxrwsr-x 7 root root 4096 2003-09-19 12:21 .. d--x--x--x 2 root root 4096 2003-09-19 12:22 bin d--x--x--x 2 root root 4096 2003-09-19 12:19 etc drwx-wx-wt 2 root root 4096 2003-09-19 12:19 incoming drwxr-sr-x 2 root root 4096 2003-09-19 12:21 lib dr-xr-xr-x 2 root root 4096 2003-09-19 12:19 pub ftp/bin: total 76 d--x--x--x 2 root root 4096 2003-09-19 12:22 . drwxr-sr-x 7 root root 4096 2003-09-19 12:19 .. ---x--x--x 1 root root 64428 2003-09-19 12:22 ls ftp/etc: total 16 d--x--x--x 2 root root 4096 2003-09-19 12:19 . drwxr-sr-x 7 root root 4096 2003-09-19 12:19 .. -r--r--r-- 1 root root 12 2003-09-19 12:19 group -r--r--r-- 1 root root 87 2003-09-19 12:19 passwd ftp/incoming: total 8 drwx-wx-wt 2 root root 4096 2003-09-19 12:19 . drwxr-sr-x 7 root root 4096 2003-09-19 12:19 .. ftp/lib: total 1296 drwxr-sr-x 2 root root 4096 2003-09-19 12:21 . drwxr-sr-x 7 root root 4096 2003-09-19 12:19 .. -rwxr-xr-x 1 root root 82456 2003-09-19 12:22 ld-linux.so.2 -rwxr-xr-x 1 root root 1104040 2003-09-19 12:22 libc.so.6 -rw-r--r-- 1 root root 81959 2003-09-19 12:22 libpthread.so.0 -rw-r--r-- 1 root root 26592 2003-09-19 12:22 librt.so.1 ftp/pub: total 8 dr-xr-xr-x 2 root root 4096 2003-09-19 12:19 . drwxr-sr-x 7 root root 4096 2003-09-19 12:19 ..
C'est normalement terminé.
Activez le service dans inetd.conf et lancez le service inetd si ce n'est pas déjà fait.
Vérifiez que le port est bien ouvert avec la commande netstat
root@mr:/home# netstat -atup | grep LISTEN tcp 0 0 *:ftp *:* LISTEN 879/inetd
Vérifiez que rien n'interdit l'accès au service ftp dans les fichiers hosts.allow et hosts.deny
Commentez le fichier /etc/ftpusers comme ci-dessous :
# /etc/ftpusers: list of users disallowed ftp access. See ftpusers(5). root #ftp #anonymous
Testez et vérifiez le bon fonctionnement de l'accès ftp anonyme (en utilisant le compte "ftp" ou "anonymous" avec la commande :
lftp localhost -u anonymous ou lftp localhost -u ftp
Si la configuration est correcte, vous devriez avoir le résultat suivant :
root@master:/home# lftp localhost -u ftp Mot de passe: #Il n'y a pas de mot de passe, faites ENTREE lftp ftp@localhost:~> ls total 20 d--x--x--x 2 0 0 4096 May 5 03:35 bin d--x--x--x 2 0 0 4096 May 5 03:35 etc drwx-wx-wt 2 0 0 4096 May 5 03:04 incoming dr-xr-xr-x 2 0 0 4096 May 5 03:32 lib dr-xr-xr-x 2 0 0 4096 May 5 03:04 pub
Commentez la ligne anonymous dans le fichier /etc/ftpusers et refaites un essai de connexion.
Faites un test en utilisant un compte système existant, par exemple "lftp localhost -u util" si util est votre compte.
Restaurez l'état initial du fichier /etc/ftpusers.
Interdisez l'accès ftp avec TCP-Wrapper. Testez avec l'accès anonyme et en utilisant un compte authentifié.
Que peut-on conclure des deux méthodes de protection ?
On désactive en général ces services sauf cas très particulier, car les transactions ne sont pas cryptées. On préfère utiliser les services ssh, scp et sftp. Vous devez avoir un service sshd actif sur le serveur.
Exemple d'utilisation ssh :
[root@uranus etc]# grep ssh /etc/services ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp # SSH Remote Login Protocol ssh -l NomUtilisateur Machine ssh -l mlx localhost
Remarque : Sur la version Live-On-CD, vous devez lancer le démon, car il n'est pas actif par défaut : /etc/init.d/sshd start. Le lancement de ce serveur permet l'utilisation de ssh et de scp à partir de clients.
Exemple d'utilisation de sftp :
[root@uranus etc]# grep sftp /etc/services sftp 115/tcp sftp 115/udp [root@uranus etc]# sftp usage: sftp [-1vC] [-b batchfile] [-osshopt=value] [user@]host[:file [file]] [root@uranus etc]# sftp mlx@localhost Connecting to localhost... mlx@localhost's password: Vous pouvez ensuite envoyer ou récupérer des fichiers entre les 2 machines.
Exemple d'utilisation de scp :
SYNOPSIS
scp [-pqrvC46] [-S program] [-P port] [-c cipher] [-i identity_file]
[-o option] [[user@]host1:]file1 [...] [[user@]host2:]file2
# Exporte le fichier "unfichierlocal"
scp -S ssh unfichierlocal mlx@hotedistant:/un/chemin/distant/unfichierdistant
# Importe de "hotedistant", le fichier distant "unfichierdistant"
scp -S ssh mlx@hotedistant:/un/chemin/distant/unfichierdistant unfichierlocal
La première ligne exporte un fichier, la deuxième importe. Le compte utilisé est mlx. La transaction est encryptée avec ssh.
Table of Contents
Abstract
Approche de ssh, des tunnels et des services mandataires
Un des principaux risques sur les réseaux provient de "l'écoute" possible puisque toutes les données transitent, si rien n'est fait, en clair sur les résaeux. C'est à dire qu'elles ne sont pas cryptées.
Il est ainsi possible de récupérer sans difficulté les mots de passe des personnes utilisant le réseau, leur messages, et d'espionner toutes leurs transactions, y compris celles passées sur des serveurs HTTP. Ceci est lié à la méthode d'accès des réseaux. Le principe de la commutation par switch permet de limiter un peu les risques mais n'est pas imparable.
Il existe des solutions permettant de sécuriser un minimum les
transactions. Nous allons voir rapidement quelques modes d'utilisation de
ssh et de logiciels comme scp, sftp, unisson et rsync
afin de voir comment évoluer dans un environnement plus sûr.
Il sera fait référence à la maquette suivante :
Qu'est ce que ssh ?
En fait ssh ou Secure SHell, propose un shell sécurisé pour les connexions à distance et se présente dans ce domaine comme le standard "de fait". Mais ce n'est pas que cela. Nous allons essayer de voir quelques modes d'utilisation de ce produit.
Dans une transaction traditionnelle, un client (personne ou programme) émet une requête TCP vers un serveur. Il y a un processus serveur utilisant un port et un processus client utilisant également un port. Par exemple pop3. Il y a donc un processus serveur et un processus client.
Avec ssh, il sera possible d'établir un tunnel crypté (ou chiffré) entre le client et le serveur.
Il faut bien comprendre ce dont il s'agit et les processus mis en oeuvre.
Sur la machine serveur vous allez avoir 2 processus serveurs. Le serveur pop3 et le serveur SSH. Sur le client, vous allez également avoir 2 processus. Le client pop3 et le client ssh. Le client pop3 se connecte au tunnel (le client ssh local). Le serveur pop3, est relié au serveur ssh distant. Les transactions passent dans le tunnel.
Le client ssh devient un serveur mandataire (proxy) pour le protocole tunnelé. Le serveur ssh devient le client proxy pour le serveur.
Sur le diagramme, le canal entre le port tcp de l'application cliente et le port client du tunnel n'est pas chiffré. Il en est de même entre le port tcp de l'application serveur et le port serveur du tunnel. Seul, le canal entre les 2 ports du tunnel est chiffré.
L'application cliente n'utilise plus le port par défaut qu'écoute normalement le serveur.
L'utilisation d'un tunnel ssh impose des contraintes. Par exemple, dans l'exemple ci-dessus, si vous voulez utiliser l'application cliente avec un autre serveur, il faudra recréer un autre tunnel et reconfigurer le client. Vous pouvez créer deux tunnels différents, mais vous devrez avoir deux applications clientes utilisant des ports différents. Tout cela convient bien sur des environnements simples, mais reste un peu contraignant si l'environnement est complexe.
Pour tunneler un réseau ou de multiples clients, le mieux est d'installer un serveur ssh capable de recevoir plusieurs connexions et servant ainsi de serveur proxy aux clients du réseau pour un service donné et routant les requêtes dans un tunnel sécurisé vers le serveur d'application concerné.
L'objectif est de pouvoir supprimer d'un serveur toute application utilisant des protocoles "non sûrs" (ftp, telnet, rsh...), pour les remplacer par des applications plus sûres, ou alors, s'il n'est pas possible de les désactiver, de les faire passer dans un tunnel crypté.
Des programmes de la même famille comme "scp" ou "sftp" remplacent les commandes ftp ou rcp.
Avec ssh la totalité de la transaction entre un client et le serveur est cryptée. Le client a la possibilité d'utiliser des applications X distantes (X11 forwarding) à partir d'une invite shell dans un environnement sécurisé. On se sert également de SSH pour sécuriser des transactions non sûres comme pop3 ou imap par exemple. De plus en plus, ces applications supportent maintenant SSL aussi bien pour les clients que pour les serveurs.
SSH sur GNU/Linux est généralement composé de 3 packages :
OpenSSH général, (openssh), le serveur OpenSSH (openssh-server) le client (openssh-clients).
Les packages OpenSSH requièrent le paquetage OpenSSL (openssl).
Chaque fois que cela est possible vous devez utiliser une solution qui chiffre vos transactions.
L'établissement du dialogue entre le client et le serveur suit un protocole particulier :
établissement d'une couche transport sécurisée
chiffrement des données à l'aide de clefs symétriques pendant la transaction
Le client peut s'authentifier en toute sécurité, et accéder aux applications conformes aux spécifications du protocole.
La couche transport assure le chiffrement et le déchiffrement des données. Elle assure également la compression pour améliorer le transfert. Le client et le serveur négocient plusieurs éléments afin que la session puisse s'établir.
l'échange des clés
l'algorithme de clé publique à utiliser
l'algorithme de chiffrement symétrique à utiliser
l'algorithme d'authentification de message à utiliser
l'algorithme repère (hash) à utiliser
Lors du premier échange, le client ne connaît pas le serveur. Le serveur propose alors une clé hôte qui servira par la suite au client de moyen d'identification du serveur.
M0:$ ssh -l mlx M1.foo.org Warning: Permanently added 'M1,x.y.z.t' (DSA) to the list of known hosts. mlx@M1.foo.org's password: Last login: Sat Nov 2 11:37:32 2002 from 212.47.248.114 Linux 2.2.19. mlx@M1.foo.org:$
Voilà une idée de ce que cela donne :
freeduc-sup.alt.eu.org,144.85.15.72 ssh-rsa AAAAB3NzaC1y (...) pegase,195.115.88.38 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIE (...) freeduc-sup.eu.org,137.194.161.2 ssh-dss AAAAB3NzaC1kc3M (...) (...)
Le risque de ce processus, vient donc surtout de la première transaction, où le client n'a pas le moyen d'identifier de façon fiable le serveur avec qui il communique. Un pirate peut dans certains cas, tenter de détourner cette opération. Au cours d'un échange, le client et le serveur modifient régulièrement leurs clés. A chaque opération de renouvellement de clé, un pirate qui aurait réussi à décrypter les clés, devrait refaire toute l'opération.
Authentification :
Une fois le tunnel sécurisé mis en place, le serveur envoie au client les différentes méthodes d'authentification qu'il supporte. Dans le cadre d'une authentification par mot de passe, celui-ci peut être envoyé en toute sécurité puisqu'il est chiffré.
Connexion :
Une fois l'authentification réalisée, le tunnel SSH peut multiplexer plusieurs canaux en délégant la tâche à des agents.
[mlx@M1 X11]$ pstree -l 24245
sshd---bash-+-drakfw
|-pstree
|-2*[xclock]
`-xlogo
Ici on voit dans la même session ssh, 2 canaux pour xclock, 1 pour xlogo et 1 pour la commande pstree. Chaque canal est numéroté. Le client peut fermer un canal sans pour autant fermer toute la session.
OpenSSH est constitué de deux ensembles de fichiers de configuration, comme c'est en général le cas sur les services sous linux (ldap, samba..). Il y a un fichier de configuration pour les programmes clients (ssh, scp et sftp) et l'autre pour le service serveur(sshd). Les informations de configuration SSH qui s'appliquent à l'ensemble du système sont stockées dans le répertoire /etc/ssh. Voici les principaux fichiers de configuration :
ssh_config fichier de configuration client SSH pour l'ensemble
du système. Il est écrasé si un même fichier est
présent dans le répertoire personnel de
l'utilisateur
(~/.ssh/config).
sshd_config fichier de configuration pour sshd.
ssh_host_dsa_key clé DSA privée utilisée par sshd.
ssh_host_dsa_key.pub clé DSA publique utilisée par sshd.
ssh_host_key clé RSA privée utilisée par sshd pour la
version 1 du protocole SSH.
ssh_host_key.pub clé RSA publique utilisée par sshd pour la
version 1 du protocole SSH.
ssh_host_rsa_key clé RSA privée utilisée par sshd pour la
version 2 du protocole SSH.
ssh_host_rsa_key.pub clé RSA publique utilisée par sshd pour la
version 2 du protocole SSH.
Les informations spécifiques à un utilisateur sont stockées dans son répertoire personnel à l'intérieur du répertoire ~/.ssh/:
authorized_keys ou parfois authorized_keys2
ce fichier contient une liste de clés
publiques "autorisées". Si un utilisateur
se connecte et prouve qu'il connaît la clé
privée correspondant à l'une de ces clés,
il obtient l'authentification. Notez qu'il
ne s'agit que d'une méthode d'authentification
facultative.
id_dsa contient l'identité d'authentification
DSA de l'utilisateur.
id_dsa.pub la clé DSA publique de l'utilisateur.
id_rsa la clé RSA publique utilisée par sshd pour
la version 2 du protocole SSH.
identity la clé RSA privée utilisée par sshd pour la
version 1 du protocole SSH.
known_hosts ce fichier contient les clés hôte DSA des
serveurs SSH auxquels l'utilisateur s'est connecté.
Exemple sur une machine :
mlx@M1:~$ ls -al .ssh/ total 16 drwx------ 2 mlx mlx 4096 Jan 16 2004 ./ drwxr-xr-x 5 mlx mlx 4096 Oct 18 16:12 ../ -rw------- 1 mlx mlx 1192 Mar 11 2004 authorized_keys2 -rw------- 1 mlx mlx 240 Jan 16 2004 known_hosts
Nous allons faire nos premières expérences avec ssh. Il vous faut un client et un serveur. C'est mieux.
L'idée est de mettre en place une procédure entre un client et un serveur qui garantit des transactions sécurisées. A la fin, vous pourrez utiliser les ressources du serveur distant dans un tunnel, sans avoir à vous authentifier à chaque fois.
Pour ceux qui ont déjà utilisé les commandes rlogin, rsh, rcp... et les fichiers .rhosts, le principe est identique. La différence fondamentale est que, avec ssh, tout est crypté.
Pour cela vous devez mettre en place les clés qui serviront à ssh pour vous authentifier. Concrètement cela consiste à définir une paire de clés, une publique que vous mettrez sur le serveur distant, une privée que vous conserverez sur votre machine.
La première chose à faire est de vous créer une clé. Voyons comment réaliser cela.
Tout d'abord allez dans votre répertoire personnel.
$ cd $ ssh-keygen -t dsa $ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/mlx/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/mlx/.ssh/id_dsa. Your public key has been saved in /home/mlx/.ssh/id_dsa.pub. The key fingerprint is: 5c:d9:d8:c5:3d:8d:0b:10:33:42:9c:83:45:a1:d0:61 mlx@neptune.foo.org
Vérification de .ssh. Attention il y a un "." devant ssh
[mlx@neptune mlx]$ ls -alR .ssh .ssh: total 20 drwx------ 2 mlx mlx 4096 nov 11 18:19 ./ drwx--x--x 37 mlx mlx 4096 nov 11 18:09 ../ -rw------- 1 mlx mlx 736 nov 11 18:19 id_dsa -rw-r--r-- 1 mlx mlx 616 nov 11 18:19 id_dsa.pub -rw-r--r-- 1 mlx mlx 1956 nov 10 19:38 known_hosts
Cette commande a généré une clé DSA par défaut de 1024 bits. La clé privée sera stockée dans ~/.ssh/id_dsa et la clé publique dans ~/.ssh/id_dsa.pub.
Si vous voulez générer une clé RSA2, utilisez l'option "-t rsa" et pour du RSA1 "-t rsa1". Vous devrez entrer une "passphrase". Entre 10 et 30 caractères. Mélangez majuscules, minuscules et chiffres. La clé privée doit ensuite être mise en lecture seule pour le propriétaire et aucun accès pour les autres.
Pour modifier votre "passphrase" sur une clé privée DSA, utilisez la commande :
M0:$ ssh-keygen -p -f ~/.ssh/id_dsa Enter old passphrase: Key has comment '/home/mlx/.ssh/id_dsa' Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase.
Attention, il ne faut pas oublier la "passphrase", elle vous sera redemandée. Il va falloir maintenant copier la clé publique vers le ou les serveurs distants. Il est préférable que vous ayez un compte, sinon vous devrez demander à l'administrateur distant de réaliser la procédure.
La clé publique, doit être copiée sur le serveur distant dans ~/.ssh/authorized_keys. La clé privée reste sur votre poste client. Vous pouvez mettre plusieurs clés publiques sur le serveur, si vous le souhaitez ou si vous accédez au serveur avec plusieurs comptes d'accès différents.
Copiez la clé avec scp sur le compte que vous avez sur le serveur :
MO:$ cat .ssh/id_dsa.pub | ssh mlx@M1.foo.org \
"cat - >>.ssh/authorized_keys[2]"
# Attention, sur certaines machines, le fichier se nomme
# authorized_keys, sur d'autres authorized_keys2
# Dasn l'exemple qui est donné, le répertoire .ssh doit exister.
Warning: Permanently added 'M1.foo.org' (RSA) to the list of known hosts.
mlx@M1.foo.org's password:
Le système demande votre mot de passe.
Elle est transférée. On doit pouvoir maintenant réaliser des opérations (commandes) comme scp sur le serveur distant, sans avoir à saisir de mot de passe. Ici on va faire un "ls", sans ouvrir de session sur la machine distante.
M0:$ ssh mlx@M1.foo.org ls Enter passphrase for key '/home/mlx/.ssh/id_dsa': d1 d2 d3 d4
Le système distant ne demande plus le mot de passe, par contre il demande la "passphrase". Il va falloir aussi essayer de se passer de ça, car s'il est fastidieux de saisir son mot de passe, il est encore plus embêtant de saisir une "passphrase". Nous verrons comment se passer de ça avec un agent.
Remarque : Envoyer une clé par mail n'est pas un système sûr, et même chiffré et signé cela ne garantit pas au destinataire que vous en êtes l'émetteur s'il ne vous a jamais vu. L'administrateur distant peut demander à ce que l'envoyeur justifie qu'il est bien celui qui a envoyé la clé. Il suffit pour cela de téléphoner à l'administrateur et de communiquer "la signature ou empreinte" (finger print) de la clé (ou par sms). On utilise le même procédé pour identifier et vérifier la validité des clés gpg.
Pour obtenir le "finger print" d'une clé utiliser la commande :
M0:$ ssh-keygen -l Enter file in which the key is (/home/mlx/.ssh/id_rsa): .ssh/id_dsa 1024 5c:d9:d8:c5:3d:8d:0b:10:33:42:9c:83:45:a1:d0:61 .ssh/id_dsa.pub M0:$ ssh-keygen -l Enter file in which the key is (/home/mlx/.ssh/id_rsa): .ssh/id_dsa.pub 1024 5c:d9:d8:c5:3d:8d:0b:10:33:42:9c:83:45:a1:d0:61 .ssh/id_dsa.pub
L'utilisation d'un agent, évite d'avoir à retaper la "passphrase" à chaque fois que l'on sollicite l'utilisation de la clé privée. Un agent stocke en mémoire les clés privées. Voici comment activer un agent :
M0:$ ssh-agent
La commande met sur la sortie standard des variables environnement à déclarer et à exporter. Faites le.
M0:$ SSH_AUTH_SOCK=/tmp/ssh-XXXB76f4/agent.2888; export SSH_AUTH_SOCK; M0:$ SSH_AGENT_PID=2889; export SSH_AGENT_PID; M0:$ echo Agent pid 2889;
On va maintenant exporter les clés. Cela consiste à les mettre dans le cache de l'agent avec la commande ssh-add. La commande demandera la "passphrase"..
M0:$ ssh-add Enter passphrase for /home/mlx/.ssh/id_dsa: Identity added: /home/mlx/.ssh/id_dsa (/home/mlx/.ssh/id_dsa)
On vérifie maintenant la connexion.
M0:$ ssh mlx@M1.foo.org ls d1 d2 d3 d4
Nous n'avons plus besoin de taper le mot de passe, ni la "passphrase". Pour supprimer une clé (ici RSA) de l'agent, utilisez l'option "-d"
M0:$ ssh-add -d ~/.ssh/id_rsa Utilisez l'option -D pour supprimer toutes les clés de l'agent. Utilisez l'option -l pour savoir quelles clés sont chargées par l'agent.
Cela peut être automatisé dans un script.
"ssh-agent" est un daemon dont le but est d'intercepter la clé publique lorsque le programme "ssh-add" la lit après avoir demandé la passphrase. "ssh-agent" doit ensuite transmettre la clé aux processus dont il est le "père" du point de vue du système. "ssh-agent" fait bénéficier les processus fils (fork) de ses propriétés.
Pour étendre cela aux sessions X, si vous lancez l'interface graphique manuellement, cela deviendra par exemple :
M0:$ ssh-agent xinit ou M0:$ ssh-agent startx
Dans tous les cas, il est nécessaire que les variables d'environnement soient définies avant le lancement du serveur X, qui les exportera par défaut à l'ensemble de vos applications graphiques (lancées sous X).
Cela peut aussi être fait dans le fichier startx ou bien ~/.xinitrc ou bien ~/.xsession, en résumé avant le lancement de votre gestionnaire de fenêtres. Par exemple, si c'est le fichier ~/.xinitrc qui lance le gestionnaire de fenêtres, il ressemblera à ceci:
#!/bin/sh ssh-agent -s > /tmp/ssh.keys # pour y mettre les variables environnement . /tmp/ssh.keys # Exporter les variables rm /tmp/ssh.keys # Faire le ménage après startx
Ainsi, au prochain lancement d'un serveur X, vous n'aurez plus
qu'à ouvrir une fenêtre xterm et taper la commande:
ssh-add
Une autre solution consiste à mettre dans son .xinit ou .xsession :
/usr/local/bin/ssh-add $HOME/.ssh/id_dsa < /dev/null
La commande ssh-add demande la passphrase
Pour les sessions xdm par exemple, modifier les fichiers de démarrage :
#Au début de /etc/X11/Xsession:
AGENT=$(type -p ssh-agent)
if [ -x "$AGENT" -a -z "$SSH_AUTH_SOCK" ]; then
if [ -r $HOME/.ssh/identity -o -r $HOME/.ssh2/identification \
-o -r $HOME/.ssh/id_dsa -o -r $HOME/.ssh/id_rsa ]; then
SSH_AGENT="$AGENT --"
fi
fiAvant d'aller plus loin il est important de bien comprendre ce qu'est le "port forwarding".
Nous avons vu qu'il y avait en jeu :
- l'application cliente
- l'application serveur
- le client ssh
- le serveur ssh
Nous allons voir la redirection locale '-L' et distante '-R'. La différence vient du sens de la connexion. Dans le relayage local, le client tcp et le client ssh sont sur la même machine. Dans le relayage distant ou "remote", le client ssh est sur la même machine que le serveur tcp.
Dans la démarche qui suit, on utilise un client M0 et deux serveurs M1 et M2. On considère que sur chaque serveur fonctionne un serveur ssh. On considère aussi que sur chaque machine on dispose d'un compte d'accès sur chaque machine identique avec les clés publiques installées. Cela évite une authentification à chaque commande ou l'utilisation de l'option '-l' pour préciser le compte à utiliser sur le serveur.
Si on considère ces 3 machines : M0, la machine cliente, M1 et M2, des serveurs. La syntaxe de la commande est la suivante :
ssh -L port-local:HOSTNAME:port-distant machine-distante
la commande est passée sur M0.
M0:$ ssh -L 1234:HOSTNAME:80 M1
La commande ouvre une connexion entre le M0:1234 vers HOSTNAME:80 en utilisant le serveur sshd M1:22 (actif sur M1 et sur le port 22). Tout dépend de la valeur que va prendre HOSTNAME. HOSTNAME indique la machine distante sur lequel s'opére la connexion.
Si HOSTNAME est localhost :
M0:$ ssh -L 1234:localhost:80 M1
Ici localhost indique l'adresse de loopback de la machine distante, c'est à dire ici M1 et sur laquelle tourne le serveur sshd. C'est donc M0:1234 qui est tunnélé vers le port M1:80 en utilisant le service M1:22.
Si HOSTNAME est M1 :
M0:$ ssh -L 1234:M1:80 M1 :-/
La connexion est identique mais utilisera l'adresse de la M1 (interface réseau ) plutôt que l'interface lo.
Si HOSTNAME est M0 :
M0:$ ssh -L 1234:M0:80 M1
La commande connecte M1 sur M0:80.
Si HOSTNAME est M2 :
M0:$ ssh -L 1234:M2:80 M1
Il y aura une connexion (un tunnel créé) entre M0 et M1 mais la redirection est effectuée entre M1:1234 et M2:80 en utilisant M1:22. Les transactions sont chiffrées entre M0 et M1, mais pas entre M1 et M2, sauf si un second tunnel ssh est créé entre M1 et M2.
Les redirections de ports ne sont accessibles en théorie que pour les processus locaux (localhost) (pour nous M0). Si la redirection était possible pour des clients (MX ou MY) ou des requêtes distantes qui viendraient se connecter su rM0:1234 dans notre exemple, ces clients pourraient être surpris de se voir re-routés. (Sans parler de risques pour la sécurité car cela signifie que d'autres personnes pourraient utiliser à notre insu le tunnel que nous venons de créer. Prenons un exemple :
MO$ ssh -L 1234:M1:80 M1
les requêtes locales passées sur M1:1234 sont redirigées vers M1:80, mais des requêtes passées d'autres machines sur M0:1234 ne seront pas, par défaut redirigées.
Il est possible toutefois de passer outre avec l'option '-g' qui autorise des clients distants à se connecter à des ports locaux redirigés.
MO$ ssh -g -L 1234:M2:80 M1
La commande "lynx http://M0:1234" lancé à partir d'une machine tierce (MX ou MY) redirigera vers M2:80.
Une utilisation de cette fonction sera vue en application un peu plus loin.
Ici le client ssh et le serveur TCP sont du même côté. La syntaxe de la commande est la suivante :
ssh -R port-distant:HOSTNAME:port-local machine-distante
Le port distant est donc sur la machine distante (remote)
On reprend les mêmes machines que précédemment :
M0:$ ssh -R 1234:HOSTNAME:80 M1
Ici M0 à le serveur TCP, il sert donc de relais entre une connexion M1:1234 et HOSTNAME:80. La connexion est chiffrée entre M1 et M0. Le chiffrement entre M0 et HOSTNAME dépend de la liaison mise en place.
Si HOSTNAME est localhost, alors on a :
M0:$ ssh -R 1234:localhost:80 M1
Cela ouvre une connexion depuis M1:1234 vers M0:80 car localhost correspond, ici, à M0. Si un utilisateur passe une requête sur M1:1234, elle sera redirigée vers M0:80.
Si HOSTNAME est M2, on a :
M0:$ ssh -R 1234:M2:80 M1
Cela ouvre une connexion entre M0 et M1:22, mais les requêtes allant de M1:1234 sont redirigés sur M2:80. Le canal est chiffré entre M1 et M0, mais pas entre M0 et M2.
Enfin dernière remarque, il est possible de passer en paramètre le compte à utiliser sur le serveur qui fait tourner le serveur sshd.
Cette option permet par exemple de donner, à des machines distantes, un accès à un service sur une machine inaccessible autrement.
SSH permet de "tunneler" des protocoles applicatifs via la retransmission de port. Lorsque vous utilisez cette technique, le serveur SSH devient un conduit crypté vers le client SSH.
Cela représente un des plus importants intérêt de SSH. Permettre la création de tunnels "sûrs" pour des protocoles de transports "non sûrs". Ce principe est utilisé pour des applications comme pop, imap, mais également pour des applications X Window.
La retransmission de port mappe (redirige) un port local du client vers un port distant du serveur. SSH permet de mapper (rediriger) tous les ports du serveur vers tous les ports du client.
Pour créer un canal de retransmission de port TCP/IP entre 2 machines qui attend les connexions sur l'hôte local, on utilise la commande suivante :
ssh -L port-local:HOSTNAME:port-distant nomutilisateur@nomhôte
Une fois que le canal de retransmission de port est en place entre les deux ordinateurs, vous pouvez diriger votre client (POP par exemple) pour qu'il utilise le port local redirigé et non plus vers le port distant avec une transmission en clair.
Nous avons bien vu les options '-L' et '-R'. De nombreuses autres options sont utilisables, par exemple :
-L # Forwarder un port local vers un port distant sur une machine distante
-R # Forwarder un port distant vers un port local sur la machine locale
-N # Ne pas exécuter de commande distante
-f # Excute le programme en tâche de fond
-l # Passer en paramètre le login de connexion
-g # Autoriser des machines distantes à se connecter
# sur des ports locaux exportés
Voyons comment créer un tunnel pour le service d'émulation VT par exemple. On va utiliser un port local compris entre 1024 et 65535 qui sont réservés pour des applications utilisateurs. On va prendre par exemple le port local 1025. Pour créer un tunnel on va utiliser la commande :
M0:$ ssh -L 1025:localhost:23 mlx@M1.foo.org
Ici on utilise (précise) que le compte utilisé sur la machine distante sera M1.foo.org. Vous devez faire cela si le nom du compte que vous utilisez sur le client diffère de celui que vous utilisez sur le serveur.
On crée ici un tunnel entre le port local 1025 et le port distant 23. Le tunnel étant créé il ne reste plus qu'à utiliser le port local 1025 avec un telnet adresse_de_la_machine 1025
Le fait de quitter ssh ferme la session tunnelée.
Il est également possible d'ouvrir une session temporaire pour un temps donné. Cela évite d'avoir à fermer les connexions. Dans la commande :
M0:$ ssh -f -L 1025:localhost:23 mlx@M1.foo.org sleep 10
L'option -f, met ssh en tâche de fond. La session sera fermée automatiquement au bout du temps déterminé, seulement si aucun processus n'utilise le canal à ce moment.
Le principe peut être appliqué à d'autres services. Voici comment utiliser un canal sécurisé vers une application (ici un webmail) qui ne l'est pas. (En fait dans la réalité, je vous rassure, l'application présentée sur l'image offre toutes les options de connexion en mode sécurisé. L'exemple donné est pris pour illustrer le propos.)
# On crée un tunnel entre le port local et le webmail en utilisant # le compte mlx@foo.org M0:$ ssh -N -f -L 2038:M1:80 mlx@foo.org
On peut également sans risque aller sur sa zone public_html en toute sécurité.
lynx http://localhost:2038/~mlx
La connexion se fait sur la machine locale et sur le port forwardé. Ni le compte utilisateur utilisé, ni le mot de passe ne transitent en clair.
Avec la machine sur lequel le test est réalisé, les commandes :
M0:$ ssh -N -f -L 2038:M1:80 mlx@foo.org et M0:$ ssh -N -f -L 2038:localhost:80 mlx@foo.org
ne produisent pas la même chose.
En effet :
M0:$ ssh -N -f -L 2038:M1:80 mlx@foo.org
fait référence à une adresse IP qui est redirigée par un Vhost Apache.
M0:$ ssh -N -f -L 2038:localhost:80 mlx@foo.org
fait référence à l'adresse de loopback, ici c'est le serveur par défaut (typiquement sur une debian /var/www/) qui est consulté. Si vous avez plusieurs Vhosts, il vous faudra créer un tunnel par Vhost.
De la même façon, on peut l'utiliser pour une session ftp.
M0:$ ssh -N -f -L 2039:M1:21 mlx@foo.org M0:$ ftp localhost 2039 Connected to localhost. 220 ProFTPD 1.2.5rc1 Server (Debian) [M1] Name (localhost:mlx): mlx 331 Password required for mlx. Password: 230 User mlx logged in. Remote system type is UNIX. Using binary mode to transfer files.
Attention, dans ce dernier exemple, il n'y a que l'authentification qui est chiffrée car le port 20 (ftp-data) n'est pas forwardé.
Le déport d'application graphique fonctionne sur le même principe. Le client (/etc/ssh/ssh_config), doit avoir l'option "X11Forward" activée pour les systèmes distants. Le serveur (/etc/ssh/sshd_config), doit avoir l'option "X11Forwarding" d'activée. Il est possible de tunneler des applications graphiques dans ssh.
# Sur le client /etc/ssh/ssh_config ForwardX11 yes # Sur le serveur /etc/ssh/sshd_config X11Forwarding yes
Voyons comment utiliser une application graphique distante :
M0:$ ssh -C mlx@M1.foo.org Enter passphrase for key '/home/mlx/.ssh/id_dsa': M0:$ xclock & [1] 7771
L'horloge distante s'affiche. L'option "-C", active la compression.
Vous pouvez tout mettre sur la même ligne de commande, avec l'option "-f", qui "fork" l'application demandée.
M0:$ ssh -C -f mlx@M1.foo.org xclock
Notez le prompt, ici l'ouverture de session a été effectuée en tâche de fond (-f). Pour fermer le canal ssh, il suffit de fermer l'application.
Dans la mesure où il est possible de passer des commandes à distances sur un serveur, sans avoir à saisir de mot de passe ou de "passphrase", on peut envisager l'automatisation de tâches entre machines et dans des tunnels, comme par exemple les sauvegardes ou la synchronisation de fichiers. Il suffira pour cela de créer un compte associé à la tâche, lui créer une clé privée et exporter sa clé publique sur les différentes machines.
Attention toutefois, les manipulations sur les serveurs requièrent un accès root. Cela signifie que votre compte opérateur, devra avoir un accès root sur le serveur ce qui n'est jamais très bon.
Vous aurez intérêt à réfléchir à la façon de réaliser le traitement sans que ce compte opérateur ait besoin du compte "super utilisateur".
Si vous avez un serveur ayant un dm (Desktop Manager) comme gdm par exemple, disponible sur le réseau vous pouvez lancer les émulations X Window des clients en appelant le serveur. Par exemple sur le client faire :
X -query x.y.z.t :u ou encore X -broadcast :u
avec u pouvant varier de 0 à 5, suivant que vous voulez avoir la session graphique sur F7...F12. Pour le système vc7 que vous utilisez par défaut avec CTRL ALT F7 correspond au premier "display" :0.
Maintenant que nous y voyons plus clair, voici deux scénarios d'utilisation d'un proxy ssh.
Vous êtes sur un réseau avec un accès extérieur limité. Pas d'accès http :-(
Vous devez disposer d'une machine à l'extérieur sur laquelle tourne un serveur ssh et un proxy Squid par exemple.
Par défaut Squid utilise le port 3128. On met tout d'abord les autorisations à Squid afin qu'il accepte nos requêtes, sinon elles seront rejetées. (Voir les ACL du fichier /etc/squid.conf). Si vous êtes pressés un "http_access allow all" est brutal, mais ça marche ;-) Nous allons créer un tunnel vers ce service de la machine locale vers la machine distante sur le port 3128.
ssh -N -f -L 3128:M1:3128 mlx@M1
Il ne reste plus qu'à configurer votre navigateur pour qu'il utilise le proxy local "localhost:3128" et le tour est joué. Vous pouvez naviguer en toute sécurité, si vos requêtes sont espionnées au niveau du firewall de votre boîte, elle ne pourront plus être lues.
Cette configuration présente une limitation. Vous ne pouvez utiliser le proxy qu'à partir de la machine sur laquelle vous avez créé le tunnel (M0).
Si vous êtes mobile dans votre entreprise et que vous souhaitez accéder à l'extérieur à partir d'autres machines, ou encore que vous voulez laisser cet accès à des amis qui utilisent le même réseau que vous, il faut procéder autrement.
ssh -g -N -f -L 3128:M1:3128 mlx@M1
L'option "-g" va transformer votre machine en passerelle pour le tunnel. Les autres n'auront plus qu'à mettre comme proxy, le nom ou l'adresse de votre machine et le port 3128.
Si vous souhaitez par contre ouvrir le service de votre proxy à d'autres amis mais pouvant être dans d'autres boîtes ou sur d'autres réseaux, cela se complique un peu, car chacun d'eux doit pouvoir créer un tunnel vers votre proxy. Il faut donc, sur votre proxy créer plusieurs ports d'écoute pour les tunnels et rediriger tout ça vers votre proxy.
ssh -N -f -g -L 3130:localhost:3128 mlx@localhost ssh -N -f -g -L 3131:localhost:3128 mlx@localhost etc... etc...
Ici on a créé sur le proxy 2 ports, 3130 et 3131 qui redirigent vers le port 3128. Il suffit ensuite à partir des machines distantes (réseaux distants) de créer les tunnels vers ces ports.
MY$ ssh -g -N -f -L 3128:localhost:3130 mlx@M1 MZ$ ssh -g -N -f -L 3128:localhost:3130 mlx@M1
et d'utiliser les redirections comme cela a été expliqué plus haut.
Si vous ne souhaitez rediriger les requêtes que pour une machine (site web) en particulier vous pouvez créer un tunnel de la façon suivante :
M0:$ ssh -N -f -L 3128:SITEWEB:3128 mlx@M1
où SITEWEB est l'url du site web que vous souhaitez atteindre (typiquement un webmail). Ici, la configuration du navigateur ne change pas. Le proxy est le même. Vous évitez juste l'utilisation d'un squid si vous n'en avez pas.
Remarque, dans le navigateur vous pouvez taper tout ce que vous voulez (yahoo, wanadoo, google...) vous arriverez toujours sur SITEWEB.
rsync est un outil largement utilisé pour la synchronisation de répertoires sur la même machine ou sur des machines distantes. (création de miroirs distants).
rsync est intéressant car il ne mettra à jour sur le "repository" qui reçoit uniquement les fichiers qui ont été créés ou modifiés. Cela procure un gain non négligeable par rapport à une simple "recopie" de toute l'arborescence dans le cas ou peu de fichiers sont modifiés.
rsync et rsyncd, associés à des scripts et à la crontab, est une option remarquable pour la réplication de disques entre 2 ou plusieurs machines.
Si vous souhaitez "mirorrer" un disque local vers un répertoire que vous avez sur une autre machine sur internet, il vous faudra également passer par une procédure d'authentification. Si vous avez exporté votre clé publique sur la machine distante, vous allez pouvoir synchroniser les disques dans un tunnel sécurisé avec ssh et sans avoir à entrer votre mot de passe. Par exemple, la commande :
cd & & rsync -e ssh -valptz * mlx@M1.foo.org
synchronisera votre $HOME local, sur le $HOME de la machine distante.
Il existe bien sûr des applications graphiques basées sur le concept rsync.
Une autre option pour la synchronisation de disques distants est "unison". unison est un produit particulièrement performant :
http://www.cis.upenn.edu/~bcpierce/unison/index.html
unison permet l'utilisation en mode commande (scripts) mais propose aussi une interface graphique.
L'utilisation de ces commandes est relativement simple. SCP permet de faire de la copie de fichiers. SFTP est utilisable en mode intéractif ou en mode batch et ressemble plus au FTP.
La commande
M0:$ ssh mlx@M1.foo.org "ls -al psionic" -rw-r--r-- 1 root root 64562 Nov 23 23:05 hostsentry-0.02-4.noarch.rpm -rw-r--r-- 1 root root 26955 Nov 23 23:05 logsentry-1.1.1-1.i386.rpm -rw-r--r-- 1 root root 48804 Nov 23 23:06 portsentry-1.1-fr7.i386.rpm -rw-r--r-- 1 root root 48804 Nov 23 23:13 portsentry-1.1-fr7.i386.rpm.1
La commande :
ssh mlx@M1.foo.org "ls -al"
donne la liste des fichiers distants qui sont dans le répertoire "psionic". Pour copier ces fichiers localement dans un répertoire psionic on va utiliser :
cd && mkdir psionic scp mlx@M1.foo.org:/home/mlx/psionic/* ~/psionic
Ou pour envoyer les fichiers du répertoire local psionic, vers le répertoire tmp qui est dans /home/mlx de la machine M1.foo.org :
scp ~/psionic/* mlx@foo.org:/home/mlx/tmp
sftp peut être utilisé pour du transfert de fichiers en mode sécurisé.
sftp mlx@M1.foo.org sftp>
On obtient un prompt, ici le système ne m'a pas demandé de m'authentifier. Pour avoir une liste des commandes, utiliser "help".
sftp> help Available commands: cd path Change remote directory to 'path' lcd path Change local directory to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode path Change permissions of file 'path' to 'mode' chown own path Change owner of file 'path' to 'own' help Display this help text get remote-path [local-path]Download file lls [ls-options [path]] Display local directory listing ln oldpath newpath Symlink remote file lmkdir path Create local directory lpwd Print local working directory ls [path] Display remote directory listing lumask umask Set local umask to 'umask' mkdir path Create remote directory put local-path [remote-path]Upload file pwd Display remote working directory exit Quit sftp quit Quit sftp rename oldpath newpath Rename remote file rmdir path Remove remote directory rm path Delete remote file symlink oldpath newpath Symlink remote file version Show SFTP version !command Execute 'command' in local shell ! Escape to local shell ? Synonym for help
Table of Contents
Abstract
Approche de SSH, de PPP, des VPN et des services mandataires
Nous allons voir comment mettre en place un réseau virtuel privé qui s'appuie sur le protocole PPP dans un tunnel SSH. Cette solution va permettre de mettre en place sur les clients tout type de service mandataire (proxy) pour accéder en toute sécurité à des services serveurs, dans une liaison point à point, et ainsi utiliser des protocoles en toute sécurité, que ceux-ci soient chiffrés ou non.
Si vous ne connaissez pas SSH, je vous recommande de commencer par le document qui aborde le fonctionnement de ce protocole et la mise en place de tunnels sécurisés avec ce produit. Certains aspects qui sont abordés ne seront pas repris ici.
Il sera fait référence à la maquette suivante :
La machine cliente est sur un réseau privé ou public. Peu importe. Il dispose des applications clientes SSH, PPP, d'un UA (client de messsagerie) et éventuellement un serveur SMTP pour les besoins de la démonstration.
Le serveur est sur une adresse publique. Mettre le serveur sur une adresse privée n'est pas compliqué, mais nécessite de mettre en place des tables de translation d'adresses sur les routeurs. Nous ferons donc sans cela pour ne pas multiplier les problèmes, mais dans la réalité les VPN servent surtout à relier deux ou plusieurs réseaux privés distants, relié par un réseau public ou "non sûr"..
Le serveur dispose de tous les services (dns, smtp, pop3, imap, proxy http(s) et ftp ...) qui serviront aux tests, d'un serveur sshd et d'un serveur pppd pour la création du VPN et du tunnel.
Les routeurs relient deux segments distants via internet ou tout autre type de liaison. Ils peuvent être des pare-feu.
Voici les adresses ethernet affectées aux machines, et les adresses PPP qui seront utilisées pour le VPN :
Client Serveur
eth0 192.168.90.2 195.115.88.38
ppp0 192.168.0.2 192.168.0.1
Sans trop entrer dans les détails, nous allons faire un petit tour du protocole PPP puisqu'il en est question dans ce document.
Le protocole PPP (Point to Point Protocol) est un protocole de niveau 2. Il supporte des liaisons point-à point synchrones ou asynchrones.
PPP est composé de trois grandes entités :
Un protocole qui servira à l'encapsulation des paquets avant dépôt sur le média physique : HDLC. HDLC est un protocole de liaison de données.
LCP (Link Control Protocol) qui sert à établir (ou rompre) la liaison, qui permet de la tester et de la configurer.
NCP (Network Control Protocol) qui sert d'interface pour les protocoles de niveau 3. Il n'y a pas un (1) protocole NCP, mais "n". En effet, chaque protocole de niveau 3 dispose de sa propre interface particulière. Sur ip, l'implémentation NCP se nomme IPCP (IP Control Protocol).
Un paquet PPP peut véhiculer plusieurs protocoles de niveau 2 ayant chacun un rôle, ou des paquets contenant des données de niveau 3. Voici quelques exemples avec les numéros de protocoles.
0021, indique un transport de données IP
8021, IPCP. Ce protocole permet de déterminer les adresses de la liaison point à point entre les deux noeuds distants. Affectation statique ou dynamique des adresses, compression des entêtes IP...
C021, paquet contenant des données LCP
C023, paquets de type PAP, Password Authentification Protocole
C223, paquet sde type CHAP, Challenge Handshake Authentification.
Les numéros de protocoles sont stockés dans un champ "contrôle" du paquet PPP. PAP et CHAP servent à l'authentification des utilisateurs.
Préparation du client et du serveur.
La première chose à faire est de mettre en place un moyen de lancer le daemon pppd chaque fois que vous voudrez mettre en place un VPN entre votre client et le serveur. Il y deux solutions. Soit vous créez un compte spécifique sur le serveur (ce que nous allons faire), et qui aura en charge de lancer le daemon, soit vous utilisez votre propre compte. Dans un cas comme dans l'autre, la procédure est très similaire.
Sur le serveur, créez un compte VPN :
adduser --disabled-password vpn
On donne le droit à cet utilisateur de lancer pppd. Il faut rajouter une ligne dans le fichier.
serveur# visudo /etc/sudoers # Ajoutez la ligne suivante vpn ALL=NOPASSWD:/usr/sbin/pppd
Comme la liaison sera chiffrée dans un tunnel SSH, il est nécessaire de mettre également un moyen qui permette cela le plus simplement possible. Cela est réalisé par un système de clé publique et privée. Si vous n'en avez pas vous pouvez vous en créer une. Ne mettez pas de mot de passphrase (vous faites entrée, ce n'est pas vraiment utile. Vous êtes sur le client :
[client]$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/client/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /client/.ssh/id_dsa. Your public key has been saved in /client/.ssh/id_dsa.pub. The key fingerprint is: c5:a5:90:b2:19:9d:bf:3a:0b:c9:64:f7:98:1e:e0:dc client@mr
Vous avez la clé publique et la clé privée sur le client, dans votre répertoire personnel et dans le sous-répertoire ".ssh". Il vous faut copier la clé publique sur le serveur.
scp .ssh/id_dsa.pub VotreCompteSurLeServeur@serveur:
Maintenant il ne reste plus qu'à déclarer cette clé publique comme valide et utilisable par le compte "VPN". Vous êtes sur le serveur.
serveur# mkdir -p /home/vpn/.ssh
serveur# cat /home/VotreCompteSurLeServeur/id_dsa.pub >> \
/home/vpn/.ssh/authorized_keys2
serveur# chmod 700 /home/vpn/.ssh && chmod 600 /home/vpn/.ssh/authorized_keys2
Normalement vous devriez pouvoir vous connecter à partir du client sur le serveur en utilisant le compte VPN sans entrer de mot de passe.
[client]$ ssh -l vpn serveur
Si cela ne fonctionne pas, et que le serveur sshd est actif, vérifiez que vous n'avez pas commis d'erreur de manipulation. Reprenez bien la procédure.
Si le serveur vous demande un mot de passe et que l'accès fonctionne en mettant un mot de passe, c'est que vous avez saisi une "passphrase". Utilisez ssh-agent et ssh-add pour ne plus avoir à sasir de mot de passe.
Si tout fonctionne, c'est terminé.
Si d'autres personnes veulent mettre en place des VPN sur le serveur, il suffit de rajouter leurs clés publique dans le fichier authorized_keys2.
Si vous ne voulez pas utiliser de compte "VPN" ou autre mais le vôtre, il suffit de modifier le fichier sudoers en mettant votre compte à la place de "vpn".
Il faut maintenant pouvoir activer et/ou désactiver le VPN à la demande. Nous allons pour cela, utiliser un script que vous pourrez adapter.
#!/bin/sh
# /usr/local/bin/vpn-pppssh
#
# This script initiates a ppp-ssh vpn connection.
# see the VPN PPP-SSH HOWTO on http://www.linuxdoc.org for more information.
#
# revision history:
# 1.6 11-Nov-1996 miquels@cistron.nl
# 1.7 20-Dec-1999 bart@jukie.net
# 2.0 16-May-2001 bronson@trestle.com
#
# You will need to change these variables...
#
# The host name or IP address of the SSH server that we are
# sending the connection request to:
SERVER_HOSTNAME=serveur.votredomaine.org
# The username on the VPN server that will run the tunnel.
# For security reasons, this should NOT be root. (Any user
# that can use PPP can intitiate the connection on the client)
SERVER_USERNAME=vpn
# The VPN network interface on the server should use this address:
SERVER_IFIPADDR=192.168.0.1
# ...and on the client, this address:
CLIENT_IFIPADDR=192.168.0.2
# This tells SSH to use unprivileged high ports, even though it's
# running as root. This way, you don't have to punch custom holes
# through your firewall.
LOCAL_SSH_OPTS="-P"
#
# The rest of this file should not need to be changed.
#
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11/:
#
# required commands...
#
PPPD=/usr/sbin/pppd
SSH=/usr/bin/ssh
if ! test -f $PPPD ; then echo "can't find $PPPD"; exit 3; fi
if ! test -f $SSH ; then echo "can't find $SSH"; exit 4; fi
case "$1" in
start)
echo -n "Starting vpn to $SERVER_HOSTNAME: "
# Modifier les 3 lignes ci-dessous afin d'ôter les \ et les CR/LF
${PPPD} updetach noauth passive pty "${SSH} ${LOCAL_SSH_OPTS}\
${SERVER_HOSTNAME} -l${SERVER_USERNAME} sudo ${PPPD} nodetach\
notty noauth" ipparam vpn ${CLIENT_IFIPADDR}:${SERVER_IFIPADDR}
echo "connected."
;;
stop)
# echo -n "Stopping vpn to $SERVER_HOSTNAME: "
# Modifier les 2 lignes ci-dessous afin d'ôter les \ et les CR/LF
PID=`ps ax | grep "${SSH} ${LOCAL_SSH_OPTS} ${SERVER_HOSTNAME}\
-l${SERVER_USERNAME}"| grep -v ' passive ' | grep -v 'grep '\
| awk '{print $1}'`
if [ "${PID}" != "" ]; then
kill $PID
echo "Kill $PID, disconnected."
else
echo "Failed to find PID for the connection"
fi
;;
config)
echo "SERVER_HOSTNAME=$SERVER_HOSTNAME"
echo "SERVER_USERNAME=$SERVER_USERNAME"
echo "SERVER_IFIPADDR=$SERVER_IFIPADDR"
echo "CLIENT_IFIPADDR=$CLIENT_IFIPADDR"
;;
*)
echo "Usage: vpn {start|stop|config}"
exit 1
;;
esac
exit 0
Pour l'utiliser, il suffit de faire un "./vpn start". Si vous obtenez quelque chose proche de cela, c'est que votre vpn est bien créé.
[root]# ./vpn-pppssh start Starting vpn to serveur: Using interface ppp0 Connect: ppp0 <--> /dev/pts/1 Looking for secret in /etc/ppp/pap-secrets for client mr server (null) Looking for secret in /etc/ppp/chap-secrets for client mr server (null) Deflate (15) compression enabled local IP address 192.168.0.2 remote IP address 192.168.0.1 connected.
Sur le client et sur le serveur, les interfaces ppp0 doivent être actives :
# Sur le client, ifconfig
ppp0 Lien encap:Protocole Point-à-Point
inet adr:192.168.0.2 P-t-P:192.168.0.1 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:126 errors:0 dropped:0 overruns:0 frame:0
TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:3
RX bytes:10139 (9.9 Kb) TX bytes:9029 (8.8 Kb)
# Sur le serveur, ifconfig
ppp0 Lien encap:Protocole Point-à-Point
inet adr:192.168.0.1 P-t-P:192.168.0.2 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:102 errors:0 dropped:0 overruns:0 frame:0
TX packets:126 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:3
RX bytes:9029 (8.8 KiB) TX bytes:10139 (9.9 KiB)
Le protocole a installé les routes de ces interfaces et qui viennent compléter celles déjà existantes :
# Sur le client : [Client]# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 # Sur le serveur Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
Sur le client, les commandes :
ping 192.168.0.1 ping 192.168.0.2
fonctionnent. Le routage est donc bien actif entre ces interfaces, nous allons pouvoir faire fonctionner des applications clientes et serveur sur ce canal.
Sur le client, les applications sont configurées pour utiliser l'adresse ip affectée à ppp0. Le dialogue peut être effectué sans chiffrement. Le paquet est délégué à SSH qui va chiffrer puis déposer le paquet sur eth0.
Sur le serveur les paquets arrivent chiffrés sur eth0. Ils sont déchiffrés par SSH et routés sur l'interface ppp0 du serveur qui les délivre au service serveur.
Cela présente bien sûr un inconvénient:celui de charger les processeurs et la bande passante bien que PPP supporte la compression des données. Il n'est pas toujours facile de trouver un bon compromis entre des options de sécurité par chiffrement tout en tenant compte des coûts que cela induit.
Le schéma montre que chaque paquet subit deux traitements de plus que s'il était traité normalement pour l'émission, ce qui en génère également deux de plus lors de la réception.
L'objet de cette manipulation est de vérifier simplement le bon fonctionnement du vpn à l'aide d'une requête DNS (dig www.yahoo.fr) entre le client et le serveur. La capture intercepte ce qui se passe sur eth0 et ppp0.
Le fichier resolv.conf est configuré pour utiliser le serveur de nom :
[client]# more /etc/resolv.conf nameserver 195.115.88.38
Les requêtes passent dans ce cas par eth0.
Sur ppp0 rien ne passe, sur eth0 par contre, il y a du traffic.
[client]# ettercap -T -i eth0 Listening on eth0... (Ethernet) eth0 -> 00:90:F5:28:D5:06 192.168.90.2 255.255.255.0 Mon Nov 22 10:11:59 2004 UDP 192.168.90.2:32885 --> 195.115.88.38:53 | .}...........www.yahoo.com.....
Il s'agit bien d'une requête UDP qui est passée sur ETH0, en utilisant comme source 192.168.90.2:32885 et à destination de 195.115.88.38:53. Le trafic n'est pas chiffré.
On va modifier le resolv.conf afin que les requêtes passent par le VPN.
nameserver 192.168.0.1
Et on lance la capture sur ppp0 :
[client]# ettercap -T -i ppp0 ppp0 -> 00:00:00:00:00:00 192.168.0.2 255.255.255.255 Mon Nov 22 10:24:04 2004 UDP 192.168.0.2:32885 --> 192.168.0.1:53 | iF...........www.yahoo.com..... Mon Nov 22 10:24:04 2004 UDP 192.168.0.1:53 --> 192.168.0.2:32885 |
Maintenant on a bien un trafic sur ppp0. Noter qu'elle n'a pas d'adresse MAC car c'est une interface logique. Il s'agit bien d'une requête UDP de l'hôte source 192.168.0.2:3288 vers l'hôte destination 192.168.0.1:53. Ici le trafic n'est pas chiffré.
On la lance également sur eth0 :
[client]# ettercap -T -i eth0 Listening on eth0... (Ethernet) eth0 -> 00:90:F5:28:D5:06 192.168.90.2 255.255.255.0 Mon Nov 22 10:20:39 2004 TCP 195.115.88.38:22 --> 192.168.90.2:33102 | AP ..!..O.R$.[NP...<G.O._uRH?O."..M36<.Gd.?.. ..Vx. Mon Nov 22 10:20:39 2004 TCP 192.168.90.2:33102 --> 195.115.88.38:22 | AP 8..1.xV....]....D..q.7:3y.%.&.J..2..8.Qp%.*.."..
Là le dialogue n'est plus dirigé vers de l'UDP/53 mais vers du TCP/22. Il s'agit bien de SSH et plus rien n'est lisible.
La maquette fonctionne parfaitement, le service mis en place est le premier service proxy actif. Il s'agit d'un service proxy DNS.
Pour les services pop et imap il n'y a aucun difficulté. Il suffit de configurer le client pour qu'il relève les courriers sur 192.168.0.1.
En ce qui concerne SMTP il y a deux scénarios posibles :
utiliser directement le serveur smtp qui est sur le serveur,
utiliser un serveur smtp qui est sur sa propre machine comme cela se fait fréquemment.
Dans le premier cas, la procédure est assez simple. Dans la configuration de votre client de messagerie (paramètre envoi de message), vous mettez 192.168.0.1, c'est à dire l'adresse du serveur.
Si vous utilisez votre propre serveur SMTP local sur le client, il faut mettre l'adresse du client : 192.168.0.2.
Mais cela ne suffit pas. Par défaut, si vous ne précisez rien, un serveur SMTP envoie le message directement au destinataire. C'est la fonction de routage du service SMTP qui assure cela. Il se base sur l'enregistrement MX de la zone destinataire. Pour faire cela, il faut configurer le serveur SMTP pour qu'il utilise l'interface eth0 et non pas ppp0. La configuration du client de messagerie contient, dans ce cas, l'adresse ip de eth0, mais en faisant cela, on utilise plus du tout le VPN.
Pour utiliser le VPN mis en place, il faut indiquer au serveur SMTP local de ne pas envoyer directement les messages sur internet vers le destinataire, mais de les faire relayer par le serveur smtp du serveur.
Comment configurer cela ?
On va prendre comme exemple Postfix.
Sur le client, il faut ajouter un paramètre dans /etc/postfix/main.cf :
relayhost = 192.168.0.1 # On demande au serveur de relayer
pour indiquer au serveur smtp local, que les messages seront relayés par le serveur d'adresse 192.168.0.1.
Maintenant le serveur. Il faut lui indiquer qu'il doit accepter et traiter les paquets provenant de l'adresse 192.168.0.2, voire carrément d'un réseau 192.168.0.0/24 car postfix est généralement configuré pour ne pas relayer les messages qui ne proviennent pas de son réseau.
Sur le client il faut rajouter un paramètre dans /etc/postfix/main.cf, et ajouter à la variable "mynetworks", l'adresse du VPN :
# Vous pouvez en avoir d'autres. mynetworks = 127.0.0.1/32, 192.168.0.0/24
à partir de ce moment, il est possible d'utiliser son service SMTP local pour ne pas changer ses habitudes, cela, en toute sécurité quel que soit l'endroit où on se trouvons. (Du moins entre les deux points du VPN) et avec l'énorme avantage d'utiliser un serveur SMTP déclaré ou officiel qui répond aux contraintes de plus en plus draconniennes que mettent en place les FAI et les administrateurs systèmes.
La mise en place d'un service proxy squid, ne pose pas non plus de difficulté une fois le VPN installé. Il doit falloir moins de 3 minutes pour installer Squid sur une debian. Ensuite il faut juste lui indiquer les machines dont il doit traiter les requêtes.
Comme le service sera installé sur un serveur public, on fera attention aux autorisations données afin de limiter les risques. Cela se passe dans le fichier de configuration "/etc/squid.conf" et dans le paragraphe qui décrit les ACL.
On déclare une nouvelle ACL, et on autorise les machines qui répondent à ce critère :
acl vpn src 192.168.0.0/255.255.255.0 http_access allow vpn
Pour le serveur c'est terminé.
Il ne reste plus qu'à configurer les clients d'accès (navigateur) pour qu'ils utilisent le proxy : 192.168.0.1.
Là encore toutes les transactions entre le client et le serveur seront chiffrées, et on bénéficie en plus d'un serveur de cache.
Cette solution est assez simple à mettre en place. Elle est particulièrement intéressante pour les clients nomades. Ils peuvent, quelque soit l'endroit où ils se trouvent, mettre en place un VPN entre le client et un serveur, sans avoir à se soucier de l'état du réseau sur lequel ils se trouvent, et peuvent utiliser quasiment tous les services réseau sans se préoccuper des règles installées sur les pare-feux, puisque tous les services sont routés dans le même tunnel.
Abstract
Mettre en place et comprendre la résolution de noms d'hôtes.
L'atelier présente la résolution de noms d'hôtes sur un petit réseau
à l'aide d'un fichier hosts.
Vous utiliserez la commande ping pour diagnostiquer le fonctionnement du réseau.
Il est en 3 parties :
une présentation de la résolution de nom sur un réseau local,
un TP,
un questionnaire.
Vous devez connaître la classe d'adresse de votre réseau. Vous devez connaître également les adresses des hôtes que vous voulez adresser ainsi que leurs noms d'hôtes.
Dans un réseau, on assigne généralement un nom à chaque hôte. Le terme d'hôte est pris dans son sens large, c'est à dire un “ noeud de réseau ”. Une imprimante, un routeur, un serveur, un poste de travail sont des noeuds qui peuvent avoir un nom d'hôte, s'ils ont une adresse IP.
On parle de “ nom d'hôte ” sur les réseaux qui utilisent le protocole TCP/IP. Ne pas confondre le “ nom d'hôte ” avec le “ nom Netbios ” qui est utilisé sur les réseaux Microsoft™ ou IBM.
Le nom d'hôte est assigné à un noeud qui est configuré avec une
adresse IP. Le nom permet d'adresser le noeud,
autrement qu'avec l'adresse IP. Par exemple, si le
réseau est équipé d'un serveur d'adresse 192.68.0.100 et dont le nom
d'hôte est srv1, il sera alors possible de saisir les
commandes suivantes :
telnet 192.68.0.100
ou bien
telnet srv1
Le nom sert de mnémonique, qui évite de retenir toutes les adresses IP du réseau. Le protocole TCP/IP se charge de la résolution des noms d'hôtes, ensuite le protocole ARP, se charge de la résolution des adresses IP en adresses MAC (Ethernet le plus souvent).
Pour que la résolution de nom fonctionne, il faut déclarer dans un
fichier tous les noms d'hôtes, et pour chaque nom, son adresse
IP. Cette déclaration est réalisée dans le fichier
/etc/hosts.
Le processus de résolution équivalent peut être mis en oeuvre
sur des réseaux qui utilisent Windows 9x, Windows NT Server, Windows
NT Workstation. Vous devrez alors créer les fichiers respectivement
dans les répertoires Windows et
winnt\system32\drivers\etc.
Vous trouverez dans ces répertoires, si TCP/IP est
installé un fichier host.sam qui peut vous servir
d'exemple
Vous utiliserez un éditeur joe ou
emacs afin de modifier le fichier
/etc/hosts. Utilisez l'algorithme suivant pour
créer / modifier votre fichier :
Pour chaque hôte du réseau faire mettre un enregistrement Fin pour
Les enregistrements ont la structure suivante : AdresseIP Nom1 [...NomN]
Exemple : 195.115.88.35 foo foo.foo.org becassine
Consultez également la commande man
hosts
Etablissez la nomenclature des machines du réseau. Configurez
le fichier host avec la nomenclature. Testez la
résolution de nom avec la commande ping, puis en
utilisant les services telnet et
ftp.
Modifiez la correspondance Nom / Adresse d'une des
machines que vous avez dans votre fichier host
et accédez-y avec telnet. Que se
passe-t-il ?
Débranchez la jarretière de votre carte réseau, et réutilisez
les commandes ping
,
localhostping
,
127.0.0.1ping
.
Que se passe-t-il et que peut-on en déduire ?UneMachineDistante
Attention, plus tard nous verrons la résolution de nom par un autre
service DNS. Les deux solutions (DNS
et Hosts) ne sont pas exclusives, par contre on peut jouer sur l'ordre qui
doit être appliqué. Cela est traité par le fichier de configuration
/etc/host.conf.
$ more /etc/host.conf order hosts,bind
Il faut bien se souvenir de ça, car dans l'exemple donné ci-dessus,
le fichier hosts est prioritaire sur
DNS.
Quelle est la commande qui permet d'obtenir le nom d'hôte de la machine locale ?
Quelles sont les informations que donne la commande ifconfig ?
Donnez la commande qui permet de n'envoyer qu'un seul ping à
une machine distante (voir man
ping)
Quelle est la taille d'un paquet envoyé par la commande ping ?
Quelle est la commande qui permet d'envoyer des paquets de 1500 octets ?
Quelle est la commande ping qui permet d'envoyer des paquets en flot ininterrompu ?
Quel protocole utilise la commande ping ?
Table of Contents
Abstract
Configuration d'un serveur Apache 2 et mise en place de services web
Installation et configuration d'un serveur HTTP avec Apache 2.
Mots clés “Serveur Web”, “Serveur HTTP”, “Apache 2”
Description et objectifs de la séquence
Le document doit vous permettre de mettre en place un serveur Apache supportant :
des accès anonymes,
des accès authentifiés par Apache,
un accès à des pages personnelles,
des scripts CGI,
des serveurs web virtuels.
Ce chapitre donne un aperçu des fonctions et de l'environnement du serveur Apache 2. Vous pourrez retrouver tous les aspects développés dans la documentation (en partie en français) du produit à l'adresse suivante apache.org.
Apache 2 a très certainement été installé par défaut lors de l'installation de votre Debian. Pour le vérifier : dpkg -l | grep apache2
ii apache2 ii apache2-common ii apache2-mpm-prefork ii apache2-utils ii libapache2-mod-perl2 ii libapache2-mod-php4 (ou libapache2-mod-php5)
Si Apache2 n'est pas installé, la commande : apt-get install apache2 installera le serveur web avec ses dépendances.
Vous aurez certainement besoin par la suite du module php alors autant l'installer tout de suite : apt-get install libapache2-mod-php4 (ou apt-get install libapache2-mod-php5)
Si vous voulez installer la documentation en local : apt-get install apache2-doc
Le serveur HTTP Apache2 est un programme modulaire. Mise à part quelques modules directement intégrés dans le programme binaire httpd, l'administrateur peut choisir les fonctionnalités qu'il souhaite en activant des modules.
De même, il existe plusieurs fichiers de configuration tous
présents dans
/etc/apache2/.
Le fichier de configuration principal est
/etc/apache2/apache2.conf
Il contient les paramètres généraux et communs à tous les
serveurs et plusieurs "Include" vers les autres
fichiers.
Le fichier de configuration
/etc/apache2/ports.conf contient la liste des
ports en écoute.
On trouve tous les fichiers concernant les modules
dans le répertoire
/etc/apache2/mods-available/.
On y trouve deux catégories de fichiers :
*.load et
*.conf
Les fichiers avec l'extension load charge effectivement les modules dynamiques :
cat /etc/apache2/mods-available/userdir.load
LoadModule userdir_module /usr/lib/apache2/modules/mod_userdir.so
Les fichiers avec l'extension conf sont les fichiers de configuration des modules :
cat /etc/apache2/mods-available/userdir.conf
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
</IfModule>
On trouve les fichiers concernant les modules
activés
dans le répertoire
/etc/apache2/mods-enabled/
: ce sont uniquement ces fichiers qui sont inclus dans
le fichier de configuration principal par les directives :
Include /etc/apache2/mods-enabled/*.load Include /etc/apache2/mods-enabled/*.conf
Et ces fichiers sont en fait des liens qui pointent vers
les fichiers de
/etc/apache2/mods-available
Pour activer un module (ce qui revient donc à créer le lien), il est pratique d'utiliser la commande suivante : a2enmod mod_userdir. Mais on peut bien évidemment créer le lien "à la main".
On trouve tous les fichiers de configuration des
serveurs web
/etc/apache2/sites-available/
On trouve les fichiers de configuration des sites web
activés
dans le répertoire
/etc/apache2/sites-enabled/
: ce sont uniquement ces fichiers qui sont inclus dans
le fichier de configuration principal par la directive :
Include /etc/apache2/sites-enabled/[^.#]*
Et ces fichiers sont en fait des liens qui pointent
vers les fichiers de
/etc/apache2/sites-available
De même que pour les modules, pour activer
un site, il existe une commande :
a2ensite fichier_conf.
"fichier_conf" étant un fichier de configuration
présent dans
/etc/apache2/sites-available/
La documentation est dans
/usr/share/doc.
Les journaux sont dans
/var/log/apache2/.
Le script de lancement du service serveur est dans
/etc/init.d
Pour que le serveur Web puisse répondre à une demande d'un client, il doit être démarré : /etc/init.d/apache2 start.
Apache2 ne fonctionne qu'en standalone (la directive ServerType n'est donc plus reconnu).
Ce paragraphe décrit les principaux paramètres pour mettre en place un service HTTP minimum.
Prenez la peine de faire une sauvegarde des fichiers de configuration avant de procéder à toutes modifications (par exemple : cp -rp /etc/apache2 /etc/apache2.init).
Les modifications ne seront prises en compte que si les fichiers de configurations sont relus /etc/init.d/apache2 reload ou si le service est redémarré /etc/init.d/apache2 restart.
Vous pouvez vérifier la syntaxe des fichiers de configuration par la commande : apache2 -t
Comment retrouver rapidement le fichier dans lequel se trouve une directive ? :
grep -ni "documentroot" /etc/apache2/* ne renvoie rien...
grep -ni « documentroot » /etc/apache/*/* sites-available/default:5: DocumentRoot /var/www sites-enabled/000-default:5: DocumentRoot /var/www
L'option « ni » permet de chercher sans tenir compte de la casse et de renvoyer aussi le numéro de la ligne. L'astérisque peut être remplacé par un nom de fichier.
Dans le fichier
/etc/apache2/ports.conf
Listen 80, indique quel est le
port utilisé par le service (par défaut 80). Il est
possible d'utiliser un autre port, par contre vous
devrez spécifier au navigateur quel est le port utilisé par
le serveur. Si vous configurez par exemple le port 8080
(Listen 8080) sur une machine
www.MonDomaine.edu, vous devrez
spécifier dans le navigateur
www.MonDomaine.edu:8080, pour que le
serveur reçoive et traite votre requête.
Dans le fichier
/etc/apache2/apache2.conf
user www-data et group www-data, spécifient le compte anonyme utilisé par le serveur une fois qu'il est lancé. En effet, pour accéder aux ports inférieurs à 1024, le serveur utilise un compte administrateur, ce qui présente des dangers. Une fois le processus actif, il utilisera l'UID d'un autre compte (ici www-data). Ce compte doit pouvoir lire les fichiers de configuration et ceux de la racine du serveur HTTP (attention donc aux droits sur les pages web desservies). D'autres distributions utilisent le compte “nobody” ou “apache”
ServerRoot
/etc/apache2, indique l'adresse du
répertoire racine du serveur, où sont stockés les fichiers
de configuration du serveur HTTP. Cette
adresse peut être modifiée.
PidFile
/var/run/apache2.pid, indique le fichier où le
serveur en exécution stocke son numéro de processus
(PID).
ErrorLog, fichier error_log,
journalisation des erreurs. L'adresse est calculée à
partir de ServerRoot. Si ServerRoot est
/etc/httpd et
ErrorLog logs/error_log, le chemin complet est
/var/log/apache/logs/error_log.
Il est fréquent d'héberger plusieurs serveurs web sur un même poste aussi la déclaration et le paramétrage des différents serveurs est déportée dans des fichiers à placer dans /etc/apache2/sites-available/. Le fichier default y est déjà présent pour assurer le paramétrage du site principal par défaut dont la racine se trouve, toujours par défaut à /var/www/.
Le site par défaut est déjà activé ; on retrouve donc un lien vers ce fichier dans /etc/apache2/sites-enabled.
Sinon, le principe est le suivant :
On crée un fichier de configuration (appellé
conf_site) pour un site web spécifique dans
/etc/apache2/sites-available/.
On active ce fichier de configuration par la commande
: a2ensite conf_site ; cette commande a
pour effet de créer un lien dans
/etc/apache2/sites-enabled/ qui pointe
vers
/etc/apache2/sites-available/conf_site.
De plus, il est aussi possible de faire exécuter plusieurs instances d'Apache en spécifiant un fichier de configuration particulier par une commande du style : apache -f fichier_config où fichier_config est le nom du fichier de configuration, en chemin absolu (sinon il est considéré comme situé relativement à la directive ServerRoot, c'est-à-dire /etc/apache2, par défaut).
Les directives qui suivent correspondent à des serveurs
spécifiques et sont donc incluses dans les fichiers de
configuration présents dans
/etc/apache2/sites-available/ , notamment
celui par défaut
/etc/apache2/sites-available/default.
ServerAdmin webmaster@localhost,
précise quel est le compte qui reçoit les messages. Par
défaut un compte spécifique administrateur de site web (à
modifier pour une adresse comme
root@MonDomaine.edu).
ServerName www.MonDomaine.edu,
indique le nom ou l'alias avec lequel la machine est
désignée. Par exemple, l'hôte
ns1.MonDomaine.edu, peut avoir le nom
d'alias www.MonDomaine.edu. Ce nom
doit correspondre à une adresse IP, donc être renseigné
dans un serveur DNS (ou dans un premier temps mais à éviter
en production dans un fichier hosts sur le cient).
S'il n'est pas défini, alors le serveur tentera
de le résoudre à partir de sa propre adresse IP. Voir la
résolution de nom avec un DNS.
DocumentRoot /var/www, indique l'emplacement par défaut des pages HTML quand une requête accède au serveur. Exemple : la requête http://www.MonDomaine.edu/index.html pointe en fait sur le fichier local /var/ww/index.html sauf si le répertoire est pointé par une directive tel que Alias (voir ci-après).
Alias /CheminVu/ /CheminRéel/, par exemple : "/icons/ /usr/share/apache/icons/", ce paramètre permet de renommer, à la manière d'un lien logique, un emplacement physique avec un nom logique.
Exemple: vous voulez que www.MonDomaine.edu/test/index.html, ne corresponde pas physiquement à un répertoire sur la racine du serveur HTTP (défini par la directive précédente DocumentRoot) mais à un emplacement qui serait /usr/local/essai. Vous pouvez mettre dans le fichier de configuration d'Apache un alias de la forme: alias /test/ /usr/local/essai/
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin, de la forme "ScriptAlias FakeName RealName", indique où sont physiquement situés les scripts sur le disque, ainsi que l'alias utilisé par les développeurs pour le développement des scripts et des pages. Un développeur utilisera un lien (exemple : /cgi-bin/NomDuScript où /cgi-bin/ est un alias sur /home/httpd/cgi-bin/), et c'est le script /home/httpd/cgi-bin/NomDuScript qui sera effectivement exécuté. La mise en place d'alias permet de restructurer ou déplacer un serveur sans avoir à modifier toutes les pages développées.
DirectoryIndex donne le ou les noms des fichiers que le serveur doit rechercher si le navigateur passe une requête sur un répertoire. Par exemple sur une requête http://www.MonDomaine.edu, le serveur va rechercher dans l'ordre s'il trouve un fichier index.html, index.stml, index.cgi... en fonction des paramètres de cette variable.
On peut activer ou non (activée par défaut) l'option "Indexes" au niveau d'un répertoire (voir la partie suivante concernant la sécurisation des accès) de manière à ce que si une URL pointe sur un répertoire, et aucun fichier défini par DirectoryIndex n'existe dans ce dernier, alors le serveur retourne une liste du contenu du répertoire. Si l'indexation n'est pas activée (ce qui est plus sécurisé), on obtient une page d'erreur 403 ("You don't have permission to access /repertoire on this server").
Chaque répertoire dont le contenu doit être géré par Apache2 peut être configuré spécifiquement.
Pour chaque répertoire "UnRépertoire", sur lequel on désire avoir une action, on utilisera la procédure suivante:
<Directory UnRépertoire> ...Ici mettre les actions... </Directory>
Tout ce qui est entre les balises s'applique au répertoire "UnRépertoire".
Quelques options :
<Directory UnRépertoire>
Options Indexes FollowSymLinks ExecCGI
...
</Directory>
Indexes : autorise l'affichage du contenu d'un répertoire (si un fichier par défaut n'y est pas trouvé).
FollowSymLinks: le serveur est autorisé à suivre les liens symboliques dans ce répertoire.
ExecCGI : l'exécution de scripts CGI est autorisé.
Pour désactiver les options (par exemple Indexes)
<Directory UnRépertoire>
Options -Indexes FollowSymLinks ExecCGI
...
</Directory>
Sécuriser un répertoire en autorisant/refusant l'accès
On peut réglementer pour chaque répertoire le droit
d'accéder aux pages contenues dans ce répertoire, en
fonction de la machine cliente et/ou de l'utilisateur
qui se connecte. Le fichier dans lequel ce paramétrage
s'effectue est un fichier de configuration présent
dans
/etc/apache2/sites-available/.
Exemple: On désire autoriser l'accès du répertoire "/intranet" aux machines du réseau d'adresse 192.168.1.0/24 et de nom de domaine MonDomaine.edu, et l'interdire à tous les autres.
<Directory /intranet> #Ordre de lecture des règles order allow,deny deny from all allow from 192.168.1 #ou encore allow from .MonDomaine.edu </Directory>
Il importe de préciser dans quel ordre les règles de restriction vont être appliquées. Cet ordre est indiqué par le mot réservé “order”, par exemple “order deny,allow” (On refuse puis on alloue l'accès à quelques adresses, c'est à dire que toutes les régles deny vont être lues d'abord, puis ce sera le tour de toutes les règles allow) ou “order allow,deny” (on accepte généralement les accès mais il sont refusés pour quelques adresses : ici, on prend en compte en premier lieu toutes les règles allow dans l'ordre trouvé, puis ensuite toutes les règles deny).
Exemple: On désire que l'accès soit majoritairement accepté, sauf pour un ou quelques sites.
<directory /home/httpd/html> AllowOverride none Order deny,allow deny from pirate.com badboy.com cochon.com allow from all </directory>
Authentifier l'accès à un répertoire : ce procédé va permettre de sécuriser l'accès à un répertoire ou à des fichiers. L'accès sera autorisé à une ou plusieurs personnes ou encore à un ou plusieurs groupes de personnes.
AuthName, définit ce qui sera affiché au client pour lui demander son nom et son mot de passe,
AuthType, définit le mode d'authentification et d'encryptage “basic” avec HTTP/0 ou “MD5” par exemple avec HTTP/1.
AuthUserFile, définit le fichier qui contient la liste des utilisateurs et des mots de passe. Ce fichier contient deux champs (Nom d'utilisateur, Mot de passe crypté). Vous pouvez créer ce fichier à partir du fichier /etc/passwd (attention ! faille de sécurité. Il n'est pas forcément avisé d'avoir le même mot de passe pour accéder à Linux et pour accéder à un dossier Web) ou avec la commande "htpasswd" d'Apache.
Exemple du mode d'utilisation de la commande "htpasswd" :
root@mr:/home# htpasswd --help
htpasswd [-cmdps] passwordfile username
-c Create a new file.
#> htpasswd -c /etc/apache/users mlx
Ici on crée le fichier /etc/apache/users et on ajoute un compte.
N'utiliser l'option "-c" que la première fois.
AuthGroupFile définit le fichier qui contient la liste des groupes et la liste des membres de chaque groupe,
Require permet de définir quelles personnes, groupes ou listes de groupes ont une permission d'accès.
Exemple de fichier AuthUserFile :
doudou:zrag FmlkSsSjhaz didon:PsddKfdqhgf.fLTER
Exemple de fichier AuthGroupFile :
users: tintin milou haddock dupond dupont tournesol tournesol dupont
Exemple d'autorisation :
require user tintin dupond /* tintin et dupond ont un accès */ require group users /* le groupe users à un accès */ require valid-user /* toute personne existant dans AuthUserFile */
Exemple d'accès sécurisé sur un répertoire :
<Directory /home/httpd/html/intranet/>
AuthName PatteBlanche
AuthType basic
AuthUserFile /etc/httpd/conf/users
AutGroupFile /etc/httpd/conf/group
<Limit GET POST>#Ici il faudra un mot de passe
require valid-user
</Limit>
</Directory>
Voici la fenêtre sécurisée que propose Netscape sur l'URL http://localhost/essai:
La déclaration d'un accès authentifié sur un répertoire peut être faite dans le fichier de configuration correspondant, comme nous venons de le voir, ou en créant un fichier ".htaccess" dans le répertoire que l'on souhaite sécuriser. Le fichier ".htaccess" contient les mêmes directives que celles qui auraient été déclarées dans le fichier httpd.conf. Ainsi, il est possible de délocaliser la gestion de la configuration, au moyen de fichiers spéciaux appelés par défaut .htaccess. Ce dernier paramètre est modifiable.
Le ".htaccess" correspondant à l'exemple précédent contient les directives suivantes :
AuthName PatteBlanche
AuthType basic
AuthUserFile /etc/httpd/conf/users
AutGroupFile /etc/httpd/conf/group
<Limit GET POST>#Ici il faudra un mot de passe
require valid-user
</Limit>
Attention :
Si vous mettez les clauses d'accès restreint pour un répertoire dans le fichier de configuration d'Apache, les clauses seront incluses entre 2 balises : <Directory ...> </Directory ...> Si vous mettez les clauses de restriction dans un fichier ".htaccess", vous n'avez pas besoin de mettre ces balises.
Quelques remarques :
Les fichiers .htaccess sont lus dynamiquement au moment de chaque requête qui concerne son répertoire : toute modification de ces fichiers prend donc effet immédiatement sans qu'il soit nécessaire au service de relire la configuration.
La directive AllowOverride None, permet de désactiver l'utilisation des fichiers .htaccess (attention, elle est à "None" par défaut). Pour qu'Apache lise ce fichier il lui faut mettre la directive : AllowOverride AuthConfig
Limitations de la sécurité par répertoire: ce procédé alourdit la charge du serveur. En effet, si une requête est passée sur www.MonDomaine.edu/rep1/rep2/index.html, le serveur va vérifier dans chaque répertoire rep1, rep2... l'existence d'un fichier .htaccess. Ce sont les règles du dernier fichier qui seront appliquées. Ce processus est mis en oeuvre pour chaque accès. Cette directive est donc à utiliser avec beaucoup de parcimonie car elle crée une surcharge pour le serveur.
Une directive particulière Userdir public_html permet de gérer pour chaque utilisateur (c'est à dire chaque possesseur d'un compte) des pages personnelles.
Dans apache2, cette directive est en fait associé à un module non activé par défaut. Il suffit donc d'activer le module correspondant par la commande a2enmod mod_userdir, ce qui aura pour effet de créer deux liens vers les fichiers correspondants userdir.conf et userdir.load.
Dans userdir.conf, on trouve par défaut les directives suivantes :
UserDir public_html, ce paramètre décrit le processus utilisé pour accéder aux pages personnelles d'une personne, si ces pages sont stockées dans son répertoire personnel.
Par défaut :
<Directory /home/*/public_html> AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec </Directory>
Supposons que vous êtes l'utilisateur "bestof" du réseau et que vous ayez des pages personnelles. Il sera possible d'accéder à vos pages, avec l'adresse suivante: www.MonDomaine.edu/~bestof/index.html. Le (tilde "~") permet d'accéder à votre répertoire personnel. La requête sera réellement exécutée sur "/home/bestof/public_html/index.html.
Attention, vérifier que le répertoire personnel ne soit pas en mode 700, car personne ne pourrait accéder aux pages personnelles.
UserDir disabled root, ce paramètre, par mesure de sécurité ne permet pas à l'utilisateur "root" de mettre en ligne un web personnel.
La configuration par défaut n'est pas très sécurisée car elle oblige à mettre les droits de lecture à tout le monde (755) sur le répertoire personnel. Il vous est possible de changer la variable Userdir par exemple :
UserDir /home/web
Pensez à changer la valeur de Directory.
Utilisez les commandes suivantes pour activer, désactiver le serveur:
/etc/init.d/apache start
/etc/init.d/apache stop
Pour relire le fichier de configuration alors qu'apache est déjà lancé, utilisez :
/etc/init.d/apache reload
Pour activer et desactiver un module, utilisez :
a2enmod nomModule
a2dismod nomModule
nomModule est le nom d'un module présent dans
/etc/apaches2/mods-available
Pour activer et desactiver un site WEB, utilisez
a2ensite nomSite
a2dissite nomSite
nomSite est le nom d'un fichier de configuration du
site présent dans
/etc/apaches2/sites-available
Pensez dans tous les cas à consulter les journaux afin de détecter les dysfonctionnements.
Quel protocole et quel port par défaut utilise le serveur Apache2 ?
Comment se nomme le principal fichier de configuration d'Apache2, et où se trouve-t-il ?
Dans quel répertoire sont situées les pages du serveur ?
Vous modifiez le port d'utilisation du serveur et vous faites un essai à partir d'un client. L'accès ne fonctionne pas. Donnez au moins deux raisons possibles et les moyens de remédier à ce problème.
Quel est le paramètre qui permet l'utilisation de répertoires personnels pour les utilisateurs afin de déployer leurs sites WEB personnels ?
Vous activez le paramètre du répertoire personnel dans Apache2 et relancez le serveur. Vous essayez l'accès sur votre compte or il est refusé. Que se passe-t-il et comment corriger le problème ?
Dans quels répertoires se trouvent les fichiers log d'Apache et comment se nomment ces fichiers ?
Table of Contents
Installation d'un serveur WEB - TP(s)
La séquence est bâtie pour des travaux réalisés avec plusieurs machines. Certaines parties pourront être réalisées sur votre propre machine, celle-ci servant de client et de serveur.
Vous devez avoir un navigateur d'installé, par exemple mozilla, firefox, konqueror, galeon...
La résolution de noms doit fonctionner.
Attention : Les paramètres peuvent différer d'une version à l'autre de Linux ou d'une distribution à l'autre. J'utilise dans ce document des variables, vous devrez y substituer les valeurs réelles de votre environnement.
$APACHE_HOME, répertoire dans lequel sont stockées les pages du serveur.
$APACHE_CONF, répertoire dans lequel sont stockés les fichiers de configuration.
$APACHE_USER, compte utilisateur sous lequel fonctionne Apache.
$APACHE_GROUP, groupe auquel est rattaché le compte $APACHE_USER.
D'autres variables peuvent être définies au besoin dans l'ensemble des TP.
Vous allez réaliser les opérations suivantes:
configurer le serveur HTTP pour qu'il soit activé en mode standalone
activer le serveur HTTP,
tester le fonctionnement du serveur
A la fin vous devriez pouvoir accéder sur toutes les machines (serveurs HTTP) du réseau à partir du navigateur client.
Attention Vous utiliserez les éléments donnés dans la fiche de cours.
Vous allez réaliser une configuration de base du serveur. Vous allez donc modifier les fichiers de configuration qui vous ont été présentés dans la fiche de cours. Avant toute modification, faites une copie de sauvegarde des fichiers.
Ouvrez le fichier à l'aide d'un éditeur, relevez et vérifiez les paramètres suivants. Pour chacun de ces paramètres vous noterez leurs rôles à partir de la fiche de cours et des commentaires (pensez à enregistrer vos modifications) :
ServerName, nom pleinement qualifié de votre serveur (FQDN)
Listen 80
User $APACHE_USER
Group $APACHE_GROUP
ServerAdmin webmaster@localhost
ServerRoot /etc/apache2
DocumentRoot $APACHE_HOME
UserDir public_html
DirectoryIndex index.html index.shtml index.cgi
AccessFileName .htaccess
Alias /icons/ $APACHE_ICONS/icons/
ScriptAlias /cgi-bin/ $APACHE_CGI/cgi-bin/
Regardez dans la fiche de cours les commandes de lancement du service serveur et la procédure de test. Regardez dans les fichiers de log et dans la table de processus si le service est bien démarré. Vérifier avec la commande netstat que le port 80 est bien ouvert.
Notez toutes les commandes que vous utilisez.
A ce stade le serveur est configuré et fonctionne. Il ne reste plus qu'à réaliser les tests. Vous devez pour cela activer le navigateur.
Faites les tests à partir de la machine locale et d'une machine distante. Utilisez les adresses localhost, 127.0.0.1, les adresses IP et les noms d'hôtes.
Si tout fonctionne, vous êtes en mesure de déployer votre site. Il suffira pour cela de l'installer dans l'arborescence $APACHE_HOME.
Dépannage: si cela ne fonctionne pas, procédez par élimination.
1 - Essayez avec les adresses IP des machines. Si ça fonctionne c'est que la résolution de noms n'est pas en place.
2 - Vérifiez que votre serveur est bien actif.
3 - Vérifiez que la configuration du serveur est correcte. Si vous apportez des modifications vous devez réinitialiser le serveur HTTP.
Quels sont les fichiers de base pour la configuration du serveur apache2 et dans quels répertoires sont-ils situés ?
Comment active-t-on un site ?
Comment se nomme le compte d'utilisateur qui utilise le serveur http ?
Quels sont les permissions d'accès par défaut sur le site principal du serveur ?
Dans quel répertoire sont installés par défaut les pages HTML du site ?
Dans quel répertoire par défaut sont stockés les scripts CGI et quel en est l'alias ?
Quel est le principal rôle des alias ?
Quelle(s) procédure(s) peut-on utiliser pour déterminer l'état du serveur et son bon fonctionnement ?
Vous installez un serveur Apache sur une machine d'adresse 192.168.90.1 et de nom foo.foo.org. Lors des tests sur la machine locale, les commandes http://localhost, http://127.0.0.1, http://192.168.90.1 fonctionnent et http://foo.foo.org ne fonctionne pas. Lors des tests à partir d'une machine distante les commandes http://192.168.90.1 et http://foo.foo.org fonctionnent.
Que peut-on en déduire et comment résoudre le problème ?
Table of Contents
Vous allez réaliser les opérations suivantes
Vérifier que la configuration de votre machine est correcte,
Développer quelques pages HTML puis les déployer,
Tester les nouvelles pages à partir d'un client Linux et Windows.
Vous utiliserez les archives qui vous sont fournies. Ces archives sont composées des quelques pages html qui vous serviront de site web et de scripts cgi.
Installez le service serveur et vérifiez qu'il est bien configuré et actif.
Pour tester la configuration de votre serveur, vous pouvez également utiliser la procédure suivante à partir de l'hôte local ou d'un hôte distant.
Lancez la commande suivante "$ telnet @IP du PC 80" (exemple : telnet 192.168.1.1 80 si cette adresse est celle de votre machine)
Cette commande crée une connexion au serveur httpd (port 80). Ce dernier invoque un agent.
Identifiez la connexion réseau dans une autre fenêtre xterm et avec la commande :
netstat -atup | grep ESTABLISHED root@mr:/home# netstat -atup | grep ESTABLISHED #Vous devriez obtenir quelque chose comme : tcp 0 0 mr:33073 mr:www ESTABLISHED 1513/telnet
Ensuite, transmettez à l'agent la ligne (commande) suivante : "GET /index.html"
Vérifiez que l'agent transmet de manière transparente le document HTML, et qu'il coupe automatiquement la connexion.
Vous allez utiliser les documents HTML fournis en annexe. Vous allez procéder de la façon suivante:
Créez un répertoire $APACHE_HOME/journal pour y mettre toutes les pages html
Copiez les images dans $APACHE_ICONS/icons (normalement /usr/share/apache2/icons)
Copiez le script cgi compilé "prog" dans $APACHE_CGI/cgi-bin (normalement /usr/lib/cgi-bin)
Testez le site à partir d'un navigateur avec la commande http://@URLDuServeur/journal/
Le site est maintenant déployé, testez l'enchaînement des pages, l'affichage des images.
Le formulaire ne fonctionne pas encore. Vous avez copié le script compilé "prog" dans "/usr/lib/cgi-bin". Vérifiez quel est le nom du script que le formulaire "form.html" essaie de lancer sur le serveur.
Modifiez le nom du script ou le formulaire en conséquence.
Testez le fonctionnement du formulaire dans un navigateur.
Si vous rencontrez des difficultés sur l'exécution du script, vérifiez dans le fichier adéquat de configuration d'apache que vous avez bien :
ScriptAlias /cgi-bin/ "/usr/lib/cgi-bin/"
et
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
Réalisez sous LINUX votre curriculum vitae en langage HTML. Celui-ci devra être composé de plusieurs documents reliés par des liens (ancres). Il sera installé dans $APACHE_HOME/cv et les images dans le répertoire référencé par l'alias /icons/.
- 1 page d'accueil de présentation avec les liens sur les autres pages,
- 1 page pour la formation initiale,
- 1 page pour les expériences professionnelles,
- 1 page pour les loisirs, passions...
Chaque page doit vous permettre de revenir à la page d'accueil.
Mettez les pages dans le répertoire qui était prévu $APACHE_HOME/cv
Vous allez vous connecter à votre site à partir d'un client distant. Utilisez de préférence les adresses URL. Corrigez les erreurs si l'accès n'est pas réalisé.
Afin de comprendre le fonctionnement des alias vous allez maintenant réaliser quelques manipulations. Vous allez déplacer le répertoire qui contient les images de "$APACHE_HOME/icons" vers "/tmp/httpd/icons.
Réalisez l'opération de déplacement du répertoire vers /tmp/httpd/icons,
Apportez les modifications nécessaires aux fichiers de configuration d'Apache
Vérifiez le résultat.
Vous constatez ainsi qu'il est possible de déplacer un répertoire sur un serveur, sans qu'il soit nécessaire pour autant de modifier toutes les pages utilisant ce répertoire.
Quel est le nom de la page par défaut qui est ouverte par le navigateur dans un répertoire du serveur HTTP.
Quel intérêt procure l'utilisation des alias ?
Dans quels répertoires sont, par défaut, installés les pages HTML, scripts CGI, images et comment se nomment les alias ?
On crée un répertoire $APACHE_HOME/html/journal pour y stocker des pages HTML. Il n'est pas possible d'y accéder alors que pour les autres sites tout fonctionne. Voici le message renvoyé par le navigateur. Aucune mesure de sécurité n'a été mise en oeuvre.
Forbidden you don't have permission to access / on this server
Quelle est la cause du problème et comment y remédier ?
Table of Contents
Vous allez mettre en place un accès pour les utilisateurs du système. Ceux-ci auront la possibilité de mettre leurs pages personnelles dans leur répertoire privé.
Vous allez réaliser les opérations suivantes:
Configurer le compte personnel,
Développer un site personnel,
Tester l'accès au site personnel.
Relevez dans le fichier de configuration d'Apache2 adéquat le nom du répertoire dans lequel doivent être stockées les pages personnelles.
Créez un compte d'utilisateur. Je vais utiliser, pour la description des opérations le compte "mlx",
Allez dans le répertoire personnel /home/mlx,
Créez le répertoire du site Web personnel ,
Dans ce répertoire vous allez créer un répertoire pour les pages, un pour les images, un pour les scripts CGI avec la commande mkdir.
Vous allez utiliser les pages HTML fournies en annexes. Utilisez les documents du TP précédent si vous en avez besoin.
Installez les fichiers fournis en annexe dans les répertoires adéquats.
Modifiez les pages HTML à l'aide d'un éditeur pour qu'elles utilisent les images de votre répertoire personnel "~/public_html/images" et le script CGI de votre répertoire personnel "~/public-html/cgi-bin" et pas ceux qui sont dans "$APACHE_HOME/cgi-bin".
Pour autoriser l'utilisation de scripts CGI dans un répertoire, vous devez le déclarer. Voici trois exemples :
<Directory /home/*/public_html/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory>
<Directory /home/*/public_html>
Options +ExecCGI
</Directory>
<Directory /var/www/journal>
Options +ExecCGI
</Directory>
Recherchez également la ligne suivante dans le fichier
apache2.conf
:
AddHandler cgi-script .cgi .sh .pl
Décommentez là ou ajoutez la si elle n'y est pas.
Copiez le script dans le répertoire que vous réservez pour les scripts. Vérifiez si c'est un programme "C" compilé qu'il porte bien l'extension ".cgi", au besoin renommez-le.
Vous pouvez maintenant tester votre site personnel. A l'aide d'un navigateur utilisez l'URL "http//localhost/~mlx", (remarquez l'utilisation du "~" pour définir le répertoire personnel.)
Corrigez toutes les erreurs que vous pouvez rencontrer (problèmes d'alias, page principale, page de liens, problèmes de scripts, permissions d'accès au répertoire...)
Faites le test avec les sites personnels situés sur les autres machines.
Quel avantage présente l'utilisation des répertoires personnels pour le développement de sites Web ?
Vous installez votre site personnel et vos pages. Vous tentez de réaliser un test or vous n'arrivez pas à accéder à vos pages. Quels peuvent être les problèmes et comment y remédier ?
Vous rencontrez un problème de configuration. Vous apportez les corrections dans les fichiers de configuration, or la modification n'est toujours pas prise en compte sur le client. Que se passe-t-il et comment corriger le problème ?
Comment avez vous fait pour que les scripts personnels soient chargés et exécutés de /home/mlx/public_html/cgi-bin
Pour l'utilisateur mlx, sur la machine saturne et le domaine toutbet.edu, donnez:
l'adresse URL de son site personnel,
l'emplacement physique de son répertoire personnel sur la machine,
le nom (et chemin complet) du fichier qui est activé quand on accède à son site.
Table of Contents
Vous allez réaliser les opérations suivantes:
1 - Déployer un site d'accès en ligne
2 - Sécuriser l'accès à ce site par un mot de passe
3 - Tester la configuration.
Vous allez utiliser les pages fournies en annexe.
Créez un répertoire sur votre machine. "mkdir $APACHE_HOME/protege"
Copiez les pages dans ce répertoire.
Dans un premier temps vous allez interdire l'accès à tout le monde. Pour cela vous allez modifier le fichier de configuration d'Apache2 adéquat et y mettre les lignes suivantes :
<Directory $APACHE_HOME/protege> order deny,allow deny from all </Directory>
Arrêtez puis relancez le serveur et faites un test à partir d'un navigateur. Notez le message qui apparaît. Plus personne n'a accès au site.
Pour mettre un accès sécurisé par mot de passe il manque 2 éléments:
Modifiez la configuration d'accès au répertoire,
Créez le mot de passe crypté.
Modifiez la configuration d'accès au répertoire
<Directory $APACHE_HOME/protege> AuthName Protected AuthType basic AuthUserFile $APACHE_CONF/users # fichier de mots de passe <Limit GET POST> require valid-user # ici on demande une authentification </Limit> </Directory>
Créez le mot de passe crypté.
Le mot de passe est un fichier texte à deux champs séparés par un "deux points" (:). Le premier champ contient le compte d'utilisateur, le deuxième contient le mot de passe crypté.
Pour créer ce fichier, les comptes et les mots de passe, utilisez la commande "htpasswd".
Ouvrez une session à l'aide d'un navigateur et ouvrez l'URL "http://localhost/protege"
Une fenêtre d'authentification doit s'ouvrir, entrez le nom d'utilisateur et le mot de passe.
Réalisez les opérations à partir de machines distantes.
Dépannage:
Vérifiez le nom du répertoire que vous avez créé et la déclaration dans le fichierde configuration,
Vérifiez le nom et la structure du fichier dans lequel vous avez mis les mots de passe.
Si vous faites plusieurs tests, quittez puis relancez le navigateur après chaque session ouverte ou refusée,
Vérifiez que le répertoire soit bien en mode 755 (chmod)
Si cela ne fonctionne toujours pas reprenez le processus au début:
- affectez toutes les permissions à tout le monde,
- supprimez toutes les permissions à tout le monde,
- affectez les restrictions.
Utilisez un compte sans mot de passe. Le fichier $APACHE_CONF/users va contenir uniquement la chaîne: mlx, mais il n'y a pas le mot de passe.
Si cela fonctionne alors le problème vient du cryptage du mot de passe.
Une fois que vous avez été authentifié, quittez et relancez le navigateur si vous voulez refaire le test d'accès à la ressource protégée.
En vous basant sur ce que vous venez de faire, sécurisez l'accès à un autre répertoire en utilisant un fichier .htaccess.
Dans quel cas un accès sécurisé peut-il être utilisé ?
Vous affectez un mot de passe à un utilisateur distant. Vous faites un test sur votre machine tout semble fonctionner. Il vous appelle pour vous dire que ses requêtes sur le site protégé sont toujours rejetées. Que se passe-t-il ?
Si on utilise les possibilités du système, quelle autre solution peut-on utiliser pour interdire l'accès à un répertoire.
Table of Contents
Il existe deux méthodes qui permettent de faire communiquer un formulaire html avec un script CGI. La méthode POST et la méthode GET. Nous utiliserons ici la méthode POST.
Ce TP doit vous permettre de développer un formulaire et un script CGI en C. Vous devez savoir compiler un programme.
Vous allez réaliser les opérations suivantes:
Etudier les sources fournies en annexe.
Développer un formulaire et adaptez les scripts,
Tester le fonctionnement des scripts.
Transférez les programmes C, les .h et le makefile dans votre répertoire personnel. Etudiez attentivement les sources. Testez le fonctionnement du script.
A partir de l'exemple fourni, développez les pages HTML d'un site commercial qui doit permettre la prise de commande à distance de pizzas. Il doit y avoir au moins 3 pages:
une page principale,
une page de description des produits,
une page (formulaire) pour passer commande contenant tous les types de champs qui existent dans le formulaire form.html. (liste déroulante, bouton radio, zone de texte)
Exemple :
Zone de texte (Nom du client)
Liste déroulante (Calzone, Margarita, Quatre-saisons)
Bouton radio (Grande, Moyenne, Petite)
Case à cocher (Avec des anchois)
Vous afficherez au client le résultat de sa commande.
Adaptez le script CGI qui vous est fourni, à votre formulaire.
Pour tester le script:
ouvrez la page principale de votre site à l'aide d'un navigateur,
passez des commandes,
vérifiez les résultats retournés par le script. (réponse).
Que signifie CGI ?
Quel intérêt présente l'utilisation de scripts CGI ?
Quelle est la différence entre la méthode GET et POST ?
Comment se nomment les variables d'environnement qui contiennent la chaîne (paramètres) du formulaire ?
Comment est structurée cette chaîne ?
Quel est le caractère de concaténation des chaînes ?
Pourquoi la réponse contient dans l'entête la chaîne Content-type: text/html ?
A quoi correspondent ces 2 paramètres text et html ?
Table of Contents
Il est préférable d'avoir réalisé les TP sur les serveurs de noms avant de réaliser celui-ci.
Pour réaliser ce TP, vous devrez avoir un serveur de noms qui fonctionne.
La mise en place de serveurs webs virtuels, permet de faire cohabiter plusieurs serveurs sur un même hôte. Nous verrons qu'il y a plusieurs techniques pour faire cela.
On ajoutera, dans un premier temps le paramétrage des sites virtuels dans le fichier de configuration spécifique situé dans /etc/apache2/sites-available/default mais il est tout à fait possible de créer dans ce même répertoire un fichier pour chaque serveur virtuel.
Les serveurs virtuels basés sur le nom, dans ce cas, vous devrez désigner pour une adresse IP sur la machine (et si possible le port), quel est le nom utilisé (directive ServerName), et quelle est la racine du site (directive DocumentRoot).
Le nom de serveur (ServerName) et la racine web (DocumentRoot) doivent exactement correspondre respectivement au nom sous lequel le serveur virtuel sera nommé dans les URL clientes et au chemin du répertoire d'accueil des documents du site.
# Ici toutes les adresses ip sont utilisées, on peut mettre *
NameVirtualHost *
# Toutes les requêtes sur http://www.domain.tld/
# pointeront sur /www/domain
<VirtualHost *>
ServerName www.domain.tld
DocumentRoot /www/domain
</VirtualHost>
# Toutes les requêtes sur http://www.otherdomain.tld/
# pointeront sur /www/otherdomain
<VirtualHost *>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
# Ici on utilise une adresse en particulier
# Toutes les requêtes sur http://www.domain.tld/domain
# pointeront sur /web/domain
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.domain.tld
ServerPath /domain
DocumentRoot /web/domain
</VirtualHost>
Dès lors que l'on a des serveurs virtuels qui "tournent" sur des ports différents, il est obligatoire de préciser pour chaque serveur virtuel son port :
NameVirtualHost * devient NameVirtualHost *:80 <VirtualHost *> devient <VirtualHost *:80>
Nous le verrons avec le TP sur SSL.
Les serveurs virtuels basés sur des adresses IP. Dans ce cas, chaque serveur aura sa propre adresse IP. Vous devrez également avoir un serveur de noms sur lequel toutes les zones et serveurs sont déclarés, car c'est ce dernier qui assurera la correspondance "adresse ip <-> nom du serveur" :
# Chaque serveur peut avoir son propre administrateur, ses
# propres fichiers de logs.
# Tous fonctionnent avec la même instance d'Apache.
# Il est possible de lancer plusieurs instances d'apache
# mais sur des ports différents
<VirtualHost www.smallco.com>
ServerAdmin webmaster@mail.smallco.com
DocumentRoot /groups/smallco/www
ServerName www.smallco.com
ErrorLog /groups/smallco/logs/error_log
TransferLog /groups/smallco/logs/access_log
</VirtualHost>
<VirtualHost www.baygroup.org>
ServerAdmin webmaster@mail.baygroup.org
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>
La redirection est un service un peu particulier, qui diffère de celui des services web virtuels. Il permet de rediriger une partie du site web à un autre endroit du disque physique. La encore on utilisera une des fonctions d'Apache qui permet de définir des alias.
Prenons par exemple un site installé physiquement sur "/var/www" et accessible par l'url "http://FQDN". L'url "http://FQDN/unREP" devrait correspondre normalement à l'emplacement physique "/var/www/unREP". La redirection va permettre de rediriger physiquement vers un autre répertoire.
Cette technique est largement utilisée par des applications ou pour la création d'espaces documentaires.
L'URL "http://FQDN/compta", pourra pointer physiquement dans "/usr/lib/compta" au lieu de "/var/www/compta".
Dans cet atelier, vous allez réaliser les opérations suivantes:
Installer un service de serveurs web virtuels par adresse et par nom,
Mettre en place un service de redirection par alias.
Configurez votre serveur de noms si ce n'est pas fait. Vous pouvez vous aider de l'annexe sur le "web-hosting" ci-dessous.
Pour créer des alias dynamiquement à votre interface réseau, utilisez la commande suivante:
ifconfig eth0:0 192.168.0.1
ifconfig eth0:1 192.168.1.1
ifconfig
eth0 Lien encap:Ethernet HWaddr 00:D0:59:82:2B:86
inet adr:192.168.90.2 Bcast:192.168.90.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:95041 errors:0 dropped:0 overruns:0 frame:0
TX packets:106227 errors:0 dropped:0 overruns:26 carrier:0
collisions:0 lg file transmission:100
RX bytes:57490902 (54.8 MiB) TX bytes:11496187 (10.9 MiB)
Interruption:11 Adresse de base:0x3000
eth0:0 Lien encap:Ethernet HWaddr 00:D0:59:82:2B:86
inet adr:192.168.0.1 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interruption:11 Adresse de base:0x3000
eth0:1 Lien encap:Ethernet HWaddr 00:D0:59:82:2B:86
inet adr:192.168.1.1 Bcast:192.168.1.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interruption:11 Adresse de base:0x3000
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:70 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:4564 (4.4 KiB) TX bytes:4564 (4.4 KiB)
Créez votre serveur de noms pour deux domaines par exemple (domain1.org et domain2.org), adaptez la configuration du fichier "/etc/resolv.conf", vérifiez le bon fonctionnement de la résolution de noms sur les CNAME (www.domain1.org et www.domain2.org).
D'abord les déclarations dans le fichier de configuration :
# Web hosting ip based NameVirtualHost 192.168.0.1 <VirtualHost 192.168.0.1> DocumentRoot /home/web/domain1 ServerName www.domain1.org </VirtualHost> NameVirtualHost 192.168.1.1 <VirtualHost 192.168.1.1> DocumentRoot /home/web/domain2 ServerName www.domain2.org </VirtualHost>
Préparation des sites webs (sans trop se casser la tête) :
# mkdir -p /home/web/domain1 /home/web/domain2 # echo "<H1>Salut domain1 </H1>" > /home/web/domain1/index.html # echo "<H1>Salut domain2 </H1>" > /home/web/domain2/index.html
On relance Apache :
/etc/init.d/apache2 restart
C'est terminé, les requêtes sur "http://ww.domain1.org", "http://www.domain2.org", doivent fonctionner et vous renvoyer la bonne page.
On va utiliser l'adresse ip de ns1.domain1.org pour les url w3.domain1.org et wiki.domain1.org. w3 et wiki sont deux zones de déploiement de site web différentes, sur un même serveur HTTP.
Modification du fichier de configuration :
# Web hosting name based (basé sur le nom) #Site secondaire de domain1 <VirtualHost 192.168.0.1> ServerName w3.domain1.org DocumentRoot /home/web/w3 </VirtualHost> <VirtualHost 192.168.0.1> ServerName wiki.domain1.org DocumentRoot /home/web/wiki </VirtualHost>
Relisez la configuration d'Apache2.
Création des sites web :
# mkdir -p /home/web/wiki /home/web/w3 # echo "<H1>Salut w3 </H1>" > /home/web/w3/index.html # echo "<H1>Salut wiki </H1>" > /home/web/wiki/index.html
Mettez les droits nécessaires.
C'est terminé, les requêtes sur :
http://w3.domain1.org http://wiki.domain1.org
doivent retourner les bonnes pages.
Nous allons créer un espace documentaire pour le domain "domain1.org". Il sera accessible par l'url "http://www.domain1.org/mesdocs", mais il sera localisé dans "/etc/domain1doc".
Créez un répertoire "domain1doc" dans /etc pour ce nouveau projet et mettez-y le fichier "apache.conf" ci-dessous:
# Création du répertoire mkdir /etc/domain1doc # Création du fichier /etc/domain1doc/apache.conf Alias /mesdocs /etc/domain1doc/ <Directory /etc/domain1doc> Options FollowSymLinks AllowOverride None order allow,deny allow from all </Directory>
Faites une inclusion de ce fichier dans le fichier de configuration d'Apache et relancez le service Apache.
C'est terminé, toutes les requêtes sur "http://www.domain1.org/mesdocs", ouvriront les pages qui sont dans "/etc/domain1doc".
=== A rajouter dans /etc/bind/named.conf
zone "domain1.org" {
type master;
file "/etc/bind/domain1.org.hosts";
};
zone "domain2.org" {
type master;
file "/etc/bind/domain2.org.hosts";
};
=== fichiers de zone
root@freeduc-sup:/etc/bind# more domain1.org.hosts
$ttl 38400
@ IN SOA domain1.org. hostmaster.domain1.org. (
2004052604
10800
3600
604800
38400 )
@ IN NS ns1.domain1.org.
ns1 IN A 192.168.0.1
www IN CNAME ns1
wiki IN CNAME ns1
w3 IN CNAME ns1
root@freeduc-sup:/etc/bind# more domain2.org.hosts
$ttl 38400
@ IN SOA domain2.org. hostmaster.domain2.org. (
2004052604
10800
3600
604800
38400 )
@ IN NS ns1.domain2.org.
ns1 IN A 192.168.1.1
www IN CNAME ns1
Table of Contents
Abstract
Ce cours se propose de définir les concepts de base du chiffrement et surtout ses objectifs :
Définition du chiffrement ;
Les deux méthodes de chiffrement (chiffrement symétrique et chiffrement asymétrique) ;
Les objectifs du chiffrement (confidentialité, authentification, intégrité, signature électronique) ;
La notion de certificat ;
La mise en oeuvre avec le protocole SSL.
Le chiffrement consiste à rendre illisible un message en brouillant ses éléments de telle sorte qu'il soit très difficile de reconstituer l'original si l'on ne connaît pas la transformation appliquée.
Le chiffrement est basé sur deux éléments : une clé et un algorithme .
La clé est une chaîne de nombres binaires (0 et 1).
L'algorithme est une fonction mathématique souvent complexe qui va combiner la clé et le texte à crypter pour rendre ce texte illisible.
Pour "casser" un chiffrement, il n'existe que deux solutions :
Il faut essayer toutes les clés, ce qui devient impossible actuellement compte tenu de la longueur de celles-ci ;
"Casser" l'algorithme (qui est, en général, connu par tous), c'est-à-dire rechercher une faille dans la fonction mathématique ou dans son implémentation permettant de trouver la clé plus rapidement.
Le choix d'un algorithme dépend donc de :
La fiabilité de ce dernier (savoir s'il existe des failles importantes) ;
La longueur de clé qu'il gère ;
De ce que l'on va en faire : on sera plus vigilant pour un serveur RADIUS permettant l'accès au réseau WIFI de la NASA que pour notre messagerie personnelle...
La même clé est utilisée pour coder et décoder et doit bien évidemment rester secrète.
Un algorithme répandu consiste à effectuer des substitutions et des transpositions en cascade sur les lettres du message. Par exemple : MICROAPPLICATION devient IRMCAPOPIALCINTO si l'on fixe comme clé le principe suivant : "la première lettre sera la troisième, la seconde sera la première, la troisième sera la quatrième et la quatrième sera la seconde".
La figure suivante illustre le principe du chiffrement symétrique.
Quelques algorithmes couramment utilisés (liste non exhaustive) :
Data Encryption Standard (DES) est une invention du National Bureau of Standards (NSB) américain, qui date de 1977 : c'est le premier algorithme de chiffrement publique gratuit. Les données sont découpées en blocs de 64 bits et codées grâce à la clé secrète de 56 bits propre à un couple d'utilisateurs
RC2, RC4 et RC5 sont des algorithmes créés à partir de 1989 par Ronald Rivest pour la RSA Security. L'acronyme "RC" signifie "Ron's Code" ou "Rivest's Cipher". Ce procédé permet aux utilisateurs la possibilité de choisir la grandeur de la clé (jusqu'à 1024 bits).
Advanced Encryption Standard (AES) est un standard approuvé par le ministère américain du commerce en 2001 et vise à remplacer le DES ; il est placé dans le domaine public et accepte des clés d'une taille de 128, 192 ou 266 bits.
Les inconvénients de ce système de chiffrement sont les suivants :
il faut autant de paires de clés que de couples de correspondants ;
la non-répudiation n'est pas assurée. Mon correspondant possédant la même clé que moi, il peut fabriquer un message en usurpant mon identité ;
il faut pouvoir se transmettre la clé au départ sans avoir à utiliser le média à sécuriser !
C'est une approche radicalement différente apparue en 1976 : la clé qui sert à coder est différente de celle qui peut déchiffrer.
La grande nouveauté introduite par cette famille de méthodes, c'est que la clé chiffrante est publique. Cette notion de cryptographie à clé publique résulte d'un défi mathématique lancé par Witfield Diffie et Martin Hellman. Trois mathématiciens américains (Ronald Rivest, Adi Shamir et Leonard Adleman) ont réussi à l'époque à trouver une solution, aujourd'hui employée sous le nom de RSA.
La méthode repose sur un constat très simple : il est facile d'effectuer la multiplication de deux nombres premiers, mais il est très difficile de retrouver les facteurs quand le résultat est grand.
La clé publique est donc constituée du produit n de deux nombres premiers p et q, choisis très grands. La clé secrète dépend directement de p et q et ne peut donc etre déduite de la clé publique.
En résumé, chacun dispose d'une clé privée qui est gardée secrète et d'une clé publique qui est destinée à être divulguée. Ces clés sont liées entre elles. Un document encrypté avec l'une ne peut être décodée qu'avec l'autre. Toutefois, la possession de l'une des clés ne permet pas d'en déduire l'autre.
Un autre algorithme utilisant le système de chiffrage asymétrique largement utilisé est le DSA (Digital Signature Algorithm).
Ce système a réellement permit d'assurer des fonctions essentielles telles que la confidentialité et l'