Cours dintroduction ` a TCP/IP

Fran cois Laissus Version du 25 f evrier 2009

ii Copyright c 1999 - 2009 $Rev: 131 $ Fran cois Laissus

Avant propos
Les sources de ce document sont d evelopp ees, g er ees et conserv ees gr ace aux services de FreeBSD1 , remarquable syst` eme dexploitation OpenSource ! Les divers chiers qui composent le source sont edit es ` a laide de l editeur de texte vi ; lhistorique des modications est con e aux bons soins de loutil subversion (gestionnaire de versions). Lensemble du processus de fabrication est pilot e par une poign ee de chiers Makefile (commande make).
A La mise en forme seectue gr ace au logiciel L TEX. Les gures sont dessin ees sous X Window Systems (X11) ` a laide du logiciel xfig et int egr ees directement dans le document nal sous forme de PostScript encapsul e. Les listings des exemples de code C ont et e fabriqu es ` a laide du logiciel a2ps et inclus dans le document nal egalement en PostScript encapsul e.

La sortie papier a et e imprim ee en PostScript sur une imprimante de type laser, avec dvips. La version pdf est une transformation du format PostScript ` a laide du logiciel dvipdfm, enn la version HTML est traduite directement A en HTML ` a partir du format L TEX ` a laide du logiciel latex2html. Tous les outils ou formats utilis es sont en acc` es ou usage libre, cest ` a dire sans versement de droit ` a leurs auteurs respectifs. Quils en soient remerci es pour leurs contributions inestimables au monde informatique libre et ouvert ! Je remercie egalement Jean-Jacques Dh enin et les nombreux lecteurs que je ne connais quau travers de leur e-mails, davoir bien voulu prendre le temps de relire lint egralit e de ce cours et de me faire part des innombrables erreurs et coquilles typographiques quil comporte, merci encore ! Ce support de cours est en consultation libre ` a cette url : HTML http://www.laissus.fr/cours/cours.html

Ou ` a t el echarger au format PDF : HTTP FTP http://www.laissus.fr/cours/cours.pdf ftp://ftp.laissus.fr/pub/cours/cours.pdf

Dautres formats (.ps,.dvi,. . .) sont accessibles dans ce r epertoire : HTTP FTP http://www.laissus.fr/pub/cours/ ftp://ftp.laissus.fr/pub/cours/

http://www.freebsd.org/

iii Copyright c 1999 - 2009 $Rev: 131 $ Fran cois Laissus

Historique des principaux changements

` ce jour(25/02/2009), ce document existe et est accessible sur lInternet A depuis le milieu des ann ees 90. De tr` es nombreux internautes lont t el echarg e et mont renvoy e leurs commentaires. Il etait donc plus que temps de garder une trace des principales modications et restructurations an que ces lecteurs d` eles puissent suivre les modications et, peut etre, t el echarger une nouvelle version en connaissance de cause !

Version du 25 F evrier 2009 Restructuration de lensemble en quatre parties principales (A,B,C, D) et un index g en eral. Ajout dune partie R eseaux IP avanc es . Ajout dun chapitre sur SNMP et dun chapitre sur le routage dynamique. Ajout dun changelog, cette page. . . Le .pdf est maintenant r eactif, les urls, les renvois de pages, le sommaire, les listes de tableaux et gures. Nombreuses corrections et mises ` a jour de tous les chapitres depuis la version du 14 octobre 2007.

iv

Table des mati` eres

Pr eface xxi

A
I 1 2

Introduction ` a la pile ARPA

R eseaux locaux Pr eambule . . . . . . . . . . . . . . . . . . . . . . G en eralit es - LANs . . . . . . . . . . . . . . . . . 2.1 G en eralit es . . . . . . . . . . . . . . . . . 2.2 Mod` ele de communication OSI . . . . . . R eseaux locaux . . . . . . . . . . . . . . . . . . . 3.1 Quest-ce quun LAN ? . . . . . . . . . . . 3.2 WAN - MAN . . . . . . . . . . . . . . . . 3.3 Communications inter-r eseaux . . . . . . . Couche 2 - Liaison (Data Link) . . . . . . . . . . 4.1 Caract eristiques dEthernet . . . . . . . . 4.1.1 Quelques principes fondamentaux 4.1.2 Format dune Frame Ethernet 4.1.3 Adresses IEEE 802.3 ou Ethernet 4.1.4 Unicast, multicast et broadcast . 4.2 Di erences Ethernet - 802.2/802.3 . . . . . Interconnexion - Technologie el ementaire . . . . . 5.1 Raccordement . . . . . . . . . . . . . . . . 5.1.1 10Base5 . . . . . . . . . . . . . . 5.1.2 10Base2 . . . . . . . . . . . . . . 5.1.3 10BaseT . . . . . . . . . . . . . . 5.1.4 Fibre optique . . . . . . . . . . . 5.1.5 Conclusion . . . . . . . . . . . . 5.2 R ep eteur . . . . . . . . . . . . . . . . . . . 5.3 Concentrateur . . . . . . . . . . . . . . . . 5.4 Ponts . . . . . . . . . . . . . . . . . . . . 5.5 Commutateurs . . . . . . . . . . . . . . . 5.6 Passerelles Routeurs . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . Introduction ` a IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
3 3 3 3 4 7 7 8 8 9 9 9 10 11 12 13 14 15 15 15 16 16 17 17 18 19 20 22 23 25

6 II

vi 1 2 3

` TABLE DES MATIERES TCP/IP et lInternet - Un peu dhistoire Caract eristiques de TCP/IP . . . . . . . Comparaison TCP/IP ISO . . . . . . 3.1 Couche Application Layer . . 3.2 Couche Transport Layer . . . 3.3 Couche Internet Layer . . . . 3.4 Couche Network Access . . . Encapsulation dIP . . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 27 28 29 29 30 30 30 31 33 33 33 34 35 35 37 38 40 41 42 42 43 44 47 47 47 48 49 52 52 53 55 55 57 58 58 59 59 60 61 63 63 64

4 5

III Anatomie dune adresse IP 1 Adressage IP . . . . . . . . . . . . . . . 1.1 Unicit e de ladresse . . . . . . . . . 1.2 D elivrance des adresses IPv4 . . . . 2 Anatomie dune adresse IP . . . . . . . . . 2.1 D ecomposition en classes . . . . . . 2.2 Adresses particuli` eres . . . . . . . . 2.3 Sous-r eseaux . . . . . . . . . . . . . 2.4 CIDR . . . . . . . . . . . . . . . . 2.5 Pr ecisions sur le broadcast . . . . . 3 Adressage multicast . . . . . . . . . . . . . 3.1 Adresse de groupe multicast . . . . 3.2 Adresse multicast et adresse MAC . 4 Conclusion et bibliographie . . . . . . . . . IV 1 Protocole IP Datagramme IP . . . . . . . . . . . . . . 1.1 Structure de len-t ete . . . . . . . 1.2 Network Byte Order . . . . . . . 1.3 Description de len-t ete . . . . . . 1.4 Fragmentation IP - MTU . . . . 1.4.1 Fragmentation . . . . . 1.4.2 R eassemblage . . . . . . Protocole ARP . . . . . . . . . . . . . . 2.1 Fonctionnement . . . . . . . . . . 2.2 Format du datagramme . . . . . 2.3 Proxy ARP . . . . . . . . . . . . Protocole RARP . . . . . . . . . . . . . Protocole ICMP . . . . . . . . . . . . . . 4.1 Le syst` eme de messages derreur . 4.2 Format des messages ICMP . . . 4.3 Quelques types de messages ICMP Protocole IGMP . . . . . . . . . . . . . . 5.1 Description de len-t ete . . . . . . 5.2 Fonctionnement du protocole . . . . . . . . . . . . . . . . . . . . .

3 4

` TABLE DES MATIERES 5.3 Fonctionnement du Mbone . . . . . . . . . . . . . . Routage IP . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Table de routage . . . . . . . . . . . . . . . . . . . 6.2 Routage statique . . . . . . . . . . . . . . . . . . . 6.2.1 Algorithme de routage . . . . . . . . . . . 6.3 Routage dynamique . . . . . . . . . . . . . . . . . . 6.3.1 RIP Routing Information Protocol 6.3.2 OSPF Open Shortest Path First . . 6.4 D ecouverte de routeur et propagation de routes . . 6.5 Message ICMP redirect . . . . . . . . . . . . . 6.6 Interface de loopback . . . . . . . . . . . . . . Finalement, comment ca marche ? . . . . . . . . . . . . . . Conclusion sur IP . . . . . . . . . . . . . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 66 67 69 70 71 72 73 73 74 75 76 78 79 81 81 81 83 85 86 86 87 89 89 89 91 94 94 95 95 96 97 97 98 100 100 101 101 102 105 105

vii

7 8 9 V

Protocole UDP 1 UDP User Datagram Protocol . . . . . . . . . . . . . . . 1.1 Identication de la destination . . . . . . . . . . . . 1.2 Description de len-t ete . . . . . . . . . . . . . . . . 1.3 Ports r eserv es ports disponibles . . . . . . . . . 1.3.1 Attribution des ports ancienne m ethode 1.3.2 Attribution des ports nouvelle m ethode 2 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . Protocole TCP TCP Transmission Control Protocol . . . 1.1 Caract eristiques de TCP . . . . . . 1.2 Description de len-t ete . . . . . . . D ebut et cl oture dune connexion . . . . . 2.1 Etablissement dune connexion . . 2.2 Cl oture dune connexion . . . . . . 2.2.1 Cl oture canonique . . . . 2.2.2 Cl oture abrupte . . . . . . Contr ole du transport . . . . . . . . . . . 3.1 M ecanisme de lacquittement . . . 3.2 Fen etres glissantes . . . . . . . . . Compl ements sur le fonctionnement de TCP 4.1 Algorithme de Nagle . . . . . . . . 4.2 D epart lent . . . . . . . . . . . . . 4.3 Evitement de congestion . . . . . . Paquets captur es, comment es . . . . . . . Conclusion sur TCP . . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

VI 1

5 6 7

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

viii

` TABLE DES MATIERES

R eseaux IP avanc es

107
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 109 110 111 113 114 116 117 118 120 120 120 120 120 121 121 122 124 127 127 127 129 130 131 131 133 133 135

VII Routage dynamique dIP 1 Introduction & rappels . . . . . . . . . . . . . . . . . 1.1 IGP, EGP, Syst` eme autonome . . . . . . . . . 1.2 Vecteur de distances vs Etat de liens . . . . . 2 Routage avec RIP . . . . . . . . . . . . . . . . . . . . 2.1 En fonctionnement . . . . . . . . . . . . . . . 2.1.1 Horizon partag e ou Split horizon . . 2.1.2 Mises ` a jour d eclench ees ou Triggered 2.2 Le protocole RIPv1 vs RIPv2 . . . . . . . . . 2.3 Algorithme Bellman-Ford . . . . . . . . . . . 2.3.1 M etrique . . . . . . . . . . . . . . . 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . 2.4.1 Points forts . . . . . . . . . . . . . . 2.4.2 Points faibles . . . . . . . . . . . . . 3 Routage avec OSPF . . . . . . . . . . . . . . . . . . 3.1 Grandes lignes de fonctionnement . . . . . . . 3.2 RIP vs OSPF . . . . . . . . . . . . . . . . . . 3.3 Principe de propagation des etats . . . . . . . 3.3.1 Valeur des etats de liens . . . . . . . 3.4 Calcul du plus court chemin . . . . . . . . . . 3.5 Hi erarchie de routeurs . . . . . . . . . . . . . 3.6 Fonctionnement ` a lint erieur dune zone . . . . 3.6.1 Voisinage et adjacence . . . . . . . . 3.7 Protocole HELLO . . . . . . . . . . . . . . . . 3.7.1 Cinq types de paquets . . . . . . . . 3.7.2 En-t ete standard des paquets OSPF 3.7.3 En-t ete des paquets HELLO . . . . . 4 Bibliographie . . . . . . . . . . . . . . . . . . . . . . ements de r VIII El eseaux 1 H otes ou services virtuels . . . . . . . . . . . . . . . 2 Tunnel IP . . . . . . . . . . . . . . . . . . . . . . . 2.1 Tunnel IP avec linterface gif . . . . . . . . 2.2 IPsec et VPN . . . . . . . . . . . . . . . . . 2.2.1 IPsec dans quel but ? . . . . . . . . 2.2.2 IPsec en r esum e . . . . . . . . . . 2.2.3 Comment utiliser IPsec ? . . . . . . 2.2.4 Impl ementation dIPsec . . . . . . 3 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 Translation dadresses . . . . . . . . . . . . . . . . 4.1 NAPT sur un routeur de type PC avec natd 4.1.1 Interactions entre natd et le noyau 4.2 Translation dadresses vers le r eseau priv e . . . . . . . . . . . . . .

137 . 137 . 139 . 140 . 143 . 143 . 144 . 145 . 147 . 148 . 148 . 150 . 151 . 152

` TABLE DES MATIERES 4.3 NAPT sur un routeur CISCO . . Filtrage IP . . . . . . . . . . . . . . . . . 5.1 Filtrage IP sur un routeur CISCO 5.2 Le cas dipfw de FreeBSD . . . . Exemple complet . . . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 154 154 154 157 160

ix

6 7

C
IX 1

Protocoles applicatifs
Serveur de noms - DNS G en eralit es sur le serveur de noms . . . . . . . . . 1.1 Bref historique . . . . . . . . . . . . . . . 1.2 Syst` eme hi erarchis e de nommage . . . . . 1.2.1 Domaine & zone . . . . . . . . . 1.2.2 Hi erarchie des domaines . . . . . Fonctionnement du DNS . . . . . . . . . . . . . . 2.1 Convention de nommage . . . . . . . . . . 2.1.1 Completion . . . . . . . . . . 2.2 Le Resolver . . . . . . . . . . . . . . . 2.3 Strat egie de fonctionnement . . . . . . . . 2.3.1 Interrogation locale . . . . . . . . 2.3.2 Interrogation distante . . . . . . 2.3.3 Interrogation par procuration 2.4 Hi erarchie de serveurs . . . . . . . . . . . 2.5 Conversion dadresses IP en noms . . . . . 2.6 Conclusion . . . . . . . . . . . . . . . . . . Mise ` a jour dynamique . . . . . . . . . . . . . . . S ecurisation des echanges . . . . . . . . . . . . . . 4.1 TSIG/TKEY pour s ecuriser les transferts . 4.1.1 TSIG . . . . . . . . . . . . . . . 4.1.2 TKEY . . . . . . . . . . . . . . . 4.2 DNSSEC pour s ecuriser les interrogations Attaque DNS par amplication . . . . . . . . . . Format des Resource Record . . . . . . . . . . 6.1 RR de type SOA . . . . . . . . . . . . . . . 6.2 RR de type NS . . . . . . . . . . . . . . . 6.3 RR de type A . . . . . . . . . . . . . . . . 6.4 RR de type PTR . . . . . . . . . . . . . . . 6.5 RR de type MX . . . . . . . . . . . . . . . 6.6 RR de type CNAME . . . . . . . . . . . . . 6.7 Autres RR. . . . . . . . . . . . . . . . . . . BIND de lISC . . . . . . . . . . . . . . . . . . . . 7.1 Architecture du daemon named . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

163
165 . 165 . 165 . 166 . 167 . 168 . 169 . 169 . 170 . 170 . 172 . 172 . 173 . 174 . 175 . 175 . 177 . 177 . 178 . 178 . 179 . 179 . 179 . 180 . 182 . 183 . 183 . 184 . 184 . 184 . 185 . 185 . 186 . 186 . 187

3 4

5 6

7 8

x X 1

` TABLE DES MATIERES Courrier electronique G en eralit es sur le courrier electronique . . . . . . . . . . 1.1 M etaphore du courrier postal - Lenveloppe . . . 1.2 Adresse electronique . . . . . . . . . . . . . . . . Format dun E-mail - RFC 822 . . . . . . . . . . . . 2.1 Quelques champs couramment rencontr es dans les t etes . . . . . . . . . . . . . . . . . . . . . . . . . Protocole SMTP - RFC 821 . . . . . . . . . . . . . . . . 3.1 Protocole SMTP . . . . . . . . . . . . . . . . . . . 3.2 Principales commandes de SMTP . . . . . . . . . 3.2.1 Commande HELO . . . . . . . . . . . . 3.2.2 Commande MAIL . . . . . . . . . . . . 3.2.3 Commande RCPT . . . . . . . . . . . . 3.2.4 Commande DATA . . . . . . . . . . . . 3.2.5 Commande QUIT . . . . . . . . . . . . 3.3 Propagation du courrier electronique . . . . . . . 3.4 Courriers ind esirables - Le spam . . . . . . . . . . 3.4.1 Caract eriser le spam . . . . . . . . . . . 3.4.2 Eviter le spam . . . . . . . . . . . . . . Exemple de MTA - Sendmail et son environnement . 4.1 Relations avec le DNS . . . . . . . . . . . . . . . 4.2 Relations avec le syst` eme dexploitation . . . . . 4.3 Le cas de POP . . . . . . . . . . . . . . . . . . . 4.4 Le cas de IMAP . . . . . . . . . . . . . . . . . . . Conguration du Sendmail . . . . . . . . . . . . . . . . . 5.1 Conguration ` a laide de M4 . . . . . . . . . . . . 5.2 Conguration manuelle . . . . . . . . . . . . . . . 5.2.1 R` egles de r e ecriture . . . . . . . . . . . 5.2.2 Exemple de sortie de debug . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . 189 . 189 . 190 . 190 . 191 . . . . . . . . . . . . . . . . . . . . . . . . 192 195 195 197 197 198 198 198 198 199 201 201 202 205 205 206 210 211 212 212 214 214 217 218

6 XI

. . . . . . . . en. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Instrumentalisation de r eseaux avec SNMP 1 N ecessit e dun outil . . . . . . . . . . . . . . . . . . . . . 1.1 Probl ematique de lISO . . . . . . . . . . . . . . . 1.2 Syst` eme de gestion de r eseau . . . . . . . . . . . 1.3 SNMP Simple Network Management Protocol 1.4 Historique du protocole SNMP . . . . . . . . . . 1.5 Vocabulaire et architecture . . . . . . . . . . . . . 1.6 Di erentes versions . . . . . . . . . . . . . . . . . 1.6.1 Trois composantes pour SNMP . . . . . 1.6.2 Conclusion . . . . . . . . . . . . . . . . 2 SMI Structure of Management Information . . . . . . 3 MIB Management Information Base . . . . . . . . . . 3.1 OID Objet Identier . . . . . . . . . . . . . . 3.2 Types de donn ees el ementaires . . . . . . . . . . .

221 . 221 . 221 . 222 . 223 . 224 . 224 . 226 . 226 . 227 . 228 . 228 . 230 . 231

` TABLE DES MATIERES 4 5 La MIB-2 . . . . . . . . . . . . Protocole SNMP . . . . . . . . 5.1 Communaut e . . . . . . 5.2 PDUs . . . . . . . . . . 5.3 SNMPv3 . . . . . . . . . Loutil NET-SNMP . . . . . . . 6.1 snmptranslate . . . . . 6.2 snmpget . . . . . . . . 6.3 snmpgetnext . . . . . 6.4 snmpwalk . . . . . . . 6.5 snmptable . . . . . . . 6.6 snmpset . . . . . . . . 6.7 Approche graphique . . Glossaire des acronymes SNMP Liens & Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 234 235 235 237 238 238 242 242 242 243 243 244 247 248

xi

7 8

Sockets BSD et architecture de serveurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

249
251 . 251 . 252 . 253 . 253 . 255 . 256 . 256 . 256 . 256 . 257 . 258 . 259 . 259 . 259 . 260 . 260 . 260 . 261 . 262 . 262 . 262 . 263 . 263 . 264 . 265

XII G en eralit es sur les sockets de Berkeley 1 G en eralit es . . . . . . . . . . . . . . . . . . . . . . 2 Pr esentation des sockets . . . . . . . . . . . . . . . 3 Etude des primitives . . . . . . . . . . . . . . . . . 3.1 Cr eation dune socket . . . . . . . . . . . . . 3.1.1 Valeur retourn ee par socket . . . . 3.2 Sp ecication dune adresse . . . . . . . . . . 3.2.1 Sp ecication dun num ero de port . 3.2.2 Sp ecication dune adresse IP . . . 3.2.3 La primitive bind . . . . . . . . . 3.2.4 Les structures dadresses . . . . . . 3.2.5 Valeur retourn ee par bind . . . . . 3.3 Connexion ` a une adresse distante . . . . . . 3.3.1 Mode connect e . . . . . . . . . . . 3.3.2 Mode datagramme . . . . . . . . . 3.3.3 Valeur retourn ee par connect : . . 3.4 Envoyer des donn ees . . . . . . . . . . . . . 3.4.1 Envoi en mode connect e . . . . . . 3.4.2 Envoi en mode datagramme . . . . 3.5 Recevoir des donn ees . . . . . . . . . . . . . 3.5.1 Reception en mode connect e. . . . 3.5.2 Recevoir en mode datagramme . . 3.6 Sp ecier une le dattente . . . . . . . . . . 3.7 Accepter une connexion . . . . . . . . . . . 3.8 Terminer une connexion . . . . . . . . . . . 4 Sch ema g en eral dune session clientserveur . . . .

xii 5 Exemples de code client . . . 5.1 Client TCP DTCPcli . 5.2 Client UDP DUDPcli . Conclusion et Bibliographie . . . . . . .

` TABLE DES MATIERES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 267 271 273

XIII Compl ements sur les sockets Berkeley 275 1 R eservation des ports . . . . . . . . . . . . . . . . . . . . . . . 275 1.1 R eservation de port Ancienne m ethode . . . . . . . 276 1.2 R eservation de port Nouvelle m ethode . . . . . . . . 276 2 Ordre des octets sur le r eseau . . . . . . . . . . . . . . . . . . 277 3 Op erations sur les octets . . . . . . . . . . . . . . . . . . . . . 278 4 Conversion dadresses . . . . . . . . . . . . . . . . . . . . . . . 279 4.1 Conversion dadresse - IPv4 seul . . . . . . . . . . . . . 279 4.2 Conversion dadresse - Compatible IPv4 et IPv6 . . . . 279 5 Conversion h ote adresse IPv4 . . . . . . . . . . . . . . . . . 280 5.1 Une adresse IP ` a partir dun nom dh ote . . . . . . . . 280 5.2 Un nom dh ote ` a partir dune adresse IP . . . . . . . . 282 6 Conversion N de port service . . . . . . . . . . . . . . . . . 282 6.1 Le num ero ` a partir du nom . . . . . . . . . . . . . . . 282 6.2 Le nom ` a partir du num ero . . . . . . . . . . . . . . . 284 7 Getaddrinfo, pour IPv4 et IPv6 . . . . . . . . . . . . . . . . 285 7.1 La fonction getaddrinfo . . . . . . . . . . . . . . . . . 285 7.1.1 Prototype de getaddrinfo . . . . . . . . . . 285 7.1.2 Description des arguments . . . . . . . . . . . 286 7.1.3 La structure addrinfo . . . . . . . . . . . . . 286 7.1.4 En r esum e . . . . . . . . . . . . . . . . . . . . 287 7.1.5 Exemple dusage ` a la place de gethostbyname 288 7.1.6 Exemple dusage ` a la place de getservbyname 290 7.1.7 En r esum e . . . . . . . . . . . . . . . . . . . . 290 8 Conversion nom de protocole N de protocole . . . . . . . . 291 9 Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 10 Exemples de mise en application . . . . . . . . . . . . . . . . . 293 10.1 Ancienne m ethode (usage de gethostbyname) . . . . . 293 10.2 Nouvelle m ethode (usage de getaddrinfo) . . . . . . . 298 11 Conclusion et bibliographie . . . . . . . . . . . . . . . . . . . . 300 XIV 1 ements de serveurs El Type de serveurs . . . . . . . . . . . . 1.1 Serveurs it eratif et concourant . 1.2 Le choix dun protocole . . . . . 1.2.1 Mode connect e . . . . 1.2.2 Mode datagramme . . 1.3 Quatre mod` eles de serveurs . . Technologie el ementaire . . . . . . . . 2.1 Gestion des t aches esclaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 301 301 302 302 303 303 307 307

` TABLE DES MATIERES 2.2 fork, vfork et rfork . . . . . . . . . . . . 2.3 Processus l egers, les threads . . . . . 2.4 Programmation asynchrone . . . . . . . 2.5 La primitive select . . . . . . . . . . . 2.6 La primitive poll . . . . . . . . . . . . . Fonctionnement des daemons . . . . . . . . . . 3.1 Programmation dun daemon . . . . . . 3.2 Daemon syslogd . . . . . . . . . . . . . 3.3 Fichier syslog.conf . . . . . . . . . . . 3.4 Fonctions syslog . . . . . . . . . . . . . Exemple de daemon inetd . . . . . . . . . . 4.1 Pr esentation de inetd . . . . . . . . . . Exemple de code serveur . . . . . . . . . . . . . 5.1 Guide de lecture du source serv2prot.c Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 309 311 312 314 315 315 316 318 318 320 320 322 322 325

xiii

4 5 6

XV Anatomie dun serveur Web 1 Le protocole HTTP . . . . . . . . . . . . . . . 1.1 Exemple d echange avec http . . . . . 1.2 Structure dun echange . . . . . . . . . 2 URIs et URLs . . . . . . . . . . . . . . . . . . 2.1 Scheme http . . . . . . . . . . . . . . . 3 Architecture interne du serveur Apache . . . . 3.1 Environnement dutilisation . . . . . . 3.2 Architecture interne . . . . . . . . . . 3.2.1 Gestion des processus . . . . 3.2.2 Prise en main des requ etes . . 3.2.3 Deux types de CGIs . . . . . 4 Principe de fonctionnement des CGIs . . . . . 4.1 CGI M ethode GET, sans argument 4.2 CGI M ethode GET, avec arguments 4.3 CGI M ethode POST . . . . . . . . 4.4 Ecriture dune CGI en Perl . . . . . . 5 Conclusion Bibliographie . . . . . . . . . . .

327 . 327 . 328 . 328 . 332 . 332 . 334 . 334 . 336 . 337 . 342 . 343 . 347 . 347 . 348 . 349 . 350 . 351

Index g en eral & Annexes

353
367

A Programme serv2prot.c

xiv

` TABLE DES MATIERES

Table des gures

I.01 I.02 I.03 I.04 I.05 I.06 I.07 I.08 I.09 I.10 I.11 I.12 I.13 I.14 II.01 II.02 II.03 III.01 III.02 III.03 III.04 III.05 III.06 IV.01 IV.02 IV.03 IV.04 IV.05 IV.06 IV.07 IV.08 IV.09 IV.10 IV.11 Mod` ele en 7 couches de lOSI . . . . . . . . . Exemple de LANs . . . . . . . . . . . . . . . . trame Ethernet . . . . . . . . . . . . . . . . . Di erences Ethernet 802.2/802.3 . . . . . . . . Interconnexion - Technologie el ementaire . . . Prise vampire . . . . . . . . . . . . . . . . . . Technologie de liaison . . . . . . . . . . . . . . Plusieurs r ep eteurs mais toujours le m eme lan Concentrateur . . . . . . . . . . . . . . . . . . Dialogue sans pont . . . . . . . . . . . . . . . Dialogue avec pont . . . . . . . . . . . . . . . Commutateur . . . . . . . . . . . . . . . . . . Fonction routage . . . . . . . . . . . . . . . . Traduction de protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 10 13 14 15 17 18 18 19 19 21 22 22

Comparaison ISO-ARPA . . . . . . . . . . . . . . . . . . . . 28 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . 29 Encapsulation dIP . . . . . . . . . . . . . . . . . . . . . . . 31 D ecomposition en classes . . . . . Sous-r eseaux . . . . . . . . . . . . Puissances de 2 . . . . . . . . . . . Adresses de multicast . . . . . . . Adresse physique de multicast . . . Usage combin e des adresses logique Structure du datagramme IP . . . Big endian vs Little endian Fragmentation IP . . . . . . . . . . Fragment ` a transmettre . . . . . . R esum e de la fragmentation . . . . Question ARP . . . . . . . . . . . R eponse ARP . . . . . . . . . . . . Datagramme ARP . . . . . . . . . Message ICMP . . . . . . . . . . . Format dun message ICMP . . . . Echo request vs Echo reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . et physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 38 38 42 43 44 47 48 52 53 54 55 56 57 60 60 61

xvi IV.12 IV.13 IV.14 IV.15 IV.16 IV.17 IV.18 IV.21 IV.22 IV.23 V.01 V.02 V.03 V.04 VI.01 VI.02 VI.03 VI.04 VI.05 VI.06 VI.07 VI.08 VI.09 VII.01 VII.02 VII.03 VII.04 VII.05 VII.06 VII.07 VII.08 VII.09 VII.10 VII.11 VII.12 VII.13 VIII.01 VIII.02 VIII.03 VIII.04 VIII.05 VIII.06

TABLE DES FIGURES En-t ete IGMP . . . . . . . . . . . . . . Fonctionnement IGMP . . . . . . . . . . Table de routage . . . . . . . . . . . . . Situation r eseau lors du netstat . . . . Exemple de nuage avec routage statique Exemple pour routage dynamique . . . . Topologie pour routage dynamique . . . ICMP redirect . . . . . . . . . . . . Interface de loopback . . . . . . . . Illustration du routage direct et indirect Num ero de port comme num ero UDP encapsul e dans IP . . . . Structure de len-t ete UDP . . Cas du checksum non nul . . . TCP encapsul e dans IP . . . . Structure de len-t ete TCP . . Etablissement dune connexion Cl oture dune connexion . . . . Emission dun rst . . . . . . . . M ecanisme de lacquittement . Principe de la fen etre glissante D etail de la fen etre glissante . . Exemple de fen etre glissante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 64 67 69 70 71 72 74 75 76 82 83 84 84 89 91 94 95 96 97 98 99 104

de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Un AS, le monde ext erieur, le monde int erieur ! . . . . . . . 111 La route vers H depuis R a une m etrique de 2 et passe par R1113 Fonctionnement el ementaire . . . . . . . . . . . . . . . . . . 115 L horizon partag e ne r esout pas tout ! . . . . . . . . . . 116 RIP est transport e par UDP/IP . . . . . . . . . . . . . . . . 118 Format dun message RIPv2 . . . . . . . . . . . . . . . . . . 118 Relation dordre entre deux LSP . . . . . . . . . . . . . . . 125 Propagation des LSP par inondation ou ooding . . . . 126 Organisation en zones Hi erarchie de routeurs . . . . . . . 128 Propagation dun LSP, sans et avec un DR . . . . . . . . . . 129 Organisation globale de len-t ete du protocole OSPF . . . . 132 En-t ete standard de 24 octets . . . . . . . . . . . . . . . . . 133 En-t ete du paquet HELLO . . . . . . . . . . . . . . . . . . 134 Serveur HTTP virtuel Tunnel IP - Principe . Tunnel IP - cas concr et En-t etes dIPsec . . . . Association 1 . . . . . Association 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 139 141 145 145 146

TABLE DES FIGURES VIII.07 Association 3 . . . . . . . . . . . . . . . . . . . . . . VIII.08 Association 4 . . . . . . . . . . . . . . . . . . . . . . VIII.04 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . VIII.10 R translate dynamiquement des couples (adresse num ero de port) . . . . . . . . . . . . . . . . . . . . . . . VIII.11 Machine NAPT en routeur . . . . . . . . . . . . . . . VIII.12 Interactions entre natd et le noyau de FreeBSD . . . VIII.13 Static Nat . . . . . . . . . . . . . . . . . . . . . . . . VIII.14 Conguration multiservices . . . . . . . . . . . . . . . VIII.15 Conguration simple de ltrage . . . . . . . . . . . . VIII.16 Translation dadresse et ltrage IP . . . . . . . . . . . IX.01 IX.02 IX.03 IX.03 IX.05 IX.06 IX.07 IX.08 X.01 X.02 X.03 X.04 X.05 X.06 X.07 X.08 Organisation hi erarchique des domaines Le resolver dans son environnement Subdivision hi erarchique des domaines . Interrogation locale . . . . . . . . . . . . Interrogation distante . . . . . . . . . . R eponse ` a une requ ete non formul ee . . Attaque DNS par amplication . . . . . BIND de lISC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 . 146 . 148 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 150 151 152 153 155 157 169 171 172 172 174 180 181 186 192 199 200 205 206 210 213 215 224 230 234 235 244

xvii

Format dun e-mail . . . . . . . . . . . . . . . . . . . MUA - MSA - MTA - LDA - OS . . . . . . . . . . . Trajet dun mail . . . . . . . . . . . . . . . . . . . . MX primaire et secondaires . . . . . . . . . . . . . . Relation entre Sendmail et le syst` eme dexploitation Le cas de POP . . . . . . . . . . . . . . . . . . . . . Concentration du mail sur un mailhub . . . . . . R` egles de r e ecriture . . . . . . . . . . . . . . . . . .

XI.01 Agent et Manager dans une relation de type client-serveur XI.02 La racine de larbre des OIDs . . . . . . . . . . . . . . . . XI.03 Des agents et un Manager . . . . . . . . . . . . . . . . . . XI.04 Format des messages SNMP . . . . . . . . . . . . . . . . . XI.05 Exemple dinterrogation dun agent avec loutil mbrowse . XI.06 Synth` ese graphique des compteurs ifInOctets et ifOutOctets sur 24h . . . . . . . . . . . . . . . . . . . . . . XI.07 Exemple d ecran de surveillance avec tkined . . . . . . . XII.01 XII.02 XII.03 XII.04 XII.05 Les sockets, une famille de primitives . . . . . Relation pile IP, num ero de port et process ID Structures dadresses . . . . . . . . . . . . . . Relation clientserveur en mode connect e . . Relation clientserveur en mode non connect e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. 245 . 247 . . . . . 251 252 258 265 266

XIII.01 Ordre des octets sur le r eseau . . . . . . . . . . . . . . . . . 277

xviii XIV.01 XIV.02 XIV.03 XIV.04 XV.01 XV.02 XV.03 XV.04 XV.05 Quatre types de serveurs . . . Ex ecution avec et sans threads Syslogd . . . . . . . . . . . . . Inetd . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 309 317 321 329 334 340 342 343

Structure dun message HTTP . . . Environnement syst` eme . . . . . . . Algorithme de gestion des processus Usage de la score board . . . . . . Deux type de CGIs . . . . . . . . . .

Liste des tableaux

I.01 Quelques valeurs du champs type de len-t ete IP . . . . . . . . 11 I.02 Exemples de Organizationally Unique Identier (OUI) . . 12 III.01 III.02 III.03 III.04 III.05 III.06 III.07 Adresses IP des r eseaux priv es . . . . . . . . Adresses IP avec une signication particuli` ere Partitionnement dune classe C en quatre sous D etail des quatre sous r eseaux dun /26 . . . Adresses IP priv ees, notation du CIDR . . . . Agr egations r egionales des blocs IP . . . . . . Quelques adresses multicasts du LAN . . . . . . . . . . . . . . r eseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 37 38 39 40 41 42

IV.01 Bits du champ TOS . . . . . . . . . . . . . . . . . . . . . . 49 IV.02 En-t ete des fragments IP vs en-t ete datagramme original . . 54 IV.03 Quelques drapeaux de routage de la commande netstat -r 69 V.01 Extrait succinct du chier /etc/services . . . . . . . . . . 85

VI.01 Drapeaux du champ CODE (en-t ete TCP) . . . . . . . . . . 92 VII.01 Quelques valeurs d etats de liens pour OSPF . . . . . . . . . 127 X.01 Quelques champs couramment rencontr es dans un t ete de mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

XI.01 Extrait de la MIB II concernant lOID tcpConnTable . . . . 229 XI.02 Extrait du d ebut de la MIB-2 . . . . . . . . . . . . . . . . . 233 XI.03 Extrait de la MIB-2 concernant le d ebut du goupe system 241 XII.01 Exemples de familles de protocoles pour une socket . . . . . 254 XII.02 Exemples de type de sockets . . . . . . . . . . . . . . . . . . 254 XII.03 Exemples de protocoles associ es ` a une socket . . . . . . . . 255 XIII.01 Exemples de codes de retours des primitives syst` emes pour le r eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 XIV.01 Typologie des applicatifs qui utilisent syslog . . . . . . . . 319 XIV.02 Criticit e des messages de log . . . . . . . . . . . . . . . . . 319 XV.01 Codes de retour du protocole HTTP . . . . . . . . . . . . . 330

xx

LISTE DES TABLEAUX XV.02 Conguration du mod` ele pre-forked dApache . . . . . . 335

Pr eface
Attention ! Ce document nest quun support de cours, cest ` a dire quil ne remplace pas les documents cit es dans la bibliographie qui termine chacun des chapitres qui le composent.
Evidement imparfaites, pleines derreurs involontaires, et surtout incompl` etes, ces pages r eclament avant tout votre indulgence de lecteur bienveillant : Rien nest constant, tout change comme le disait d ej` a Lao Tseu, 400 ans avant JC. Que dirait-il alors aujourdhui, concernant les r eseaux ! ! Ces cours saccompagnent de travaux pratiques dont le texte ne gure pas ici, ils sont initialement con cus pour les etudiants du Mast` ere de Syst` emes 2 dInformations Ouverts (SIO) de lEcole Centrale Paris, an de les aider ` a la compr ehension th eorique et pratique des r eseaux TCP/IP.

Ce support est en acc` es libre, cest ` a dire mis ` a la disposition de tous pour un usage personnel ou collectif, sans but lucratif. Sa revente, sil y a lieu, ne peut etre envisag ee que pour couvrir les frais induits par sa reproduction. Enn, sa redistribution sous quelque forme que ce soit, ne peut se concevoir sans cette pr eface.
Ne pas h esiter ` a me contacter en cas de doute sur lusage : Fran cois Laissus <fr.laissus@laissus.fr> En aucun cas lauteur ne pourra etre tenu responsable des cons equences de lusage de ce document, qui est fourni tel quel et sans garantie daucune sorte. Lusage des informations contenues est donc plac e sous la responsabilit e pleine et enti` ere du lecteur. Enn, si vous pensez que la lecture de ce support vous a apport e quelque chose, que vous avez une remarque ` a me faire, ou tout simplement me complimenter ( ca fait toujours plaisir quoi que lon puisse en dire ! :) sentez-vous libres de menvoyer un courrier electronique, je suis toujours ravi dapprendre que ce travail a pu servir ! Enn merci de votre int er et pour ce document, jesp` ere que vous y trouverez ce que vous cherchez !
2

http://www.mastere-sio.ecp.fr/

xxii

Pr eface

Premi` ere partie Introduction ` a la pile ARPA

Chapitre I R eseaux locaux

1 Pr eambule

Ce cours nest pas un cours g en eral sur les r eseaux mais une pr esentation minimale de cette technologie pour pouvoir aborder le cours de concepts et programmation TCP/IP sous UNIX. TCP/IP est le protocole le plus r epandu dans le monde gr ace ` a lInternet. En 1980 il ne comptait que quelques dizaines dh otes, en juin 1996 ce nombre etait de 12 millions de machines, r eparties en pr` es de 500 000 r eseaux (Par comparaison, en f evrier 1995, les m emes chires etaient 4 850 000 machines pour plus de 71 000 r eseaux locaux). En janvier 2003, le nombre de machines1 directement accessibles sur le r eseau etait de 180 000 000 selon lISC2 . Depuis on ne compte plus tant la croissance est importante. . .Pour la france lAFNIC propose egalement 3 quelques statisques . . .Il nexiste pas de botin g en eral du r eseau, par contre Bill Cheswick des Bell labs la cartographi e, et le r esultat est fascinant :
http://www.cheswick.com/ches/map/gallery/index.html

2
2.1

G en eralit es - LANs
G en eralit es

Un r eseau informatique met en relation des ordinateurs, comme un r eseau t el ephonique met en relation des personnes. Des ordinateurs sont dits en r eseaux d` es lors quils partagent une technologie qui leur permet de communiquer ensemble. Le plus souvent cette technologie se mat erialise physiquement par une liaison avec un c able conducteur. Sur ce type de support, un signal electrique
1 2

Source http://www.isc.org/ds/ Internet Software consortium 3 http://www.nic.fr/statistiques/

R eseaux locaux v ehicule les messages informatiques. Il existe dautres types de supports en pleine expansion comme les liaisons par ondes hertziennes, rayon laser, infrarouge. . . Sans connaissance pr ealable concernant les r eseaux informatiques on peut imaginer quantit e dinterrogations ` a partir de cette hypoth` ese de raccordement : Comment reconnaitre un correspondant ? Comment dialoguer avec ? Comment diuser linformation ` a plusieurs correspondants ? Comment eviter la cacophonie ? Il y a til une hi erarchie des machines ? Il y a til un chef dorchestre ? ... Toutes ces questions (et bien dautres) trouveront une r eponse dans ce cycle de cours. Ces r eponses sont g en eralement formul ees dans un protocole , une sorte de mode demploi des r eseaux. Il y a des centaines de protocoles di erents sur lInternet, certains sont tr` es populaires, dautres absolument pas.

2.2

Mod` ele de communication OSI

Le concept de base de tout ce cours est celui de la commutation de a lapproche par paquets , une vieille id ee de linformatique4 contrairement ` circuits virtuels plus utilis ee en t el ephonie. Les donn ees ` a transmettre dune machine ` a une autre sont fragment ees ` a l emission en petit blocs de quelques centaines doctets munis de ladresse du destinataire, envoy ees sur le r eseau et r e-assembl ees ` a la r eception pour reproduire les donn ees dorigine. Ce concept facilite le partage des possibilit es physiques du r eseaux (bande passante) et est parfaitement adapt e pour une impl ementation sur machines s equentielles travaillant en temps partag e (plusieurs communications peuvent alors avoir lieu simultan ement et sur une m eme machine). Partant de ce concept, un mod` ele darchitecture pour les protocoles de communication a et e d evelopp e par lISO (International Standards Organisation) entre 1977 et 1984. Ce mod` ele sert souvent de r ef erence pour d ecrire la structure et le fonctionnement des protocoles de communication, mais nest pas une contrainte de sp ecication. Ce mod` ele se nomme OSI comme Open Systems Interconnection Reference Model . Les constituants de ce mod` ele sont si largement employ es quil est dicile de parler de r eseaux sans y faire r ef erence. ` chaque couche est asLe mod` ele OSI est constitu e de sept couches. A soci ee une fonction bien pr ecise, linformation traverse ces couches, chacune y apporte sa particularit e. Cette forme dorganisation nest pas d ue au hasard, cest celle sur la4

Con cu par lAm ericain Paul Baran et publi e en 1964

G en eralit es - LANs quelle les informaticiens ont beaucoup travaill e dans les ann ees soixantes pour d enir les caract eristiques des syst` emes dexploitation. Une couche ne d enit pas un protocole, elle d elimite un service qui peut etre r ealis e par plusieurs protocoles de di erentes origines. Ainsi chaque couche peut contenir tous les protocoles que lon veut, pourvu que ceux-ci fournissent le service demand e` a ce niveau du mod` ele. Un des int er ets majeurs du mod` ele en couches est de s eparer la notion de communication, des probl` emes li es ` a la technologie employ ee pour v ehiculer les donn ees. Pour m emoire (gure I.01) : 7 La couche application (Application layer) est constitu ee des programmes dapplication ou services, qui se servent du r eseau. Ils ne sont pas forc ement accessibles ` a lutilisateur car ils peuvent etre r eserv es ` a un usage dadministration. 6 La couche de pr esentation (Pr esentation layer) met en forme les donn ees suivant les standards locaux ou particuliers ` a lapplication. Comme, par exemple passer dune repr esentation big endian ou ` a une repr esentation little endian ou encore plus complexe comme celle d ecrite pas les XdR (eXternal Data Representation) et qui autorise la transmission de types abstraits de donn ees (structures complexes, arbres, listes chain ees, la liste nest pas limitative. . .). De nos jour cest de plus en plus le XML5 qui occupe cet espace nalement assez peu norm e. 5 La couche de session (Session layer) eectue laiguillage entre les divers services (7) qui communiquent simultan ement ` a travers le m eme ordinateur connect e et le m eme r eseau. Deux utilisateurs dune m eme machine peuvent utiliser la m eme application sans risque dinter-actions parasites. 4 La couche de transport (Transport layer) garantie que le destinataire obtient exactement linformation qui lui a et e envoy ee. Cette couche met par exemple en uvre des r` egles de renvoi de linformation en cas derreur de r eception. 3 La couche r eseau (Network layer) isole les couches hautes du mod` ele qui ne soccupent que de lutilisation du r eseau, des couches basses qui ne soccupent que de la transmission de linformation. 2 La couche de donn ee (Data link layer) eectue le travail de transmission des donn ees dune machine ` a une autre. 1 La couche Physique (Physical layer) d enit les caract eristiques du mat eriel n ecessaire pour mettre en euvre le signal de transmission, comme des tensions, des fr equences, la description dune prise. . .
5

http://www.w3.org/XML/

6 Mod` ele en 7 couches de lOSI

R eseaux locaux

Protocole

Application Prsentation Session

S Protocole

Application Prsentation Session

S

Protocole

Transport
T S

Protocole

Transport
S T

Rseau
R T S

Protocole

Rseau
S T R

Liaison
L R T S

Protocole

Liaison
S T R L

Physique
L R T S

Protocole

Physique
S T R L

gure I.01 Mod` ele en 7 couches de lOSI

Du niveau 7 de lapplication, au niveau 4 du transport, linformation circule dans ce que lon appelle un message , au niveau 3 elle se nomme packet , puis frame au niveau 2 et signal au niveau 1. Chaque couche ne voit et ne sait communiquer quavec la couche qui la pr ec` ede et celle qui la suit, avec le cas particulier des couches 1 et 7. Lint er et de travailler en couches est que lorsque les modalit es d echanges entre chacune dentres elles sont pr ecis ement d ecrites, on peut changer limpl ementation et les sp ecicit es de la couche elle-m eme sans que cela aecte le reste de l edice. Cest sur ce principe quest b atie la suite de protocoles d esign ee par TCP/IP Quand deux applications A et B discutent entre-elles via le r eseau, les informations circulent de la couche 7 vers la couche 2 quand lapplication A envoie de linformation sur le r eseau, et de la couche 2 vers la couche 7 pour que lapplication B re coive linformation de A. Le principe de base de cette discussion repose sur le fait que chaque couche du mod` ele de la machine A est en relation uniquement avec son homologue du m eme niveau de la machine B. Quand linformation descend de la couche 7 vers la couche 1, chaque couche en-capsule les donn ees re cues avant de les transmettre. Ainsi le volume dinformations sest accr u de quelques centaines doctets arriv e` a la couche 1. De mani` ere sym etrique, quand linformation remonte de la couche physique vers la couche Application, chaque couche pr el` eve les octets qui lui sont propres, ainsi lapplication B ne voit-elle que les octets envoy es par lapplication A, sans le d etail de lacheminement.

3 R eseaux locaux

R eseaux locaux

Le probl` eme intuitif et pratique qui se pose est de relier entre elles par un c able toutes les machines qui veulent communiquer : cest impossible dabord pour des raisons techniques, le monde est vaste, puis de politique demploi des ressources du r eseau, tel r eseau qui sert ` a lenseignement ne doit pas pas perturber le fonctionnement de tel processus industriel. La cons equence est que les r eseaux se d eveloppent dabord en local, autour dun centre dint er et commun, avant de se tourner (parfois) vers lext erieur.

3.1

Quest-ce quun LAN ?

Le terme r eseau local nest pas clairement d eni, cependant tout le monde saccorde ` a baptiser de la sorte un r eseau, d` es lors quon lui reconnait les caract eristiques suivantes : Cohabitation de plusieurs protocoles, Un m eme m edia (m eme c able par exemple) qui raccorde de multiples machines, peut etre de caract eristiques di erentes, Une bande passante elev ee, partag ee par tous les h otes La capacit e de faire du broadcasting et du multicasting , Une extension g eographique de moins en moins limit ee, Un nombre de machines raccord ees limit e, Des relations entre les machines plac ees sur un mode d egalit e, (et non par exemple sur un mode Ma tre/Esclave comme dans un r eseau dont la topologie serait en etoile), Une mise en uvre qui reste du domaine priv e, cest ` a dire qui ne d epend pas dun op erateur ociel de t el ecommunications. Notez que les notions de bande passante et nombre limit e (etc. . .) sont volontairement qualitatives. Elles evoluent rapidement avec le temps.

Machine sur le LAN

gure I.02 Exemple de LANs Exemple de types de technologies utilis ees dans les LANs : Token ring

8 IEEE 802 LANs Ethernet et Fast-Ethernet FDDI (anneau en bre optique) ATM 802.11(a,b,g,. . .) ...

R eseaux locaux

3.2

WAN - MAN

Un WAN (Wide Area Network) d esigne des ordinateurs connect es entre di erentes villes (Metropolitan Area Network) ou pays. La technologie utilis ee est traditionnellement moins performante que celle dun LAN, cest par exemple une ligne t el ephonique lou ee fonctionnant ` a 64 kbps, une liaison RNIS, ou encore une liaison transatlantique ` a 1Mbits/secondes. Les am eliorations technologiques apport ees aux LANs permettent de les etendre de plus en plus g eographiquement, celles apport ees aux WAN augmentent consid erablement les bandes passantes, ces deux tendances font que la distinction entre ces deux types de r eseaux est de moins en moins claire.

3.3

Communications inter-r eseaux

Les r eseaux sont appel es ` a communiquer entres eux et quand cela se produit on parle de communications inter-r eseaux ( internetworking ). Le r ole dune communication inter-r eseaux est de gommer les eventuelles di erences de technologie d echange pour permettre ` a deux r eseaux, ou plus, le partage de ressources communes, l echange dinformations. Un moyen de faire communiquer deux r eseaux distincts passe par lutilisation de gateway ou passerelle. Un tel dispositif est parfois appel e routeur (router), mais cest un abus de langage. Les hommes se connectent sur les ordinateurs Les ordinateurs se connectent sur un r eseau Les r eseaux sinter-connectent dans un internet

4 Couche 2 - Liaison (Data Link)

Couche 2 - Liaison (Data Link)

La couche 2 la plus populaire est surement celle que lon nomme abusivement Ethernet , du nom du standard publi e en 1982 par DEC, Intel Corp. et Xerox. Cette technique repose sur une m ethode dacc` es et de contr ole dite CSMA/CD ( Carrier Sense, Multiple Access with Collision Detection ). Elle est devenue tellement populaire quon parle dun c able Ethernet, dune adresse Ethernet, dune liaison Ethernet. . . Plus tard lIEEE ( Institute of Electrical and Electronics Engineers ) 6 sous linstance de son commit e 802, publia un ensemble de standards l eg` erement di erents, les plus connus concernant la couche 2 sont 802.2 (Contr ole logique de la liaison LLC7 ) et 802.3 (CSMA/CD) Dans le monde TCP/IP, lencapsulation des datagrammes IP est d ecrite dans la RFC 894 [Hornig 1984] pour les r eseaux Ethernet et dans la RFC 1042 [Postel et Reynolds 1988] pour les r eseaux 802. En r` egle g en erale, toute machine utilisant TCP/IP sur ce type de r eseaux doit : 1. etre capable denvoyer et de recevoir un paquet conforme ` a la RFC 894, 2. etre capable de recevoir des paquets conformes aux deux standards, 3. Par contre il est seulement souhaitable que cette machine soit capable denvoyer des paquets conformes ` a la RFC 1042. Par d efaut le standard est donc celui de la RFC 894, si une machine peut faire les deux, cela doit etre congurable. De nos jours la couche 802.11 (r eseau sans l - wi) voit sa popularit e cro tre tr` es vite. Elle est bas ee sur une m ethode dacc` es assez proche, le CSMA/CA ( Carrier Sense, Multiple Access with Collision Avoidance ). En eet les collisions ne peuvent pas toujours etre d etect ees car les h otes ne sont pas n ecessairement ` a port ee radio directe. Les echanges, quand ils ne sont pas de type point ` a point , passent par un interm ediaire nomm e en g en eral point dacc` es ce qui complique le protocole, et donc la trame, par rapport au CSMA/CD.

4.1
4.1.1

Caract eristiques dEthernet

Quelques principes fondamentaux

1. Le support de transmission est un Segment = bus = c able coaxial. Il ny a pas de topologie particuli` ere (boucle, etoile, etc. . .). 2. Un equipement est raccord e sur un c able par un transceiver : Transmitter + receiver = transceiver (coupleur ou transducteur). On parle alors dune station Ethernet, celle-ci a une adresse unique.
6 7

http://www.ieee.org/ Logical Link Control

10

R eseaux locaux 3. Sur le cable circulent des trames, autant de paquets de bits. Il ny a pas de multiplexage en fr equence, pas de full duplex 8 . Une trame emise par une station est re cue par tous les coupleurs du r eseau Ethernet, elle contient ladresse de l emetteur et celle du destinataire. 4. Un coupleur doit etre ` a l ecoute des trames qui circulent sur le c able. Un coupleur connait sa propre adresse, ainsi si une trame lui est destin ee il la prend, sinon il nen fait rien. 5. Une station qui veut emettre attend que toutes les autres stations se taisent. Autrement dit, si le c able est libre elle envoie sa trame, sinon elle attend. Si deux stations emettent en m eme temps il y a collision. Les deux trames sont alors inexploitables, les deux (ou plus) stations d etectent ce fait et re emettent ult erieurement leur paquet en attente. 6. Un r eseau Ethernet est donc un r eseau ` a caract` ere probabiliste car il ny a pas de chef dorchestre pour synchroniser les emissions. Cette absence conduit ` a dire que cest un r eseau egalitaire, une sorte de r eunion sans animateur entre personnes polies En conclusion, la technologie Ethernet est simple, sa mise en uvre se fait ` a faible co ut. Points ` a retenir : Simplicit e et faible co ut Peu de fonctions optionnelles Pas de priorit e Pas de contr ole sur lattitude des voisins D ebit dau moins 10Mb/s (jusqu` a 1000Mb/s th eorique). Performances peu d ependantes de la charge, sauf en cas de collisions trop importantes. 4.1.2 Format dune Frame Ethernet
Encapsulation Ethernet (RFC 894) Donnes encapsules

46 1500

Type des donnes Adresse de la source Adresse de la destination Prambule de synchronisation

Checksum

gure I.03 trame Ethernet

les cartes Ethernet modernes utilisent 4 ls au lieu de deux et orent ansi des possibilit es de full duplex que navaient pas leurs anc etres des ann ees 80
8

Couche 2 - Liaison (Data Link) Quelques consid erations en vrac : D u au d ebit global de 10Mbits/seconde, le d ebit est de 10 bits par micro-seconde (en gros un facteur 1000 avec un cpu). Une trame a une longueur minimale (72) et une longueur maximale (1526). Si les donn ees ne sont pas assez longues (46 octets) des caract` eres de remplissage sont ajout es ( padding ). Les octets circulent du premier octet du pr eambule au dernier octet du CRC. A lint erieur de chaque octet le premier bit envoy e est celui de poids faible, etc.. Le pr eambule et le SFD ( Start Frame Delimiter ) servent ` a la synchronisation. Adresses dorigine et de destination sont celles respectivement de la machine emettrice et de la machine destinatrice. Remarque importante : il faut conna tre ladresse de son correspondant ` ce stade de lexpos pour pouvoir lui envoyer un paquet ! A e on ne sait pas encore comment faire quand on ignore cette information. Le champ type est deux octets qui d esignent le type des donn ees encapsul ees : Type Donn ees 0800 IP 0806 ARP 0835 RARP 6000 DEC 6009 DEC 8019 DOMAIN ... ... 4.1.3 Adresses IEEE 802.3 ou Ethernet

11

Pour ces deux standards, ladresse est cod ee sur 6 octets soit 48 bits. Pour un h ote sur un r eseau, cette adresse est ce que lon appelle son adresse physique ( hardware addresse ) par opposition ` a son adresse logique qui interviendra lors de lexamen de la couche 3. En fait cette adresse est divis ee en deux parties egales, les trois premiers octets d esignent le constructeur, cest le OUI ( Organizationally Unique Identier ) distribu e par lIEEE 9 les trois derniers d esignent le num ero de carte, dont la valeur est laiss ee ` a linitiative du constructeur qui poss` ede le pr exe. LIEEE assure ainsi lunicit e de lattribution des num eros de construc10 24 teurs, par tranches de 2 cartes Chaque constructeur assure lunicit e du num ero de chaque carte fahttp://standards.ieee.org/regauth/oui/index.shtml La liste ` a jour est accessible ` a cette url http://standards.ieee.org/regauth/oui/ a la n de la RFC 1700 (page 172) Ethernet vendors address components oui.txt ou `
10 9

12

R eseaux locaux briqu ee. Il y a au maximum 224 cartes par classe dadresses. Cette unicit e est primordiale car le bon fonctionnement dun LAN requiert que toutes les stations aient une adresse physique di erente. Dans le cas contraire le r eseau et les applications qui lutilisent auront un comportement impr evisible le rendant impraticable. Nous aurons loccasion de rencontrer ` a nouveau ce soucis dunicit e de ladresse physique lorsque nous examinerons les protocoles ARP et RARP (cf cours ARP/RARP pages 55 et 58) et avec CARP ( Common Address Redundancy Protocol ) lorsque nous parlerons des h otes virtuels, page 137. Exemple dadresse physique en repr esentation hexad ecimale : 08:00:09:35:d5:0b 08:00:09 est attribu e` a la rme Hewlett-Packard 35:d5:0b est ladresse de la carte Apple Computer Cisco Systems, Inc. Dell Computer Corp. Sun Microsystems Digital Equipment Corporation 3Com Corporation ...

Dautres constructeurs, captur es au hasard des r eseaux : 00:11:24 00:00:0C 00:06:5B 08:00:20 AA:00:04 00:10:5A ... 4.1.4

Unicast, multicast et broadcast

Dans la pluspart des technologies de LAN, toutes les stations peuvent ecouter toutes les trames qui leur parviennent. Beaucoup dentres elles ne leur sont pas destin ees, et sil fallait que le syst` eme dexploitation qui g` ere linterface r eseau sinterrompt ` a chaque fois pour les examiner, il ne serait pas tr` es utilisable pour les applications de lutilisateur, parceque tout le temps interrompu par ces ev enements r eseau. Pour eviter cette situation, le logiciel embarqu e dans linterface r eseau est param etr e (par le syst` eme dexploitation) pour ltrer les paquets non voulus car non n ecessaires au bon fonctionnement en r eseau. Ce param` etrage peut changer dune station ` a une autre. Il est egalement possible de ne pas ltrer, cest une propri et e utilis ee par les analyseurs de trames, comme par exemple loutil tcpdump. La carte fonctionne alors en mode dit promiscuous , qui nest donc pas son mode de fonctionnement standard. Le ltrage sappuie sur trois types dadressages : unicast Ladresse MAC est constitu ee de la combinaison de 48 bits qui la rend unique. Ce mode dadressage est typique d echanges entre deux stations uniquement. Cest lessentiel du trac sur un LAN. Le ltrage peut seectuer en ne retenant que les trames qui ont ladresse MAC de la station locale et donc ecarter les autres trames de type unicast.

Couche 2 - Liaison (Data Link) broadcast Tous les bits de ladresse MAC sont ` a 1. Toutes les stations dun r eseau sont destinatrices de tels paquets, que leur ltrage doit laisser passer, avec les inconvients cit es pr ec edemment. Ce mode dadressage ne devrait etre utilis e par les protocoles quuniquement quand il nest pas possible de faire autrement. Par exemple pour obtenir une information que seule une station inconnue sur le LAN poss` ede. Cest le cas des protocoles ARP et RARP (cf cours ARP/RARP pages 55 et 58) Utilis e abusivement, le broadcast est une g ene. multicast Il existe un pr exe particulier 01:00:5E, non d edi ee ` a un constructeur car dit de multicast , que nous examinerons dans le cas dIP page 42. Ce mode de dadressage est r eserv e le plus g en eralement ` a la d ecouverte passive (par l ecoute de messages davertissement) ou ` a la recherche (par l emission de messages de sollicitation) de voisins de LAN ayant des propri et es particuli` eres. Le ltrage des sollicitations et leurs r eponses peut etre congur e` a la carte sur chaque station, en fonction des imp eratifs et besoins de fonctionnement. Ce mode de fonctionnement est assez econome des ressources du r eseau, puisquune seule station emet une information qui est trait ee par toutes celles qui sont int eress ees, et elles seules. Toutes les adresses qui ne sont ni du type broadcast ni du type multicast sont du type unicast.

13

4.2

Di erences Ethernet - 802.2/802.3

MAC dest. source LLC 1 1 1 SNAP 3 2 Donnes 38 1492

6
dest.

6
source

RFC 894

gure I.04 Di erences Ethernet 802.2/802.3 On remarque que le champ taille de la trame 802.3 est ` a la place du champ type de la trame Ethernet. La di erenciation seectue ` a partir de la valeur de ces deux octets. On remarque egalement que le commit e 802 a choisi de subdiviser la couche 2 ISO en deux sous couches : MAC et LLC.

14

R eseaux locaux Tous les num eros de protocole sont sup erieurs ` a 150011 qui est la longueur maximale des donn ees encapsul ees. Donc une valeur inf erieure ou egale ` a ce seuil indique une trame 802.3. MAC = Medium Access Control Cette couche est concern ee par la gestion de ladresse physique de la technologie de LAN employ ee (comme token-ring par exemple) LLC = Logical Link Control D enit ce qui est n ecessaire aux multiples couches sup erieures possibles pour utiliser et partager les ressources du lan en m eme temps. Le commit e 802.2 a egalement pr evu plusieurs options, dont deux principalement utilis ees : LLC type 1 Les trames sont d elivr ees en mode datagramme cest ` a dire selon le principe du best eort (on fait au mieux sans garantie de r esultat). LLC type 2 Les trames sont d elivr ees avec une garantie de bon acheminement. Lusage du LLC de type 2 entra ne lajout de champs dans lent ete pour num eroter les paquets, ajouter des acquittements, des synchronisations, etc. . .Cest le protocole HDLC comme Highlevel Data Link Control . Un travail qui est normalement d evolu ` a la couche de transport et qui donc parasite beaucoup la lisibilit e de lensemble.

Interconnexion - Technologie el ementaire

LLC MAC Cable transceiver Carte coupleur Ethernet Cable coaxial

Bus de station

Couche rseau

Couche liaison

Couche physique

gure I.05 Interconnexion - Technologie el ementaire

Le plus petit num ero de protocole est celui dIP : 0800 hexad ecimal. Ce qui fait en d ecimal : 8 162 + 0 161 + 0 160 = 2048
11

Interconnexion - Technologie el ementaire Linterconnexion ne se limite pas au niveau Ethernet. Quelques notions de technologie de base et donc tr` es succintes sont n ecessaires pour bien comprendre la suite de ce cours.

15

5.1

Raccordement
Rseau local Prise "vampire" Transceiver

Figure I.06 lh ote est raccord e ` a laide dune prise de type vampire et dun transceiver . Dans cette technologie de raccordement, le support est un gros c able jaune, dit encore Thick Ethernet ou Ethernet standard, ou encore 10Base5 (10 comme 10Mbits/s, Base comme Baseband , 5 comme 500 m` etres).

Carte rseau

Bus informatique

gure I.06 Prise vampire 5.1.1 10Base5

Quelques particularit es du 10Base5 : Longueur maxi est 500 m` etres, pour un maximum de 100 stations. Cest une vieille technologie tr` es bien normalis ee mais d epass ee. Pas de perturbation quand on ajoute une station : la pose dune nouvelle prise ninterrompt pas la continuit e du r eseau. Co ut non n egligeable. D eplacement dune station non ais e, en plus on perd la prise vampire, elle reste sur le c able. Pour les c ablages rapides on pr ef` ere le 10Base2 ou Thin Ethernet ou encore Ethernet n (2 comme 200 m` etres). 5.1.2 10Base2

Quelques particularit es du 10Base2 : Longueur maxi de 185 m` etres avec un maximum de 30 stations. La topologie impose de mettre les stations en s erie avec un minimum de 0.5 m` etre entre chaque. Le raccord se fait avec un transceiver en T (BNC bien connu des electroniciens). Il faut un bouchon de 50 ohms ` a chaque extr emit e du r eseau (2). Technique tr` es bon march e, souple, les cartes int` egrent le transducteur. Il faut rompre la continuit e du r eseau pour ajouter une nouvelle station, ce qui lemp eche de fonctionner durant lop eration. Cest un in-

16

R eseaux locaux conv enient de taille sur un r eseau tr` es utilis e. Cette technique est en outre assez sensible aux perturbations electromagn etiques. Les d esavantages du 10Base2 imposent g en eralement lusage du 10BaseT dans toute structure d epassant quelques machines (5 ` a 10). Le 10BaseT r` egle d enitivement le probl` eme de lajout ou du retrait dune machine sur le LAN (T comme Twisted Pair ou paires torsad ees). Cette technique impose lusage dune boite noire r eseau nomm ee HUB 12 ou moyeu. Celle-ci simule la continuit e dans le cas du retrait dune station. 5.1.3 10BaseT

Quelques particularit es du 10BaseT : Une double paire torsad ee de c able sut. La longueur maximale entre le moyeu et la station est de 100 m` etres. Le moyeu impose une architecture en etoile. Le raccordement au transducteur se fait ` a laide dune prise du type RJ45, tr` es fragile (ne pas marcher dessus ! :). Le raccordement du HUB eseau se fait par 10Base2, en bre optique, ou (page 18) au reste du r tout simplement par cha nage avec un autre HUB ( Daisy chain ). Cette technique est dune tr` es grande souplesse dutilisation elle impose n eanmoins lacquisiton de HUB, tr` es peu on ereux de nos jours. Cette technique des paires torsad ees est tr` es sensible aux perturbations electromagn etiques. electromagn etiques. Aujourdhui le 100BaseT equipe la majeur partie des equipements professionnels, 100 comme 100 Mbits/s. Enn la bre optique est utilis ee de plus en plus souvent pour eectuer les liaisons point ` a point. 5.1.4 Fibre optique

Quelques particularit es de la bre optique : La plus utilis ee est la bre multimode 62.5/125.0 m Usage dun transducteur optique pour assurer la transformation entre le signal lumineux (un laser) et le signal electrique. La distance maximale entre deux points est 1,5 km. La bre est insensible aux perturbations electromagn etiques, elle permet en outre le c ablage de site important (plusieurs km2 ). La bre permet datteindre des vitesses de transmission sup erieures aux 10Mbits/100Mbits/1000Mbits maintenant courants sur des paires de ls en cuivre. Les nouvelles technologies issues des recherches les plus r ecentes promettent des bres multifr equences (1024 canaux par bre) avec pour
12

Voir au paragraphe 5.3 page 18

Interconnexion - Technologie el ementaire chaque canal une bande passante de plusieurs giga-octets. Ces nouveaux m edias auront une bande passante de plusieurs t era-octets par secondes. . . Son principal d esavantage est un co ut elev e au m` etre (de lordre dune dizaine d pour un c able dun m` etre cinquante) et la n ecessit e davoir des transducteurs au raccordement de tous les appareils contenant de l electronique (serveur, switch, routeur). Un tel module peut co uter de lordre de 500 ` a 1000  . . . 5.1.5 Conclusion

17

Construire un r eseau local consiste ` a juxtaposer des composants de base tr` es bien maitris e, une sorte de m ecano car tous les supports sont mixables. Ne plus installer les technologies les plus anciennes 10Base5, 10Base2 ou m eme 10BaseT, pr ef erer lusage du 100BaseT ou du 1000BaseT qui sont devenus un standard courant du pr ecablage. En eet le c ablage constitue les fondations dun r eseau, le faire proprement dembl e evite une source continuelle dennuis pas la suite ! Les besoins en bande passante daujourdhui ne pr egurent sans doute pas encore les besoins de demain (vid eo haute d enition sur tous les postes. . .), il faut donc pr evoir tr` es large d` es la conception initiale.

Machine A

Machine B

Rseau physique

Ethernet vs 802.2/802.3 Raccordement ==> drivation du rseau

gure I.07 Technologie de liaison

5.2

R ep eteur

` une technologie particuli` A ere correspond forc ement des limitations dues aux lois de la physique. Par exemple en technologie Ethernet la longueur maximale dun brin ne peut pas exc eder 180 m` etres. Pour pallier ` a cette d ecience on utilise des r ep eteurs ( repeaters ).

18 R ep eteurs :
Rpteur R

R eseaux locaux

Brins physiques R diffrents mais meme LAN

gure I.08 Plusieurs r ep eteurs mais toujours le m eme lan Agit uniquement au niveau de la couche 1 ISO, cest un amplicateur de ligne avec ses avantages et aussi linconv enient de transmettre le bruit sans discernement : il ny a aucun ltrage sur le contenu. Relie deux brins dune m eme technologie en un seul LAN car les trames sont reproduites ` a lidentique. En 10Base5, lusage dun r ep eteur fait passer la limite des 500 m` etres ` a 1000 m` etres... Il ny a aucune administration particuli` ere, sinon de brancher la boite noire ` a un emplacement jug e pertinent. Cest un el ement bon march e .

5.3

Concentrateur
gure I.09 Concentateur
" Backbone "

Un concentrateur (ou HUB , moyeu) : Est aussi nomm e etoile ou multir ep eteur. Les HUB nont pas dadresse Ethernet, sauf certains mod` eles evolu es, g erables ` a distance (TELNET,SNMP,. . .). On parle alors de hubs intelligents parcequils permettent dassocier des ports entres-eux.

HUB

Prises RJ45 Stations raccorder au rseau local

Interconnexion - Technologie el ementaire Un hub assure la continuit e du r eseau sur chacune de ses prises, que lon y branche ou pas un h ote. En cela il agit uniquement au niveau de la couche 1 ISO. Il ne limite pas le nombre de collisions et nam eliore pas lusage de la bande passante. Son seul int er et est de donc permettre le branchement ou le d ebranchement des stations sans perturber le fonctionnement global du r eseau. Les hubs peuvent etre cha n es entres-eux ; souvent ils sont reli es au backbone local par une autre technologie que la paire torsad ee (bre optique. . .). Dans le cas de hubs intelligents les ports sont associ es les uns aux autres par groupes de fonctionnement.

19

5.4

Ponts

La technologie CSMA/CD atteint vite ses limites quand le r eseau est encombr e. Une am elioration possible quand on ne peut pas changer de technologie (augmentation du d ebit) est dutiliser un ou plusieurs ponts ( bridges ) pour regrouper des machines qui ont entre-elles un dialogue privil egi e. Dialogue entre deux stations, sans pont :

Le dialogue entre A et B perturbe lventuel dialogue entre D et E.

gure I.10 Dialogue sans pont De nos jours le pont en tant que tel est de moins en moins utilis e par contre le principe de son fonctionnement se retrouve, entres autres, dans les commutateurs (paragraphe suivant) et dans les points dacc` es sans l ( wireless ). Dialogue entre deux stations, avec pont :

Pont intelligent

P Meme rseau local

gure I.11 Dialogue avec pont On peut remarquer que les echanges locaux ` a chaque branche du pont seectuent au mieux des possibilit e de la bande passante, le pont a donc

20

R eseaux locaux multipli e par deux la capacit e globale du trac r eseau vis ` a vis de certains echanges. Un pont : Agit au niveau de la couche 2 ISO, donc au niveau de la trame physique. Son action est plus que physique elle est aussi logique puisquil y a lecture et interpr etation des octets v ehicul es. Le r esultat de ce travail logique (apprentissage) consiste ` a isoler le trac sur certains tron cons ` dun LAN. A cause de ce travail on parle g en eralement de ponts intelligents ou de ponts transparents car la phase dapprentissage est automatique ! R eduit le taux de collisions en r eduisant le trac inutile, donc am eliore lusage de la bande passante. Sur la gure I.11 les machines A et B peuvent dialoguer sans pertuber le dialogue entre les machines D et E. Par contre dans le cas dun dialogue entre A et E le pont ne sert ` a rien. Moins cher quun routeur et plus rapide (services rendus moins complets). Relie deux segments (ou plus) en un seul LAN, les trames transmises sont reproduites ` a lidentique. Un pont contient un cpu, il est en g en eral administrable ` a distance car on peut agir sur la table de ltrages (ajout, contraintes de ltrages, etc...). Dans ce cas un pont a une adresse Ethernet. Les ponts interdisent que les r eseaux aient des boucles, un protocole nomm e STP ( Spanning Tree Protocol ) d esactive automatiquement le ou les ponts qui occasionne(nt) un bouclage des trames. Il existe des ponts entre Ethernet et Token-ring, on parle alors de ponts ` a translations . Attention, un pont ne soccupe que des adresses de type unicast, il ne ltre pas les types broadcast et multicast. On peut remarquer que dans le cas de gure ou le trac est strictement contenu dun cot e et de lautre du pont, alors la bande passante globale du LAN est multipli ee par deux. Bien s ur cette remarque nest plus valable d` es lors quune trame franchit le pont.

5.5

Commutateurs

Aligner des stations sur un m eme r eseau local constitue une premi` ere etape simple et de faible co ut pour un r eseau local dentreprise. Le revers dune telle architecture est que le nombre de collisions cro t tr` es vite avec le trac, do` u une baisse tr` es sensible de la rapidit e des echanges d ue ` a ce gaspillage de la bande passante. Lusage de ponts peut constituer une premi` ere solution mais elle nest pas totalement satisfaisante dans tous les cas de gure, comme nous avons pu le remarquer au paragraphe pr ec edent. Depuis plus dune dizaine dann ees est apparue une technologie nomm ee Intelligent Switching Hub (ISH) commutateur intelligent qui utilise

Interconnexion - Technologie el ementaire le concept de commutation parall` ele et qui a r evolutionn e lorganisation des r eseaux locaux. Daspect ext erieur ces equipements se pr esentent comme un hub mais ont en interne un cpu susamment puissant et un bus interne de donn ees susamment rapide pour mettre en uvre une logique de commutation ran ee. Lorsquune trame se pr esente sur lun des ports du commutateur elle est (ou nest pas) re-rout ee vers un autre port en fonction de ladresse physique du destinataire. Il existe plusieurs di erences entre un pont et un commutateur : Un commutateur peut mettre simultan ement plusieurs ports en relation, sans que le d ebit de chacun en soure. Par exemple un commutateur de 8 ports en 100BaseT peut supporter quatre connexions port source/port destination simultan ees ` a 100 Mbit/s chacune, ce qui donne un d ebit global de 400 Mbit/s qui doit pouvoir etre support e par le bus interne ou fond de panier . Dun point de vue plus th eorique, un commutateur ` a N ports ` a 100 Mbit/s chacun a un d ebit maximum de N 100/2 = 50 N M bit/s. Si une trame est ` a destination dun port d ej` a occup e, le commutateur la m emorise pour la d elivrer sit ot le port disponible. Un commutateur fonctionne comme un pont pour etablir sa carte des adresses mais il peut aussi travailler ` a partir dune table pr econgur ee. Un commutateur peut fonctionner par port (une seule station Ethernet par port) ou par segment (plusieurs stations Ethernet par port). Avec un commutateur, il est ais e dorganiser un r eseau en fonction de la port ee des serveurs des postes clients associ es. La gure I.12 illustre ce principe :
S1 S2 Serveurs gnraux

21

Commutateur intelligent

Hub

Client 1

Serveur local

Client 2

gure I.12 Commutateur Le trac r eseau entre le client 1 et le serveur S2 ne perturbe pas

22

R eseaux locaux le trac entre le client 2 et le serveur S1 . De m eme le trac entre le client 1 et le serveur local nest pas vu du client 2 . Les commutateurs etiquettent les trames avec un identicateur du VLAN auquel elles appartiennent. Cette etiquette se r esume par deux octets ajout es dans la trame, selon les recommandations du comit e 802 (norme 802.1Q).

5.6

Passerelles Routeurs

Pour raccorder deux LANs non forc ement contigus il faut faire appel ` a ce que lon d esigne une passerelle ( gateway ). Son r ole est de prendre une d ecision sur la route ` a suivre et de convertir le format des donn ees pour etre compatible avec le r eseau ` a atteindre (en fonction de la route). Souvent, et cest le cas avec TCP/IP, la fonction de conversion nest pas utilis ee, la fonction de routage donne alors son nom ` a lappareil en question ( eponyme), qui devient un routeur ( router ). Le probl` eme du routage entre A et B :

Plusieurs chemins sont possibles pour aller de A B, do la ncessit dune stratgie.

gure I.13 Fonction routage La fonction passerelle consiste aussi en traduction de protocoles :
A G G G X25 Ethernet B

Token ring

Modem Liaison rtc

gure I.14 Traduction de protocoles Un routeur : Agit au niveau de la couche 3. Il prend des d ecisions de destination.

6 Bibliographie Poss` ede au moins deux interfaces r eseau (pas forc ement identiques). Contient un cpu et un programme tr` es evolu e, il est administrable ` a distance. Remplit egalement les fonctions dun pont (B-routeur) mais les brins ainsi reli es ne forment en g en eral plus un LAN car les adresses physiques contenues dans les trames ne servent plus ` a identier le destinataire. Il faut une autre adresse qui d epend de la pile au-dessus (exemple adresse IP). Il existe cependant des possibilit es de simuler un m eme LAN bien que les trame traversent un routeur (cf cours ARP (page 55)).

23

Bibliographie

Pour en savoir plus : RFC 0894 S C. Hornig, Standard for the transmission of IP datagrams over Ethernet networks , 04/01/1984. (Pages=3) (Format=.txt) RFC 1042 S J. Postel, J. Reynolds, Standard for the transmission of IP datagrams over IEEE 802 networks , 02/01/1988. (Pages=15) (Format=.txt) (Obsoletes RFC0948) Radia Perlman Interconnections Briges and Routeurs AddisonWesley Radia Perlman Interconnections Second Edition Briges, Routeurs, Switches, and Internetworking Protocoles AddisonWesley

24

R eseaux locaux

Chapitre II Introduction ` a IP
1 TCP/IP et lInternet - Un peu dhistoire

En 1969 aux Etats Unis, lagence gouvernementale DARPA lance un projet de r eseau exp erimental, bas e sur la commutation de paquets. Ce r eseau, nomm e ARPANET, fut construit dans le but d etudier les technologies de communications, ind ependamment de toute contrainte commerciale1 Un grand nombre de techniques de communication par modems datent de cette epoque. Lexp erience dARPANET est alors si concluante que toutes les organisations qui lui sont rattach ees lutilisent quotidiennement pour pour leurs messages de service. En 1975, le r eseau passe ociellement du stade exp erimental au stade op erationnel. Le d eveloppement dARPANET ne sarr ete pas pour autant, les bases des protocoles TCP/IP sont d evelopp es ` a ce moment, donc apr` es que ARPANET soit op erationnel. En Juin 1978 Jon Postel2 d enit IPv4 et en 1981 IP est standardis e dans la RFC 791 [J. Postel 1981]. En 1983 les protocoles TCP/IP sont adopt es comme un standard militaire et toutes les machines sur le r eseau commencent ` a lutiliser. Pour faciliter cette reconversion, la DARPA demande ` a luniversit e de Berkeley dimpl ementer ces protocoles dans leur version (BSD) dunix. Ainsi commence le mariage entre ce syst` eme dexploitation et les protocoles TCP/IP. Lapport de lUniversit e de Berkeley est majeur, tant au niveau th eorique (concept des sockets) quau niveau de lutilisateur, avec des utilitaires tr` es homog` enes qui sint` egrent parfaitement au paradigme dusage existant (rcp,
Lanc e en France en 1972, le projet Cyclades , sous la responsabilit e de Louis Pouzin, etait egalement bas e sur la commutation de paquets et lusage de datagrammes. Il reliait quelques grands centres universitaires en France (Lille, Paris, Grenoble,. . .) et en Europe. Il est rest e op erationnel jusquen 1978, date ` a laquelle faute de cr edit il a et e abandonn e au prot de X25, pr ef er e par les op erateurs de t el ecoms nationaux. 2 Jon Postel est d ec ed e le 16 Octobre 1998 ` a l age de 55 ans, cest le premier pionner de lInternet d ec ed e, on peut consulter par exemple : http://www.isi.edu/postel.html
1

26

Introduction ` a IP rsh, rlogin. . .). Depuis cette epoque, un nouveau terme est apparu pour d esigner cette interconnexion de r eseaux, lInternet, avec un i majuscule. Le succ` es de cette technologie est alors tr` es important et suscite un int er et croissant de la part dacteurs tr` es divers, et en particulier La National Science Foundation qui y voit un int er et majeur pour la recherche scientique et soutient donc ce nouveau moyen de mettre en communication tous les chercheurs. Depuis 1990, ARPANET nest plus, pourtant le terme Internet demeure il d esigne maintenant un espace de communication qui englobe la plan` ete tout enti` ere. Des millions de sites partout sur la surface du globe y sont connect es. Depuis 1994, lInternet sest ouvert au commerce, surtout avec lapparition en 1991 dun nouvel outil de consultation, le World Wide Web ou Web et ses interfaces populaires : Mosaic3 , Netscape, Mozilla, Firefox, Konqueror. . . La liste nest pas exhaustive ! Depuis 1995, pour faire face ` a sa popularit e fortement croissante et aux demandes de transactions s ecuris ees, le protocole evolue et une nouvelle version, la version 6 (IPng puis tout simplement IPv6), est d enie et en cours de d eploiement exp erimental. Les protocoles d esign es par TCP/IP ont egalement envahi les r eseaux locaux eux-m emes, car il est plus facile dutiliser les m emes protocoles en interne et en externe. Pour les utilisateurs, lacc` es ` a lInternet est possible ` a laide dune collection de programmes sp ecialis es si faciles ` a utiliser que lon peut ignorer tout (ou presque) de leur fonctionnement interne. Seul les programmeurs dapplications r eseaux et les administrateurs de syst` emes ont besoin den conna tre les arcanes. Les services r eseaux les plus populaires sont principalement : Le courrier electronique qui permet l echange de messages entres usagers. Les innombrables forums de discussion ( news ). Le transfert de chiers entre machines ( ftp et ses d eriv es comme fetch , wget , curl . . .). Le remote login , ou ses equivalents crypt es ( ssh , qui permet ` a un utilisateur de se connecter sur un site distant, depuis son poste local. Les serveurs inter-actifs. Les anciens se nommaient archie, gopher, veronica, wais... D esormais ils sont rendus obsol` etes par le web (protocole http). Puis maintenant la radio, la vid eoconf erence, la r ealit e virtuelle avec le VRML, le chat , les bourses d echanges point ` a point, les blogs forme evolu ee des pages personnelles, etc . . . ... En conclusion de ce paragraphe sur lhistorique on peut dire que lInternet est une collection apparemment anarchique (il ny a pas de structure hi e3

http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html

2 Caract eristiques de TCP/IP rarchique et centralis ee) de r eseaux inter-connect es et appartenant ` a divers propri etaires. On distingue trois niveaux : les r eseaux au sein des organisations (lans), les r eseaux r egionaux et les r eseaux de transit. Le site de lAssociation Fnet indique quelques pointeurs int eressants sur 4 lhistorique de lInternet (en anglais).

27

Caract eristiques de TCP/IP

Le succ` es de TCP/IP, sil vient dabord dun choix du gouvernement am ericain, sappuit ensuite sur des caract eristiques int eressantes : 1. Cest un protocole ouvert, les sources (C) en sont disponibles gratuitement et ont et e d evelopp es ind ependamment dune architecture particuli` ere, dun syst` eme dexploitation particulier, dune structure commerciale propri etaire. Ils sont donc th eoriquement transportables sur nimporte quel type de plate-forme, ce qui est prouv e de nos jours. 2. Ce protocole est ind ependant du support physique du r eseau. Cela permet ` a TCP/IP d etre v ehicul e par des supports et des technologies aussi di erents quune ligne s erie, un c able coaxial Ethernet, une liaison lou ee, un r eseau token-ring, une liaison radio (satellites, wireless 802.11a/b/g), une liaison FDDI 600Mbits, une liaison par rayon laser, infrarouge, xDSL, ATM, bre optique, la liste des supports et des technologies nest pas exhaustive. . . 3. Le mode dadressage est commun ` a tous les utilisateurs de TCP/IP quelle que soit la plate-forme qui lutilise. Si lunicit e de ladresse est respect ee, les communications aboutissent m eme si les h otes sont aux antipodes. 4. Les protocoles de hauts niveaux sont standardis es ce qui permet des d eveloppements largement r epandus et inter-op erables sur tous types de machines. La majeurs partie des informations relatives ` a ces protocoles sont publi ees dans les RFCs (Requests For Comments). Les RFCs contiennent les derni` eres versions des sp ecications de tous les protocoles TCP/IP, ainsi que bien dautres informations comme des propositions dam eliorations des outils actuels, la description de nouveaux protocoles, des commentaires sur la gestion des r eseaux, la liste nest pas exhaustive.

http://www.fnet.fr/history/

28

Introduction ` a IP

Comparaison TCP/IP ISO

La suite de protocoles d esign ee par TCP/IP, ou encore pile ARPA , est construite sur un mod` ele en couches moins complet que la proposition de lISO. Quatre couches sont susantes pour d enir larchitecture de ce protocole. 4 Couche Application (Application layer). 3 Couche Transport (Transport layer). 2 Couche Internet (Internet layer). 1 Couche interface r eseau (Network access layer). 0 Mat eriel (nest pas une couche comprise dans le protocole).

Application Prsentation Session Transport Rseau Liaison Physique 4 3 2 1 0 Application Transport Internet Interface Matriel

Pile Arpa

gure II.01 Comparaison ISO-ARPA La gure II.01 met en comparaison les fonctionnalit es des couches du mod` ele OSI et celles des protocoles TCP/IP. La gure II.02 elle, donne une vue densemble de larchitecture logicielle avec quelques protocoles dapplications de la famille IP. Ils sont tr` es nombreux, non repr esent es tous ici, et il sen faut de beaucoup car il en existe des centaines. La lecture du chier /etc/services, pr esent sur toute machine de la famille des Unix, donne un aper cu des principaux services enregistr es aupr` es de lIANA. Quand nous aurons expliqi e la notion port (cf page 81) cette lecture sera plus facile. . .Donc patience ! IP Internet Protocol SCTP Stream Control Transmission Protocol TCP Transmission Control Protocol UDP User Datagram Protocol

Comparaison TCP/IP ISO

29

http SCTP arp rarp Ethernet ATM

smtp TCP IP fibre optique

dns

snmp UDP igmp

nfs xdr rpc

Application

Transport icmp ... Internet + Interface Couche matrielle non comprise dans Arpa

Infra rouge

Wifi

gure II.02 Architecture logicielle Les chapitres qui suivent donnent loccasion dexaminer SMTP, DNS, SNMP, SCTP, TCP, UDP, ARP, RARP, IP, IGMP et ICMP !

3.1

Couche Application Layer

Au plus haut niveau les utilisateurs invoquent les programmes qui permettent lacc` es au r eseau. Chaque programme dapplication interagit avec la couche de transport pour envoyer ou recevoir des donn ees. En fonction des caract eristiques de l echange le programme a choisi un mode de transmission ` a la couche de transport. La plus grande proportion des applications laissent ` a la couche de transport le soin deectuer le travail de Session , n eanmoins il est possible pour certaines applications de court-circuiter cette fonctionnalit e pour agir directement au niveau R eseau , comme on peut lobserver sur la gure II.02 ` a droite.

3.2

Couche Transport Layer

La principale t ache de la couche de transport est de fournir la communication dun programme dapplication ` a un autre. Une telle communication est souvent quali ee de point ` a point . Cette couche peut avoir ` a r eguler le ot de donn ees et ` a assurer la abilit e du transfert : les octets re cus doivent etre identiques aux octets envoy es. Cest pourquoi cette couche doit g erer des checksums et savoir re- emettre des paquets mal arriv es. Cette couche divise le ux de donn ees en paquets (terminologie de lISO) et passe chacun avec une adresse de destination au niveau inf erieur. De plus, et cest surtout valable pour les syst` emes dexploitation multit aches multi-utilisateurs (Unix,. . .), de multiples processus appartenant ` a des utilisateurs di erents et pour des programmes dapplications di erents, acc` edent au r eseau au m eme moment, ce qui implique la capacit e de multiplexer et de d emultiplexer les donn ees, suivant quelles vont vers le r eseaux

30 ou vers les applications ( Session ).

Introduction ` a IP

3.3

Couche Internet Layer

Cette couche re coit des data-grammes en provenance de la couche r eseau, quelle doit analyser pour d eterminer sils lui sont adress es ou pas. Dans le premier cas elle doit d ecapsuler son en-t ete du data-gramme pour transmettre les donn ees ` a la couche de transport et au bon protocole de cette couche (TCP, UDP...), dans le deuxi` eme cas elle les ignore. Cette couche prend aussi en charge la communication de machine ` a machine. Elle accepte des requ etes venant de la couche de transport avec une identication de la machine vers laquelle le paquet doit etre envoy e. Elle utilise alors lalgorithme de routage (page 70) pour d ecider si le paquet doit etre envoy e vers une passerelle ou vers une machine directement accessible. Enn cette couche g` ere les datagrammes des protocoles ICMP et IGMP.

3.4

Couche Network Access

Le protocole dans cette couche d enit le moyen pour un syst` eme de d elivrer linformation ` a un autre syst` eme physiquement reli e. Il d enit comment les data-grammes IP sont transmis. La d enition de ceux-ci reste ind ependante de la couche r eseau, ce qui leur permet de sadapter ` a chaque nouvelle technologie au fur et ` a mesure de leur apparition. Avant de sint eresser au d etail des data-grammes IP, nous allons examiner le probl` eme de ladressage IP, dans le chapitre suivant.

Encapsulation dIP
A Application Message Transport Paquet Internet Datagramme Network Trame Network Internet Transport B Application

Rseau physique

5 Bibliographie gure II.03 Encapsulation dIP Comme nous lavons d ecrit avec le mod` ele des couches OSI, les couches IP fonctionnent par encapsulations progressives. Chaque couche en-capsule la pr ec edente avec les informations de contr ole quelle destine ` a la couche de m eme niveau sur la machine distante. Cet ajout est nomm e header (en-t ete) parce-quil est plac e en t ete des donn ees ` a transmettre. Application Transport Internet Network | | Header | | Header | Header | | Header | Header | Header | datas datas datas datas | | | |

31

La taille des headers d epend des protocoles utilis es. Pour la couche IP le protocole comporte en standard 5 mots de 32 bits, m eme chose pour la 5 couche TCP .

Bibliographie

Pour en savoir plus :

RFC 0791 S J. Postel, Internet Protocol , 09/01/1981. (Pages=45) (Format=.txt) (Obsoletes RFC0760) La Recherche Num ero sp ecial Internet num ero 238 de f evrier 2000

5 mots de 32 bits = 5 4 octets = 20 octets

32

Introduction ` a IP

Chapitre III Anatomie dune adresse IP

1 Adressage IP

Nous avons dit que lInternet est un r eseau virtuel, construit par interconnexion de r eseaux physiques via des passerelles. Ce chapitre parle de ladressage, le maillon essentiel des protocoles TCP/IP pour rendre transparents les d etails physiques des r eseaux et faire apparaitre lInternet comme une entit e homog` ene.

1.1

Unicit e de ladresse

Un syst` eme de communication doit pouvoir permettre ` a nimporte quel h ote de se mettre en relation avec nimporte quel autre. An quil ny ait pas dambigu t e pour la reconnaissance des h otes possibles, il est absolument n ecessaire dadmettre un principe g en eral didentication. Lorsque lon veut etablir une communication, il est intuitivement indispensable de poss eder trois informations : 1. Le nom de la machine distante, 2. Son adresse, 3. La route ` a suivre pour y parvenir. Le nom dit qui est lh ote distant, ladresse nous dit o` u il se trouve et la route comment on y parvient. En r` egle g en erale les utilisateurs pr ef` erent des noms symboliques pour identier les machines tandis que les processeurs de ces m emes machines ne comprennent que les nombres exprim es au format binaire. Les adresses IP (version 4) sont standardis ees sous forme dun nombre de 32 bits qui permet ` a la fois lidentication de chaque h ote et du r eseau auquel il appartient. Le choix des nombres composants une adresse IP nest pas laiss e au hasard, au contraire il fait lobjet dune attention particuli` ere notamment pour faciliter les op erations de routage. Nous eludons la correspondance entre ce nombre et une eventuelle repr esentation symbolique, cest lobjet du serveur de noms, une application examin ee page 165.

34

Anatomie dune adresse IP Chaque adresse IP contient donc deux informations el ementaires, une adresse de r eseau et une adresse dh ote. La combinaison des deux d esigne de mani` ere unique une machine et une seule sur lInternet, sous r eserve que cette adresse ait et e attribu ee par un organisme ayant pouvoir de le faire !

1.2

D elivrance des adresses IPv4

On distingue deux types dadresses IP : Les adresses priv ees que tout administrateur de r eseau peut sattribuer librement pourvu quil(elle) ne cherche pas ` a les router sur lInternet les adresses publiques d elivr ees par une structure mondiale qui en assure lunicit e. Ce dernier point est capital pour assurer lecience du routage, comme nous le comprendrons en d etaillant le fonctionnement dIP, ` a partir de la page 47. Les adresses ` a utiliser sur les r eseaux priv es sont d ecrites par la RFC 1918 : 10.0.0.01 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255 Les adresses publiques (souvent une seule), sont le plus g en eralement four2 nies par le FAI . Quelles soient d elivr ees de mani` ere temporaire ou attribu ees pour le long terme, elles doivent etre uniques sur le r eseau. La question est donc de savoir de qui le FAI les obtient. Cest LICANN ou Internet Corporation for Assigned Names and Numbers3 qui est charg e au niveau mondial de la gestion de lespace dadressage IP. Il d enit les proc edures dattribution et de r esolution de conits dans lattribution des adresses, mais d el` egue le d etail de la gestion de ces ressources ` a des instances r egionales puis locales, dans chaque pays, appel ees RIR ou Regional Internet Registries . Il y a actuellement cinq Regional Internet Registries op erationnels : 4 5 lAPNIC pour la r egion Asie-Pacique, lARIN pour lAm erique, le RIPE NCC6 pour lEurope, lAfriNIC7 pour lAfrique enn LACNIC8 pour lAm erique Latine. Pour ce qui nous concerne en Europe cest donc le RIPE NCC (R eseaux IP europ een Network Coordination Centre) qui d elivre les adresses que nous utilisons. Les adresses IP sont allou ees ` a lutilisateur nal qui en fait la demande par un Local Internet Registry , ou LIR, autoris e par le RIPE NCC.
2 3

Fournisseur dAcc` es Internet http://www.icann.org 4 http://www.apnic.net 5 http://www.arin.net/ 6 http://www.ripe.net/ 7 http://www.afrinic.net/ 8 http://lacnic.net/

2 Anatomie dune adresse IP Un LIR est g en eralement un FAI ou une grande organisation (entreprise multinationale). Il est sous lautorit e de linstance r egionale de gestion de ladressage. Ainsi pour un utilisateur (quelle que soit sa taille) changer de FAI implique aussi de changer de plan dadressage IP, lorsque celles-ci ont et e allou ees statiquement par le LIR. Les adresses IP sont alors restitu ees puis r e-attribu ees ` a dautres utilisateurs. On compte plus de 2000 de LIRs orant leurs services en Europe see depuis 2003, avec lon le RIPE NCC9 . Le chire a forcement augment l elargissement des fronti` eres europ eennes.

35

Anatomie dune adresse IP

Une adresse IP est un nombre de 32 bits que lon a coutume de repr esenter sous forme de quatre entiers de huit bits, s epar es par des points (paragraphe 1.2). La partie r eseau de ladresse IP vient toujours en t ete, la partie h ote est donc toujours en queue. Lint er et de cette repr esentation est imm ediat quand on sait que la partie r eseau et donc la partie h ote sont presque toujours cod ees sur un nombre entier doctets. Ainsi, on a principalement les trois formes suivantes : Classe A Un octet r eseau, trois octets dh otes. Classe B Deux octets r eseau, deux octets dh otes. Classe C Trois octets r eseau, un octet dh ote.

2.1

D ecomposition en classes
Classe Nombre de rseaux/machines

1.x.y.z 127.x.y.z
127 rseaux 16 777 216 machines (2^24)

128.0.x.y 191.255.x.y B
16 384 rseaux (2^14) 65536 machines (2^16)

192.0.0.z 223.255.255.z C
2 097 152 rseaux (2^21) 256 machines (2^8)

224.0.0.0 239.255.255.255

240.0.0.0 247.255.255.255

gure III.01
D ecomposition en classes
9

Pour distinguer les classes A, B, C, D et E il faut examiner les bits de poids fort de loctet de poids fort : Si le premier bit est 0, ladresse est de classe A. On dispose de 7 bits pour identier le r eseau et de 24 bits pour identier lh ote. On a donc les r eseaux de 1 ` a 127 et 224 h otes possibles, cest ` a dire 16 777 216 machines di erentes (de 0 ` a 16 777 215). Les lecteurs attentifs auront remarqu e que le r eseau 0 nest pas utilis e, il a une signication particuli` ere ( tous les r eseaux ). Plus de d etails au paragraphe 2.2.

http://www.ripe.net/ripe/docs/ar2003.html

36

Anatomie dune adresse IP De m eme, la machine 0 nest pas utilis ee, tout comme la machine ayant le plus fort num ero dans le r eseau (tous les bits de la partie h ote ` a 1, ici 16 777 215), ce qui r eduit de deux unit es le nombre des machines nommables. Il reste donc seulement 16 777 214 machines adressables dans une classe A ! Si les deux premiers bits sont 10 , ladresse est de classe B. Il reste 14 bits pour identier le r eseau et 16 bits pour identier la machine. Ce 14 qui fait 2 = 16 384 r eseaux (128.0 ` a 191.255) et 65 534 (65 536 2) machines. Si les trois premiers bits sont 110 , ladresse est de classe C. Il reste 21 bits pour identier le r eseau et 8 bits pour identier la machine. Ce 21 qui fait 2 = 2 097 152 r eseaux (de 192.0.0 ` a 223.255.255) et 254 (256 2) machines. Si les quatre premiers bits de ladresse sont 1110 , il sagit dune classe dadressage sp eciale, la classe D. Cette classe est pr evue pour faire du multicast , ou multipoint. (RFC 1112 [S. Deering, 1989]), contrairement aux trois premi` eres classes qui sont d edi ees ` a l unicast ou point ` a point. Ces adresses forment une cat egorie ` a part, nous en reparlons au paragraphe 3. Si les quatre premiers bits de ladresse sont 1111 , il sagit dune classe exp erimentale, la classe E. La RFC 1700 pr ecise Class E addresses are reserved for future use mais nindique pas de quel futur il sagit. . . Enn, pour conclure ce paragraphe, calculons le nombre dh otes adressables th eoriquement ` a laide des classes A, B et C : 127 16777212 + 16384 65534 + 2097152 254 = 3737091588
10

Ce total, pour etre plus exact, doit etre amput e des 17 890 780 h otes des 11 r eseaux priv es pr evus dans la RFC 1918 , soit donc tout de m eme au total 3 719 200 808 h otes adressables en utilisant IPv4 !

10 11

Sous shell, tapez : echo "127*16777212+16384*65534+2097152*254"|bc 16777212 + 16 65534 + 256 254 = 17890780

Anatomie dune adresse IP

37

2.2

Adresses particuli` eres

Certaines adresses IP ont une signication particuli` ere ! Par convention le num ero 0 dh ote nest pas attribu e. Si une adresse IP contient cette zone nulle cela signie que lon adresse le r eseau lui-m eme et aucun h ote en particulier, donc en r` egle g en erale lh ote lui-m eme. De m eme, pour toutes les pile Arpa ladresse 127.0.0.1 indique la machine elle-m eme ( localhost Voir chapitre IP page 47), ind ependamment des autres adresses r eseaux eventuellement attribu ees ` a nimporte lequel de ses interfaces. ` linverse, si tous les bits de la partie h A ote sont ` a 1, cela d esigne toutes les machines du r eseaux, cest ce que lon appele une adresse de broadcast , cest ` a dire une information adress ee ` a tout le monde. On evite au maximum lusage dune telle adresse IP sur les r eseaux, pour des raisons decacit e (encombrement de la bande passante). Quelques exemples dadresses avec une signication particuli` ere : 0.0.0.0 0.0.0.1 255.255.255.255 138.195.52.1 138.195.0.0 193.104.1.255 127.0.0.1 H ote inconnu, sur ce r eseau Lh ote 1 de ce r eseau Tous les h otes Lh ote 52.1 du r eseau 138.195.0.0 Cet h ote sur le 138.195.0.0 Tous les h otes du 193.104.1.0 Cet h ote (boucle locale).

Remarque : les deux premi` eres adresses, avec un num ero de r eseau egal ` a 0, ne peuvent gurer que comme adresse source dans des cas bien particuliers comme le d emarrage dune station (cf chapitre IP page 47 et les travaux pratiques associ es).

38

Anatomie dune adresse IP

2.3

Sous-r eseaux

En 1984 un troisi` eme niveau de hi erarchie est mis en place : le subnet ou sous-r eseau. pour permettre aux administrateurs de g erer plus nement de grands r eseaux. La RFC 950 [J. Mogul, J. Postel, 1985] donne plus de pr ecisions, la RFC 1878 [T. Pummill & B. Manning, 1995] est une table de tous les sous-r eseaux possibles.
Hostid de la classe C 31 24 23 16 15 193 104 1 8 76 5 0 hostid (6 bits) rduit des 2 bits du subnet id

Netid de la la classe C

subnet id (2 bits) netmask (les 2 bits de poids fort) : 255.255.255.192 = 0xFFFFFFC0

Dans la gure III.02 ci-contre, les bits 6 et 7 de la partie host sont utilis es pour caract eriser un sousr eseau. Quelques r evisions des propri et es des puissances de 212 sont souvent n ecessaires pour bien assimiler ce paragraphe. La gure suivante en rappelle les valeurs pour les huit premiers exposants : gure III.03 Puissances de 2

gure III.02 Sous-r eseaux Le subnet utilise les bits de poids fort de la partie h ote de ladresse IP, pour d esigner un r eseau. Le nombre de bits employ es est laiss e ` a linitiative de ladministrateur.
1

7 128

6 64

5 32

4 16

3 8

2 4

1 2

0 1

Dcomposition unique : 255 = 128 + 64 + 32 + 16 +8 + 4 + 2 + 1

Nous avons dune part 27 + 26 = 192, et dautre part 25 + 24 + 23 + 22 + 2 + 20 = 6313 . Ce qui permet de caract eriser 4 sous-r eseaux de 62 machines (63 moins ladresse de broascast, le 0 n etant pas compt e). Le calcul des masques et des adresses de diusion est expliqu e dans le tableau suivant : Num ero du r eseau 193.104.1.00 193.104.1.64 193.104.1.128 193.104.1.192 Netmask Broadcast Adressage h ote 255.255.255.192 00 + 63 = 63 .1 ` a .62 255.255.255.192 64 + 63 = 127 .65 ` a .126 255.255.255.192 128 + 63 = 191 .129 ` a .190 255.255.255.192 192 + 63 = 255 .193 ` a .254

12 13

et plus g en eralement de la d ecomposition dun nombre en ses facteurs premiers. . . Donc 64 valeurs possibles de 0 ` a 63

Sous-r eseaux Soit un total de 62 4 = 248 h otes possibles pour cette classe C avec un 14 masque de sous-r eseau , au lieu des 254 h otes sans. La machine dadresse 1 sur chaque sous-r eseau, aura comme adresse IP : Sous-r eseau Adresse D ecomposition 00 193.104.1.1 00 + 1 = 1 01 193.104.1.65 64 + 1 = 65 10 193.104.1.129 128 + 1 = 129 11 193.104.1.193 192 + 1 = 193 Si vous pensez avoir tout compris, le remplissage du tableau suivant dans le cas de la classe C 192.168.192.0 et avec 3 bits pour d enir les sous-r eseaux ne devrait pas vous poser de probl` eme. . . Num ero du subnet 000(0) 001(1) 010(2) 011(3) 100(4) 101(5) 110(6) 111(7) Num ero du r eseau 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. Adresse de broadcast 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. Premi` ere Derni` ere machine machine

39

` toutes ces adresses il faudra appliquer le masque de sous-r A eseau : 0xFFFFFF soit encore 255.255.255.

Remarque : On pourra v erifer que la perte despace dadressage pour adresser des h otes se calcule avec la relation (2n 1) 2, o` u n est le nombre de bits du masque. Ainsi avec 3 bits de masque de sous-r eseau, la perte despace dadressage s el` eve ` a 14 h otes ! Les 254 possibilit es (256 moins 0 et 255) de num erotation de la classe C se r eduisent ` a 240, amput ees de 31, 32, 63, 64, 95, 96, 127, 128, 159, 160, 191, 192, 223 et 224.

14

netmask

40

Anatomie dune adresse IP

2.4

CIDR

En 1992 la moiti e des classes B etaient allou ees, et si le rythme avait continu e, au d ebut de 1994 il ny aurait plus eu de classe B disponible et lInternet aurait bien pu mourrir par asphyxie ! De plus la croissance du nombre de r eseaux se traduisait par un usage aux limites des routeurs, proches de la saturation car non pr evus au d epart pour un tel volume de routes (voir les RFC 1518 et RFC 1519). Deux consid erations qui ont conduit lIETF a mettre en place le Classless InterDomain Routing ou CIDR ou encore routage Internet sans classe, bas e sur une constatation de simple bon sens : Sil est courant de rencontrer une organisation ayant plus de 254 h otes, il est moins courant den rencontrer une de plus de quelques milliers. Les adresses allou ees sont donc des classes C contig ues, attribu ees par r egion ou par continent. En g en erale, 8 ` a 16 classes C mises bout ` a bout susent pour une entreprise. Ces blocs de num eros sont souvent appell es supernet . Ainsi par exemple il est courant dentendre les administrateurs de r eseaux parler dun slash 22 (/22) pour d esigner un bloc de quatre classes C cons ecutives. . . Il est plus facile de pr evoir une table de routage pour un bloc de r eseaux contig ues que davoir ` a le faire pour une multitude de routes individuelles. En plus cette op eration all` ege la longueur des tables. Plus pr ecisement, trois caract eristiques sont requises pour pouvoir utiliser ce concept : 1. Pour etre r eunies dans une m eme route, des adresses IP multiples doivent avoir les m emes bits de poids fort (seuls les bits de poids plus faible di` erent)de poids faibles di` erent. 2. Les tables de routages et algorithmes doivent prendre en compte un masque de 32 bits, ` a appliquer sur les adresses. 3. Les protocoles de routage doivent ajouter un masque 32 bits pour chaque adresse IP (Cet ajout double le volume dinformations) transmise. OSPF, IS-IS, RIP-2, BGP-4 le font. Ce masque se manifeste concr etement comme dans la re ecriture du tableau du paragraphe 1.2 : 10.0.0.0 10.255.255.255 10/8 172.16.0.0 172.31.255.255 172.16/12 192.168.0.0 192.168.255.255 192.168/16 Le terme classless vient de ce fait, le routage nest plus bas e uniquement sur la partie r eseau des adresses.

Pr ecisions sur le broadcast Les agr egations dadresses sont ventil ees selon le tableau suivant15 : Multir egionales Europe Autres Am erique du Nord Am erique centrale, Am erique du Sud Zone Pacique Autres Autres 192.0.0.0 194.0.0.0 196.0.0.0 198.0.0.0 200.0.0.0 202.0.0.0 204.0.0.0 206.0.0.0 193.255.255.255 195.255.255.255 197.255.255.255 199.255.255.255 201.255.255.255 203.255.255.255 205.255.255.255 207.255.255.255

41

2.5

Pr ecisions sur le broadcast

Tout dabord il faut pr eciser quune adresse de broadcast est forc ement une adresse de destination, elle ne peut jamais appara tre comme une adresse source dans un usage normal des r eseaux. Quatre formes possibles de broadcast : Limited broadcast (255.255.255.255) Une telle adresse ne peut servir que sur le brin local et ne devrait jamais franchir un routeur. Ce nest malheureusement pas le cas (pr ecisions en cours). Lusage de cette adresse est normalement limit ee ` a un h ote en phase dinitialisation, quand il ne connait rien du r eseau sur lequel il est connect e. Net-directed broadcast Tous les bits de la partie h ote sont ` a 1. Un routeur propage ce type de broadcast, sur option. Subnet-directed broadcast Cest le m eme cas que ci-dessus mais avec une adresses IP comportant des subnets. All-subnets-directed broadcast Cest le cas o` u tous les bits des subnets et h otes sont ` a 1. Ce cas possible th eoriquement est rendu obsol` ete depuis la RFC 922 (1993).

Ce tableau est tr` es synth etique, pour une information plus d etaill ee et ` a jour consultez le site de lIANA http://www.iana.org/assignments/ipv4-address-space

15

42

Anatomie dune adresse IP

Adressage multicast

En r` egle g en erale ladressage multicast est employ e pour sadresser en une seule fois ` a un groupe de machines. Dans le cas dun serveur vid eo/audio, cette approche induit une economie de moyen et de bande passante evidente quand on la compare ` a une d emarche unicast : un seul datagramme est rout e vers tous les clients int eress es au lieu dun envoi massif dautant de datagrammes quil y a de clients. Les adresses de type multicast ont donc la facult e didentier un groupe de machines qui partagent un protocole commun par opposition ` a un groupe de machines qui partagent un r eseau commun. La plupart des adresses multicast allou ees le sont pour des applications particuli` eres comme par exemple la d ecouverte de routeurs (que nous verrons ult erieurement lors du routage IP) ou encore la radio ou le t el ephone/vid eo sur Internet ( Mbone ). Parmi les plus souvent utilis ees16 sur un lan : 224.0.0.1 224.0.0.2 224.0.0.5 224.0.0.9 224.0.0.22 Toutes les machines sur ce sous-r eseau Tous les routeurs sur ce sous-r eseau Tous les routeurs OSPF (page 121) Tous les routeurs RIPv2 (page 113) Protocole IGMP (page 63)

3.1

Adresse de groupe multicast

Si une adresse multicast d emarre avec les bits 1110 par contre pour les 28 bits suivants son organisation interne di` ere de celle des classes A, B et C.
"Multicast group address"

1 1 1 0

4 bits

28 bits "Multicast group ID"

gure III.04 Adresses de multicast Les 28 bits nont pas de structure particuli` ere par contre on continue ` a utiliser la notation d ecimale point ee : 224.0.0.0 ` a 239.255.255.255. Un groupe dh otes qui partagent un protocole commun utilisant une adresse multicast commune peuvent etre r epartis nimporte o` u sur le r eseau. Lappartenance ` a un groupe est dynamique, les h otes qui le d esirent rejoignent et quittent le groupe comme ils veulent. Il ny a pas de restriction sur le nombre dh otes dans un groupe et un h ote na pas besoin dappartenir ` a un groupe pour lui envoyer un message.
16

Pour plus de pr ecisions on pourra se reporter page 56 de la RFC 1700

Adresse multicast et adresse MAC

43

3.2

Adresse multicast et adresse MAC

Une station Ethernet quelconque doit etre congur ee pour accepter le multicast, cest ` a dire pour accepter les trames contenant un datagramme munis dune adresse IP de destination qui est une adresse multicast. Cette op eration sous entend que la carte r eseau sait faire le tri entre les trames. En eet les trames multicast ont une adresse MAC particuli` ere : elles commencent forc ement par les trois octets 01:00:5E17 . Ceux-ci ne d esignent pas un constructeur en particulier mais sont poss ed es par lICANN (ex IANA). Restent trois octets dont le bit de poids fort est forc ement ` a 0 pour d esigner les adresses de multicast (contrainte de la RFC 1700), ce qui conduit au sch ema suivant :
5 bits non insrables dans ladresse MAC.
0 1 1 10 7 8 15 16 23 24 31

01

00

5E

Les 23 bits de poids faible du "group Id" de ladresse

0 00 0 0 0 01 0 0 0 0 0 0 0 0 01 01 1 1 1 0 0

gure III.05 Adresse physique de multicast Du fait quil ny a pas assez de place dans ladresse MAC pour faire tenir les 28 bits du groupe multicast, cette adresse nest pas unique. On peut m eme pr eciser que pour chaque trame comportant une adresse multicast il y a 25 adresses IP de groupes multicast possibles ! Ce qui signie que si les 23 bits de poids faible ne susent pas ` a discriminer la trame il faudra faire appel au pilote de p eriph erique ou ` a la couche IP pour lever lambigu t e. Quand une trame de type multicast est lue par la station Ethernet puis par le pilote de p eriph erique, si ladresse correspond ` a lune des adresses de groupe multicast pr ealablement congur ees, le datagramme franchit la couche IP et une copie des donn ees est d elivr ee aux processus qui ont joint le groupe multicast . La question est de savoir comment les trames de type multicast atteignent justement cette station Ethernet ? La r eponse se trouve dans un protocole nomm e IGMP et que nous examinerons dans le prochain chapitre concernant IP, page 63.

17

Cf RFC 1700 page 171

44

Anatomie dune adresse IP

Conclusion et bibliographie

Pour conclure ce chapitre sur ladressage IP, il faut nous donner quelques pr ecisions suppl ementaires. Jusqu` a pr esent nous avons d esign e un h ote par son adresse IP. Cette d emarche nest pas exacte si on consid` ere par exemple le cas dune passerelle, connect ee physiquement ` a au moins deux r eseaux di erents, avec une adresse IP dans chacun de ces r eseaux. On dira donc maintenant quune adresse IP identie non pas un h ote mais un interface. La r eciproque nest pas vraie car un m eme interface peut collectionner plusieurs adresses IP. Toutes permettent datteindre cet interface, on parle alors d alias IP , d h otes virtuels et de r eseaux virtuels . . .Nous aurons loccasion de revenir sur ces notions ` a la n de ce cours (page 137). On dit dune machine ayant au moins deux adresses IP quelle est du type multi-homed . En g en eral une passerelle qui met en relation n r eseaux poss` ede n adresses IP di erentes (une dans chaque r eseau), mais ce nest pas une obligation (nous verrons quelle peut en etre lutilit e` a la n de ce cours).
A Application Messages identiques Transport Transport B Application

Paquets identiques Passerelle G

Internet

Internet

Internet

Rseau

Rseau

Rseau

Rseau physique 1

Rseau physique 2

gure III.06 Usage combin e des adresses logique et physique La gure III.06 met en situation deux h otes, A et B, en relation via une passerelle G. Si les messages et les paquets sont identiques, par contre les datagrammes et les trames di` erent puisquil ne sagit plus du m eme r eseau physique. D` es que nous aurons examin e le fonctionnement de la couche IP nous reviendrons sur cette gure pour en expliquer le fonctionnement (voir page 76).

Conclusion et bibliographie Pour en savoir plus : RFC 0950 S J. Mogul, J. Postel, Internet standard subnetting procedure , 08/01/1985. (Pages=18) (Format=.txt) (STD 5) RFC 1112 S S. Deering, Host extensions for IP multicasting , 08/01/1989. (Pages=17) (Format=.txt) (Obsoletes RFC0988) (STD 5) RFC 1518 An Architecture for IP Address Allocation with CIDR Y. Rekhter, T. Li. September 1993. (Format : TXT=72609 bytes) (Status : PROPOSED STANDARD) RFC 1519 PS V. Fuller, T. Li, J. Yu, K. Varadhan, Classless InterDomain Routing (CIDR) : an Address Assignment and Aggregation Strategy , 09/24/1993. (Pages=24) (Format=.txt) (Obsoletes RFC1338) RFC 1466 I E. Gerich, Guidelines for Management of IP Address Space , 05/26/1993. (Pages=10) (Format=.txt) (Obsoletes RFC1366) RFC 1467 Status of CIDR Deployment in the Internet. C. Topolcic. August 1993. (Format : TXT=20720 bytes) (Obsoletes RFC1367) (Status : INFORMATIONAL) RFC 1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD) RFC 1878 Variable Length Subnet Table For IPv4. T. Pummill & B. Manning. December 1995. (Format : TXT=19414 bytes) (Obsoletes RFC1860) (Status : INFORMATIONAL) RFC 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE) Quelques ouvrages qui font autorit e: W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall Christian Huitema - Le routage dans lInternet - EYROLLES

45

46

Anatomie dune adresse IP

Chapitre IV Protocole IP
1 Datagramme IP

IP est lacronyme de Internet Protocol , il est d eni dans la RFC 791 et a et e con cu en 1980 pour remplacer NCP ( Network Control Protocol ), le protocole de lArpanet. Presque trente ans apr` es sa premi` ere impl ementation, ses limitations se font de plus en plus p enalisantes pour les nouveaux usages sur les r eseaux. Avant de le jeter aux orties, posons-nous la question de qui pouvait pr evoir ` a cette epoque o` u moins de mille ordinateurs etaient reli es ensembles, que trois d ecennies plus tard des dizaines de millions dh otes lutiliseraient comme principal protocole de communication ? Sa long evit e est donc remarquable et il convient de lanalyser de pr` es avant de pouvoir le critiquer de mani` ere constructive.

1.1

Structure de len-t ete

31 Entete standard (5 mots de 4 octets) 28 27 VERS 24 23 SERVICE TYPE FLAGS (3bits) 16 15 TOTAL LENGTH FRAGMENT OFFSET (13 bits) 0

Les octets issus de la couche de transport et encapsul es ` a laide dun en-t ete IP avant d etre propag es vers la couche r eseau (Ethernet par exemple), sont collectivement nomm es datagramme IP , datagramme Internet ou datagramme tout court. Ces datagrammes ont une taille maximale li ee aux caract eristiques de propagation du support physique, cest le Maximum Transfer Unit ou MTU. gure IV.01 Structure du datagramme IP

HLEN

IDENTIFICATION

TTL

PROTO

HEADER CHECKSUM

SOURCE IP ADDRESS

DESTINATION IP ADDRESS

IP OPTIONS

PADDING

DATA

....

48

Protocole IP Quelques caract eristiques en vrac du protocole IP : IP est le support de travail des protocoles de la couche de transport, UDP, TCP et SCTP. IP ne donne aucune garantie quant au bon acheminement des donn ees quil envoie. Il nentretient aucun dialogue avec une autre couche IP distante, on dit aussi quil d elivre les datagramme au mieux . Chaque datagramme est g er e ind ependamment des autres datagrammes m eme au sein du transfert des octets dun m eme chier. Cela signie que les datagrammes peuvent etre m elang es, dupliqu es, perdus ou alt er es ! Ces probl` emes ne sont pas d etect es par IP et donc il ne peut en informer la couche de transport. Les octets sont lus et transmis au r eseau en respectant le Network Byte Order ou NBO (cf paragraphe 1.2) quelle que soit larchitecture cpu de lh ote. Len-t ete IP minimale fait 5 mots de 4 octets, soit 20 octets. Sil y a des options la taille maximale peut atteindre 60 octets.

1.2

Network Byte Order

Sur la gure IV.01 les bits les plus signicatifs de chaque mot de quatre octets sont ` a gauche (31. . .). Ils sont dailleurs transmis sur le r eseau dans cet ordre1 , cest un standard, cest le Network Byte Order . Toutes les architectures de CPU ne sont pas b aties sur le m eme mod` ele :
15 Un mot de deux octets : 0 87 1 0

Bits de poids fort (MSB) : 15 Bits de poids faible (LSB) : 0 "Big endian" ... A+1 A octet 1 octet 0 HP (hppa), Sun (sparc) Ibm, Apple (ppc) Motorola (68k) "Little endian" ... octet 0 octet 1 Intel(i386) Digital(vax) Croissance des adresses mmoire

gure IV.02 Big endian vs Little endian

Le lecteur ayant un acc` es aux sources dune pile IP pourra aller consulter directement la structure de len-t ete, par exemple le chier /usr/src/sys/netinet/ip.h sur une machine FreeBSD
1

Description de len-t ete Les termes Big endian et Little endian indiquent quelle est la terminaison ( end ) de deux octets que lon ecrit en premier le poids fort ( big ), cest aussi le sens de l ecriture humaine, ou le poids faible ( little ).

49

1.3

Description de len-t ete

VERS 4 bits qui sp ecient la version du protocol IP. Lobjet de ce champ est la v erication que l emetteur et le destinataire des datagrammes sont bien en phases avec la m eme version. Actuellement cest la version 4 qui est principalement utilis e sur lInternet, bien que quelques impl ementations de la version 6 existent et soient d ej` a en exp erimentation2 . HLEN 4bits qui donnent la longueur de len-t ete en mots de 4 octets. La taille standard de cette en-t ete fait 5 mots, la taille maximale fait : (23 + 22 + 21 + 20 ) 4 = 60 octets3 TOTAL LENGTH Donne la taille du datagramme, en-t ete plus donn ees. Sil y fragmentation (voir plus loin) il sagit egalement de la taille du fragment (chaque datagramme est ind ependant des autres). La taille des donn ees est donc ` a calculer par soustraction de la taille de len-t ete. 16 bits autorisent la valeur 65535. . .La limitation vient le plus souvent du support physique (MTU) qui impose une taille plus petite, sauf sur les liaisons de type hyperchannel . TYPE OF SERVICE vs DSCP/ECN Historiquement dans la RFC 791 ce champ est nomm e TYPE OF SERVICE et joue potentiellement deux r oles selon les bits examin es (pr es eance et type de service). Pratiquement, la pr es eance ne sert plus et la RFC 1349 d enit 4 bits utiles sur les huit (3 ` a 6). Ceux-ci indiquent au routeur lattitude ` a avoir vis ` a vis du datagramme. Par exemple, des datagrammes dun transfert de chier (ftp) peuvent avoir ` a laisser passer un datagramme rep er e comme contenant des caract` eres frapp es au clavier (session telnet). 0x00 0x10 0x08 0x04 0x02 Service normal Transfert banal bit 3,D Minimiser le d elai Session telnet bit 4,T Maximiser le d ebit Transfert ftp bit 5,R Maximiser la qualit e ICMP bit 6,C Minimiser le co ut news (nntp)

Lusage de ces bits est mutuellement exclusif. Les nouveaux besoins de routage on conduit lIETF a revoir la d enition de ce champ dans la RFC 3168. Celle ci partage les huit bits en deux parties, les premiers bits d enissent le DSCP ou Dierentiated Services CodePoints qui est une version beaucoup plus ne des quatre
2 3

Nous examinerons les caract eristiques de la version 6 dIP ` a la n de ce cycle de cours On encore plus simple (24 1) 4

50

Protocole IP bits ci-dessus. Les deux derniers bits d enissent lECN ou Explicit Congestion Notication qui est un m ecanisme permettant de pr evenir les congestions, contrairement au m ecanisme plus ancien bas e sur les messages ICMP de type source quench (voir page 61) qui tente de r egler le ux en cas de congestion. Il faut noter que les protocoles de routage qui tiennent compte de l etat des liaisons (OSPF,IS-IS. . .) sont susceptibles dutiliser ce champ. Enn la RFC 3168 indique que ces deux ecritures du champ ne sont pas compatibles entre elles. . . IDENTIFICATION, FLAGS et FRAGMENT OFFSET Ces mots sont pr evus pour contr oler la fragmentation des datagrammes. Les donn ees sont fragment ees car les datagrammes peuvent avoir ` a traverser des r eseaux avec des MTU plus petits que celui du premier support physique employ e. Consulter la section suivante Fragmentation IP. TTL Time To Live 8 bits, 255 secondes maximum de temps de vie pour un datagramme sur le net. Pr evu ` a lorigine pour d ecompter un temps, ce champ nest quun compteur d ecr ement e dune unit e` a chaque passage dans un routeur. Couramment la valeur de d epart est 32 ou m eme 64. Son objet est d eviter la pr esence de paquets fant omes circulant ind eniment. . . Si un routeur passe le compteur ` a z ero avant d elivrance du datagramme, e un message derreur ICMP (consultez le paragraphe 4) est renvoy ` a l emetteur avec lindication du routeur. Le paquet en lui-m eme est perdu. PROTOCOL 8 bits pour identier le format et le contenu des donn ees, un peu comme le champ type dune trame Ethernet. Il permet ` a IP dadresser les donn ees extraites ` a lune ou lautre des couches de transport. Dans le cadre de ce cours, nous utiliserons essentiellement ICMP(1), IGMP(2), IP-ENCAP(4), TCP(6), UDP(17), ESP(50), AH(51), et OSPF(89). La table de correspondance entre le symbole et le num ero du protocole est pr esente sur tout syst` eme dexploitation digne de ce nom, dans le chier /etc/protocols. HEADER CHECKSUM 16 bits pour sassurer de lint egrit e de len-t ete. Lors du calcul de ce checksum ce champ est ` a 0. A la r eception de chaque paquet, la couche calcule cette valeur, si elle ne correspond pas ` a celle trouv ee dans len-t ete le datagramme est oubli e ( discard ) sans message derreur. SOURCE ADDRESS Adresse IP de l emetteur, ` a lorigine du datagramme. DESTINATION ADDRESS Adresse IP du destinataire du datagramme. IP OPTIONS 24 bits pour pr eciser des options de comportement des couches IP travers ees et destinatrices. Les options les plus courantes concernent :

Description de len-t ete Des probl` emes de s ecurit e Des enregistrements de routes Des enregistrements dheure Des sp ecications de route ` a suivre ... Historiquement ces options ont et e pr evues d` es le d ebut mais leur impl ementation na pas et e termin ee et la plupart des routeurs ltrants bloquent les datagrammes IP comportant des options. PADDING Remplissage pour aligner sur 32 bits. . . En conclusion partielle que peut-on dire du travail de la couche IP ? 1. Il consiste ` a router les datagrammes en les acheminant au mieux , on verra plus loin de quelle mani` ere. Cest son travail principal. 2. Il peut avoir ` a fragmenter les donn ees de taille sup erieure au MTU du support physique ` a employer.

51

52

Protocole IP

1.4

Fragmentation IP - MTU

La couche de liaison (Couche 2 Link ) impose une taille limite, le Maximum Transfer Unit . Par exemple cette valeur est de 1500 pour une trame Ethernet, elle peut etre de 256 avec SLIP ( Serial Line IP ) sur liaison s erie (RS232. . .). Dans ces conditions, si la couche IP doit transmettre un bloc de donn ees de taille sup erieure au MTU ` a employer, il y a fragmentation ! Par exemple, un bloc de 1481 octets sur Ethernet sera d ecompos e en un datagramme de 1480 (1480 + 20 = 1500) et un datagramme de 1 octet ! Il existe une exception ` a cette op eration, due ` a la pr esence active du bit Dont Fragment bit du champ FLAGS de len-t ete IP. La pr esence ` a 1 de ce bit interdit la fragmentation dudit datagramme par la couche IP qui en aurait besoin. Cest une situation de blocage, la couche emettrice est tenue au courant par un message ICMP (cf paragraphe 4 page 59) Fragmentation needed but dont fragment bit set et bien s ur le datagramme nest pas transmis plus loin.

G1

802.2 (1492) X25 (256)

G2

Ethernet (1500)

gure IV.03 Fragmentation IP 1.4.1 Fragmentation

Quand un datagramme est fragment e, il nest r eassembl e que par la couche IP destinatrice nale. Cela implique trois remarques : 1. La taille des datagrammes re cus par le destinataire nal est directement d ependante du plus petit MTU rencontr e. 2. Les fragments deviennent des datagrammes ` a part enti` ere. 3. Rien ne soppose ` a ce quun fragment soit ` a nouveau fragment e. Cette op eration est absolument transparente pour les couches de transport qui utilisent IP.

Fragmentation IP - MTU Quand un datagramme est fragment e, chaque fragment comporte la m eme valeur de champ IDENTIFICATION que le datagramme initial. Sil y a encore des fragments, un des bits du champ FLAGS est positionn e ` a 1 pour indiquer More fragment ! Ce champ a une longueur de 3 bits. FRAGMENT OFFSET contient loset du fragment, relativement au datagramme initial. Cet oset est cod e sur 13 bits.
Offset : donnes transmises Ce qui reste transmettre

53

Le fragment transmettre

gure IV.04 Fragment ` a transmettre Pour tous les fragments : Les donn ees doivent faire un multiple de 8 octets, sauf pour le dernier fragment, evidement. Le champ TOTAL LENGTH change. Chaque fragment est un datagramme ind ependant, susceptible d etre ` a son tour fragment e. Pour le dernier fragment : FLAGS est remis ` a z ero. Les donn ees ont une taille quelconque.

1.4.2

R eassemblage

Tous les datagrammes issus dune fragmentation deviennent des datagrammes IP comme (presque) les autres. Ils arrivent ` a destination, peut etre dans le d esordre, dupliqu es. IP doit faire le tri. il y a susamment dinformation dans len-t ete pour r eassembler les fragments epars. Mais si un fragment manque, la totalit e du datagramme est perdu car aucun m ecanisme de contr ole nest impl ement e pour cela dans IP. Cest la raison principale pour laquelle il faut absolument eviter de fragmenter un datagramme IP ! La gure IV.05 r esume lop eration de fragmentation dun datagramme IP.

54
Datagramme initial
H 0 N multiple entier de 8 N1 N H1

Protocole IP

5 datagrammes diffrents
H2 H3 H4 H5

2N

3N

4N

M, reste de la division entire de L par 8.

L octets transmettre

esum e de la fragmentation gure IV.05 R

IDENTIFICATION FLAG OFFSET TOTAL LENGTH HEADER CHECKSUM

H1 I MF 0 H +N C1

H2 I MF N H +N C2

H3 I MF 2N H +N C3

H4 I MF 3N H +N C4

H5 I 0 4N H +M C5

Notez les variations de certains champs de len-t ete : 1. IDENTIFICATION est le m eme pour tous 2. FLAG est 0 pour le dernier datagramme 3. OFFSET cro t de la taille du fragment, ici N. 4. TOTAL LENGTH est g en eralement di erent pour le dernier fragment, sauf cas particulier. 5. HEADER CHECKSUM change ` a chaque fois car lOFFSET change (rappel : il ne tient pas compte des donn ees).

2 Protocole ARP

55

Protocole ARP

ARP est lacronyme de Address Resolution Protocol , il est d enie dans la RFC 826. Le probl` eme ` a r esoudre est issu de la constatation quune adresse IP na de sens que pour la suite de protocole TCP/IP ; celle-ci etant ind ependante de la partie mat erielle il faut avoir un moyen d etablir un lien entre ces deux constituants. La norme Ethernet (vs IEEE) suppose lidentication unique de chaque carte construite et vendue4 . Sur une m eme liaison physique (lire plus loin m eme LAN ), Ethernet par exemple, deux machines peuvent communiquer elles connaissent leurs adresses physiques respectives. On suppose quune machine connait sa propre adresse physique par un moyen qui nest pas d ecrit ici (ne fait pas partie du protocole). Remarque importante : Cette information na pas de sens dans le cadre dune liaison de type point ` a point avec un protocole tel que ppp. Lors du premier echange entre 2 machines dun m eme LAN, si les adresses physiques ne sont pas d ej` a connues (on verra pourquoi plus loin), la solution ` a ce probl` eme passe par lusage du protocole ARP. Lusage de ARP est compl` etement transparent pour lutilisateur.

2.1

Fonctionnement
A demande toutes les stations : tant donn ladresse IP de B, que vaut son adresse physique ?

Broadcast Ethernet (vs IEEE)

gure IV.06 Question ARP Sur la gure IV.06 la station Ethernet A (IA , PA ) a besoin de connaitre ladresse physique de la station Ethernet B (IB , PB ), pour ce faire elle envoie un datagramme de format sp ecial (cf paragraphe suivant), d edi e` a ARP, qui lui permet de poser la question ( Arp question ) ` a lensemble des machines actives. Ladresse de la machine qui doit r epondre etant lobjet de la question, son adresse (champ destinataire) est donc remplac ee par une adresse de broadcast (48 bits ` a 1). Toutes les machines du LAN ecoutent cet echange et peuvent mettre ` a jour leur table de conversion (adresse IP adresse Ethernet) pour la machine A.
4

cf chapitre I R eseaux locaux

56

Protocole IP Le broadcast , co uteux en bande passante, est ainsi utilis e au maximum de ses possibilit es. Sur la gure IV.07 la r eponse de B est du type unicast . Remarque : quand une station Ethernet ne r epond plus (cf ICMP) il y a suppression de lassociation adresse IP - adresse MAC.

Rponse unicast.

B rpond directement A en lui communiquant son adresse physique.

gure IV.07 R eponse ARP

Si la station B ne r epond pas, la station continuera ` a poser la question ` a intervals r eguliers pendant un temps inni. . . Il nest pas besoin dutiliser ARP pr ealablement ` a chaque echange, car heureusement le r esultat est m emoris e. En r` egle g en erale la dur ee de vie dune adresse en m emoire est de lordre de 20 minutes et chaque utilisation remet ` a jour ce compteur. La commande arp -a sous Unix permet davoir le contenu de la table de la machine sur laquelle on se trouve, par exemple :

$ arp -a soupirs.chezmoi.fr espoirs.chezmoi.fr plethore.chezmoi.fr byzance.chezmoi.fr ramidus.chezmoi.fr desiree.chezmoi.fr pythie.chezmoi.fr ramidus.chezmoi.fr gateway.chezmoi.fr

(192.168.192.10) (192.168.192.11) (192.168.192.12) (192.168.192.13) (192.168.192.14) (192.168.192.33) (192.168.192.34) (192.168.192.35) (192.168.192.36)

at at at at at at at at at

8:0:9:85:76:9c 8:0:9:85:76:bd 8:0:9:a:f9:aa 8:0:9:a:f9:bc 0:4f:49:1:28:22 permanent 8:0:9:70:44:52 0:20:af:2f:8f:f1 0:4f:49:1:36:50 permanent 0:60:8c:81:d5:1b

Enn, et cest un point tr` es important, du fait de lutilisation de broadcast physiques, les messages ARP ne franchissent pas les routeurs. Il existe cependant un cas particulier : le proxy ARP, que nous evoquerons succintement ` a la n de ce paragraphe.

Protocole ARP

57

2.2

Format du datagramme
31 HARDWARE TYPE 16 15 PROTOCOL TYPE 0

HLEN 1

HLEN 2

OPERATION

SENDER HA (0 3)

SENDER HA (4,5) SENDER ADR (2,3)

SENDER ADR (0,1)

TARGET HA (0,1)

TARGET HA (2 5)

TARGET ADR (0 3)

gure IV.08 Datagramme ARP Le datagramme ci-dessus est encapsul e dans une trame physique du type 5 0x0806 . HARDWARE TYPE pour sp ecier le type dadresse physique dans les champs SENDER HA et TARGET HA, cest 1 pour Ethernet. PROTOCOL TYPE pour sp ecier le type dadresse logique dans les champs SENDER ADR et TARGET ADR, cest 0x0800 (m eme valeur que dans la trame Ethernet) pour des adresses IP. HLEN 1 pour sp ecier la longueur de ladresse physique (6 octets pour Ethernet). HLEN 2 pour sp ecier la longueur de ladresse logique (4 octets pour IP). OPERATION ce champ pr ecise le type de lop eration, il est n ecessaire car la trame est la m eme pour toutes les op erations des deux protocoles qui lutilisent. Question R eponse 1 2 3 4

ARP RARP

SENDER HA adresse physique de l emetteur SENDER ADR adresse logique de l emetteur TARGET HA adresse physique du destinataire TARGET ADR adresse logique du destinataire
5

voir ou revoir la gure II.02 du chapitre dintroduction ` a IP (page 25)

58

Protocole IP

2.3

Proxy ARP

Le proxy ARP permet lextension du lan ` a des h otes qui ne lui sont pas directement physiquement reli es, mais qui sy rattachent par exemple au travers dune passerelle. Un exemple tr` es courant est celui dun h ote qui acc` ede ` a un r eseau via un dialup (rtc, num eris,. . .). Le NetID de son adresse IP peut alors etre le m eme que celui du r eseau rejoint, comme sil y etait physiquement raccord e. Ce subterfuge est rendu possible apr` es conguration ad equate de la passerelle de raccordement.

Protocole RARP

RARP est lacronyme de Reverse Address Resolution Protocol , il est d eni dans la RFC 903 (BOOTP et DHCP en sont des alternatives avec plus de possibilit es). Normalement une machine qui d emarre obtient son adresse IP par lecture dun chier sur son disque dur (ou depuis sa conguration g ee dans une m emoire non volatile). Pour certains equipements cette op eration nest pas possible voire m eme non souhait ee par ladministrateur du r eseau : Terminaux X Windows Stations de travail diskless Imprimante en r eseau Boites noires sans capacit e autonome de d emarrage PC en r eseau ... Pour communiquer en TCP/IP une machine a besoin dau moins une adresse IP, lid ee de ce protocole est de la demander au r eseau. Le protocole RARP est adapt e de ARP : l emetteur envoie une requ ete RARP sp eciant son adresse physique dans un datagramme de m eme format que celui de ARP et avec une adresse de broadcast physique. Le champ OPERATION contient alors le code de RARP question Toutes les stations en activit e re coivent la requ ete, celles qui sont habilit es ` a r epondre (serveurs RARP) compl` etent le datagramme et le renvoient directement ( unicast ) ` a l emetteur de la requ ete puisquelle connaissent son adresse physique. Sur une machine Unix congur ee en serveur RARP les correspondances entres adresses IP et adresses physiques sont enregistr ees dans un chier nomm e g en eralement /etc/bootptab.

4 Protocole ICMP

59

Protocole ICMP

ICMP est lacronyme de Internet Control Message Protocol , il est historiquement d eni dans la RFC 950. Nous avons vu que le protocole IP ne v erie pas si les paquets emis sont arriv es ` a leur destinataire dans de bonnes conditions. Les paquets circulent dune passerelle vers un autre jusqu` a en trouver une qui puisse les d elivrer directement ` a un h ote. Si une passerelle ne peut router ou d elivrer directement un paquet ou si un evenement anormal arrive sur le r eseau comme un trac trop important ou une machine indisponible, il faut pouvoir en informer lh ote qui a emis le paquet. Celui-ci pourra alors r eagir en fonction du type de probl` eme rencontr e. ICMP est un m ecanisme de contr ole des erreurs au niveau IP, mais la gure II.02 du chapitre dintroduction ` a IP (page 25) montre que le niveau Application peut egalement avoir un acc` es direct ` a ce protocole.

4.1

Le syst` eme de messages derreur

Dans le syst` eme que nous avons d ecrit, chaque passerelle et chaque h ote op` ere de mani` ere autonome, route et d elivre les datagrammes qui arrivent sans coordination avec l emetteur. Le syst` eme fonctionne parfaitement si toutes les machines sont en ordre de marche et si toutes les tables de routage sont ` a jour. Malheureusement cest une situation id eale. . . Il peut y avoir des rupture de lignes de communication, des machines peuvent etre ` a larr et, en pannes, d econnect ees du r eseau ou incapables de router les paquets parcequen surcharge. Des paquets IP peuvent alors ne pas etre d elivr es ` a leur destinataire et le protocol IP lui-m eme ne contient rien qui puisse permettre de d etecter cet echec de transmission. Cest pourquoi est ajout e syst ematiquement un m ecanisme de gestion des erreurs connu sous le doux nom de ICMP. Il fait partie de la couche IP6 et porte le num ero de protocole 1. Ainsi, quand un message derreur arrive pour un paquet emis, cest la couche IP elle-m eme qui g` ere le probl` eme, la plupart des cas sans en informer les couches sup erieures (certaines applications utilisent ICMP7 ). Initialement pr evu pour permettre aux passerelles dinformer les h otes sur des erreurs de transmission, ICMP nest pas restreint aux echanges passerellesh otes, des echanges entres h otes sont tout ` a fait possibles. Le m eme m ecanisme est valable pour les deux types d echanges.

6 7

voir ou revoir la gure II.02 du chapitre dintroduction ` a IP (page 25) M eme gure quau point pr ec edent

60

Protocole IP

4.2

Format des messages ICMP

Chaque message ICMP traverse le r eseau dans la partie DATA dun datagramme IP :
Entete IP Message ICMP

gure IV.09 Message ICMP La cons equence directe est que les messages ICMP sont rout es comme les autres paquets IP au travers le r eseau. Il y a toutefois une exception : il peut arriver quun paquet derreur rencontre lui-m eme un probl` eme de transmission, dans ce cas on ne g en` ere pas derreur sur lerreur ! Il est important de bien voir que puisque les messages ICMP sont encapsul es dans un datagramme IP, ICMP nest pas consid er e comme un protocole de niveau plus elev e. La raison de lutilisation dIP pour d elivrer de telles informations, est que les messages peuvent avoir ` a traverser plusieurs r eseaux avant darriver ` a leur destination nale. Il n etait donc pas possible de rester au niveau physique du r eseau (` a linverse de ARP ou RARP). La gure IV.10 d ecrit le format du message ICMP :
31 TYPE 24 23 CODE 16 15 CHECKSUM 0

ENTETE du message original

..

gure IV.10 Format dun message ICMP Chaque message ICMP a un type particulier qui caract erise le probl` eme quil signale. Un en-t ete de 32 bits est compos e comme suit : TYPE contient le code derreur. CODE compl` ete linformation du champ pr ec edent. CHECKSUM est utilis e avec le m eme m ecanisme de v erication que pour les datagrammes IP mais ici il ne porte que sur le message ICMP (rappel : le checksum de len-t ete IP ne porte que sur son en-t ete et non sur les donn ees v ehicul ees). En addition, les messages ICMP donnent toujours len-t ete IP et les 64 premiers bits (les deux premiers mots de quatre octets) du datagramme qui est ` a lorigine du probl` eme, pour permettre au destinataire du message didentier quel paquet est ` a lorigine du probl` eme.

Protocole ICMP

61

4.3

Quelques types de messages ICMP

Ce paragraphe examine quelques uns des principaux types de messages ICMP, ceux qui sont le plus utilis es. Il existe onze valeurs de TYPE di erentes. Echo Request (8), Echo reply (0) Une machine envoie un message ICMP echo request pour tester si son destinataire est accessible. Nimporte quelle machine qui re coit une telle requ ete doit formuler un 8 message ICMP echo reply en retour Ce m ecanisme est extr emement utile, la plupart des impl ementations le propose sous forme dun utilitaire (ping sous Unix).
Echo request(8) IP

IP A

Echo reply(0) B Y

gure IV.11 Echo request vs Echo reply Destination Unreachable (3) Quand une passerelle ne peut pas d elivrer un datagramme IP, elle envoie un message ICMP destination unreachable ` a l emetteur. Dans ce cas le champ CODE compl` ete le message derreur avec : 0 Network unreachable 1 Host unreachable 2 Protocol unreachable 3 Port unreachable 4 Fragmentation needed and DF set 5 Source route failed Source Quench (4) Quand un datagramme IP arrive trop vite pour une passerelle ou un h ote, il est rejet e. Un paquet arrive trop vite quand la machine qui doit le lire est congestionn ee, trop de trac ` a suivre.. . . Dans ce cas la machine en question envoie un paquet ICMP source quench qui est interpr et e de la fa con suivante : L emetteur ralenti le rythme denvoi de ses paquets jusqu` a ce quil cesse de recevoir ce message derreur. La vitesse est donc ajust ee par une sorte dapprentissage rustique. Puis graduellement il augmente le d ebit, aussi longtemps que le message source quench ne revient pas .
8

Pour des raisons de s ecurit e certaines machines peuvent ne pas r epondre.

62

Protocole IP Ce type de paquet ICMP a donc tendance ` a vouloir r eguler le ux des datagrammes au niveau IP alors que cest une fonctionnalit e de la couche de transport (TCP). Cest donc une s erieuse entorse ` a la r` egle dind ependance des couches. Redirect (5) Les tables de routage (Voir le paragraphe 6) des stations restent assez statiques durant de longues p eriodes. Le syst` eme dexploitation les lit au d emarrage sur le syst` eme de chiers et ladministrateur en change de temps en temps les el ements. Si entre deux modications une destination change demplacement, la donn ee initiale dans la table de routage peut sav erer incorrecte. Les passerelles connaissent de bien meilleures routes que les h otes euxm emes, ainsi quand une passerelle d etecte une erreur de routage, elle fait deux choses : 1. Elle envoie ` a l emetteur du paquet un message ICMP redirect 2. Elle redirige le paquet vers la bonne destination. Cette redirection ne r` egle pas les probl` emes de routage car elle est limit ee aux interactions entres passerelles et h otes directement connect es. La propagation des routes aux travers des r eseaux multiples est un autre probl` eme. Le champ CODE du message ICMP peut avoir les valeurs suivantes : 0 Redirect datagram for the Net 1 Redirect datagram for the host 2 ... Router solicitation (10) vs Router advertisement (9) Il sagit dobtenir ou dannoncer des routes, nous verrons cela plus en d etail dans le paragraphe 6.4. Time exceeded (11) Chaque datagramme contient un champ TTL dit TIME TO LIVE appell e aussi hop count . An de pr evenir le cas ou un paquet circulerait ` a linni dune passerelle ` a une autre, chaque passerelle d ecr emente ce compteur et rejette le paquet quand le compteur arrive ` a z ero et envoie un message ICMP ` a l emetteur pour le tenir au courant.

5 Protocole IGMP

63

Protocole IGMP

IGMP, lacronyme de Internet Group Management Protocol , est historiquement d eni dans lAnnexe I de la RFC 1112. Sa raison d etre est que les datagrammes ayant une adresse multicast9 sont ` a destination dun groupe dutilisateurs dont l emetteur ne connait ni le nombre ni lemplacement. Lusage du multicast etant par construction d edi e 10 aux applications comme la radio ou la vid eo sur le r eseau , donc consommatrices de bande passante, il est primordial que les routeurs aient un moyen de savoir sil y a des utilisateurs de tel ou tel groupe sur les LANs directement accessibles pour ne pas encombrer les bandes passantes associ ees avec des ux doctets que personne nutilise plus !

5.1

Description de len-t ete

IGMP est un protocole de communication entre les routeurs susceptibles de transmettre des datagrammes multicast et des h otes qui veulent senregistrer dans tel ou tel groupe. IGMP est encapsul e dans IP11 avec le protocole num ero 2. Comme le montre la gure Romanchapter.12, sa taille est xe (contrairement ` a ICMP) : seulement 2 mots de 4 octets.
31 28 27 24 23 16 15 0

Vers. Type

Inutilis

Checksum sur 16 bits

Adresse du groupe sur 32 bits

gure IV.12 En-t ete IGMP Version Version 1. Type Ce champ prend deux valeurs, 1 pour dire quil sagit dune question (query dun routeur), 2 pour dire quil sagit de la r eponse dun h ote. Inutilis e ... Checksum Le checksum est calcul e comme celui dICMP. Adresse Cest ladresse multicast (classe D) ` a laquelle appartient lh ote qui r epond.

Voir page 42 La premi` ere exp erience ` a grande echelle du multicast fut sans doute la conf erence de lIETF en mars 1992. Le papier ftp ://venera.isi.edu/ietf-audiocast-article.ps relate cette exp erience. 11 voir ou revoir la gure II.02 du chapitre I dintroduction ` a IP (page 25)
10

64

Protocole IP

5.2

Fonctionnement du protocole

La RFC 1112 pr ecise que les routeurs multicast envoient des messages de questionnement (Type=Queries) pour reconna tre quels sont les eventuels h otes appartenant ` a quel groupe. Ces questions sont envoy ees ` a tous les h otes des LANs directement raccord es ` a laide de ladresse multicast du groupe 12 224.0.0.1 encapsul e dans un datagramme IP ayant un champ TTL=1. Tous les h otes susceptibles de joindre un groupe multicast ecoutent ce groupe par hypoth` ese. Les h otes, dont les interfaces ont et e correctement congur ees, r epondent ` a une question par autant de r eponses que de groupes auxquels ils appartiennent sur linterface r eseau qui a re cu la question. An d eviter une temp ete de r eponses chaque h ote met en uvre la strat egie suivante : 1. Un h ote ne r epond pas imm ediatement ` a la question re cue. Pour chaque groupe auquel il appartient, il attend un d elais compris entre 0 et 10 secondes, calcul e al eatoirement ` a partir de ladresse IP unicast de linterface qui a re cu la question, avant de renvoyer sa r eponse. La gure Romanchapter.13 montre un tel echange, remarquez au passage la valeur des adresses. 2. La r eponse envoy ee est ecout ee par tous les membres du groupe appartenant au m eme LAN. Tout ceux qui sappr etaient ` a envoyer une telle r eponse au serveur en interrompent le processus pour eviter une redite. Le routeur ne re coit ainsi quune seule r eponse pour chaque groupe, et pour chaque LAN, ce qui lui sut pour justier le routage demand e.
Type= Report TTL=1 Src=IP A Groupe=Adr. groupe M. Dst=Adr. groupe M.

TTL=1 Src= IPG Dst=224.0.0.1 IP

Type=Query Groupe=0.0.0.0 IGMP G

gure IV.13 Fonctionnement IGMP Il y a deux exceptions ` a la strat egie ci-dessus. La premi` ere est que si une question est re cue alors que le compte ` a rebours pour r epondre ` a une r eponse est en cours, il nest pas interrompu. La deuxi` eme est quil ny a jamais de d elai appliqu e pour lenvoi de datagramme portant ladresse du groupe de base 224.0.0.1. Pour rafra chir leur connaissance des besoins de routage les routeurs envoient leurs questions avec une fr equence tr` es faible de lordre de la minute,
12

tous les h otes du LAN

Protocole IGMP an de pr eserver au maximum la bande passante du r eseau. Si aucune r eponse ne leur parvient pour tel ou tel groupe demand e pr ec edement, le routage sinterrompt. Quand un h ote rejoint un groupe, il envoie imm ediatement une r eponse (type=report) pour le groupe (les) qui lint eresse, plut ot que dattendre une question du routeur. Au cas o` u cette r eponse se perdrait il est recommand e deectuer une r e emission dans un court d elai. Remarques : 1. Sur un LAN sans routeur pour le multicast, le seul trac IGMP est celui des h otes demandant ` a rejoindre tel ou tel groupe. 2. Il ny a pas de report pour quitter un groupe. 3. La plage dadresses multicast entre 224.0.0.0 et 224.0.0.225 est d edi ee aux applications utilisant une valeur de 1 pour le champ TTL (administration et services au niveau du LAN). Les routeurs ne doivent pas transmettre de tels datagrammes. 4. Il ny a pas de message ICMP sur les datagrammes ayant une adresse de destination du type multicast. En cons equence les applications qui utilisent le multicast (avec une adresse sup erieure ` a 224.0.0.225) pour d ecouvrir des services, doivent avoir une strat egie pour augmenter la valeur du champ TTL en cas de non r eponse.

65

5.3

Fonctionnement du Mbone

Pr ecisions en cours. . .

66

Protocole IP

Routage IP

Ce paragraphe d ecrit de mani` ere succincte le routage des datagrammes. Sur lInternet, ou au sein de toute entit e qui utilise IP, les datagrammes ne sont pas rout es par des machines Unix, mais par des routeurs dont cest la fonction par d enition. Ils sont plus ecaces et plus perfectionn es pour cette t ache par construction, et surtout autorisent lapplication dune politique de routage ( routing policy ) ce que la pile IP standard dune machine Unix ne sait pas faire. Toutefois il est courant dans les petits r eseaux , ou quand le probl` eme ` a r esoudre reste simple, de faire appel ` a une machine Unix pour 13 ce faire . Dans ce paragraphe nous examinons le probl` eme du routage de mani` ere synth etique, nous laborderons plus en d etail les aspects techniques du routage dynamique au chapitre VII, page 109. Le routage des datagrammes se fait au niveau de la couche IP, et cest son travail le plus important. Toutes les machines multiprocessus sont th eoriquement capables deectuer cette op eration. La di erence entre un routeur et un h ote est que le premier est capable de transmettre un datagramme dun interface ` a un autre et pas le deuxi` eme. Cette op eration est d elicate si les machines qui doivent dialoguer sont connect ees ` a de multiples r eseaux physiques. Dun point de vue id eal etablir une route pour des datagrammes devrait tenir compte d el ements comme la charge du r eseau, la taille des datagrammes, le type de service demand e, les d elais de propagation, l etat des liaisons, le trajet le plus court. . . La pratique est plus rudimentaire ! Il sagit de transporter des datagrammes aux travers de multiples r eseaux physiques, donc aux travers de multiples passerelles. On divise le routage en deux grandes familles : Le routage direct Il sagit de d elivrer un datagramme ` a une machine raccord ee au m eme LAN. L emetteur trouve ladresse physique du correspondant (ARP), encapsule le datagramme dans une trame et lenvoie. Le routage indirect Le destinataire nest pas sur le m eme LAN comme pr ec edement. Il est absolument n ecessaire de franchir une passerelle connue davance ou demployer un chemin par d efaut. En eet, toutes les machines ` a atteindre ne sont pas forc ement sur le m eme r eseau physique. Cest le cas le plus courant, par exemple sur lInternet qui regroupe des centaines de milliers de r eseaux di erents. Cette op eration est beaucoup plus d elicate que la pr ec edente car il faut s electionner une passerelle.
On peut consulter par exemple http://www.freebsd.org/$\sim$picobsd/, o` u le site du projet Zebra de GNU http://www.zebra.org/
13

Table de routage IP Parceque le routage est une op eration fondamentalement orient ee r eseau , le routage sappuie sur cette partie de ladresse IP du destinataire. La couche IP d etermine celle-ci en examinant les bits de poids fort qui conditionnent la classe dadresse et donc la segmentation network.host . Dans certain cas (CIDR) le masque de sous r eseau est aussi employ e. Muni de ce num ero de r eseau, la couche IP examine les informations contenues dans sa table de routage :

67

6.1

Table de routage

Sous Unix toutes les op erations de routage se font gr ace ` a une table, dite table de routage , qui se trouve dans le noyau lui-m eme. La gure IV.14 r esume la situation :

Dmons DHCP de routage

Commande route

Commande netstat

ICMP

Algorithme de routage Table de routage

Couche IP

gure IV.14 Table de routage Cette table est tr` es fr equemment utilis ee par IP : sur un serveur plusieurs centaines de fois par secondes. Comment est-elle cr ee ? Au d emarrage avec la commande route, invoqu ee dans les scripts de lancement du syst` eme, et en fonctionnement : Au coup par coup avec la commande route, ` a partir du shell (administrateur syst` eme uniquement). Dynamiquement avec les d emons de routage routed ou gated (la fr equence de mise ` a jour est typiquement de lordre de 30 sec.).

68

Protocole IP Par des messages ICMP redirect . La commande netstat -rn permet de la visualiser au niveau de linterface utilisateur ( Application layer ) : $ netstat -rn Routing tables Internet: Destination default 127.0.0.1 192.168.192/27 192.168.192.10 192.168.192.11 192.168.192.12 192.168.192.13 192.168.192.14 192.168.192.15 192.168.192.32/27 192.168.192.33 192.168.192.34 192.168.192.35 192.168.192.36

Gateway 192.168.192.36 127.0.0.1 link#1 8:0:9:85:76:9c 8:0:9:85:76:bd 8:0:9:88:8e:31 8:0:9:a:f9:bc 0:4f:49:1:28:22 link#1 link#2 8:0:9:70:44:52 0:20:af:2f:8f:f1 0:4f:49:1:36:50 link#2

Flags UGS UH UC UHLW UHLW UHLW UHLW UHLW UHLW UC UHLW UHLW UHLW UHLW

On peut m emoriser cette table comme etant essentiellement compos ee dune colonne origine, dune colonne destination. De plus, chaque route qui d esigne une passerelle (ici la route par d efaut) doit saccompagner dun nombre de sauts ( hop ), ou encore m etrique, qui permet le choix dune route plut ot quune autre en fonction de cette valeur. Chaque franchissement dun routeur compte pour un saut. Dans la table ci-dessus, la m etrique de la route par d efaut est 1. Remarque : la sortie de la commande netstat -rn ci-dessus a et e sim14 pli ee. Les drapeaux ( ags ) les plus courants : C c D G H L M S U W
14

La route est g en er ee par la machine, ` a lusage. La route a et e cr ee dynamiquement (d emons de routage). La route d esigne une passerelle, sinon cest une route directe. La route est vers une machine, sinon elle est vers un r eseau. D esigne la conversion vers une adresse physique (cf ARP). La route a et e modi ee par un redirect . La route a et e ajout ee manuellement. La route est active. La route est le r esultat dun cl onage.

Des colonnes Refs, Use et Netif

Routage statique La gure IV.15 pr ecise larchitecture du r eseau autour de la machine sur laquelle a et e ex ecut e le netstat.

69

Subnet 000

.14 link 1

.35 link 2

Subnet 001

.36

gure IV.15 Situation r eseau lors du netstat

6.2

Routage statique

Comme nous avons pu le deviner au paragraphe pr ec edent, les routes statiques sont celles cr ees au d emarrage de la machine ou ajout ees manuellement par ladministeur syst` eme, en cours de fonctionnement. Le nombre de machines possibles ` a atteindre potentiellement sur lInternet est beaucoup trop elev e pour que chaque machine puisse esp erer en conserver ladresse, qui plus est, m eme si cela etait concevable, cette information ne serait jamais ` a jour donc inutilisable. Plut ot que denvisager la situation pr ec edente on pr ef` ere restreindre l etendue du monde connu et utiliser la strat egie de proche en proche pr ec edement cit ee. Si une machine ne peut pas router un datagramme, elle connait (ou est suppos ee conna tre) ladresse dune passerelle suppos ee etre mieux inform ee pour transmettre ce datagramme. Dans lexemple de sortie de la commande netstat du paragraphe 6.1, on peut reconna tre que ladministrateur syst` eme na congur e quune seule 15 route manuellement , toutes les autres lignes ont et e d eduites par la couche IP elle-m eme. La gure IV.16 met en situation plusieurs r eseaux et les passerelles qui les relient. Voici une version tr` es simpli ee des tables de routage statiques pr esentes sont les machines A, B, R1 et R2 : Machine A default : 192.168.192.251 Machine B default : 10.1.1.1 Routeur R1 10 : 172.16.10.3 Routeur R2 192.168.192 : 172.16.10.1
Ce nest pas tout ` a fait exact, nous verrons pourquoi au paragraphe concernant linterface de loopback (6.6).
15

70
.251 .10.1

Protocole IP

R1

172.16

.10.3 192.168.192

R2 .1.1.1

.1 A B 1.1.23 10

gure IV.16 Exemple de nuage avec routage statique 6.2.1 Algorithme de routage

Cet algorithme simpli e r esume les op erations de la couche IP pour choisir une destination, en fonction de sa table de routage. Cette op eration est essentiellement bas ee sur le num ero de r eseau, IN , extrait de ladresse IP, ID . M d esigne la machine sur laquelle seectue le routage. Si IN est un num ero de r eseau auquel M est directement reli ee : Obtenir ladresse physique de la machine destinatrice Encapsuler le datagramme dans une trame physique et lenvoyer directement. Sinon Si ID apparait comme une machine ` a laquelle une route sp eciale est attribu ee, router le datagramme en fonction. Sinon Si IN apparait dans la table de routage, router le datagramme en fonction. Sinon Sil existe une route par d efaut router le datagramme vers la passerelle ainsi d esign ee. Sinon D eclarer une erreur de routage (ICMP).

Routage dynamique

71

6.3

Routage dynamique

Si la topologie dun r eseau ore la possibilit e de plusieurs routes pour atteindre une m eme destination, sil est vaste et complexe, sujet ` a des changements fr equents de conguration. . .Le routage dynamique est alors un bon moyen dentretenir les tables de routages et de mani` ere automatique. Il existe de nombreux protocoles de routage dynamique dont certains sont aussi anciens que lInternet. N eanmoins tous ne conviennent pas ` a tous les types de probl` eme, il en existe une hi erarchie. Sch ematiquement on peut imaginer lInternet comme une hi erarchie de routeurs. Les routeurs principaux ( core gateways ) de cette architecture utilisent entres-eux des protocoles comme GGP ( Gateway to Gateway Protocol ), lensemble de ces routeurs forment ce que lon nomme l Internet Core . En bordure de ces routeurs principaux se situent les routeurs qui marquent la fronti` ere avec ce que lon nomme les Autonomous systems , cest ` a dire des syst` emes de routeurs et de r eseaux qui poss` edent leurs m ecanismes propres de propagation des routes. Le protocole utilis e par ces routeurs limitrophes est souvent EGP ( Exterior Gateway Protocol ) ou BGP ( Border Gateway Protocol ).
Internet Core

GGP Core Gateway EGP,BGP Core Gateway

RIP,OSPF External gateways

Autonomous System

Autonomous System

gure IV.17 Exemple pour routage dynamique Au sein dun syst` eme autonome on utilise un IGP ( Interior Gateway Protocol ) cest ` a dire un protocole de gateways int erieurs . Les protocoles les plus couramment employ es sont RIP ( Routing Information Protocol ) qui est simple ` a comprendre et ` a utiliser, ou encore OSPF ( Open Shortest Path First ) plus r ecent, plus capable mais aussi beaucoup plus complexe ` a comprendre dans son mode de fonctionnement, ou encore IS-IS de la couche ISO de lOSI.

72 6.3.1 RIP Routing Information Protocol

Protocole IP

RIP est apparu avec la version BSD dUnix, il est document e dans la RFC 1058 (1988 - Version 1 du protocole) et la RFC 1388 (1993 - Version 2 du protocole). Ce protocole est bas e sur des travaux plus anciens men es par la rme Xerox. RIP utilise le concept de vecteur de distance , qui sappuie sur un algorithme de calcul du chemin le plus court dans un graphe. Le graphe est celui des routeurs, la longueur du chemin est etablie en nombre de sauts ( hop ), ou m etrique, entre la source et la destination, cest ` a dire en comptant toutes les liaisons. Cette distance est exprim ee comme un nombre entier variant entre 1 et 15 ; la valeur 16 est consid er ee comme linni et indique une mise ` a l ecart de la route. Chaque routeur emet dans un datagramme portant une adresse IP de broadcast, ` a fr equence xe (environ 30 secondes), le contenu de sa table de routage et ecoute celle des autres routeurs pour compl eter sa propre table. Ainsi se propagent les tables de routes dun bout ` a lautre du r eseau. Pour eviter une temp etes de mises ` a jours , le d elais de 30 secondes est augment e dune valeur al eatoire comprise entre 1 et 5 secondes. Si une route nest pas annonc ee au moins une fois en trois minutes, la distance devient innie , et la route sera retir ee un peu plus tard de la table (elle est propag ee avec cette m etrique). Ladresse IP utilis ee est une adresse de multipoint ( multicast ) comme nous verrons au paragraphe 6.4 Depuis la d enition de RIPv2 les routes peuvent etre accompagn ees du masque de sous r eseau qui les caract erise. Ainsi on peut avoir la situation suivante :

Subnet 192.168.192.224 (netmask 0xFFFFFFE0)

R1 Subnet 192.168.10.0

R2 Subnet 192.168.11.0

R4

R3

Subnet 192.168.192.64 (netmask 0xFFFFFFE0)

gure IV.18 Topologie pour routage dynamique

Apr` es propagation des routes, la table de routage du routeur R1 pourrait bien ressembler ` a:

D ecouverte de routeur et propagation de routes Source 192.168.192.224 192.168.10.0 192.168.11.0 192.168.192.64 Destination R1 R1 R2 R3 Co ut 1 1 2 3

73

Avec une route par d efaut qui est le routeur R2. La constitution de cette table nest possible quavec RIPv2 etant donn e lexistence des deux sousr eseaux de la classe C 192.168.192. Le fonctionnement de ce protocole est d etaill e page 113 6.3.2 OSPF Open Shortest Path First

Contrairement ` a RIP, OSPF nutilise pas de vecteur de distances mais base ses d ecisions de routage sur le concept d etats des liaisons . Celuici permet un usage beaucoup plus n des performances r eelles des r eseaux travers es, parceque cette m etrique est changeante au cours du temps. Si on ajoute ` a cela une m ethode de propagation tr` es rapide des routes par inondation, sans boucle et la possibilit e de chemin multiples, OSPF, bien que beaucoup plus complexe que RIP, a toutes les qualit es pour le remplacer, m eme sur les tous petits r eseaux. OSPF doit son nom ` a lalgorithme dEdsger W. Dijkstra16 de recherche du chemin le plus court dabord lors du parcours dun graphe. Le Open vient du fait quil sagit dun protocole ouvert de lIETF, dans la RFC 2328. . . Le fonctionnement de ce protocole est d etaill e page 121

6.4

D ecouverte de routeur et propagation de routes

Au d emarrage dune station, plut ot que de congurer manuellement les routes statiques, surtout si elle sont susceptibles de changer et que le nombre de stations est grand, il peut etre int eressant de faire de la d ecouverte automatique de routeurs (RFC 1256). ` intervals r A eguliers les routeurs diusent des messages ICMP de type 9 ( router advertisement ) dannonces de routes. Ces messages ont ladresse multicast 224.0.0.1, qui est a destination de tous les h otes du LAN. Toutes les stations capables de comprendre le multicast (et convenablement congur ees pour ce faire) ecoutent ces messages et mettent ` a jour leur table. Les stations qui d emarrent peuvent solliciter les routeurs si lattente est trop longue (environ 7 minutes) avec un autre message ICMP, de type 10 ( router sollicitation ) et avec ladresse multicast 224.0.0.2 (` a destination de tous les routeurs de ce LAN). La r eponse du ou des routeurs est du type unicast , sauf si le routeur sappr etait ` a emettre une annonce.
16

http://www.cs.utexas.edu/users/EWD/

74

Protocole IP ` chaque route est associ A e un niveau de pr ef erence et une dur ee de validit e, d enis par ladministrateur du r eseau. Une validit e nulle indique un routeur qui sarr ete et donc une route qui doit etre supprim ee. Si entre deux annonces une route change, le m ecanisme de ICMP redirect , examin e au paragraphe suivant, corrige lerreur de route. La d ecouverte de routeur nest pas un protocole de routage, son objectif est bien moins ambitieux : obtenir une route par d efaut. Il est int eressant de noter sur les machines FreeBSD cest le d emon de 17 routage routed qui eectue ce travail ` a la demande

6.5

Message ICMP redirect

La table de routage peut etre modi ee dynamiquement par un message ICMP (IV). La situation est celle de la gure IV.21.
Station Datagramme 1 ICMP redirect Datagramme 2 R1 R2

gure IV.21 ICMP redirect La station veut envoyer un datagramme et sa table de routage lui commande dutiliser la route qui passe par le routeur R1. Le routeur R1 re coit le datagramme, scrute sa table de routage et sapper coit quil faut d esormais passer par R2. Pour se faire : 1. Il re-route le datagramme vers R2, ce qui evite quil soit emis deux fois sur le LAN. 2. Il envoie un message ICMP redirect (type 5) ` a la station, lui indiquant la nouvelle route vers R2. Ce travail seectue pour chaque datagramme re cu de la station. D` es que la station re coit le message ICMP redirect elle met ` a jour sa table de routage. La nouvelle route est employ ee pour les datagrammes qui suivent (vers la m eme direction). La route modi ee est visible avec la commande netstat -r, elle gure avec le drapeau M (modication dynamique). Pour des raisons evidentes de s ecurit e, cette possibilit e nest valable que sur un m eme LAN.
17 `

A condition dactiver avec router enable=YES dans le chier /etc/rc.conf.

Interface de loopback

75

6.6

Interface de loopback

Toutes les impl ementations dIP supportent une interface de type loopback . Lobjet de cette interface est de pouvoir utiliser les outils du r eseau en local, sans passer par un interface r eseau r eel (associ e ` a une carte physique). La gure IV.22 ci-contre, montre que la couche IP peut utiliser, selon le routage, linterface standard du r eseau, o` u linterface de loopback. Le routage est ici bien s ur bas e sur ladresse IP associ ee ` a chacune des interfaces. Cette association est eectu ee sur une machine Unix ` a laide de la commande ifconfig, qui etablit une correspondance entre un pilote de p eriph erique (rep er e par son chier sp ecial) et une adresse IP. Dans le cas du pilote de loopback, ladresse est standardis ee ` a nimporte quelle adresse valide du r eseau 127 (page 37).

Internet IP

Rseau

Pilote de "loopback" Pilote de carte rseau Rseau physique

gure IV.22 Interface de

loopback

La valeur courante est 127.0.0.1, do` u lexplication de la ligne ci-dessous d ej` a rencontr ee (page 67) dans le cadre de la table de routage : Routing tables Internet: Destination ... 127.0.0.1 ...

Gateway 127.0.0.1

Flags UH

Netif lo0

Dans toutes les machines Unix modernes cette conguration est d ej` a pr evue dembl ee dans les scripts de d emarrage. Concr` etement, tout dialogue entre outils clients et serveurs sur une m eme machine est possible et m eme souhaitable sur cet interface pour am eliorer les performances et parfois la s ecurit e18 . Lexemple dusage le plus marquant est sans doute celui du serveur de noms (voir page 165) qui tient compte explicitement de cet interface dans sa conguration.

Nous verrons ult erieurement (cf chapitre VIII) que le ltrage IP sur le 127/8 est aussi ais e que sur nimporte quel autre r eseau

18

76

Protocole IP

Finalement, comment ca marche ?

Dans ce paragraphe nous reprenons la gure III.06 (page 44) et nous y apportons comme etait annonc e une explication du fonctionnement qui tienne compte des protocoles principaux examin es dans ce chapitre. Pour cela nous utilisons deux r eseaux priv es de la RFC 1918 : 192.168.10.0 et 192.168.20.0 et nous faisons lhypoth` ese que la passerelle fonctionne comme une machine Unix qui ferait du routage entre deux de ses interfaces !
A Internet R Internet B Internet

Rseau .109 ifA ifR1 .249

Rseau ifR2 .249

Rseau ifB .69

192.168.10.0

192.168.20.0

gure IV.23 Illustration du routage direct et indirect Ce tableau r esume ladressage physique et logique de la situation : Interface ifA ifB ifR1 ifR2 Adresse MAC Adresse IP 08:00:20:20:cf:af 192.168.10.109 00:01:e6:a1:07:64 192.168.20.69 00:06:5b:0f:5a:1f 192.168.10.249 00:06:5b:0f:5a:20 192.168.20.249

Nous faisons en outre les hypoth` eses suivantes : 1. Les caches arp des machines A, B et R sont vides 2. La machine A a connaissance dune route vers le r eseau 192.168.20 passant par 192.168.10.249 et r eciproquement la machine B voit le r eseau 192.168.10.0 via le 192.168.20.249 3. La machine A a connaissance de ladresse IP de la machine B La machine A envoie un datagramme ` a la machine B, que se passe t-il sur le r eseau ? Etape 1 La machine A applique lalgorithme de routage (page 70) et sapper coit que la partie r eseau de ladresse de B nest pas dans le m eme LAN (192.168.10/24 et 192.168.20/20 di` erent). Lhypoth` ese 2 entraine quune route route existe pour atteindre ce r eseau, passant par R. Ladresse IP de R est dans le m eme LAN, A peut donc atteindre R par un routage direct. La cons equence de lhypoth` ese 1 implique que pour atteindre R directement il nous faut dabord d eterminer son adresse physique. Le protocole ARP (page 55) doit etre utilis e.

Finalement, comment ca marche ? A envoie en cons equence une trame ARP (page 57 comportant les el ements suivants : SENDER SENDER TARGET TARGET HA ADR HA ADR 08:00:20:20:cf:af 192.168.10.109 ff:ff:ff:ff:ff:ff 192.168.10.249

77

Avec un champ OPERATION qui contient la valeur 1, comme question ARP . Remarquez quici ladresse IP destination est celle de R ! Etape 2 R r epond ` a la question ARP par une r eponse ARP (OPERATION contient 2) et un champ compl` et e: SENDER SENDER TARGET TARGET HA ADR HA ADR 00:06:5b:0f:5a:1f 192.168.10.249 08:00:20:20:cf:af 192.168.10.109

Etape 3 A est en mesure denvoyer son datagramme ` a B en passant par R. Il sagit de routage indirect puisque ladresse de B nest pas sur le m eme LAN. Les adresses physiques et logiques se r epartissent maintenant comme ceci : IP SOURCE 192.168.10.109 IP TARGET 192.168.20.69 MAC SOURCE 08:00:20:20:cf:af MAC TARGET 00:06:5b:0f:5a:1f Remarquez quici ladresse IP destination est celle de B ! Etape 4 R a re cu le datagramme depuis A et ` a destination de B. Celle-ci est sur un LAN dans lequel R se trouve egalement, un routage direct est donc le moyen de transf errer le datagramme. Pour la m eme raison qu` a l etape 1 R na pas ladresse MAC de B et doit utiliser ARP pour obtenir cette adresse. Voici les el ements de cette question ARP : SENDER SENDER TARGET TARGET HA ADR HA ADR 00:06:5b:0f:5a:20 192.168.20.249 ff:ff:ff:ff:ff:ff 192.168.20.69

Etape 5 Et la r eponse ARP : SENDER SENDER TARGET TARGET HA ADR HA ADR 00:01:e6:a1:07:64 192.168.20.69 00:06:5b:0f:5a:20 192.168.20.249

Etape 6 Enn, dans cette derni` ere etape, R envoie le datagramme en provenance de A, ` aB:

78 IP SOURCE 192.168.10.109 IP TARGET 192.168.20.69 MAC SOURCE 00:06:5b:0f:5a:20 MAC TARGET 00:01:e6:a1:07:64

Protocole IP

Remarque, comparons avec le datagramme de l etape 3. Si les adresses IP nont pas chang e, les adresses MAC, di` erent compl` etement ! Remarque : Si A envoie un deuxi` eme datagramme, les caches ARP ont les adresses MAC utiles et donc les etape 1, 2, 4 et 5 deviennent inutiles. . .

Conclusion sur IP

Apr` es notre tour dhorizon sur IPv4 nous pouvons dire en conclusion que son espace dadressage trop limit e nest pas la seule raison qui a motiv e les travaux de recherche et d eveloppement dIPv6 : 1. Son en-t ete comporte deux probl` emes, la somme de contr ole (checksum) doit etre calcul ee ` a chaque traitement de datagramme, chaque routeur doit analyser le contenu du champ option. 2. Sa conguration n ecessite au moins trois informations que sont ladresse, le masque de sous r eseau et la route par d efaut. 3. Son absence de s ecurit e est insupportable. Issu dun monde ferm e o` u la s ecurit e n etait pas un probl` eme, le datagramme de base nore aucun service de condentialit e, dint egrit e et dauthentication. 4. Son absence de qualit e de service ne r epond pas aux exigences des protocoles applicatifs modernes (t el ephonie, vid eo, jeux interactifs en r eseau, . . .). Le champ TOS nest pas susant et surtout est interpr et e de mani` ere inconsistante par les equipements.

9 Bibliographie

79

Bibliographie

Pour en savoir plus : RFC 791 Internet Protocol. J. Postel. Sep-01-1981. (Format : TXT=97779 bytes) (Obsoletes RFC0760) (Status : STANDARD) RFC 826 Ethernet Address Resolution Protocol : Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware. D.C. Plummer. Nov-01-1982. (Format : TXT=22026 bytes) (Status : STANDARD) RFC 903 Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. Jun-01-1984. (Format : TXT=9345 bytes) (Status : STANDARD) RFC 950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. Aug-01-1985. (Format : TXT=37985 bytes) (Updates RFC0792) (Status : STANDARD) RFC 1112 Host extensions for IP multicasting. S.E. Deering. Aug-011989. (Format : TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status : STANDARD) RFC 1256 ICMP Router Discovery Messages. S. Deering. Sep-01-1991. (Format : TXT=43059 bytes) (Also RFC0792) (Status : PROPOSED STANDARD) W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall Craig Hunt - TCP/IP Network Administration - OReilly & Associates, Inc. Christian Huitema - Le routage dans lInternet - EYROLLES

80

Protocole IP

Chapitre V Protocole UDP

1 UDP User Datagram Protocol

UDP est lacronyme de User Datagram Protocol, il est d eni dans la RFC 768 [Postel 1980]. Les donn ees encapsul ees dans un en-t ete UDP sont des paquets UDP.

1.1

Identication de la destination

Rappel : Au niveau de la couche Internet les datagrammes sont rout es dune machine ` a une autre en fonction des bits de ladresse IP qui identient le num ero de r eseau. Lors de cette op eration aucune distinction nest faite entre les services ou les utilisateurs qui emettent ou recoivent des datagrammes, ie tous les datagrammes sont m elang es. La couche UDP ajoute un m ecanisme qui permet lidentication du service (niveau Application). En eet, il est indispensable de faire un tri entre les divers applications (services) : plusieurs programmes de plusieurs utilisateurs peuvent utiliser simultan ement la m eme couche de transport et il ne doit pas y avoir de confusion entre eux. Pour le syst` eme Unix les programmes sont identi es de mani` ere unique par un num ero de processus, mais ce num ero est eph em` ere, non pr evisible ` a distance, il ne peut servir ` a cette fonction. Lid ee est dassocier la destination ` a la fonction quelle remplie. Cette identication se fait ` a laide dun entier positif que lon baptise port. Le syst` eme dexploitation local a ` a sa charge de d enir le m ecanisme qui permet ` a un processus dacc eder ` a un port. La plupart des syst` emes dexploitation fournissent le moyen dun acc` es synchrone ` a un port. Ce logiciel doit alors assurer la possibilit e de g erer la le dattente des paquets qui arrivent, jusqu` a ce quun processus (Application) les lise. A linverse, lOS, Operating System , bloque un processus qui tente de lire une donn ee non encore disponible. Pour communiquer avec un service distant il faut donc avoir connaissance

82

Protocole UDP de son num ero de port, en plus de ladresse IP de la machine elle-m eme. On peut pr evoir le num ero de port en fonction du service ` a atteindre, cest lobjet du paragraphe 1.3. La gure V.01 explicite la notion de port. La couche IP s epare les data1 grammes SCTP, TCP et UDP gr ace au champ PROTO de son en-t ete, lassociation du protocole de transport et du num ero de port identie un service sans ambigu t e. Conceptuellement on sapper coit alors que rien ne soppose ` a ce quun m eme service (Num ero de port) soit attribu e conjointement aux trois protocoles (en pointill es sur la gure). Cette situation est dailleurs courante dans la r ealit e des serveurs.

Application

Port 1

Port 2

Port 3 Message

Transport

UDP Paquet UDP

TCP

SCTP

Internet

IP

gure V.01 Num ero de port comme num ero de service

Cf description page 47

Description de len-t ete

83

1.2

Description de len-t ete

Un paquet UDP est con cu pour etre encapsul e dans un datagramme IP et permettre un echange de donn ees entre deux applications, sans echange pr eliminaire. Ainsi, si les donn ees ` a transmettre nobligent pas IP ` a fragmenter (cf page 52), un paquet UDP g en` ere un datagramme IP et cest tout !

Header IP

Paquet UDP = donnes dIP

PROTO

= UDP

gure V.02 UDP encapsul e dans IP UDP apporte un m ecanisme de gestion des ports, au dessus de la couche Internet. UDP est simplement une interface au dessus dIP, ainsi l emission des messages se fait-elle sans garantie de bon acheminement. Plus g en eralement, tous les d efauts dIP recens es au chapitre pr ec edent sont applicables ` a UDP. Plus particuli` erement, les paquets ` a destination dune application UDP sont conserv es dans une pile de type FIFO. Si lapplication destinatrice ne les consomme pas assez rapidement, les plus anciens paquets risquent d etre ecras es par les plus r ecents. . .Un risque suppl ementaire (par rapport aux propri et es dIP d ej` a connues) de perte de donn ees. Il ny a aucun retour dinformation au niveau du protocole pour apporter un quelconque moyen de contr ole sur le bon acheminement des donn ees. Cest au niveau applicatif quil convient de prendre en compte cette lacune. UDP est aussi d esign e comme un mode de transport non connect e, ou encore mode datagramme, par opposition ` a TCP ou SCTP que nous examinerons dans les prochains chapitres. Parmis les utilisations les plus courantes dUDP on peut signaler le serveur ees r epartie au niveau mondial, et qui saccomode de noms2 , base de donn tr` es bien de ce mode de transport. En local dautres applications tr` es utiles comme tftp ou nfs sont egalement susceptibles demployer UDP.

DNS RFC 1035 Ce service utilise UDP dans le cas d echanges de petits paquets dinformations ( 512 octets) sinon il utilise TCP

84 La gure V.03 d ecrit la structure de len-t ete.

31 UDP SOURCE PORT MESSAGE LENGTH DATA .... ... 1615

Protocole UDP

0 UDP DESTINATION PORT CHECKSUM

gure V.03 Structure de len-t ete UDP UDP SOURCE PORT Le num ero de port de l emetteur du paquet. Ce champ est optionnel, quand il est sp eci e il indique le num ero de port que le destinataire doit employer pour sa r eponse. La valeur z ero (0) indique quil est inutilis e, le port 0 nest donc pas celui dun service valide. UDP DESTINATION PORT Le num ero de port du destinataire du paquet. MESSAGE LENGTH Cest la longueur du paquet, donc comprennant len-t ete et le message. La longueur minimal est 8 La longueur maximale est 65 535 H (IP ). Dans le cas courant (IP sans option) cette taille maximale est donc de 65 515. CHECKSUM Le checksum est optionnel et toutes les impl ementations ne lutilisent pas. Sil est employ e, il porte sur un pseudo en-t ete constitu e de la mani` ere suivante :
31 87 16 15 Source Address Destination Address zero Protocol UDP length UDP source port UDP destination port UDP length CHECKSUM 24 23 DATA 0

gure V.04 Cas du checksum non nul Ce pseudo en-t ete est pr evu initialement pour apporter une protection en cas de datagrammes mal rout es !

Ports r eserv es disponibles

85

1.3

Ports r eserv es ports disponibles

Le num ero de port est un entier 16 bits non sign e, les bornes sont donc [0, 65535], par construction. Nous avons vu pr ec edement que le port 0 nest pas exploitable en tant que d esignation de service valide, donc le segment r eellement exploitable est [1, 65535]. Toute machine qui utilise la pile TCP/IP se doit de conna tre un certain nombre de services bien connus, rep er es par une s erie de ports bien connus ou well known port numbers, pour pouvoir dialoguer avec les autres machines de lInternet (vs Intranet). Sur une machine Unix, cette liste de services est plac ee dans le chier /etc/services et lisible par tous les utilisateurs et toutes les applications. En eet, comme nous lexaminerons en d etail dans le cours de programmation, un service (comprendre un programme au niveau applicatif) qui d emarre son activit e r eseau (et qui donc est consid er e comme ayant un r ole de serveur) sattribue le (les) num ero(s) de port qui lui revient (reviennent) conform ement ` a cette table. Nom echo echo ftp-data ftp-data ftp ftp ssh ssh smtp smtp domain domain http http pop3 pop3 imap imap https https Port Proto 7 tcp 7 udp 20 tcp 20 udp 21 tcp 21 udp 22 tcp 22 udp 25 tcp 25 udp 53 tcp 53 udp 80 tcp 80 udp 110 tcp 110 udp 143 tcp 143 udp 443 tcp 443 udp Commentaire

#File Transfer [Default Data] #File Transfer [Default Data] #File Transfer [Control] #File Transfer [Control] #Secure Shell Login #Secure Shell Login mail #Simple Mail Transfer mail #Simple Mail Transfer #Domain Name Server #Domain Name Server www www-http #World Wide Web HTTP www www-http #World Wide Web HTTP #Post Office Protocol - Version 3 #Post Office Protocol - Version 3 #Interim Mail Access Protocol #Interim Mail Access Protocol #Secure World Wide Web HTTP #Secure World Wide Web HTTP

Le tableau de la gure V.05 pr esente quelques uns des ports bien connus plus connus les plus utilis es, il y en a quantit e dautres. . . 3 Une autorit e, lIANA , centralise et diuse linformation relative ` a tous
3

Internet Assigned Numbers Authority

86

Protocole UDP les nombres utilis es sur lInternet via une RFC. La derni` ere en date est la RFC 1700, elle fait plus de 200 pages ! Par voie de cons equence cette RFC concerne aussi les num eros de ports. 1.3.1 Attribution des ports ancienne m ethode

Historiquement les ports de 1 ` a 255 sont r eserv es aux services bien connus, plus r ecemment, ce segment ` a et e elargi ` a [1, 1023]. Aucune application ne peut sattribuer durablement et au niveau de lInternet un num ero de port dans ce segment, sans en r ef errer ` a lIANA, qui en contr ole lusage. ` partir de 1024 et jusqu` A a 65535, lIANA se contente denregistrer les demandes dusage et signale les eventuels conits. 1.3.2 Attribution des ports nouvelle m ethode

Devant lexplosion du nombre des services enregistr es lIANA a modi e 4 la segmentation qui pr ec` ede. D esormais les num eros de ports sont class es selon les trois cat egories suivantes : 1. Le segment [1, 1023] est toujours r eserv es aux services bien connus. Les services bien connus sont d esign es par lIANA et sont mis en uvre par des applications qui sex ecutent avec des droits privil egi es (root sur une machine Unix) 2. Le segment [1024, 49151] est celui des services enregistr es. Ils sont enum er es par lIANA et peuvent etre employ es par des processus ayant des droits ordinaires. Par exemple : Nom Port Proto Commentaire bpcd 13782 tcp VERITAS NetBackup bpcd 13782 udp VERITAS NetBackup 3. Le segment [49152, 65535] est celui des attributions dynamiques et des services priv es ; nous en examinerons lusage dans le cours de programmation.

http://www.iana.org/assignments/port-numbers

2 Bibliographie

87

Bibliographie

Pour en savoir plus : RFC 768 User Datagram Protocol. J. Postel. Aug-28-1980. (Format : TXT=5896 bytes) (Status : STANDARD) RFC 1035 Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987. (Format : TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC1065, RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181) (Status : STANDARD) RFC 1700 ASSIGNED NUMBERS. J. Reynolds,J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD) RFC 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE) Sans oublier : W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley 1994 Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall

88

Protocole UDP

Chapitre VI Protocole TCP

1 TCP Transmission Control Protocol

TCP est lacronyme de Transmission Control Protocol , il est d eni dans la RFC 793 [Postel 1981c]. Les donn ees encapsul ees dans un en-t ete TCP sont des paquets TCP .
Header IP Segment TCP = donnes IP

PROTO

= TCP

gure VI.01 TCP encapsul e dans IP

1.1

Caract eristiques de TCP

e au chapitre pr ec edent, il TCP est bien plus compliqu e1 quUDP examin apporte en contrepartie des services beaucoup plus elabor es. Cinq points principaux caract erisent ce protocole : 1. TCP contient un m ecanisme pour assurer le bon acheminement des donn ees. Cette possibilit e est absolument indispensable d` es lors que les applications doivent transmettre de gros volumes de donn ees et de fa con able. Il faut pr eciser que les paquets de donn ees sont acquitt es de bout en bout et non de point en point. Dune mani` ere g en erale le r eseau assure lacheminement et les extr emit es le contr ole (Dave Clark). 2. Le protocole TCP permet l etablissement dun circuit virtuel entre les deux points qui echangent de linformation. On dit aussi que TCP
Une simple comparaison du volume des RFC initiales est parlante : 85 pages pour TCP, 3 pour UDP !
1

90

Protocole TCP fonctionne en mode connect e (par opposition ` a UDP qui est en mode non connect e ou encore mode datagramme). Avant le transfert les 2 applications se mettent en relation avec leurs OS2 respectifs, les informent de leurs d esirs d etablir ou de recevoir une communication. Pratiquement, lune des deux applications doit eectuer un appel que lautre doit accepter. Les protocoles des 2 OS communiquent alors en senvoyant des messages au travers du r eseau pour v erier que le transfert est possible (autoris e) et que les deux applications sont pr etes pour leurs r oles. Une fois ces pr eliminaires etablis, les modules de protocole informent les applications respectives que la connexion est etablie et que le transfert peut d ebuter. Durant le transfert, le dialogue entre les protocoles continue, pour v erier le bon acheminement des donn ees. Conceptuellement, pour etablir une connexion un circuit virtuel il faut avoir r eunis les el ements du quintuplet : Le protocole Cest TCP mais il y pourrait y avoir dautres transports qui assurent le m eme service. . . IP locale Adresse de la machine qui emet. Port local Le num ero de port associ e au processus. Il est impos e ou est d etermin e automatiquement comme nous le verrons dans le cours de programmation. IP distante Adresse de la machine distante. Port distant Le num ero de port associ e au service ` a atteindre. Il est obligatoire de le conna tre pr ecisement. Lensemble de ces cinq el ements d enit un circuit virtuel unique. Que lun deux change et il sagit dune autre connexion ! 3. TCP a la capacit e de m emoriser3 des donn ees : Aux deux extr emit es du circuit virtuel, les applications senvoient des volumes de donn ees absolument quelconques, allant de 0 octet ` a des centaines (ou plus) de Mo. ` la r A eception, le protocole d elivre les octets exactement comme ils ont et e envoy es. Le protocole est libre de fragmenter le ux de donn ees en paquets de tailles adapt ees aux r eseaux travers es. Il lui incombe cependant deectuer le r eassemblage et donc de stocker temporairement les fragments avant de les pr esenter dans le bon ordre ` a lapplication. 4. TCP est ind ependant vis ` a vis des donn ees transport ees, cest un ux doctets non structur e sur lequel il nagit pas.
2 3

Operating System dans un buer

Description de len-t ete 5. TCP simule une connexion en full duplex . Pour chacune des deux applications en connexion par un circuit virtuel, lop eration qui consiste ` a lire des donn ees peut seectuer ind ependamment de celle qui consiste ` a en ecrire. Le protocole autorise la cl oture du ot dans une direction tandis que lautre continue ` a etre active. Le circuit virtuel est rompu quand les deux parties ont clos le ux.

91

1.2

Description de len-t ete

La gure suivante montre la structure dun en-t ete TCP. Sa taille normale est de 20 octets, ` a moins que des options soient pr esentes.
31 19 87 16 15 TCP SOURCE PORT TCP DESTINATION PORT SEQUENCE NUMBER OFF ACKNOWLEDGEMENT NUMBER RESERVED CODE WINDOW CHECKSUM URGENT POINTER OPTIONS PADDING DATA ... 0

gure VI.02 Structure de len-t ete TCP TCP SOURCE PORT Le num ero de port de lapplication locale. TCP DESTINATION PORT Le num ero de port de lapplication distante. SEQUENCE NUMBER Cest un nombre qui identie la position des donn ees ` a transmettre par rapport au segment original. Au d emarrage de chaque connexion, ce champ contient une valeur non nulle et non facilement pr evisible, cest la s equence initiale ou ISN4 TCP num erote chaque octet transmis en incr ementant ce nombre 32 bits non sign e. Il repasse ` a 0 apr` es avoir atteint 232 1 (4 294 967 295). Pour le premier octet des donn ees transmis ce nombre est incr ement e de un, et ainsi de suite. . . ACKNOWLEDGEMENT NUMBER Cest un num ero qui identie la position du dernier octet re cu dans le ux entrant. Il doit saccompagner du drapeau ACK (voir plus loin). OFF pour OFFSET, il sagit dun d eplacement qui permet datteindre les donn ees quand il y a des options. Cod e sur 4 bits, il sagit du nombre de mots de 4 octets qui composent len-t ete. Le d eplacement maximum 4 est donc de 60 octets (2 1 4 octets). Dans le cas dun en-t ete sans option, ce champ porte la valeur 5. 10 mots de 4 octets sont donc possibles pour les options.
4

Initial Sequence Number

92 RESERVED Six bits r eserv es pour un usage futur !

Protocole TCP

CODE Six bits pour inuer sur le comportement de TCP en caract erisant lusage du segment : URG Le champ URGENT POINTER doit etre exploit e. ACK Le champ ACNOWLEDGMENT NUMBER doit etre exploit e. PSH Cest une notication de l emetteur au r ecepteur, pour lui indiquer que toutes les donn ees collect ees doivent etre transmises ` a lapplication sans attendre les eventuelles donn ees qui suivent. RST SYN FIN Re-initialisation de la connexion Le champ SEQUENCE NUMBER contient la valeur de d ebut de connexion. L emetteur du segment a ni d emettre.

En fonctionnement normal un seul bit est activ e` a la fois mais ce nest pas une obligation. La RFC 1024 [Postel 1987] d ecrit lexistence de paquets tcp d enomm es Christmas tree ou paquet kamikaze comprenant les bits SYN+URG+PSH+FIN ! WINDOW Le ux TCP est control e de part et dautre pour les octets compris dans une zone bien d elimit ee et nomm ee fen etre . La taille de celle-ci est d enie par un entier non sign e de 16 bits, qui en limite donc th eoriquement la taille ` a 65 535 octets (ce nest pas compl` etement exact, voir plus loin loption wscale). Chaque partie annonce ainsi la taille de son buer de r eception. Par construction, l emetteur nenvoie pas plus de donn ees que le r ecepteur ne peut en accepter. Cette valeur varie en fonction de la nature du r eseau et surtout de la bande passante devin ee ` a laide de statistiques sur la valeur du RTT. Nous y reviendrons au paragraphe 4. CHECKSUM Un calcul qui porte sur la totalit e du segment, en-t ete et donn ees. URGENT POINTER Ce champ nest valide que si le drapeau URG est arm e. Ce pointeur contient alors un oset ` a ajouter ` a la valeur de SEQUENCE NUMBER du segment en cours pour d elimiter la zone des donn ees urgentes ` a transmettre ` a lapplication. Le m ecanisme de transmission ` a lapplication d epend du syst` eme dexploitation. OPTIONS Cest un param` etrage de TCP. Sa pr esence est d etect ee d` es lors que lOFFSET est sup erieur ` a 5. Les options utilis ees :

Description de len-t ete mss La taille maximale du segment5 des donn ees applicatives que l emetteur accepte de recevoir. Au moment de l etablissement dune connexion (paquet comportant le ag SYN), chaque partie annonce sa taille de MSS. Ce nest pas une n egociation. Pour de lEthernet la valeur est 1460 ( = M T U 2 20). timestamp pour calculer la dur ee dun aller et retour (RTT ou round trip time ). wscale Facteur d echelle ( shift ) pour augmenter la taille de la fen etre au del` a des 16 bits du champ WINDOW (> 65535). Quand cette valeur nest pas nulle, la taille de la fen etre est de 65535 2shif t . Par exemple si shift vaut 1 la taille de la fen etre est de 131072 octets soit encore 128 ko. nop Les options utilisent un nombre quelconque doctets par contre les paquet TCP sont toujours align es sur une taille de mot de quatre octets ; ` a cet eet une option No Operation ou nop, cod ee sur 1 seul octet, est pr evue pour compl eter les mots. PADDING Remplissage pour se caler sur un mot de 32 bits. DATAS Les donn ees transport ees. Cette partie est de longueur nulle ` a l etablissement de la connexion, elle peut egalement etre nulle par choix de lapplication.

93

MSS= Maximum Segment Size

94

Protocole TCP

2
2.1

D ebut et cl oture dune connexion

Etablissement dune connexion

L etablissement dune connexion TCP seectue en trois temps, comme le sch ema de la gure 3 lexplicite.
Emetteur
SYN (seq=x)

Rcepteur

SYN (seq=y) ACK (seq=x+1)

ACK(seq=y+1)

Temps

gure VI.03 Etablissement dune connexion

On suppose que l emetteur du premier paquet avec le bit SYN a connaissance du couple (adresse IP du r ecepteur, num ero de port du service souhait e). L emetteur du premier paquet est ` a lorigine de l etablissement du circuit virtuel, cest une attitude g en eralement quali ee de cliente . On dit aussi que le client eectue une ouverture active (active open). Le r ecepteur du premier paquet accepte l etablissement de la connexion, ce qui suppose quil etait pr et ` a le faire avant que la partie cliente en prenne linitiative. Cest une attitude de serveur . On dit aussi que le serveur eectue une ouverture passive (passive open). 1. Le client envoie un segment comportant le drapeau SYN, avec sa s equence initiale (ISN = x). 2. Le serveur r epond avec sa propre s equence (ISN = y ), mais il doit egalement acquitter le paquet pr ec edent, ce quil fait avec ACK (seq = x + 1). 3. Le client doit acquitter le deuxi` eme segment avec ACK (seq = y + 1).

Cl oture dune connexion Une fois achev ee cette phase nomm ee three-way handshake , les deux applications sont en mesure d echanger les octets qui justient l etablissement de la connexion.

95

2.2
2.2.1

Cl oture dune connexion

Cl oture canonique

Un echange de trois segments est n ecessaire pour l etablissement de la connexion ; il en faut quatre pour quelle sach` eve de mani` ere canonique ( orderly release ).

Emetteur
close FIN (seq=x)

Rcepteur
Envoi dun EOF ACK (seq = x + 1) lapplication

Flux de donnes du rcepteur vers lmetteur FIN (seq = y) Envoi dun EOF lapplication ACK (seq = y + 1) Temps close

Dernier segment de la connexion

gure VI.04 Cl oture dune connexion La raison est quune connexion TCP est full-duplex , ce qui implique que les donn ees circulent ind ependamment dans un sens et dans lautre. Les deux directions doivent donc pouvoir etre interrompues ind ependamment lune de lautre. Lapplication qui envoie un paquet avec le drapeau FIN indique ` a la couche TCP de la machine distante quelle nenverra plus de donn ee. La machine distante doit acquitter ce segment, comme il est indiqu e sur la gure VI.04, en incr ementant dune unit e le sequence number . La connexion est v eritablement termin ee quand les deux applications ont eectu e ce travail. Il y a donc echange de 4 paquets pour terminer la connexion.

96

Protocole TCP Au total, sans compter les echanges propres au transfert des donn ees, les deux couches TCP doivent g erer 7 paquets, il faut en tenir compte lors de la conception des applications ! Sur la gure on constate que le serveur continue denvoyer des donn ees bien que le client ait termin e ses envois. Le serveur a d etect e cette attitude par la r eception dun caract` ere de EOF (en C sous Unix). Cette possibilit e a son utilit e, notamment dans le cas des traitements distants qui doivent saccomplir une fois toutes les donn ees transmises, comme par exemple pour un tri. 2.2.2 Cl oture abrupte

Au lieu dun echange de quatre paquets comme pr ec edement, un m ecanisme de reset est pr evu pour terminer une connexion au plus vite (abortive release). Ce type darr et est typiquement g er e par la couche TCP elle-m eme quand lapplication est brutalement interrompue sans avoir eectu e un appel ` a la primitive close(2), comme par exemple lors dun appel ` a la primitive abort(2), ou apr` es avoir rencontr e une exception non prise en compte ( core dump . . .). Lextremit e qui arr ete brutalement la connexion emet un paquet assorti du bit RST, apr` es avoir (ou non) envoy e les derniers octets en attente6 . Ce paquet cl ot l echange. Il ne re coit aucun acquittement. Lextr emit e qui re coit le paquet de reset (bit RST), transmet les eventuelles derni` eres donn ees ` a lapplication et provoque une sortie derreur du type Connection reset par peer pour la primitive de lecture r eseau. Comme cest le dernier echange, si des donn ees restaient ` a transmettre ` a lapplication qui a envoy e le RST elles peuvent etre d etruites.

Emetteur
RST

Rcepteur

gure VI.05 Emission dun rst

6

Voir dans le cours de programmation, loption SO LINGER

3 Contr ole du transport

97

Contr ole du transport

Le bon acheminement des donn ees applicatives est assur e par un m ecanisme dacquittement des paquets, comme nous avons d ej` a pu lexaminer partiellement au paragraphe pr ec edent.

3.1

M ecanisme de lacquittement
Emetteur
Paquet i Horloge

Rcepteur

RTT

ACK Paquet i+1

gure VI.06 M ecanisme de lacquittement Au d epart du Paquet i une horloge se d eclenche. Si cette horloge d epasse une valeur limite avant r eception de lACK le Paquet i est retransmis Cette valeur limite est bas ee sur la constante MSL7 qui est un choix dimpl ementation, g en eralement de 30 secondes ` a 2 minutes. Le temps maximum dattente est donc de 2 M SL. Le temps qui s ecoule entre l emission dun paquet et la r eception de son 8 acquittement est le RTT , il doit donc etre inf erieur ` a 2 M SL. Il est courant sur lInternet actuel davoir un RTT de lordre de la seconde. Il faut noter que le RTT est la somme des temps de transit entre chaque routeur et du temps pass e dans les diverses les dattente sur les routeurs. L emetteur conserve la trace du Paquet i pour eventuellement le renvoyer. Si on consid` ere des d elais de transmission de lordre de 500 ms (voire plus), un tel m ecanisme est totalement inadapt e au transfert de ux de donn ees. On peut aussi remarquer quil sous-emploie la bande passante du r eseau.
7 8

Maximum Segment Lifetime Round Trip Time , calcul e` a laide de loption timestamp - voir page 93

98

Protocole TCP

3.2

Fen etres glissantes

Cette attente de lacquittement est p enalisante, sauf si on utilise un 9 m ecanisme de fen etres glissantes , comme le sugg` ere la gure VI.07 :

Emetteur
Paquet i Paquet i+1 Paquet i+2 Paquet i+3 ACK(i) Paquet i+4

Rcepteur

Dure maximale dattente pour lacquittement sur le Paquet i

gure VI.07 Principe de la fen etre glissante Avec ce principe, la bande passante du r eseau est beaucoup mieux employ ee. Si lun des paquets doit etre re emis, la couche TCP du destinataire aura toute linformation pour le replacer dans le bon ordre. ` chaque paquet est associ A ee une horloge comme sur la gure VI.06. Le nombre de paquets ` a envoyer avant dattendre le premier acquittement est fonction de deux param` etres : 1. La largeur de la fen etre pr ecis ee dans le champ WINDOW de len-t ete. Des valeurs courantes sont de lordre de 4096, 8192 ou 16384. Elle change dynamiquement pour deux raisons : (a) Lapplication change la taille du buer de la socket 10 qui correspond ` a la taille de cette fen etre. (b) Chaque acquittement ACK envoy e est assorti dune nouvelle valeur de taille de la fen etre, permettant ainsi ` a l emetteur dajuster ` a tout instant le nombre de segment quil peut envoyer simultan ement. Celle valeur peut etre nulle, comme par exemple lorsque lapplication cesse de lire les donn ees re cues. Cest ce m ecanisme qui assure le contr ole de ux de TCP.
9 10

sliding windows voir le cours de programmation

Fen etres glissantes 2. La taille maximale des donn ees, ou MSS11 vaut 512 octets par d efaut. Cest la plus grande taille du segment de donn ees que TCP enverra au cours de la session. Le datagramme IP a donc une taille egale au MSS augment ee de 40 octets (20 + 20), en labsence doption de TCP. Cette option apparait uniquement dans un paquet assorti du drapeau SYN, donc ` a l etablissement de la connexion. Comme de bien entendu cette valeur est fortement d ependante du 12 support physique et plus particuli` erement du MTU . Sur de lEthernet la valeur maximale est 1500 2 20 = 1460, avec des trames lencapsultation 802.3 de lIEEE un calcul similaire conduit ` a une longueur de 1452 octets. Chaque couche TCP envoie sa valeur de MSS en m eme temps que le paquet de synchronisation, comme une option de len-t ete. Cette valeur est calcul ee pour eviter absolument la fragmentation de IP au d epart des datagrammes.

99

MSS accept par le destinataire

Fentre possible pour le destinataire (dernier acquittement) Fentre utilisable

10

...

Dj envoys, ACK reus.

Envoys, ACK non reus.

Peuvent tre envoys

Ne peuvent pas encore tre envoys, il faut attendre que la fentre se dplace.

gure VI.08 D etail de la fen etre glissante Le d ebit obtenu d epend de la taille de la fen etre et bien s ur de la bande passante disponible. On con coit ais ement quentre la situation de la gure VI.06 et celle de la gure VI.07 lusage de la bande passante sam eliore. Par contre lagrandissement de la taille de la fen etre ne se con coit que jusqu` a une limite optimale au dela de laquelle des paquets sont perdus parcequenvoy es trop rapidement pour etre re cus par le destinataire. Or, pour fonctionner de mani` ere optimale, TCP se doit de limiter au maximum la perte de paquets et donc leur r e emission.
11 12

Maximum Segment Size - Cf page 93 Maximum Transfer Unit - Cf page 52

100

Protocole TCP Cette taille limite optimale de la largeur de la fen etre est, comme on peut le deviner, fonction de la bande passante th eorique du r eseau et surtout de son taux doccupation instantann e. Cette derni` ere donn ee est uctuante, aussi TCP doit-il asservir continuement les tailles de fen etre pour en tenir compte.

Compl ements sur le fonctionnement de TCP

Lusage du protocole TCP di` ere consid erablement en fonction des applications mises en uvre et des r eseaux ` a parcourir. Dapr` es [W. Richard Stevens], 10% des donn ees echang ees sur le r eseau concernent des applications interactives et 90% des applications qui echangent des ux de donn ees. Si le protocole TCP reste le m eme pour tous, les algorithmes qui le pilotent sajustent en fonction de lusage. Pour le trac en volume ( bulk data ), TCP tente dutiliser des paquets les plus larges possibles pour maximiser le d ebit, alors que le trac interactif utilise des paquets quasiment vides emis le plus souvent ` a la fr equence de frappe des utilisateurs ou au rythme des mouvements dune souris. Un exemple typique est celui de lapplication telnet pour laquelle les caract` eres sont envoy es un ` a un dans un paquet di erent, chaque caract` ere etant ` a lorigine de quatre paquets : emission dun caract` ere, acquittement, retour de l echo du caract` ere, acquittement. Si ce comportement nest absolument pas p enalisant sur un r eseau rapide (LAN) par contre d` es que la bande passante commence ` a etre statur ee il est pr ef erable de regrouper un maximum doctets (deux ou trois en pratique) dans un seul paquet pour en diminuer le nombre. Cest ce que fait lalgorithme de Nagle.

4.1

Algorithme de Nagle

Pour r eduire le trac de ces tinygrams (RFC 896), lalgorithme de Nagle (1984) dit quune connexion TCP ne peut pas attendre plus dun acquittement. Deux cas se pr esentent donc : 1. Le r eseau est lent. Dans ce cas TCP accumule dans un m eme buer les octets en partance. D` es r eception de lacquittement il y a emission du contenu du buer en un seul paquet. 2. Le r eseau est rapide. Les acquittements arrivent rapidement les agr egats doctets peuvent tendre vers un seul caract` ere par paquet. La qualit e lent/rapide du r eseau est calcul ee ` a partir du timestamp envoy e dans les options de TCP et qui est etabli d` es le premier echange (puis re evalu ee statistiquement par la suite). L el egance de cet algorithme est quil est tr` es simple et quil sauto-r egule suivant le d elais de propagation.

D epart lent Certaines applications d esactivent cet algorithme13 comme le serveur Apache ou le syst` eme de multi-fen etrage X11.

101

4.2

D epart lent

Un paquet est re emis parcequil arrive corrompu ou parcequil narrive jamais. Une r e emission entraine un blocage de lavancement de la fen etre glissante , p enalisant pour le d ebit (cf conclusion du chapitre page 105). TCP consid` ere quun paquet perdu est la cons equence dun routeur (ou plus) congestionn e, cest ` a dire pour lequel les les dattente ne sont pas assez larges pour absorber tous les paquets entrants14 Dans ce contexte, on comprend bien quil vaut mieux ne pas envoyer la totalit e du contenu de la fen etre d` es le d ebut de la connexion. Au contraire, TCP utilise un algorithme nomm e slow start qui asservit l emission des paquets au rythme de la r eception de leurs acquittements, plut ot que de les emettre dun coup aussi rapidement que lautorise le syst` eme ou le d ebit th eorique du r eseau. Ainsi, au d ebut de chaque connexion ou apr` es une p eriode de calme ( idle ) l emetteur envoie un premier paquet de taille maximale (le mss du destinataire), et attend son acquittement. Quand celui-ci est re cu, il envoie deux paquets, puis quatre, et ainsi de suite jusqu` a atteindre louverture maximale de la fen etre. Durant cette progression, si des paquets sont perdus, il y a congestion suppos ee sur lun des routeurs franchis et louverture de la fen etre est r eduite pour retrouver un d ebit qui minimise le taux de retransmission. Louverture de la fen etre est nomm ee fen etre de congestion ou encore congestion window .

4.3

Evitement de congestion

Le contr ole du ux evoqu e pr ec edement, pour eviter la congestion des routeurs, est impl ement e` a laide dune variable (cwnd) nomm ee congestion window que lon traduit par fen etre de congestion. Concr` etement, le nombre maximum de segments de donn ees (M SS en octets) que l emetteur peut envoyer avant den recevoir le premier acquittement est le minimum entre cette variable (cwnd) et la taille de la fen etre annonc ee par le r ecepteur ` a chaque acquittement de paquet. Le contenu de cette variable est pilot e par les algorithmes de d epart lent evitement de congestion ( congestion slow start , voir 4.2 et d avoidance ) examin e ici. La limite de croissance de la variable cwnd est la taille de la fen etre annonc ee par le r ecepteur. Une fois la capacit e de d ebit maximale atteinte, si un paquet est perdu lalgorithme d evitement de congestion en diminue
13 14

` a laide de loption TCP NODELAY Ce cas arrive fr equemment quand un routeur s epare un r eseau rapide dun r eseau lent

102

Protocole TCP lin eairement la valeur (contrairement au slow start qui laugmente exponentiellement).

Paquets captur es, comment es

Le premier exemple montre un echange de paquets de synchronisation (SYN) et de n (FIN) entre la machine clnt.chezmoi et la machine srv.chezmoi. L etablissement de la connexion se fait ` a laide de la commande telnet sur le port discard (9) du serveur srv.chezmoi. La machine qui est ` a lorigine de l etablissement de la connexion est dite cliente, et celle qui est suppos ee pr ete ` a r epondre, serveur. Pour information, le service discard peut etre consid er e comme l equivalent du chier /dev/null sur le r eseau : les octets quon lui envoie sont oubli es ( discard ). Lutilisateur tape :
Simultan ement la $ telnet srv discard capture des paquets Trying... est lanc ee, par Connected to srv.chezmoi. exemple dans une Escape character is ^]. autre fen etre xterm.

telnet> quit Connection closed. Et loutil danalyse r eseau15 permet la capture pour lobservation des echanges suivants. Le num ero qui gure en t ete de chaque ligne a et e ajout e manuellement, le nom de domaine chezmoi a et e retir e, le tout pour faciliter la lecture :
0 1 2 3 4 5 6 13:52:30.274009 clnt.1159 > srv.discard: S 55104001:55104001(0) win 8192 <mss 1460> 13:52:30.275114 srv.discard > clnt.1159: S 2072448001:2072448001(0) ack 55104002 win 4096 <mss 1024> 13:52:30.275903 clnt.1159 > srv.discard: . ack 1 win 8192 13:52:33.456899 clnt.1159 > srv.discard: F 1:1(0) ack 1 win 8192 13:52:33.457559 srv.discard > clnt.1159: . ack 2 win 4096 13:52:33.458887 srv.discard > clnt.1159: F 1:1(0) ack 2 win 4096 13:52:33.459598 clnt.1159 > srv.discard: . ack 2 win 8192

Plusieurs remarques simposent : 1. Pour am eliorer la lisibilit e les num eros de s equences vrais ne sont indiqu es quau premier echange. Les suivants sont relatifs. Ainsi le ack 1 de la ligne 2 doit etre lu 2072448002 (2072448001 + 1). ` A chaque echange la valeur entre parenth` eses indique le nombre doctets echang es.
15

tcpdump que nous aurons loccasion dutiliser en TP

Exemples de ux 2. Les tailles de fen etre (win) et de segment maximum (mss) ne sont pas identiques. Le telnet du client fonctionne sur HP-UX alors que le serveur telnetd fonctionne sur une machine BSD. 3. La symbole > qui marque le sens du transfert. 4. Le port source 1159 et le port destination discard. 5. Les ags F et S. Labsence de ag, rep er e par un point. Le deuxi` eme exemple montre une situation de transfert de chier avec 16 loutil ftp . Il faut remarquer que l etablissement de la connexion TCP est ici ` a linitiative du serveur, ce qui peut laisser le lecteur perplexe. . .Lexplication est simple. En fait le protocole ftp fonctionne avec deux connexions TCP, la premi` ere, non montr ee ici, est etablie du client vers le serveur, suppos e ` a l ecoute sur le port 21. Elle sert au client pour assurer le contr ole du transfert. Lorsquun transfert de chier est demand e via cette premi` ere connexion, le serveur etablit une connexion temporaire vers le client. Cest cette connexion que nous examinons ici. Elle est clotur ee d` es que le dernier octet demand e est transf err e. Extrait du chier /etc/services, concernant ftp :
ftp-data ftp-data ftp ftp 20/tcp 20/udp 21/tcp 21/udp #File #File #File #File Transfer Transfer Transfer Transfer [Default Data] [Default Data] [Control] [Control]

103

Dans cette exemple nous pouvons suivre le fonctionnement du m ecanisme des fen etres glissantes. Les lignes ont et e num erot ees manuellement et la date associ ee ` a chaque paquet supprim ee.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 srv.20 > clnt.1158: S 1469312001:1469312001(0) win 4096 <mss 1024> [tos 0x8] clnt.1158 > srv.20: S 53888001:53888001(0) ack 1469312002 win 8192 <mss 1460> srv.20 > clnt.1158: . ack 1 win 4096 [tos 0x8] srv.20 > clnt.1158: P 1:1025(1024) ack 1 win 4096 [tos 0x8] clnt.1158 > srv.20: . ack 1025 win 8192 srv.20 > clnt.1158: . 1025:2049(1024) ack 1 win 4096 [tos 0x8] srv.20 > clnt.1158: . 2049:3073(1024) ack 1 win 4096 [tos 0x8] clnt.1158 > srv.20: . ack 3073 win 8192 srv.20 > clnt.1158: . 3073:4097(1024) ack 1 win 4096 [tos 0x8] srv.20 > clnt.1158: P 4097:5121(1024) ack 1 win 4096 [tos 0x8] srv.20 > clnt.1158: P 5121:6145(1024) ack 1 win 4096 [tos 0x8] clnt.1158 > srv.20: . ack 5121 win 8192 srv.20 > clnt.1158: P 6145:7169(1024) ack 1 win 4096 [tos 0x8] srv.20 > clnt.1158: P 7169:8193(1024) ack 1 win 4096 [tos 0x8] clnt.1158 > srv.20: . ack 7169 win 8192 du nom du protocole applicatif utilis e : File Transfer Protocol

16

104
15 16 17 18 19 20 ... 21 22 23 24 25 26 27 28 29 30 31 32 srv.20 > clnt.1158: srv.20 > clnt.1158: clnt.1158 > srv.20: srv.20 > clnt.1158: srv.20 > clnt.1158: clnt.1158 > srv.20: ... ... srv.20 > clnt.1158: clnt.1158 > srv.20: srv.20 > clnt.1158: srv.20 > clnt.1158: srv.20 > clnt.1158: clnt.1158 > srv.20: clnt.1158 > srv.20: srv.20 > clnt.1158: srv.20 > clnt.1158: clnt.1158 > srv.20: clnt.1158 > srv.20: srv.20 > clnt.1158: P P . P P . P . P P P . . P F . F .

Protocole TCP
8193:9217(1024) ack 1 win 4096 [tos 0x8] 9217:10241(1024) ack 1 win 4096 [tos 0x8] ack 9217 win 8192 10241:11265(1024) ack 1 win 4096 [tos 0x8] 11265:12289(1024) ack 1 win 4096 [tos 0x8] ack 11265 win 8192 1178625:1179649(1024) ack 1 win 4096 [tos 0x8] ack 1178625 win 8192 1212417:1213441(1024) ack 1 win 4096 [tos 0x8] 1213441:1214465(1024) ack 1 win 4096 [tos 0x8] 1214465:1215489(1024) ack 1 win 4096 [tos 0x8] ack 1213441 win 8192 ack 1215489 win 8192 1215489:1215738(249) ack 1 win 4096 [tos 0x8] 1215738:1215738(0) ack 1 win 4096 [tos 0x8] ack 1215739 win 8192 1:1(0) ack 1215739 win 8192 ack 2 win 4096 [tos 0x8]

Remarques : 1. Le P symbolise le drapeau PSH. La couche TCP qui re coit un tel paquet est inform ee quelle doit transmettre ` a lapplication toutes les donn ees re cues, y compris celles transmises dans ce paquet. Le positionnement de ce drapeau est ` a linitiative de la couche TCP emettrice et non ` a lapplication. 2. Le type de service ( Type Of service tos 0x8) est demand e par lapplication pour maximiser le d ebit (consulter le cours IP page 49).
Donnes transmettre, par segment de 1024 octets Numros des lignes 1024 3 5,6 8,9,10 12,13 15,16 18,19 4 7 11 14 17 20

gure VI.09 Exemple de fen etre glissante

6 Conclusion sur TCP

105

Conclusion sur TCP

Le protocole TCP a et e con cu ` a une epoque o` u lusage de la commande ligne etait universel, et les applications graphiques utilisant le r eseau tr` es rares. . . ! Une trentaine dann ees plus tard, on peut faire le constat pratiquement inverse : les applications textes interactives (beaucoup de petits messages applicatifs) disparaissent au prot dapplications moins interactives et qui sont plus orient ees ux de donn ees (vid eo, audio, t el ephonie. . .) avec des echanges plus volumineux et des besoins en transport qui ont evolu e. Le principe de la fen etre glissante, si performant quil soit pour assurer le bon acheminement des donn ees, est bloquant pour certaines applications comme le web. En eet, si le paquet de donn ees de t ete nest pas acquitt e, les suivants, m eme re cus, sont en attente avant d etre d elivr es ` a lapplication. Si la r eponse comporte par exemple de nombreuses zones graphiques et textuelles di erentes la uidit e de la consultation est consid erablement amoindrie, et tenter de la compenser en etablissant un grand nombre de connexions simultann ees pour r ecup erer individuellement les el ements de la page, consomme beaucoup de ressources syst` eme et r eseaux (celles de l etablissement des connexions) qui ne compense que partiellement ce soucis. Lind ependance de TCP vis ` a vis de la structure des donn ees est egalement un inconv enient dans certaines applications comme la t el ephonie pour laquelle la notion de messages successifs est bien plus int eressante. Depuis le d ebut des ann ees 2000 lIETF met au point le protocole SCTP qui fournit des services similaires ` a ceux de TCP, en abandonne certains et apporte les nouvelles fonctionnalit es adapt ees aux nouveaux besoins.

Bibliographie

RFC 793 Transmission Control Protocol. J. Postel. Sep-01-1981. (Format : TXT=177957 bytes) (Status : STANDARD) RFC 1025 TCP and IP bake o. J. Postel. Sep-01-1987. (Format : TXT=11648 bytes) (Status : UNKNOWN) RFC 1700 ASSIGNED NUMBERS. J. Reynolds,J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD) Sans oublier : W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall McKusick Bostic Karels Quaterman The Design and implementation of the 4.4 BSD Operating System (chapitre 13) AddisonWesley 1996

106

Protocole TCP

Deuxi` eme partie R eseaux IP avanc es

Chapitre VII Routage dynamique dIP

1 Introduction & rappels

La notion de routage est inh erente au fonctionnement du datagramme IP (examin e page 47). Le routage des datagrammes IP nest rien dautre que lop eration qui consiste ` a trouver une route pour les conduire vers la destination, cest ` a dire ladresse du champ destination de len-t ete (page 49). Un premier examen du routage nous a conduit ` a distinguer le routage direct, sur un m eme lan et associ e` a lusage des services du protocole ARP (Voir page 55) puis le routage indirect, appell e ainsi parcequil fait appel aux services dune ou plusieurs passerelles avant datteindre la destination. Dans les deux cas la d ecision de routage porte sur la partie r eseau de ladresse IP du destinataire, ou encore le netid. Le routage indirect se subdivise en deux cat egories : le routage statique, qui implique lusage dune passerelle par d efaut et enn le routage dynamique, sujet qui concerne ce chapitre. Lid ee dune route statique est s eduisante par sa facilit e de mise en uvre pour lorganisation des petits r eseaux . Elle se r esume le plus souvent ` a ajouter une simple ligne dans la conguration de lappareil ` a raccorder au r eseau, et cette information vitale peut m eme etre r ecup er ee automatiquement ` a laide de protocoles comme BOOTP ou DHCP ! Sur un routeur cisco1 ,la ligne de conguration : ip route 0.0.0.0 0.0.0.0 138.195.52.129 Indique que tous les datagrammes non routables directement doivent etre envoy es ` a ladresse 138.195.52.129. Une seule route par d efaut peut etre d enie pour une pile IP comme il a et e expliqu e lors de lanalyse de lalgorithme de routage page 70. Cette disposition tr` es simple est bien commode car elle evite de se poser des questions compliqu ees sur le choix de la route, en d el eguant ` a dautres ce travail d elicat. En eet, il faudra bien ` a un certain moment du trajet suivi par
1

http://www.cisco.com

110

Routage dynamique dIP les datagrammes, quun dispositif particulier, etymologiquement un routeur, prenne une d ecision face ` a des possibilit es multiples. Ce routeur plus intelligent sera probablement celui qui permet ` a vos datagrammes de rejoindre linternet si vous appartenez ` a une entit e qui a son autonomie (voir plus loin), ou le routeur du prestataires FAI pour un particulier, ou une plus petite entit e, abonn e` a un service xDSL quelconque. La pr esence de plusieurs routes possibles pour rejoindre une destination implique de facto lusage dun protocole de routage dynamique. Une route statique privil egie une seule route et ignore les autres. Lexistence de plusieurs routes est une n ecessit e pour assurer la redondance du service, voire m eme l equilibrage du trac sur plusieurs liens.

1.1

IGP, EGP, Syst` eme autonome

Au commencement, lArpanet etait un seul r eseau g er e de mani` ere homog` ene, du moins par un ensemble de personnes d ependantes de la m eme entit e administrative, ce qui permettait den orienter le d eveloppement de la m eme mani` ere partout. Le protocole de routage dynamique etait un anc etre du protocole RIP etudi e dans ce chapitre. Ce protocole, comme on va le voir, implique que les routeurs s echangent continuement des informations sur les meilleures routes ` a employer. Sans entrave, chaque routeur nit par avoir une route pour atteindre tout le monde, partout ! Lextension de ce r eseau ` a des entit es tr` es di erentes entres elles, a conduit les architectes r eseaux de l epoque ` a cr eer la notion de syst` eme autonomes (autonomous systems ou AS dans le texte), an de permettre ` a chacun de d evelopper son r eseau interne sans risque den diuser le contenu ` a lext erieur (soucis de condentialit e et de s ecurit e). Un syst` eme autonome se caract erise par un num ero, ou num ero dAS, sur 16 bits dont lattribution d epend de lIANA et de ses d el egations, par exemple autonomous-system 2192 que lon pourrait retrouver dans la conguration dun external gateway de la gure VII.01. Cette nouvelle architecture entraine des changements dans lusage des protocoles de routage. Certains sont plus adapt es que dautres ` a router des blocs dadresses IP conform ement ` a des politiques de routage (routing policy) internationales, ce sont les EGP comme external gateway protocol. Leur anc etre se nomme dailleurs EGP, il est remplac e aujourdhui par BGP (Border Gateway Protocol). ` lint A erieur du syst` eme autonome, les protocoles de routages sont des IGP comme Interior Gateway Protocol et ne sont plus du tout adapt es ` a la gestion de linternet moderne. Par contre ils r epondent plus ou moins bien au besoin des r eseaux internes si compliqu es et vastes soient-ils. Ces IGP echangent bien entendu des routes avec les EGP, le routage ne serait pas possible sans cela.

 Vecteur de distances vs Etat de liens

Internet Core

111

GGP Core Gateway EGP,BGP Core Gateway

RIP,OSPF External gateways

Autonomous System

Autonomous System

gure VII.01 Un AS, le monde ext erieur, le monde int erieur ! Ce chapitre de cours examine deux IGP tr` es classiques, RIP et OSPF ! Si ces deux protocoles se rencontrent tr` es fr equemment sur les r eseaux, ils di` erent beaucoup dans leurs propri et es comme nous allons le voir. . .

1.2

Vecteur de distances vs Etat de liens

RIP Routing Information Protocol et OSPF Open Shortest Path First sont construits sur des approches di erentes. Les algorithmes de routage ` a vecteur de distances (bas es sur lalgorithme de Bellman-Ford) conduisent les routeurs ` a transmettre ` a leurs voisins r eseaux imm ediats une copie de leur table de routage. Ces tables se modient au fur et ` a mesure de leur propagation, car chaque route est associ ee ` a une m etrique qui cro t par d efaut dune unit e au passage de chaque routeur (le routeur voisin accessible sur le m eme LAN est associ e` a une m etrique de 1, etc. . .). Le choix de la meilleure route est etabli par chaque routeur en consid erant la valeur minimale de cette m etrique pour toutes les routes qui aboutissent ` a la m eme destination. Seule la meilleure route est propag ee, les autres sont oubli ees. Pour ces consid erations on dit que le calcul de la route est distribu e et par cons equence chaque routeur na pas la connaissance de la topologie globale du r eseau : il nen connait quune version interpr et ee par ses voisins. Les algorithmes ` a etats de liens b atissent les tables de routages di eremment. Chaque routeur est responsable de la reconnaissance de tous ses voisins, plus ou moins lointains, ` a qui il envoie une liste compl` ete des noms et des co uts (en terme de bande passante, par d efaut) contenu dans une base de donn ees ` a sa charge et qui repr esente lint egralit e de tous les routeurs du nuage avec lesquels il doit travailler.

112

Routage dynamique dIP Chaque routeur a donc une connaissance exhaustive de la topologie du nuage dans lequel il se situe et cest ` a partir de cette repr esentation quil calcule ses routes ` a laide dun algorithme connu de recherche du plus court chemin dans un graphe : celui de Dijkstra2

http://www.cs.utexas.edu/users/EWD/

2 Routage avec RIP

113

Routage avec RIP

RIP est lacronyme de Routing Information Protocol. Cest le protocole historique de routage dArpanet3 , d eni dans la RFC 1058 (historique) de 1988. Il est amusant de constater que l ecriture de cette RFC vient de lanalyse fonctionelle du dmon routed pr esent sur les machines BSD de l epoque4 . Le principe de fonctionnement de RIP est bas e sur le calcul distribu e du chemin le plus court dans un graphe, selon lalgorithme Bellman-Ford5 d ecrit ` a la n des ann ees 1950. Le terme chemin le plus court d esigne implicitement lusage dune m etrique pour comparer les longueurs. Ici, la m etrique est basiquement le nombre de sauts (hops) entre deux routeurs. Pour tout routeur, les r eseaux directement rattach es sont accessibles avec un nombre de saut egal ` a 1 (par d efaut). La m etrique pour satteindre soit-m eme etant toujours 0 par hypoth` ese. Les routes qui sont propag ees dun routeur ` a un autre voient leur m etrique augmenter de 1 (ou plus) ` a chaque franchissement dun routeur. En pratique on ne d epasse gu` ere une profondeur de quelques unit es, sinon le protocole devient inecace comme on le verra au paragraphe suivant. Plus pr ecisement, une route assortie de la m etrique 16 est consid er ee comme innie, donc d esigne une destination (devenue) inaccessible. Cette limitation du protocole laisse quand m eme aux architectes dinfrastructures r eseaux la possibilit e de concevoir des r eseaux s epar es les uns des autres par un maximum de 15 routeurs. . .Au del` a de cette limite il faut forc ement envisager lusage dun autre protocole !
R N R1 R2

N mtrique == 2

N mtrique == 1

gure VII.02 La route vers H depuis R a une m etrique de 2 et passe par R1 Sur la gure VII.02 Le routeur R peut atteindre lh ote H avec une route dont la m etrique est 2 et qui passe par le routeur R1. Il faut bien noter quavec RIP, chaque routeur nest en relation quavec ses voisins directs, cest ` a dire ceux avec lesquels il partage un LAN6 . Typiquement un routeur qui fait du RIP a au moins deux interfaces (elles peuvent
old ARPANET routing Il lest encore de nos jours ! 5 http://brassens.upmf-grenoble.fr/IMSS/mamass/graphecomp/bellmannFord. htm pour une explication tr` es visuelle et soign ee du fonctionnement de lalgorithme 6 Cf page 7
4 3

114

Routage dynamique dIP etre virtuelles), donc voit deux LANs. Ici R1 a un r ole central et incontournable car ni R ni R2 ne s echangent directement des routes. Pour cette raison, les routes sont globalement issues dun calcul distribu e. Pour chaque routeur l etablissement de sa table de routage seectue ` a partir des informations fournies par les routeurs de son voisinage, cest ` a dire ceux quil peut atteindre par un routage directe (cf page 66). La connaissance des routes acquises par chaque routeur ne seectue quau travers du r esultat des calculs de routes eectu es par ses voisins, calculs quil confrontera ` a sa propre table de routage et ` a son propre calcul de route (le choix dune route plus courte ` a laide de la m etrique annonc ee), puis diusera ` a son tour. Par ce principe, dans la gure VII.02, R1 a connaissance du r eseau N indirectement gr ace aux annonces de routes dius ees par R2. Le terme vecteurs de distances est employ e parceque la propagation des routes seectue sous la forme de vecteurs : Pour atteindre telle destination, il faut passer par ce routeur et la m etrique associ ee vaut cette valeur . Donc une direction et une m etrique, do` u lanalogie avec un vecteur. Le moyen de propagation des tables de routes est un broadcast IP (adresse 255.255.255.255 Limited broadcast pour RIPv1) ou des annonces multicast (adresse 224.0.0.9 si on utilise RIPv27 ).

2.1

En fonctionnement

1. Au d emarrage, chaque routeur a connaissance des r eseaux auxquels il est directement rattach e, ainsi que du co ut associ e ` a chacune de ses liaisons (1 par d efaut). Le co ut de la liaison locale, cest ` a dire celle du routeur vers lui-m eme, est 0 alors que celle pour atteindre nimporte quel autre point est inni (valeur 16 par d efaut). Le routeur envoie un paquet de questionnement (request packet) ` a ses voisins pour constituer sa table de routage initiale. La RFC 2453 pr ecise que celle-ci contient 5 informations pour chaque entr ee : (a) (b) (c) (d) Ladresse IPv4 de la destination, La m etrique pour atteindre cette destination, Ladresse IPv4 de premi` ere passerelle (next router) ` a utiliser, Un drapeau qui indique si la route a chang e r ecemment (route change ag) (e) Deux chronom` etres associ es ` a la route, lun pour signier que la route nest plus utilisable (timeout), lautre pour compter le temps

Rappellons (cf page 42) que les adresses du groupe 224.0.0.0/24 ont un TTL de 1 et donc ne sont pas rout ees en dehors du LAN

Routage avec RIP durant lequel une route non utilisable doit etre maintenue dans la table avant d etre supprim ee et lespace m emoire utilis e recycl e (garbage-collection). 2. En fonctionnement chaque routeur transmet son vecteur de distance ` a ses voisins directs (LAN) soit par un broadcast, soit par un multicast. Le port de destination est toujours 520 ; Cet ev enement a lieu p eriodiquement (30 secondes) o` u d` es que quelque chose change dans la table de routage (Triggered updates page 117), ou encore ` a r eception dun paquet de demande de route, par exemple par un h ote dun r eseau directement raccord e (voir page 73) ; 3. Chaque routeur calcule son propre vecteur de distance, le co ut minimum est le crit` ere de s election. Ce calcul intervient d` es que : Le routeur re coit un vecteur de distance qui di` ere avec ce quil a d ej` a en m emoire, Le constat de la perte de contact (link ou absence de r eception des annonces) avec un voisin. 4. Quand une route na pas et e rafra chie depuis 180 secondes (6 paquets de broadcast non re cus) sa m etrique prend la valeur innie (16) puis elle est d etruite (deuxi` eme chronom` etre d eni pr ec edemment). Le fonctionnement de RIP a un cot e magique et pourtant lalgorithme converge vers un etat stable, cest d emontr e! Examinons-en le fonctionnement el ementaire sur un r eseau th eorique de trois routeurs align es lors dun d emarrage ` a froid :
R1 N1 R2 N2 R3

115

gure VII.03 Fonctionnement el ementaire ` linstant 0 Chaque routeur d A ecouvre les r eseaux qui lui sont directement rattach es et se connait lui-m eme, cest ` a dire quil connait sa ou ses adresses IP. On peut le formaliser par un triplet (Destination, gateway, m etrique), pour R1 ca donne (R1,local,0)8 ; R1 annonce (R1,local,0) sur N1 R2 annonce (R2,local,0) sur N1 et N2 R3 annonce (R3,local,0) sur N2 En nal Chacun annonce ses routes de mani` ere asynchrone, met ` a jour sa table de routage et annonce celle-ci, tout ca de mani` ere un peu asynchrone. On examine les tables de routages une fois ces echanges stabilis es.
Notons au passage quune route peut etre formul ee vers un h ote ou un r eseau, indi erement
8

116

Routage dynamique dIP R2 re coit les annonces de route en provenance de R1 et R3. Il ajoute le co ut de la liaison et obtient en nal une table qui ressemble ` a: (R2,local,0) (R1,R1,1) (R2,R2,1), De la m eme mani` ere R1 enrichit sa table avec deux routes : (R2,R2,1) et (R3,R2,2). Pour R3 de mani` ere sym etrique : (R2,R2,1), (R1,R2,2). Que se passe t-il maintenant si R3 devient inaccessible (coupure r eseau, h ote arr et e. . .) ? Basiquement R2 devrait supprimer la route vers R3. Il nen fait rien pour linstant puisque R1 annonce une route (R3,R2,2). R2 d ecide donc quil existe une route (R3,R1,3) et annonce sa nouvelle table. R1 ayant re cu une route modi ee de R2 modie sa propre route qui devient (R3,R2,4) et ainsi de suite dans une boucle infernale qui tend ` a compter jusqu` a linni. For heureusement le calcul sarr etera ` a 16 par d efaut, R1 et R2 conclueront alors que R3 nest pas (plus) accessible et niront par retirer la route de leur table ! On peut aisement se rendre compte de la stupidit e de cette d emarche ainsi (et cest surtout ce quon lui reproche) de la perte de temps engendr ee. Do` u les am eliorations apport ees : 2.1.1 Horizon partag e ou Split horizon

Le concept est simple, il sut de constater (toujours dans la gure VII.03) quil est stupide si R1 route via R2 des paquets pour R3, dessayer pour R2 de router ces paquets vers R1. Donc R1 ne doit pas annoncer ` a R2 des routes passant par R2. Les routes annonc ees ne sont donc plus identiques sur chaque r eseau mais tiennent compte des destinations qui sont atteintes via chacune de ces liaisons pour eviter ce type dannonce.
R1 R3 R2 H

gure VII.04 : L horizon partag e ne r esout pas tout ! Il existe une variante plus ecace encore, qui consiste, pour R1, ` a annoncer ` a R2 la route (R3,R2,16), donc une route innie. R2 ne pourra donc pas utiliser cette route pour atteindre R3 via R1. Il ny a pas de boucle de comptage ` a linni et R2 concluera tout de suite ` a linaccessibilit e de R3. Ces deux astuces r eunies sont rep er ees dans la RFC sous le terme split horizon with poisoned reverse.

Routage avec RIP La gure VII.03 repr esente donc un cas th eorique facile. En pratique, un des int er ets du routage dynamique etant davoir plusieurs routes possibles pour atteindre une destination, on aura plut ot la situation de la gure VII.04 ce qui am` ene au cas de gure suivant : Supposons que lh ote H devienne inaccessible, la technique ci-dessus emp echera R3 de tenter de router les datagrammes vers R1 et R2, mais, du fait du caract` ere asynchrone des mises ` a jours, R1 ayant re cu de R3 le fait que H est inaccessible peut conclure que R2 est le meilleur chemin avec un co ut de 3 et cette fausse information peut se propager ` a R3 via R2 et le comptage ` a linni est reparti. . . Pour y rem edier le protocole comporte un dispositif de mises ` a jours d eclench ees : 2.1.2 Mises ` a jour d eclench ees ou Triggered updates

117

L eventualit e dune situation de comptage ` a linni evoqu ee dans le contexte de la gure VII.04 peut etre endigu ee par ce dispositif. Seules des mises ` a jours tr` es rapides peuvent conduirent R1 et R2 ` a converger vers la conclusion que la distance vers H est devenue innie. La r` egle initiale est que quand un routeur change la m etrique dune route, il doit envoyer un message de mise ` a jour aussi vite que possible ` a tous ses voisins imm ediats. Ce message ne contient que ce qui a chang e et non lint egralit e de la table. Mises ` a jour rapides ne signient pas pour autant temp etes de paquets sur le r eseau , dune part parceque le principe de lhorizon partag e est conserv e, et que dautre part, une temporisation al eatoire (de 1 ` a 5 secondes) limite la fr equence d emission de chaque mise ` a jour. Durant ce laps de temps la r eception dune mise ` a jour peut etre egalement prise en compte et donc entrainer un changement des routes etablies. La di erence entre ce dipositif et les annonces r eguli` eres tient ` a sa fr equence d emission et au contenu restreint aux seules routes dont la m etrique a chang e. La RFC 2453 conclue toutefois However, counting to innity is still possible . Qui nest vraiment pas tr` es satisfaisant. . .

118

Routage dynamique dIP

2.2

Le protocole RIPv1 vs RIPv2

Entete RIP (4 octets) IP 20 8 4 octets + 25 routes x 20 octets = 504 octets UDP message RIP

RIP est encapsul e dans paquet UDP avec 520 comme port de destination :

gure VII.05 RIP est transport e par UDP/IP Etant donn e le mode de propagation des annonces de routes, le choix du protocole UDP est tout ` a fait appropri e. Cependant, la RFC 2453 sp ecie que le nombre maximum de routes est limit e` a 25, comme il faut 20 octets (gure VII.06) pour d ecrire une route, la partie utile du datagramme fait au plus 4 + 25 20 = 504 octets et le datagramme complet 532 octets au maximum, le risque de fragmentation est nul sur des lans et via les liaisons point ` a point modernes (PPP par exemple). Par contre, sil faut propager plus de 25 routes, il faut envisager l emission dautant de datagramme que n ecessaire ! ` lint A erieur du message RIP de la gure VII.03 les octets sorganisent de la mani` ere suivante :
0 7 8 15 16 * version * 31 Domaine Id. de route 4 octets toujours prsents

commande

Famille dadresse

Adresse IPv4 * * Masque de sousrseau Adresse IPv4 du prochain routeur Mtrique (*) champ laiss vide en RIPv1 20 octets (pour chaque route ajoute)

gure VII.06 Format dun message RIPv2 Le format dun message RIP laisse plein despace vide (surtout quand il sagit de RIPv1 les champs marqu es dune sur la gure). Lalignement des champs sur des mots de 32 bits en est ` a lorigine.

Routage avec RIP Commande 1 pour signier une demande, request, et 2 pour une r eponse, reply. Dautres commandes existent mais elles sont obsol` etes ou non document ees dans la RFC. . . Version 1 pour RIPv1 et 2 pour RIPv2. Domaine (RIPv2) Pour pouvoir faire tourner simultan ement sur une m eme machine plusieurs instances du daemon routed, ce champs contient un identiant (PID. . .) qui permet de discriminer la provenance des routes. Famille dadresse (Address familly identier - AFI) Famille dadresse, comme pour une socket (cf page 253) donc AF INET pour IPv4. Ce champ peut egalement contenir la valeur hexad ecimale 0xffff pour indiquer quil sagit un bloc dauthentication. Dans ce cas lidentiant de route contient la valeur 2 et les 16 octets qui suivent un mot de passe en clair, align e` a gauche et compl et e par des z eros ! Rien nest d eni dans la RFC 2453 pour etre plus condentiel. . . Identiant de route (Route tag - RIPv2) Cest un traceur pour identier une route qui provient dun autre IGP voire dun autre EGP et qui est propag ee par RIP. Adresse IPv4 Il sagit de la destination ` a atteindre par le routeur qui emet cette annonce. Masque de sous-r eseau (RIPv2) Le masque de sous-r eseau ` a appliquer au champ qui pr ec` ede. Cest un des apports principaux de RIPv2 par rapport ` a RIPv1. Adresse IPv4 du prochain routeur (Next hop - RIPv2) En fonctionnement normal ladresse 0.0.0.0 signie que la route passe par celui qui lannonce. Ici il sagit dune autre adresse IPv4, di erente de celle de lannonceur. Celui-ci nutilise pas RIP (sinon il ferait lannonce lui-m eme), mais sans doute un autre protocole de routage. Ce cas de gure arrive ` a la fronti` ere entre deux r eseaux, quand par exemple un routeur interne annonce une meilleure route via un routeur du m eme lan. M etrique Il sagit de lannonce de la m etrique, de 0 (h ote local) ` a 16 (inni non accessible) en pratique. En r esum e, les apports de RIPv2 sont les suivants : 1. Transmission dun masque de sous-r eseau avec chaque route. Ce point est majeur parcequil permet dutiliser RIP avec des r eseaux comportant des sous-r eseaux ; 2. Authentication (tr` es insusante puisque le mot de passe circule en clair). Le constructeur Cisco a ajout e des extension permettant lusage de MD5, cest mieux ; 3. Indication dun prochain routeur qui nest pas celui qui annonce la route ;

119

120

Routage dynamique dIP 4. Indication de routes de provenances externes, ou Route tag ; 5. Usage de ladresse multicast 244.0.0.9 pour propager des routes (plut ot quun limited broadcast IP, plus perturbateur parceque lu par tous les h otes.

2.3

Algorithme Bellman-Ford

Pour le fonctionnement de lalgorithme nous invitons le lecteur ` a consulter lexcellente simulation mise ` a disposition par lUniversit e Pierre Mend` es France de Grenoble, ` a cette url (cliquer sur le bouton Appliquette ) :
http://brassens.upmf-grenoble.fr/IMSS/mamass/graphecomp/bellmannFord.htm

2.3.1

M etrique

Dans les r eseaux simples, le plus courant est dutiliser le nombre de sauts, hop, cest ` a dire le nombre de routeurs ` a franchir pour arriver ` a destination. Les r eseaux plus complexe, on privil egira une m etrique bas ee sur le d elais, par exemple.

2.4

Conclusion

Lapparition des protocoles ` a etats de liens na pas emp ech e son d eveloppement, la RFC 2453 de 1998, d ecrit RIPv2 encore en usage dans bon nombre de (petits) r eseaux. 2.4.1 Points forts

Simplicit e de mise en uvre ; Simplicit e du protocole permettant une compr ehension ais ee des echange ; Robustesse des impl ementations. 2.4.2 Points faibles

Limitation ` a une profondeur de 15 ; Probl` eme de la vitesse de convergence (lente) de lalgorithme, et du comptage eventuel jusqu` a la route innie ; La m etrique nest pas adapt ee ` a des r eseaux dont les nuds sont s epar es par des liaisons utilisant des bandes passantes disparates ; Lauthentication de l emetteur des donn ees est tr` es pauvre en fonctionnalit e et pas du tout secure ; La topologie des r eseaux RIP reste ` a un seul niveau (pas de hi erarchie par exemple entre lar` ete centrale dun r eseau (backbone) et des r eseaux terminaux.

3 Routage avec OSPF

121

Routage avec OSPF

Lorigine du protocole OSPF, et de la technologie de routage par etats des liaisons , datent du tout d ebut des ann ees 1980, pour faire face aux insusances du protocole ` a vecteurs de distances, constat ees sur les r eseaux Arpanet et Cyclades. Son d eveloppement est d u aux eorts du groupe OSPF de lIETF.

3.1

Grandes lignes de fonctionnement

Les explications qui suivent font lhypoth` ese dun r eseau IP qui supporte la propagation de trames avec une adresse de destination de type multicast9 , autrement dit ne traite pas le cas des r eseaux sans diusion ce type ou encore NBMA (Non Broadcast Multi-Access networks). Basiquement un protocole ` a etats de liens a un fonctionnement simple : 1. Chaque routeur est responsable de la reconnaissance de ses voisins (et donc de leur nom) directs, cest ` a dire accessibles sur un des LANs directement raccord es ; 2. Chaque routeur etablit un paquet nomm e link state packet (LSP) qui contient la liste des noms et des co uts (paragraphe 3.3.1) dans la m etrique choisie pour atteindre chacun de ses voisins ; 3. Le LSP est propag e ` a tous les routeurs et chacun conserve le plus r ecent LSP re cu des autres routeurs dans une base de donn ees (linkstate database). Chaque routeur du nuage travaille ainsi ` a partir des m emes donn ees, une sorte de carte globale des etats ; 4. Chaque routeur a la responsabilit e par ses propres moyens (puissance CPU) du calcul du chemin ` a co ut minimum (shortest path) ` a partir de lui-m eme et pour atteindre tous les nuds du r eseau ; 5. Les changements de topologie du nuage (comme la perte de connectivit e sur un interface) de routeurs sont rapidement d etect es, annonc es au voisinage, et pris en compte pour recalculer les routes. En r esum e un tel protocole a deux grandes activit es, la premi` ere est de propager ses etats et d ecouter ceux de ces voisins au sein de lAS, cest ce quon appelle le ooding, en fran cais proc ed e par inondation, la deuxi` eme est de calculer des routes ` a partir de tous les etats de liens re cus. Ce calcul est eectu e` a laide de lalgorithme de Dijkstra de recherche du plus court chemin dans un graphe. Pour les r eseaux complexes, OSPF permet le groupement de routeurs en zones distinctes, areas, qui etablissent des nuages autonomes qui routent les datagrammes entres eux, mais ne laissent pas ltrer leur trac interne de LSP. Se d egage ainsi une hi erarchie de routeurs, ceux qui sont au milieu de
9

Page 42

122

Routage dynamique dIP la zone, ceux qui en sont ` a la fronti` ere et assurent les echanges avec les autres zones, enn ceux qui assurent les echangent avec les EGP (comme BGP) pour le trac externe ` a lAS. Tous les echanges sont authenti es. Par ce biais, seulement les routeurs pr evus dans la conguration participent au routage. La technique dauthentication peut di erer dune zone ` a une autre (cf paragraphe 3.7.2) Enn, les echanges de donn ees sont structur ees autour dun protocole nomm e HELLO. Ce protocole applicatif est v ehicul e par deux adresses multicast (page 42) qui lui sont attribu ees : principalement 224.0.0.5 et 224.0.0.6 dans certains cas, voir le paragraphe 3.6). Le protocole est encapsul e directement dans les datagrammes IP, et le champ PROTO contient la valeur 89 (chier /etc/protocols).

3.2

RIP vs OSPF

Le choix de lun ou de lautre est assujeti ` a lexamen de ce qui les di erencie, que lon r esume dans les X points suivants : 1. RIP est limit e` a 15 sauts (hop), qui limite de facto la structure du nuage de routeurs ; 2. Il faut utiliser RIPv2 car RIPv1 ne supporte la notion de masque de sous-r eseau (Variable Length Subnet Mask ou VLSM) ; 3. Plus le nuage est important et les liaisons moins performantes (comme sur un WAN) plus la diusion p eriodique des tables de routages consomme des ressources (bande passante) ; 4. RIP converge beaucoup plus lentement quOSPF. La cons equence dun changement de la topologie peut mettre plusieurs minutes ` a etre compl` etement int egr ee, m eme avec lusage des adresses multicast, des mises ` a jours d eclench ees et du concept dhorizon partag e; 5. Le principe fondateur, nombre de sauts, ne tient pas compte des d elais de propagation, le plus court chemin en terme de nombre de sauts ne d esigne pas n ecessairement le chemin qui ore le meilleur d ebit, sauf si toutes les liens qui le composent sont de la m eme technologie (Ethernet 100BT par exemple) ; 6. Labsence de la possibilit e dune structuration des routeurs RIP en zones ne permet pas une structuration intelligente des grands r eseaux, surtout quand ils sont organis es avec des classes dadresses que lon puisse agr eger entres elles en supernet (page 40) ; 7. RIP na aucun m ecanisme able dauthentication des annonces, ainsi nimporte quel h ote du r eseau peut empoisonner lensemble avec des routes farfelues (ou malveillantes, ou les deux. . .) ; 8. Le calcul des routes est distribu e pour RIP, chaque routeur nayant quune vue partielle du nuage, alors que pour OSPF chaque routeur de

RIP vs OSPF la zone a une vue compl` ete de l etat de tous les liens et etablit lui-m eme le calcul des routes en se pla cant ` a la racine du graphe de destination. En synth` ese OSPF est plus performants sur les points suivants : 1. Pas de limitation en nombre de sauts, cette donn ee nentre pas en ligne de compte puisque ce sont des etats de liens qui sont propag es ; 2. Les etats de liens sont envoy es avec une adresse de destination multicast, et seules des mises ` a jour des etats qui changent sont envoy ees. La bande passante est pr eserv ee au maximum ; 3. OSPF converge tr` es vite, du fait de son m ecanisme de propagation rapide (ooding) des etats ; 4. Le calcul du plus court chemin peut conduire ` a des routes de m eme valeur et OSPF est capable de g erer alors ecacement l equilibre de la charge (load balancing) entre tous ces cheminements possibles ; 5. Lorganisation des grands r eseaux en zones est compl` etement possibles, ce qui dune part r eduit le trac des etats de liens et dautre part permet des regroupement plus logiques bas es sur les classes dadresses IP ; 6. Les informations echang ees entres routeurs peuvent etre authenti ees selon plusieures m ethodes, voir paragraphe 3.7.2 ; 7. Les routes peuvent etre etiquett ees, ainsi les routes en provenance des EGP seront trac ees et trait ees sp eciquement.

123

124

Routage dynamique dIP

3.3

Principe de propagation des etats

L etablissement des tables de routages d epend de la compl etude dune table appel ee link-state database, base de donn ees d etats de liens, pr esente ` a lidentique sur chaque routeur de la zone. Cette table est aliment ee par les etats de liens, Link State Packet (LSP), que senvoient les routeurs entres eux. Or cette distribution d epend du routage. . . Contrairement ` a ce que lon pourrait en d eduire, il ny a pas de probl` eme de pr ec edence entre ces deux op erations, car la strat egie de distribution repose sur lusage dune adresse de multicast, valable uniquement dans un LAN (page 42) donc qui ne d epend pas de l etat de la table de routage ! Chaque changement d etat sur un lien doit etre signal e au plus vite ` a tous les voisins except e celui qui a signal e le changement. Cest un proc ed e par inondation, ou ooding dans la litt erature. Intuitivement ce mod` ele de propagation semble rapide mais g en` ere potentiellement un nombre exponentiel de copies de chaque paquet. . . Pour eviter une temp ete pr evisible de LSP, lid ee initiale des concepteurs consiste ` a ajouter ` a chaque LSP un num ero de s equence : Chaque routeur conserve un trace du dernier num ero de s equence utilis e. Quand il g en` ere un nouveau LSP il incr emente cette valeur ; Quand un routeur re coit un LSP depuis un voisin, il compare son num ero de s equence avec celui eventuellement d ej` a pr esent dans sa base de donn ees. Si le num ero est plus ancien, il oublie le paquet, Si le num ero est plus r ecent il remplace eventuellement celui d ej` a pr esent en m emoire. Ce dispositif tend ` a mod erer la temp ete de mises ` a jour mais induit dautres interrogations : 1. Que faire quand on arrive ` a la valeur maximale du compteur (m eme avec des registre 64bits ca arrive un jour) ? Plus g en eralement comment d eterminer la relation dordre entre deux LSP de valeur a et b ? 2. Que se passe t-il quand un routeur red emarre ? Il annonce des LSP avec un num ero de s equence plus petit que ceux d ej` a en circulation et qui donc seront ignor es, m eme si plus pertinents. Cette constatation est voisine de la situation de deux parties dun m eme r eseau, s epar ees ` a la suite dune rupture de connectivit ee et qui se retrouvent mais apr` es que lun des compteurs soit repass e par 0 ?

Principe de propagation des etats Qui am` enent les r eponses suivantes : 1. Le num ero de s equence est un compteur, avec une valeur minimale et maximale nie. Quand la valeur maximale est atteinte, il repasse par z ero, exactement comme un counter de SMI (page 228, chapitre concernant SNMP). Ensuite, pour etablir une relation dordre entre les LSP, la r` egle suivante est adopt ee :
b n/2 n/2 + a n/2 + b n/2

125

a n

a b n

. 0, 1, 2..

0, 1, 2..

Zone o b serait plus ancien que a

Zone o a serait plus rcent que b

gure VII.07 Relation dordre entre deux LSP On peut d eclarer que le LSP b est plus r ecent que a si les conditions : |a b | < a<b
n 2

ou encore

|a b | > a>b

n 2

sont r eunies. Cest ce que sch ematise graphiquement la gure VII.07 ci-dessus ; 2. Pour r epondre ` a la deuxi` eme interrogation, on introduit une nouvelle donn ee : l age du LSP. Cest une valeur num erique (cod ee sur 16 bits selon la RFC 2328) positionn ee non nulle par le routeur qui emet le LSP. Chaque routeur qui re coit un LSP doit d ecr ementer l age dau moins 1 unit e et continuera ainsi dans le temps jusqu` a la valeur 0, ` l age 0 le LSP ne doit plus etre transmis mais peut participer A encore au calcul des routes, Nimporte quel LSP (en terme de num ero de s equence) qui arrive avec un age non nul peut remplacer un LSP d age nul. En r esum e: Quand un routeur R g en` ere un LSP, son num ero de s equence doit etre plus grand de 1 (modulo n, cette derni` ere valeur etant la valeur 32 maximale du compteur lui m eme, par exemple 2 1) que la pr ec edente s equence g en er ee. L age doit etre positionn e` a une valeur maximale.

126

Routage dynamique dIP Quand un routeur autre que R re coit le LSP, il laccepte en remplacement de tout LSP avec un plus petit num ero de s equence (donc plus ancien). Si l age du LSP stock e etait 0, le nouvel LSP le remplace de mani` ere inconditionnelle : on ne peut propager un LSP d age nul. Le v eritable algorithme est plus complexe, voir la RFC 2328 page 143, The ooding procedure.
Etape 1 :
A B C

Etape 2 :
A B C

Etape 3 :
A B C

gure VII.08 Propagation des LSP par inondation ou ooding La gure VII.08 montre un exemple simple de propagation dun changement d etat initi e par le nud C. En trois etapes tous les routeurs sont ` mis au courant. A l etape 2 on peut remarquer que les routeurs B,F et G sinterdisent de renvoyer le LSP ` a C, son emetteur. On remarque egalement que F et G senvoient le m eme paquet, mais celui issu de F a un age plus ancien, il sera donc oubli e imm ediatement, comme celui issu de G, pour la m eme raison. Le Nud E re coit le m eme LSP depuis B et F, le premier arriv e sera pris en compte, le deuxi` eme oubli e. M eme remarque pour D ` a la n de la troisi` eme etape.

Valeur des etats de liens La dur ee totale de ces trois etapes est pratiquement celle n ecessaire pour propager les datagrammes (donc fortement d ependante de la bande passante), de quelques milli-secondes ` a quelques centaines de milli-secondes, donc ! 3.3.1 Valeur des etats de liens

127

Le co ut des liens, nomm e egalement la m etrique, agit directement sur le choix dune route plut ot quune autre comme on le voit dans le paragraphe qui suit. Le constructeur Cisco pr econise10 une formule qui est reprise partout : cost =
100000000 bande passante en bps

bps signie bits per second. Ce qui signie quune liaison Ethernet ` a 10Mbits (dix milions de bits par seconde, un milion doctets par secondes) a un co ut de 108 /107 = 10. Le petit tableau ci-dessous indique quelques valeurs pour des d ebit connus : M edia Liaison s erie 56kbps T1 (s erie 1544 kbps) E1 (s erie 2048 kbps) Token ring 4Mbps Ethernet 10Mbps Token ring 16Mbps Ethernet 100Mbps ... Co ut 1785 64 48 25 10 6 1 ...

Bien entendu on peut toujours imposer manuellement sa propre valeur de co ut dune liaison, pour inuencer le routage !

3.4

Calcul du plus court chemin

Pour le fonctionnement de lalgorithme de Dijkstra nous invitons le lecteur ` a consulter lexcellente simulation mise ` a disposition par lUniversit e Pierre Mend` es France de Grenoble, ` a cette url (cliquer sur le bouton Appliquette ) :
http://brassens.upmf-grenoble.fr/IMSS/mamass/graphecomp/dijkstra.htm

3.5

Hi erarchie de routeurs

Les r eseaux ` a administrer peuvent etre vastes et complexes, dans ces conditions il est souvent pertinent de les regrouper en sous-ensembles. La
10

http://www.cisco.com/warp/customer/104/1.html

128

Routage dynamique dIP conception dOSPF permet de le faire, il sagit dun concept nomm e zone ou (area) et qui se traduit par une hi erarchisation du routage. Outre la structuration plus claire du r eseau global en sous r eseaux, lavantage de cette approche est egalement de diminuer le nombre de routes sur lequel porte le calcul de plus court chemin, et aussi de diminuer le trac des mises ` a jour, non n egligeable sur un r eseau vaste et complexe. La RFC pr ecise quune zone doit faire le lien avec toutes les autres, il sagit forc ement de la zone 0, qui joue donc le r ole de lar ete centrale (OSPF Backbone). De cette structuration d ecoule le fait que tous les routeurs nont pas le m eme r ole, certain sont au milieu dune zone et dautres ` a la fronti` ere entre deux zones, voire m eme ` a la fronti` ere entre le nuage OSPF et dautres m ecanismes de routage, vers dautres AS :
Area 2 Area 3

IR ABR BR Area 0 (Backbone OSPF) Autre routeur (RIP) ASBR Autre AS (BGP) ABR

IR

Area 1

gure VII.09 Organisation en zones Hi erarchie de routeurs La RFC pr ecise quatre types de routeurs dans ce cas de gure : Internal routers (IR) Cest le cas le plus simple dun routeur au milieu dun nuage ` a lint erieur dune zone. Il na quune seule base d etats de liens quil met ` a jour avec les autres routeurs de son voisinage ; Area border routers (ABR) Ces routeurs se trouvent attach es ` a au moins deux zones. Ils poss` edent autant de bases de donn ees d etats de liens quils ont dinterfaces connect es ` a des zones di erentes. Ces bases di` erent car elles concernent des nuages di erents. Elles doivent etre propag ees vers la zone 0 sous forme dune route r esum ee (summarized)

Fonctionnement ` a lint erieur dune zone qui utilise au mieux les possibilit e du CIDR. Bien entendu cela suppose que les r eseaux puissent etre aggr eg es entres eux ; Backbone routers (BR) Il sagit de routeurs qui sont raccord es au moins ` a la zone 0. LA RFC nest pas claire sur leur signication exacte. . . Autonomous system boundary routeurs (ASBR) Cest le (les) routeur(s) qui marque(nt) la fronti` ere dinuence de lIGP. Il peut etre en relation avec nimporte quel autre protocole de routage, par exemple RIP et BGP sur la gure VII.09 avec lesquelles il etablit des passerelles et echange des routes. Les usagers de lIGP ont besoin d echanges avec lext erieur (autres r eseaux, autres AS).

129

3.6

Fonctionnement ` a lint erieur dune zone

Le fonctionnement du m ecanisme dinondation ` a lint erieur dune zone, tel que nous lavons succintement d ecrit au paragraphe 3.3, induit que lors de la diusion dun LSP chaque routeur propage le changement d etat re cu 2 ` a son voisinage r eseau. Ce comportement induit un trac en N , si N est le nombre de routeurs sur le LAN en question. OSPF essaie de r eduire ce nombre ` a seulement N en faisant jouer un r ole particulier ` a lun des routeurs, le routeur d esign e, ou Designated Router (DR). Celui-ci re coit les mises ` a jours car il ecoute sur une autre adresse multicast, 224.0.0.6 (tous les routeurs OSPF d esign es) et si besoin est propage ` a nouveau cette information vers les autres routeurs du LAN, avec ce coup-ci ladresse 224.0.0.5 (tous les routeurs OSPF). Se pose imm ediatement la question de la panne eventuelle du routeur ` cet eet un DR, celle-ci bloquerait la mise ` a jour des bases d etats de liens. A routeur d esign e de sauvegarde est egalement elu, cest le Backup Designated Router, mis ` a jour en m eme temps que le DR mais qui reste muet sur le r eseau tant que le protocole HELLO na pas d etect e un dysfonctionnement du DR.
R DR BDR

gure VII.10 Propagation dun LSP, sans et avec un DR Sur la gure VII.10, sch ema de gauche, le routeur R propage un nouvel LSP ` a tous ses voisins, puis chacun propage ce quil a re cu vers les voisins

130

Routage dynamique dIP pour lesquels il na rien re cu. Le nombre de paquets est alors en th eorie celui N 1 11 du nombre de paires possibles , soit encore : N 2 , 10 pour cet exemple. Pour le sch ema de droite, le routeur DR a re cu un LSP et le diuse aux trois routeurs concern es. Notons que le BDR ne fait rien, il a egalement re cu la mise ` a jour mais sabstient de toute action tant que le DR est op erationnel. Avant de pouvoir etablir une hi erarchie entres eux et d echanger ecacement des etats de liens, les routeurs doivent d eterminer qui sont leurs voisins, autrement dit la topologie du r eseau qui les entoure. 3.6.1 Voisinage et adjacence

La RFC 2328 d enit une progression selon 8 etats (7 pour les r eseaux avec propagation par multicast) pour chaque routeur OSPF, avant de pouvoir echanger ecacement avec ses voisins. Il est utile den avoir connaissance pour diagnostiquer une situation. L etablissement (ou non) de ces etats repose sur la structuration du protocole HELLO, qui se d ecline en cinq types de paquets di erents, nous les examinons au paragraphe 3.7 Down Cest l etat initial, pr ealable ` a tout etablissement dune conversation avec le voisinage. Il indique quaucune activit e de voisinage na et e d etect ee depuis un moment ; Init Les routeurs envoient des paquets de type Hello ` a fr equence r eguli` ere (environ 10 secondes). La r eception dun tel paquet sut pour passer ` a cet etat. Dans la liste des voisins transmise dans le paquet le routeur nappara t pas, la communication reste uni-directionnelle ; Two-way Un routeur entre dans cet etat sil se voit dans le paquet Hello propag e par un voisin. La communication est alors bi-directionnelle. Cet etat est la relation de voisinage la plus basique. Pour pouvoir echanger des etats de liens et construire des routes, chaque routeur doit former une contigu t e (adjacency) avec chacun de ses voisins. Cest une relation avanc ee entre routeurs OSPF. Elle s etablit en commen cant par l etat suivant ; ExStart Cest le premier pas pour constituer une contigu t e de routeurs entre deux voisins. Le but de cette etape est de d ecider qui sera le ma tre et lesclave dans la relation. Des paquets de type DataBase Description echang ees, et le routeur ayant la plus forte paquet (cf page 131) sont valeur de RID (Router ID) gagne. Cette derni` ere valeur est fonction de ladresse IP la plus elev ee pour tous les interfaces du routeur, et dun coecient congur e manuellement (non d emocratique) ;
Cest le nombre de paires du triangle de Pascal http://fr.wikipedia.org/wiki/ Triangle_de_Pascal
11

Protocole HELLO Exchange Les routeurs s echangent lint egralit e de leur base d etats de liens ` a laide de paquets DBD ; ` ce stade les routeurs terminent de compl Loading A eter leur table de liens. Les etats qui ont besoin d etre rafra chis font lobjet de requ etes ` a laide de paquets de type Link-state request (LSR) auxquels sont r epondus des paquets de type Link-state update (LSU) (Voir paragraphe 3.7) qui contiennent les LSP, appel es LSA en pratique, cur du fonctionnement du protocole. Les LSU sont acquitt es par des Link-state acknowledgment (LSAck) ; Full Une fois atteint cet etat, ladjacence dun routeur avec un voisin est compl` ete. Chaque routeur conserve une liste de ses voisins dans une base de donn ees adjacency database.

131

3.7

Protocole HELLO

Le protocole HELLO est en charge de l etablissement et du maintien des relations de voisinage entre routeurs. Il sassure egalement que les communications entre chaque voisin sont bi-directionnelles. Comme nous lavons pr ecis e en introduction ce paquet est encapsul e dans un datagramme IP, donc en lieu et place dun protocole de transport (quil ne remplace pas). Des paquets de type HELLO sont envoy es ` a fr equence p eriodique sur tous les interfaces des routeurs. Les communications sont rep er ees comme etant bi-directionnelles si un routeur se reconnait dans la liste (des voisins connus) emise dans le paquet HELLO dun voisin. Le protocole sert egalement ` a l election du Routeur D esign e (DR). Sur les r eseaux permettant le multicast, chaque routeur sannonce luim eme en envoyant p eriodiquement des paquets HELLO. Ce dispositif permet aux routeurs voisins de se conna tre dynamiquement, de v erier continuellement laccessibilit e des voisins d ej` a connus. 3.7.1 Cinq types de paquets

Le protocole HELLO se compose principalement dun en-t ete de 6 mots de 4 octets (24 octets) et dun compl ement qui d epend du type de paquet. Ce type est d eni d` es le premier mot de len-t ete. Hello (type 1) Ce paquet etablit et maintient les relations de voisinage (adjacency information) ; DataBase Description paquet (type 2) (DBD) Sert ` a d ecrire le contenu des bases de donn ees d etats de liens des routeurs OSPF lors de l etablissement dune contigu t e de routeurs. De multiples paquets de ce type peuvent etre envoy es pour d ecrire lint egralit e de la base de donn ees ; Link-state request (type 3) (LSR) Une fois echang ee la descriptions de la base d etats, un routeur peut sapercevoir quune partie des liens sont

132

Routage dynamique dIP p erim es (date de fra cheur). Ce type 3 est alors utilis e pour requ erir du voisin une mise ` a jour. De multiples paquets peuvent etre envoy es ; Link-state update (type 4) (LSU) Ces paquets sont utilis es par le proc ed e dinondation pr esent e au paragraphe 3.3. Chacun deux transporte une collection de LSP (on les nomme egalement LSA) ` a destination du voisinage imm ediat. Pour rendre la proc edure dinondation ecace ces paquets doivent etre explicitement acquitt es par des paquets de type 5 ; Link-state acknowledgment (type 5) (LSAck) Chaque LSA envoy e est acquitt e par l emission dun paquet de type 5. Plusieurs acquittements peuvent etre combin es dans un seul paquet. Ladresse IP de destination peut prendre une valeur multicast ou unicast.
Type 1 24 octets pour la partie fixe 5 Type 1 : Hello 2 Type 2 : BDD Type 3 : LSR 3 4 Type 5 : LSAck Type 4 : LSU

gure VII.11 Organisation globale de len-t ete du protocole OSPF

En-t ete standard des paquets OSPF 3.7.2 En-t ete standard des paquets OSPF

133

Tous les paquets OSPF d emarrent par un en-t ete standard de 24 octets :
31 Version# Entete standard (6 mots de 4 octets) 24 23 Type 16 15 Packet length 0

Router ID

Area ID

Checksum

AuType

Authentication

Authentication

(Selon valeur de Type)

....

gure VII.12 En-t ete standard de 24 octets Version La valeur 2 est requise, cest la version du protocole. Type Une valeur comprise entre 1 et 5 qui d etermine la partie variable de len-t ete. Packet length Longueur du paquet en octets, y compris len-t ete. Routeur ID Cest lidentiant du routeur (RID). Area ID Cest le num ero de la zone. La repr esentation d ecimale point ee est utilis ee, par exemple pour la zone backbone ce champ vaut 0.0.0.0. Checksum Il porte sur la totalit e du paquet moins cette zone et les 8 octets du champ Authentication. AuType Tous les echanges sont authenti es. Ce champ en d ecrit la m ethode. Trois valeurs sont pr evues par la RFC : AuType Description 0 Pas dauthentication 1 Mot de passe en clair sur le r eseau 2 Crypto ` a partir dun secret partag e Authentication 64 bits qui sont utilis es selon la valeur du champ pr ec edent. 3.7.3 En-t ete des paquets HELLO

Un paquet de type 1 (Hello) est envoy e p eriodiquement sur tous les interfaces des routeurs qui participent au nuage OSPF. Lobjectif est de maintenir

134

Routage dynamique dIP les relations de voisinages et dadjacences comme vu pr ec edement. Cest une sorte de Keep-alive pour les besoins du protocole. Les octets de la gure VII.13 sont ` a placer en continuit e de ceux de la gure VII.12, pour former un en-t ete de 24 + 24 = 48 octets minimum. La taille saccro t ensuite de quatre octets par RID suppl ementaire de voisin.
31 16 15 Network Mask Hello Interval Options Router Dead Interval Designated Router Backup Designated Router Neighbor ... Rtr Prio 0

gure VII.13 En-t ete du paquet HELLO Network Mask Le masque de sous r eseau associ e` a linterface. Options Les options du routeur. Cinq bits sont utilis es seulement pour d ecrire des possibilit es annexes au fonctionnement global. Hello Interval Le nombre de secondes entre deux paquets de ce type. Rtr Prio La priorit e de ce routeur. Cest une valeur positionn ee manuellement dans la conguration et qui a un impact direct sur le r esultat de l election des DR et BDR. Une valeur 0 na aucun impact, alors que 255 assure quasiment le routeur d etre DR. Router Dead Interval Le nombre de secondes avant de d eclarer inatteignable un routeur devenu silencieux. Designated Router Cest ladresse IP du DR pour ce LAN. Ce champ est ` a 0.0.0.0 sil ny en a pas. Backup Designated Router Idem pour le BDR. Neighbor Il sagit de la liste des RID (Router ID) des voisins connus et de qui on a re cu r ecemment (cest ` a dire avec un d elai inf erieur ` a la valeur du champ Router Dead Interval) un paquet de type 1. La description des 4 autres types de paquets se trouve ` a lannexe A.3 de la RFC.

4 Bibliographie

135

Bibliographie

Pour en savoir plus : RFC 1058 Routing Information Protocol. C.L. Hedrick. June 1988. (Format : TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Status : HISTORIC) RFC 1247 OSPF Version 2. J. Moy. July 1991. (Format : TXT=433332, PS=989724, PDF=490300 bytes) (Obsoletes RFC1131) (Obsoleted by RFC1583) (Updated by RFC1349) (Also RFC1246, RFC1245) (Status : DRAFT STANDARD) RFC 2328 OSPF Version 2. J. Moy. April 1998. (Format : TXT=447367 bytes) (Obsoletes RFC2178) (Also STD0054) (Status : STANDARD) RFC 2453 RIP Version 2. G. Malkin. November 1998. (Format : TXT=98462 bytes) (Obsoletes RFC1723) (Also STD0056) (Status : STANDARD) Sites web : CISCO OSPF Design Guide http://www.cisco.com/warp/customer/104/1.
html

Algorithme de Bellman-Ford http://brassens.upmf-grenoble.fr/IMSS/

mamass/graphecomp/bellmannFord.htm

Algorithme de Dijkstra http://brassens.upmf-grenoble.fr/IMSS/mamass/

graphecomp/dijkstra.htm

Ouvrages de r ef erences : W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Christian Huitema - Le routage dans lInternet - EYROLLES Radia Perlman Interconnections Second Edition Briges, Routers, Switches, and Internetworking Protocoles AddisonWesley

136

Routage dynamique dIP

Chapitre VIII ements de r El eseaux

1 H otes ou services virtuels

HTTP

HTTP

HTTP

HTTP

ipC ipA ipB ipWWW

ipD Traffic HTTP

Consolidation possible sur un seul hote

gure VIII.01 Serveur(s) HTTP virtuel(s)

La machine B (dadresse IP xe ipB) h eberge par exemple le service HTTP dadresse ip ipWWW. Cette op eration est rendue possible si le syst` eme dexploitation de B autorise la notion dalias IP. Si les machines A, C et D ex ecutent egalement un serveur HTTP, elles peuvent potentiellement prendre le relais de la machine B, d` es lors que ladresse ipWWW aura et e retir ee de la machine B pour etre recongur ee sur lune dentres elles. Cette op eration peut se faire manuellement ou via un outil dadministration. Elle permet de faire transiter tr` es rapidement des services dune machine ` a une autre, sans rupture ou presque de la continuit e. Vu des clients il sagit toujours de la m eme machine, mais elle est virtuelle puisquelle nexiste pas physiquement. Les syst` emes dexploitations modernes facilitent la construction de ma-

138

ements de r El eseaux chines virtuelles. FreeBSD a un m ecanisme tr` es adapt e nomm e jail1 , autrement dit une prison. Cest une version tr` es am elior ee de la primitive unix chroot. Les jails permettent de virtualiser ` a la demande les services puisquils peuvent etre d emarr es ou stopp es ` a la demande. Solaris 10, poss` ede un m ecanisme qui fonctionne de la m eme 2 mani` ere. . .Nomm e zone . Aussi bien les zones de Solaris que les jails de FreeBSD peuvent utiliser des alias IP pour assurer leur autonomie sur le r eseau, mais ces deux m ecanismes manquent ` a ce jour dune virtualisation compl` ete de la stack IP qui leur permettrait davoir une route par d efaut dans chaque instance virtuelle du syst` eme, ce qui les rendrait beaucoup plus ind ependants de lh ote h ebergeur et autoriserait des congurations beaucoup plus souples. La consolidation des h otes A, B,C et D (et potentiellement en nombre bien plus grand encore) est possible de nos jours sur une seule machine. L enorme mont ee en puissance des processeurs multi-cores et de l evolution des architectures SMP3 dune part, et dautre part la maturit e des technologies de 4 virtualisation des syst` emes dexploitation Cette op eration permet d eviter l eparpillement des petits serveurs au prot de machines sur lesquelles on peut concentrer un eort de maintenance mat erielle plus grand tout en r ealisant m eme une economie d echelle pour le mat eriel. Au niveau de la maintenance des syst` emes dexploitation leort dadministration reste le m emes, puisque proportionnel au nombre dinstances en exploitation..

http://docs.freebsd.org/44doc/papers/jail/jail.html http://www.sun.com/software/whitepapers/solaris10/grid_containers.pdf 3 http://www.sun.com/smi/Press/sunflash/2005-01/sunflash.20050118.1.xml 4 Les produits commerciaux sont bien connus, lOpenSource nest pas en reste avec le projet XEN http://www.cl.cam.ac.uk/research/srg/netos/xen/
2

2 Tunnel IP

139

Tunnel IP
A Encapsulation dIP dans IP

gure VIII.02 Tunnel IP - Principe Le tunnel permet dencapsuler un protocole dans un autre de m eme niveau ou sup erieur. Pr ec edemment, page 30, nous avons d ej` a analys e lencapsulation des couches de la pile Arpa selon une progression naturelle de fonctionnalit es. Ici, si le principe dencapsulation est conserv e, la logique initiale de construction, elle, est bouscul ee. Par exemple on peut envisager dencapsuler IP dans de multiple protocole autres quEthernet, comme PPP5 , IP, dans une couche de transport comme TCP, voire m eme dans une couche applicative comme HTTP. Ce dernier exemple peut para tre contre nature et pourtant cela fonctionne. . . Construire un tunnel a un co ut : dune part celui de la perte despace de donn ees dans le datagramme (il faut loger un ou plusieurs en-t etes suppl ementaires et le MTU reste constant lui !) et dautre part celui du traitement suppl ementaire (d ecapsulation, analyse) engendr e par lajout de ces nouveaux en-t etes. En r esum e, construire un tunnel se traduit par une perte despace pour les donn ees dans les datagrammes et par une consommation accrue de cycles cpus pour traiter les en-t etes suppl ementaires. Heureusement le gain en fonctionnalit es pour le r eseau est substanciel, comme les exemples qui vont suivre t achent de lillustrer ! Les tunnels qui transitent par une couche de transport sont g er es par une application (par exemple sshd ou httptunnel). Aussi le trac de datagrammes remonte au niveau applicatif pour redescendre au niveau IP, ce qui a lavantage de pouvoir etre mis en uvre par un utilisateur nayant pas n ecessairement les droits de ladministrateur6 , mais par contre, outre une consommation suppl ementaire de cycles cpu et des changements de contexte enient d etre d edi e` a un seul inh erents ` a larchitecture logicielle7 , a linconv
Point to Point Protocol , lui -m eme eventuellement encapsul e dans de lEthernet (PPPoE RFC 2516) ou de lATM (PPPoA pour lADSL, RFC 2364) 6 Pour encapsuler IP dans IP par exemple, il faut pouvoir ecrire directement dans IP ce qui n ecessite une socket en mode raw et donc un uid 0 ` a lex ecution 7 Rappelons que les processus applicatifs standards sex ecutent en mode utilisateur, et que les transferts entre la couche de transport (dans le noyau) et la couche applicative seectuent via un jeu de primitives du syst` eme, voir la description des sockets de Berkeley page 251
5

140

ements de r El eseaux port (par exemple celui dune application non crypt ee comme pop au travers une liaison ssh. Il faut noter que depuis la version 4.3 dOpenSSH les tunnels sont possibles, non limit es ` a un seul port)8 . Encapsuler IP dans IP a lavantage de rester g en eraliste du point de vue des applications. Sur la gure VIII.02 le tunnel IP encapsule donc de lIP dans lui m eme. Pour les routeurs qui acheminent ce trac il sagit de datagrammes IP avec le type 4 (cf le chier /etc/protocols au lieu des types 1 (icmp) 6 (tcp) ou 17 (udp) plus habituels.

2.1

Tunnel IP avec linterface gif

La gure Romanchapter.03 illustre lencapsulation dIP dans IP gr ace ` a lusage du generic tunnel interface 9 . Il sagit dun pseudo-device (pas dinterface r eel associ e au device), qui permet dencapsuler de lIP (version 4 ou 6) dans de lIP (version 4 ou 6)10 . Le but de cet exemple de tunnel est de montrer un routage de datagrammes issus dun r eseau priv e, le 192.168.2.0/24 (RFC 1918), depuis la machine B (IPB ), vers la machine A (IPA ) et qui traverse un r eseau public rout e quelconque, non nomm e sur la gure, de telle sorte que A soit int egr ee au LAN 192.168.2.0/24. Par hypoth` ese la machine A sait comment router vers le 192.168.2.0/24. Un de ses interfaces r eseaux peut etre surcharg e avec une adresse dans cette classe C. Le r eseau 192.168.249.0/30 sert de r eseau dinterconnexion entre les deux machines. Concr` etement, il sagit dattribuer une adresse IP ` a chacun des pseudo-devices, qui ne soit pas d ej` a dans lun des r eseaux attach es ` a chacune des machines. Conceptuellement, il serait parfaitement possible dutiliser, par exemple, des adresses dans le 192.168.2.0/24, mais lauteur pr ef` ere lusage dun r eseau dinterconnexion qui permet de bien s eparer fonctionnellement les adresses IP qui constituent le tunnel en lui-m eme de celles qui sont amen ees ` a lemprunter. De plus, si on souhaite (et cest une quasi obligation quand on utilise des tunnels) ajouter un ltrage IP sur la machine B, il est beaucoup plus ais e pour la conception des r` egles de ltrage de consid erer lorigine des datagrammes ayant une adresse source dans le 192.168.2.0/24 uniquement derri` ere le ltre.

La mise en uvre dun tunnel au travers http pour contourner le ltrage en sortie dun site nest absolument pas recommand ee par lauteur de ces pages et laiss ee ` a la compl` ete responsabilit e du lecteur 9 man gif sous FreeBSD, NetBSD, OpenBSD ou Mac OS X 10 Nous avons d ej` a rencontr e un tel interface virtuel avec linterface de loopback lo0 page 75

Tunnel IP avec linterface gif Examinons maintenant quelle pourrait etre la conguration sp ecique ` a ce tunnel, Sur la machine A :
ifconfig gif0 create ifconfig gif0 inet tunnel IP(A) IP(B) ifconfig gif0 inet 192.168.249.1 192.168.249.2 netmask 0xfffffffc route add -net 192.168.2.0 192.168.249.2

141

Notez lajout de la route sp ecique vers le r eseau non directement raccord e. Puis, ex ecution des op erations sym etriques sur la machine B :
ifconfig gif0 create ifconfig gif0 inet tunnel IP(B) IP(A) ifconfig gif0 inet 192.168.249.2 192.168.249.1 netmask 0xfffffffc
A 192.168.249.1 192.168.249.2 gif0
fxp0 gif0 hem0

B .200 192.168.2.0/24

192.168.2.229 IP(A)

192.168.2.218 IP(B)

Datagrammes IPv4 non routables encapsuls dans des datagrammes IPv4 routables.

gure VIII.03 Tunnel IP - cas concr et Notez que la premi` ere ligne de conguration pr ecise la source et la destination r eelle des datagrammes alors que la deuxi` eme indique ladresse locale et distante des extr emit es du tunnel. Cest une ecriture particuli` ere, adapt ee au pilote de linterface gif0 pour la conguration des tunnels. Sur la machine B, on peut voir le r esultat de la conguration comme ca :
$ ifconfig gif0 gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280 tunnel inet IP(B) --> IP(A) inet 192.168.249.2 -> 192.168.249.1 netmask 0xfffffffc $ netstat -f inet -rn ... 192.168.249.1 192.168.249.2 UH 0 9779

gif0

Et sur la machine A (remarquez la plus petite valeur de MTU) :

$ ifconfig gif0 gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280 tunnel inet IP(A) --> IP(B) inet 192.168.249.1 -> 192.168.249.2 netmask 0xfffffffc $ netstat -f inet -rn ... 192.168.2.0/24 192.168.249.2 UGS 0 83 192.168.249.2 192.168.249.1 UH 1 8941

gif0 gif0

142

ements de r El eseaux Enn, si on examine11 sur les interfaces hme0 puis gif0 de B le passage des datagrammes dun ping, envoy es depuis A vers 192.168.2.200, lobservation pratique rejoint la th eorie : on retrouve bien sur linterface du tunnel (gif0) len-t ete 2, d ecapsul e de son en-t ete 1. Le datagramme est alors disponible au niveau de la pile IP de B pour etre rout e (routage direct12 ici) vers 192.168.2.200. Le tableau qui suit r esume le contenu des en-t etes observ ees : En-t ete 1 Src IPA Dst IPB Code ipencap(4) En-t ete 2 192.168.249.1 192.168.2.200 icmp

Sur linterface hme0

Sur linterface gif0

Src Dst Code

En-t ete 192.168.249.1 192.168.2.200 icmp

Remarques : Attention, les routeurs ltrants doivent etre sp ecialement congur es pour 13 laisser passer ce type de trac . Les core gateway le laissent passer. Il est int eressant de noter que le d eploiement dIPv6 est dabord bas e sur lencapsulation de trames de la version 6 dans des trames de la version 4, en attendant que tous les routeurs soient capables de router IPv6 nativement. Enn pour conclure, est-il n ecessaire de pr eciser que m eme encapsul es dans IP, nos datagrammes nen sont pas moins lisibles par des yeux indiscr ets ? Pour sen pr emunir il nous faut examiner une technologie compl etementaire. . . Dans le paragraphe suivant !

Avec tcpdump -i hme0 puis tcpdump -i gif0 par exemple Cf page 66 13 Pour un routeur de type cisco qui prot egerait la machine B, il faudrait ajouter des r` egles du genre permit ipinip host IPB IPA et permit ipinip host IPA IPB
12

11

IPsec et VPN

143

2.2

IPsec et VPN

IPsec est un protocole de s ecurit e inclus dans la couche IP elle-m eme. Il est d eni dans la RFC 2401. Ce paragraphe aborde bri` evement la question du point de vue du protocole et de sa place dans la pile Arpa, tout en laissant volontairement dans un certain ou les aspects li es ` a la cryptographie, 14 clairement absents des objectifs de ce cours . 2.2.1 IPsec dans quel but ?

IPsec est un point de passage oblig e pour tout administrateur de r eseau qui souhaite mettre en place une politique de s ecurit e. Dailleurs, pour faire le lien avec le paragraphe qui pr ec` ede, pr ecisons quIPsec encapsul e dans IP (formellement, un tunnel) porte un nom, le VPN ( Virtual Private Network ) ! Nous avons examin e comment un tunnel accro t l etendue dun r eseau au travers dautres r eseaux. Ajouter Ipsec introduit, entre autres, une dimension de s ecurit e tr` es utilis ee pour relier des machines - ou des r eseaux - physiquement localis es nimporte o` u il y a un acc` es IP, en r eseaux virtuels s ecuris es ! Cest pour cette raison quIpsec est un artefact incontournable de la panoplie s ecuritaire sur les r eseaux. Nous aurions pu conclure le chapitre sur IP page 47 par cette constatation que le protocole IP est lisible par tout le monde y compris par les indiscr ets et que quasiment nimporte quel bricoleur peut forger de faux datagrammes ( fake datagrams ) pour empoisonner un r eseau, voire d etourner les services dune machine. Ainsi, tout ce qui renforce la s ecurit e IP est une bonne chose, surtout ` a lheure des r eseaux wi dont les limites de port ee ne sont pas ma trisables. IPsec renforce la s ecurit e dIP sur plusieurs points : Condentialit e Les donn ees dIP (protocole de transport et donn ees applicatives) sont crypt ees, donc normalement non inspectables avec tout outil danalyse de r eseau accessible sur le r eseau lui-m eme. Authentication La source du datagramme ne peut etre quun seul emetteur, et non un interm ediaire non pr evu. Int egrit e La totalit e des donn ees est prot eg ee par une somme de contr ole (checksum), travail normalement d evolu ` a la couche de transport mais qui au niveau dIP permet d ecarter tout datagramme qui aurait et e modi e pendant son transport. Dispositif anti-rejeux pour eviter les attaques du type man-in-themiddle consistants ` a capturer un ou plusieurs datagrammes (crypt es) dans le but de les envoyer ` a nouveau pour b en ecier du m eme eet produit que lenvoi initial.
Les RFCs donn ees page 160 sont le bon point de d epart pour se documenter sur les aspects cryptographiques dIPsec
14

144 2.2.2 IPsec en r esum e

ements de r El eseaux

Ipsec (RFC 2401) est un assemblage de quatre protocoles : ESP ( Encapsulating Security Payload ) est d eni par la RFC 2406. Il assure la condentialit e par lusage dalgorithmes de cryptage comme DES (RFC 2405) , 3DES (RFC 2451), CAST-128 (RFC 2144) ou encore blowsh (RFC 2451), la liste nest pas exhaustive. . . Il faut juste noter quil sagit dalgorithmes bas es sur lexistence un secret partag e (manuellement dans un chier ou cr ee dynamiquement avec IKE, voir plus bas) entre les parties qui echangent des messages, et non sur l echange dune clef publique. Cette remarque a un impact sur la mani` ere avec laquelle on doit les congurer ! AH ( Authentication Header ) est d eni par la RFC 2402. Il assure lauthentication, cest ` a dire quil cherche ` a certier que les deux couches IP qui dialoguent sont bien celles quelles pr etendent etre, puis lint egrit e des donn ees par le calcul dun checksum. Il faut noter que ce dernier travail empi` ete largement sur les attributions de la couche de transport mais se justie compte-tenu des exigences inh erentes au fonctionnement dIPsec. IPcomp ( IP payload compression ) sert ` a compresser les donn ees avant de les crypter. Son action est rendue n ecessaire pour tenter de compenser la perte de la place occup ee par les en-t etes ajout es. Bien entendu IPcomp peut etre utilis e seul. IKE ( Internet Key Exchange ) est d eni par la RFC 2409. Ce protocole nest pas formellement indispensable au bon fonctionnement dIPsec mais lui apporte un m ecanisme d echange de clefs, au d emarrage des echanges et au cours du temps. Ainsi la clef de chirement nest plus d enie de mani` ere statique dans un chier mais change continuellement au cours du temps, ce qui est meilleur du point de vue de la s ecurit e. Du point de vue de ladministration syst` eme et r eseau, la mise en place 15 de ce protocole passe par lusage dun daemon , par exemple racoon, et par une ouverture de port UDP (isakmp/500) suppl ementaire dans le ltrage du r eseau. Une n egociation d ecrite dans la RFC 2409 se d eroule entre les h otes qui doivent dialoguer, ce qui peut entrainer une certaine latence au d ebut des echanges. eoriquement Les 32 bits de ladresse IP de destination16 permettent th dexprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de gures sont tous th eoriquement possibles, les impl ementations dIPsec ne supportent que lunicast. La cons equence est importante sur le d eploiement dIPsec, il est eectu e point ` a point plut ot que g en eralis e pour tout un r eseau.
15 16

Voir page 315 pour le fonctionnement des daemons R evision possible page 35

IPsec et VPN Ce travail est inclus dans ce qui est nomm e politique de s ecurit e dans la RFC 2401. Pour AH comme pour ESP, lajout de donn ees vient se placer entre len-t ete IP et les donn ees. Les deux protocoles peuvent etre utilis es ensembles ou s eparement, cest un choix qui rel` eve de la politique de s ecurit e. Pour en tenir compte, la n egociation qui a lieu lors de l etablissement dIPsec repose sur ce que la RFC appelle des SA ( Security Association ). Une SA est formellement un triplet unique constitu e dun index unique , le SPI

145

gure Romanchapter.04 En-t etes dIPsec

Standard IP TCP DATA

code=6(tcp) Avec AH IP AH TCP code=51(ah) DATA Donnes authentifies ESP Auth Donnes encryptes authentifies AH + ESP IP AH ESP TCP DATA ESP Auth

Avec ESP

IP ESP TCP code=50(esp)

DATA

code=6(tcp) code=50(esp) code=51(ah)

( Security Parameter Index ) sorte de num ero didentication IP suppl ementaire17 inclus dans len-t ete AH ou ESP, de ladresse IP du destinataire et du protocole ESP ou dAH. Si les deux protocoles doivent etre utilis es, il faut n egocier deux SAs. 2.2.3 Comment utiliser IPsec ?

Aux deux protocoles AH et ESP, sajoutent deux mani` eres dutiliser IPsec, soit directement dune machine ` a une autre, on parle alors de mode transport soit encore en lencapsulant dans un tunnel comme vu au paragraphe 2 page 139 et on parle de mode tunnel , plus connu sous le vocable VPN . La RFC 2401 indique que toute impl ementation se r eclamant dIPsec doit supporter les 4 associations qui suivent. La s ecurit e entre deux h otes qui supporte IPsec, au travers lInternet, en mode transport ou en mode tunnel. Les datagrammes peuvent avoir les structures suivantes :
Mode transport [IP1][AH][Transport][Data] [IP1][ESP][Transport][Data] [IP1][AH][ESP][Transport][Data]

gure VIII.05 Association 1

Internet * H1 * H2

intranet

intranet

Mode tunnel [IP2][AH][IP1][Transport][Data] [IP2][ESP][IP1][Transport][Data]

17

H=hote *=Supporte IPsec AH et/ou ESP

Voir page 50

146

ements de r El eseaux Remarque : En mode tunnel pour ce premier cas il ny a pas dobligation du support dAH et ESP simultan ement. Quand ils sont appliqu es tous les deux, il faut dabord appliquer ESP, puis AH aux datagrammes. gure VIII.06 Association 2
Internet * G1 * G2

Le mode tunnel est le seul requis ici. Nous avons donc une structure de datagramme qui a ces formes possibles :
Mode tunnel [IP2][AH][IP1][Transport][Data] [IP2][ESP][IP1][Transport][Data]

H1 intranet G=passerelle H=hote *=Supporte IPsec

H2 intranet AH et/ou ESP

Cest la combinaison des deux premiers cas, on ajoute la s ecurit e entre les h otes terminaux ` a celle d ej` a apport ee par les routeurs. La propagation du trac de type ISAKMP (protocole IKE) au travers les routeurs est un plus.

gure VIII.07 Association 3

* G1 * G2

* H1 intranet Internet

* H2 intranet

G=passerelle H=hote *=Supporte IPsec

AH et/ou ESP

gure VIII.08 Association 4

Hote isol dialup/ppp * H1 * G1

Internet AH et/ou ESP G=passerelle H=hote *=Supporte IPsec

H2 intranet

Ce dernier cas est celui dun poste isol e qui se raccorde par exemple ` a lintranet de son entreprise via un modem ou un acc` es IP non s ur, et qui utilise un protocole non crypt e comme AppleTalk, ou PoP, par exemple. Le mode tunnel est seul requis entre lh ote H1 et la passerelle G1. Ensuite, entre H1 et H2 on revient au premier cas.

IPsec et VPN 2.2.4 Impl ementation dIPsec

147

Limpl ementation dIPsec sur les machines FreeBSD et NetBSd est issue du projet KAME18 et est ainsi fortement li e au d eveloppement de la pile IPv6. Les protocoles AH, ESP et IPcomp sont inclus dans le noyau directement. La gestion des clefs seectue via une commande externe, setkey qui pilote une table de gestion des clefs situ ee elle aussi dans le noyau, gr ace ` a des socket de type PF KEY Les clefs sont soit plac ees de mani` ere semi-d enitive dans le chier de conguration dipsec lui-m eme (par exemple /etc/ipsec.conf soit con ee aux bons soins dun programme externe qui se charge de les cr ee et de les propager ` a laide du protocole IKE. Quelques daemons savent faire cela, notamment racoon du projet KAME. Si nous reconsid erons la gure VIII.03 les machines A et B jouent le r ole des passerelles G1 et G2 de la gure VIII.06 (association 2). Les chiers de conguration IPsec (AH et ESP) pourraient etre : Sur la machine A
spdadd IP(A) IP(B) any -P out ipsec \ esp/tunnel/192.168.249.1-192.168.249.2/require \ ah/tunnel/192.168.249.1-192.168.249.2/require; spdadd IP(B) IP(A) any -P in ipsec \ esp/tunnel/192.168.249.2-192.168.249.1/require \ ah/tunnel/192.168.249.2-192.168.249.1/require;

spdadd est une instruction de la commande setkey. Il faut d enir sa politique de s ecurit e, cest ` a dire ce que lon souhaite en entr ee (in), en sortie (out) puis un choix de protocole (esp, ah, ipcomp), un mode (tunnel ici) avec lentr ee et la sortie du tunnel, enn un niveau dusage (require ici indique que tous echanges doivent utiliser IPsec). Sur la machine B
spdadd IP(B) IP(A) any -P out ipsec \ esp/tunnel/192.168.249.2-192.168.249.1/require \ ah/tunnel/192.168.249.2-192.168.249.1/require; spdadd IP(A) IP(B) any -P in ipsec \ esp/tunnel/192.168.249.1-192.168.249.2/require \ ah/tunnel/192.168.249.1-192.168.249.2/require;

La clef de cryptage ne gure pas dans ce chier car lexemple utilise IKE pour cela, ` a laide de loutil racoon. Enn, un excellent document de conguration se trouve sur le site du projet NetBSD : http://www.netbsd.org/Documentation/network/ipsec/
18

http://www.kame.net/

148

ements de r El eseaux

Proxy

gure VIII.09 Proxy Le propos dun proxy est de concentrer le trac r eseau via une seule machine pour toute une vari et e de protocoles (telnet, http, smtp, . . .). Il existe des proxy sp ecialis es sur tel ou tel protocole, qui eectuent donc des t aches potentiellement tr` es complexes (par exemple squid pour http) ou tr` es g en eraux et donc moins performants sur chaque protocole (cf nat au paragraphe suivant). Tout le trac r eseau qui passe par un proxy sy arr ete pour en repartir. Les conditions de ce rebond peuvent etre param` etr ees par des r` egles dacc` es, ce qui en fait un el ement utile en s ecurit e des r eseaux (voir la RFC 1919). Section en chantier, pr ecisions en cours. . .

Translation dadresses

La p enurie dadresses IP est ` a lorigine du besoin de translation des adresses. Son principe se trouve d ecrit dans la RFC 1631. Un tel dispositif se situe g en eralement ` a la fronti` ere entre un r eseau de type priv e et un autre de type publique. Le cas le plus g en eral est lorsque le r eseau publique est linternet lui-m eme, et le r eseau priv e celui dune entit e quelconque abonn ee aux services dacc` es r eseau dun FAI, mais ce nest pas une obligation conceptuelle.
Rseau publique C R S Rseau priv

gure VIII.10 R translate dynamiquement des couples (adresse IP, num ero de port) Sur la gure 10 le r eseau priv e comporte plus dh otes que dadresses IP fournies dans le r eseau publique. Pour pouvoir se d evelopper en saranchissant de cette contrainte, lusage de la translation dadresses et de ports NAT et PAT, ou encore NAPT comme Network Address Port Translation est incontournable parce que le r eseau priv e est b ati avec des adresses non

Translation dadresse routables (cf page 34) de la RFC 1918, potentiellement illimit ees ` a l echelle dune entit e priv ee, m eme grande. . . R dispose de quelques adresses (un pool dune adresse au minimum) routables sur le r eseau publique, quil peut assigner aux h otes du r eseau priv e (C) qui initient une connexion vers le r eseau publique (S). Cette assignation peut etre dynamique ou statique. Un datagramme qui part de C vers S a une adresse source non exploitable sur le r eseau publique. R maintient une table, si C nest pas d ej` a associ e` a une adresse routable du pool allou e` a R, celui-ci lui en attribue une et modie ` a la vol ee ladresse source du datagramme, de telle sorte que le retour de S puisse etre rout e convenablement jusqu` a R. Puis R modie ladresse de destination du datagramme pour lui donner ladresse de C, sur le r eseau priv e. Si on fait lhypoth` ese que la plupart des h otes du r eseau priv e n etablissent pas simultan ement des connexions vers le r eseau publique, le pool dadresses publiques peut rester beaucoup plus petit que le nombre dh otes du r eseau priv e. Mais cette hypoth` ese est fragile consid erant les besoins toujours plus grands dacc eder ` a linformation r epartie. Ce premier m ecanisme se compl` ete alors dun second qui est le NAPT. En plus de traduire ladresse IP ` a la vol ee, R attribue egalement un num ero de port di erent. Ce dispositif autorise lusage simultann e dune m eme adresse IP publique par des milliers dh otes du r eseau priv e. Le fonctionnement de la translation dadresse et de port engendre une propri et e int eressante pour R : il ne laisse passer aucun paquet du r eseau publique vers le r eseau priv e qui ne soit pas la r eponse ` a une sollicitation venue du r eseau priv e, cest donc en standard un fonctionnement ` a sens unique. Cette propri et e peut etre remise en question, voir le paragraphe 4.2. Enn, du fait du changement dadresse source ` a laller puis dadresse de destination au retour du datagramme, le NAPT rend impossible lusage dIPSEC (page 143) entre une machine quelconque du r eseau publique et linterface de R dans ce r eseau et sur laquelle seectue le travail de translation (il a modication de len-t ete, ce contre quoi justement IPSEC est sens e nous prot eger. . .). Le seul moyen dans ce cas de gure est de passer par lusage dun tunnel, comme vu paragraphe 2 (page 139). Tous les routeurs modernes ont les fonctions de translation dadresses et de ports incluses dans leurs fonctionnalit es standards.

149

150

ements de r El eseaux

4.1

NAPT sur un routeur de type PC avec natd

Natd est loutil logiciel libre bien connu des administrateurs r eseaux. Il 19 fonctionne selon le mod` ele de la gure 11 .
Adresses IP prives
if_int 10.33.93.1

Adresses IP NAPT
193.104.1.1

B publiques

if_ext 193.104.112.163

A
10.33.96.5

Internet

gure VIII.11 Machine NAPT en routeur Dans la gure 11, la machine NAPT est par hypoth` ese congur ee en routeur. Elle repr esente la route par d efaut pour la machine A. Natd convertit les adresses IP ` a la vol ee. Un datagramme voit ses adresses sources (et eventuellement de destination, voir plus loin) changer dynamiquement. Examinons en d etail les composantes dune connexion etablie depuis A vers B, donc lors dun trac sortant vis ` a vis de R. Pour la machine A La machine A sadresse directement ` a la machine 193.104.112.163 en utilisant son routeur par d efaut. Lutilisateur de la machine A voit la connexion soit la forme : {tcp, IP H ote A, port A, IP H ote B, port B} Pour la machine B La machine B voit une connexion arriver en provenance de NAPT . La machine B na pas connaissance de la machine A, elle dialogue avec la machine NAPT selon : {tcp, IP H ote B, port B, IP H ote NAT, port A} Pour la machine NAPT La machine NAPT a connaissance des 2 r eseaux, elle translate dynamiquement les adresses et les ports dans les deux sens. La machine NAPT fait le travail dun proxy transparent pour la couche 3 ISO puisque chaque connexion sy arr ete puis en repart sans conguration particuli` ere de la part de ladministrateur de A ou de B. La translation (ou IP masquerading ) seectue dynamiquement selon ladresse demand ee.
Les impl ementation commerciales que lon trouve dans les routeurs, si elles ne se congurent pas de la m eme mani` ere, ont des propri et es tr` es voisines en fonctionnement
19

Translation dadresse La translation dadresse seectue pour les datagrammes qui traversent linterface if ext. Le dialogue entre cette machine et les autres machines du r eseau priv e , via linterface if int ne fait pas lobjet dune translation dadresse. La situation de la machine A est plut ot celle dun poste client car non vu de lext erieur de son r eseau. Etre serveur est toutefois possible comme il lest expliqu e avec lusage de natd au paragraphe ??. 4.1.1 Interactions entre natd et le noyau

151

Lusage de natd sur un PC est un travail consommateur de ressources cpu parceque les datagrammes font lobjet de deux recopies et de deux changements de contexte suppl ementaires : ils sont trait es par un processus qui sex ecute en mode utilisateur. Sur la gure 12 le processus natd ouvre une socket en mode raw pour communiquer directement avec la couche IP : divertInOut = socket (PF INET, SOCK RAW, IPPROTO DIVERT) ; Le noyau IP, muni du m ecanisme ad equat 20 redirige tout le trac entrant et sortant dun interface r eseau, vers un num ero de port convenu ` a la conguration, par exemple le port 6668, ` a ajouter dans /etc/services : natd 6668/divert # Network Address Translation socket Natd lit tous les datagrammes et ne retient pour traitements que ceux qui sont ` a destination du port d edi e.
Processus

natd

Noyau

6668

Rgles de translation (/etc/natd.conf) Interface plac sous la gestion de natd

if_int if_ext

gure 12 Interactions entre natd et le noyau de FreeBSD Compte tenu du chier de conguration, les adresses IP des datagrammes ainsi que les num eros de ports sont re ecrits et reinject es dans le noyau IP qui les traite comme dautres datagrammes (routage, ltrage. . .).
Par exemple pour FreeBSD il faut ajoute loption IPDIVERT dans la conguration du noyau
20

152

ements de r El eseaux

4.2

Translation dadresses vers le r eseau priv e

Les gures qui pr ec` edent ne concernent que les connexions sortantes du r eseau priv e, mais on peut envisager linverse. Bien entendu vu du r eseau publique on ne voit que les adresses du pool attribu e au routeur R. Le m ecanisme de translation de port permet eventuellement de ventiler les connexions entrantes vers une ou plusieurs machines priv ees. Le crit` ere discriminant est le num ero de port demand e. On distingue deux attitudes, soit tout le ux entrant est redirig e sur une seule machine, soit il est est eectu e en fonction du port, donc du service demand e. ` linsu des utilisateurs de La litt erature appelle ce cas le static nat . A la machine NAPT du r eseau publique, tout le trac IP (cest ainsi quil faut comprendre ladresse IP 0.0.0.0) est renvoy e sur la machine S, et celle-ci nest pas visible du r eseau public.
Partie prive du rseau NAPT IP(S) Hote accessible
Hote distant

Partie publique du rseau

if_ext

Internet

gure VIII.13 Static Nat

Translation dadresse La conguration du natd pourrait etre : natd -interface if ext -redirect address IP(S) 0.0.0.0 La gure 14 nous montre un exemple de trac eclat e en fonction du service demand e, ce qui permet une gestion beaucoup ne des ressources du r eseau. Une demande de connexion de lh ote distant R sur la machine NAT et au port 80 va etre r eachemin ee vers la machine interne HTTP et sur le port que lon souhaite, par exemple 8080. M eme remarque pour les deux autres services pr esent es. La machine HTTP voit la connexion en provenance de la machine R sous sa forme exacte : {tcp, IP H ote R, Port R, IP H ote HTTP, 8080} La machine R ne voit que la partie publique de la connexion : {tcp, IP H ote R, Port R, IP H ote NAT, 80} La conguration NAPT pourrait ressembler ` a:
# # Configuration multiservices # redirect_port tcp http:8080 80 redirect_port tcp smtp:25 25 redirect_port tcp dns:domain domain redirect_port udp dns:domain domain

153

Partie prive du rseau http NAPT

Hote accessible

Hote distant R

Partie publique du rseau

smtp

dns

Internet

gure 14 Conguration multiservices

4.3

NAPT sur un routeur CISCO

Voir en travaux pratiques. . .

154

ements de r El eseaux

Filtrage IP

Le propos du ltrage IP est dappliquer des r` egles de ltrage ` a un ux de datagrammes IP an de prendre une d ecision qui est le plus souvent binaire : laisser passer ou ne pas laisser passer avec en option de conserver une trace de passage (des logs). Par son usage on cherche ` a prot eger un site ou une machine dun ux de datagrammes pour lesquels on suspecte que tous ne sont pas envoy es par des utilisateurs bienveillants. Le ltre seorce d eliminer le trac ind esirable ` a partir de consid erations ` a priori, mais il ne repr esente pas la panac ee en mati` ere de s ecurit e sur les r eseaux, autrement dit il ne faut pas penser quun ltre IP sut ` a r` egler tous les probl` emes de s ecurit e dun site ou dun h ote. En eet, ` a partir du moment o` u le ltre laisse passer certains datagrammes, m eme ` a priori innocents, une porte est ouverte au d etournement de lusage initial du service oert. Dans ces conditions il faut se rendre ` a 21 l evidence : il ny a pas de s ecurit e absolue sur le r eseau ! Dans la litt erature, un routeur ltrant est nomm e FireWall , quil faut traduire en pare-feux . Le ltrage IP est une caract eristique essentielle de tout routeur digne de ce nom ! Il est aussi possible de faire du ltrage IP avec les Unix libres, cest cette approche qui est choisie dans les paragraphes qui suivent parcequaccessible ` a toutes les bourses. . . Si les d etails de mise en uvre di` erent dune impl ementation ` a une autre, le fond du probl` eme reste le m eme. Limpl ementation choisie ici est ipfw, le ltre natif de FreeBSD22 . Il existe dautres ltre, notamment ipf, encore une fois le principe reste toujours le m eme.

5.1

Filtrage IP sur un routeur CISCO

Voir en travaux pratiques. . .

5.2

Le cas dipfw de FreeBSD

Le ltre IP en question est impl ement e dans le noyau, il est activ e d` es lors que loptions IPFIREWALL est ajout ee dans le noyau. On peut egalement y adjoindre loption IPFIREWALL VERBOSE pour le rendre bavard23 , ce quappr ecient par dessus tout les administrateurs r eseaux, soucieux davoir une connaissance pr ecise de la nature du trac sur leurs r eseaux. . . Le ltre est un module du noyau, charg e au d emarrage, et qui se param` etre ` a laide de la commande ipfw. Celle-ci est utilis ee dans les scripts de d emarrage pour dicter au noyau les r` egles de ltrage, lues dans un chier nomm e
21 22

Les seuls r eseaux s urs sont isol es du monde ext erieur dans une cage de Faraday. . . http://www.freebsd.org 23 Via syslogd

Filtrage IP par defaut /etc/rc.firewall. les scripts de d emarrage pour dicter au noyau les r` egles de ltrage, Etablir des r` egles de ltrage IP sous-entend avoir une connaissance exhaustive de tous les el ements qui sy rattachent : Nom des interfaces r eseaux impliqu ees Protocoles r eseaux employ es (tcp, udp, icmp,. . .) Protocoles applicatifs autoris es (smtp, domain, http. . .) Adresses IP, num ero de ports, masque de sous-r eseaux Sens du trac par rapport aux interfaces ci-dessus

155

Il est assez ais e de mettre en place un ltrage simple, par contre cette op eration peut devenir complexe d` es lors quon utilise des protocoles applicatifs compliqu es, mettant en jeux une strat egie dutilisation des ports et des adresses non triviale. Consid erons un site simple, comme celui de la gure VIII.15. La machine C acc` ede depuis lext erieur ` a la machine S, prot eg ee par le ltrage IP activ e sur la machine R, qui agit donc en tant que routeur ltrant.

Rseau protg
Interface ed1
193.104.1.225 193.104.1.228

Rseau publique R
ipfw
193.104.1.1

http dns smtp ntp

Interface ed0

Internet

gure VIII.15 Conguration simple de ltrage

Adaptons-y les r` egles du mod` ele de base, extraites du chier /etc/rc.firewall de la conguration standard dune machine FreeBSD r ecente (cest un script shell). Lexamen de ces r` egles nous permet de d ecouvrir la nature du trac autoris e ou non.

156

ements de r El eseaux

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

# Interface externe oif="ed0" onet="193.104.1.0" omask="255.255.255.224" oip="193.104.1.1" # Interface interne iif="ed1" inet="193.104.1.224" imask="255.255.255.224" iip="193.104.1.225" # Ne pas laisser passer le spoofing ipfw add deny all from ${inet}:${imask} to any in via ${oif} ipfw add deny all from ${onet}:${omask} to any in via ${iif} # Ne ipfw add ipfw add ipfw add ipfw add ipfw add ipfw add pas router les adresses de la RFC1918 deny all from 192.168.0.0:255.255.0.0 to any via ${oif} deny all from any to 192.168.0.0:255.255.0.0 via ${oif} deny all from 172.16.0.0:255.240.0.0 to any via ${oif} deny all from any to 172.16.0.0:255.240.0.0 via ${oif} deny all from 10.0.0.0:255.0.0.0 to any via ${oif} deny all from any to 10.0.0.0:255.0.0.0 via ${oif}

# Laisser passer les connexions TCP existantes ipfw add pass tcp from any to any established # Permettre larrive du courrier SMTP ipfw add pass tcp from any to 193.104.1.228 25 setup # Permettre laccs au serveur HTTP ipfw add pass tcp from any to 193.104.1.228 80 setup # Rejetter et faire des logs de toutes les autres demandes de connexion ipfw add deny log tcp from any to any in via ${oif} setup # Permettre ltablissement des autres connexions (via $iif). ipfw add pass tcp from ${inet}:${imask} to any setup in via ${iif} # Permettre le trafic UDP/DOMAIN vers/depuis les serveurs DNS externes ipfw add pass udp from any 53 to any 53 # Permettre le trafic NTP vers/depuis les serveurs de dates ipfw add pass udp from any 123 to any 123 # Permettre le passage de tous les paquets ICMP ipfw allow icmp from any to any # Tout ce qui nest pas explicitement autoris est # implicitement interdit (cf comportement par dfaut dipfw). ipfw deny ip from any to any

Quelques consid erations : Les r` egles sont parcourues de la premi` ere ` a la derni` ere, si aucune convient, laction par d efaut consiste ` a bloquer le trac (peut etre chang ee). D` es quune r` egle convient, elle est appliqu ee et le ltrage sarr ete. Le ltrage IP consomme des ressources cpu, donc pour am eliorer les performances il vaut mieux placer en t ete de liste les r` egles employ ees le plus couramment. Il faut remarquer que la machine 193.104.1.228 est visible depuis lext erieure et utilise une adresse ociellement rout ee. Une tentative dacc` es sur un service non autoris e se traduit par un mes-

6 Exemple complet sage derreur (syslogd). Par exemple supposons que lutilisateur de la station C ex ecute la commande suivante : telnet 193.104.1.228 Il va obtenir le message :
telnet : Unable to connect to remote host : Connection timed out

157

Tandis que ladministrateur du r eseau 193.104.1.0 va constater la tentative dintrusion par le message :
ipfw : 3310 Deny TCP Adr.IP H^ ote C :2735 193.104.1.228 :23 in via ed0

Par contre, si lintrusion consiste ` a d etourner lusage du service SMTP, ladministrateur du r eseau 193.104.1.0 ne verra rien par ce biais puisque lacc` es SMTP est autoris e sur la machine 193.104.1.22824

Exemple complet

Dans cette partie nous examinons le cas de la conguration de la gure VIII.16, synth` ese des gures Romanchapter.13, Romanchapter.14 et Romanchapter.15. Cest une conguration tr` es employ ee du fait de la distribution parcimonieuse dadresses IP par les fournisseurs dacc` es.
Rseau priv non visible de lextrieur NAPT R
Interface ed1 ipfw
193.104.1.225 193.104.1.228 193.104.1.1

Rseau publique C

http dns smtp ntp

Interface ed0

Internet

gure VIII.16 Translation dadresse et ltrage IP Le propos est de mettre en place un routeur ltrant eectuant en plus la translation dadresses IP. La juxtaposition des deux services induit peu de changements dans la conguration des r` egles de ltrage.
24

Toute ressemblance avec la conguration r eelle de ce r eseau ne peut etre que fortuite

158 Commen cons par les r` egles de ltrage :

ements de r El eseaux

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

# Interface externe oif="ed0" onet="193.104.1.0" omask="255.255.255.224" oip="193.104.1.1" # Interface interne iif="ed1" inet="193.104.1.224 imask="255.255.255.224" iip="193.104.1.225" # # Usage de natd pour transformer tout ce qui passe sur linterface # "ed0" donc le subnet public. ipfw add divert 8668 all from any to any via ${oif} # Ne pas laisser passer le spoofing ipfw add deny all from ${inet}:${imask} to any in via ${oif} ipfw add deny all from ${onet}:${omask} to any in via ${iif} # Ne ipfw add ipfw add ipfw add ipfw add ipfw add ipfw add pas router les adresses de la RFC1918 deny all from 192.168.0.0:255.255.0.0 to any via ${oif} deny all from any to 192.168.0.0:255.255.0.0 via ${oif} deny all from 172.16.0.0:255.240.0.0 to any via ${oif} deny all from any to 172.16.0.0:255.240.0.0 via ${oif} deny all from 10.0.0.0:255.0.0.0 to any via ${oif} deny all from any to 10.0.0.0:255.0.0.0 via ${oif}

# Laisser passer les connexions TCP existantes ipfw add pass tcp from any to any established # Permettre larrive du courrier SMTP ipfw add pass tcp from any to 193.104.1.228 25 setup # Permettre le trafic TCP/DOMAIN ipfw add pass tcp from any to 193.104.1.228 53 setup # Permettre laccs au serveur HTTP ipfw add pass tcp from any to 193.104.1.228 80 setup # Rejetter et faire des logs de tout autre demande de connexion ipfw add deny log tcp from any to any in via ${oif} setup # Permettre ltablissement des autres connexions (via $iif). ipfw add pass tcp from ${inet}:${imask} to any setup in via ${iif} # Permettre le trafic UDP/DOMAIN vers/depuis les forwarders ipfw add pass udp from any 53 to 193.104.1.228 53 ipfw add pass udp from 193.104.1.228 53 to any 53 # Permettre le trafic DTP/NTP ipfw add pass udp from any 123 to 193.104.1.228 123 ipfw add pass udp from 193.14.1.228 123 to any 123 # Permettre le passage des paquets ICMP (ping, traceroute...) ipfw add pass icmp from any to any via ${oif} icmptype 0,3,8,11 ipfw add pass udp from any 3276865535 to any 3276865535 out xmit ${oif} ipfw add log icmp from any to any in recv ${oif} ipfw add pass icmp from any to any via ${iif} # Tout ce qui nest pas explicitement autoris est # implicitement interdit (cf comportement par dfaut dipfw). ipfw deny ip from any to any

Exemple complet Dans le principe lh ote 193.104.1.228 nest plus visible de lext erieur, les services sont en apparence h eberg es par la machine R qui se charge de re-router les datagrammes en modiant dynamiquement ladresse de destination. Dans lordre des op erations, la translation dadresses est eectu ee avant le ltrage IP. Ce sont donc des adresses IP modi ees qui sont introduites dans les r` egles de ltrage ! Terminons avec la conguration de natd. Voici le contenu du chier /etc/natd.conf pour cette situation :
redirect_port redirect_port redirect_port redirect_port redirect_port tcp tcp tcp udp udp 193.104.1.228:80 80 193.104.1.228:25 25 193.104.1.228:53 53 193.104.1.228:53 53 193.104.1.228:123 123

159

O` u lon sapper coit que la conguration na pratiquement pas chang e fondamentalement ormis par lintroduction de la r` egle : ipfw add divert 6668 all from any to any via ${oif} Qui indique au ltre que tout ce qui provient de linterface oif est ` a lire sur le port 6668, donc a d ej` a subit la translation dadresse avant d etre soumis au ltrage IP. Ainsi une demande de connexion sur le port 25 de la machine 193.104.1.1 sera transform ee en une demande de connexion sur le port 25 de la machine 193.104.1.228, qui est autoris e. Pour lutilisateur de la station C la machine 193.104.1.228 nest plus visible, seule la machine dadresse 193.104.1.1 semble cumuler tous les services !

160

Protocole TCP

Bibliographie

RFC 1631 The IP Network Address Translator (NAT). K. Egevang & P. Francis. May 1994. (Format : TXT=22714 bytes) (Status : INFORMATIONAL) RFC 1918 Address Allocation for Private Internets. Y. Rekhter, B. Groot & E. Lear. February 1996. Moskowitz, D. Karrenberg, G. J.de (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE) RFC 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. (Format : TXT=56772 bytes) (Obsoleted by RFC2401) (Status : PROPOSED STANDARD) RFC 2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format : TXT=23539 bytes) (Status : PROPOSED STANDARD) RFC 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format : TXT=168162 bytes) (Obsoletes RFC1825) (Updated by RFC3168) (Status : PROPOSED STANDARD) RFC 2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. (Format : TXT=52831 bytes) (Obsoletes RFC1826) (Status : PROPOSED STANDARD) RFC 2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998. (Format : TXT=54202 bytes) (Obsoletes RFC1827) (Status : PROPOSED STANDARD) RFC 2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998. (Format : TXT=94949 bytes) (Status : PROPOSED STANDARD) RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE). L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format : TXT=32537 bytes) (Status : INFORMATIONAL) RFC 3168 The Addition of Explicit Congestion Notication (ECN) to IP. K. Ramakrishnan, S. Floyd, D. Black. September 2001. (Format : TXT=170966 bytes) (Obsoletes RFC2481) (Updates RFC2474, RFC2401, RFC0793) (Status : PROPOSED STANDARD) RFC 1919 Classical versus Transparent IP Proxies . M. Chatel. March 1996. (Format : TXT=87374 bytes) (Status : INFORMATIONAL)

Bibliographie Sans oublier : W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Firewalls and Internet Security - William R. Cheswick, Steven M. Bellovin - Addison-Wesley 1994. Building Internet Firewalls - D. Brent Chapman and Elizabeth D. Zwicky - OReilly - 1995. Steven M. Bellovin - Addison-Wesley 1994.

161

162

Protocole TCP

Troisi` eme partie Protocoles applicatifs

Chapitre IX Serveur de noms - DNS

1 G en eralit es sur le serveur de noms

Sil est obligatoire dattribuer au moins une adresse IP ` a une pile ARPA pour pouvoir linterconnecter en r eseau avec dautres piles de m eme nature, en revanche, lui attribuer un nom symbolique nest absolument pas n ecessaire au bon fonctionnement de ses trois couches basses. Ce nommage symbolique est simplement beaucoup plus naturel pour nos cerveaux humains que la manipulation des adresses IP, m eme sous forme d ecimale point ee (adresses IP page 33). Il nintervient donc quau niveau applicatif, ainsi la majeure partie des applications r eseaux font usage de noms symboliques avec, de mani` ere sous-jacente, une r ef erence implicite ` a leur(s) correspondant(s) num erique(s). Ce chapitre explore les grandes lignes du fonctionnement de ce que lon nomme le serveur de noms , lien entre cette symbolique et ladressage IP qui lui est associ e. Pour terminer cette introduction, il nest pas innocent de pr eciser que le serveur de noms est en g en eral le premier service mis en route sur un r eseau, tout simplement parceque beaucoup de services le requi` erent pour accepter de fonctionner (le courrier electronique en est un exemple majeur). Cest la raison pour laquelle lusage dadresses IP sous la forme d ecimale point ee reste de mise lors de la conguration des el ements de commutation et de routage1 .

1.1

Bref historique

Au d ebut de lhistoire de lInternet, la correspondance entre le nom (les noms sil y a des synonymes ou alias ) et ladresse (il peut y en avoir plusieurs associ ees ` a un seul nom) dune machine est plac ee dans le chier /etc/hosts, pr esent sur toutes les machines unix dot ees dune pile Arpa. Ci-apr` es le chier en question, pr elev e (et tronqu e partiellement) sur une 2 a jour. On y remarque quil ne contient plus que ladresse machine FreeBSD `
1 2

Eviter un blocage d u` a linterrogation des serveurs de noms www.freebsd.org

166 de loopback en ipv6 et ipv4.

Serveur de noms - DNS

# $FreeBSD$ # # Host Database # # This file should contain the addresses and aliases for local hosts that # share this file. Replace my.domain below with the domainname of your # machine. # # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain

Au d ebut des ann ees 1980 cest le NIC3 qui g` ere la mise ` a jour continuelle de cette table (HOSTS.TXT), avec les inconv enients suivants : Absence de structure claire dans le nommage do` u de nombreux conits entre les noms des stations. Par exemple entre les dieux de la mythologie grecque, les plan` etes du syst` eme solaire, les h eros historiques ou de bandes dessin ees. . . Centralisation des mises ` a jour, ce qui entraine : 1. Une lourdeur du processus de mise ` a jour : il faut passer par un interm ediaire pour attribuer un nom ` a ses machines. 2. Un trac r eseau (ftp) en forte croissance (N 2 si N est le nombre de machines dans cette table) et qui devient rapidement ing erable au vu des bandes passantes de l epoque (quelques kilo bits par seconde), et surtout jamais ` a jour compte tenu des changements continuels. Dapr` es Douglas E. Comer, au milieu des ann ees 1980 (1986) la liste ocielle des h otes de lInternet contient 3100 noms et 6500 alias ! La forte croissance du nombre des machines, a rendu obsol` ete cette approche.

1.2

Syst` eme hi erarchis e de nommage

Lespace de noms, pr ealablement non structur e, est d esormais r eorganis e de mani` ere hi erarchique, sous forme dun arbre (et non dun graphe). Cette organisation entraine une hi erarchisation des noms de machines et des autorit es qui ont le pouvoir de les nommer, de les maintenir. Chaque nud de larbre porte un nom, la racine nen a pas. Les machines, feuilles de larbre, sont nomm ees ` a laide du chemin parcouru de la feuille (machine) ` a la racine (non nomm ee).
3

Network Information Center (http://www.internic.net/)

Syst` eme hi erarchis e de nommage Le s eparateur entre chaque embranchement, ou nud, est le point d ecimal. Voici un exemple de nom de machine : www.sio.ecp.fr Derri` ere ce nom il faut imaginer un point (.) qui est omis la plupart du temps car il est implicite4 . La lecture seectue naturellement de gauche ` a droite, par contre la hi erarchie de noms sobserve de droite ` a gauche. 1.2.1 Domaine & zone

167

Le r eseau peut etre consid er e comme une hi erarchie de domaines. Lespace des noms y est organis e en tenant compte des limites administratives ou organisationnelles. Chaque nud, appel e un domaine, est baptis e par une cha ne de caract` eres et le nom de ce domaine est la concat enation de toutes les etiquettes de nuds lues depuis la racine, donc de droite ` a gauche. Par exemple : fr ecp.fr sio.ecp.fr Domaine fr Domaine ecp.fr sous domaine du fr Domaine sio.ecp.fr sous domaine de ecp.fr

Par construction, tout nud est un domaine, m eme sil est terminal, cest ` a dire na pas de sous domaine. Un sous domaine est un domaine ` a part enti` ere et, except ee la racine, tout domaine est un sous domaine dun autre. Bien que le serveur de noms, Domain Name Server fasse r ef erence explicitement au concept de domaine, pour bien comprendre la conguration dun tel service il faut egalement comprendre la notion de zone . Une zone est un point de d el egation dans larbre DNS, autrement dit une zone concerne un sous arbre du DNS dont ladministration lui est propre. Ce sous arbre peut comprendre plusieurs niveaux, cest ` a dire plusieurs sous domaines. Une zone peut etre confondue avec le domaine dans les cas les plus simples. Dans les exemples ci-dessus, on peut parler de zone sio.ecp.fr puisque celle-ci est g er ee de mani` ere autonome par rapport ` a la zone ecp.fr. Le serveur de noms est concern e par les zones . Ses chiers de conguration5 pr ecisent la port ee de la zone et non du domaine. Chaque zone doit avoir un serveur principal ( master ) qui d etient ses informations dun chier congur e manuellement ou semi manuellement (DNS dynamique). Plusieurs serveurs secondaires ( slave ) recoivent une copie de la zone via le r eseau et pour assurer la continuit e du service (par la redondance des serveurs). Le fait dadministrer une zone est le r esultat dune d el eguation de pouvoir de ladministrateur de la zone parente et se concr etise par la responsabilit e de congurer et dentretenir le champ SOA ( start of authority , page 183) de la-dite zone.
4 5

Sauf justement dans les chiers de conguration du serveur de noms, voir plus loin named.boot vs named.conf

168 1.2.2 Hi erarchie des domaines

Serveur de noms - DNS

Cette organisation du nommage pallie aux inconv enients de la premi` ere m ethode : Le NIC g` ere le plus haut niveau de la hi erarchie, appel e aussi celui des top levels domains (TLD). Les instances r egionales du NIC g` erent les domaines qui leur sont d evolus. Par exemple le NIC France 6 g` ere le contenu de la zone .fr. Le nommage sur deux lettres des pays est issu de la norme ISO 31667 . Chaque administrateur de domaine (universit es, entreprises, associations, entit es administratives,. . .) est en charge de son domaine et des sous domaines quil cr ee. Sa responsabilit e est nomminative vis ` a vis du NIC. On dit aussi quil a lautorit e sur son domaine ( authoritative 8 for the domain )

Racine non nomme Sens de lecture com

arpa

edu

gov

int

mil

net

org

ae Emirats Arabes Unis

fr

zw Zimbabwe

Domaines du niveau le plus lev (TLD)

inaddr

Domaines du second niveau

ecp

138

Contour de zone

cti

sio

195

Domaines gnriques

Domaines nationaux

10

52

52.10.195.138.inaddr.arpa.

http://www.nic.fr/ On peut les voir en d etail ` a cette adresse http://www.nw.com/zone/ iso-country-code 8 Une base de donn ees sur les administrateurs de DNS est entretenue par les NICs, cest la base whois , interrogeable par lutilitaire du m eme nom. Consulter le site http: //www.ripe.net/ pour plus dinformations, egalement man whois sur une machine unix
7

2 Fonctionnement du DNS gure IX.01 Organisation hi erarchique des domaines Les eventuels conits de nommage sont ` a la charge des administrateurs de domaine. Du fait de la hi erarchisation, des machines de m eme nom peuvent se trouver dans des domaines di erents sans que cela pose le moindre probl` eme. Le nom www est de loin le plus employ e 9 , pourtant il ny a aucune confusion possible entres ces machines, comme par exemple entres les machines www.ecp.fr et www.sio.ecp.fr. Chaque domaine entretient une base de donn ees sur le nommage de ses machines. Celle-ci est mise ` a disposition de tous les utilisateurs du r eseau. Chaque site raccord e de mani` ere permanente proc` ede de cette mani` ere, ainsi il ny a pas une base de donn ees pour lInternet mais un ensemble structur e de bases de donn ees reli ees entres elles et formant une gigantesque base de donn ees distribu ee.

169

2
2.1

Fonctionnement du DNS
Convention de nommage

La RFC 1034 pr ecise que les noms de machines sont d evelopp es un peu comme les noms dun syst` eme de chiers hi erarchis es (Unix,. . .) et utilisent les caract` eres ascii 7 bits assortis des contraintes suivantes : Le . est le s eparateur Chaque nud ne peut faire que 63 caract` eres au maximum ; le bon usage les limite ` a 12 caract` eres et commen cant par une lettre. Les majuscules et minuscules sont indi erenci ees. Les chires [0-9] et le tiret peuvent etre utilis es, le soulign e ( ) est un abus dusage. Le point . et le blanc sont proscrits. Les cha nes de caract` eres comme NIC ou dautres acronymes bien connus sont ` a eviter absolument, m eme encadr ees par dautres caract` eres. Les noms complets ne doivent pas faire plus de 255 caract` eres de long. Il y a des noms relatifs et des noms absolus , comme des chemins dans un syst` eme de chiers. Lusage du . en n de nom, qui indique un eserv e` a certains outils comme ping ou traceroute nommage absolu10 , est r et aux chiers de conguration du serveur de noms. En r` egle g en erale il nest pas utile de lemployer.
901 961 instances en janvier 2003 contre 1 203 856 instances en janvier 2002, selon le site du Network Wizards Internet Domain Suvey (www.nw.com), Top 100 Host Names 10 FQDN, comme Fully Qualied Domain Name
9

170 2.1.1 Completion

Serveur de noms - DNS

Sur un m eme r eseau logique on a coutume de ne pas utiliser le nom complet des machines auxquelles on sadresse couramment et pourtant ca fonctionne ! La raison est que le resolver , partie du syst` eme qui est en charge de r esoudre les probl` emes de conversion entre un nom de machine et son adresse IP, utilise un m ecanisme de compl etion ( domain completion ) pour compl eter le nom de machine simpli e, jusqu` a trouver un nom plus complet que le serveur de noms saura reconna tre dans sa base de donn ees. Le resolver connait par hypoth` ese le ou les noms de domaine (lus dans le chier de conguration /etc/resolv.conf) qui concernent la machine locale. Une station de travail nen a g en eralement quun seul alors quun serveur peut en comporter plusieurs, par exemple si on souhaite consolider toute une palette de services pour plusieurs domaines sur une m eme machine. Exemple dun tel chier : domain search nameserver nameserver nameserver sio.ecp.fr sio.ecp.fr., ecp.fr. 138.195.52.68 138.195.52.69 138.195.52.132

Plus g en eralement ce nom de domaine se pr esente sous forme d1 .d2 ...dn . Ainsi, en pr esence dun nom symbolique x, le resolver teste pour chaque i, i {1, 2, . . . , n} lexistence de x.di .di+1 ...dn et sarr ete si celle-ci est reconnue. Dans le cas contraire la machine en question nest pas atteignable. Exemple, avec le domaine ci-dessus : a) machine = www (requ ete) www.sio.ecp.fr = Succ` es ! b) machine = www.sio (requ ete) www.sio.sio.ecp.fr = Echec ! www.sio.ecp.fr = Succ` es !

2.2

Le Resolver

Le resolver d esigne un ensemble de fonctions11 plac ees dans la biblioth` eque standard (gethostbyname vu en cours de programmation invoque les fonctions du resolver ) qui font linterface entre les applications et les serveurs de noms. Par construction les fonctions du resolver sont compil ees avec lapplication qui les utilise (physiquement dans la libc, donc accessibles par d efaut).
res query, res search, res mkquery, res send, res init, dn comp, dn expand - Faire man resolver sur une machine unix
11

Le Resolver Le resolver applique la strat egie locale de recherche, d enie par ladministrateur de la machine, pour r esoudre les requ etes de r esolution de noms. Pour cela il sappuie sur son chier de conguration /etc/resolv.conf et sur la strat egie locale (voir paragraphe suivant) demploi des possibilit es (serveur de noms, chier /etc/nsswitch.conf, NIS,. . .).

171

Application Code utilisateur /etc/resolv.conf Requete UDP "Resolver" Reponse UDP

Serveur(s) de noms distant(s)

gure IX.02 Le resolver dans son environnement Le chier /etc/resolv.conf pr ecise au moins le domaine local assorti de directives optionnelles.

172

Serveur de noms - DNS

2.3

Strat egie de fonctionnement

La gure IX.03 illustre le fait que chaque serveur de noms a la ma trise de ses donn ees mais doit interroger ses voisins d` es quune requ ete concerne une zone sur laquelle il na pas lautorit e de nommage. Ainsi, un h ote du domaine R2 qui veut r esoudre une adresse du domaine R1 doit n ecessairement passer par un serveur interm ediaire pour obtenir linformation. Cette d emarche sappuie sur plusieurs strat egies possibles, que nous examinons dans les paragraphes suivants.

Subdivistion hirarchiques des domaines

Domaine R1 Domaines

Domaine R2

gure IX.03 Subdivision hi erarchique des domaines 2.3.1 Interrogation locale

La gure ci-dessous illustre la recherche dun nom dans le domaine local.

1 Processus

Serveur de noms local

gure IX.04 Interrogation locale

Strat egie de fonctionnement Un processus ( browser http par exemple) recherche ladresse dun nom de serveur. Sur les machines Unix cela se traduit par lappel ` a la fonction gethostbyname. Cette fonction est syst ematiquement pr esente dans la biblioth` eque standard (libc) et est donc accessible potentiellement ` a tout ex ecutable lors dune compilation. La fonction gethostbyname fait syst ematiquement appel au resolver d ej` a cit e. Cest donc toujours en passant par ce m ecanisme que les processus acc` edent ` a lespace de noms. Le resolver utilise une strat egie g en erale ` a la machine (donc qui a et e choisie par son administrateur) pour r esoudre de telles requ etes : 1. Interrogation du serveur de noms (DNS) si pr esent 2. Utilisation des services type YP (NIS) si congur es 3. Utilisation du chier /etc/hosts Cette strat egie est param` etrable en fonction du constructeur. Le nsswitch sous HP-UX12 ou Solaris13 permet de passer de lun ` a lautre en cas dindisponibilit e, le chier /etc/nsswitch.conf sous FreeBSD eectue un travail assez proche. Enn, quelle que soit larchitecture logicielle le resolver est congur e ` a laide du chier /etc/resolv.conf. Sur la gure IX.04 : 1. Le processus demande ladresse IP dun serveur. Le resolver envoie la demande au serveur local. 2. Le serveur local re coit la demande, parcequil a lautorit e sur le domaine demand e (le sien), il r epond directement au resolver . 2.3.2 Interrogation distante

173

1. Un processus demande ladresse IP dune machine. Le resolver envoie sa requ ete au serveur local. 2. Le serveur local re coit la requ ete et dans ce deuxi` eme cas il ne peut pas r epondre directement car la machine nest pas dans sa zone dautorit e. Pour lever lind etermination il interroge alors un serveur racine pour avoir ladresse dun serveur qui a lautorit e sur la zone demand ee par le processus. 3. Le serveur racine renvoie ladresse dun serveur qui a ociellement lautorit e sur la zone 4. Le serveur local interroge ce nouveau serveur distant. 5. Le serveur distant renvoie linformation demand ee au serveur local. 6. Le serveur local retourne la r eponse au resolver
12 13

Unix de Hewlett-Packard Unix de Sun Microsystems

174

Serveur de noms - DNS

Serveur de noms racine

1 Processus 6

4 Serveur de noms local L 5

Serveur de noms distant

gure IX.05 Interrogation distante Remarques importantes : Un m ecanisme de cache acc el` ere le processus ci-dessus : Si un processus redemande la m eme machine distante on se retrouve dans le cas dune interrogation locale , du moins pendant la dur ee de validit e des donn ees (cf page 186). Si un processus demande une machine du m eme domaine que la pr ec edente (mais pas du m eme nom ! :), les etapes 2 et 3 deviennent inutiles et le serveur local interroge alors directement le serveur distant. La dur ee de vie de ladresse du serveur distant est elle aussi assortie dune date limite dutilisation. Dans le cas g en eral les serveurs racines ne voient pas plus de 1 ou deux niveaux en dessous. Ainsi, si un processus demande A.B.C.D.net : 1. Le serveur racine donne ladresse dun serveur pour D 2. Le serveur pour D donnera peut etre ladresse dun serveur pour C et ainsi jouera le r ole de serveur racine de l etape pr ec edente. On dit egalement que le serveur L de la gure IX.05 fonctionne en mode r ecursif. 2.3.3 Interrogation par procuration

Le processus de recherche d ecrit au paragraphe pr ec edent ne convient pas dans tous les cas, notamment vis ` a vis des deux crit` eres suivants : 1. S ecurit e dun domaine 2. Conservation de la bande passante 1. La gure Romanchapter.05 montre le serveur local qui interroge directement les serveurs distants, cette d emarche pose des probl` emes de s ecurit e dans le cas dun domaine au sein duquel seuls un ou deux serveurs sont autoris es.

Hi erarchie de serveurs Par exemple le serveur de noms du domaine sio.ecp.fr ninterroge pas directement le serveur racine, il passe par le serveur ociel qui est piston.ecp.fr (138.195.33.3). 2. Le trac destin e au serveur de noms peut consommer une partie non n egligeable de la bande passante, cest pourquoi il peut etre strat egique de concentrer les demandes vers un seul serveur r egional et donc de b en ecier au maximum de leet de cache d ecrit pr ec edement.

175

2.4

Hi erarchie de serveurs

Si tous les serveurs de noms traitent de donn ees dun format identique, leur position dans larborescence leur conf` ere un statut qui se nomme : serveur racine ( root name server ) Un serveur ayant autorit e sur la racine de lespace de nommage. Actuellement il y a 13 serveurs de ce type, nomm es [A-M].ROOT-SERVERS.NET14 serveur primaire ( master ) Un serveur de noms qui a lautorit e pour un ou plusieurs domaines (est d etenteur dautant de SOA Voir page 183). Il lit ses donn ees dans un chier stock e sur disque dur, ` a son d emarrage. Ladministrateur du (des) domaine(s) met ` a jour les informations des domaines concern es depuis cette machine. serveur secondaire ( slave ) Dans le cas dune panne ou dun engorgement du serveur primaire, les serveurs secondaires re coivent en pr evision une copie de la base de donn ees. Strat egiquement il est pr ef erable de les placer en dehors du domaine, sur le r eseau dun autre FAI. Il peut y avoir autant de serveurs secondaires que souhait e, de lordre de trois ou quatre est souvent recontr e. Au d emarrage ils re coivent les informations du serveur primaire, ou ils les lisent sur leur disque dur sils ont eu le temps de les y stocker au pr ec edent arr et du serveur, et si elles sont encore valides. Par exemple, le serveur PISTON.ECP.FR a comme serveurs secondaires NS2.NIC.FR, SOLEIL.UVSQ.FR, MANOUL.CTI.ECP.FR.

2.5

Conversion dadresses IP en noms

On dit aussi questions inverses ( inverse queries vs reverse queries ). Cette possibilit e est indiqu ee comme optionnelle dans la RFC 1034 mais est n eanmoins bien commode voire m eme fr equement requise pour le client r eseau de services comme le courrier electronique, l etablissement de sessions ` a distance avec ssh ou m eme les serveurs de chiers anonymes (ftp). Si une machine est enregistr ee dans le TLD in-addr.arpa, cest un indicateur favorable quant ` a la qualit e dadministration du r eseau qui lh eberge, mais ne prouve rien quant aux bonnes intentions de son (ses) utilisateur(s).
14

chier named.root, par exemple dans le r epertoire /etc/namedb

176

Serveur de noms - DNS Il faut ajouter que le bon usage sur les r eseaux est de pr evoir une entr ee dans la zone reverse pour toutes les machines utiles et utilis ees dun r eseau accessible de lInternet. Le contraire provoque bien souvent la grogne (` a juste titre) des administrateurs. ` gauche de la gure on distingue Il faut reconsid erer la gure IX.01. A un domaine un peu particulier in-addr.arpa . Toutes les adresses sont exprim ees dans le top level domain : in-addr.arpa Du fait de la lecture inverse de larbre, les adresses IP sont exprim ees en mirroir de la r ealit e. Par exemple pour la classe B de lecp : 195.138.in-addr.arpa (Classe B 138.195) Le fonctionnement par d el egation est calqu e sur celui utilis e pour les noms symboliques (cest la justication de son insertion dans la gure ChapterRoman.01). Ainsi, on peut obtenir la liste des serveurs ayant autorit e sur la zone 195.138.in-addr.arpa en questionnant dabord les serveurs du TLD in-addr.arpa puis ceux pour la zone 138.in-addr.arpa, et ainsi de suite. . . Chaque administrateur de zone peut aussi etre en charge de ladministration des zones reverses , portion du domaine arpa , des classes dadresses dont il dispose pour nommer ses machines, sil en re coit la d el egation. Il faut bien noter que cette d el egation est une op eration ind ependante de celle qui a lieu pour les autres domaines. Notons egalement que la notion de sous r eseau (cf page 38) nest pas applicable au domaine in-addr.arpa , ce qui signie que les adresses selon les contours naturels des octets. Ainsi, pour les clients de fournisseurs dacc` es nayant comme adresses IP ocielles que celles d elimit ees par un masque de sous r eseau large seulement que de quelques unit es (< 254), la gestion de la zone reverse reste du domaine du prestataire (FAI) et non du client.

Conclusion

177

2.6

Conclusion

Quest-ce quun DNS ? Un serveur de noms repose sur trois constituants : 1. Un espace de noms et une base de donn ees qui associe de mani` ere structur ee des noms ` a des adresses IP. 2. Des serveurs de noms, qui sont comp etents pour r epondre sur une ou plusieurs zones. 3. Des resolver capables dinterroger les serveurs avec une strat egie d enie par ladministrateur du syst` eme. TCP ou UDP ? Le port 53 bien connu pour le serveur de noms est pr evu pour fonctionner avec les deux protocoles. Normalement la majeure partie du trac se fait avec UDP, mais si la taille dune r eponse d epasse les 512 octets, un drapeau de len-t ete du protocole lindique au client qui reformule sans question en utilisant TCP. Quand un serveur secondaire d emarre son activit e, il eectue une connexion TCP vers le serveur primaire pour obtenir sa copie de la base de donn ees. En g en eral, toutes les trois heures (cest une valeur courante) il eectue cette d emarche.

Mise ` a jour dynamique

La mise ` a jour dynamique de serveur de noms (RFC 2136) est une fonctionnalit e assez r ecente sur le r eseau, elle permet comme son nom lindique de mettre ` a jour la base de donn ee r epartie. Aussi bien au niveau du r eseau local qu` a l echelle de lInternet il sagit le plus souvent de faire correspondre un nom de machine xe avec une adresse ip changeante. Cest typiquement le cas dun tout petit site qui a enregistr e son domaine chez un vendeur quelconque et qui au gr e des changements dadresse ip (attribu ee dynamiquement par exemple avec DHCP15 ) par son fournisseur dacc` es, met ` a jour le serveur de noms pour etre toujours accessible. Avec comme mot clef dyndns , les moteurs de recherche indiquent lexistence de sites commerciaux ou ` a caract` ere associatif, qui proposent cette fonctionnalit e.

15

Cf http://www.isc.org/products/DHCP/

178

Serveur de noms - DNS

S ecurisation des echanges

Le serveur de noms est la clef de vo ute des r eseaux, et cest en m eme temps un de ses talons dAchille parceque les programmes que nous employons quotidiennement utilisent sans discernement linformation acquise du r eseau. En eet, quest-ce qui vous assure que le site web de votre banque sur lequel vous venez de taper votre mot de passe est bien le vrai site ociel de cet etablissement ? Lapparence de la page de garde ? Typiquement il y a deux situations de vuln erabilit e: 1. Dialogue serveur ` a serveur, notament lors de transferts de zones 2. Interrogation dun serveur par un resolveur Pour faire conance en ce que vous dit le serveur de noms interrog e il faut dune part que vous soyez certains dinterroger la bonne machine et dautre part que celle-ci soit d etentrice dune information incontestable. Cest une cha ne de conance, comme toujours en s ecurit e, qui remonte par construction du fonctionnement du serveur de noms interrog e par votre application (comme nous lavons examin e dans les paragraphes qui pr ec` edent) jusquaux serveurs racines. La version ISC (consultez le paragraphe 7) du programme BIND utilise deux strat egies di erentes, selon les cas ci-dessus. Dans le premier cas il sagit dun m ecanisme nomm e TSIG/TKEY, dans le deuxi` eme DNSSEC. TSIG/TKEY utilisent une clef sym etrique, donc partag ee par les deux serveurs (cette clef leur est connue par des m ecanismes di erents). DNSSEC utilise un m ecanisme bas e sur le principe dun echange de clefs publiques. Outre les dysfonctionnements d us ` a une information erron ee on observe 16 egalement des attaques de type d eni de service utilisant le fonctionnant intrins` eque du protocole (voir plus loin5).

4.1

TSIG/TKEY pour s ecuriser les transferts

Lusage dune clef sym etrique indique quil sagit dun secret partag e entre 2 serveurs. La m eme clef sert au chirement et au d echirement des donn ees. Le bon usage veut que lon d edie une clef ` a un certain type de transaction (par exemple le transfert dune zone) entre deux serveurs donn es. Cette mani` ere de proc eder se traduit donc rapidement par un grand nombre de clefs ` a g erer ce qui interdit un d eploiement g en eralis e sur lInternet. Pour eviter de trop longs temps de chirement, ce ne sont pas les donn ees ` a transf erer qui sont chir ees (de plus elles ne sont pas condentielles), mais leur empreinte ( ngerprints ) avec un algorithme de type MD5 ou SHA117 .
http://fr.wikipedia.org/wiki/D\unhbox\voidb@x\bgroup\let\unhbox\ voidb@x\setbox\@tempboxa\hbox{e\global\mathchardef\accent@spacefactor\ spacefactor}\accent19e\egroup\spacefactor\accent@spacefactorni_de_service 17 Ne pas h esiter ` a faire un man md5 ou man sha1 sur une machine Unix pour en savoir plus !
16

DNSSEC pour s ecuriser les interrogations Cette empreinte, seule, est crypt ee. Le serveur qui re coit un tel paquet sign e, calcule lempreinte du paquet avec le m eme algorithme, d echire celle jointe avec la clef secr` ete partag ee et compare les deux empreintes. Le r esultat de cette comparaison dit si les donn ees sont valides ou non. Lint er et de ces transferts sign es est que les serveurs secondaires sont certains de mettre ` a jour leur zones avec des donn ees qui proviennent bien du d etenteur du SOA et qui sont absolument semblables ` a ce qui a et e emis. 4.1.1 TSIG

179

TSIG comme Transaction SIGnature est la m ethode d ecrite dans la RFC 2845 et bas ee sur lusage dune clef sym etrique. La g en eration de cette clef peut etre manuelle ou automatis ee avec le programme dnssec-keygen . La propagation de cette clef est manuelle (scp. . .Eviter absolument lusage de tout protocole diusant un mot de passe en clair sur le r eseau), donc mise en place au coup par coup. TSIG sert egalement ` a la mise ` a jour dynamique ( dynamic update ), la connaissance de la clef par le client sert ` a la fois ` a lauthentier et ` a signer 18 les donn ees . 4.1.2 TKEY

TKEY, d ecrit dans la RFC 2930, rend les m emes services que TSIG tout en evitant le transport du secret (TSIG). Cette caract eristique est bas ee sur le calcul la clef sym etrique automatiquement avec lalgorithme de DieHellman plut ot que par un echange manuel 19 . Par contre, cet algorithme ` a base du tandem clef publique clef priv ee suppose lajout dun champ KEY dans les chiers de conguration du serveur. Comme dailleurs le m ecanisme suivant. . .

4.2

DNSSEC pour s ecuriser les interrogations

DNSSEC d ecrit dans la RFC 2535 permet : 1. La distribution dune clef publique (champ KEY) 2. La certication de lorigine des donn ees 3. Lauthentication des transactions (transferts, requ etes) Mis en place, le DNSSEC permet de construire une cha ne de conance, depuis le top level jusquau serveur interrog e par votre station de travail.
cf le programme nsupdate et la RFC 2136 On peut trouver une explication de cet algorithme sur ce site : http://www. rsasecurity.com/rsalabs/faq/3-6-1.html
19 18

180

Serveur de noms - DNS

Attaque DNS par amplication

Le fonctionnement repose sur UDP, protocole pour lequel len-t ete (page 84) est facilement falsiable, notamment sur ladresse de retour. Il est ainsi tr` es facile denvoyer une requ ete ` a un serveur, avec une adresse de retour qui est celle dune machine victime plut ot que la sienne :
Serveur de noms IPs

IPx Requete avec IPv comme adresse de retour Rponse une requete non pose par IPv

IPv

Machine assaillante

Machine victime

gure IX.06 R eponse ` a une requ ete non formul ee Sur la gure IX.06 la machine dadresse IPv re coit un message du serveur de noms dadresse IPs, non sollicit e. Il est bien evident quun seul message de ce type reste sans eet, cependant : 1. Le volume en octets de la r eponse peut etre consid erablement plus important que celui de la requ ete, notamment si le serveur de noms est congur e par lassaillant. Par exemple dun facteur 5 ou 10. 2. Lassaillant peut envoyer un tr` es grand nombre de requ etes ` a des serveurs ouverts en mode r ecursif pour toute requ ete ne portant pas sur les domaines sur lequels ils ont autorit e. La machine victime est alors submerg ee par un ot de r eponses qui saturent compl` etement ses acc` es r eseaux, cest une une attaque DNS par ameni de service sur le site qui la subit. plication20 et qui provoque un d Le sch ema densemble dune telle attaque est r esum e sur la gure IX.07. La machine assaillante (elles peuvent etre nombreuses, des centaines de milliers) bombardent les serveurs (S1, S2,. . .Sn) de fausses requ etes. Ces serveurs sont utilis es parcequils combinent deux propri et es int eressantes : 1. Ils sont ouverts aux requ etes ext erieures m eme et surtout celles qui ne portent pas sur leurs donn ees. Cette propri et e est h erit ee de l epoque ou lInternet etait encore un r eseau duniversitaires et dinformaticiens. Cette proprit e devrait tendre ` a dispara tre, mais cest loin d etre encore
20

http://www.isotf.org/news/DNS-Amplification-Attacks.pdf

Attaque DNS par amplication le cas21 puisque la conguration standard des outils lautorise et que les comp etences techniques ne sont pas assez nombreuses. 2. Ils utilisent un cache DNS. Leet de ce cache est que m eme si la machine source est isol ee du r eseau, les enregistrements lus, pourvu quils soient assortis dun temps de vie susant (TTL, page 183) peuvent continuer d etre exploit es.
Serveur de noms source IPs S1 S2 S3 S4 S5 Sn

181

IPx Requete avec IPv comme adresse de retour Rponse une requete non pose par IPv

IPv

Machine assaillante

Machine victime

gure IX.07 Attaque DNS par amplication Quelques remarques : 1. Le serveur de noms source nest pas n ecessairement complice, cest tout simplement un serveur avec de gros enregistrements. 2. Les serveurs S1 ` a Sn sont utilis es ` a leur insu mais une conguration soigneuse peut eviter cet abus dusage. 3. Une fois attaqu e le serveur victime ne peut pas faire grand chose. Ses services ne sont plus accessibles car le r eseau est satur e. 4. La parade avec un serveur de type Bind de lISC (page 186) consiste ` a explicitement limiter louverture ext erieure du serveur aux seules donn ees sur lesquelles il a autorit e 22 . Lacc` es aux donn ees dans le cache doit egalement etre prot eg e car dautres techniques existent pour peupler les caches, par exemple envoyer un mail qui n ecessite linterrogation du serveur source.

Un test sur son serveur depuis une machine hors de son r eseau local est possible ` a cette url http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl 22 Directives allow-recursion et allow-query-cache du chier de conguration

21

182

Serveur de noms - DNS

Format des Resource Record

Comme pour toute base de donn ees, le serveur de nom a un format pour ses champs, ou Resource Record , RR dans la suite de ce texte, d eni ` a lorigine dans la RFC 1035. En pratique toutes les distributions (commerciales ou libres) du serveur de noms conservent ce format de base de donn ees, la mise en uvre du serveur seule change (chier de conguration du daemon). Un serveur de noms a autorit e (responsabilit e du SOA) sur une ou plusieurs zones, celles-ci sont rep er ees dans ses chiers de conguration (named.conf ou named.boot selon les versions). Sil est serveur primaire dune ou plusieurs zones, le contenu de ces zones est inscrit dans des chiers ASCII ; leur syntaxe est succintement d ecrite dans le paragraphe suivant. Sil est serveur secondaire, le chier de conguration indique au server de quelle(s) zone(s) il est secondaire (il peut etre secondaire dun grand nombre de zones) et donc o` u (adresse IP) il devra aller chercher cette information. Cette action se traduit par ce que lon nomme un transfert de zone . Ce transfert est eectu e automatiquement ` a la fr equence pr evue par ladministrateur du champ SOA et donc connue d` es le premier transfert. En cas de changement sur le serveur principal, celui-ci avertit ( Notify ) ses serveurs secondaires de la n ecessit e de recharger la zone pour etre ` a jour. Le propos de ce qui suit nest pas de se substituer ` a une documentation nombreuse et bien faite sur le sujet, mais dapporter quelques el ements fondamentaux pour en aider la lecture. Le constituant de base dun serveur de noms est une paire de chiers ASCII contenant les enregistrements, les Resource Record . Ceux-ci sont en g en eral ecrits sur une seule ligne de texte (sauf pour le champ SOA qui s etale sur plusieurs lignes. Le marqueur de n de ligne (CR+LF) est aussi celui de la n de lenregistrement. Le contenu g en eral dun tel enregistrement a la forme suivante (les accolades indique des donn ees optionnelles) :
{name} {ttl} addr-class Record Type Record Specific data

Cinq enregistrements, ou Resource Record , ou en RR, sont absolument fondamentaux pour faire fonctionner un serveur de noms : SOA, NS, A, MX et PTR.

RR de type SOA

183

6.1

RR de type SOA

$(ORIGIN) sio.ecp.fr. name {ttl} addrclass @ IN

SOA SOA

Origin Person in charge sio.ecp.fr. hostmaster.sio.ecp.fr. ( 2007100801 ; Serial 10800 ; Refresh (3h) 3600 ; Retry (1H) 3600000 ; Expire (5w6d16h) 86400 ) ; Minimum ttl (1D)

SOA est lacronyme de Start Of Authority et d esigne le d ebut oblig e et unique dune zone. Il doit gurer dans chaque chier db.domain et db.adresse Le nom de cette zone est ici rep er e par le caract` ere @ qui signie la zone courante, rep er ee par la ligne au dessus $(ORIGIN) sio.ecp.fr. . La ligne aurait egalement pu s ecrire :
sio.ecp.fr. IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. (...)

Un probl` eme concernant cette zone devra etre signal e par e-mail ` a hostmaster@sio.ecp.fr (notez le . qui sest transform e en @). Les param` etres de ce SOA sont d ecrits sur plusieurs lignes, regroup ees entres parenth` eses. Le caract` ere ; marque le d ebut dun commentaire, qui sarr ete ` a la n de ligne. Les points en n de noms sont n ecessaires. Le num ero de s erie doit changer ` a chaque mise ` a jour de la zone (sur le serveur principal). Le Refresh indique la fr equence, en secondes, ` a laquelle les serveurs secondaires doivent consulter le primaire pour eventuellement lancer un transfert de zone (si le num ero de s erie est plus grand). Le Retry indique combien de secondes un serveur secondaire doit attendre un transfert avant de le d eclarer impossible. Le Expire indique le nombre de secondes maximum pendant lesquelles un serveur secondaire peut se servir des donn ees du primaire en cas d echec du transfert. Minimum ttl est le nombre de secondes par d efaut pour le champ TTL si celui-ci est omis dans les RR.

6.2

RR de type NS

Il faut ajouter une ligne de ce type ( Name Server ) pour chaque serveur de noms pour le domaine. Notez bien que rien dans la syntaxe ne permet de distinguer le serveur principal de ses secondaires. Dans le chier db.domaine :

{name}

{ttl}

addrclass IN IN IN

NS NS NS NS

Name servers name nsmaster.sio.ecp.fr. nsslave1.sio.ecp.fr. nsslave2.sio.ecp.fr.

184

Serveur de noms - DNS Dans le chier qui renseigne la zone reverse , par exemple db.adresse, on trouvera :

52.195.138.inaddr.arpa. IN 52.195.138.inaddr.arpa. IN 52.195.138.inaddr.arpa. IN

NS NS NS

nsmaster.sio.ecp.fr. nsslave1.sio.ecp.fr. nsslave2.sio.ecp.fr.

6.3

RR de type A

Le RR de type A, ou encore Address record attribue une ou plusieurs adresses ` a un nom, cest donc celui qui est potentiellement le plus fr equement utilis e. Il doit y avoir un RR de type A pour chaque adresse dune machine.

{name} gwsio

{ttl}

addrclass IN IN IN

A A A A

address 138.195.52.2 138.195.52.33 138.195.52.65

6.4

RR de type PTR

Le RR de type PTR, ou encore PoinTeR record permet de sp ecier les adresses pour la r esolution inverse, donc dans le domaine sp ecial IN-ADDR.ARPA. Notez le . en n de nom qui interdit la compl etion (il sagit bien du nom FQDN).

name 2 33 65

{ttl}

addrclass IN IN IN

PTR PTR PTR PTR

real name gwsio.sio.ecp.fr. gwsio.sio.ecp.fr. gwsio.sio.ecp.fr.

6.5

RR de type MX

Le RR de type MX, ou encore Mail eXchanger concerne les relations entre le serveur de noms et le courrier electronique. Nous examinerons son fonctionnement ult erieurement dans le chapitre sur le courrier electronique (cf page 205).

sio.ecp.fr. sio.ecp.fr.

IN IN

MX MX

10 20

smtp.ecp.fr. mailhost.laissus.fr.

RR de type CNAME

185

6.6

RR de type CNAME

Le RR de type CNAME, ou encore canonical name permet de distinguer le nom ociel dune machine de ses surnoms.

www.sio.ecp.fr.

IN

CNAME

msiobipro.cti.ecp.fr.

Dans lexemple ci-dessus, la machine www.sio.ecp.fr est un surnom de la machine msio-bipro.cti.ecp.fr. Le fait que ces deux appellations soient dans la m eme zone (ecp.fr.) naide en rien au bon fonctionnement du dispositif. La machine msio-bipro pourrait etre h eberg ee nimporte o` u ailleurs sur un autre r eseau dans une autre zone. . . ! Cette possibilit e est tr` es employ ee pour constituer des machines virtuelles, comme nous le verrons au chapitre VIII.

6.7

Autres RR. . .

Il existe dautres RR, entres autres HINFO , TXT, WKS et KEY, non trait es dans cette pr esentation parcequils napportent rien ` a la compr ehension du fonctionnement du serveur de noms. Le lecteur est fortement incit e ` a se reporter au Name Server Operations Guide pour plus dinformations.

186

Serveur de noms - DNS

BIND de lISC

LInternet Software Consortium23 est une organisation non commerciale qui d eveloppe et favorise lemploi de loutil Open Source comme BIND (acronyme de Berkeley Internet Name Domain ). Cette version libre du serveur de nom est la plus employ ee sur les machines Unix du r eseau, ce qui justie que lon sy int eresse. Elle fournit une version du daemon named et un resolver int egr e dans la libc. On peut ais ement installer ce logiciel sur ` a peu pr` es toutes les impl ementations dunix connues (cf le chier INSTALL du r epertoire src).
named nsupdate Rseau tcp/ip Transferts de zones, queries Mise jour dynamique de RRs
Signaux

Syslog

named rndc

named.conf named.root

localhost.rev db.192.168.192 db.terminal

/var/run/named.pid /var/run/ndc /var/tmp/* Contour logique du serveur de noms

gure IX.08 BIND de lISC

7.1

Architecture du daemon named

La gure IX.06 montre le sch ema g en eral de lorganisation logicielle du daemon named . Au d emarrage celui-ci lit sa conguration dans un chier qui peut se nommer named.boot ou named.conf selon que lon est en version 4.9.11, 8.3.6 ou 9.2.9 et les suivantes du logiciel24 . named.conf Cest le chier de conguration lu au d emarrage. Sa structure d epend de la version du logicielle, heureusement dans les deux cas la s emantique reste proche !
23 24

http://www.isc.org/ taper named -v pour les discerner entre-elles

8 Bibliographie named.root Ce chier contient la liste des serveurs de la racine, leur nom et adresse IP. localhost.rev Ce chier contient la base de donn ee du localhost . Personne ne poss` ede en particulier le r eseau 127, donc chacun doit le g erer pour lui-m eme. Labsence de ce chier nemp eche pas le serveur de fonctionner, mais ne lui permet pas de r esoudre 127.0.0.xx (o` u xx est le num ero de la machine courante, souvent 1). db.terminal Exemple de chier de base de donn ees pour le domaine factice terminal.fr qui est utile durant les travaux pratiques. Ce chier permet la convertion des noms en adresses IP. db.192.168.192 Ce chier contient la base de donn ees de la zone reverse pour le domaine terminal.fr, cest ` a dire le chier qui permet au logiciel de convertir les adresses IP en noms. rndc ou name server control utility est comme son nom lindique un outil dadministration du programme named lui-m eme. Cest une alternative ` a lusage direct des signaux. Le canal de communication entre les deux programmes est une socket unix AF UNIX vs AF LOCAL (cf cours de programmation page 251). Un certain nombre de signaux modient le comportement du serveur, ils seront examin es en travaux pratiques, tout comme les chiers lus ou ecrits dans les r epertoires /var/run et /var/tmp/. Enn la ` eche vers syslog signie que named utilise ce service pour laisser une trace de son activit e (cf cours sur larchitecture des serveurs). Enn, le BOG, cest ` a dire le Bind Operations Guide , d etaille le contenu des champs de la base de donn ees des versions 4.x et 8.x. Pour la version 9.x est distribu ee avec BIND 9 Administrator Reference Manual une documentation egalement tr` es bien faite.

187

Bibliographie

Quand on sait d ej` a , la page de man de named sut ` a v erier un point obscur ! Sinon il existe une documentation tr` es fournie sur le sujet, avec notamment : Kein J. Dunlap & Michael J. Karels Name Server Operations Guide Ce document est accessible sur le serveur de lInternet Software Consortium 25 By the Nominum BIND Development Team BIND 9 Administrator Reference Manual Version 9.1.3 26 Douglas E. Comer Internetworking with TCP/IP Volume I (chapter 18) Prentice All 1988
On trouve le BOG dans la distribution de bind ` a cette adresse : http://www.isc. org/products/BIND/ 26 on trouve egalement la derni` ere version de ce document sur le site de lISC
25

188

Serveur de noms - DNS Paul Albitz & Cricket Liu DNS and BIND OReilly & Associates, Inc. 1992 Installing and Administering ARPA Services Hewlett Packard 1991 W. Richard Stevens TCP/IP Illustrated Volume I (chapter 14) Prentice All 1994 Et pour en savoir encore plus. . . RFC 1034 Domain names - concepts and facilities . P.V. Mockapetris. Nov-01-1987. (Format : TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC1065, RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181) (Status : STANDARD) RFC 1035 Domain names - implementation and specication . P.V. Mockapetris. Nov-01-1987. (Format : TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136, RFC2137) (Status : STANDARD) RFC 1101 DNS encoding of network names and other types . P.V. Mockapetris. Apr-01-1989. (Format : TXT=28677 bytes) (Updates RFC1034, RFC1035) (Status : UNKNOWN) RFC 1123 Requirements for Internet hosts - application and support . R.T. Braden. Oct-01-1989. (Format : TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status : STANDARD) RFC 1713 Tools for DNS debugging . A. Romao. November 1994. (Format : TXT=33500 bytes) (Also FYI0027) (Status : INFORMATIONAL) RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE) . P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format : TXT=56354 bytes) (Updates RFC1035) (Updated by RFC3007) (Status : PROPOSED STANDARD) RFC 2535 Domain Name System Security Extensions . D. Eastlake 3rd. March 1999. (Format : TXT=110958 bytes) (Obsoletes RFC2065) (Updates RFC2181, RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445) (Status : PROPOSED STANDARD) RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) P. Vixie, O. Gudmundsson, B. Wellington. May 2000. (Format : TXT=32272 bytes) (Updates RFC1035) (Status : PROPOSED STANDARD) RFC 2930 Secret Key Establishment for DNS (TKEY RR) D. Eastlake 3rd. September 2000. (Format : TXT=34894 bytes) (Status : PROPOSED STANDARD)

Chapitre X Courrier electronique

G en eralit es sur le courrier electronique

Le courrier electronique, ou mail est lun des deux services les plus populaires sur le r eseau, avec le web. Cest aussi lun des plus vieux services du r eseau, bien avant que le r eseau existe sous la forme que lon pratique aujourdhui1 . La pr eface de la [RFC 822], document fondamental parmi les documents fondamentaux pour ce chapitre, laisse supposer lexistence de nombreux formats d echanges electroniques sur lArpanet, et ce avant 1977. Sa popularit e repose sur sa grande souplesse et rapidit e demploi. Il permet aussi bien les echanges professionnels que les echanges priv es ; son mode dadressage donne la possibilit e denvoyer un courrier ` a une personne comme ` a une liste de personnes ou encore ` a un automate capable de rediuser vers un groupe ( mailing-list ). De nombreux outils d evelopp es, ` a lorigine essentiellement sur le syst` eme Unix, autour de ce concept ouvrent un vaste champs de possibilit es aux utilisateurs de tous les syst` emes dexploitation, comme la ventilation des courriers par th` eme, le renvoi automatique, le r epondeur (pendant les absences), lacc` es ` a sa boite aux lettres depuis des endroits di erents, la r eception de fax,. . .La liste ne peut pas etre exhaustive ! Cest souvent pour avoir lusage du courrier electronique que les entit es (sil en reste) non encore reli ees ` a lInternet franchissent le pas. Lusage des autres services arrivent plus tard, si besoin est.

Un historique int eressant http://www.fnet.fr/history/

190

Courrier electronique

1.1

M etaphore du courrier postal - Lenveloppe

Un courrier postal (ou de surface, s-mail ) a fondamentalement besoin de ladresse du destinataire et de ladresse de l emetteur (pour la r eponse). Lusage du timbre et de lenveloppe r epondent ` a dautres crit` eres. Une fois dans la bo te aux lettres, lenveloppe est rout ee de la poste locale vers la poste la plus proche du destinataire, pour etre nalement d elivr ee par un facteur. Pour un courrier electronique les besoins sont quasiment identiques ! Le concept denveloppe est conserv e, il sagit de ladresse de l emetteur du courrier et de celle(s) du (des) destinataire(s), propag ees de mani` ere bien s epar ee du corps du message an que le protocole SMTP qui joue le r ole du service postale (Voir page 195) puisse router et nalement d elivrer le courrier ` a son (ses) destinataire(s). Il existe de tr` es nombreux outils pour lire/ ecrire un mail, des outils pour jouer le r ole du bureau de poste et/ou du facteur. Sous Unix le facteur est le syst` eme lui-m eme, le bureau de poste un programme nomm e sendmail2 . Il existe dautres alternatives non abord ees dans ce document, comme le programme qmail3 ou encore le programme postx4 .

1.2

Adresse electronique

Tous les courriers electroniques ont un destinataire pr ecis e par son adresse 5 ecise le nom du destinataire et le site electronique, ou E-mail . Celle-ci pr o` u il re coit son courrier electronique. Le nom du destinaire est une cha ne de caract` eres. Traditionnellement et pour des raisons techniques, sur le syst` eme Unix, le login de lutilisateur peut etre egalement le nom de sa boite aux lettres. Cette possibilit e est de moins en moins vraie ` a mesure que dautres syst` emes avec dautres logiques de fonctionnement existent egalement sur le r eseau (notamment la lecture du mail via un interface html ou encore lorsque le mail est d elivr e directement dans une une base de donn ees et non d elivr e dans un chier). Par exemple, il est assez fr equent de voir employer le nom complet (pr enom et nom de famille) pour d esigner linterlocuteur distant. La conversion ultime entre cette convention et la bo te aux lettres de lutilisateur est laaire du bureau de poste le plus proche , cest ` a dire le programme sendmail pour ce document (voir plus loin au paragraphe 4). Le caract` ere @ (lire at ) s epare lidenticateur du destinataire de la destination.
2 3

Version 8.13.5 en septembre 2005 http://www.sendmail.org/ http://www.qmail.org/ 4 http://postfix.eu.org/start.html 5 Terme francis e en m` el , ou couriel pour les documents administratifs. . . ;-)

2 Format dun E-mail - RFC 822 La destination est peut etre vide (il sagit alors dun destinataire sur la machine courante, ou dun synonyme ( alias ) que le sendmail local sait traiter), etre un nom de machine du domaine local, le nom dun autre domaine ou dune machine sur un autre domaine. Les adresses suivantes ont un format valide : user1 Destinataire local. user2@nom de machine Destinataire sur une machine du domaine courant (rappellez-vous, il existe un m ecanisme de compl etion dans le resolver page 170 !). user3@nom de machine.domaine Destinataire sur une machine particuli` ere dun domaine particulier (non forc ement local). user4@domaine Destinataire sur un domaine particulier (m eme remarque que ci-dessus). On devine ais ement que le fonctionnement du courrier electronique sur une machine distante est fortement li ee au bon fonctionnement du serveur de noms (chapitre IX). Qui plus est, lorsque seul un nom de domaine est pr ecis e ` a droite du caract` ere @ , une information manque apparemment quant ` a la machine susceptible de recevoir le mail. Le lecteur en qu ete de plus de pr ecisions trouvera une description exhaustive de la syntaxe dune adresse au paragraphe 6 de la [RFC 822].

191

Format dun E-mail - RFC 822

Les octets qui composent un courrier electronique ob eissent ` a une structure bien d enie par la [RFC 822] de David H. Crocker : un en-t ete et un 6 corps de message, s epar es par une ligne blanche (deux CRLF qui se suivent). Le contenu de len-t ete dans son int egralit e nest pas toujours spontan ement montr e par les outils qui nous permettent de lire et denvoyer du courrier electronique. Une option est toujours accessible pour ce faire, comme h sous mutt 7 . Une partie de len-t ete est g en er ee automatiquement par le programme qui se charge du transfert (le paragraphe suivant nous dira quil sagit dun MTA), une autre est ajout ee par le programme qui permet de composer le mail, le MUA, une autre enn est tap ee par lutilisateur lui-m eme. Len-t ete est constitu e de lignes construites sur le mod` ele : identicateur : [ valeur ] CRLF
6 7

Il sagit respectivement des caract` eres 13 et 10 de la table ASCII - cf man ascii http://www.mutt.org/ le MUA (Mail User Agent) pr ef er e de lauteur :-)

192

Courrier electronique Lidenticateur ne peut pas contenir le caract` ere : parcequil sert de s eparateur avec la partie droite. Il est constitu e de caract` eres ASCII cod es sur 7 bits et imprimables (cest ` a dire comprise dans le segment [33, 126]), except e lespace. Valeur est optionnelle. Lusage des majuscules ou des minuscules est indi erenci e.

Entte Donnes (DATA) du protocole SMTP

Entte ajoute automatiquement Entte ajoute par lutilisateur Ligne blanche ajoute automatiquement

Le message

Corps

(peut tre vide)

gure X.01 Format dun e-mail Lordre dapparition de ces champs est quelconque. Seule lorganisation de la gure X.01 doit etre globalement respect ee. Le lecteur soucieux dune description exhaustive de ce en quoi peut etre constitu e un en-t ete pourra se repporter au paragraphe 4.1 de la RFC (SYNTAX). Certains champs de len-t ete proviennent de la conguration du MTA, dautres sont cr ees en interne par le MTA lui-m eme, dautres enn sont g er ees par le MUA, donc accessible ` a lutilisateur nal.

2.1

Quelques champs couramment rencontr es dans les en-t etes

Type dinformation Destinataire(s) du courrier Origine du courrier Identication du courrier Cheminement du courrier Nature du contenu Divers Champs etendus Noms des champs To, Cc, Bcc From, Reply-To Message-ID Received, Priority Content-Transfer-Encoding, Content-Type Date, Subject X-

Quelques champs couramment rencontr es dans les en-t etes

193

To (The primary recipients) Il sagit du (des) destinataire(s) principaux du message ( recipient ). Ce champ peut eventuellement etre vide, le MTA prend alors une d ecision param` etrable pour le compl eter. La valeur undisclosed-recipient : ; est courante dans ce cas. Cc (Carbon copy) Ce champ est dans le fonctionnement un doublon de To, mais lusage en nuance le sens : cest une copie pour information qui est transmise au(x) destinataire(s) list e(s). Bcc (Blind carbon copy) Une copie du message est transmise au(x) destinataire(s) list e(s), sans que les destinaitaires principaux des champs To et Cc en soit inform es. From (The sender) il sagit de l emetteur du message. Le plus souvent il sagit dune seule personne, quand ce champ en liste plusieurs (le s eparateur est la virgule , ) le champ Sender doit pr eciser ladresse de celui qui a eectivement envoy e le message. Reply-To (Alternative reply address) Ce champ pr ecise une adresse alternative ` a celle du champ From pour lenvoi de la r eponse. Cette disposition est utilis ee par les robots de gestion des mailing-list, pour distinguer lauteur du message et le destinataire de la r eponse. Message-ID (Unique identier for message) Ce champ est cens e identi e de mani` ere unique le message. Il est fabriqu e d` es sa soumission au premier MTA (MSA). Il est constitu e traditionnellement de la mani` ere suivante : nombre de secondes.identificateur de queue@domaine nombre de secondes Correspond ` a la date courante en secondes cal8 cul ees depuis le 01/01/1970 identificateur de queue Identie la queue locale sur laquelle ce mail est d epos e en entr ee. domaine Cest le domaine d emission du message. Exemple : Message-ID: <20051104121857.GC44788@laissus.fr> Received (Trace routing of mail) Cest une trace du routage suivi par le message, depuis sa soumission jusqu` a sa d elivrance nale. Chaque MTA ajoute un champ de ce type. Le cheminement est ` a suivre en commen cant en n de len-t ete. Chaque champ est constitu e au minimum de from, le nom canonique de la machine de qui le MTA a re cu le message, de by le nom canonique du MTA qui a re cu le message et ajout e ce champ et enn de la date de la transaction.

Epoch pour les unixiens !

194 Exemple :

Courrier electronique

Received: from mailhost.sio.ecp.fr (mailhost.sio.ecp.fr [138.195.52.34]) by leopard.ecp.fr (Postfix) with ESMTP id A6C1D37C91 for <fr.laissus@laissus.fr>; Thu, 3 Nov 2005 13:56:58 +0100 (CET)

Priority (Determine timeouts in the queue) En fonction dune valeur qui est urgent, normal ou non-urgent les messages qui ne peuvent etre d elivr es imm ediatement sont plac es dans une le dattente dont la date dexpiration est dautant plus courte que le message est urgent. L emetteur du message re coit dabord un avertissement puis une erreur si le message nest pas d elivr e quand arrive la date dexpiration. Content-Transfer-Encoding (Auxiliary MIME encoding) Indique comment est encod e le corps du message pour supporter les caract` eres hors jeu ascii 7 bits (SMTP ne transporte que des caract` eres 7 bits). Des valeurs courantes sont base64, quoted-printable, 8bit,.... Content-Type (The nature of the body of the message) Ce champ indique comment est constitu e le corps du message. Par d efaut il est suppos e etre constitu e que de caract` eres 8 bits dont le bit de poids fort est sans signication (7 bits eectifs). Pour ecrire les caract` eres accentu es du fran cais, par exemplen il faut avoir un champ de cette forme Content-Type: text/plain; charset=ISO-8859-1 Dans ce cas, le corps du message ne contient que du texte. Le cas contraire est celui dun message qui contient des pi` eces jointes, une balise introduite en suppl ement dans len-t ete va servir ` a s eparer les di erentes parties du message comme dans : Content-Type: multipart/mixed; boundary="opJtzjQTFsWocga" La chaine opJtzjQTFsWocga sert alors de marqueur pour rep erer chaque partie du mail (corps du message et pi` eces jointes). Date (The origin date) Cest la date ` a laquelle le message a et e envoy e initialement. Ce champ est obligatoire. Subject (Topic of the message) Cest une courte cha ne de caract` eres qui r esume le message. Les MUA montre ce champ pour permettre une meilleure s election des messages avant de les lire. MIME-Version (This message conforms to MIME standards) Niveau de MIME pour lencodage du corps de message (voir page 197). X- Cest un en-t ete sp eciquement ajout e par le MUA ou par un processus de la cha ne de traitement du courrier. Un exemple parmi tellement dautre :
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2

Ajout e par un m ecanisme ext erieur au MTA, qui agit contre le spam, et nomm e le Greylisting9
9

http://projects.puremagic.com/greylisting/whitepaper.html

3 Protocole SMTP - RFC 821

195

Protocole SMTP - RFC 821

Le protocole SMTP, ou Simple Mail Transfer Protocol a comme objet le transport du courrier electronique de mani` ere able et ecace. Il est d eni dans la [RFC 821] de Jonathan B. Postel. Ind ependant par sa conception dun quelconque sous-syst` eme de transport, il est principalement aujourdhui encapsul e dans des paquets TCP ` a destination du port 25 (cf le chier /etc/services). Dans un pass e pas si lointain lacc` es r eseau de beaucoup de sites se r esumait au courrier electronique encapsul e dans des trames du protocole UUCP10 , donc sur liaison s erie via modem !

3.1

Protocole SMTP

SMTP est un protocole ASCII (7 bits, human readable ). La partie cliente de la transaction se connecte sur le port 25 du serveur et envoie des commandes auxquelles le serveur r epond par des codes num eriques qui indiquent le statut de la prise en compte de la commande. Cest pourquoi il est ais e de se connecter sur un MTA avec un simple 11 telnet :
$ telnet localhost 25 Connected to localhost. Escape character is ^]. 220 host.mondomain.fr ESMTP Sendmail 8.12.6; Mon, 20 Jan 2003 15:34:45 +0100 (CET) NOOP 250 2.0.0 OK QUIT 221 2.0.0 host.mondomain.fr closing connection Connection closed by foreign host.

Dans cet exemple le MTA est le programme Sendmail 12 , qui r epond ` a la connexion par un code 220 pour dire que le service est op erationnel ( service ready ), suivi du nom de la machine, de la banni` ere du programme, de la version de sa conguration, et de sa date courante. Puis lutilisateur a tap e la commande NOOP qui na dautre eet que de forcer le serveur ` a r epondre et renvoyer un code (250) pour dire que tout va bien. Enn Lutilisateur a tap e QUIT pour nir proprement la transaction. La r eponse du serveur est un code 221 pour signier la n canonique de la connexion.
http://fr.wikipedia.org/wiki/Unix_to_Unix_Copy_Protocol Attention toutefois de ne pas abuser de cette pratique car de nombreuses attaques de sites ont d emarr e par le pass e` a laide un d etournement de sendmail. Les administrateurs r eseaux sont donc attentifs au trac sur le port 25 ; il est pr ef erable de r eserver ce genre de tests uniquement sur son propre site. 12 http://www.sendmail.org/
11 10

196

Courrier electronique Dans un deuxi` eme essai nous utilisons loption -v du programme mail, pour visualiser les echanges entre le MUA (machine athome.mondomain.fr) et le MTA local (machine mailhub.mondomain.fr). Essayons :
$ sendmail -v user@mondomain.fr Subject: test Ca passe ? . <<<--- A taper pour marquer la fin du mail dans ce mode. EOT user@mondomain.fr... Connecting to mailhub.mondomain.fr. via relay... 220 mailhub.mondomain.fr HP Sendmail (1.37.109.4/user-2.1) ready at Mon, 26 Jan 98 14:08:57 +0100 >>> HELO athome.mondomain.fr 250 mailhub.mondomain.fr Hello athome.mondomain.fr, pleased to meet you >>> MAIL From:<user@mondomain.fr> 250 <user@mondomain.fr>... Sender ok >>> RCPT To:<user@mondomain.fr> 250 <user@mondomain.fr>... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . 250 Ok user@mondomain.fr... Sent (Ok) Closing connection to mailhub.mondomain.fr. >>> QUIT 221 mailhub.mondomain.fr closing connection

Et le courrier re cu, lu aussi avec mail :

Message 208/208 User Lambda Jan 26, 98 02:09:06 pm +0100

From user@mondomain.fr Mon Jan 26 14:09:08 1998 Received: from mailhub.mondomain.fr by athome.mondomain.fr with SMTP (8.8.7/8.8.7/f la.2.1) id OAA27655; Mon, 26 Jan 1998 14:09:08 +0100 (CET) Received: from athome.mondomain.fr by mailhub.mondomain.fr with SMTP (1.37.109.4/fl a-2.1) id AA06996; Mon, 26 Jan 98 14:08:57 +0100 From: User Lambda <user@mondomain.fr> Received: by athome.mondomain.fr Date: Mon, 26 Jan 1998 14:09:06 +0100 (CET) Message-Id: <199801261309.OAA27653@athome.mondomain.fr> To: user@mondomain.fr Subject: test Ca passe ?

Manifestement, ca passe ! :) Il est egalement int eressant dobserver ` a ce niveau que les caract` eres du courrier ont et e consid erablement enrichis par un en-t ete volumineux (relativement). En eet, chaque nud travers e (MTA), ajoute un champ Received permettant apr` es coup de suivre le trajet du courrier. Les autres champs

Protocole SMTP comme Date :, Subject : ou Message-Id : sont ajout es dans len-t ete par le MUA de l ecrivain du message. Cette partie de len-t ete ajout ee par le MUA dorigine est souvent destin ee ` a piloter le comportement du MUA du destinataire du message plus que pour etre lue. Cette attitude sest g en eralis ee au point de devenir assez compliqu ee et etre formalis ee dans un ensemble de r` egles baptis ees MIME comme Multipurpose Internet Mail Extensions ([RFC 2184]). La fonction la plus r epandue et la plus simple de MIME est dautoriser lusage des caract` eres accentu es (codage sur 8 bits ou plus) ` a lint erieur du corps du message (len-t ete SMTP reste cod ee sur 7 bits). Lutilisateur voit alors appara tre des lignes suppl ementaires comme celles-ci :
X-Mime-Autoconverted: from 8bit to quoted-printable by bidule.domain id SAA23150 X-MIME-Autoconverted: from quoted-printable to 8bit by mamachine.ici id QAA29283

197

Le quoted-printable est une forme possible du codage des caract` eres accentu es, d enie dans la [RFC 822]. Le plus souvent on trouve des lignes comme celles-ci :
Mime-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfert-Encoding: quoted-printable Content-ID: Content-ID: <Pine.FBSD.3.14.1592654.19971998X.domain> Content-Description: arlg.c

Dautres formes de MIME peuvent conduire ` a lex ecution dun programme ext erieur au MUA, ce qui constitue une dangereuse faille potentielle dans la s ecurit e des r eseaux, donc ` a eviter.

3.2

Principales commandes de SMTP

Exp erimentalement nous avons d ecouvert quelques uns des mots r eserv es du protocole : HELO, MAIL, RCPT, DATA, QUIT. Une impl ementation minimale de SMTP en comprend deux autres en plus : RSET et NOOP. Cest donc un protocole assez simple, du moins dans sa version de base. Les codes de retour sont organis es sur trois chires, le premier chire donne le sens g en eral de la r eponse, tr` es succintement ce qui d ebute par 1,2 ou 3 a une signication positive, 4 ou 5 signie une erreur. Une information plus d etaill ee se trouve ` a lannexe E de la RFC. Les cinq commandes d ecouvertes pr ec edement sutilisent toujours dans cet ordre. Examinons succintement leur usage : 3.2.1 Commande HELO

Synopsis : HELO <espace> <domaine> <CRLF> Cette commande est utilis ee pour identier l emetteur du mail. Largument qui suit, domain est le nom de la machine ou du domaine do` u provient la connexion.

198

Courrier electronique En r eponse le serveur envoie une banni` ere dans laquelle il sidentie et donne la date courante. Cette information est optionnelle, ce qui compte cest le code de retour pour conrmer laptitude au travail du serveur ! 3.2.2 Commande MAIL

Synopsis : MAIL <espace> FROM : <chemin inverse> <CRLF> Cette commande d ebute un transfert de mail. En argument sont transmis (chemin inverse) ladresse e-mail de l emetteur et la liste des machines qui ont relay e le mail courant. La premi` ere machine est la plus r ecente. Cette information est utilis ee pour renvoyer, sil y a lieu, une notication de probl` eme ` a l emetteur du mail. Par exemple : MAIL FROM:<@mailhub.ici:@mailhost.labas:Lambda@mondomain.fr> 3.2.3 Commande RCPT

Synopsis : RCPT <espace> TO : <destinataire> <CRLF> Cette commande est la deuxi` eme etape dans la proc edure denvoi dun mail. Il y a une commande de ce type par destinataire du courrier ( recipient ). Par exemple : RCPT TO:<Lambda@mondomain.fr> Il est int eressant de noter que les arguments de cette commande et ceux de la pr ec edente (MAIL) forment lenveloppe du mail (exp editeur et destinataire) comme nous en avons signal e lexistence conceptuelle page 190. 3.2.4 Commande DATA

Synopsis : DATA <CRLF> Apr` es r eception de la commande, le serveur lit les lignes de texte en provenance du client jusqu` a rencontrer la s equence <CRLF>.<CRLF> qui marque la n du message. Il faut remarquer que celui-ci comprend lint egralit e de la gure X.01. 3.2.5 Commande QUIT

Synopsis : QUIT <CRLF> Marque la n de la session et entraine la cl oture de la connexion.

Protocole SMTP

199

3.3

Propagation du courrier electronique

SMTP est d eni comme un protocole de transfert, donc un moyen pour router et d elivrer le message ` a son (ses) destinataire nal (naux).

MUA
utilisateur

LDA MTA MTA MSA

OS

OS

SMTP ou ESMTP MUA

utilisateur

gure X.02 MUA - MSA - MTA - LDA - OS MUA Mail User Agent ou encore mailer , cest le programme qui permet de lire et ecrire le corps du courrier et de param etrer quelques el ements de len-t ete, principalement ladresse du destinaire, et le sujet du message. Il existe un tr` es grand nombre de MUAs sous Unix, il est courant de rencontrer mail, mailx, elm, pine, mutt, mh, eudora, kmail, thundermail, sylpheed... Il y en a pour tous les go uts ! MSA Mail Submission Agent , cest une nouveaut e d enie par la [RFC 2476] et qui joue le r ole dinterface entre le MUA et le MTA. Lobjet du MSA est de s eparer les fonctions de transfert du courrier et dacceptation de nouveaux courriers emis depuis les MUA. Cette s eparation des t aches am eliore deux aspects : La s ecurit e Les nouveaux mails sont soumis ` a un daemon qui ne nex ecutent pas avec les droits du root13 . La conformit e aux standards Les messages proviennent de MUAs qui ne respectent pas forc ement tous les pr erequis de formulation des en-t etes. Le r ole du MSA est de v erier et de compl` eter ces en-t etes avant de soumettre les mails au MTA pour le routage. MTA Mail Transfer Agent , cest le programme que prend en charge le transfert du courrier. Sous Unix cest un daemon. Par exemple : MMDF, Smail, Zmailer, sendmail, postfix, qmail...
13

SUID bit

200

Courrier electronique Les MTAs ecoutent le r eseau sur le port 25 et dialoguent entre-eux avec le protocole SMTP (ESMTP14 ). LDA Local Delivery Agent , cest lentit e qui d elivre eectivement le mail, soit dans une boite au lettres soit dans une base de donn ees, par exemple une base Cyrus15 . OS Operating System , le syst` eme dexploitation sur lequel fonctionnent ces programmes. La gure X.2 illustre la possibilit e la plus simple d echange entre deux MTA : la connexion directe. Cela signie que le MTA de la station emettrice contacte le MTA de la station r eceptrice et lui d elivre directement le message. La vie r eelle est plus compliqu ee car elle tient compte de lorganisation hi erarchique des r eseaux et surtout de la s ecurit e qui est un aspect devenu important sur lInternet. Cela se traduit par un emploi g en eralis e de machines relais ou mailhub .

B@domaine2

MTA MTA
relay mail

Utilisateur A au travail.

MUA

SMTP/ TCP/IP

Station de lutilisateur A Stockage temporaire tant que le MTA du domaine 2 est inacessible.

Wild Internet !

SMTP/ TCP/IP Utilisateur B au travail.

MUA MTA MTA

relay mail

Stockage long terme sur le disque dur de la station.

Station de lutilisateur B Stockage temporaire tant que la station de B est inacessible.

gure X.03 Trajet dun mail Une telle machine concentre tous les courriers electroniques dun site, vers lext erieur et inversement. Elle a des avantages, notamment :
14 15

Extented SMTP http://asg.web.cmu.edu/cyrus/

Courriers ind esirables - Le spam Avoir une politique de s ecurit e concentr ee sur un petit nombre de ma16 chines expos ees , plut ot que sur toutes les stations du r eseau : le routeur ltrant nautorise les acc` es ext erieurs que sur le port smtp(25) de ces quelques machines d edi ees. Avoir une politique centralis ee pour le ltrage des contenus ind esirables (virus) et des emetteurs suspects (spams). Limiter le nombre de congurations compliqu ees de sendmail ` a un petit nombre de machines. Les stations des utilisateurs peuvent se contenter dune conguration standard plus facile ` a distribuer et ` a adapter automatiquement. Permettre de masquer plus facilement les machines internes du r eseau vis ` a vis de lext erieur. En clair, les courriers auront lair de provenir de cette machine plut ot que de la station dun utilisateur sur le r eseau interne. Ladresse de l emetteur aura la forme : user@domaine au lieu de : user@machine.domaine. Permettre le stockage interm ediaire du courrier en attente dune d elivrance : les stations des utilisateurs ne sont pas toujours en fonctionnement. Cette architecture est th eorique, en pratique il peut y avoir une hi erarchie de relay mail plus compliqu ee. Par exemple une grappe de machines distinctes suivant que le courrier entre ou sort du site, une arborescence de machines relais quand lentreprise est elle-m eme r epartie sur plusieurs sites g eographiques et ne poss` ede quune liaison vers lext erieur,. . .

201

3.4

Courriers ind esirables - Le spam

Le spam est laspect tr` es d esagr eable du courrier electronique. Par spam on d esigne ces innombrables courriers, le plus souvent ` a caract` ere commercial, qui envahissent nos boites aux lettres electroniques. Certaines estimations tablent sur au moins 30% de spam dans le trac mail mondial et cette estimation est r eguli` erement revue ` a la hausse. Deux questions se posent, comment le caract eriser et surtout comment l eviter ? 3.4.1 Caract eriser le spam

1. Un contenu commercial, publicitaire, nancier, ou qui tente de retenir lattention du lecteur ` a partir dune histoire dont lissue est toujours p ecuniaire et au d etriment du destinataire.
Ce qui nexclue pas bien entendu davoir une politique de s ecurit e pour le mail sur le r eseau interne
16

202

Courrier electronique 2. Une importante liste de destinataires. Le champ Cc : peut contenir par exemple des centaines de destinataires. 3. Un en-t ete de message truqu e. Par exemple le champ Message-ID : qui est cens e identier le message de mani` ere unique est absent ou incoh erent (page 193). 4. Un grand nombre dexemplaires du m eme message envoy e dans un court laps de temps. Cette caract eristique ne concerne pas le contenu du mail mais la mani` ere avec laquelle il est envoy e. Cest le MTA qui re coit les demandes de connexions qui peut d etecter cette caract eristiques. 5. Utilisation de ladresse dun destinataire sans son consentement explicite pour ce type denvoi. 6. Usage dun site open mail relay pour l emission. L emetteur du mail peut alors usurper le nom du domaine d emission. Pour m emoire, un site open mail relay autorise un RCPT qui ne d esigne pas un destinataire pour lequel la d elivrance des mails est autoris ee sur ce site. Le site sert alors en quelque sorte de tremplin pour le mail, avec un eet de dissimulation du site emetteur v eritable. Les versions modernes des MTA interdisent cette possibilit e par d efaut. 7. Champs To et From de len-t ete invalides Comme par exemple lutilisation comme adresse e-mail dorigine du mail celle dun utilisateur nayant strictement rien ` a voir avec le message (cest lenveloppe qui compte pour la d elivrance du mail). 8. Le contenu du mail contient un virus, soit dans le corps du message soit dans une pi` ece jointe. Par abus ce genre de mail est parfois trait e comme du spam. 3.4.2 Eviter le spam

Cest une question ouverte. . . Sil est evident que lil humain reconnait un tel courrier de mani` ere quasi infaillible, il nen est pas de m eme pour la machine. Il nexiste pas de m ethode de lutte unique et infaillible. Un bon r esultat (plus de 99% du trac de spam bloqu e) peut cependant etre atteint en passant par lusage dune palette doutils et de dispositifs ext erieurs. Toutefois lensemble de ce dispositif a un co ut non n egligeable en terme de cycles cpu consomm es pour un mail d elivr e, dune part, et dautre part en terme de co ut de maintenance car larchitecture logicielle qui en d ecoule est complexe et demande du temps de sp ecialiste de bon niveau pour sa maintenance. Tout dabord, une bonne partie de lorigine du spam vient du fait que le protocole SMTP lui-m eme est beaucoup trop permissif. Con cu ` a une epoque o` u le r eseau etait constitu e sur la base de la conance et de la collaboration entre sites honorables, il nest plus adapt e` a ce quest devenu le r eseau. La faille la plus navrante est que lenveloppe transmise lors

Courriers ind esirables - Le spam de l echange protocolaire nest pas n ecessairement identique ` a ce qui gure dans len-t ete du mail. Lexemple qui suit illustre cette faille :
telnet mailhost.mondomain.fr 25 Connected to mailhost.mondomain.fr. Escape character is ^]. 220 mailhost.mondomain.fr ESMTP HELO UnSiteQuelconque.com 250 mailhost.mondomain.fr Hello UnSiteQuelconque.com, pleased to meet you MAIL From:<> 250 2.1.0 <>... Sender ok RCPT To:<lambda@mondomain.fr> 250 2.1.5 <lambda@mondomain.fr>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From:<NePasRepondre@XXX.com> To:<TuPeuxToujoursEssayer@YYY.com> Unsollicited Bulk Email (UBE) or Unsollicited Commercial Email (UCE). .

203

Et le mail sera d elivr e dans la boite aux lettres de lutilisateur lambda avec des champs From : et To : compl` etement inexploitables ! Pour eviter la d elivrance de ce mail, la conguration du MTA de mondomain.fr pourrait mettre en place une protection agissant en trois temps : lors de l etablissement de la connexion, lors de la r eception de lenveloppe puis ` a la r eception du message lui-m eme. Le protocole SMTP ne comprend pas daccus e de r eception. Si lhonn ete utilisateur de ce protocole envoie un courrier rout e silencieusement, par erreur, dans une boite aux lettres de courriers ind esirables (en g en eral non lus et souvent supprim es automatiquement), cest regrettable et dautant plus pr ejudiciable que le contenu du mail est important. Il est donc bien plus ecace de refuser le message tant que la connexion avec le MTA qui l emet est maintenue, car quel que soit le contenu de lenveloppe (les Reply-to et From sont peut etre faux ou inexistants), le MTA qui route ce mail est ` a lautre bout de la connexion et est suppos e, par construction, etre le mieux plac e pour pr evenir lauteur du mail que la transaction actuelle est refus ee. Autrement dit, il est bien pr ef erable deectuer le tri en temps r eel plut ot quen temps di er e lors de la d elivrance dans la boite de lutilisateur ou apr` es rapatriement (voir page 210) des mails par son MUA. Si lorigine du mail est honn ete, l emetteur sera tout de suite pr evenu (mail derreur) et pourra agir en cons equence, dans le cas contraire le spammeur r eceptionnera autant de messages derreurs que de spams envoy es (un r eve. . .) ce qui ne manquera pas de le g ener consid erablement. Nous ne le plaindrons pas.

204

Courrier electronique ` l A etablissement de la connexion le MTA peut v erier que le taux de demandes de connexions nexc` ede pas un certain ratio (par exemple pas plus de 30 connexions TCP par minutes). Les el ements de la connexion (voir page 90) fournissent ladresse IP et le port dorigine. Ladresse IP doit pouvoir etre r esolue dans le tld in-addr.arpa, le cas contraire est r edhibitoire. Ladresse IP peut etre tout simplement r efut ee localement, tout comme le domaine (au sens du DNS). Ladresse IP peut etre egalement r efut ee apr` es interrogation des DNSBL ( Domain Name Services BlackList ) qui sont des bases de donn ees de sites reconnus comme etant ` a lorigine de spams ou connus comme open mail relay . ` la r A eception de lenveloppe le MTA peut demander une authentication de l emetteur (login et mot de passe) du mail. Le MTA peut egalement consulter une base locale de champs From et To refus es. Il existe un m ecanisme assez ing enieux et r ecent, nomm e le GreyListing17 qui stoppe bon nombre de spams en sp eculant sur le fait que les spammeurs sont des gens press es et que leur mails sont envoy es en tr` es grand nombre (des centaines de milliers dunit es) et le plus vite possible. En cons equence, si l etablissement du protocole SMTP ne fonctionne pas du premier coup, la plupart dentre eux se d ecouragent et ne r eessaient pas (contrairement ` a ce que le protocole SMTP pr evoit). Ce dispositif consiste donc ` a faire patienter tout le monde (sauf peut etre une liste dadresses de correspondants ou de domaines r eput es ables) et seuls ceux qui respectent le procotole ` a la lettre nissent par pouvoir transmettre leur mail, dautant plus que sils ont patient e une fois ils sont plac es dans une liste dacc` es sans d elai pendant un temps programmable (par exemple 24h). En pratique la connexion est coup ee apr` es emission dun message derreur qui invite ` a recommencer ult erieurement. ` la r A eception du corps du mail des ltres peuvent etre appliqu es sur len-t ete pour en v erier la consistance, sur le corps du message pour r eagir sur la pr esence de tels ou tels mots clefs (de tels ltres ont en g en eral un fonctionnement statistique bas e sur lapprentissage dune base de spams et dune base de non-spams et sont enrichis continuellement avec les messages ind esirables) enn les pi` eces jointes sont extraites du courrier et examin ees ` a laide dun dispositif de reconnaissance des virus (une base de virus doit etre mise ` a jour tr` es r eguli` erement).
17

http://projects.puremagic.com/greylisting/whitepaper.html

4 Exemple de MTA - Sendmail et son environnement

205

4
4.1

Exemple de MTA - Sendmail et son environnement

Relations avec le DNS

Comme nous lavons evoqu e au paragraphe 1.2 page 190, la relation entre le MTA et le DNS est etroite. Sendmail a besoin du serveur de noms pour les op erations suivantes :
Qui reoit le mail pour le domaine D ? Sendmail

DNS Voici la liste des machines ayant un RR de type MX pour ce domaine et avec leur prfrence respective

chec ! Sendmail machineA.domaineD

chec ! Sendmail machineB.domaineD

Succs ! Sendmail machineC.domaineX

MTA pouvant rcuprer le courrier pour le domaine D

gure X.04 MX primaire et secondaires 1. Transformer le nom de la machine distante en adresse IP 2. Canoniser le nom de la machine locale. 3. Canoniser le nom de la machine qui se connecte 4. D eterminer quelles sont les machines susceptibles de recevoir du courrier pour le domaine ` a atteindre. Le quatri` eme point est le plus crucial. Si le DNS du domaine ` a atteindre (une adresse est toujours mise sous la forme nom@domain ) ne d esigne pas de machine capable de recevoir le courrier, le mail ne passera jamais pour ce domaine. Le champ RR ( Resource Record ) correspondant est du type MX ( Mail Exchanger ). Il sp ecie une liste dh otes pond er es par des pr ef erences, ` a qui on peut envoyer du courrier. La pond eration indique lordre ` a suivre pour les tentatives de connexions : il faut commencer par la valeur la plus basse. Si cette liste est explor ee de bout en bout sans succ` es il y a echec de la transmission du courrier.

206

Courrier electronique Sil y a echec de la r e emission, le mail est conserv e un certain temps, puis est nalement rejet e sil y a persistance de l echec. Le r esultat est mat erialis e dans un chier nomm e dead.letter Figure X.4, Le contenu du champ RR renvoy e par le DNS pourrait avoir la constitution suivante :
; ;[name] ; domaineD [ttl][class] MX preference IN IN IN MX MX MX 10 20 30 mail exchanger machineA.domaineD machineB.domaineD machineC.domaineX

Il est important de remarquer quune machine baptis ee MX par le DNS nest pas forc ement localis ee dans le domaine pour lequel elle re coit le courrier, cest m eme souvent le cas pour les machines relay . Cest le cas de la troisi` eme ligne, machineC.domaineX

4.2

Relations avec le syst` eme dexploitation

Sendmail a de multiples relations avec le syst` eme dexploitation. La gure X.5 en fait un r esum e:
UUCP X.400 SMTP/ESMTP

syslogd

(gestion des logs) Sendmail

Outil externe pour dlivrer le mail aux utilisateurs Programme(s) externe(s) de traitement (avant la dlivrance) Socket locale (UNIX)

Fichiers de configuration :
/etc/mail/sendmail.cf /etc/mail/submit.cf /etc/mail/aliases /etc/mail/access /etc/mail/localhostnames /etc/mail/mailertable /etc/mail/virtusertable /etc/mail/userdb $HOME/.forward /var/mail/userX

File dattente des messages en /var/spool/mqueue

gure X.05 Relation entre Sendmail et le syst` eme dexploitation Lactivit e op erationnelle de sendmail est consign ee ` a laide de syslog18 , ce qui explique la pr esence de la ligne suivante trouv ee dans le chier /etc/syslog.conf : mail.info /var/log/maillog
18

ements de serveurs Chapitre III du cours de programmation El

Relations avec le syst` eme dexploitation UUCP, X.400, SMTP Sont autant de moyens de propager le courrier. Ces supports peuvent cohabiter au sein dune m eme conguration ; autant de Mailer s electionn es en fonction de ladresse du destinataire (cf sendmail.cf). /etc/mail/sendmail.cf Est le chier de conguration de sendmail qui fonctionne en tant que MTA. Sa pr esence est indispensable. La conguration standard livr ee est en g en erale ` a adapter aux imp eratifs de fonctionnement du r eseau local. Voir ` a ce propos le paragraphe 5 page 212. /etc/mail/submit.cf Est le chier de conguration de sendmail en tant que MSA. Sa pr esence est optionnelle si le chier pr ec edent indique explicitement le contraire. /etc/mail/aliases est une base de synonymes. Quand sendmail re coit un courrier, il tente de reconna tre le nom du destinataire dans cette base et si cest le cas de lui appliquer la transformation prescrite. Un certain nombre dalias sont requis par la [RFC 1123], dautres sont conseill es par la [RFC 2142]. Un court extrait du-dit chier :
# Basic system aliases -- these MUST be present MAILER-DAEMON: postmaster postmaster: root # Well-known aliases -- these should be filled in! root: user info: root marketing: root sales: root support: root www: webmaster webmaster: root ...

207

Cela signie par exemple que chaque fois qun courrier est envoy e au postmaster de ce site, sendmail transforme postmaster en root , puis root en user . Si cette derni` ere cha ne ne fait pas lobjet dune autre transformation par cette table, il sagit dun utilisateur de la machine courante. Lentretien de la table des alias est de la responsabilit e de ladministrateur de la machine. La table des alias dun domaine est un chier strat egique quil convient de mettre ` a jour soigneusement (droits dacc` es, utilisateurs inexistants, boucles. . .). ` chaque changement dans cette table ladministrateur doit fabriquer A une table dacc` es rapides ( hash table ) ` a laide de la commande sendmail -bi souvent li ee ` a newaliases /etc/mail/access Cest un chier qui regroupe des autorisations sp eciques dacc` es ou de rejet des mails entrants. Par exemple :

208

Courrier electronique MonNouveauDomain.tld RELAY Connect:microsoft.com REJECT Acceptera de relayer tout mail pour le domaine MonDomain.tld mais rejetera tout mail en provenance du domaine suivant. /etc/mail/local-host-names Ce chier collecte tous les noms sous lesquels la machine qui ex ecute le MTA est connue ce qui evite que celui rejette le mail en refusant de le relayer. /etc/mail/mailertable Un MTA peut accepter deectuer le routage du courrier pour un grand nombre de domaines. Ce chier permet deectuer un routage en fonction du domaine, par exemple : un.autre.domain.tld smtp:autre.machine.tld mon.domain.a.moi local: /etc/mail/virtusertable Ce chier permet deectuer des r e ecritures dadresses dun domaine vers un autre domaine avec plus de possibilit es dexpression que le chier des aliases. Par exemple : @MonAncienDomaine.tld %1-old@MonNouveauDomaine.tld webmaster@MonNouveauDomaine.tld wbm-new@AutreDomaine.tld Dans la premi` ere ligne le %1 est remplac e dynamiquement par tout ce qui pr ec` ede le @ de @MonAncienDomaine.tld ce qui permettra par exemple deectuer un tri au moment de la d elivrance des messages, entre ceux envoy es pour le nouveau domaine et lancien. /etc/mail/userdb Cette table, User Database permet au sendmail deffectuer une traduction de cha ne sur les noms des utilisateurs pour les courriers sortants. Cette disposition permet de traduire un nom de login en Prenom.Nom , donc davoir une adresse de retour de la forme Prenom.Nom@domaine ce qui fait toujours plus chic ! /var/spool/mqueue Dans ce r epertoire sont stock es les mails en attente dune d elivrance. Il peuvent y rester plusieurs jours (cest un param` etre de la conguration du sendmail), on peut visualiser cette le dattente avec la commande mailq. Si un grand nombre de courriers sont en attente, et ca peut etre le cas pour les machines relais, la section du disque dur qui supporte cette partition (ici /var) doit faire lobjet dun dimensionnement en cons equence, sous peine dobliger sendmail ` a refuser les mails faute de place disque. /var/mail/userX Chaque utilisateur de la machine locale (il peut ne pas y en avoir sur un serveur) a une bo te aux lettres ( mail box ) rep er ee comme un chier ayant comme nom son login. Par exemple /var/spool/mail/root. Ce chier est mis ` a jour automatiquement par le MTA local en cas darriv ee de courrier.

Relations avec le syst` eme dexploitation De m eme que pour le r epertoire de le dattente, le r epertoire des bo tes aux lettres des utilisateurs doit faire lobjet dune attention particuli` ere de la part de ladministrateur ; la prolif eration des documents attach es aux courriers electroniques est un eaux contre lequel il est dicile de se pr emunir sauf ` a agrandir perp etuellement la taille de la partition /var. . . ! :( ${HOME}/.forward Avant d etre nalement d elivr e dans la bo te aux lettres de lutilisateurs, sendmail lit le contenu de ce chier, ${HOME} etant le r epertoire racine des chiers de lutilisateur en question. Le chier .forward est la base personnelle dalias pour chaque utilisateur, ca permet de renvoyer son courrier vers dautres sites, voire aussi deectuer des transformations avant de stocker les mails (procmail). Si le .forward contient la cha ne suivante : moi@ailleurs.tld Tous les courriers envoy e` a cette utilisateurs sont renvoy es ` a ladresse indiqu ee. Ou encore : "|exec /usr/local/bin/procmail" Qui permet dinvoquer lusage du programme procmail, celui-ci est un tr` es puissant ltre qui permet de faire un tri des courriers electroniques avec des expressions r eguli` eres (indispensable pour g erer de multiples abonnements ` a des mailing-lists ). Par exemple, avec la conguration virtusertable ci-dessus, pour forcer la d elivrance des mails adress es ` a @MonAncienDomaine.tld dans un chier sp ecial plut ot que la boite par d efaut, on pourrait ecrire un chier .procmailrc de conguration contenant les lignes suivantes : :0 H: * ^To[ :]+.*-old@MonNouveauDomaine.tld ${HOME}/Mail/Rougnes Socket locale Sendmail peut communiquer avec des programmes ext erieurs par le biais dune socket locale (UNIX). Le dialogue est facilit e par une biblioth` eque nomm ee MILTER19 li ee ` a sendmail lors de sa compilation. Lid ee est quil est plus int eressant de refuser eventuellement un mail d` es que les premiers el ements du protocole SMTP (ou ult erieurement en examinant le corps du message) sont connus, plut ot que dattendre que la connexion soit close et que le mail soit d elivr e. De ce fait, l emetteur, quel quil soit (honn ete utilisateur ou spammeur) sera imm ediatement pr evenu que son mail est refus e et pourra agir en cons equence. De nombreux outils sont capable de fonctionner avec sendmail et son interface MILTER, liste non exhaustive : MIMEDefang20 , Clamav21 , milter-greylist22 ,. . .
19 20

209

http://www.milter.org http://www.mimedefang.org/ 21 http://www.clamav.net/ 22 http://hcpnet.free.fr/milter-greylist/

210

Courrier electronique Outil externe de d elivrance Le message pr et ` a etre d elivr e est con e par sendmail aux bons soins dun programme ext erieur. Si la d elivrance seectue dans une boite aux lettres unix (un chier au format mailbox qui porte comme nom le login de lutilisateur et est situ e g en eralement dans le r epertoire /var/mail/), ce programme se nomme local.mail en standard. Il peut etre remplac e par dautres, notamment par le programme procmail d ej` a cit e, si on souhaite eectuer un ltrage suppl ementaire ` a ce niveau du traitement, par exemple pour mettre dans une boite aux lettres sp eciale les mails consid er es comme etant du spam en laissant ` a lutilisateur le soin de les d etruire par lui-m eme. Enn on peut remarquer quaucun signal nest pr evu pour indiquer ` a sendmail quil faut relire son chier de conguration, cest voulu par le concepteur. Lors de la mise au point de ce chier, il faut arr eter puis le 23 relancer manuellement .

4.3

Le cas de POP

POP est lacronyme de Post Oce Protocol , il permet lacc` es ` a un serveur de courrier depuis des clients PC sous Windows, voire m eme des stations unix distantes, par exemple via ppp, qui ne sont pas congur ees pour faire un trac SMTP entrant. POP dans sa version 3 est d eni par la [RFC 1939].

Envoi : SMTP Serveur POP Client POP

MTA

Popd

MUA

SMTP

Lecture: POP3

Boite aux lettres de lutilisateur (mail box)

gure X.06 Le cas de POP Les clients POP sont l egions sur les PCs et sur les stations de travail sous Unix. Pour celles-ci citons : kmail24 , mh, pine, elm, mutt, gnus pour emacs, ou encore sylpheed et thunderbird. La liste nest pas exhaustive, loin sen faut.
Par exemple sur une machine NetBSD/FreeBSD en tapant /etc/rc.d/sendmail restart 24 De lenvironnement de bureau KDE - http://www.kde.org/
23

Relations avec le syst` eme dexploitation POP est un protocole tr` es simple qui fonctionne parfaitement mais qui nest pas d enu e de d efauts : 1. Lauthentication (login/password) est bien souvent echang ee en clair sur le r eseau 2. Sur larchitecture Unix, lutilisateur doit avoir un compte sur la machine serveur (Une base de donn ees des utilisateurs est toutefois possible) 3. Les messages doivent etre r ecup er es sur le poste client pour etre manipul es (en POP3 un double peut rester sur le serveur) 4. La boite aux lettres ne peut etre consult ee que par un seul client ` a la fois Ces points deviennent vite r edhibitoires quand le poste client doit acc eder au serveur au travers dun r eseau non s ur, et surtout lorsque le d etenteur de la boite aux lettres veut consulter ses mails depuis des postes di erents. Ce cas de gure est de plus la r ealit e de toute personne qui se d eplace et souhaite un contact mail permanent avec ses correspondants. Cest pourquoi dautres solutions se sont d evelopp ees et sont de plus en plus utilis ees : les messageries accessibles via un browser web (webmail), donc qui utilisent comme support le protocole HTTP (voir page 327), ou un rempla cant du procole POP, le protocole IMAP !

211

4.4

Le cas de IMAP

Bien que largement d eploy e que depuis quelques ann ees, le protocole IMAP Internet Message Access Protocol a et e d evelopp e` a luniversit e de Stanford en 1986. Cest actuellement la version 4rev1 qui est utilis ee, d enie dans la [RFC 3501]. Larchitecture pr esent ee gure X.06 reste valable, pratiquement il sut dy remplacer le mot POP par IMAP25 ! Les fonctionnalit es sont plus riches et surtout pallient aux inconv enients list es pour POP. En clair, les points n egatifs list es pour POP sont tous r egl es. Imap est con cu pour pouvoir acc eder ` a ses boites aux lettres depuis de multiples machines, nimporte o` u sur le r eseau, alors que POP est plus adapt e` a une machine unique. Voici ses objectifs principaux : 1. Etre compatible avec les standards, MIME par exemple 2. Permettre lacc` es et la gestion des mails depuis plus dune machine 3. Fournir un mode de fonctionnement en-ligne et hors-ligne 4. Supporter les acc` es concourrants aux m emes boites aux lettres 5. Etre ind ependant du stockage des mails (chiers ou base de donn ees, par exemple)
25

Consultez http://www.imap.org/ pour plus dinformations

212

Courrier electronique Un excellent comparatif des deux protocoles est accessible ici :
http://www.imap.org/papers/imap.vs.pop.brief.html

Conguration du Sendmail

Le programme sendmail sappuie sur un ensemble de r` egles de r e ecritures (gure X.05 page 206) par d efaut regroup ees dans les chiers /etc/mail/sendmail.cf et /etc/mail/submit.cf. La plupart des cas de la vie courante se traitent sans avoir besoin de modier manuellement ces deux chiers. Lusage dun jeux de macros m426 tr` es complet et puissant sut pour g en erer les congurations ci-dessus, apr` es l ecriture dun chier de requ etes de quelques lignes. M4 g en` ere ensuite les chiers attendus ` a partir de ces requ etes, et dun mod` ele ( template ) install e avec le programme sendmail. Il faut noter quun certain nombre dadministrateurs syst` eme, form es ` a la vieille ecole , aiment bien conserver la ma trise totale de ce quils produisent et pr ef` erent donc ecrire eux-m emes manuellement leurs r` egles, ces macros ne leur sont donc pas destin ees !

5.1

Conguration ` a laide de M4

Le point dentr ee pour utiliser cet outil est une documentation livr ee avec la distribution du programme sendmail et nomm ee : <pr efixe dinstallation>/cf/README Consid erons la situation r eseau de la gure X.07. Le courrier au d epart de la station, soumis par exemple au MSA local, doit etre rout e syst ematiquement vers une machine nomm ee mailhub.mondomain.fr, et qui concentre tout le trac local sortant, do` u dailleurs son nom de mailhub . Celle-ci est cens ee savoir router le mail quelle re coit, mais ce nest pas notre pr eoccupation ici.
MUA
MTA/MSA

Station

Poursuite du trajet du mail aprs dcision de routage

MTA Trajet du mail sortant de la station. Serveur local ou mailhub

26

Macro processeur bien connu dans le monde Unix

Conguration du Sendmail gure X.07 Concentration du mail sur un mailhub Le chier de conguration pour la station pourrait etre :

213

1 2 3 4 5 6 7 8 9 10 11 12 13

divert(0) VERSIONID(mondomainfla04052005)dnl OSTYPE(freebsd5)dnl define(confSMTP_LOGIN_MSG,$j STATION LAMBDA $b)dnl dnl FEATURE(always_add_domain)dnl MASQUERADE_AS(mondomaine.fr)dnl FEATURE(allmasquerade)dnl dnl define(MAIL_HUB,smtp:mailhub.mondomain.fr.)dnl define(SMART_HOST,smtp:mailhub.mondomain.fr.)dnl dnl MAILER(smtp)dnl

Et ce chier (config.mc) est utilis e de cette mani` ere :

m4 m4/cf.m4 config.mc > sendmail.cf

Pour g en erer en nal le chier attendu, dont le nombre de lignes exc` edent 1400 ! Il faut noter que le MSA se congurent de mani` ere similaire, ` a partir de son propre chier de conguration. Ligne 1 Cest la d enition dun canal de sortie pour m4 (cf man m4). Ligne 2 Cest une etiquette ( tag ) ins er ee dans le chier g en er e et qui servira ` a lidentier, par exemple avec la commande ident si l etiquette est un identiant de rcs ou cvs. Remarque : dnl est un mot clef de m4, au m eme titre que divert, et qui signie quon peut ignorer (discard) tous les caract` eres jusquau prochain retour ` a la ligne (nl). Ligne 3 Cest un identiant du syst` eme dexploitation pour que m4 puisse faire les choix adapt es (choix des chemins standards par exemple). Ligne 4 D enition de la banni` ere de HELO du protocole SMTP. $j est une variable qui contient le nom canonique (FQDN - Voir page 169)) de la machine h ote. La banni` ere de HELO smtp de la station ressemblera ` a ca :
220 stationYXZ.mondomain.fr ESMTP --- STATION LAMBDA --- (date du jour)

Ligne 6 Ajout syst ematique du nom de domaine, m eme et surtout pour les courriers locaux (donc dans le domaine local par d efaut). Ligne 7 et 8 Ces deux lignes entrainent la r e ecriture des adresses From de telle sorte quelles se pr esentent toujours sous la forme <untel@mondomain.fr> au lieu de leur forme par d efaut <untel@station.mondomain.fr> qui est nuisible au retour du courrier car la machine station.mondomain.fr nest tr` es vraisemblablement pas atteignable directement depuis le r eseau global sur son port 25.

214

Courrier electronique Ligne 10 Tout le mail local doit etre envoy e ` a la machine mailhub.mondomain.fr. Ligne 11 Tout le mail autre que local doit etre envoy e ` a la machine mailhub.mondomain.fr. Ligne 13 Normalement inutile dans le cas pr esent (pas de delivery sur cette machine). Pour conclure, sendmail comme tous les outils, evolue plusieurs fois par an. Si ` a chaque version il est n ecessaire de reconstruire manuellement son chier sendmail.cf il est probable que votre emploi du temps va etre s erieusement amput e dun temps pr ecieux. . .Mieux vaut avoir juste ` a taper make dans le bon r epertoire pour reconstruire un chier de conguration tout beau tout propre !

5.2

Conguration manuelle

Cette section est une extraction libre et incompl` ete du paragraphe 5 du document intitul e Sendmail Installation and Operation Guide , disponible dans toute distribution de la V8. On peut egalement trouver ce document dans la section System Managers Manual (SMM) des syst` emes BSD27 . Le chier de conguration (sendmail.cf est organis e comme une s erie de lignes, le premier caract` ere de chacune delles en pr ecise le type. Une ligne vide ou qui d ebute par un # est ignor ee (commentaire), une ligne qui d ebute par un espace ou une tabulation est la continuation de la pr ec edente. 5.2.1 R` egles de r e ecriture

Les r` egles de r e ecritures sont rep erables comme ces lignes qui d emarrent par un S (d ebut dun paquet de r` egles) ou un par un R (simple r` egle). Les paquets de r` egles (organisation densemble gure X.7 ) ont comme but essentiel danalyser puis de prendre les bonnes d ecisions en fonction des adresses trouv ees dans len-t ete. Cest une d emarche purement formelle. Ces r` egles utilisent une syntaxe dense qui rebute g en eralement les administrateurs. Il faut imaginer quelles sont int egralement analys ees chaque fois que le programme sendmail est invoqu e, cest ` a dire en gros pour chaque e-mail entrant ou sortant. Elles doivent donc etre faciles ` a analyser, m eme par un cpu de modeste performance (ou tr` es charg e, ce qui revient nalement au m eme). Lensemble fonctionne comme un syst` eme de production, cest ` a dire qui consomme des r` egles lues s equentiellement et les applique ` a un jeux de donn ees initiales, ici une ou plusieurs adresses electroniques. eclencheur ( pattern matching ) La partie gauche (ou lhs28 ) sert de d
pour FreeBSD, NetBSD ou OpenBSD ca se trouve dans le r epertoire /usr/share/doc/smm/08.sendmailop/ 28 left hand side
27

Conguration du Sendmail pour une r` egle. La partie droite (ou rhs29 ) est d eclench ee si le motif de la partie gauche est reconnu dans le ux de donn ees. Le r esultat produit, sil existe, est reinject e dans le syst` eme de production et ce jusqu` a epuisement des possibilit es. La gure X.7 donne un aper cu du fonctionnement de lautomate, les chires (0,1,2,3,4) sont autant de ruleset , comprendre des paquets de r` egles qui sont regroup ees ensembles parcequelles traitent dun objectif commun.

215

Adresse rsolue

Adresse

Message

D : Ajout du domaine de lmetteur S : Recrite spcifique au mailer, pour lmission R : Idem S mais pour la rception.

gure X.08 R` egles de r e ecriture Les r` egles sont num erot ees, le premier chire dit ` a quel paquet elles appartiennent. Le paquet de r` egles 0 sert essentiellement ` a d eterminer le mailer cest ` a dire le moyen denvoyer le courrier (SMTP, ESMTP, UUCP. . .). Les paquets de r` egles 1 et 2 sont appliqu es respectivement ` a len-t ete des messages qui sortent ( send ) ou qui entrent ( receive ). Le paquet de r` egles 3 est appliqu e syst ematiquement ` a toutes les adresses. Le paquet de r` egles 4 est appliqu e` a toutes les adresses dans le message, typiquement pour passer dune forme interne ` a une forme externe. Le paquet de r` egles 5, non repr esent e sur lautomate, sert ` a traiter les adresses locales apr` es que les aliases aient et e appliqu es. Les paquets de r` egles sont rep er es par la lettre S, qui en balise le nom, comme dans :
###################################### ### Ruleset 0 -- Parse Address ### ###################################### Sparse=0

Quant aux r` egles, elles d emarrent toutes avec la lettre R, comme dans :
29

right hand side

216
R$* R<@> R$* R$* $: $>Parse0 $1 $#local $: <@> $: $>ParseLocal $1 $: $>Parse1 $1

Courrier electronique
initial parsing special case error msgs handle local hacks final parsing

Deux remarques simposent : 1. Chaque ligne forme une r` egle, sur le mod` ele : Rlhs rhs commentaire 2. Le s eparateur de champ entre les trois partie de ces r` egles est la tabulation (une au minimum) Ladresse postmaster@mondomain.fr, par exemple, quand elle se pr esente devant le paquet de r` egles 0 qui d emarre ci-dessus, a et e mise sous une forme canonique par dautres r` egles appliqu ees pr ealablement (notament dans la ruleset 3 ) : postmaster < @ mondomain . fr . > Le pattern matching va tenter de rapprocher cette suite de mots ou tokens de la partie gauche des r` egles (lhs) pour d eterminer celles qui peuvent etre d eclench ees. Dans la partie gauche $ sapplique ` a toute suite de tokens, m eme vide. Donc la premi` ere ligne convient. La deuxi` eme ne le pourrait pas car la cha ne postmaster pr ec` ede le caract` ere < et le @ est suivi de mondomain . fr . . La troisi` eme et la quatri` eme r` egle sont egalement d eclenchables mais pr esentement lordre dapparition est egalement lordre de d eclenchement, cette possiblit e sera donc examin ee eventuellement plus tard. La partie droite de la premi` ere r` egle commence par $ : $>Parse0 ce qui signie lappel dun autre paquet de r` egles que lon pourra trouver plus loin dans le chier sendmail.cf :
# # # # # # Parse0 -- do initial syntax checking and eliminate local addresses. This should either return with the (possibly modified) input or return with a #error mailer. It should not return with a #mailer other than the #error mailer.

SParse0

Le $1 signie que lon ne transmet que le premier des tokens reconnus dans la partie gauche ( postmaster dans lexemple). . .

Conguration du Sendmail 5.2.2 Exemple de sortie de debug

217

Il est utile davoir ce sch ema en t ete quand on d ebogue les r` egles : avec loption -bt de sendmail on peut suivre la progression de la transformation, r` egle par r` egle.
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 postmaster@mondomain.fr rewrite: ruleset 3 input: postmaster @ mondomain . fr rewrite: ruleset 96 input: postmaster < @ mondomain . fr > rewrite: ruleset 96 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 3 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 0 input: postmaster < @ mondomain . fr . > rewrite: ruleset 199 input: postmaster < @ mondomain . fr . > rewrite: ruleset 199 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 98 input: postmaster < @ mondomain . fr . > rewrite: ruleset 98 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 198 input: postmaster < @ mondomain . fr . > rewrite: ruleset 90 input: < mondomain . fr > postmaster < @ mondomain . fr . > rewrite: ruleset 90 input: mondomain . < fr > postmaster < @ mondomain . fr . > rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 95 input: < mailhub . mondomain . fr > postmaster < @ mondomain . fr . > rewrite: ruleset 95 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . > rewrite: ruleset 198 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . > rewrite: ruleset 0 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . > >

Plus en TP. . .

218

Courrier electronique

Bibliographie

Pour en savoir davantage, on pourra consulter les bons auteurs suivants : Eric Allman Sendmail Installation and Operation Guide document au format PostScript jointe ` a toutes les distributions de la V8.xx. Bryan Costales with Eric Allman & Neil Rickert Sendmail OReilly & Associates Inc. 1994 Installing and Administering ARPA Services HewlettPackard 1991 Douglas E. Comer Internetworking with TCP/IP Volume I (chapter 19) Prentice All 1988 W. Richard Stevens TCP/IP Illustrated Volume I (chapter 28) Prentice All 1994 Et pour en savoir encore plus. . . RFC 821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Format : TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Status : STANDARD) RFC 822 Standard for the format of ARPA Internet text messages. D. Crocker. Aug-13-1982. (Format : TXT=109200 bytes) (Obsoletes RFC0733) (Updated by RFC1123, RFC1138, RFC1148, RFC1327) (Also STD0011) (Status : STANDARD) RFC 974 Mail routing and the domain system. C. Partridge. Jan-011986. (Format : TXT=18581 bytes) (Status : STANDARD) RFC 1123 Requirements for Internet hosts - application and support. R.T. Braden. Oct-01-1989. (Format : TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status : STANDARD) RFC 1652 SMTP Service Extension for 8bit-MIMEtransport. Klensin, N. Freed, M. Rose, E. Steerud & D. Crocker. July 1994. (Format : TXT=11842 bytes) (Obsoletes RFC1426) (Status : DRAFT STANDARD) RFC 1939 Post Oce Protocol - Version 3. J. Myers & M. Rose. May 1996. (Format : TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957) (Also STD0053) (Status : STANDARD) RFC 2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. December 1996. (Format : TXT=166513 bytes) (Obsoletes RFC1730) (Status : PROPOSED STANDARD) RFC 2184 MIME Parameter Value and Encoded Word Extensions : Character Sets, Languages, and Continuations. N. Freed, K. Moore. August 1997. (Format : TXT=17635 bytes) (Updates RFC2045, RFC2047, RFC2183) (Status : PROPOSED STANDARD) RFC 2476 Message Submission. R. Gellens, J. Klensin. December 1998. (Format : TXT=30050 bytes) (Status : PROPOSED STANDARD)

Bibliographie RFC 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.April 2001. (Format : TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869) (Status : PROPOSED STANDARD) RFC 2822 Internet Message Format. P. Resnick, Ed.April 2001. (Format : TXT=110695 bytes) (Obsoletes RFC0822) (Status : PROPOSED STANDARD)

219

220

Courrier electronique

Chapitre XI Instrumentalisation de r eseaux avec SNMP

1 N ecessit e dun outil

La majeure partie des activit es informatiques d ependent du bon fonctionnement des r eseaux et des services associ es. Leurs nombres et leur complexit e ne cessent de saccro tre, mais bien souvent le personnel responsable de l evolution et du bon fonctionnement de lensemble ne voit pas ses eectifs humains evoluer dans le m eme sens, du moins aussi rapidement que le parc de machines ` a administrer ! Or, le bon fonctionnement dun grand r eseau ne peut d ependre pour seule composante que de leort intellectuel dindividus ou de groupe dindividus, fussent-ils comp etents et d evou es. Il faut des outils !

1.1

Probl ematique de lISO

LISO, sest pench e sur la question et a segment e le probl` eme de la gestion technique de r eseau en cinq points : La gestion des pannes (Fault management) Il sagit de d etecter les pannes, de les localiser et dy rem edier en minimisant limpact de la perte de fonctionnalit e sur le reste du syst` eme dinformation. La panne nest pas une erreur, mais un grand nombre derreurs peuvent conduire ` a d eclarer une panne. Par exemple la croissance anormale du nombre de collisions sur un r eseau, lengorgement dun disque. . . La comptabilisation de lusage des ressources (Accounting management) Il sagit darchiver et de mettre en ordre tous les compteurs g en er es par les applicatifs et les couches r eseaux an de pouvoir tirer un enseignement de lusage des ressources. Laspect condentiel de ces donn ees doit etre pris en compte. La gestion des congurations (Conguration and name management) Il sagit de la mise en uvre et de la conguration de tous les equipements qui inter-agissent sur le r eseau.

222

Gestion de r eseaux avec SNMP Laudit des performances (Performance management) Il sagit davoir une approche quantitative sur le fonctionnement du r eseau an de pouvoir r epondre ` a des questions aussi basiques que : 1. 2. 3. 4. 5. Quel est le niveau actuel dutilisation ? Il y a t-il un (des) trac(s) excessif(s) ? Le d ebit nominal est-il r eduit ` a une valeur inacceptable ? O` u sont les goulots d etranglement ? Quelle est l evolution du temps de r eponse ?

La gestion de la s ecurit e (Security management) Il sagit de maintenir coh erent et eectif lensemble des protections sur les autorisations dacc` es et donn ees sensibles collect ees. Les logs (syslog) sont un point important de la gestion de la s ecurit e. En conclusion, les buts dune gestion technique ecace dun r eseau sont multiples : il sagit dorir aux usagers un service de qualit e, de permettre les evolutions du syst` eme dinformation en y incluant de nouvelles fonctionnalit es, doptimiser lusage des ressources et de minimiser les co uts dexploitation ou dinvestissement.

1.2

Syst` eme de gestion de r eseau

Un syst` eme de gestion de r eseau (Network Management System) est une collection doutils pour la surveillance et le contr ole an de permettre ` a un op erateur deectuer la plupart des op erations de gestion depuis un interface le plus simple et ergonomique possible ! Cest un ensemble de logiciels (Network Management Entity) associ es eventuellement ` a des mat eriels sp eciques, qui sont d eploy es sur tous les composants du syst` eme dinformation. Un NMS est donc con cu pour donner une image uni ee du r eseau, quelle que soit son etendue et son h et erog en eit e. Le logiciel utilis e pour visualiser limage du r eseau est un NMA (Network Management Application). Un NME : Collecte des donn ees sur lactivit e r eseau Conserve ces donn ees dans une base R epond aux requ etes du NMA, notamment sur les points suivants : 1. Transmission des donn ees collect ees 2. Changement dun param` etre de conguration 3. Fourniture de statut de composants logiciels ou mat eriels 4. G en eration de tests Envoi des messages dalerte (trap) en cas de d etection d ev enements exceptionnels. Au moins un nud du r eseau est d esign e comme etant le manager, et supportant le NMA. Cette architecture nest pas n ecessairement centralis e, la supervision du r eseau peut seectuer par secteurs.

N ecessit e dun outil

223

1.3

SNMP Simple Network Management Protocol

SNMP est un terme un peu g en erique qui d esigne ` a la fois un protocole r eseau applicatif bien pr ecis, une collection de sp ecications pour le management de r eseau et la d enition de structures de donn ees ainsi que leurs concepts associ es. SNMP est n e en 1988 de la n ecessit e de disposer dun outil de supervision du r eseau d` es lors que celui-ci comporte un grand nombre dh otes qui interagissent, stations, serveurs, el ements de routage ou de commutation ou encore boites noires. Leur nombre grandissant sur les LANs (des machines en clusters par exemples) implique davoir un outil qui permette dexpliquer le r eseau. Ce besoin est moins evident quand tout va bien, mais il sut parfois dun simple petit grain de sable. . . Dans ces moments l` a, disposer dun outil qui d elivre une information de synth` ese est indispensable ! Les logs, au sens de syslog (paragraphe 3.2 page 316) , m eme concentr es, ltr es, et tri es ne d elivrent une information parfois trop verbeuse et en tout cas structur ee di eremment selon les applications ou les noyaux. Les ev enements r eseaux y sont le plus souvent absents, sauf dans le cas tr` es par1 ticulier de d emons qui surveillent le r eseau, arpwatch en est un exemple. Le tri par niveau de criticit e ne retire rien ou presque au fait que cest une information brute quil faut ltrer pour en extraire linformation pertinente. Larchitecture dun r eseau g er e avec SNMP comporte essentiellement deux entit es : le manager et lagent, ou encore le client et le serveur. Le client (manager) interroge le serveur pour r ecolter de linformation ou congurer une valeur, le serveur (agent) est capable de pr evenir le client en cas d ev enements exceptionnels (traps). Enn, nimporte quelle machine munie dune stack IP est susceptible de supporter SNMP, depuis le calepin electronique, en passant par la borne wi et jusquau mainframe. En quelques mots, SNMP permet : De cartographier le r eseau De fournir un panel tr` es complet de r esultats de mesures pour chaque h ote De mesurer en temps r eel la consommation de ressources dune application De signaler les dysfonctionnements De changer certains param` etres r eseaux de fonctionnement Avantages : Protocole est simple et facile dutilisation Permet une gestion centralis ee dun parc Dispose dun mod` ele extensible Est ind ependant de larchitecture mat erielle

Site ociel http://www-nrg.ee.lbl.gov/

224
Station de management NMA SNMP MIBs

Gestion de r eseaux avec SNMP

Agent SNMP NME Requetes :161 Rponses Rseau UDP/IP :162 Envoi de "trap" SNMP MIBs

gure XI.01 Agent et Manager dans une relation de type client-serveur

1.4

Historique du protocole SNMP

Avant 1987/1988 il ny a rien dautre quICMP pour recevoir de linfo entres routeurs et h otes. Le couple (echo request,echo reply) est le plus utilis e pour maintenir un etat des machines accessibles. Le point de d epart est SGMP ( Simple Gateway Monitoring Protocol RFC 1028 de novembre 1987) mais trop orient e sur la gestion des routeurs. Du cot e de lOSI dautres tentatives avec CMIS et CMIP ( Common Management Information Service & Protocol ) SNMP est sorti en 1988, comme une version am elior ee de SGMP. Les RFCs fondatrices sont les 1155, 1156 et 1157 conserv ees actuellement au rang dhistoriques bien que tous les equipements soient th eoriquement encore compatibles SNMPv1 (m eme sils r epondent ` a un niveau de version SNMP plus r ecent, cest ` a dire 2 ou 3).

1.5

Vocabulaire et architecture

Un syst` eme dexploitation peut etre vu comme une vaste collection de compteurs et dhorloges auxquels SNMP nous permet dacc eder ` a distance pour les lire et les modier (certaines, sous r eserve dy avoir acc` es). An que les agents et les managers soient inter-op erables les variables sont collectionn ees selon une repr esentation arborescente tr` es structur ee et standardis ee, ce sont les MIBs ( Management Information Base ). On les retrouve partout o` u SNMP est support e. Ainsi, une m eme information se nomme de la m eme mani` ere quelle que soit limpl ementation de SNMP et ind ependamment de sa valeur qui est fonction du contexte. Cest donc tr` es commode pour automatiser les traitements (scripts de collecte et de surveillance. . .) dans un r eseau qui est h et erog` ene la plupart du temps !

N ecessit e dun outil Les feuilles de cet arbre sont les variables et on y acc` ede en connaissant le chemin ` a priori depuis la racine, un peu ` a la mani` ere dun syst` eme de chiers, sauf quici les chemins sont codi es ` a lavance. Actuellement cest la MIB-2 qui est la plus r epandue (RFC 1213), elle r epond parfaitement aux besoins elementaires. Si un appareil ou un syst` eme a des besoins sp eciques il est toujours possible dajouter des branches au tronc commun, un embranchement est pr evu pour cela, on parle alors dune extension vendor . Tous les vendeurs dh otes r eseaux pr evoient des MIBs pour leurs equipements ( mibs vendors donc), d` es lors quils sont accessibles via ip (routeurs, commutateurs, ponts, h otes, imprimantes, boites noires diverses) m eme si celle-ci nest pas montr ee ` a lutilisateur nal. Telle borne wi dun c el` ebre constructeur informatique ` a la pomme , utilise SNMP pour se congurer mais lutilisateur ne le voit pas, cest masqu e par un interface utilisateur convivial. La gure XI.01 pr esente la relation entre les deux entit es logicielles qui dans le cas de SNMP se nomment : Agent SNMP, ou NME (le serveur) Cest un logiciel qui sex ecute sur lappareil que lon souhaite administrer ` a distance. Il r epond aux requ etes du gestionnaire, et g en` ere des alarmes (traps) si besoin est. La conguration dun agent est en g en eral assez simple (par rapport ` a celle dun logiciel Manager). Manager NMA (le client) Cest le logiciel qui sex ecute sur la station dadministration. Sa conguration est forc emement plus d elicate que celle de lagent parcequil n ecessite une adaptation au r eseau local qui est toujours un cas particulier. Il existe de nombreux logiciels HP OpenView, SUN Net Manager , IBM Netview, Spectrum, ISM OpenMaster, SNMPc.. . . LOpen Source nest pas en reste et sans etre aussi complet, loutil tkined est d ej` a tr` es satisfaisant pour lessentiel des besoins (voir la recopie d ecran page 247). Sonde RMON (alternative de serveur) La gure 01 est en fait incompl` ete dans le cadre dune architecture de supervision globale de r eseau : si chaque agent sur chaque h ote peut r epondre individuellement sur les ev enements r eseau le concernant, il manque un maillon plus global qui fasse la supervision du r eseau en lui-m eme, le v eritable networking management . Cet el ement existe, cest ce quon appelle une sonde RMON, ou encore Remote Monitoring . Cest une entit e logicielle, comme un agent SNMP. Elle sappuie sur une extension de la MIB de base. On la trouve principalement sur les el ements de commutation ou de routage, l` a o` u se concentre le trac r eseau, mais on peut la trouver sur un h ote egalement, par exemple sur un serveur critique. LOpen Source nous en fournit un tr` es bel exemple avec le logiciel

225

226 ntop2 .

Gestion de r eseaux avec SNMP

La repr esentation des donn ees dans les variables nest pas laiss ee au hasard des besoins des d eveloppeurs mais est structur ee selon une sp ecication appell e SMI Structure of Management Information , d enie par la RFC 1155, qui dit par exemple quun entier positif va de 0 ` a 232 1. Pour etre ind ependant du formalisme local de la plateforme (probl ematique de la couche 6 OSI).

1.6

Di erentes versions

Enn cet echange de donn ees prend place dans un protocol r eseau qui est d eni par les RFC 1155 ` a 1157, nomm e Simple Network Management Procotol (version 1). Beaucoup de travail dans les rfc depuis. . . Actuellement il y a 3 versions de SNMP, v1, v2c et v3. La v1 est support ee pour des raison historiques , la v2 est la plus couramment support ee par les appareillages. Elle pose quelques soucis que tente de r egler la v3 (notamment la s ecurisation de lauthentication). La premi` ere version sourait dun certain nombre de lacunes au niveau du protocole et de la s ecurit e que la deuxi` eme version (SNMPv2c Communitybased SNMPv2 ) d enie par les RFC 1901 ` a 1908, tente de combler. Rien nest malheureusement fait cot e s ecurit e dans cette deuxi` eme version mais des am eliorations sont apport ees aux mibs standards et au protocole. Plus r ecemment un nouveau cadre de travail a et e d evelopp e, qui saffranchit compl` etement de la notion de communaut e , obstacle ` a lusage de SNMP en ecriture, et qui introduit des am eliorations signicatives de la s ecurit e (RFC 3411 ` a 3418). Linertie des habitudes retarde son d eploiement g en eralis e, ainsi que la n ecessit e de continuer ` a g erer des appareils ne le supportant pas (encore). 1.6.1 Trois composantes pour SNMP

Dapr` es la RFC 1213 (MIB II) le cadre de travail de SNMP repose sur trois composantes : SMI d enit les types dobjets utilis es dans les mibs. Cest une sorte de m eta mod` ele de donn ees. Par exemple pour d enir une adresse physique (MAC)
PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets.
2

http://www.ntop.org/

N ecessit e dun outil La MIB d ecrit une collection structur ee des ressources ` a g erer. Une ressource ` a g erer est repr esent ee par un objet. Le protocole SNMP qui r egit le contenu des dialogues clients/serveurs cest ` a dire linterrogation des donn ees structur ees par la MIB. 1.6.2 Conclusion

227

le protocole SNMP est simple dans sa conception ce qui permet son d eploiement sur de tr` es nombreux appareils h et erog` enes mis en r eseau. En pratique la situation est moins simple du fait de la coexistence de 3 versions des MIB non toutes support ees par tous les h otes du r eseau. La conguration de la station dadministration demande du temps, une connaissance tr` es approfondie de la topologie du r eseau ` a administrer, et beaucoup de comp etences techniques. Cest un travail ` a haute valeur ajout ee !

228

Gestion de r eseaux avec SNMP

SMI Structure of Management Information

La RFC 1155 fondatrice pose le cadre de travail ` a lint erieur duquel on peut b atir les MIBs. En eet, la SMI pr ecises les types de donn ees et les ressources qui peuvent etre sp eci ees dans une MIB. Les donn ees ont et e pr evues simples, le tableau (par exemple pour repr esenter un ensemble de connexions tcp tcpConnTable) et la liste (les el ements dun quintuplet tcp tcpConnEntry) sont les formes les plus complexes pr evues. Ces structures de donn ees sont remplies avec les 5 types suivants : networkaddress Il sagit dune zone pouvant contenir une adresse r eseau, avec comme format possible IpAddress (ipv4 32 bits). counter Cest un compteur qui prend sa valeur maxi ` a 232 1 (on reconnait un entier 32 bits non sign e) et qui ne peut pas etre d ecr ement e. Quand il atteind sa valeur maxi il repasse ` a 0. gauge Cest un compteur, qui a la m eme valeur maximale que le pr ec edent mais qui au contraire peut etre d ecr ement e. Par contre il ne repasse pas automatiquement ` a 0 en cas de valeur maximale atteinte. timeticks Le nombre de secondes ecoul ees depuis epoch, cest ` a dire le 1er janvier 1970. opaque Cest un ux doctets banalis es qui permet dencoder tout ce qui ne rel` eve pas des types pr ec edents, une sorte de fourre-tout en quelque sorte. . . Toutes les ressources auxquelles on souhaite acc eder d ecrites dans un document qui est une MIB.

MIB Management Information Base

Les MIBs sont des chiers au format ascii qui d ecrivent dans le d etail chacune des ressources ` a quantier. Ces ressources sont des el ements simples (scalaire ou tableaux ` a deux dimensions). Chaque unit e de description se nomme un objet (sans aucun rapport avec la programmation du m eme nom). Une MIB est une collection structur ee de tous ces objets. Un m eme objet est accessible de la m eme mani` ere partout sur le r eseau. Le propos dune MIB peut etre celui de respecter un standard ouvert, d ecrit alors par une RFC et distribu e librement, ou d etre sp ecique pour un type particulier dappareil et de constructeur ( mibs vendor ). Sa diusion est alors ` a linitiative de son auteur. Le contenu dune MIB est toujours d ecrit ` a laide dun langage formel 3 e g en eralement pour d enir des structures de donn ees nomm e ASN.1 utilis
3

d evelopp e et standardis e par le CCITT (X.208) et lISO (ISO 8824)

MIB Management Information Base applicatives complexes (couche 6 du mod` ele de lOSI) et qui est ind ependant de tout langage de programmation. Un extrait de la MIB II (RFC 1213) concernant le d ebut de la description de lobjet tcpConnTable, ` a savoir la table des connexions tcp, celle l` a m eme que lon peut observer avec la commande netstat -p tcp.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

229

the TCP Connection table The TCP connection table contains information about this entitys existing TCP connections. tcpConnTable OBJECTTYPE SYNTAX SEQUENCE OF TcpConnEntry ACCESS notaccessible STATUS mandatory DESCRIPTION "A table containing TCP connectionspecific information." ::= { tcp 13 } tcpConnEntry OBJECTTYPE SYNTAX TcpConnEntry ACCESS notaccessible STATUS mandatory DESCRIPTION "Information about a particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state." INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 }

Ce petit exemple montre que lidentication dun objet repose sur cinq champs : 1. Le nom de lobjet, tcpConnTable qui balise le d ebut de la d enition 2. (SYNTAX) La syntaxe dusage. Ici une liste dobjets tcpConnEntry. On y reconna tra sans peine les el ements du quintuplet vus en cours TCP. 3. (ACCESS) Lacc` es (lecture, ecriture, lecture- ecriture, pas accessible). Ici On ne peut ni lire ni ecrire dans cet objet. 4. (STATUS) L etat de lobjet, valeur ` a prendre dans obligatoire (MANDATORY), obsol` ete ou optionnel. 5. (DESCRIPTION) Un texte qui d ecrit ce que repr esente lobjet. Les lignes qui d ebutent par un sont des commentaires. Enn on peut remarquer que ce bloc de texte se termine par ::= { tcp 13 } qui signie que cet objet est le treizi` eme ls de lobjet p` ere tcp. Tous les objets de toutes les MIBs (propri etaires ou non) sont organis es dans un seul arbre, donc avec une seule racine commune. Pour identier un objet dans cet ensemble, on parle de son OID.

230

Gestion de r eseaux avec SNMP

3.1

OID Objet Identier

Le nommage des objets utilise une repr esentation arborescente dont la racine est g ee mais qui est extensible ` a volont e. Le nommage dun objet passe par la d enition (en ASN.1) dun Objet IDentier ou OID, qui peut sapparenter au path dun chier. Ce chemin peut sexprimer de mani` ere symbolique, par exemple .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 ou encore dans une repr esentation num erique absolument equivalente .1.3.6.1.2.1.1.1 En pratique on pourra le plus fr equemment faire r ef erence seulement ` a sysDescr.04 . La racine de larbre est ` a gauche, contrairement, par exemple, au syst` eme de nommage du DNS qui place la racine ` a droite. En eet un OID est une s equence dentiers, parcours dans larbre de la racine jusqu` a la feuille terminale. Chaque noeud travers e est etiquett e par un nombre et un bref texte descriptif. Bien entendu lunicit e de l etiquettage ` a un niveau donn e de larbre est primordial pour son bon fonctionnement. La racine nest pas nomm ee, do` u le point (.) ` a gauche des deux ecritures qui pr ec` edent. ` ce jour deux entit A es se partagent les trois noeuds du premier niveau de 5 larbre : lISO et le CCITT6 , le troisi` eme noeud sexplique par une entit e mixte des deux et nomm ee joint-iso-ccitt .
root ccitt(0) iso(1) org(3) dod(6) internet(1) directory(1) mgmt(2) mib2(1) experimental(3) private(4) enterprises(1) Internet SMI security(5) snmpv2(6) jointisoccitt(2)

gure XI.02 La racine de larbre des OIDs Sous le noeud de liso un sous arbre est pr evu pour dautres organisations, lune delle est le d epartement de la d efense US (dod). La RFC 1155 pose le fait quun sous arbre du dod est allou e` a lIAB (Internet Activity Board), sans doute une trace des origines militaires de la pile Arpa. Et voila pourquoi les OIDs standards sont plac es sous le noeud nomm e
Notez la pr esence du 0 en n de cha ne qui ne fait pas partie du nommage mais est un artice ` a linterrogation pour indiquer quil sagit dune feuille de larbre et non par exemple la base dun tableau 5 International Organization for Standardisation 6 International Telegraph and Telephone Consultative Committee
4

MIB Management Information Base mib-2(1) et que le pr exe le plus commun est .1.3.6.1.2.1, indices des noeuds p` eres travers es ` a partir de la racine ! Directory(1) R eserv e pour lOSI mgmt(2) Ladministration de ce sous arbre est d el egu e` a lIANA7 et est donc r egit par des RFCs ! Experimental(3) Utilis e pour identier des objets utilis es pour des d eploiements exp erimentaux sur lInternet. D el egu e` a lIANA. Private(4) Comme son nom lindique ce sous arbre est celui des d el egations priv ees. Le sous arbre enterprise(1) permet aux entreprises dy placer leurs MIBs, apr` es s etre enregistr ees aupr` es de lIANA. ...

231

3.2

Types de donn ees el ementaires

Le type des objets utilis es dans les MIBs est limit e` a un sous ensemble des types disponibles dans ASN.1, mais susant pour exprimer les compteurs, les tables et les identicateurs que lon trouve dans la m emoire dun syst` eme dexploitation. INTEGER De nombreux compteurs du syst` eme dexploitation utilisent un tel type, comme par exemple ceux des statistiques extraites du noyau par la commande netstat -s -p ip. OCTETS STRINGS Pour d enir une cha ne de caract` eres comme une suite de 0 ou plus octets de 8 bits. NULL Pour dire quil ny a pas de valeur. OBJECT IDENTIFIER Pour d enir les objets (OID). SEQUENCE Se rapproche de la notion de structure du langage C, autrement dit pour grouper plusieurs types dans un seul. SEQUENCE-OF Introduit la notion de vecteur. Bien que ces types de donn ees puissent ressembler ` a ceux de tel ou tel langage de programmation, leur repr esentation interne di` ere tr` es certaine8 ment puisquelle respecte les Basic Encoding Rules , ou BER, an d etre abolument portables sur tout type de plateforme. BER est une m ethode dencodage des valeurs pour tous les types d enis par ASN.1, sous forme dune cha ne doctets et bas ee sur lusage dun triplet de valeurs (type, longueur, valeur) ou TLV. Ainsi par exemple les cha nes de caract` eres ne sont pas termin ees par un caract` ere null (Ascii 0) comme dans le langage C mais sont encod ees directement avec leur longueur.
7 8

Internet Assigned Numbers Authority d evelopp e et standardis e par le CCITT (X.209) et lISO (ISO 8825)

232

Gestion de r eseaux avec SNMP

La MIB-2

la mib standard la plus courante est la MIB-2 d enie dans la RFC 1213, cest un sur-ensemble de la mib dorigine (MIB-I) d enie dans la RFC 1156. Cette mib regroupe les compteurs les plus courants associ es ` a une pile Arpa et dautres comme ceux associ es ` a la technologie Token-Ring, FDDI, Microsoft Lan Manager, DECnet, pour information. La racine du sous-arbre concern ee est clairement mgmt, cest ` a dire .1.3.6.1.2 et le noeud concern e est mib-2(1) qui est lOID d eni ligne 15. Puis viennent les 10 sous arbres d ecrits plus avant dans cette mib : system(1) Le groupe system fournit des informations dordre g en eral sur le system lui-m eme, comme le-mail dun contact, la valeur de l uptime ou encore la location physique de lappareil. interfaces(2) Le groupe interfaces regroupe toutes les informations sur les interfaces physiques ou virtuels pr esents, leur type, le fabricant, leur caract eristiques et enn les statistiques dusage. at(3) Ce groupe est une seule table de correspondances entre les adresses physiques et logiques. Pour une pile Arpa il sagit de la table des adresses physique(MAC), telle quelle peut etre extraite par la commande arp -an. ip(4) Le groupe ip contient toutes informations relatives ` a ce protocole (adresse, netmask), notamment la table de routage et tous les compteurs auxquels on peut acc eder ` a laide de netstat -s -p ip. icmp(5) Le groupe icmp contient toutes les informations relatives ` a ce protocole. Le compteur du nombre d echo request est par exemple accessible, tout comme il peut l etre avec un netstat -s -p icmp. Tous les messages sont associ es ` a deux compteurs. tcp(6) Le groupe tcp contient toutes les informations relatives ` a ce protocole, par exemple celles que lon peut obtenir ` a laide dun netstat -s -p tcp plus dautres comme la liste des connexions en cours avec leur etat. udp(7) Le groupe udp regroupe toutes les informations relative ` a ce protocole (netstat -s p -udp). G` ere egalement la liste des applications utilisant ce protocole. egp(8) Le groupe egp regroupe les informations relatives au protocole de routage Exterior Gateway Protocol . transmission(10) Le groupe transmission regroupe des interfaces d ej` a d enies dans le Interfaces(2). mais selon dautres crit` eres, comme par exemple les protocoles support es. snmp(11) Ce groupe donne des informations sur limpl ementation et lex ecution de SNMP lui-m eme, cest ` a dire le nombre de message entrants, sortants, la r epartition du type de requ etes re cues, emises.

La MIB-2 Voici un extrait du d ebut de cette mib :

RFC1213MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155SMI OBJECTTYPE FROM RFC1212; This MIB module uses the extended OBJECTTYPE macro as defined in [14]; MIBII (same prefix as MIBI) OBJECT IDENTIFIER ::= { mgmt 1 }

233

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

mib2

textual conventions DisplayString ::= OCTET STRING This data type is used to model textual information taken from the NVT ASCII character set. By convention, objects with this syntax are declared as having SIZE (0..255)

PhysAddress ::= OCTET STRING This data type is used to model media addresses. For many types of media, this will be in a binary representation. For example, an ethernet address would be represented as a string of 6 octets. groups in MIBII system interfaces at ip icmp tcp udp egp OBJECT IDENTIFIER ::= { mib2 1 } OBJECT IDENTIFIER ::= { mib2 2 } OBJECT IDENTIFIER ::= { mib2 3 } OBJECT IDENTIFIER ::= { mib2 4 } OBJECT IDENTIFIER ::= { mib2 5 } OBJECT IDENTIFIER ::= { mib2 6 } OBJECT IDENTIFIER ::= { mib2 7 } OBJECT IDENTIFIER ::= { mib2 8 }

historical (some say hysterical) cmot OBJECT IDENTIFIER ::= { mib2 9 } transmission OBJECT IDENTIFIER ::= { mib2 10 } snmp OBJECT IDENTIFIER ::= { mib2 11 }

234

Gestion de r eseaux avec SNMP

Protocole SNMP

le protocole SNMP est du type client/serveur classique. Un vocabulaire sp ecique : le serveur est nomm e Agent SNMP alors que le client est un Manager ou encore Network Management Software (NMS). Le serveur (agent) ecoute les requ etes du client (manager) sur le port 161 (UDP) et peut lui envoyer des messages dexception (trap) sur son port 162. Le choix du transport UDP est justi e par le trac de petits datagrammes (la RFC 1157 An implementation of this protocol need not accept messages whose length exceeds 484 octets . Les besoins ont evolu e mais ce choix initial perdure. Aux parties applicatives la t ache de faire le travail dune couche de transport si besoin est (gestion dun time-out et de la re emission des datagrammes manquants). Le client (manager), interroge ` a son rythme les agents sur leur port 161 et ecoute sur le port 162 (UDP) les eventuels messages dexceptions envoy es par ces m emes agents. Il faut noter que le protocole permet non seulement la lecture de variables mais aussi leur modication, ce qui pose des probl` emes dauthentication et de condentialit e, non r esolus avec SNMPv1 et SNMPv2. En eet, ce qui fait oce de m ecanisme dauthentication est une cha ne de caract` eres qui circule en clair sur le r eseau, cest la fameuse communaut e dont la valeur par d efaut sur les equipement est traditionnellement public . La plupart du temps on se borne donc ` a laspect read only du protocole et seulement pour des echanges sur des r eseaux qui devraient etre prot eg es, par exemple cantonn es sur un vlan dadministration sur lequel ne circule aucun trac applicatif inutile et surtout auquel aucun utilisateur standard nacc` ede.
Agent Agent Agent Agent

:161(UDP)
getrequest getnextrequest setrequest getresponse getbulkrequest

:161

:161 :162 (UDP)

:161
Trap

Manager

gure XI.03 Des agents et un Manager

Protocole SNMP

235

5.1

Communaut e

La communaut e SNMP est une relation entre un agent et les stations dadministration qui linterrogent. Cette unique cha ne de caract` eres d enit ` a la fois lauthentication et le contr ole dacc` es. Il peut y avoir autant de communaut es que dagents, cest au manager den conserver la liste. Chaque message dune station dadministration vers un agent comporte le nom de la communaut e et donc permet ` a lagent dauthentier la source de la requ ete. Ce mode dauthentication nest bien s ur plus adapt e aux contraintes de s ecurit e quimpose lexploitation moderne des r eseaux. Le minimum pour exploiter malgr e tout SNMPv2 est davoir au moins trois communaut es di erentes : une pour la lecture (GET), une pour l ecriture (SET) et une troisi` eme pour les traps.

5.2

PDUs

Que ce soit pour des requ etes, des r eponses aux requ etes, ou lenvoi dun trap, SNMPv2 sappuie sur un message dont le format est d ecrit succintement dans la gure 04 :
Message SNMP Entete standard Com munaut Get/Set/Trap

IP

UDP

Version

Protocol Data Unit (PDU)

ID PDU type requete

(variable, valeur)

GetRequest, GetNextRequest, SetRequest, Trap, InformRequest ID PDU type requete Response ID PDU type requete GetBulkRequest max non repeaters repetitions Statut derreur Index derreur

(variable, valeur)

(variable, valeur)

gure XI.04 Format des messages SNMP La partie standard de len-t ete, comporte deux champs : Version Il sagit de la version du protocole, 1, 2 ou 3. Communaut e Une cha ne doctets qui identie la communaut e, public par d efaut. . .

236

Gestion de r eseaux avec SNMP Ensuite le message est compos e dune partie dont la longueur et le contenu sont assez variables, selon les op erations. Cest ce quon appelle le PDU ( Protocol Data Unit ). Il y en a sept possibles. En eet, le protocole de base (SNMPv1) pr evoit cinq types de requ etes : GetRequest Cest une question du manager ` a lagent. Une liste de couples (variable,valeur) est fournie. Les valeurs sont positionn ees ` a unSpecified. GetNextRequest Cette requ ete est assez voisine de la pr ec edente ` a ceci pr` es que lOID exact de la variable est d etermin e en prenant le plus proche dans lordre lexicographique (dou le sens de next ). SetRequest Cest une demande du manager ` a lagent pour positionner une certaine valeur ` a chacune des variables list ees. GetResponse Cest la r eponse ` a toutes les requ etes Get/Set qui pr ec` edent. Trap Envoy e depuis lagent vers le manager, associ e` a une liste de couples (variable,valeur). Il ny a pas de r eponse ` a un trap. Auquels SNMPv2 en ajoute deux autres : GetBulkRequest Pour r ecup erer des donn ees de grande taille, cest ` a dire des morceaux complets de larbre. Les deux champs non repeaters et max repetitions servent alors ` a param` etrer les limites de ce transfert, dans la limite de la taille dun message. InformRequest Sert ` a la communication entre managers. Une station dadministration envoie des donn ees vers une autre station qui centralise les informations contenues dans la MIB manager to manager . Le message a le m eme format quun Get. Ce type de message est une sorte de m ecanisme de traps entre managers (conguration dalarmes, ensemble d ev enements choisis). Ainsi le champ PDU type peut-il prendre lune de ces sept valeurs et conduire ` a autant de PDUs di erents, en taille et en signication. Chaque champ de len-t ete SNMP ` a une taille variable, selon limpl ementation des OIDs de la MIB. PDU type Valeur ` a prendre dans la liste get-request, get-next-request, get-bulk-request, response, set-request, inform-request, snmpv2-trap. RequestID Cest un num ero de requ ete, la r eponse doit porter le m eme num ero que celui de la requ ete. Error-status Une valeur non nulle indique une erreur pendant le traitement de la requ ete. Error-index Quand error-status nest pas nul, ce champ identie le num ero dordre du couple (variable,valeur) qui pose probl` eme. Le premier a 1 comme index. (variable,valeur) Il sagit de couple, la variable est un OID et la valeur est celle associ ee ` a lOID.

Protocole SNMP

237

5.3

SNMPv3

238

Gestion de r eseaux avec SNMP

Loutil NET-SNMP

Dabord nomm e UCD-SNMP au d ebut des ann ees 1990 ` a luniversit e de Carnegie-Mellon, le projet sest transform e en NET-SNMP au d ebut des ann eees 2000 et est maintenant la base de nombreux outils open-source ou non. Sa abilit e est telle quun OS industriel tel que Solaris 109 nh esite pas ` a le placer dans son core OS :
#solaris10$ /usr/sfw/sbin/snmpd -version NET-SNMP version: Web: Email: 5.0.9 http://www.net-snmp.org/ net-snmp-coders@lists.sourceforge.net

Loutil net-snmp est dabord un outil dadministrateur syst` eme donc est essentiellement compos e de commandes ` a taper dans un shell. Il existe dautres approches plus graphiques, nous donnerons quelques pistes dans le paragraphe suivant. Commandes pour interroger un agent : snmpget, snmpgetnext, snmpwalk snmptable,snmpdelta Commande pour positionner une valeur : snmpset Un daemon pour recevoir les notications : snmptrapd Un agent : snmpd Nous allons mettre en uvre quelques exemples dusage de ces outils avec certains des OIDs de la MIB-2. On suppose que la machine localhost est accessible avec public comme valeur pour la communaut e dacc` es en mode lecture seule.

6.1

snmptranslate

Dans sa forme la plus simple cette commande prend un OID et ache la valeur textuelle correspondante. Prenons le cas de luptime cest ` a dire au sens de SNMP le nombre de centi` emes de seconde ecoul ees depuis que la partie r eseau a et e initialis ee. Son nom textuel est SNMPv2-MIB::sysUpTime.
$ snmptranslate -On SNMPv2-MIB::sysUpTime .1.3.6.1.2.1.1.3 $ snmptranslate -Of SNMPv2-MIB::sysUpTime.0 .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance

On peut egalement utiliser une expression r eguli` ere :

9

http://www.sun.com

Loutil NET-SNMP
$ snmptranslate -TB sys.*Time SNMPv2-MIB::sysORUpTime SNMPv2-MIB::sysUpTime DISMAN-EVENT-MIB::sysUpTimeInstance HOST-RESOURCES-MIB::hrSystemUptime

239

Mais aussi lutiliser pour obtenir plus dinformation sur lOID :

$ snmptranslate -On -Td SNMPv2-MIB::sysUpTime .1.3.6.1.2.1.1.3 sysUpTime OBJECT-TYPE -- FROM SNMPv2-MIB, RFC1213-MIB SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 3 } $ snmptranslate -IR -Tp SNMPv2-MIB::system +--system(1) | +-- -R-- String sysDescr(1) | Textual Convention: DisplayString | Size: 0..255 +-- -R-- ObjID sysObjectID(2) +-- -R-- TimeTicks sysUpTime(3) | | | +--sysUpTimeInstance(0) | +-- -RW- String sysContact(4) | Textual Convention: DisplayString | Size: 0..255 +-- -RW- String sysName(5) | Textual Convention: DisplayString | Size: 0..255 +-- -RW- String sysLocation(6) | Textual Convention: DisplayString | Size: 0..255 +-- -R-- INTEGER sysServices(7) | Range: 0..127 +-- -R-- TimeTicks sysORLastChange(8) | Textual Convention: TimeStamp | +--sysORTable(9) | +--sysOREntry(1) | Index: sysORIndex | +-- ---- INTEGER sysORIndex(1) | Range: 1..2147483647 +-- -R-- ObjID sysORID(2) +-- -R-- String sysORDescr(3) | Textual Convention: DisplayString

240

Gestion de r eseaux avec SNMP

| Size: 0..255 +-- -R-- TimeTicks sysORUpTime(4) Textual Convention: TimeStamp

Le lecteur curieux den savoir plus pourra essayer la commande snmptranslate -IR -Tp ! Lextrait suivant de la MIB montre le d ebut de la description du groupe system.

Loutil NET-SNMP

241

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

the System group Implementation of the System group is mandatory for all systems. If an agent is not configured to have a value for any of these variables, a string of length 0 is returned.

sysDescr OBJECTTYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS readonly STATUS mandatory DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the systems hardware type, software operatingsystem, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 } sysObjectID OBJECTTYPE SYNTAX OBJECT IDENTIFIER ACCESS readonly STATUS mandatory DESCRIPTION "The vendors authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining what kind of box is being managed. For example, if vendor Flintstones, Inc. was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its Fred Router." ::= { system 2 } sysUpTime OBJECTTYPE SYNTAX TimeTicks ACCESS readonly STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last reinitialized." ::= { system 3 } sysContact OBJECTTYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS readwrite STATUS mandatory DESCRIPTION "The textual identification of the contact person for this managed node, together with information on how to contact this person." ::= { system 4 }

242

Gestion de r eseaux avec SNMP

6.2

snmpget

Cette commande correspond ` a lop eration la plus el ementaire du protocole SNMP, aller chercher linformation relative ` a un OID pr ecis sur un agent.
$ snmpget -v 2c -c public localhost SysUpTimeInstance DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (33310293) 3 days, 20:31:42.93 $ snmpget -v 2c -c public localhost SNMPv2-MIB::sysLocation SNMPv2-MIB::sysLocation = No Such Instance currently exists at this OID

Une erreur courante avec cette commande est doublier lindex ( instance subidentier ) de la donn ee demand ee. Le cas le plus courant est pour les donn ees de type scalaire, il ny a quune seule valeur alors il ne semble pas n ecessaire de pr eciser un index. Cet index est toujours un simple z ero (0) comme lexemple ci-dessous le montre.
$ snmpget -v 2c -c public localhost SNMPv2-MIB::sysLocation.0 SNMPv2-MIB::sysLocation.0 = STRING: S110

Ce point de d etail technique sav` ere vite lassant, cest pourquoi on utilise plus fr equemment la commande suivante. . .

6.3

snmpgetnext

$ snmpgetnext -v 2c -c public localhost SNMPv2-MIB::sysUpTime.0 SNMPv2-MIB::sysContact.0 = STRING: Francois Laissus

La commande renvoie la valeur associ ee ` a lOID (ou aux OIDs) suivant, ainsi on a limpression que lexemple ci-dessus est dicilement utilisable en pratique ! En fait il nen est rien et lexemple suivant devrait dissiper cette fausse impression :
$ snmpgetnext -v 2c -c public localhost SNMPv2-MIB::sysUpTime DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (34853433) 4 days, 0:48:54.33

Un usage tr` es employ e de cette commande est de lutiliser avec une OID incompl` ete, par exemple sans lindex ( instance subidentier ) et lagent en d etermine la procha ne instance compl` ete associ ee ` a sa valeur. Cest une sorte de m ecanisme rudimentaire de compl etion.

6.4

snmpwalk

Cette commande eectue des requ ete de type get-next pour explorer toute larborescence des sous-arbres li es ` a un OID. Par exemple :
$ snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.5 IP-MIB::icmpInMsgs.0 = Counter32: 205413 IP-MIB::icmpInErrors.0 = Counter32: 0 IP-MIB::icmpInDestUnreachs.0 = Counter32: 205039

Loutil NET-SNMP
IP-MIB::icmpInTimeExcds.0 = Counter32: 43 IP-MIB::icmpInParmProbs.0 = Counter32: 0 IP-MIB::icmpInSrcQuenchs.0 = Counter32: 0 IP-MIB::icmpInRedirects.0 = Counter32: 0 IP-MIB::icmpOutDestUnreachs.0 = Counter32: 203947 ...

243

Permet dacc eder dun seul coup ` a toutes les compteurs relatifs ` a SNMP (la sortie a et e tronqu ee). Le lecteur pourra essayer lOID 1.3.6 en argument. . .

6.5

snmptable

Comme son nom le sugg` ere, cette commande est plut ot utilis ee pour manipuler des tables. Ici il sagit de la liste des interfaces et de leurs compteurs associ es.
$ snmptable -v 2c -c public -Os -Cw 80 localhost ifTable SNMP table: ifTable ifIndex ifDescr ifType ifMtu ifSpeed ifPhysAddress ifAdminStatus 1 em0 ethernetCsmacd 1500 1000000000 0:6:5b:f:5a:31 up 2 em1 ethernetCsmacd 1500 1000000000 0:6:5b:f:5a:32 down 3 lo0 softwareLoopback 16384 0 up SNMP table ifTable, part 2 ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts ifInDiscards up 0:0:00:00.00 2318958978 2767895021 2 0 down 0:0:00:00.00 0 0 0 0 up 0:0:00:00.00 90441064 717640 0 0 SNMP table ifTable, part 3 ifInErrors ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts 0 0 2137908126 2767886776 0 0 0 0 0 0 0 0 90441687 717644 0 SNMP table ifTable, part 4 ifOutDiscards ifOutErrors ifOutQLen ifSpecific 0 0 ? ? 0 0 ? ? 0 0 ? ?

6.6

snmpset

Pour changer la valeur dune donn ee, donc d econseill e en SNMPv2.

244

Gestion de r eseaux avec SNMP

6.7

Approche graphique

Ce premier exemple graphique montre un outil open-source nomm e 10 mbrowse simple et bien commode pour interroger nimporte quel agent ` a partir dun interface graphique assez intuitif.

gure XI.05 Exemple dinterrogation dun agent avec loutil mbrowse Dans un deuxi` eme exemple, il sagit dextraire le contenu de la table ifTable, comme nous avons pu le faire pr ec edemment avec snmptable, ce coup-ci avec la commande snmpwalk, puis de traiter graphiquement le r esultat.
$ snmpwalk -c public -v2c gw ifTable IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.2 = INTEGER: 2 IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifDescr.1 = STRING: fxp0 IF-MIB::ifDescr.2 = STRING: plip0 IF-MIB::ifDescr.3 = STRING: lo0
10

http://www.kill-9.org/mbrowse/

Loutil NET-SNMP
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.2 = INTEGER: para(34) IF-MIB::ifType.3 = INTEGER: softwareLoopback(24) IF-MIB::ifMtu.1 = INTEGER: 1500 IF-MIB::ifMtu.2 = INTEGER: 1500 IF-MIB::ifMtu.3 = INTEGER: 16384 IF-MIB::ifSpeed.1 = Gauge32: 100000000 IF-MIB::ifSpeed.2 = Gauge32: 0 IF-MIB::ifSpeed.3 = Gauge32: 0 IF-MIB::ifPhysAddress.1 = STRING: 0:2:b3:3d:22:5 IF-MIB::ifPhysAddress.2 = STRING: IF-MIB::ifPhysAddress.3 = STRING: ... IF-MIB::ifInOctets.1 = Counter32: 29017357 ... IF-MIB::ifOutOctets.1 = Counter32: 3117625 ...

245

O` u lon sapper coit que cette machine a trois interfaces, nomm ees respectivement fxp0, plip0 et lo0. On voit egalement que le mtu de linterface de loopback (lo0) est de 16384 octets et que linterface fxp0 est le seul qui travaille r eellement au vu des compteurs qui lui sont associ es, 29017357 octets en entr ee et 3117625 en sortie, depuis que la machine est en route (voir sysUpTime). Bien entendu cette approche manuelle est trop lourde pour etre utilis ee telle que pour surveiller un r eseau ! Il est indispensable dutiliser des outils capables de faire la synth` ese de tous ces compteurs, par exemple pour les pr esenter sous forme graphique. Loutil mrtg11 est capable de produire tr` es simplement un tel graphique avec jusqu` a une ann ee dhistorique pour nimporte quel interface :

gure XI.06 Synth` ese graphique des compteurs ifInOctets et ifOutOctets sur
24h

Il existe dautres MIBs, notamment applicatives comme celle d enie par la RFC 1611 qui concerne le serveur de noms et celle d enie par la RFC 2790 qui concernes les ressources de lh ote lui-m eme (espace disque, charge...) et que lon peut surveiller egalement avec loutil mrtg. Il est ainsi ais e de faire des graphiques dusage de la m emoire, des disques, de la charge de la machine, etc. . .
11

http://oss.oetiker.ch/mrtg/

246

Gestion de r eseaux avec SNMP

7 Glossaire des acronymes SNMP

247

La page pr ec edente est un exemple d ecran de surveillance dun r eseau aujourdhui compl` etement d emantel e, et obtenu ` a laide de loutil open-source tkined !

Glossaire des acronymes SNMP

Agent Cest le logiciel embarqu e dans lh ote r eseau, quel quil soit. Il fonctionne en mode serveur et est ` a l ecoute en UDP sur le port 161 (snmp) Il est egalement susceptible denvoyer des traps vers le port 162 du ou des manager(s). ASN1 Abstract Syntax Notation One est une norme internationale 12 dont la vocation premi` ere est la sp ecication de donn ees utilis ees dans les protocoles de communication. BER Basic Encoding Rules M ethode dencodage des valeurs pour tous les types d enis dans ASN.1. Manager Le logiciel de supervision. Il interroge les agents dans une relation de type client serveur dont il assume la partie cliente. Le manager est destinataire des traps , quil r eceptionne en UDP sur le port 162 (snmptrap). MIB Management Information Base . Cest la description de tous les composants logiciels ou mat eriels surveill es par lagent. Chaque composant est d esign e par son OID. La MIB est ecrite ` a laide du langage ASN.1 et selon une SMI bien pr ecise. Cest un arbre, dont les nu ds et les feuilles sont rep er es de mani` ere unique par un chire. NMA Network Management Application . Est une autre mani` ere, non sp ecique ` a SNMP, de d esigner le manager. NME Network Management Entity . Est une autre mani` ere, non sp ecique ` a SNMP, de d esigner lagent. NMS Network Management Software . Synonyme de NMA. OID Object IDentier . Cest la d esignation unique dun objet dans la structure en arbre de la MIB. PDU Protocol Data Unit . Il sagit des paquets r eseau, structur es selon le d etail du protocol applicatif SNMP. RMON Remote Network Monitoring . Il sagit dun agent particulier dont lobjet est la surveillance du r eseau lui m eme et non un h ote en particulier. On d esigne souvent ces agents sous la terminologie de sonde RMON. SMI Structure of Management Information . Cest la description du contenu et du formatage des donn ees dune MIB.
12

http ://asn1.elibel.tm.fr/fr/

248

Gestion de r eseaux avec SNMP SNMP Simple Network Management Protocol . Cest le nom du protocole r eseau qui sert ` a interroger les agents/sondes RMON. Trap Cest un message dexception envoy e depuis lagent vers le port 162 du (des) manager(s).

Liens & Bibliographie

Quelques RFCs minimales et en nombre non exhaustif ! RFC 1115, 1156, 1157, 1213, 1901 ` a 1908, 3411 ` a 3418 Des urls : Pour ASN.1 http://www.asn1.org/ http://asn1.elibel.tm.fr/ http://www.itu.int/ITU-T/asn1/ Pour SNMP lui-m eme :

http://www.snmplink.org/ http://www.faqs.org/faqs/snmp-faq/part1/index.html http://www.faqs.org/faqs/snmp-faq/part2/index.html http://www.net-snmp.org/wiki/index.php/Tutorials http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNM Quelques outils en vrac : Net-Snmp Mrtg Scotty Mbrowse http://net-snmp.sourceforge.net/ http://oss.oetiker.ch/mrtg/ http://wwwhome.cs.utwente.nl/~schoenw/scotty/ http://www.kill-9.org/mbrowse/

Quelques ouvrages de r ef erence : William Stalling SNMPv1, SNMPv2, SNMPv3 and RMON 1 and 2 (third Edition) AddisonWesley 1999. Douglas R. Mauro and Kevin J. Schmidt Essential SNMP OReilly 2001. W. Richard Stevens TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley

Quatri` eme partie Sockets BSD et architecture de serveurs

Chapitre XII G en eralit es sur les sockets de Berkeley

1 G en eralit es

La version BSD 4.1c dUnix pour VAX, en 1982, a et e la premi` ere ` a inclure TCP/IP dans le noyau du syst` eme dexploitation et ` a proposer une interface 1 de programmation de ces protocoles : les sockets . Les sockets sont ce que lon appelle une API ( Application Program Interface ) cest ` a dire une interface entre les programmes dapplications et la couche transport, par exemple TCP ou UDP. N eanmoins les sockets ne sont pas li ees ` a TCP/IP et peuvent utiliser dautres protocoles comme AppleTalk, X erox XNS, etc. . .

Application Transport

Programmes applicatifs API = sockets Noyau du systme

Internet Rseau

Pilotes de priphriques

Matriel

gure XII.01 Les sockets, une famille de primitives Les deux principales API pour Unix sont les sockets Berkeley et les TLI System V. Ces deux interfaces ont et e d evelopp ees en C. Les fonctionnalit es des sockets que nous allons d ecrire, sont celles apparues ` a partir de la version 4.3 de BSD Unix, en 1986. Il faut noter que les
Pour un historique tr` es int eressant de cette p eriode on pourra consulter http://www. oreillynet.com/pub/a/network/2000/03/17/bsd.html
1

252

Sockets de Berkeley constructeurs de stations de travail comme HP, SUN2 , IBM, SGI, ont adopt e ces sockets, ainsi sont-elles devenues un standard de fait et une justication de leur etude. Pour conforter ce point de vue il nest pas sans int er et dajouter que toutes les applications majeures (named, dhcpd, sendmail, ftpd, apache,. . .) Open Sources de lInternet, utilisent cette API. Enn, et avant dentrer dans le vif du sujet, le sch ema ci-dessous rappelle les relations entre pile ARPA, N de port et processus.

Application

Processus utilisateurs

Application

...

Noyau Mcanisme de gestion des ports (session).

...

Transport Internet Rseau

Transport Internet Rseau

gure XII.02 Relation pile IP, num ero de port et process ID

Pr esentation des sockets

Les cr eateurs des sockets ont essay e au maximum de conserver la s emantique des primitives syst` emes dentr ees/sorties sur chiers comme open, read, write, et close. Cependant, les m ecanismes propres aux op erations sur les r eseaux les ont conduits ` a d evelopper des primitives compl ementaires (par exemple les notions de connexion et dadresse IP nexistent pas lorsque lon a besoin douvrir un chier !). Quand un processus ouvre un chier (open), le syst` eme place un pointeur sur les structures internes de donn ees correspondantes dans la table des descripteurs ouverts de ce processus et renvoie lindice utilis e dans cette table. Par la suite, lutilisateur manipule ce chier uniquement par linterm ediaire de lindice, aussi nomm e descripteur de chier. Comme pour un chier, chaque socket active est identi ee par un petit entier appel e descripteur de socket. Unix place ce descripteur dans la m eme
Les applications natives de ce constructeur utilisent les TLI, par contre il est possible dutiliser les sockets dans toutes les applications que lon recompile soi-m eme, elles sont pr esentes dans des biblioth` eques pr ecis ees lors de la compilation des sources
2

 3 Etude des primitives table que les descripteurs de chiers, ainsi une application ne peut-elle pas avoir un descripteur de chier et un descripteur de socket de m eme valeur. Pour cr eer une socket, une application utilisera la primitive socket et non open, pour les raisons que nous allons examiner. En eet, il serait tr` es agr eable si cette interface avec le r eseau conservait la s emantique des primitives de gestion du syst` eme de chiers sous Unix, malheureusement les entr ees/sorties sur r eseau mettent en jeux plus de m ecanismes que les entr ees/sorties sur un syst` eme de chiers, ce nest donc pas possible. Il faut consid erer les points suivants : 1. Dans une relation du type client-serveur les relations ne sont pas sym etriques. D emarrer une telle relation suppose que le programme sait quel r ole il doit jouer. 2. Une connexion r eseau peut etre du type connect ee ou non. Dans le premier cas, une fois la connexion etablie le processus origine discute uniquement avec le processus destinataire. Dans le cas dun mode non connect e, un m eme processus peut envoyer plusieurs data-grammes ` a plusieurs autres processus sur des machines di erentes. 3. Une connexion est d enie par un quintuplet (cf cours TCP page 89) qui est beaucoup plus compliqu e quun simple nom de chier. 4. Linterface r eseau supporte de multiples protocoles comme XNS, IPX, APPLETALK3 , la liste nest pas exhaustive. Un sous syst` eme de gestion de chiers sous Unix ne supporte quun seul format. En conclusion de ce paragraphe on peut dire que le terme socket d esigne, dune part un ensemble de primitives, on parle des sockets de Berkeley, et dautre part lextr emit e dun canal de communication (point de communication) par lequel un processus peut emettre ou recevoir des donn ees. Ce point de communication est repr esent e par une variable enti` ere, similaire ` a un descripteur de chier.

253

Etude des primitives

Ce paragraphe est consacr e` a une pr esentation des primitives essentielles pour programmer des applications en r eseaux. Pour etre bien complet il est fortement souhaitable de consulter les pages de manuels associ ees aux primitives et la documentation cit ee en n de chapitre page 273.

3.1
3

Cr eation dune socket

La cr eation dune socket se fait par lappel syst` eme socket.

Linspection du chier /usr/include/sys/socket.h sous FreeBSD 6.x en explicite une petite quarantaine

254
#include #include #include <sys/types.h> <sys/socket.h> <netinet/in.h>

Sockets de Berkeley
/* Pour toutes les primitives */ /* de ce chapitre il faut */ /* inclure ces fichiers. */

int socket(int PF, int TYPE, int PROTOCOL) ;

PF Sp ecie la famille de protocole ( Protocol Family ) ` a utiliser avec la socket. On trouve (extrait) par exemple sur FreeBSD 4 7.0 : PF PF PF PF PF PF PF INET INET6 LOCAL UNIX ROUTE KEY LINK : : : : : : : Pour les sockets IPv4 Pour les sockets IPv6 Pour rester en mode local (pipe). . . Idem AF LOCAL Acc` es ` a la table de routage Acc` es ` a une table de clefs (IPsec) Acc` es ` a la couche Link impl ementations notamment avec les proto: Pour les r eseaux Apple : Pour le protocole Xerox NS : Pour le protocole de lOSI : Pour le protocole SNA dIBM : Protocole Internet de Novell : Asynchronous Transfert Mode : ...

Mais il existe dautres coles5 : PF APPLETALK PF NS PF ISO PF SNA PF IPX PF ATM ...

Le pr exe PF est la contraction de Protocol Family On peut egalement utiliser le pr exe AF, pour Address Family . Les deux nommages sont possibles ; l equivalence est d enie dans le chier dent ete socket.h. TYPE Cet argument sp ecie le type de communication d esir e. En fait avec la famille PF INET, le type permet de faire le choix entre un mode connect e, un mode non connect e ou une intervention directe dans la couche IP : SOCK STREAM SOCK DGRAM SOCK RAW : Mode connect e Couche transport : Mode non connect e Idem : Dialogue direct avec la couche IP

Faut-il repr eciser que seules les sockets en mode connect e permettent les liaisons full-duplex ? PROTOCOL Ce troisi` eme argument permet de sp ecier le protocole ` a uti6 liser. Il est du type UDP ou TCP le plus couramment .
www.freebsd.org On en compte 38 sur une machine FreeBSD 7.0 (22/10/2008) 6 il en existe au mois un autre pour les sockets de type PF INET et PF INET6, nomm e SCTP et qui nest pas (encore) trait e dans ce cours
5 4

 Etude des primitives IPPROTO IPPROTO IPPROTO IPPROTO TCP SCTP UDP RAW, IPPROTO ICMP : : : : TCP SCTP UDP uniquement avec SOCK RAW

255

PROTOCOL est typiquement mis ` a z ero car lassociation de la famille de protocole et du type de communication d enit explicitement le protocole de transport : PF INET + SOCK STREAM PF INET + SOCK DGRAM = = TCP = IPPROTO TCP UDP = IPPROTO UDP

Cest une constante d enie dans le chier den-t etes /usr/include/netinet/in.h et qui re` ete le contenu du chier syst` eme /etc/protocols. 3.1.1 Valeur retourn ee par socket

La primitive socket retourne un entier qui est le descripteur de la socket nouvellement cr e ee par cet appel. Par rapport ` a la connexion future cette primitive ne fait que donner le premier el ement du quintuplet : {protocole, port local, adresse locale, port eloign e, adresse eloign ee } Si la primitive renvoie -1, la variable globale errno donne lindice du meseque standard sage derreur idoine dans la table sys errlist, que la biblioth` 7 sait parfaitement exploiter . Remarque importante : Comme pour les entr ees/sorties sur chiers, un appel syst` eme fork duplique la table des descripteurs de chiers ouverts du processus p` ere dans le processus ls. Ainsi les descripteurs de sockets sont egalement transmis. Le bon usage du descripteur de socket partag e entre les deux processus incombe donc ` a la responsabilit e du programmeur. Enn, quand un processus a ni dutiliser une socket il appelle la primitive close avec en argument le descripteur de la socket :
close(descripteur de socket) ;

Si un processus ayant ouvert des sockets vient ` a sinterrompre pour une raison quelconque, en interne la socket est ferm ee et si plus aucun processus na de descripteur ouvert sur elle, le noyau la supprime.

cf man errno ou la page de manuel de perror(3)

256

Sockets de Berkeley

3.2

Sp ecication dune adresse

Il faut remarquer quune socket est cr e ee sans ladresse de l emetteur comprendre le couple (num ero de port, adresse IP) - ni celle du destinataire. Il y a deux couples ` a pr eciser, celui cot e client et lautre cot e serveur. La primitive bind eectue cette op eration pour la socket de lh ote local. 3.2.1 Sp ecication dun num ero de port

Lusage dun num ero de port est obligatoire. Par contre le choix de sa valeur est largement conditionn e par le r ole que remplit la socket : client versus serveur. Sil sagit dun serveur, lusage dune valeur de port bien connue est essentiel pour etre accessible syst ematiquement par les clients (par exemple le port 25 pour un serveur SMTP ou 80 pour un serveur HTTP). ` linverse, le codage de la partie cliente dune application r A eseau ne n ecessite pas une telle pr ecaution (sauf contrainte particuli` ere d ue au protocole de lapplication elle-m eme) parceque le num ero de port associ e ` a la socket cliente est communiqu e au serveur via len-t ete de la couche de transport choisie, d` es la prise de contact par le r eseau. Le serveur utilise alors la valeur lue dans len-t ete pour r epondre ` a la requ ete du client, quel que soit le choix de sa valeur initiale. L etablissement de cette valeur par le client peut donc etre le r esultat dun automate, eventuellement d ebrayable. 3.2.2 Sp ecication dune adresse IP

Pour des raisons evidentes de communication, il est n ecessaire de pr eciser ladresse IP du serveur avec lequel on souhaite etablir un trac r eseau. Par contre, concernant le choix sa propre adresse IP, cest ` a dire celle qui va servir dadresse pour le retour des datagrammes, un comportement par d efaut peut etre choisi lors de la construction de la socket, qui consiste ` a laisser au noyau du syst` eme le soin den choisir la valeur la plus appropri ee. Pour une machine unix standard mise en r eseau, cest le cas par exemple dune station de travail, celle-ci poss` ede au moins deux adresses IP : une sur le r eseau local et une autre sur linterface de loopback (cf page 75). La socket est alors associ ee aux deux adresses IP, voire plus si la machine est du type multi-homed (page 44). On peut egalement choisir pour sa socket un comportement plus s electif, consistant ` a n ecouter que sur une seule des adresses IP de la station. 3.2.3 La primitive bind

La primitive bind eectue ce travail dassocier une socket ` a un couple (adresse IP, num ero de port) associ es dans une structure de type en eraliste, ce qui sockaddr in, pour IPv4. Mais la primitive bind est g

Sp ecication dune adresse explique que son prototype fasse etat dune structure g en erique nomm ee sockaddr, plut ot qu` a une structure d edi ee dun protocole particulier (IPv4 ici).
int bind(int sockfd, struct sockaddr *myaddr, socklen t addrlen) ;

257

socket myaddr addrlen

: : :

Usage du descripteur renvoy e par socket. La structure qui sp ecie ladresse locale que lon veut associer ` a la socket pr ealablement ouverte. Taille en octets de la structure qui contient ladresse.

sockaddr est constitu ee (dans sa forme POSIX) de deux octets qui rappellent la famille de protocole, suivis de 14 octets qui d enissent ladresse en elle-m eme. 3.2.4 Les structures dadresses

Avec la pr esence de plus en plus eective dIPv6, les impl ementations les plus r ecentes tiennent compte des recommandations de la RFC 34938 , ajoutent un champ sa len dune longueur de 8 bits et font passer de 16 ` a8 bits la taille du champ sa family pour ne pas augmenter la taille globale de la structure.
struct sockaddr uint8_t sa_family_t char } ; { /* La structure */ sa_len ; /* generique */ sa_family ; sa_data[14] ;

sa len indique taille de la structure en octets, il est pr esent au m eme emplacement dans toutes les variantes de cette structure et contient 16 (octets) pour une structure de type sockaddr in, ou 28 octets pour une structure de type sockaddr in6 (IPv6). Pour la famille PF INET (IPv4) cette structure se nomme sockaddr in, et est d enie de la mani` ere suivante :
struct in_addr { unsigned long } ; s_addr ; /* 32 bits Internet */

struct sockaddr_in { uint8_t sin_len ; sa_family_t sin_family ; in_port_t sin_port ; struct in_addr sin_addr ; char sin_zero[8] ; } ;
8

/* /* /* /* /*

Taille de la structure == 16 octets */ PF_INET (IPv4) */ Numero de port sur 16 bits / NBO */ Adresse IP sur 32 bits / NBO */ Inutilises */

Basic Socket Interface Extensions for IPv6

258

Sockets de Berkeley

struct sockaddr sa_len sa_family

struct sockaddr_in sin_len sin_family sin_port sin_addr

struct sockaddr_in6 sin6_len sin6_family sin6_port ... Structure dadresse pour IPv6 ... 28 octets

16 octets sa_data

sin_zero

La structure gnrique

socket IPv4

Socket IPv6

gure XII.03 Structures dadresses La primitive bind ne permet pas toutes les associations de num eros de port, par exemple si un num ero de port est d ej` a utilis e par un autre processus, ou encore si ladresse internet est invalide. Trois utilisations typiques de la primitive : 1. En r` egle g en eral les serveurs fonctionnent avec des num eros de port bien connus (cf /etc/services). Dans ce cas bind indique au syst` eme cest mon adresse, tout message re cu ` a cette adresse doit m etre renvoy e . En mode connect e ou non, les serveurs ont besoin de pr eciser cette information avant de pouvoir accepter les requ etes des clients. 2. Un client peut pr eciser sa propre adresse, en mode connect e ou non. 3. Un client en mode non connect e a besoin que le syst` eme lui assigne une adresse particuli` ere, ce qui autorise lusage des primitives read et write traditionnellement d edi ees au mode connect e. 3.2.5 Valeur retourn ee par bind

Bind retourne 0 si tout va bien, -1 si une erreur est intervenue. Dans ce cas la variable globale errno est positionn ee ` a la bonne valeur. Cet appel syst` eme compl` ete ladresse locale et le num ero de port du quintuplet qui qualie une connexion. Avec bind+socket on a la moiti e dune connexion, ` a savoir un protocole, un num ero de port et une adresse IP : {protocole, port local, adresse locale, port eloign e, adresse eloign ee}

Connexion ` a une adresse distante

259

3.3

Connexion ` a une adresse distante

Prendre linitiative de l etablissement dune connexion est typique de la d emarche dun client r eseau.. La primitive connect permet d etablir la connexion avec une socket distante, suppos ee ` a l ecoute sur un port connu ` a lavance de la partie cliente. Son usage principal est dutiliser une socket en mode connect e . Lusage dune socket en mode datagramme est possible mais a un autre sens (voir plus loin) et est moins utilis e. La primitive connect a le prototype suivant :
int connect(int sockfd,const struct sockaddr *servaddr,socklen t addrlen) ;

sockfd servaddr addrlen 3.3.1

Le descripteur de socket renvoy e par la primitive socket. : La structure qui d enit ladresse du destinataire, du m eme type que pour bind. : La longueur de ladresse, en octets.

Mode connect e

Pour les protocoles orient es connexion, cet appel syst` eme rend la main au code utilisateur une fois etabli le circuit virtuel entre les deux piles TCP/IP. Durant cette phase, des paquets sont echang es comme nous avons pu d ej` a lexaminer page 89 dans le cas de TCP. Tant que cette connexion nest pas compl` etement etablie au niveau de la couche de transport, la primitive connect reste en mode noyau, et est donc bloquante vis ` a vis du code de lapplication. Dans le cas g en eral, les clients nont pas besoin de faire appel ` a bind avant dinvoquer connect, la d enition de la socket locale est compl et ee automatiquement : le port est attribu e automatiquement selon une d emarche d ecrite page 276, et ladresse IP est lune de celles de linterface quemprunte le datagramme pour son routage initial9 . 3.3.2 Mode datagramme

Dans le cas dun client en mode datagramme, un appel ` a connect nest pas faux mais il ne sert ` a rien au niveau protocolaire, il redonne aussit ot la main au code utilisateur. Le seul int er et que lon peut y trouver est que ladresse du destinataire est alors x ee et que lon peut alors utiliser les primitives read, write, recv et send, traditionnellement r eserv ees au mode connect e.
Est-il n ecessaire de rappeler quun interface peut comporter plusieurs adresses IP et quil peut y avoir plusieurs interfaces reseau sur un m eme h ote. . . ?
9

260 3.3.3 Valeur retourn ee par connect :

Sockets de Berkeley

En cas derreur elle renvoie la valeur -1 et positionne la variable globale errno ` a la valeur idoine, par exemple ` a ETIMEOUT, sil ny a pas eu de r eponse ` a l emission des paquets de synchronisation (cf page 94). Bien dautres erreurs li ees ` a des probl` emes du r eseau sont ` a consulter dans la section ERRORS de la page de manuel. Un code 0 indique que la connexion est etablie sans probl` eme particulier. Tous les el ements du quintuplet sont en place : {protocole, port local, adresse locale, port eloign e, adresse eloign ee}

3.4

Envoyer des donn ees

Une fois quun programme dapplication a cr e e une socket, il peut lutiliser pour transmettre des donn ees. Il y a cinq primitives possibles pour ce faire : send, write, writev, sendto, sendmsg 3.4.1 Envoi en mode connect e

Send, write et writev fonctionnent uniquement en mode connect e, parce-quelles norent pas la possibilit e de pr eciser ladresse du destinataire. Les di erences entre ces trois primitives sont mineures.
ssize t write(int descripteur, const void *buffer, size t longueur) ;

Quand on utilise write, le descripteur d esigne lentier renvoy e par la primitive socket. Le buffer contient les octets ` a transmettre, et longueur leur cardinal. Tous les octets ne sont pas forc ement transmis dun seul coup, et ce nest pas une condition derreur. En cons equence il est absolument n ecessaire de tenir compte de la valeur de retour de cette primitive, n egative ou non. La primitive writev est sensiblement la m eme que write simplement elle permet denvoyer un tableau de structures du type iovec plutot quun simple buer, largument vectorlen sp ecie le nombre dentr ees dans iovector :
ssize t writev(int descriptor, const struct iovec *iovector, int vectorlen) ;

La primitive send ` a la forme suivante :

int send(int s, const void *msg, size t len, int flags) ;

s D esigne lentier renvoy e par la primitive socket.

Envoyer des donn ees msg Donne ladresse du d ebut de la suite doctets ` a transmettre. len Sp ecie le nombre doctets ` a transmettre. flags Ce drapeau permet de param` etrer la transmission du data-gramme, notamment si le buer d ecriture est plein ou si lon d esire, par exemple et avec TCP, faire un envoi en urgence (out-of-band) : 0 MSG OOB MSG PEEK : Non op erant, cest le cas le plus courant. : Pour envoyer ou recevoir des messages out-of-band. : Permet daller voir quel message on a re cu sans le lire, cest ` a dire sans quil soit eectivement retir e des buers internes (ne sapplique qu` a recv (page 262).

261

3.4.2

Envoi en mode datagramme

Les deux autres primitives, sendto et sendmsg donnent la possibilit e denvoyer un message via une socket en mode non connect e. Toutes deux r eclament que lon sp ecie le destinataire ` a chaque appel.
ssize t sendto(int s,const void *msg,size t len,int flags, const struct sockaddr *to, socklen t tolen) ;

Les quatre premiers arguments sont exactement les m emes que pour send, les deux derniers permettent de sp ecier une adresse et sa longueur avec une structure du type sockaddr, comme vu pr ec edemment avec bind. Le programmeur soucieux davoir un code plus lisible pourra utiliser la deuxi` eme primitive :
ssize t sendmsg(int sockfd, const struct msghdr *messagestruct,int flags) ;

O` u messagestruct d esigne une structure contenant le message ` a envoyer sa longueur, ladresse du destinataire et sa longueur. Cette primitive est tr` es commode ` a employer avec son pendant recvmsg car elle travaille avec la m eme structure.

262

Sockets de Berkeley

3.5

Recevoir des donn ees

Sym etriquement aux cinq primitives denvoi, il existe cinq primitives de r eception : read, readv, recv, recvfrom, recvmsg. 3.5.1 Reception en mode connect e

La forme conventionnelle read dUnix nest possible quavec des sockets en mode connect e car son retour dans le code utilisateur ne saccompagne daucune pr ecision quant ` a ladresse de l emetteur. Sa forme dutilisation est :
ssize t read(int descripteur, void *buffer,size t longueur) ;

Bien sur, si cette primitive est utilis ee avec les sockets BSD, le descripteur est lentier renvoy e par un appel pr ec edent ` a la primitive socket. buffer et longueur sp ecie respectivement le buer de lecture et la longueur de ce que lon accepte de lire. Chaque lecture ne renvoie pas forc ement le nombre doctets demand es, mais peut etre un nombre inf erieur. Mais le programmeur peut aussi employer le readv, avec la forme :
ssize t readv(int descripteur, const struct iovec *iov, int vectorlen) ;

Avec les m eme caract eristiques que pour le readv. En addition aux deux primitives conventionnelles, il y a trois primitives nouvelles pour lire des messages sur le r eseau :
ssize t recv(int s, void *buf, size t len, int flags) ;

s buf len flags 3.5.2

: : : :

Lentier qui d esigne la socket. Une adresse o` u lon peut ecrire, en m emoire. La longueur du buer. Permet au lecteur deectuer un contr ole sur les paquets lus.

Recevoir en mode datagramme

ssize t recvfrom(int s, void *buf,size t len, int flags,struct sockaddr *from, socklen t *fromlen) ;

Les deux arguments additionnels par rapport ` a recv sont des pointeurs vers une structure de type sockaddr et sa longueur. Le premier contient ladresse de l emetteur. Notons que la primitive sendto fournit une adresse dans le m eme format, ce qui facilite les r eponses. La derni` ere primitive recvmsg est faite pour fonctionner avec son homologue sendmsg :
ssize t recvmsg(int sockfd, struct msghdr *messagestruct,int flags) ;

La structure messagestruct est exactement la m eme que pour sendmsg ainsi ces deux primitives sont faites pour fonctionner de paire.

Sp ecier une le dattente

263

3.6

Sp ecier une le dattente

Imaginons un serveur en train de r epondre ` a un client, si une requ ete arrive dun autre client, le serveur etant occup e, la requ ete nest pas prise en compte, et le syst` eme refuse la connexion. La primitive listen est l` a pour permettre la mise en le dattente des demandes de connexions. Elle est g en eralement utilis ee apr` es les appels de socket et de bind et imm ediatement avant le accept.
int listen(int sockfd, int backlog) ;

sockfd backlog

: :

lentier qui d ecrit la socket. Le nombre de connexions possibles en attente (quelques dizaines). La valeur maximale est fonction du param` etrage du noyau. Sous FreeBSD la valeur maximale par d efaut est de 128 (sans param` etrage sp ecique du noyau), alors que sous Solaris 10, There is currently no backlog limit . Le nombre de fois o` u le noyau refuse une connexion est comptabilis e et accessible au niveau de la ligne de commande via le r esultat de lex ecution de la commande netstat -s -p tcp (chercher listen queue overow ). Ce param` etre est important ` a suivre dans le cas dun serveur tr` es sollicit e.

3.7

Accepter une connexion

Accepter une connexion est typique de la d emarche dun serveur sur le r eseau. nous lavons examin e, un serveur utilise les primitives socket, bind et listen pour se pr eparer ` a recevoir les connexions. Il manque cependant ` a ce trio le moyen de dire au protocole jaccepte d esormais les connexions entrantes . La primitive accept est le cha non manquant ! Quand le serveur invoque cette primitive, le noyau est pr evenu que le processus est en attente dun ev enement r eseau le concernant. Le retour dans le code de lapplication ne fait que sous deux conditions, r eception dune demande de connexion ou r eception dun signal par le processus.
int accept(int sockfd, struct sockaddr *addr, socklen t *addrlen) ;

Qui sutilise comme suit :

int newsock ; newsock = accept(sockfd, addr, addrlen) ;

sockfd descripteur de la socket, renvoy e par la primitive du m eme nom.

264

Sockets de Berkeley addr Un pointeur sur une structure du type sockaddr. addlen Un pointeur sur un entier. Quand une connexion arrive, les couches sous-jacentes du protocole de transport remplissent la structure addr avec ladresse du client qui fait la demande de connexion. Addrlen contient alors la longueur de cette adresse. Cette valeur peut etre modi ee par le noyau lorsque la primitive est utilis ee avec des sockets dautres type pour lesquelles la taille de la structure dadresse est variable (sockaddr un pour les sockets locales par exemple), ce qui justie un pointeur l` a o` u nous ne pourrions attendre quun simple passage dargument par valeur. Puis le syst` eme cr ee une nouvelle socket par clonage de celle transmise et pour laquelle il renvoie un descripteur, r ecup er e ici dans newsock. Par cet artice, la socket originale reste disponible pour d eventuelles autres connexions (elle est clon ee avant que le quintuplet soit complet). En conclusion, lorsquune demande de connexion arrive, lappel ` a la primitive accept redonne la main au code utilisateur.

3.8

Terminer une connexion

Dans le cas du mode connect e on termine une connexion avec la primitive close ou shutdown.
int close(descripteur) ;

La primitive bien connue sous Unix peut etre aussi employ ee avec un descripteur de socket. Si cette derni` ere est en mode connect e, le syst` eme assure que tous les octets en attente de transmission seront eectivement transmis dans de bonnes conditions. Normalement cet appel retourne imm ediatement, cependant le kernel peut attendre le temps de la transmission des derniers octets (transparent). Le moyen le plus classique de terminer une connexion est de passer par la primitive close, mais la primitive shutdown permet un plus grand contr ole sur les connexions en full-duplex .
int shutdown(int sockfd, int how) ;

Sockfd est le descripteur ` a fermer, how permet de fermer partiellement le descripteur suivant les valeurs quil prend : 0 Aucune donn ee ne peut plus etre re cue par la socket. 1 Aucune donn ee ne peut plus etre emise. 2 Combinaison de 0 et de 1 ( equivalent de close). Enn, pour une socket en mode connect e, si un processus est interrompu de mani` ere inopin ee (r eception dun signal de n par exemple), un reset (voir page 92) est envoy e` a lh ote distant ce qui provoque la n brutale de la connexion. Les octets eventuellement en attente sont perdus.

4 Sch ema g en eral dune session clientserveur

265

Sch ema serveur

g en eral

dune

session

client

Il est temps de donner un aper cu de la structure dun serveur et dun client, mettant en uvre les APIs vus dans ce chapitre, et de rapprocher les ev enements r eseaux de ceux observables sur le syst` eme et dans le processus qui sex ecute. Relation clientserveur en mode connect e:
Serveur
fd=socket() bind(fd) listen(fd) fd=socket()

Client

Etats de la socket :

Etats de la socket :

LISTEN SYN_RCVD ESTABLISHED

fd2=accept(fd) Etablissement de la connexion connect(fd) write(fd) read(fd2) Echanges applicatifs write(fd2) read(fd)

SYN_SENT ESTABLISHED

FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT

Fermeture de la close(fd2) connexion close(fd)

CLOSE_WAIT LAST_ACK CLOSED

gure XII.04 Relation clientserveur en mode connect e Il faut etablir une comparaison entre cette gure et les gures VI.03 page 94 et VI.04 page 95. Les sockets cot e client ou cot e serveur, si elles participent ` a l etablissement dun canal de communication sym etrique en fonctionnement, ne passent pas par les m emes etats, de leur cr eation jusquau recyclage des octets qui les composent. La RFC 793 pr ecise 11 etats pour une socket et la gure ci-dessus les met en situation de mani` ere simpli ee. Ces etats peuvent etre visualis es avec la commande netstat -f inet [-a], dans la colonne state de la sortie. LISTEN La socket du serveur est en attente passive dune demande de connexion (ouverture passive). SYN-SENT Cest l etat de la socket cliente qui a envoy e le premier paquet de demande dune connexion avec un ag SYN mais non encore acquitt e (ouverture active). SYN-RCVD La socket du serveur ` a re cu un paquet de demande de connexion, lacquitte et envoi sa propre demande de connexion. Elle attend lacquittement de sa demande.

266

Sockets de Berkeley ESTABLISHED Les demandes de connexions sont acquitt ees aux deux extr emit es. La connexion est etablie. La totalit e du trac TCP applicatif seectue dans cet etat. Sa dur ee est ind enie, la cl oture est ` a linitiative des applications. FIN-WAIT-1 Celui qui est ` a linitiative de lenvoi du premier paquet de demande de n est dans cet etat (fermeture active). FIN-WAIT-2 On a re cu lacquittement ` a la demande de n de connexion. TIME-WAIT La socket etait en FIN-WAIT-2 et a re cu la demande de n de la socket distante. On doit attendre le temps susant pour etre certain que la socket distante a bien re cu lacquittement (re- emission sinon). Cet etat peut donc etre long dans le temps, 2M SL pr ecise la RFC 793. Cette constante peut aller de quelques dizaines de secondes ` a une ou deux minutes selon les impl ementations. CLOSE-WAIT La socket etait en ESTABLISHED et a re cu une demande de n. Cet etat perdure jusqu` a ce que la socket envoie ` a son tour une demande de n (fermeture passive). CLOSING Si la r eponse ` a une demande de n saccompagne imm ediatement de la demande de n de la socket locale, cet etat remplace FIN-WAIT-1 et FIN-WAIT-2. LAST-ACK La derni` ere demande de n est en attente du dernier acquittement. CLOSED Etat de n. Les octets de la socket vont etre recycl es. L etat TIME-WAIT est support e par celui qui cl ot la connexion. Les architectures de serveurs pr ef` erent une cl oture ` a linitiative du serveur, ce qui se comprend du point de vue de lecacit e (rester ma tre de la dur ee de la communication), mais le fonctionnement interne du protocole TCP implique ce temps dattente. Sur un serveur tr` es charg e les sockets dans cet etat peuvent etre en tr` es grand nombre (des dizaines de milliers. . .) bloquant ainsi les nouvelles connexions entrantes. Relation clientserveur en mode non connect e:
Serveur
fd=socket() fd=socket() bind(fd) bind(fd) sendto(fd) recvfrom(fd) changes applicatifs sendto(fd) recvfrom(fd)

Client

close(fd)

close(fd)

gure XII.05 Relation clientserveur en mode non connect e

5 Exemples de code client

267

Exemples de code client

Lobjectif de ces deux exemples est de montrer le codage en C et le fonctionnement dun client du serveur de date (RFC 867, daytime protocol ) pr esent sur toute machine unix10 . Ce serveur fonctionne en mode connect e ou non, sur le port 13 qui lui est r eserv e (/etc/services). Ici le serveur est une machine portant ladresse IP 192.168.52.232. La connaissance de ladresse IP du client nest absolument pas utile pour la compr ehension de lexemple. En mode TCP le simple fait de se connecter provoque l emission de la cha ne ascii contenant la date vers le client et sa d econnexion. En mode UDP il sut denvoyer un datagramme quelconque (1 caract` ere) au serveur puis dattendre sa r eponse.

5.1

Client TCP DTCPcli

Exemple dusage :
$ ./DTCPcli 192.168.52.232 Date(192.168.52.232) = Wed Dec 10 20:59:46 2003

Une capture des trames r eseau echang ees lors de lex ecution de cette commande se trouve page 270. ligne 29 D eclaration de la structure saddr du type sockaddr in, ` a utiliser avec IPv4. Attention, il sagit bien dune structure et non dun pointeur de structure. ligne 35 La variable sfd, re coit la valeur du descripteur de socket. Celle-ci est d edi ee au protocole TCP. ligne 39 Le champ sin family de la structure saddr indique que ce qui suit (dans la structure) concerne IPv4. ligne 40 Le champ sin port est aect e` a la valeur du num ero de port sur lequel ecoute le serveur. Il faut remarquer lusage de la fonction htons (en fait une macro du pr e-processeur cpp) qui sassure que ce num ero de port respecte bien le NBO ( Network Byte Order ), car cette valeur est directement recopi ee dans le champ PORT DESTINATION du protocole de transport employ e (voir page 84 pour UDP et page 91 pour TCP). Nous en dirons plus sur htons au chapitre suivant. Si le processeur courant est du type little endian (architecture Intel par exemple) les octets sont invers es (le NBO est du type big endian ). Vous croyez ecrire 13 alors quen r ealit e pour le r eseau vous avez ecrit 3328 (0x0D00) ce qui bien evidement ne conduit pas au m eme r esultat, sauf si un serveur de date ecoute egalement sur le port 3328, non conventionnel donc tr` es peu probable ` a priori.
10

Son activation est eventuellement ` a faire ` a partir du serveur de serveur inetd, page 320

268

Sockets de Berkeley En r esum e, si le programmeur nutilise pas la fonction htons, ce code nest utilisable que sur les machines darchitecture big endian .
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

/* $Id: DTCPcli.c 92 20090212 17:39:44Z fla $ * * Client TCP pour se connecter au serveur de date (port 13 RFC 867). * La syntaxe dutilisation est : DTCPcli <adresse ip sous forme dcimale> * */ #include #include #include #include #include #include #include #include #include #include <stdio.h> <stdlib.h> <string.h> <unistd.h> <sysexits.h> <sys/types.h> <sys/socket.h> <sys/param.h> <netinet/in.h> <arpa/inet.h> "Usage:%s adresse IP du serveur\n" 1024 13

#define USAGE #define MAXMSG #define NPORT

int main(int argc, char *argv[]) { int n, sfd ; char buf[MAXMSG] ; struct sockaddr_in saddr ; if (argc != 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if ((sfd = socket(PF_INET,SOCK_STREAM,IPPROTO_TCP)) < 0) { perror("socket") ; exit(EX_OSERR) ; } saddr.sin_family = AF_INET ; saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! */ if(inet_pton(AF_INET,argv[1],&saddr.sin_addr) != 1) { (void)fprintf(stderr,"Address %s is not parseable !\n",argv[1] ) ; exit(EX_DATAERR) ; } if (connect(sfd,(struct sockaddr *)&saddr,sizeof saddr) < 0) { perror("connect") ; exit(EX_OSERR) ; } if ((n = read(sfd, buf,MAXMSG1)) < 0) { perror("read") ; exit(EX_OSERR) ; } buf[n] = \0 ; (void)printf("Date(%s) = %s\n",argv[1],buf) ; exit(EX_OK) ; /* close(sfd) implicite */ }

Source du client DTCPcli.c ligne 41 Le champ s addr de la structure sin addr se voit aect e de ladresse IP. Cest donc l ecriture de quatre octets (IPv4), pouvant com-

5 Exemples de code client porter un caract` ere ascii 0, donc interpr etable comme le caract` ere de n de cha ne du langage C. Cest pourquoi ` a cet endroit on ne peut pas employer les habituelles fonctions de la biblioth` eque standard (celles qui commencent par str). Ici le probl` eme se complique un peu dans la mesure o` u lon dispose au d epart dune adresse IP sous sa forme d ecimale point ee. La gestion derreur prot` ege le code des erreurs de syntaxe ` a la saisie. La fonction inet pton g` ere parfaitement ce cas de gure. Nous en dirons plus ` a son sujet au chapitre suivant. ligne 45 Appel ` a la primitive connect pour etablir la connexion avec le serveur distant. Quand celle-ci retourne dans le code du programme, soit la connexion a echou e et il faut traiter lerreur, soit la connexion est etablie. L echange pr eliminaire des trois paquets sest eectu e dans de bonnes conditions (page 94). Du point de vue TCP, les cinq el ements du quintuplet qui caract erisent la connexion sont d enis (page 90). Sur la capture des paquets de la page 270 nous sommes arriv es ` a la ligne 6, cest ` a dire lenvoi de lacquittement par le client du paquet de synchronisation envoy e par le serveur (ligne 3 et 4). Il faut noter que bien que nous ayons transmis la structure saddr par adresse (caract` ere &) et non par valeur, la primitive connect ne modie pas son contenu pour autant. Notons egalement lusage du cast du C pour forcer le type du pointeur (le prototype de la primitive exige ` a cet endroit un pointeur de type sockaddr). ligne 49 Appel ` a la primitive read pour lire le r esultat en provenance du serveur, ` a laide du descripteur sfd. Sur la capture d ecran on voit ligne 8 (et 9) lenvoi de la date en provenance du serveur, dune longueur de 26 caract` eres. Ce nombre de caract` eres eectivement lus est aect e` a la variable n. Ce nombre ne peut exc eder le r esultat de l evaluation de M AXM SG 1, qui correspond ` a la taille du buer buf moins 1 caract` ere pr evu pour ajouter le caract` ere 0 de n de cha ne. En eet, celui-ci fait partie de la convention de repr esentation des cha nes de caract` eres du langage C. Rien ne dit que le serveur qui r epond ajoute un tel caract` ere ` a la n de sa r eponse. Le contraire est m eme certain puisque la RFC 867 ny fait pas mention. Remarque : le buer buf est largement surdimensionn e compte tenu de la r eponse attendue. La RFC 867 ne pr evoit pas de taille maximum si ce nest implicitement celle de lexpression de la date du syst` eme en anglais, une quarantaine doctets au maximum. ligne 53 Ajout du caract` ere de n de cha ne en utilisant le nombre de caract` eres renvoy es par read.

269

270

Sockets de Berkeley ligne 55 La sortie du programme induit une cl oture de la socket cot e client. Cot e serveur elle est d ej` a ferm ee (s equence write + close) comme on peut le voir ligne 8 (ag FP, page 92) ci-apr` es dans la capture du trac entre le client et le serveur. Remarque : rien nest explicitement pr evu dans le code pour etablir la socket cot e client, ` a savoir lassociation dun num ero de port et dune adresse IP. En fait cest la primitive connect qui sen charge. Ladresse IP est celle de la machine. Le num ero de port est choisi dans la zone dattribution automatique comme nous lavons examin e page 85. Il existe bien entendu une possibilit e pour le programme davoir connaissance de cette information : la primitive getsockname.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

23:03:29.465183 client.2769 > serveur.daytime: S 2381636173:2381636173(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 299093825 0> (DF) 23:03:29.465361 serveur.daytime > client.2769: S 3179731077:3179731077(0) ack 2381636174 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 4133222 299093825> (DF) 23:03:29.465397 client.2769 > serveur.daytime: . ack 1 win 57920 <nop,nop,timestamp 299093826 4133222> (DF) 23:03:29.466853 serveur.daytime > client.2769: FP 1:27(26) ack 1 win 57920 <nop,nop,timestamp 4133223 299093826> (DF) 23:03:29.466871 client.2769 > serveur.daytime: . ack 28 win 57894 <nop,nop,timestamp 299093826 4133223> (DF) 23:03:29.467146 client.2769 > serveur.daytime: F 1:1(0) ack 28 win 57920 <nop,nop,timestamp 299093826 4133223> (DF) 23:03:29.467296 serveur.daytime > client.2769: . ack 2 win 57920 <nop,nop,timestamp 4133223 299093826> (DF)

Trac daytime TCP, captur e avec tcpdump Un autre exemple dinterrogation, mais avec un autre h ote du m eme LAN mais sur lequel le service daytime nest pas en fonctionnement :
$ ./DTCPcli 192.168.52.232 connect: Connection refused

1 2 3 4

16:13:21.612274 IP client.57694 > serveur.daytime: S 2248945646:2248945646(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop, timestamp 360942290 0> 16:13:21.612648 IP serveur.daytime > client.57694: R 0:0(0) ack 2248945647 win 0

Trac daytime TCP (reset), captur e avec tcpdump Lenvoi dun reset (drapeau R) envoy e par le serveur en guise de r eponse est bien visible ligne 4.

5 Exemples de code client

271

5.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

Client UDP DUDPcli

/* $Id: DUDPcli.c 92 20090212 17:39:44Z fla $ * * Client UDP pour se connecter au serveur de date (port 13 RFC 867). * La syntaxe dutilisation est : DUDPcli <adresse ip sous forme dcimale> * */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sysexits.h> #include #include #include #include #include #define #define #define <sys/types.h> <sys/socket.h> <sys/param.h> <netinet/in.h> <arpa/inet.h> USAGE "Usage:%s adresse IP du serveur\n" MAXMSG 1024 NPORT 13

int main(int argc, char *argv[]) { int n, sfd ; char buf[MAXMSG] ; struct sockaddr_in saddr ; if (argc != 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if ((sfd = socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP)) < 0) { perror("socket") ; exit(EX_OSERR) ; } saddr.sin_family = AF_INET ; saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! */ if (inet_pton(PF_INET,argv[1],&saddr.sin_addr) != 1) { (void)fprintf(stderr,"Address %s is not parseable !\n",argv[1] ) ; exit(EX_DATAERR) ; } buf[0] = \0 ; if (sendto(sfd,buf,1,0,(struct sockaddr *)&saddr, sizeof saddr) != 1) { perror("sendto") ; exit(EX_OSERR) ; } if ((n=recv(sfd,buf,MAXMSG1,0)) < 0) { perror("recv") ; exit(EX_OSERR) ; } buf[n] = \0 ; (void)printf("Date(%s) = %s\n",argv[1],buf) ; exit(EX_OK) ; /* close(sfd) implicite */ }

Source du client DUDPcli.c Exemple dusage :

$ ./DUDPcli 192.168.52.232 Date(192.168.52.232) = Wed Dec 10 20:56:58 2003

272

Sockets de Berkeley ligne 34 Ouvertude dune socket UDP, donc en mode non connect e. ligne 45 Envoit dun caract` ere (NULL) au serveur, sans quoi il na aucun moyen de conna tre notre existence. ligne 38, 39 et 40 Le remplissage de la structure saddr est identique ` a celui de la version TCP. ligne 49 R eception de caract` eres en provenance du r eseau. Il faut remarquer que rien nassure que les octets lus sont bien en provenance du serveur de date interrog e. Nous aurions pu utiliser la primitive recvfrom dont un des arguments est une structure dadresse contenant justement ladresse de la socket qui envoie le datagramme (ici la r eponse du serveur). Le raisonnement sur la taille du buer est identique ` a celui de la version TCP. La capture de trames suivante montre lextr eme simplicit e de l echange en comparaison avec celle de la version utilisant TCP !
1 2 3 4 5

23:23:17.668689 client.4222 > serveur.daytime: udp 1 23:23:17.670175 serveur.daytime > client.4222: udp 26

Trac daytime UDP, captur e avec tcpdump Un autre essai avec la machine 192.168.52.233 qui ne r epond pas plus sur le port 13 en UDP :
1 2 3

16:29:42.090816 IP client.55822 > serveur.daytime: UDP, length: 1 16:29:42.091205 IP serveur > client: icmp 36: serveur udp port daytime unreachable

Trac daytime UDP (icmp), captur e avec tcpdump Et le code client reste bloqu e en lecture, malgr e lenvoi dun code ICMP qui nest pas interpr et e par d efaut par recv. . .Pour eviter une telle situation de blocage, il faudrait congurer la socket en lui ajoutant un d elai au del` a 11 duquel elle retourne dans le code du client avec un code sp ecique derreur .

11

voir la page de manuel de setsockopt assortie du param` etre SO RCVTIMEO

6 Conclusion et Bibliographie

273

Conclusion et Bibliographie
Protocole Adresses locale Adresse eloign ee et N de port. et N de port. bind listen, accept connect bind recvfrom bind sendto

En conclusion on peut etablir le tableau suivant :

Serveur orient e connexion Client orient e connexion Serveur non orient e connexion Client non orient e connexion

socket socket socket socket

RFC 867 Daytime Protocol . J. Postel. May-01-1983. (Format : TXT=2405 bytes) (Also STD0025) (Status : STANDARD) RFC 793 Transmission Control Protocol. J. Postel. September 1981. (Format : TXT=172710 bytes) (Updated by RFC3168) (Also STD0007) (Status : STANDARD) RFC 3493 Basic Socket Interface Extensions for IPv6 . R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format : TXT=82570 bytes) (Obsoletes RFC2553) (Status : INFORMATIONAL) Pour en savoir davantage, outre les pages de man des primitives cit ees dans ce chapitre, on pourra consulter les documents de r ef erence suivants : Stuart Sechrest An Introductory 4.4BSD Interprocess Communication Tutorial Re imprim e dans Programmers Supplementary Documents OReilly & Associates, Inc. 199412 W. Richard Stevens Unix Network Programming Prentice All 1990 W. Richard Stevens Unix Network Programming Second edition Prentice All 1998 W. Richard Stevens Bill Fenner, Andrew M. Rudo Unix Network Programming Third Edition Addison Wesley 2003 Douglas E. Comer David L. Stevens Internetworking with TCP/IP Volume III (BSD Socket version) Prentice All 1993 Stephen A. Rago Unix System V Network Programming AddisonWesley 1993 Et pour aller plus loin dans la compr ehension des m ecanismes internes : W. Richard Stevens TCP/IP Illustrated Volume 2 Prentice All 1995 McKusick Bostic Karels Quaterman The Design and implementation of the 4.4 BSD Operating System AddisonWesley 1996
On peut egalement trouver ce document dans /usr/share/doc/psd/20.ipctut/ des OS dinspiration Berkeley 4.4
12

le

r epertoire

274

Sockets de Berkeley

Chapitre XIII Compl ements sur les sockets Berkeley

1 R eservation des ports

Au chapitre pr ec edent nous avons utilis e la primitive bind pour assigner une adresse ` a une socket, dans ce paragraphe nous pr ecisons comment choisir le num ero de port qui va bien, selon le type dapplication envisag e. Nous avons d ej` a examin e ce point dans les grandes lignes page 85. Il y a deux mani` eres dassigner un N de port ` a une socket : 1. Le processus sp ecie le num ero. Cest typiquement ce que fait un serveur. On suppose bien evidement que les clients sont au courant ou quils disposent dun m ecanisme qui peut les renseigner (cf cours sur les RPC). 2. Le processus laisse le syst` eme lui assigner automatiquement un num ero de port. Cest typiquement ce que fait un client, sauf cas contraire exig e par le protocole dapplication (cf cours sur les remote execution ). En r` egle g en erale le d eveloppeur dapplication ne sattribue pas au hasard un (ou plus) num ero de port. Il doit respecter quelques contraintes comme ne pas utiliser les ports d ej` a attribu es. Ceux-ci gurent dans une RFC particuli` ere. La derni` ere en date est la RFC 1700 [Reynolds & Postel 1994]) au paragraphe WELL KNOWN PORT NUMBERS . Plus simplement, sur toute machine Unix ` a jour, une liste de ces ports se trouve dans le chier /etc/services 1 . Cod e sur deux octets non sign es, le num ero de port permet 65536 possibilit es de 0 ` a 65535. Cette echelle est fragment ee de deux mani` eres, lancienne ou la nouvelle m ethode. Toutes les applications sur tous les syst` emes dexploitation nont pas encore adopt e la nouvelle approche, les deux vont donc cohabiter un certain temps, ne serait-ce qu` a cause dapplications plus anciennes non encore mises ` a jour. . .
http://www.iana.org/assignments/port-numbers pour se tenir au courant des evolutions de cette liste
1

276

Compl ements sur les sockets Berkeley

1.1

R eservation de port Ancienne m ethode

Port N 0 Ce num ero nest pas utilisable pour une application, cest une sorte de jocker qui indique au syst` eme que cest ` a lui de compl eter automatiquement le num ero (voir plus loin de 1024 ` a 5000). Port de 1 ` a 255 Pour utiliser cette zone il faut avoir les droits du root ` a lex ecution (U ID = 0) pour que le bind ne retourne pas une erreur. Les serveurs classiques (domain, ftp, smtp, telnet, ssh, http, snmp...) se situent tous dans cette partie. Ports de 256 ` a 511 Jadis consid er e comme une r eserve des serveurs ociels commencent ` a sy installer, faute de place dans la zone pr ec edente. Il faut egalement avoir un U ID = 0 pour utiliser un num ero de port dans cette zone. Port de 512 ` a 1023 Une fonction rresvport permet lattribution automatique dun num ero de port dans cette zone, pour des applications ayant un U ID = 0. Par exemple, cest dans cette zone quinetd (cf cours sur les serveurs) attribue des ports automatiquement pour les outils en r de Berkeley (rlogin, rcp, rexec, rdist,...). Port de 1024 ` a 5000 Zone dattribution automatique par bind. Lorsque lutilisateur (non root) utilise 0 comme num ero, cest le premier port libre qui est employ e. Si tous les utilisateurs peuvent sattribuer manuellement un num ero dans cette zone, il vaut mieux eviter de le faire, la suivante est pr evue pour cela. 5001 ` a 65535 Zone libre attention cependant car de tr` es nombreux serveurs y ont un port r eserv e, et pas des moindres comme le serveur X11 sur le port 6000 !

1.2

R eservation de port Nouvelle m ethode

Port N 0 Ce num ero nest pas utilisable pour une application, cest une sorte de jocker qui indique au syst` eme que cest ` a lui de compl eter automatiquement le num ero (voir plus loin de 49152 ` a 65535). Port de 1 ` a 1023 Pour utiliser cette zone il faut avoir les droits du root ` a lex ecution pour que le bind ne retourne pas une erreur. Les serveurs classiques (domain, ftp, smtp, telnet, ...) se situent tous dans cette partie. Port de 1024 ` a 49151 est la zone des services enregistr es par lIANA et qui fonctionnent avec des droits ordinaires. Port de 49152 ` a 65535 est la zone dattribution automatique des ports, pour la partie cliente des connexions (si le protocole nimpose pas une valeur particuli` ere) et pour les tests de serveurs locaux.

2 Ordre des octets sur le r eseau

277

Ordre des octets sur le r eseau

15 Un mot de deux octets : 0 87 1 0

Nous reprenons ici un point d ej` a evoqu e page 48 :

Bits de poids fort (MSB) : 15 Bits de poids faible (LSB) : 0 "Big endian" ... A+1 A octet 1 octet 0 HP (hppa), Sun (sparc) Ibm, Apple (ppc) Motorola (68k) "Little endian" ... octet 0 octet 1 Intel(i386) Digital(vax) des adresses mmoire Croissance

gure XIII.01 Ordre des octets sur le r eseau Le probl` eme de lordre des octets sur le r eseau est dautant plus crucial que lon travaille dans un environnement avec des architectures h et erog` enes. La couche R eseau (page 30) ne transforme pas les octets de la couche Internet (page 30) qui elle m eme ne modie pas ceux de la couche de Transport2 (page 29). Pour cette raison, le num ero de port inscrit dans len-t ete TCP (vs UDP) de l emetteur est exploit e tel quel par la couche de transport du r ecepteur et donc il convient de prendre certaines pr ecautions pour sassurer que les couches de m eme niveau se comprennent. Dun point de vue plus g en eral, les r eseaux imposent le poids fort avant le poids faible , cest le Network Byte Order . Les architectures qui travaillent naturellement avec cette repr esentation nont donc th eoriquement pas besoin dutiliser les fonctions qui suivent, de m eme pour les applications qui doivent dialoguer avec dautres ayant la m eme architecture mat erielle. N eanmoins ecrire du code portable consiste ` a utiliser ces macros dans tous les cas3 ! Pour se souvenir de ces fonctions, il faut conna tre la signication des quatre lettres utiles : s l h n
2

short Entier court sur 16 bits, un num ero de port par exemple. long Entier long sur 32 bits, une adresse IP par exemple. host La machine sur laquelle sex ecute le programme. network Le r eseau sur lequel on envoie les donn ees.

Nous nabordons pas ici la question de la transmission de donn ees h et erog` enes au niveau applicatif, elle sera examin ee dans le cours sur les XDR 3 Pour les machines qui respectent naturellement le NBO, comme les stations HP (processeur risc) ou SUN (processeur sparc), IBM (processeur ppc) ces fonctions sont des macros vides contrairement ` a toutes les architectures de type i386

278 Do` u les protoptypes :

#include u long u short u long u short <sys/types.h> htonl (u long) ; htons (u short) ; ntohl (u long) ; ntohs (u short) ;

Compl ements sur les sockets Berkeley

/* /* /* /*

host to host to network network

network network to host to host

---------

long */ short */ long */ short */

Par exemple, pour aecter le num ero de port 13 (service daytime ) au champ sin port dune structure de type sockaddr in :
saddr.sin port = htons(13) ;

Cette ecriture est valable quelle que soit larchitecture sur laquelle elle est compil ee. Sil avait fallu se passer de la macro htons sur une architecture Intel ( little endian ), pour laection du m eme num ero de port, il eut fallu ecrire :
saddr.sin port = 0x0D00 ; /* 0D hexad ecimal == 13 d ecimal */

Op erations sur les octets

Dans le m eme ordre did ee quau paragraphe pr ec edent, les r eseaux interconnectent des architectures h et erog` enes et donc aussi des conventions de r epr esentation des cha nes de caract` eres di erentes. Pour etre plus pr ecis, le caract` ere NULL marqueur de n de cha ne bien connu des programmeurs C, nest pas valide partout, voire m eme est associ e` a une autre signication ! En cons equence, pour toutes les fonctions et primitives qui lisent et ecrivent des octets sur le r eseau, les cha nes de caract` eres sont toujours associ ees au nombre de caract` eres qui les composent. Le corollaire est que les fonctions classiques de manipulation de cha nes en C (strcpy, strcat, ...) ne sont ` a utiliser quavec une extr eme prudence. Pour copier des octets dune zone vers une autre il faut utiliser bcopy, pour comparer deux buers, bcmp, enn pour mettre ` a z ero (remplir doctets NULL) une zone, bzero.
#include <string.h> void bcopy (const void *src, void *dst, size t len) ; int bcmp (const void *b1, const void *b2, size t len) ; void bzero (const void *b, size t len) ;

bcopy Attention, len octets de src sont copi es dans dst et non linverse, comme dans strcpy. bcmp Compare b1 et b2 et renvoie 0 si les len premiers octets sont identiques, sinon une valeur non nulle qui nest pas exploitable vis ` a vis dune quelconque relation dordre (` a la di erence de strcmp qui suppose les caract` eres dans la table ASCII). bzero Met des octets NULL (0) len fois ` a ladresse b. Il exite des outils similaires, issus du syst` eme V : memcpy, memcmp, memset,....

4 Conversion dadresses

279

Conversion dadresses

La plupart du temps, par exemple dans une forme de saisie pour la conguration dun appareil, les adresses IP sont fournies par lutilisateur dans le format d ecimal point e , or la structure dadresse (sockaddr in) a besoin dun entier non sign e sur 32 bits qui respecte le NBO. Une conversion est donc n ecessaire pour passer dune repr esentation ` a une autre.

4.1

Conversion dadresse - IPv4 seul

La fonction inet addr convertit une adresse d ecimale point ee en un entier long non sign e et qui respecte le NBO. La fonction inet ntoa eectue le travail inverse. Ces deux fonctions ne sont valables que pour les adresses 32 bits dIPv4 et sont pr esentes dans la majeure partie des codes r eseaux. Dans le cadre dun nouveau d eveloppement on leur pr ef` erera les fonctions d ecrites apr` es.
#include #include #include in addr t char * <sys/socket.h> <netinet/in.h> <arpa/inet.h> inet addr inet ntoa (char *) ; /* in addr t == unsigned long */ (struct in addr) ;

Remarque : Ces deux fonctions ne sont pas sym etriques, le fait que inet addr ne renvoie pas une structure du type in addr nest pas une inconsistance mais est d u au fait que la structure in addr etait pr evue au d epart pour evoluer. Exemple dutilisation :
struct sockaddr_in saddr ; if ((saddr.sin_addr.s_addr = inet_addr("138.195.52.130")) != INADDR_NONE) printf("Adresse IP = %s\n",inet_ntoa(saddr.sin_addr)) ; else printf("Erreur sur largument de inet_addr !\n" );

Il faut juste noter quen cas derreur la fonction inet addr renvoie la constante INADDR NONE.

4.2

Conversion dadresse - Compatible IPv4 et IPv6

inet ntop inet pton (int af, const void *src, char *dst, size t size) ; (int af, const char *src, void *dst) ;

Avec les m emes chiers den-t ete, les deux nouvelles fonctions de conversion :
const char * int

Le p signie presentation , comprendre lisible par lhumain, alors que le n signie numeric , cest ` a dire compr ehensible par le noyau (entier qui respecte le NBO). Donc ntop convertit le format syst` eme vers lhumain et pton eectue le travail inverse.

280

Compl ements sur les sockets Berkeley Du fait de leur compatibilit e entre les familles de protocoles, ces fonctions sont un peu plus compliqu ees ` a lusage : Il faut pr eciser PF INET ou PF INET6. Exemple dutilisation :
struct sockaddr_in saddr ; if (inet_pton(PF_INET,"138.195.52.130",&saddr.sin_addr) != 1) (void)fprintf(stderr,"Ladrese nest pas exploitable !\n") ; else { char adr[INET_ADDRSTRLEN] ; /* 16 == 4 x 3(digits) + 3 (.) + 1 (NULL) */ printf("Adresse IP = %s\n",inet_ntop(PF_INET,&saddr.sin_addr,adr,sizeof(adr))) ; }

Il faut noter que le code de retour de la fonction inet pton peut prendre les valeurs -1, 0 ou 1. 1 signie que transformation ladresse transcod ee est utilisable. Le code de retour de inet ntop est soit NULL si la conversion a echou e, ou un pointeur sur la cha ne achable. Ici, par construction, on suppose que la conversion sera toujours r eussie.

Conversion h ote adresse IPv4

Se pose r eguli` erement le probl` eme de convertir un nom symbolique en une adresse IP et inversement. Lorigine de cette information d epend de la conguration de la station de travail : cest un serveur de noms (DNS), cest un chier (/etc/hosts) ou tout autre syst` eme de propagation des informations (NIS. . .). Dans tous les cas linformation arrive ` a un programme via une entit e nomm ee le resolver, qui unie les sources dinformations. Les paragraphes 5.1, 5.2 (p. 282), 6.1 (p. 282) et 6.2 (p. 284 pr esentent une approche traditionnelle, seulement valable avec IPv4 alors que le paragraphe 7 (p. 285) expose une d emarche beaucoup plus r ecente et adapt ee egalement ` a IPv6. L ecriture de nouveaux codes ne devraient faire appel qu` a cette nouvelle api.

5.1

Une adresse IP ` a partir dun nom dh ote

#include <netdb.h> struct hostent * gethostbyname (char *name) ; struct hostent { char *h_name ; /* Le nom officiel */ char **h_aliases ; /* Tableau de synonymes */ int h_addrtype ; /* PF_INET pour ARPA */ int h_length ; /* Long. de ladresse */ char **h_addr_list ; /* Adresses possibles */ } ; #define h_addr h_addr_list[0]

a assurer la compatibilit e avec les premi` eres versions la macro h addr sert ` dans lesquelles il ny avait quune seule adresse IP possible par h ote.

Conversion h ote adresse IPv4 Le nom ociel soppose aux noms synonymes. Par exemple, soit une machine ociellement baptis ee pasglop.mon-domain.fr ; si pour r epondre au besoin dune certaine application ladministrateur du r eseau lui donne le surnom www.mon-domain.fr, celui-ci sera consid er e comme un alias vis ` a vis du nom ociel et donc lu dans h aliases. (voir page 185)

281

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

/* * $Id: gethostbyname.c 46 20071203 19:39:16Z fla $ * Exemple dutilisation de la fonction "gethostbyname". */ #include <stdio.h> #include <stdlib.h> #include <sysexits.h> #include <sys/types.h> #include <sys/socket.h> /* AF_INET */ #include <netinet/in.h> /* struct in_addr */ #include <netdb.h> /* gethostbyname */ #include <arpa/inet.h> /* inet_ntoa */ #define DIT_FAMILY(x) (x)==AF_UNSPEC?"AF_UNSPEC":(x)==AF_UNIX?"AF_UNIX":\ (x)==AF_INET?"AF_INET":(x)==AF_INET6?"AF_INET6":"other..." #define USAGE "Usage:%s liste de machines distantes\n" void impnet(struct in_addr **list) { struct in_addr *adr ; while ((adr = *list++)) (void)printf("Adresse Internet : %s\n",inet_ntoa(*adr)) ; } int main(int argc,char *argv[]) { register char *ptr ; register struct hostent *pth ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } while (argc > 0) { ptr = *++argv ; if (!(pth = gethostbyname(ptr))) { (void)fprintf(stderr,"%s : hote inconnu !\n",ptr) ; exit(EX_SOFTWARE) ; } (void)printf ("Nom officiel : %s\n",pth>h_name) ; while ((ptr = *(pth>h_aliases))!=NULL) { (void)printf("\talias : %s\n",ptr) ; pth>h_aliases++ ; } (void)printf("Type dadresse : %s\n",DIT_FAMILY(pth>h_addrtype)) ; if (pth>h_addrtype == PF_INET) impnet((struct in_addr **)pth>h_addr_list) ; else (void)printf("Type dadresse non reconnu !\n") ; } exit(EX_OK) ; }

gethostbyname.c La n du tableau de pointeurs est marqu ee par un pointeur NULL.

282

Compl ements sur les sockets Berkeley La liste des adresses est un tableau de pointeurs, le marqueur de n de liste est egalement un pointeur NULL. Chaque adresse est une zone de h length octets (cf fonction impnet dans lexemple ci-apr` es). Le programme dusage qui suit ache toutes les informations contenues dans cette structure pour les h otes dont le nom est pass e en argument (le code source de cet exemple, gethostbyname.c, est ` a la page suivante). $ gethostbyname gw-sio.sio.ecp.fr srv-sio.sio.ecp.fr Nom officiel : gw-sio.sio.ecp.fr Type dadresse : AF_INET Adresse Internet : 138.195.52.33 Adresse Internet : 138.195.53.1 Adresse Internet : 138.195.10.52 Nom officiel : srv-sio.sio.ecp.fr Type dadresse : AF_INET Adresse Internet : 138.195.52.130 $ gethostbyname anna.sio.ecp.fr anna.sio.ecp.fr : hote inconnu !

5.2

Un nom dh ote ` a partir dune adresse IP

le probl` eme inverse se r esoud avec la fonction gethostbyaddr. La d enition du prototype se trouve au m eme endroit que pr ec edement, la fonction renvoie un pointeur sur une structure du type hostent.
#include <netdb.h> struct hostent * gethostbyaddr (char *addr, int len, int type) ;

addr len type

: Pointe sur une structure du type in addr : Est la longueur de addr : PF INET quand on utilise la pile ARPA

Conversion N de port service

Couramment les ports bien connus sont donn es par leur nom plut ot que par leur valeur num erique, comme par exemple dans les sorties de la commande tcpdump.

6.1

Le num ero ` a partir du nom

Un tel programme a besoin de faire la conversion symbolique num erique, la fonction getservbyname eectue ce travail. Lutilisateur r ecup` ere un pointeur sur une structure du type servent, NULL dans le cas dune impossibilit e. La source dinformations se trouve dans le chier /etc/services.
#include <netdb.h>

Conversion N de port service

struct servent * struct servent char char int char } ; getservbyname (char *name, char *proto) ;

283

{ *s_name ; **s_aliases ; s_port ; *s_proto ;

s name Le nom ociel du service. s aliases Un tableau de pointeurs sur les aliases possibles. Le marqueur de n de tableau est un pointeur ` a NULL. s port Le num ero du port (il respecte le Network Byte Order). s proto Le nom du protocole ` a utiliser pour contacter le service (TCP vs UDP). Voici un programme de mise en application de la fonction, le code source de lexemple, getservbyname.c se trouve ` a la page suivante. $ getservbyname domain Le service domain est reconnu dans /etc/services protocole :tcp - N de port :53 $ getservbyname domain udp Le service domain est reconnu dans /etc/services protocole :udp - N de port :53
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

/* * $Id: getservbyname.c 47 20071203 19:41:04Z fla $ * Exemple dutilisation de la fonction "getservbyname". */ #include <stdio.h> #include <stdlib.h> #include <sysexits.h> #include <sys/types.h> #include <netinet/in.h> /* Pour "ntohs" */ #include <netdb.h> /* Pour "getservbyname" */ #define USAGE "Usage:%s <nom de service> [<nom de protocole>]\n" #define MSG1 "Le service %s est reconnu dans /etc/services\nprotocole :%s N de port :%d\n" #define MSG2 "Le service %s (%s) est introuvable dans /etc/services !\n" int main(int argc,char *argv[]) { struct servent *serv ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if ((serv = getservbyname(argv[1],argv[2]?argv[2]:"tcp"))) (void)printf(MSG1,serv>s_name,serv>s_proto,ntohs(serv>s_port)) ; else (void)printf(MSG2,argv[1],argv[2]?argv[2]:"") ; exit(EX_OK) ; }

getservbyname.c

284

Compl ements sur les sockets Berkeley

6.2

Le nom ` a partir du num ero

Sym etriquement la fonction getservbyport eectue le travail inverse. Elle renvoie aussi un pointeur sur une structure servent, NULL dans le cas dune impossibilit e.
#include <netdb.h> struct servent * getservbyport (int port, char *proto) ;

Exemples dusage : $ getservbyport 53 Le port 53 correspond au service "domain" (protocole tcp). $ getservbyport 53 udp Le port 53 correspond au service "domain" (protocole udp). Exemple de programmation :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

/* * $Id: getservbyport.c 2 20070912 20:00:17Z fla $ * Exemple dutilisation de la fonction "getservbyport". */ #include <stdio.h> #include <stdlib.h> /* Pour "atoi". */ #include <sysexits.h> #include <sys/types.h> #include <netinet/in.h> /* Pour "ntohs" */ #include <netdb.h> /* Pour "getservbyport" */ #define USAGE #define MSG1 #define MSG2 "Usage:%s <numro de port> [<nom de protocole>]\n" "Le port %d correspond au service \"%s\" (protocole %s).\n" "Le port %s (%s) est introuvable dans /etc/services !\n"

int main(int argc,char *argv[]) { struct servent *serv ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if ((serv = getservbyport(atoi(argv[1]),argv[2]?argv[2]:"tcp"))) (void)printf(MSG1,ntohs(serv>s_port),serv>s_name,serv>s_proto) ; else (void)printf(MSG2,argv[1],argv[2]?argv[2]:"") ; exit(EX_OK) ; }

getservbyport.c

7 Getaddrinfo, pour IPv4 et IPv6

285

Getaddrinfo, pour IPv4 et IPv6

Les apis des deux paragraphes qui pr ec` edent (gethostbyname et getservbyname et leur sym etrique) sont des standards de facto et ce depuis le d ebut des ann ees 80. On les trouve sur toutes les variantes dUnix et m eme au del` a, ce qui a particip e` a une grande portabilit e du code ecrit qui les utilise. Larriv ee dIPv6 et de sa probable tr` es longue cohabitation avec IPv4 oblige ` a modier les habitudes de programmation au prot dune nouvelle approche, que ces concepteurs souhaitent aussi stable et largement r epandue que la pr ec edente. L ecriture de tout nouveau code devrait sappuyer sur cette nouvelle API, d enie dans la RFC 3493. La nouvelle fonction getaddrinfo de la libc ne se contente pas seulement de synth etiser gethostbyname et getservbyname en une seule fonction, elle banalise egalement lusage dIPv6. La d emarche est plus concise (une fonction au lieu dune), et la manipulation des adresses IP est rendue plus ais ee en retour, puisque que la structure de donn ees utilis ee par la fonction contient directement une structure dadresse conforme ` a la famille de protocole utilis ee, sockaddr in pour IPv4, directement utilisable par exemple avec les primitives bind, connect,. . .On peut songer par comparaison au champ h addr list de la structure hostent (page 280) qui ne contient que les adresses IP.

7.1

La fonction getaddrinfo

La fonction getaddrinfo combine les fonctionnalit es de gethostbyname et getservbyname pour les protocoles IPv4 et IPv6. Son prototype est donc le reet de sa relative complexit e, par contre son fonctionnement est tr` es logique , il d ecoule de celui des deux fonctions quelle remplace.

7.1.1

Prototype de getaddrinfo

#include <netdb.h> int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res);

Comme il y a beaucoup dinformations ` a transmettre et ` a recevoir, tout (ou presque) seectue via une nouvelle structure de donn ees nomm ee addrinfo. Elle apparait en troisi` eme argument (informations fournies ` a lappel) et quatri` eme (dernier) argument, le r esultat. Si cette fonction ne retourne pas une valeur nulle (0), le code derreur est ` a exploiter ` a laide dune fonction sp ecialis ee, gai strerror qui ajoute une bonne dizaine de messages derreurs suppl ementaires sp ecialis es.

286 7.1.2

Compl ements sur les sockets Berkeley Description des arguments

Les deux premiers arguments, hostname ou servname, sont soit des cha nes de caract` eres, soit un pointeur nul. Il ne peuvent pas etre tous les deux nuls. hostname Les valeurs acceptables sont soit un nom dh ote valide ou une adresse IP exprim ee sous sa forme d ecimale point ee. servname est soit un nom, soit un num ero de service pr esent dans /etc/services. hints La structure est optionnelle (NULL dans ce cas) et permet de piloter nement le comportement de la fonction. Lexplication de son usage passe par un survol de la constitution de sa structure. res Le dernier argument est un pointeur de pointeur sur une structure du m eme type que hints. Cest par ce moyen que la fonction va renvoyer le r esultat construit, en modiant la valeur du pointeur (il nous faut passer ladresse du pointeur puisque sa valeur va changer, do` u le pointeur de pointeur). La fonction alloue la m emoire n ecessaire pour le stockage des donn ees, au programme appelant de la restituer au syst` eme. Il dispose ` a cet eet dune fonction sp ecialis ee : freeaddrinfo. 7.1.3 La structure addrinfo

Voici les membres de la structure addrinfo, d enis dans le chier dent etes netdb.h :
struct addrinfo { int ai_flags; /* int ai_family; /* int ai_socktype; /* int ai_protocol; /* socklen_t ai_addrlen; /* char *ai_canonname; /* struct sockaddr *ai_addr; struct addrinfo *ai_next; }; AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ PF_xxx */ SOCK_xxx */ 0 or IPPROTO_xxx for IPv4 and IPv6 */ length of ai_addr */ canonical name for hostname */ /* binary address */ /* next structure in linked list */

Signalons tout de suite au lecteur le dernier membre de la structure, ai next. Il est du m eme type que celui de la structure elle m eme (structure auto-r ef erente en langage C) ce qui signie quil peut pointer vers une autre structure du m eme type. Il sagit alors dune liste cha n ee4 an de retourner une information multiple, comme peut l etre par exemple la r eponse dune requ ete DNS (type A ou PTR en loccurence), ou la liste des protocoles
Type Abstrait de Donn ees (TAD) tr` es r epandu, cf : http://fr.wikipedia.org/wiki/ Liste_chainee
4

Getaddrinfo, pour IPv4 et IPv6 pr evus pour un service donn e. La n de la liste est marqu ee par un pointeur de valeur nulle (NULL). La structure hints doit etre mise ` a z ero avant chaque usage. Les quatre premiers champs sont utilis es ` a lappel, les autres el ements sont ` a z ero lors de la transmission ` a la fonction. ai family Pour indiquer la famille de protocole utilis ee. Cest le m eme argument que celui quon utilise en premi` ere position avec la primitive socket, cf page 253. Il peut prendre la valeur PF UNSPEC quand le protocole nest pas x e. ai socktype Pour pr eciser le type de socket demand e, cest ` a dire le mode connect e ou datagramme. Cest le deuxi` eme argument de la primite socket. Si la valeur est laiss ee ` a 0 cela signie que nimporte quel protocole est accept e. ai protocol Pour pr eciser le nom du protocole. Cest le troisi` eme argument de socket. M eme remarque que pr ec edement concernant la valeur 0. ai flags Ce drapeau est eventuellement une combinaison de valeurs binaires assembl ees avec lop erateur | du langage C (ou inclusif). AI ADDRCONFIG Seules les adresses (IPv4 ou IPv6) congur ees sur le syst` eme local sont retourn ees. AI ALL Combin e avec AI V4MAPPED donne toutes les adresses IPv4 et IPv6. Sans eet si AI V4MAPPED nest pas pr esent. AI CANONNAME Si linformation est accessible (DNS. . .) le champ ai canonname de la premi` ere structure res pointe sur le nom canonique de hostname. AI NUMERICHOST Pr ecise que hostname doit etre trait e comme une adresse IP d elivr ee sous sa forme num erique, cest ` a dire d ecimale point ee pour IPv4. AI NUMERICSERV Indique que si servname est un port donn e sous forme num erique (la cha ne encode la repr esentation du nombre, comme par exemple 23 ). AI PASSIVE Sert pour lattribution automatique du num ero de port de la structure dadresse, sockaddr in pour IPv4, accessible via le pointeur g en erique sockaddr. AI V4MAPPED Utilis e avec IPv6 (AF INET6). 7.1.4 En r esum e

287

Il y a 6 variables ` a congurer, non toutes utiles selon les utilisations. Il est evident que certaines des nombreuses possibilit es oertes par la combinatoire ne sont pas consistante. Le bon sens doit pr edominer et le test de retour de la fonction etre toujours exploit e. . . !

288 7.1.5

Compl ements sur les sockets Berkeley Exemple dusage ` a la place de gethostbyname

Cet exemple remplace celui de la page 280. Le code nest pas plus simple.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

/* * $Id$ * Exemple dutilisation * et en remplacement de */ #include <stdio.h> #include <stdlib.h> #include <sysexits.h> #include <strings.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <arpa/inet.h>

de la fonction "getaddrinfo" avec IPv4 gethostbyname

/* /* /* /*

AF_INET struct in_addr getaddrinfo inet_ntop */

*/ */ */

#define USAGE "Usage:%s liste de machines distantes\n" #define DIT_FAMILY(x) (x)==AF_UNSPEC?"AF_UNSPEC":(x)==AF_UNIX?"AF_UNIX":\ (x)==AF_INET?"AF_INET":(x)==AF_INET6?"AF_INET6":"other..." int main(int argc,char *argv[]) { char *pt ; int ret ; char buf[INET_ADDRSTRLEN] ; struct addrinfo profil,*lstres,*lstres0 ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } while (argc > 0) { pt = *++argv ; bzero(&profil,sizeof(profil)) ; profil.ai_flags = AI_CANONNAME ; profil.ai_family = AF_INET ; profil.ai_socktype = SOCK_DGRAM ; if ((ret=getaddrinfo(pt,NULL,&profil,&lstres0))) { (void)fprintf(stderr,"%s",gai_strerror(ret)) ; exit(EX_SOFTWARE) ; } (void)printf ("Nom officiel :%s\n",lstres0>ai_canonname) ; (void)printf("Type dadresse :%s\n", DIT_FAMILY(lstres0>ai_socktype)) ; for (lstres=lstres0;lstres!=NULL;lstres=lstres>ai_next) (void)printf("Adresse Internet : %s\n",\ inet_ntop(lstres>ai_socktype, &((struct sockaddr_in*)lstres>ai_addr)>sin_addr, buf,sizeof buf)); } freeaddrinfo(lstres0) ; /* Ne sert rien ici ! */ exit(EX_OK) ; }

getaddrinfo 1.c Ligne 13 Il faut inclure ce chier den-t etes pour avoir le prototype de getaddrinfo. Ligne 26 D eclaration dune structure de type addrinfo et de deux pointeurs du m eme type.

Getaddrinfo, pour IPv4 et IPv6 Ligne 31 On d ecr emente avant de faire le test. Donc quand argc passe par 0 on sort de la boucle. La derni` ere valeur utilis ee de argc est 1. Ligne 32 pt pointe sur argv[1], puis sur argv[2], etc. . .On utilise argc valeurs tr` es exactement. Lignes 33 Mise ` a z ero de tous les bits de la structure Lignes 34, 35 et 36 On veut les noms canoniques, pour IPv4. Lusage de SOCK DGRAM est un artice pour eviter davoir deux r eponses, une avec TCP et lautre avec UDP. Ligne 37 Ne pas oublier de conserver le code de retour pour pouvoir eventuellement lexploiter ` a laide de la fonction gai strerror, comme ligne 38. Ligne 41 et 42 Achage des informations de la premi` ere structure (lstres0). Ligne 43 Boucle for pour explorer tous les el ements de la liste cha n ee. La condition darr et est de rencontrer un pointeur nul. Ligne 44, 45, 46 et 47 Achage de ladresse IP extraite de la structure dadresse, et mise en forme par la fonction inet ntop. Notez lutilisation des el ements de la structure dinformation pour compl eter les arguments dappel de inet ntop. Il faut utiliser un cast (struct sockaddr in *) an dacc eder au champ sin addr de la structure dadresse IPv4. La structure ai addr est g en erique et ny donne pas acc` es. Ligne 50 Restitution de la m emoire allou ee, pour lexemple parceque le noyau va de toute mani` ere recycler toute la m emoire du processus lors de lop eration de n provoqu ee ligne 51.

289

290 7.1.6

Compl ements sur les sockets Berkeley Exemple dusage ` a la place de getservbyname

Cet exemple remplace celui de la page 282

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

/* * $Id$ * Exemple dutilisation * et en remplacement de */ #include <stdio.h> #include <stdlib.h> #include <sysexits.h> #include <strings.h> #include <sys/types.h> #include <sys/socket.h> #include <netdb.h>

de la fonction "getaddrinfo" avec IPv4 getservbyname

/* AF_INET /* getaddrinfo

*/ */

#define USAGE "Usage:%s <nom de service>\n" int main(int argc,char *argv[]) { int ret ; struct addrinfo profil,*lstres,*lstres0 ; struct protoent *myproto ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } bzero(&profil,sizeof(profil)) ; profil.ai_family = AF_INET ; if ((ret=getaddrinfo(NULL,argv[1],&profil,&lstres0))) { (void)fprintf(stderr,"%s\n",gai_strerror(ret)) ; exit(EX_SOFTWARE) ; } for (lstres=lstres0;lstres !=NULL;lstres=lstres>ai_next) { myproto = getprotobynumber(lstres>ai_protocol) ; (void)printf("Port : %d Protocole : %s\n",\ ntohs(((struct sockaddr_in*)lstres>ai_addr)>sin_port), myproto>p_name) ; } freeaddrinfo(lstres0) ; /* Ne sert rien ici ! */ exit(EX_OK) ; }

getaddrinfo 2.c Ligne 27 On pr ecise IPv4. Ligne 33 Usage de la fonction getprotobynumber dont le prototype est d ecrit au paragraphe 8 page 291 et qui sert ` a retrouver la valeur symbolique dun protocole, connaissant son codage num erique (chier /etc/protocols). Ligne 34, 35 et 36 Achage du num ero de port et du nom du protocole. Notez lusage de la fonction ntohs pour pr esenter les octets du num ero de port dans le bon ordre ! 7.1.7 ... En r esum e

8 Conversion nom de protocole N de protocole

291

Conversion nom de protocole N de protocole

Les fonctions getservbyname et getservbyport d elivrent un nom de protocole, donc un symbole. Lors de la d eclaration dune socket le troisi` eme argument est num erique, il est donc n ecessaire davoir un moyen pour convertir les num eros de protocoles (IPPROTO UDP, IPPROTO TCP, IPPROTO IP,IPPROTO ICMP,...) en symboles et r eciproquement. Le chiers /etc/protocols contient cette information, et la paire de fonctions getprotobyname et getprotobynumber lexploitent.
#include <netdb.h> struct protoent *getprotobyname (const char *name) ; struct protoent *getprotobynumber (int proto) ; struct protoent { char *p_name ; char **p_aliases ; int p_proto ; } ;

p name Le nom ociel du protocol. p aliases La liste des synonymes, le dernier pointeurs est NULL. p proto Le num ero du protocole, dans /etc/services.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

/* * $Id: getprotobyname.c 2 20070912 20:00:17Z fla $ * Exemple dutilisation de la fonction "getprotobyname". */ #include <stdio.h> #include <sysexits.h> #include <netdb.h> /* Pour getprotobyname */ #define USAGE #define MSG1 #define MSG2 "Usage:%s <nom du protocole>\n" "Le protocole %s est reconnu dans /etc/protocols N : %d\n" "Le protocole %s est introuvable dans /etc/protocols !\n"

int main(int argc,char *argv[]) { struct protoent *proto ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if (proto = getprotobyname(argv[1])) (void)printf(MSG1,proto>p_name,proto>p_proto) ; else (void)printf(MSG2,argv[1]) ; exit(EX_OK) ; }

getprotobyname.c

292

Compl ements sur les sockets Berkeley Le source qui pr ec` ede donne un exemple de programmation de la fonction getprotobyname. Usage de ce programme : $ getprotobyname ip Le protocole ip est reconnu dans /etc/protocols - N : 0 $ getprotobyname tcp Le protocole tcp est reconnu dans /etc/protocols - N : 6 $ getprotobyname vmtp Le protocole ipv6 est reconnu dans /etc/protocols - N : 41

Diagnostic

Chaque retour de primitive devrait etre soigneusement test e, le code g en er e nen est que plus able et les eventuels disfonctionnements plus ais es ` a d etecter. Quelques unes des erreurs ajout ees au chier den-t ete errno.h erreur ENOTSOCK EDESTADDRREQ EMSGSIZE EPROTOTYPE ENOPROTOOPT EPROTONOSUPPORT ESOCKTNOSUPPORT EOPNOTSUPP EAFNOSUPPOR EADDRINUSE EADDRNOTAVAIL ENETDOWN ENETUNREACH ENETRESET ECONNABORTED ECONNRESET ENOBUFS EISCONN ENOTCONN ESHUTDOWN ETIMEDOUT ECONNREFUSED EREMOTERELEASE EHOSTDOWN EHOSTUNREACH Description de lerreur Le descripteur nest pas celui dune socket Adresse de destination requise Le message est trop long Mauvais type de protocole pour une socket Protocole non disponible Protocole non support e Type de socket non support e Op eration non support ee Famille dadresse non support ee Adresse d ej` a utilis ee Ladresse ne peut pas etre aect ee R eseau hors service Pas de route pour atteindre ce r eseau Connexion coup ee par le r eseau Connexion interrompue Connexion interrompue par lh ote distant Le buer est satur e La socket est d ej` a connect ee La socket nest pas connect ee Transmission apr` es un shutdown time-out expir e Connexion refus ee Lh ote distant a interrompue sa connexion Lh ote nest pas en marche Pas de route vers cet h ote

10 Exemples de mise en application

293

10
10.1

Exemples de mise en application

Ancienne m ethode (usage de gethostbyname)

Deux premiers exemples de fonctions de connexion ` a un serveur : tcp open et udp open. Toutes les deux renvoient un descripteur de socket pr et ` a lemploi, ou -1 en cas derreur (le message derreur doit etre g en er e par les fonctions elles m emes). Ces deux fonctions sont bas ees sur lusage de lapi gethosbyname, en voici les prototypes :
int tcp_open(char *host, char *service, int port) ; int udp_open(char *host, char *service, int port, int conn) ;

Description des arguments : host Une cha ne de caract` eres qui est ladresse de lh ote distant. Cette adresse est soit sous forme d ecimale point ee, soit cest un nom symbolique. Elle ne peut pas etre nulle. service Si cette cha ne nest pas nulle, elle contient le nom symbolique du service distant sur lequel il faut se connecter. port Le num ero du port distant. Sil est n egatif alors service est obligatoirement non nulle. Dans le cas o` u service est non nulle et port > 0, cette derni` ere valeur lemporte sur celle trouv ee dans le chier /etc/services. conn Cet argument na dusage que pour la fonction udp open. Egal ` a un, il pr ecise que la socket cr ee est d edi ee au serveur host (avec un bind), ie on pourra employer send et recv au lieu de sendto et recvfrom.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

/* $Id: open_tcp1.c 2 20070912 20:00:17Z fla $ * * Fonction "tcp_open" + exemple dutilisation avec "daytime" * et "time". */ #include <stdio.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <sysexits.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <arpa/inet.h> #define USAGE "Usage:%s <nom de machine distante>\n" tcp_serv_addr ; /* Adresse Internet du serveur. */ tcp_serv_info ; /* Infos de "getservbyname". */ tcp_host_info ; /* Infos de "gethostbyname". */

struct sockaddr_in struct servent struct hostent

294
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

Compl ements sur les sockets Berkeley

int tcp_open(char *host,char *service,int port) { int fd ; unsigned long inaddr ; struct hostent *hp ; struct servent *sv ; bzero ((char *)&tcp_serv_addr, sizeof tcp_serv_addr) ; tcp_serv_addr.sin_family = AF_INET ; if (*service) { if (!(sv = getservbyname(service,"tcp"))) { (void)fprintf(stderr,"tcp_open:service inconnu:%s/tcp\n",service) ; return 1 ; } tcp_serv_info = *sv ; if (port > 0) tcp_serv_addr.sin_port = htons(port) ; else tcp_serv_addr.sin_port = sv>s_port ; } else { if (port <= 0) { (void)fprintf(stderr,"tcp_open:numro de port non spcifi !\n") ; return 1 ; } tcp_serv_addr.sin_port = htons(port) ; } if ((inaddr = inet_addr(host)) != INADDR_NONE) { /* netid.hostid ? */ bcopy((char *)&inaddr,(char *)&tcp_serv_addr.sin_addr,sizeof inaddr) tcp_host_info.h_name = (char *)NULL ; } else { if (!(hp = gethostbyname(host))) { (void)fprintf(stderr,"tcp_open: erreur de nom de machine : %s : %s\n", host,strerror(errno)) ; return 1 ; } tcp_host_info = *hp ; bcopy(hp>h_addr,(char *)&tcp_serv_addr.sin_addr,hp>h_length) ; }

if ((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { (void)fprintf(stderr,"tcp_open: impossible de crer la socket !\n") ; return 1 ; } if (connect(fd,(struct sockaddr *)&tcp_serv_addr,sizeof tcp_serv_addr)<0) (void)fprintf(stderr,"tcp_open: impossible de se connecter !\n") ; (void)close(fd) ; return 1 ; } return fd ; } int main(int argc,char *argv[]) { int sfd ; int n ; unsigned long temps ; char buf[256] ;

Exemples de mise en application

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

295

if (argc < 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit (EX_USAGE) ; } /* * Connexion au serveur de date */ if ((sfd = tcp_open(argv[1],"daytime",0)) < 0) exit(EX_SOFTWARE) ; if ((n=read(sfd,(void *)buf, sizeof(buf)1))< 0) perror("read/daytime") ; else { buf[n]=\0; (void)printf("Date(%s)=%s",argv[1],buf) ; } (void)close(sfd) ; /* * Connexion au serveur de temps */ if ((sfd = tcp_open(argv[1],"",37)) < 0) exit (EX_SOFTWARE) ; if (read(sfd,(void *)&temps, sizeof temps) < 0) perror("read/port 37") ; else (void)printf("Temps(%s)=%lu\n",argv[1],ntohl(temps)) ; exit (EX_OK) ; }

open tcp.c Exemple dusage : $ ./open_tcp localhost Date : Sun Dec 2 16:12:57 2001 Temps : 3216294777 Remarque : Pour transmettre la structure dadresse du serveur ` a la fonction appelante, La fonction udp open compl` ete une structure globale.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

/* $Id: open_udp1.c 2 20070912 20:00:17Z fla $ * * Fonction "udp_open" + exemple dutilisation avec "daytime" * et "time". */ #include <stdio.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <sysexits.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <arpa/inet.h> #define USAGE "Usage:%s <nom de machine distante>\n" struct sockaddr_in udp_serv_addr ; /* Adresse Internet du serveur. */ struct sockaddr_in udp_cli_addr ; /* Adresse Internet du client. */ struct servent udp_serv_info ; /* Infos de "getservbyname". */

296
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

Compl ements sur les sockets Berkeley

int udp_open(char *host,char *service,int port,int conn) { int fd ; unsigned long inaddr ; struct hostent *hp ; struct servent *sv ; bzero ((char *)&udp_serv_addr, sizeof udp_serv_addr) ; udp_serv_addr.sin_family = AF_INET ; if (*service) { if (!(sv = getservbyname(service,"udp"))) { (void)fprintf(stderr,"udp_open:service inconnu:%s/udp\n",service) ; return 1 ; } udp_serv_info = *sv ; if (port > 0) udp_serv_addr.sin_port = htons(port) ; else udp_serv_addr.sin_port = sv>s_port ; } else { if (port <= 0) { (void)fprintf(stderr,"udp_open:numro de port non spcifi !\n") ; return 1 ; } udp_serv_addr.sin_port = htons(port) ; }

if ((inaddr = inet_addr(host)) != INADDR_NONE) { /* netid.hostid ? */ bcopy ((char *)&inaddr,(char *)&udp_serv_addr.sin_addr,sizeof inaddr) udp_host_info.h_name = (char *)NULL ; } else { if (!(hp = gethostbyname(host))) { (void)fprintf(stderr,"udp_open:erreur de nom de machine:%s:%s\n", host,strerror(errno)) ; return 1 ; } udp_host_info = *hp ; bcopy(hp>h_addr,(char *)&udp_serv_addr.sin_addr,hp>h_length) ; } if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { (void)fprintf(stderr,"udp_open: impossible de crer la socket !\n") ; return 1 ; } bzero ((char *)&udp_cli_addr,sizeof udp_cli_addr) ; udp_cli_addr.sin_family = AF_INET ; udp_cli_addr.sin_addr.s_addr = htonl(INADDR_ANY) ; udp_cli_addr.sin_port = htons(0) ; if (bind(fd,(struct sockaddr *)&udp_cli_addr,sizeof udp_cli_addr) < 0) { (void)fprintf(stderr,"udp_open:erreur avec ladresse locale !\n") ; (void)close(fd) ; return 1 ; } if (conn == 1) { /* Figer ladresse du serveur. */ if (connect(fd,(struct sockaddr *)&udp_serv_addr, sizeof udp_serv_addr)<0) { (void)fprintf(stderr,"udp_open: connexion impossible avec %s !\n",\ host) (void)close(fd) ; return 1 ; } } return fd ; }

Exemples de mise en application

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

297

int main(int argc,char *argv[]) { int sfd ; int n ; unsigned long temps ; char buf[256] ; if (argc < 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit (EX_USAGE) ; } /* * Connexion au serveur de date */ if ((sfd = udp_open(argv[1],"daytime",0,1)) < 0) exit(EX_SOFTWARE) ; if (send(sfd,(void *)" ",1,0) < 0) perror("send") ; else if ((n=recv(sfd,(void *)buf, sizeof buf,0)) < 0) perror("recv") ; else { buf[n]=\0 ; (void)printf("Date(%s)=%s",argv[1],buf) ; } (void)close(sfd) ; /* * Connexion au serveur de temps */ if ((sfd = udp_open(argv[1],"",37,0)) < 0) exit(EX_SOFTWARE) ; n = sizeof udp_serv_addr ; if (sendto(sfd,(void *)" ",1,0,(void *)&udp_serv_addr, n) < 0) perror("sendto") ; else if (recvfrom(sfd,(void *)&temps,sizeof temps,0,\ (void *)&udp_serv_addr, &n) < 0) perror("recvfrom") ; else (void)printf("Temps(%s)=%lu\n",argv[1],ntohl(temps)) ; exit(EX_OK); }

open udp.c Exemple dusage : $ ./open_udp localhost Date : Sun Dec 2 16:12:17 2001 Temps : 3216294737

298

Compl ements sur les sockets Berkeley

10.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

Nouvelle m ethode (usage de getaddrinfo)

/* $Id$ * * Fonction "sock_open" + exemple dutilisation avec "daytime" * et "time" en UDP et TCP. */ #include <stdio.h> #include <unistd.h> #include <stdlib.h> #include <sysexits.h> #include <strings.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <arpa/inet.h> #define USAGE "Usage:%s <host distant>\n"

int sock_open(char *host,char *service,int socktype) { int ret ; int mysoc ; struct addrinfo profil, *res, *lstres0 ; bzero(&profil,sizeof(profil)) ; profil.ai_family = AF_INET ; profil.ai_socktype = socktype ; profil.ai_flags = AI_PASSIVE ; if ((ret = getaddrinfo(host,service,&profil,&lstres0))) { (void)fprintf(stderr,"%s",gai_strerror(ret)) ; return 1 ; } for (res=lstres0;res!=NULL;res=res>ai_next) { if ((mysoc=socket(res>ai_family,res>ai_socktype, res>ai_protocol)) < 0) continue ; if (connect(mysoc,res>ai_addr,res>ai_addrlen) == 0) break ; /* Gotcha ! */ (void)close(mysoc) ; /* inutilisable */ mysoc=1 ; } freeaddrinfo(lstres0) ; if (mysoc < 0) (void)fprintf(stderr,"Unable to connect to %s:%s\n",host,service) ; return mysoc ; } int main(int argc,char *argv[]) { int sfd ; int n ; unsigned long temps ; char buf[256] ; if (argc < 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit (EX_USAGE) ; }

Cette nouvelle version combine tcp open et udp open en un seul souce. La en` ere un descripteur de socket pr et ` a lemploi, comme fonction sock open g

Exemples de mise en application pr ec edemment. Le main appelle quatre fois cette nouvelle fonction avec les m emes hypoth` eses de travail que pour les anciennes versions.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

299

/* * Connexion au serveur de date avec UDP (socket ddie) */ if ((sfd = sock_open(argv[1],"daytime",SOCK_DGRAM)) >= 0) { if (send(sfd,(void *)" ",1,0) < 0) perror("send Daytime") ; else if ((n=recv(sfd,(void *)buf, sizeof(buf)1,0)) < 0) perror("recv Daytime") ; else { buf[n]=\0 ; (void)printf("Date/udp/%s=%s",argv[1],buf) ; } (void)close(sfd) ; } /* * Connexion au serveur de temps avec UDP (socket ddie) */ if ((sfd = sock_open(argv[1],"37",SOCK_DGRAM)) >= 0) { if (send(sfd,(void *)" ",1,0) < 0) perror("send Time") ; else if (recv(sfd,(void *)&temps,sizeof temps,0) < 0) perror("recv Time") ; else (void)printf("Temps/udp/%s=%u\n",argv[1],ntohl(temps)) ; (void)close(sfd) ; } /* * Connexion au serveur de date avec TCP */ if ((sfd = sock_open(argv[1],"daytime",SOCK_STREAM)) >= 0) { if ((n=read(sfd,(void *)buf, sizeof(buf)1))< 0) perror("read Daytime") ; else { buf[n]=\0; (void)printf("Date/tcp/%s=%s",argv[1],buf) ; } (void)close(sfd) ; } /* * Connexion au serveur de temps avec TCP */ if ((sfd = sock_open(argv[1],"37",SOCK_STREAM)) >= 0) { if (read(sfd,(void *)&temps, sizeof temps) < 0) perror("read Time") ; else (void)printf("Temps/tcp/%s=%u\n",argv[1],ntohl(temps)) ; (void)close(sfd) ; } exit(EX_OK); }

Exemple dusage : Date/udp/srv-sio=Mon Nov 3 19:19:11 2008 Temps/udp/srv-sio=3434725151 Date/tcp/srv-sio=Mon Nov 3 19:19:11 2008 Temps/tcp/srv-sio=3434725151

300

Compl ements sur les sockets Berkeley

11

Conclusion et bibliographie

Outre les pages de manuel (man) des primitives et fonctions rencontr ees, le lecteur pourra consulter avec grand prot les ouvrages suivants : RFC 1700 J. Reynolds, J. Postel, ASSIGNED NUMBERS , 10/20/1994. (Pages=230) (Format=.txt) (Obsoletes RFC1340) (STD 2) Consultez surtour le site http://www.iana.org/ RFC 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format : TXT=82570 bytes) (Obsoletes RFC2553) (Status : INFORMATIONAL) Et des ouvrages de r ef erences : Samuel J. Leer, Robert S. Fabry, William N. Joy, Phil Lapsley An Advanced 4.4BSD Interprocess Communication Tutorial CSRG University of California, Berkeley Berkeley, California 94720. Ce document est re edit e dans Programmers Supplementary Documents editeur OReilly, ou sous forme de chier ascii dans le r epertoire : /usr/share/doc/psd/21.ipc/paper.ascii.gz W. Richard Stevens Unix Network Programming Prentice All 1990 W. Richard Stevens Unix Network Programming Second edition Prentice All 1998 W. Richard Stevens Bill Fenner Andrew M. Rudo Unix Network Programming Third edition, volume 1 Prentice All 2004 Douglas E. Comer David L. Stevens Internetworking with TCP/IP Volume III (BSD Socket version) Prentice All 1993

Chapitre XIV ements de serveurs El

Dans ce chapitre nous abordons quelques grands principes de fonctionnement des logiciels serveurs. Dabord nous tentons de r esumer leurs comportements selon une typologie en quatre mod` eles g en eriques, puis nous examinons quelques points techniques remarquables de leur architecture logicielle comme la gestion des t aches multiples, des descripteurs multiples, le fonctionnement en arri` ere plan (les fameux daemon ), la gestion des logs. . . Enn nous concluons ce chapitre avec une pr esentation tr` es synth etique du serveur de serveurs sous Unix, cest ` a dire la commande inetd, suivie dune lecture comment ee dun petit code en langage C qui sinspire de son fonctionnement, pour mieux comprendre sa strat egie !

Type de serveurs

Lalgorithme intuitif dun serveur, d eduit des sch emas (revoir la page 265) dutilisation des sockets, pourrait etre celui-ci : 1. Cr eer une socket, lui aecter une adresse locale avec un num ero de port connu des clients potentiels. 2. Entrer dans une boucle innie qui accepte les requ etes des clients, les lit, formule une r eponse et la renvoie au client. Cette d emarche, que nous pourrions qualier de na ve, ne peut convenir qu` a des applications tr` es simples. Consid erons lexemple dun serveur de chiers fonctionnant sur ce mode. Un client r eseau qui sy connecte et t el echarge pour 10 Go de donn ees accapare le serveur pendant un temps signicativement long, m eme au regard des bandes passantes modernes. Un deuxi` eme client r eseau qui attendrait la disponibilit e du m eme serveur pour transf erer 1Ko aurait des raisons de simpatienter !

1.1

Serveurs it eratif et concourant

Un serveur it eratif ( iterative server ) d esigne une impl ementation qui traite une seule requ ete ` a la fois.

302

ements de serveurs El Un serveur concourant ( concurrent server ) d esigne une impl ementation capable de g erer plusieurs t aches en apparence simultan ees. Attention, cette fonctionnalit e nimplique pas n ecessairement que ces t aches concourantes doivent toutes sex ecuter en parall` ele. . . Dans cette premi` ere approche purement algorithmique nous nabordons pas la mise en uvre technique, le paragraphe 2 sy consacrera ! Dun point de vue conceptuel, les serveurs it eratifs sont plus faciles ` a concevoir et ` a programmer que les serveurs concourants, mais le r esultat nest pas toujours satisfaisant pour les clients. Au contraire, les serveurs concourants, sils sont dune conception plus savante, sont dun usage plus agr eable pour les utilisateurs parceque naturellement plus disponibles.

1.2

Le choix dun protocole

La pile ARPA nous donne le choix entre TCP et UDP. Lalternative nest pas triviale. Le protocole dapplication peut etre compl` etement boulevers e par le choix de lun ou de lautre. Avant toute chose il faut se souvenir des caract eristiques les plus marquantes de lun et de lautre.

1.2.1

Mode connect e

Le mode connect e avec TCP est le plus facile ` a programmer, de plus il assure que les donn ees sont transmises, sans perte. Par contre, Il etablit un circuit virtuel bi-directionnel d edi e ` a chaque client ce qui monopolise une socket, donc un descripteur, et interdit par construction toute possibilit e de broadcast . L etablissement dune connexion et sa terminaison entra ne l echange de 7 paquets. Sil ny a que quelques octets ` a echanger entre le client et le serveur, cet echange est un gaspillage des ressources du r eseau. Il y a plus pr eoccupant. Si la connexion est au repos , cest ` a dire quil ny a plus d echange entre le client et le serveur, rien nindique ` a celui-ci que le client est toujours l` a ! TCP est silencieux si les deux parties nont rien ` a 1 s echanger . Si lapplication cliente a et e interrompue accidentellement2 , rien nindique au serveur que cette connexion est termin ee et il maintient la socket et les buers associ es. Que cette op eration se r ep` ete un grand nombre de fois et le serveur ne r epondra plus, faute de descripteur disponible, voire de m emoire libre au niveau de la couche de transport (allocation au niveau du noyau, en fonction de la m emoire totale et au d emarrage de la machine) !
Nous verrons au chapitre suivant comment on peut modier ce comportement par d efaut 2 crash du syst` eme, retrait du r eseau,. . .
1

Quatre mod` eles de serveurs 1.2.2 Mode datagramme

303

Le mode datagramme ou non connect e avec UDP h erite de tous les d esagr ements de IP, ` a savoir perte, duplication et d esordre introduit dans lordre des datagrammes. Pourtant malgr e ces inconv enients UDP reste un protocole qui ore des avantages par rapport ` a TCP. Avec un seul descripteur de socket un serveur peut traiter un nombre quelconque de clients sans perte de ressources due ` a de mauvaises d econnexions. Le broadcast et le multicast sont possibles. Par contre les probl` emes de abilit e du transport doivent etre g er es au niveau de lapplication. G en eralement cest la partie cliente qui est en charge de la r e emission de la requ ete si aucune r eponse du serveur ne lui parvient. La valeur du temps au del` a duquel lapplication consid` ere quil doit y avoir r e emission est evidement d elicate ` a etablir. Elle ne doit pas etre g ee aux caract eristiques dun r eseau local particulier et doit etre capable de sadapter aux conditions changeantes dun internet.

1.3

Quatre mod` eles de serveurs

Deux comportements de serveurs et deux protocoles de transport combin es induisent quatre mod` eles de serveurs :

Itratif Datagramme

Itratif Connect

Concourant Datagramme

Concourant Connect

gure XIV.01 La terminologie t ache esclave employ ee dans les algorithmes qui suivent se veut neutre quant au choix technologique retenu pour les impl ementer. Ce qui importe cest leur nature concourante avec la t ache ma tre qui les pilote. Algorithme it eratif - Mode data-gramme :

1. Cr eer une socket, lui attribuer un port connu des clients. 2. R ep eter : Lire une requ ete dun client, Formuler la r eponse, Envoyer la r eponse, conform ement au protocole dapplication.

304

ements de serveurs El Critique : Cette forme de serveur est la plus simple, elle nest pas pour autant inutile. Elle est adapt ee quand il y a un tout petit volume dinformation ` a echanger et en tout cas sans temps de calcul pour l elaboration de la r eponse. Le serveur de date daytime ou le serveur de temps time en sont dexcellents exemples.

Quatre mod` eles de serveurs Algorithme It eratif - Mode connect e:

305

1. Cr eer une socket, lui attribuer un port connu des clients. 2. Mettre la socket ` a l ecoute du r eseau, en mode passif. 3. Accepter la connexion entrante, obtenir une socket pour la traiter. 4. Entamer le dialogue avec le client, conform ement au protocole de lapplication. 5. Quand le dialogue est termin e, fermer la connexion et aller en 3). Critique : Ce type de serveur est peu utilis e. Son usage pourrait etre d edi e ` a des relations clients/serveurs mettant en jeu de petits volumes dinformations avec la n ecessit e den assurer ` a coup s ur le transport. Le temps d elaboration de la r eponse doit rester court. Le temps d etablissement de la connexion nest pas n egligeable par rapport au temps de r eponse du serveur, ce qui le rend peu attractif. Algorithme concourant - Mode datagramme : Ma tre : 1. Cr eer une socket, lui attribuer un port connu des clients. 2. R ep eter : Lire une requ ete dun client Cr eer une t ache esclave pour elaborer la r eponse. Esclave : 1. Recevoir la demande du client, 2. Elaborer la r eponse, 3. Envoyer la r eponse au client, conform ement au protocole de lapplication, 4. Terminer la t ache.

306

ements de serveurs El Critique : Si le temps d elaboration de la r eponse est rendu indi erent pour cause de cr eation de processus esclave, par contre le co ut de cr eation de ce processus ls est prohibitif par rapport ` a son usage : formuler une seule r eponse et lenvoyer. Cet inconv enient lemporte g en eralement sur lavantage apport e par le parall elisme . N eanmoins, dans le cas dun temps d elaboration de la r eponse long par rapport au temps de cr eation du processus esclave, cette solution se justie. Algorithme concourant - Mode connect e: Ma tre : 1. Cr eer une socket, lui attribuer un port connu des clients. 2. Mettre la socket ` a l ecoute du r eseau, en mode passif. 3. R ep eter : Accepter la connexion entrante, obtenir une socket pour la traiter, Cr eer une t ache esclave pour traiter la r eponse. Esclave : 1. Recevoir la demande du client, 2. Amorcer le dialogue avec le client, conform ement au protocole de lapplication, 3. Terminer la connexion et la t ache. Critique : Cest le type le plus g en eral de serveur parce-quil ore les meilleurs caract eristiques de transport et de souplesse dutilisation pour le client. Il est sur-dimensionn e pour les petits services et sa programmation soign ee nest pas toujours ` a la port ee du programmeur d ebutant.

2 Technologie el ementaire

307

Technologie el ementaire

De la partie algorithmique d ecoulent des questions techniques sur le comment le faire . Ce paragraphe donne quelques grandes indications tr` es el ementaires que le lecteur soucieux dacqu erir une vraie comp etence devra compl eter par les lectures indiqu ees au dernier paragraphe ; la Bibliographie du chapitre (page 325). Notamment il est n ecessaire de consulter les ouvrages de W. R. Stevens pour la partie syst` eme et David R. Butenhof pour la programmation des threads. La suite du texte va se consacrer ` a eclairer les points suivants : 1. Gestion des t aches esclaves (paragraphes 2.1, 2.2, 2.3, 2.4) 2. Gestion de descripteurs multiples (paragraphes 2.5, 2.6) 3. Fonctionnement des processus en arri` ere plan ou daemon (paragraphe 3)

2.1

Gestion des t aches esclaves

La gestion des t aches esclaves signal ees dans le paragraphe 1 induit que le programme serveur est capable de g erer plusieurs actions concourantes, cest ` a dire qui ont un comportement qui donne lillusion ` a lutilisateur que sa requ ete est trait ee dans un d elai raisonnable, sans devoir patienter jusqu` a lach` evement de la requ ete pr ec edente. Cest typiquement le comportement dun syst` eme dexploitation qui ordonnance des processus entre-eux pour donner ` a chacun deux un peu de la puissance de calcul disponible ( time-sharing ). La d emarche qui parait la plus naturelle pour impl ementer ces t aches esclaves est donc de tirer partie des propri et es m emes de la gestion des processus du syst` eme dexploitation. Sur un syst` eme Unix lusage de processus est une bonne solution dans un premier choix car ce syst` eme dispose de primitives (APIs) bien rod ees pour les g erer, en particulier fork(), vfork() et rfork(). N eanmoins, comme le paragraphe suivant le rappelle, lusage de processus ls nest pas la panac ee car cette solution comporte des d esagr ements. Deux autres voies existent, non toujours valables partout et dans tous les cas de gure. La premi` ere passe par lusage de processus l egers ou threads eme par lusage du signal SIGIO qui autorise ce que (paragraphe 2.3), la deuxi` lon nomme la programmation asynchrone (paragraphe 2.4). Pour conclure il faut pr eciser que des t aches esclaves ou concourantes peuvent sex ecuter dans un ordre al eatoire mais pas n ecessairement en m eme temps. Cette derni` ere caract eristique est celle des t aches parall` eles. Autrement dit, les t aches parall` eles sont toutes concourantes mais linverse nest pas vrai. Concr` etement il faut disposer dune machine avec plusieurs processeurs pour avoir, par exemple, des processus (ou des threads kernel , si elles sont support ees) qui sex ecutent vraiment de mani` ere simultan ee donc sur

308

ements sur les serveurs El des processeurs di erents. Sur une architecture mono-processeur, les t aches ne peuvent etre que concourantes !

2.2

fork, vfork et rfork

Il ne sagit pas ici de faire un rappel sur la primitive fork() examin ee dans le cadre du cours sur les primitives Unix, mais dexaminer lincidence de ses propri et es sur larchitecture des serveurs. Le r esultat du fork() est la cr eation dun processus ls qui ne di` ere de son p` ere que par les points suivants : 1. Le code de retour de fork : 0 pour le ls, le pid du ls pour le p` ere 2. Le num ero de processus (pid) ainsi que le num ero de processus du processus p` ere (ppid) 3. Les compteurs de temps (utime, stime, . . .) qui sont remis ` a z ero 4. Les verrous (flock) qui ne sont pas transmis 5. Les signaux en attente non transmis egalement Tout le reste est doublonn e, notamment la stack et surtout la heap qui peuvent etre tr` es volumineuses et donc rendre cette op eration p enalisante voire quasi r edhibitoire sur un serveur tr` es charg e (des milliers de processus et de connexions r eseaux). Si le but du fork dans le processus ls est deectuer un exec imm ediatement, alors il tr` es int eressant dutiliser plut ot le vfork. Celui-ci ne fait que cr eer un processus ls sans copier les donn ees. En cons equence, durant le temps de son ex ecution avant le exec le ls partage strictement les m emes donn ees que le p` ere (` a utiliser avec pr ecaution). Jusqu` a ce que le processus rencontre un exit ou un exec, le processus p` ere reste bloqu e (le vfork ne retourne pas). En allant plus loin dans la direction prise par vfork, le rfork3 autorise la continuation du processus p` ere apr` es le fork, la cons equence est que deux processus partagent le m eme espace dadressage simultan ement. Largument dappel du rfork permet de param` etrer ce qui est eectivement partag e ou non. RFMEM, le principal dentre eux, indique au noyau que les deux processus partagent tout lespace dadressage. Si cette derni` ere primitive est tr` es riche de potentialit es4 , elle est egalement d elicate ` a manipuler : deux (ou plus) entit es logicielles ex ecutant le m eme code et acc edant aux m emes donn ees sans pr ecaution particuli` ere vont tr` es certainement converger vers de s erieux ennuis de fonctionnement si le d eroulement de leurs op erations nest pas rigoureusement balis e. En eet, le soucis principal de ce type de programme multi-entit es est de veiller ` a ce quaucune de ses composantes ne puisse changer les etats de
clone() sous Linux dailleurs limpl ementation actuelle des threads sous Linux emploie cette primitive avec des avantages et beaucoup dinconv enients par rapport ` a ce que pr evoit la norme Posix et ` a la gestion des processus
4 3

Processus l egers, les threads sa m emoire simultan ement. Autrement dit, il faut introduire presque obligatoirement un m ecanisme de s emaphore qui permette ` a lune des entit es logicielles de v erouiller lacc` es ` a telle ou telle ressource m emoire pendant le temps n ecessaire ` a son usage. Cette op eration de v erouillage elle-m eme pose probl` eme, parceque les entit es logicielles pouvent sex ecuter en parall` ele (architecture multiprocesseurs) et donc il est indispensable que lacquisition du s emaphore qui prot` ege une ressource commune soit une op eration atomique, cest ` a dire qui sex ecute en une fois, sans quil y ait possibilit e que deux (ou plus) entit es logicielles tentent avec succ` es de lacqu erir. Cest toute la probl` ematique des mutex5 .

309

2.3

Processus l egers, les threads

Les processus l egers ou threads sont une id ee du milieu des ann ees 80. La norme Posix a pos e les bases de leur d eveloppement durable en 1995 (Posix 1.c), on parle dans ce cas des pthreads. Lid ee fondatrice des threads est de ne pas faire de fork mais plut ot de permettre le partage de lespace dadressage ` a autant de contextes dex ecution du m eme code6 que lon souhaite.
Sans thread Avec threads

Stack Adresses croissantes Registres... CP

Registres... Thread 2 CP2 Registres... Thread 1 CP1

f2() f1() 0x00000000 Texte

f2() f1() Texte

gure XIV.02 Au lieu de cr eer un nouveau processus on cr ee une nouvelle thread, ce qui revient (en gros) ` a ajouter un nouveau contexte dex ecution sur la pile syst` eme dans le processus. Lusage de mutex (cf paragraphe 2.2) est fortement recommand e pour s erialiser les acc` es aux sections critiques du code. Sur une machine ayant une architecture mono-processeur, le premier type de threads est susant, mais d` es que la machine est construite avec une ar7 8 chitecture smp ou cmt (ce qui est de plus en plus le cas avec la banalisation
mutual exclusion ordre de grandeur de quelques dizaines 7 Symmetric Multi Processor 8 Chip Multithreading - http://developers.sun.com/solaris/articles/app_ perf_cmt.html
6 5

310

ements sur les serveurs El des congurations ` a plusieurs processeurs chacun etant lui-m eme compos e de plusieurs curs) lusage de threads g erables par le noyau devient beaucoup plus int eressant car il utilise au mieux les ressources de la machine : un m eme processus pourrait avoir deux threads, une sex ecutant sur chacun des deux processeurs (ou plus bien entendu, sil y a plus de processeurs). Le principe etant pos e, on distingue plusieurs familles dimpl ementation. Dun cot e il y a les threads user land cest ` a dire qui sont compl` etement g er ees par le processus utilisateur et de lautre les threads kernel , qui sont g er ees par le noyau. Ces derni` eres threads sont support ees par les constructeurs de machines ` a architectures parall` eles, traditionnellement Sun (Solaris), Ibm (Aix), et Compaq (ex Digital, avec True64) et plus r ecemment Hewlett-Packard avec la version 11.xx dHP-UX. Le probl` eme est tr` es complexe et chaque constructeur d eveloppe ses propres strat egies. Du cot e des OS libres le probl` eme a stagn e un peu pendant des ann ees car il monopolise beaucoup de programmeurs de haut niveau, non toujours disponibles pour des t aches au long court. . .N eanmoins la famille des BSD (FreeBSD et NetBSD principalement) b en ecie depuis peu dune gestion op erationnelle des threads. Les threads Linux utilisent rfork qui est simple et tr` es ecace. Cette approche nest pas satisfaisante car chaque thread est ex ecut ee dans un processus di erent (pid di erent donc) ce qui est contraire aux recommandations POSIX, dune part, et dautre par ne permet pas dutiliser les r` egles de priorit e d enies egalement par POSIX. Une application avec un grand nombre de threads prend lavantage sur les autres applications par le fait quelle consomme en temps cumul e bien plus que les autres processus mono-thread. Les threads de FreeBSD sont devenues tr` es ecaces et performantes depuis la version 7 du syst` eme, ` a lissue dun travail de longue haleine dont lhistorique se trouve sur cette page http://www.freebsd.org/smp/. Conclusion : Les threads user land ne sex ecutent que sur un seul processeur quelle que soit larchitecture de la machine qui les supporte. Sur une machine de type smp/cmt il faut que le syst` eme dexploitation supporte les threads kernel pour quun m eme processus puisse avoir des sous-t aches sur tous les processeurs existants.

Programmation asynchrone

311

2.4

Programmation asynchrone

Les paragraphes qui pr ec` edent utilisent un processus ou une thread pour pouvoir eectuer au moins deux t aches simultan ement : ecouter le r eseau et traiter une (ou plusieurs) requ ete(s). Dans le cas dun serveur peu sollicit e il tout ` a fait envisageable de mettre en uvre une autre technique appell ee programmation asynchrone . La programmation asynchrone sappuie sur lusage du signal, SIGIO (SIGPOLL sur syst` eme V), ignor e par d efaut, qui pr evient le processus dune activit e sur un descripteur. La gestion des entr ees/sorties sur le descripteur en question est alors trait ee comme une exception, par un handler de signaux. Le signal SIGIO est ignor e par d efaut, il faut demander explicitement au noyau de le recevoir, ` a laide dun appel ` a la primitive fcntl. Une fois activ e, il nest pas re cu pour les m emes raisons selon le protocole employ e: UDP : Arriv ee dun paquet pour la socket Une erreur TCP : Une demande de connexion (attente sur un accept) qui arrive Une d econnexion Une demi-d econnexion (shutdown) Arriv ee de donn ees sur une socket Fin de l emission de donn ees (buer d emission vide) sur une socket Une erreur O` u lon voit que cette technique, du moins en TCP, ne peut etre envisag ee pour que pour des serveurs peu sollicit es. Un trop grand nombre dinterruptions possibles nuit ` a lecacit e du syst` eme (changements de contexte). De plus la distinction entre les causes du signal est dicile ` a faire, donc ce signal en TCP est quasi inexploitable. Conclusion : La d enomination programmation asynchrone bas ee seulement sur lusage du signal SIGIO (versus SIGPOLL) est abusive. Pour etre vraiment asynchrones, ces op erations de lecture et d ecriture ne devraient pas etre assujetties au retour des primitives read ou write9 . Cette technique permet l ecriture du code de petits serveurs bas e sur le protocole UDP (En TCP les causes de r eception dun tel signal sont trop nombreuses) sans fork ni thread.

La norme POSIX permet un tel comportement avec les primitives aio read et aio write

312

ements sur les serveurs El

2.5

La primitive select

Un serveur qui a la charge de g erer simultan ement plusieurs sockets (serveur multi-protocoles par exemple, comme inetd. . .) se trouve par construction dans une situation o` u il doit examiner en m eme temps plusieurs descripteurs (il pourrait sagir aussi de tubes de communication). Il est absolument d econseill e dans cette situation de faire du polling. Cette activit e consisterait ` a examiner chaque descripteur lun apr` es lautre dans une boucle innie qui devrait etre la plus rapide possible pour etre la plus r eactive possible face aux requ etes entrantes. Sous Unix cette op eration entra ne une consommation exag er ee des ressources cpu, au d etriment des autres usagers et services. La primitive select (4.3 BSD) surveille un ensemble de descripteurs, si aucun nest actif le processus est endormi et ne consomme aucune ressource cpu. D` es que lun des descripteurs devient actif (il peut y en avoir plusieurs ` a la fois) le noyau r eveille le processus et lappel de select rend la main ` a la proc edure appelante avec susemment dinformation pour que celle-ci puisse identier quel(s) descripteur(s) justie(nt) son r eveil !
#include #include <sys/types.h> <sys/time.h> *readfs, *writefs, *exceptfs, timeval *timeout) ; /* /* /* /* Tous les bits a zero. Positionne fd dans fdset Retire fd de fdset Teste la presence de fd */ */ */ */ */ */ */

int select (int maxfd, fd_set fd_set fd_set struct

FD_ZERO(fd_set *fdset) ; FD_SET(int fd, fd_set *fdset) ; FD_CLR(int fd, fd_set *fdset) ; FD_ISSET(int fd, fd_set *fdset) ; struct timeval { long tv_sec ; long tv_usec ; } ;

/* Cf "time.h" /* Nombre de secondes. /* Nombre de micro-secondes.

Le type fd set est d ecrit dans <sys/types.h>, ainsi que les macros FD XXX. Le prototype de select est dans <sys/time.h>. La primitive select examine les masques readfs, writefs et exceptfs et se comporte en fonction de timeout : Si timeout est une structure existante (pointeur non nul), la primitive retourne imm ediatement apr` es avoir test e les descripteurs. Tous les champs de timeout doivent etre ` a 0 ( polling dans ce cas). Si timeout est une structure existante (pointeur non nul), et si ses champs sont non nuls, select retourne quand un des descripteurs est

La primitive select pr et, et en tout cas jamais au del` a de la valeur pr ecis ee par timeout (cf MAXALARM dans <sys/param.h>). Si timeout est un pointeur NULL, la primitive est bloquante jusqu` a ce quun descripteur soit pr et (ou quun signal intervienne). Remarque : select travaille au niveau de la micro-seconde, ce que ne fait pas sleep (seconde), do` u un usage possible de timer de pr ecision. readfs descripteurs ` a surveiller en lecture. writefs descripteurs ` a surveiller en ecriture. exceptfs Ce champ permet de traiter des ev enements exceptionnels sur les descripteurs d esign es. Par exemple : Donn ees out-of-band sur une socket. Contr ole du statut sur un pseudo-tty ma tre. maxfd prend ` a lappel la valeur du plus grand descripteur ` a tester, plus un. Potentiellement un syst` eme BSD (4.3 et versions suivantes) permet dexaminer jusqu` a 256 descripteurs. A lappel, le programme pr ecise quels sont les descripteurs ` a surveiller dans readfs, writefs et exceptfs. Au retour, la primitive pr ecise quels sont les descripteurs qui sont actifs dans les champs readfs, writefs et exceptfs. Il convient donc de conserver une copie des valeurs avant lappel si on veut pouvoir les r eutiliser ult erieurement. La primitive renvoie -1 en cas derreur (` a tester syst ematiquement) ; une cause derreur classique est la r eception dun signal (errno==EINTR). La macro FD ISSET est utile au retour pour tester quel descripteur est actif et dans quel ensemble. Le serveur de serveurs inetd (page 4) est un excellent exemple dutilisation de la primitive.

313

314

ements sur les serveurs El

2.6

La primitive poll

La primitive poll (System V) permet la m eme chose que la primitive select, mais avec une approche di erente.
#include <poll.h> int poll(struct pollfd *fds, unsigned int nfds, int timeout); struct pollfd { int fd ; /* Descripteur de fichier */ short events ; /* Evenements attendus */ short revents ; /* Evenements observes */ } ;

La primitive retourne le nombre de descripteurs rendus disponibles pour eectuer des op erations dentr ee/sortie. -1 indique une condition derreur. 0 indique lexpiration dun d elai ( time-out ). fds est un pointeur sur la base dun tableau de nfds structures du type struct pollfd. Les champs events et revents sont des masques de bits qui param` etrent respectivement les souhaits du programmeur et ce que le noyau retourne. On utilise principalement : POLLIN POLLOUT POLLERR POLLHUP nfds Taille du vecteur. timeout Est un compteur de millisecondes qui pr ecise le comportement de poll : Le nombre de millisecondes est positif strictement. Quand le temps pr evu est ecoul e, la primitive retourne dans le code de lutilisateur m eme si aucun ev enement nest intervenu. Le nombre de millisecondes est INFTIM (-1), la primitive est bloquante. 0. La primitive retourne imm ediatement. On sapper coit imm ediatement que la valeur du param` etre de timeout nest pas compatible ni en forme ni en comportement entre select et poll.

3 Fonctionnement des daemons

315

Fonctionnement des daemons

Sous Unix les serveurs sont impl ement es le plus souvent sous forme de daemons10 . La raison principale est que ce type de processus est le plus adapt e ` a cette forme de service, comme nous allons lexaminer.

3.1

Programmation dun daemon

Les daemons sont des processus ordinaires, mais : ils ne sont pas rattach es ` a un terminal particulier (ils sont en arri` ere plan ) ; ils sex ecutent le plus souvent avec les droits du super-utilisateur , voire, mieux, sous ceux dun pseudo-utilisateur sans mot de passe ni shell d eni. ils sont le plus souvent lanc es au d emarrage du syst` eme, lors de lex ecution des shell-scripts de conguration (par exemple ` a partir de /etc/rc) ; ils ne sarr etent en principe jamais (sauf bien s ur avec le syst` eme !). La conception dun daemon suit les r` egles suivantes : 1. Ex ecuter un fork, terminer lex ecution du p` ere et continuer celle du ls qui est alors adopt e par init (traditionnellement cest le processus N 1). Le processus ls est alors d etach e du terminal, ce que lon peut visualiser avec un ps -auxw (versus ps -edalf sur un syst` eme V) en examinant la colonne TT : elle contient ? ? ; 2. Appeler la primtive setsid pour que le processus courant devienne leader de groupe (il peut y avoir un seul processus dans un groupe) ; 3. Changer de r epertoire courant, g en eralement la racine (/) ou tout autre r epertoire ` a la convenance de lapplication ; 4. Modier le masque de cr eation des chiers umask = 0 pour que le troisi` eme argument de open ne soit pas biais e par la valeur du umask lorsque cette primitive sert aussi ` a cr eer des chiers ; 5. Fermer tous les descripteurs devenus inutiles, et en particulier 0, 1 et 2 (entr ee et sorties standards nont plus de sens pour un processus d etach e dun terminal). le source ci-apr` es est un exemple de programmation de daemon, les appels ` a la fonction syslog font r ef erence ` a un autre daemon nomm e syslogd que nous examinons au paragraphe suivant.
Si lon en croit la premi` ere edition de UNIX System Administration Handbook , Nemeth, Synder & Seebass, pp 403-404 :Many people equate the word daemon with the word demon implying some kind of Satanic connection between UNIX and the underworld. This is an egregious misunderstanding. Daemon is actually a much older form of demon ; daemons have no particular bias towards good or evil, but rather serve to help dene a persons character or personality.
10

316
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

ements sur les serveurs El

/* $Id: diable.c 92 20090212 17:39:44Z fla $ * * Diablotin : exemple de dmon miniature... */ #include #include #include #include #include #include #include <stdio.h> <stdlib.h> <unistd.h> <sys/types.h> <sys/stat.h> <syslog.h> <errno.h>

int main() { switch (fork()) { case 1 : perror("fork") ; exit (1) ;

/* erreur du "fork".

*/

case 0 : /* Le futur "demon". */ (void)printf("Je suis infernal, je me transforme en demon !\n") ; (void)setsid() ; /* Devenir chef de groupe. */ (void)chdir("/") ; /* Repertoire de travail. */ (void)umask(0) ; (void)close(0) ; (void)close(1) ; (void)close(2) ; openlog("diablotin",LOG_PID|LOG_NDELAY,LOG_USER) ; syslog(LOG_INFO,"Attention, je suis un vrai daemon...\n") ; (void)sleep(1) ; (void)syslog(LOG_INFO,"Je me tue !\n") ; closelog() ; exit(EX_OK) ; default : exit(EX_OK) ; } }

diable.c

3.2

Daemon syslogd

Du fait de leur fonctionnement d etach e dun terminal, les daemons ne peuvent plus d elivrer directement de message par les canaux habituels (perror. . .). Pour pallier ` a cette d ecience un daemon est sp ecialis e dans 11 l ecoute des autres daemons ( ecoute passive :), il sagit de syslogd . Pour dialoguer avec ce daemon un programme doit utiliser les fonctionnalit es que le lecteur trouvera tr` es bien d ecrites dans man syslog, sinon cu rapide. le paragraphe 3.4 en donne un aper La gure XIV.3 suivante sch ematise le circuit de linformation dans le cas dune utilisation de syslogd. Le chier /etc/syslog.conf est le chier standard de conguration du daemon syslogd. Il est constitu e de lignes de deux champs : un d eclencheur
11

Ce r ole strat egique lui vaut d etre lanc e le premier et d etre stopp e le dernier

Daemon syslogd (selector) et une action. Entre ces deux champs un nombre quelconque de tabulations.
processus 1 processus 2 processus 3

317

/dev/log syslogd distant (msg UDP)

Noyau

kill HUP cat /var/run/syslog.pid /etc/syslog.conf syslogd

/var/log/XXXX /dev/console

syslogd distant (msg UDP)

terminal utilisateur

gure XIV.03 Si les conditions du d eclencheur sont remplies laction est ex ecut ee, plus pr ecisement : Le d eclencheur est un ltre qui associe un type de daemon avec un niveau de message. Par exemple mail.debug signie les messages de niveau DEBUG pour le syst` eme de routage du courrier. Les mots clefs possibles pour le type de daemon sont auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp, et local0 ` a local7. Une etoile ( ) ` a la place, signie nimporte quel mot clef. Le niveau de message est lun des mots clefs suivants : emerg, alert, crit, err, warning, notice, et debug. Une etoile ( ) signie nimporte lequel. Un point () s epare les deux parties du ltre, comme dans mail.debug. Dans les syslog plus evolu es ladministrateur a la possibilit e de d erouter tous les messages contenant un nom de programme ( !nom du prog) ou un nom de machine (+nom de machine) Laction est soit : Un chier d esign e par un chemin absolu, comme /var/log/syslog. Une liste de logins dutilisateurs, comme root,fla. . . Un nom de machine distante (@machine.domaine.fr) Tous les utilisateurs connect es avec une etoile .

318

ements sur les serveurs El

3.3

Fichier syslog.conf
/dev/console /var/log/messages /var/log/maillog /var/log/lpd-errs /var/cron/log root root root * |/usr/local/bin/traitinfo /var/log/diablotin.log

Exemple de chier /etc/syslog.conf :

*.err;kern.debug;auth.notice;mail.crit *.notice;kern.debug;lpr,auth.info;mail.crit mail.info lpr.info cron.* *.err *.notice;auth.debug *.alert *.emerg *.info !diablotin *.*

R esultat de lex ecution de diablotin sur la machine glups, et dans le chier /var/log/diablotin.log :
... Jan 27 18:52:02 glups diablotin[20254]: Attention, je suis un vrai daemon... Jan 27 18:52:03 glups diablotin[20254]: Je me tue ! ...

3.4

Fonctions syslog

Les prototypes et arguments des fonctions : #include <syslog.h> void openlog(const char *ident, int logopt, int facility) ; void syslog(int priority, const char *message, ...) ; void closelog(void) ; Comme dans lexemple de diablotin , un programme commence par d eclarer son intention dutiliser le syst` eme de log en faisant appel ` a la fonction openlog : logopt Donne la possibilit e de pr eciser o` u le message est envoy es et dans quelle condition. facility Est l etiquette par d efaut des futurs messages envoy es par syslog. logopt LOG LOG LOG LOG CONS NDELAY PERROR PID description Ecriture sur /dev/console. Ouverture imm ediate de la connexion avec syslogd. Ecriture dun double du message sur stderr. Identier chaque message avec le pid.

Fonctions syslog facility LOG LOG LOG LOG LOG LOG LOG LOG LOG LOG LOG LOG AUTH AUTHPRIV CRON DAEMON KERN LPR MAIL NEWS SYSLOG USER UUCP LOCAL0 description Services dauthentication. Idem ci-dessus. Le daemon qui g` ere les proc edures batch. Tous les daemons du syst` eme, comme gated. Messages du noyau. Messages du gestionnaire dimprimante. Messages du gestionnaire de courrier. Messages du gestionnaire de news . Messages du daemon syslogd lui-m eme. Messages des processus utilisateur (defaut). Messages du syst` eme de transfert de chiers. R eserv e pour un usage local.

319

Puis chaque appel ` a la fonction syslog est compos e dun message (g en er e par lapplication) et dun code de priorit e, compos e dun niveau durgence pr ecis e par le tableau ci-dessous (niveaux d ecroissants) et dune etiquette optionnelle, prise dans le tableau ci-dessus ; elle prime alors sur celle pr ecis ee lors du openlog. priority LOG LOG LOG LOG LOG LOG LOG LOG EMERG ALERT CRIT ERR WARNING NOTICE INFO DEBUG description Une condition de panic system . Intervention imm ediate requise. Probl` emes de mat eriels Erreurs. Messages davertissement. Messages qui ne sont pas des erreurs. Informations sans cons equence. Messages pour le debug.

Enn le closelog mat erialise la n dutilisation de ce syst` eme dans le code.

320

ements sur les serveurs El

Exemple de daemon inetd

Dans cette partie nous allons etudier un serveur de serveurs nomm e inetd qui est un tr` es bel exemple pour conclure ce chapitre. Ce chapitre pourra se prolonger par la lecture du code source C dinetd.

4.1

Pr esentation de inetd

Sous Unix on peut imaginer facilement que chacun des services r eseaux oerts soient programm es comme un daemon, avec une ou plusieurs sockets, chacun surveillant son ou ses ports de communication. Un tel fonctionnement existe, g en eralement rep er e par le vocabulaire stand alone . Avec cette strat egie, chaque service comme ftp , rlogin , ou encore telnet fait lobjet dun processus daemon ( daemon ). Avant la version 4.3 de BSD, cest comme cela que tous les services fonctionnaient. Le probl` eme est que pour faire fonctionner les services de base du r eseau on devait maintenir en m emoire (primaire en ram ou secondaire sur la zone de swap ) un grand nombre de processus souvent compl` etement inutiles ` a un instant donn e, simplement au cas ou. . . Linconv enient de cette strat egie est la consommation importante de ressources surtout avec le nombre croissant des services r eseaux de base . De plus, on peut remarquer que lanc es au d emarrage de la machine, tous ces processus eectuent des op erations similaires (cf 3), seuls di` erent les traitements propres aux serveurs eux-m emes cest ` a dire ceux qui rel` event du protocole de lapplication. La version 4.3 de BSD a apport e une simplication en introduisant une nouvelle notion, celle de serveur de serveurs : The Internet superserver inetd . Cest un daemon que peuvent utiliser tous les serveurs TCP/UDP. Inetd fournit essentiellement deux services principaux : 1. Il permet ` a un seul processus (celui dinetd) dattendre de multiples demandes de connexions au lieu davoir 1 processus par type de connexion. Cette strat egie r eduit dautant le nombre de processus. 2. Il simplie l ecriture des serveurs eux-m emes, puisquil g` ere toute la prise en charge de la connexion. Les serveurs lisent les requ etes sur leur entr ee standard et ecrivent la r eponse sur leur sortie standard. Inetd est un serveur parall` ele en mode connect e ou data-gramme. De plus il combine des caract eristiques particuli` eres, puisquil est egalement multiprotocoles et multi-services. Un m eme service peut y etre enregistr e et accessible en udp comme en tcp. Bien s ur cela sous entend que le programmeur de ce service ait pr evu ce fonctionnement. Le prix ` a payer pour une telle souplesse est elev e, inetd invoque fork puis exec pour pratiquement tous les services quil ore (cf lecture de code). Sur les Unix ` a architecture Berkeley, inetd est invoqu e au d emarrage de la machine, dans les scripts de lancement, /etc/rc par exemple. D` es le d ebut de son ex ecution il se transforme en daemon (cf paragraphe IV.5.3) et lit un

Exemple de daemon inetd chier de conguration g en eralement nomm e /etc/inetd.conf. Ce chier est en ASCII, il est lisible normalement par tous, cependant, sur certains sites et pour des raisons de s ecurit e, il peut ne pas l etre. La gure XIV.04 montre larchitecture g en erale (tr` es simpli ee) de fonctionnement.

321

socket () Pour chaque services bind () listen () (socket TCP) select () accept() (socket TCP) fork () pre close () (socket TCP) fils close() descr. autres que la socket. dup () socket vers 0,1 et 2 close (socket) setgid () setuid () (si non root) exec () (du serveur) trouv dans /etc/inetd.conf

gure XIV.04 Le chier /etc/inetd.conf est organis e de la mani` ere suivante : Un # en d ebut de ligne indique un commentaire, comme pour un shellscript. Les lignes vides ne sont pas prises en compte. Les lignes bien form ees sont constitu ees de 7 champs. Chaque ligne bien form ee d ecrit un serveur. Description des champs : 1. Le nom du service, qui doit egalement se trouver dans le chier /etc/services. Cest gr ace ` a lui que inetd connait le num ero de port ` a employer 2. Le type de socket, connect ee (stream) ou non (dgram).

322

ements sur les serveurs El 3. Le protocole qui doit etre tcp ou udp et doit en tout cas se trouver dans le chier /etc/protocols. Ce dernier chier donne une correspondance num erique aux di erents protocoles. 4. wait ou nowait suivant que le serveur est it eratif ou parall` ele. 5. Le nom du propri etaire (pour les droits ` a lex ecution). Le plus souvent cest root, mais ce nest pas une r` egle g en erale. 6. Le chemin absolu pour d esigner lex ecutable du serveur. 7. Les arguments transmis ` a cet ex ecutable lors du exec, il y en a 20 au maximum dans les impl ementations Berkeley de inetd (certaines re- ecritures, comme celle dHP, limitent ce nombre).

Exemple de code serveur

Lexemple qui suit est le code en langage C dun serveur d echo multi protocoles, cest ` a dire qui fonctionne avec TCP et UDP simultan ement sur un m eme num ero de port pour les deux protocoles. La contrainte est que lusage du serveur pour lun des protocoles nemp eche pas lacc` es au serveur pour lautre procotole. Ce serveur ore egalement le choix de travailler en mode it eratif ou en mode parall` ele. Cette alternative est pilot ee ` a partir de la ligne de commande, donc au lancement du serveur (option -n ou -w). Il est int eressant de remarquer que le cur du serveur est construit autour de lusage de la primite select pour g erer l ecoute sur des sockets multiples, ici au nombre de deux. Dun point de vue plus g en eral ce serveur reprend larchitecture globale du serveur de serveur inetd mais le simpliant ` a lextr eme, cest ` a dire sans gestion du chier de conguration, et sans gestion des limites.

5.1

Guide de lecture du source serv2prot.c

Le source de cet exemple se trouve ` a lAnnexe A, page 367. Le programme serv2prot le lance avec les options suivantes : -p num ero du port -n mode concourant -w mode it eratif La fonction main (ligne 64 ` a 178) contient la structure principale du programme. Ligne 77 Boucle de lecture des arguments de la ligne de commande. Loption -p a besoin dun argument (le # de port) dont la lecture est effectu ee ligne 80 (usage de la fonction atoi pour transformer la cha ne de caract` eres en entier.

5 Exemple de code serveur Ligne 102 Ouverture dune socket UDP utilisant le port nport lu sur la ligne de commande Ligne 103 M eme chose que ligne 102 mais avec une socket TCP. Ligne 104 Cest le majorant de sudp et stcp (pour select). Ligne 106 Mise ` a z ero de tous les bits de la variable lect (fd set) Ligne 107 Ajout du descripteur udp Ligne 108 Ajout du description tcp Ligne 110 Mise en place de la prise en compte des signaux de type SIGCHLD. Cest la fonction PasDeZombi qui est appell ee. Ligne 111 Mise en place de la prise en compte du signal de n, ici un SIGHUP. Appel de la fonction FinCanonique dans ce cas. Ligne 113 Entr ee de la boucle principale et innie du serveur Ligne 114 Recopie dans alire des descripteurs ` a surveiller en lecture Ligne 116 Appel de la primitive select, sans time-out, donc bloquante ind eniment (cad jusqu` a larriv ee dune demande de cnx) Ligne 118 Si on arrive ` a cette ligne cest quun signal a interrompu la primitive. Le r esultat du test est VRAI si la primitive a et e interrompu par un signal (par exemple SIGCHLD), le continue permet de retourner ` a l evaluation de la condition de sortie de boucle imm ediatement. Sinon il sagit dune erreur non contournable, achage dun message et sortie. Ligne 124 select a renvoy e le nombre de descripteurs qui justient son retour en user land . Ce nombre est 1 ou 2 au maximum (seulement 2 sockets ` a surveiller). On boucle jusqu` a epuisement du nombre de descripteurs ` a examiner. Ligne 125 FD ISSET permet de tester si la socket stcp est active. Si oui alors on passe ` a la ligne 127... Ligne 127 Appel de accept pour la socket tcp. Il faut noter quon ne tient pas compter de ladresse du client r eseau (deuxi` eme et troisi` eme argument). sock contient le descripteur de la socket vers le client. Ligne 133 Idem que ligne 125 mais pour la socket UDP. Ligne 138 Usage de la primitive getpeername pour obtenir ladresse de la socket du client (adresse IP + num ero de port). Ligne 142 Usage des fonctions inet ntoa et ntohs pour acher ladresse IP et le port du client qui se connecte. Ligne 144 Il sagit dune etiquette, point dentr ee du goto qui se situe ligne 148. Ligne 145 On tente de lancer le service demand e, ` a ex ecuter dans un processus ls.

323

324

ements sur les serveurs El Ligne 147 En cas derreur, si le fork a et e interrompu par un signal, par exemple eaSIGCHLD, on eectue un saut inconditionnel ` a l etiquette retry signal ee ligne 144. Sinon cest une vraie erreur ` a traiter ! Ligne 151 Il sagit du code ex ecut e dans le processus ls. intcp==VRAI sil sagit de la socket TCP. Fermeture des sockets devenues inutiles (cest sock qui est utile). Ligne 155 Invocation la fonction qui g` ere l echo en TCP Ligne 158 Fermeture de la socket TCP inutile. La socket UDP est indispensable. Ligne 159 Invocation de la fonction qui g` ere l echo en UDP Ligne 161 Sortie du code pour les processus ls Ligne 162 Il sagit du code ex ecut e dans le processus p` ere. Si le mode de fonctionnement est it eratif la socket en question (TCP vs UDP) doit etre retir ee des descripteurs ` a surveiller. Elle y sera remise lorsque le processus ls qui traite la session en cours sera termin e (cf fonction PasDeZombi ligne 184). Ligne 165 Si on vient de traiter la socket TCP on fait le m enage avant la prochaine boucle : fermeture de sock devenu inutile, retrait de stcp de alire et conservation dune trace du pid. Ligne 175 on d ecr emente le nombre de descripteurs ` a examiner. Ligne 177 Fin de la boucle principale commenc ee ligne 124. Ligne 171 Conservation du pid du ls UDP et suppression de sudp de alire. La fonction PasDeZombi est le handler pour les signaux de type SIGCHLD, envoy es par le noyau au processus p` ere d` es que lun de ses ls fait exit. Ligne 194 Usage de la primitive wait3 qui permet de faire une attente non bloquante (cest justi e dans la mesure o` u on a re cu un SIGCHLD) de la mort dun ls. Chaque appel renvoie le pid dun processus ls mort, sil ny a plus de processus ls mort ` a examiner le retour est n egatif. Cest la condition de sortie de boucle. Ligne 195 Si on entre dans ce test, la variable pid contient le pid du ls termin e et le mode de fonctionnement est it eratif. Ligne 197 Pour la socket TCP on remet stcp dans les descripteurs ` a surveiller Ligne 202 Pour la socket UDP on remet sudp dans les descripteurs ` a surveiller Ligne 207 Certains OS ont besoin que lon repositionne le handler de signaux ` a chaque r eception du signal. Ce nest pas le cas des BSD. Ligne 215 FinCanonique est appell ee sur r eception du signal de n SIGHUP. Cest la sortie inconditionnelle du programme.

6 Bibliographie Les fonctions OuvrirSocketUDP et OuvrirSocketTCP sont une reformulation de ce qui a d ej` a et e examin e pr ec edemment. Les fonctions TraiterTCP et TraiterUDP ne pr esentent pas de dicult e de lecture.

325

Bibliographie

Pour la partie architecture/conguration des serveurs : W. Richard Stevens Unix Network Programming Prentice All 1990 W. Richard Stevens Unix Network Programming Volume 1 & 2 Second edition Prentice All 1998 W. Richard Stevens Advanced Programming in the UNIX Environment AddisonWesley 1992 W. Richard Stevens Bill Fenner Andrew M. Rudo Unix Network Programming Third edition, volume 1 Prentice All 2004 Douglas E. Comer David L. Stevens Internetworking with TCP/IP Volume III (BSD Socket version) Prentice All 1993 Stephen A. Rago Unix System V Network Programming AddisonWesley 1993 Man Unix de inetd, syslog, syslogd et syslog.conf. Pour la programmation des threads : David R. Butenhof Programming with POSIX Threads AddisonWesley 1997 Bradford Nichols, Dirsk Buttlar & Jacqueline Proulx Farell Pthreads programming OReilly & Associates, Inc. 1996 Et pour aller plus loin dans la compr ehension des m ecanismes internes : McKusick, Bostik, Karels, Quaterman The Design and implementation of the 4.4 BSD Operating System Addison Wesley 1996 Jim Mauro, Richard McDougall Solaris Internals Sun Microsystems Press 2001 Uresh Vahalia Unix Internals, the new frontiers Prentice Hall 1996

326

ements sur les serveurs El

Chapitre XV Anatomie dun serveur Web

1 Le protocole HTTP

ATTENTION CE CHAPITRE NA PAS FAIT LOBJET DUNE REVISION DEPUIS DE NOMBREUSES ANNEES. LES INFORMATIONS CONTENUES Y SONT JUSTES MAIS PAS` SABLEMENT OBSOLETES ! Ce document est une pr esentation succincte du protocole HTTP 1.0 et du serveur Apache qui lutilise. Le protocole HTTP1 est le protocole dapplication utilis e pour v ehiculer, entres autres, de lHTML2 sur lInternet. Cest le protocole le plus utilis e en volume depuis 1995, devant FTP, NNTP et SMTP ; il accompagne lexplosion de lutilisation du syst` eme global dinformation WorldWide Web. Depuis 1990, date dapparition du Web, le protocole HTTP evolue doucement mais surement. Il est longtemps rest e sous forme de draft. La premi` ere version d eploy ee largement a et e la 1.0, d enie dans la RFC 1945 de mai 1996. Depuis le d ebut du mois de janvier 1997 est apparue la version 1.1, deux fois plus volumineuse pour tenir compte des nouvelles orientations de lusage du service. Aujourdhui ce protocole est tellement r epandu que pour bon nombre de nouveaux utilisateurs du r eseau, lInternet cest le web ! Techniquement, lusage de ce protocole se con coit comme une relation entre un client et un serveur. Le client, appel e g en eriquement un browser, un User Agent, ou encore butineur de toile, interroge un serveur connu par ecrite dans la RFC 1738. son url3 dont la syntaxe est bien d Par exemple la cha ne de caract` eres http://www.sio.ecp.fr/ est une url ; il sut de la transmettre en tant quargument ` a un quelconque outil dexploration et celui-ci vous renverra (si tout se passe comme pr evu !) ce qui est pr evu sur le serveur en question pour r epondre ` a cette demande (car il sagit bien dune requ ete comme nous le verrons plus loin dans ce chapitre).
Hypertext Transfer Protocol Hypertext Markup Language Consulter les technical reports and publications du site : http://www.w3.org/pub/WWW/TR/ 3 Uniform Resource Locator
2 1

328

Anatomie dun serveur Web Le serveur, suppos e` a l ecoute du r eseau au moment o` u la partie cliente linterroge, utilise un port connu ` a lavance. Le port 80 est d edi e ociellement 4 au protocole http , mais ce nest pas une obligation (cette d ecision est prise ` a la conguration du serveur). Lurl qui d esigne un serveur peut contenir dans sa syntaxe le num ero de port sur lequel il faut linterroger, comme dans : http://www.sio.ecp.fr:11235/.

1.1

Exemple d echange avec http

Le transport des octets est assur e par TCP5 et le protocole est human readable, ce qui nous autorise des essais de connexion avec le client tcp ` a tout faire : telnet ! Bien entendu on pourrait utiliser un browser plus classique, mais celui-ci g erant pour nous le d etail des echanges il ne serait plus possible de les examiner.
$ telnet localhost 80 Trying... Connected to localhost. Escape character is ^]. GET / HTTP/1.0

Ce qui est tap e par lutilisateur et la r eponse du serveur.

La requ ete, suivie dune ligne vide. HTTP/1.1 200 OK Enn la r eponse du serveur, Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix) que lon peut d ecomposer en Last-Modified: Sat, 10 Nov 2001 16:13:02 trois GMT parties :
ETag: "1381-8b-3bed520e" Accept-Ranges: bytes Content-Length: 79 Connection: close Content-Type: text/html

1. Un code (HTTP)

de

retour

2. Un en-t ete MIME 3. Des octets, ici ceux dune page ecrite en HTML. Notons egalement la deconnexion ` a linitiative du serveur, en n denvoi de la page HTML.

<HTML> <HEAD> <TITLE>Ceci est un titre</TITLE> </HEAD> <BODY> </BODY> </HTML> Connection closed by foreign host.

1.2

Structure dun echange

Lexemple qui pr ec` ede est typique dun echange entre le client et le serveur : une question du client g en` ere une r eponse du serveur, le tout lors dune connexion TCP qui se termine lors de lenvoi du dernier octet de la r eponse (cl oture ` a linitiative du serveur).
4 5

http://www.iana.org/assignments/port-numbers page 89

Le protocole HTTP Le serveur ne conserve pas la m emoire des echanges pass es, on dit aussi quil est sans etat, ou stateless. La question et la r eponse sont b aties sur un mod` ele voisin : le message HTTP.
Message HTTP

329

B
Dbut du message

D C

gure XV.01 Les parties A, B et C forment len-t ete du message, et D le corps. A La premi` ere ligne du message, est soit la question pos ee (request-line), soit le statut de la r eponse (status-line). La question est une ligne termin ee par CRLF, elle se compose de trois champs : Une m ethode ` a prendre dans GET, HEAD, ou POST. GET Plus de 99% des requ etes ont cette m ethode, elle retourne linformation demand ee dans lURL (ci-dessous). HEAD La m eme chose que GET, mais seul len-t ete du serveur est envoy e. Utile pour faire des tests daccessibilit e sans surcharger la bande passante. Utile egalement pour v erier de la date de fraicheur dun document (information contenue dans len-t ete). POST Cette m ethode permet denvoyer de linformation au serveur, cest typiquement le contenu dun formulaire rempli par lutilisateur. Une ressource que lon d esigne par une URL6 . Par exemple http://www.site.org/. La version du protocole , sous forme HTTP-Num ero de version. Par exemple HTTP/1.1 ! La r eponse. Cette premi` ere ligne nest que le statut de la r eponse, les octets qui la d etaillent se trouvent plus loin, dans le corps du message. Trois champs la composent, elle se termine par CRLF : La version du protocole , sous forme HTTP-Num ero de version, comme pour la question.
6

Uniform Resource Locator, consulter la RFC 1630

330

Anatomie dun serveur Web Statut Cest une valeur num erique qui d ecrit le statut de la r eponse. Le premier des trois digits donne le sens g en eral : 1xx 2xx 3xx 4xx 5xx Nest pas utilis e Futur Use Succ` es, laction demand ee a et e comprise et ex ecut ee correctement. Redirection. La partie cliente doit reprendre linterrogation, avec une autre formulation. Erreur cot e client. La question comporte une erreur de syntaxe ou ne peut etre accept ee. Erreur cot e serveur. Il peut sagir dune erreur interne, due ` a lOS ou ` a la ressource devenue non accessible.

Phrase Cest un petit commentaire (Reason- Phrase) qui accompagne le statut, par exemple le statut 200 est suivi g en eralement du commentaire OK ! B Cest une partie optionnelle, qui contient des informations ` a propos du corps du message. Sa syntaxe est proche de celle employ ee dans le courrier electronique, et pour cause, elle repecte aussi le standard MIME7 . Un en-t ete de ce type est constitu e dune suite dune ou plusieurs lignes (la n dune ligne est le marqueur CRLF) construite sur le mod` ele : Nom de champ : Valeur du champ CRLF Eventuellement le marqueur de n de ligne peut etre omis pour le s eparateur ;. Exemple den-t ete MIME :
Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix) Last-Modified: Sat, 10 Nov 2001 16:13:02 GMT ETag: "1381-8b-3bed520e" Accept-Ranges: bytes Content-Length: 79 Connection: close Content-Type: text/html

Date : Cest la date ` a laquelle le message a et e envoy e. Bien s ur il sagit de la date du serveur, il peut exister un d ecalage incoh erent si les machines ne sont pas synchronis ees (par exemple avec XNTP). Server : Contient une information relative au serveur qui a fabriqu e la r eponse. En g en erale la liste des outils logiciels et leur version. Content-type : Ce champ permet didentier les octets du corps du message. Content-length : D esigne la taille (en octets) du corps du message, cest ` a dire la partie D de la gure XV.1.
7

Multipurpose Internet Mail Extension, consulter la RFC 1521

Le protocole HTTP Last-modified : Il sagit de la date de derni` ere modication du chier demand e, comme lillustre le r esultat de la commande ll (voir aussi la co ncidence de la taille du chier et la valeur du champ pr ec edent).
-rw-r--r-1 web doc 139 Nov 10 17:13 index.html

331

ETag : Cest un identicateur du serveur, constant lors des echanges. Cest un moyen de maintenir le dialogue avec un serveur en particulier, par exemple quand ceux-ci sont en grappe pour equilibrer la charge et assurer la redondance. C Une ligne vide (CRLF) qui est le marqueur de n den-t ete. Il est donc absolument obligatoire quelle gure dans le message. Son absence entraine une incapacit e de traitement du message, par le serveur ou par le client. D Le corps du message. Il est omis dans certains cas, comme une requ ete avec la m ethode GET ou une r eponse ` a une requ ete avec la m ethode HEAD. Cest dans cette partie du message que lon trouve par exemple les octets de lHTML, ou encore ceux dune image. . . Le type des octets est intimement li e ` a celui annonc e dans len-t ete, plus pr ecisement dans le champ Content-Type. Par exemple : Content-Type : text/html = Le corps du message contient des octets ` a interpr eter comme ceux dune page ecrite en HTML. Content-Type : image/jpg = Le corps du message contient des octets ` a interpr eter comme ceux dune image au format jpeg

332

Anatomie dun serveur Web

URIs et URLs

Le succ` es du web sappuie largement sur un syst` eme de nommage des objets accessibles, qui en uniformise lacc` es, quils appartiennent ` a la machine sur laquelle on travaille ou distants sur une machine en un point quelconque du r eseau (mais suppos e accessible). Ce syst` eme de nommage universel est lurl (Uniform Resource Locator RFC 1738) d eriv e dun syst` eme de nommage plus g en eral nomm e uri (Universal Resource Identier RFC 1630). La syntaxe g en erale dun(e) url est de la forme : <scheme> :<scheme-specic-part> Succintement la scheme est une m ethode que lon s epare ` a laide du caract` ere : dune cha ne de caract` eres ascii 7 bits dont la structure est essentiellement fonction de la scheme qui pr ec` ede et que lon peut imaginer comme un argument. Une scheme est une s equence de caract` eres 7bits. Les lettres a ` a z, les chires de 0 ` a 9, le signe +, le . et le - sont admis. Majuscules et minuscules sont indi erenci es. Exemples de schemes : http, ftp, le, mailto, . . .Il en existe dautres (cf la RFC) non indispensables pour la compr ehension de cet expos e. 8 Globalement une url doit etre encod ee en ascii 7 bits sans caract` ere de contr ole (cest ` a dire entre les caract` eres 20 et 7F), ce qui a comme cons equence que tous les autres caract` eres doivent etre encod es. La m ethode dencodage transforme tout caract` ere non utilisable directement en un triplet form e du caract` ere % et de deux caract` eres qui en repr esente la valeur hexad ecimale. Par exemple lespace (20 hex) doit etre cod e %20. Un certain nombre de caract` eres, bien que th eoriquement repr esentables, sont consid er es comme non s urs (unsafe) et devraient etre egalement encod es de la m eme mani` ere que ci-dessus, ce sont : % < > " # { } | \ ^ ~ [ ] Pour un certain nombre de schemes (http. . .) certains caract` eres sont r eserv es car ils ont une signication particuli` ere. Ce sont : ; / ? : @ = & Ainsi, sils apparaissent dans lurl sans faire partie de sa syntaxe, ils doivent etre encod es.

2.1
8

Scheme http

Une url avec la scheme http bien form ee doit etre de la forme :
man ascii sur toute machine unix

URIs et URLs http://$<$host$>$:$<$port$>$/$<$path$>$?$<$searchpath$>$ path et searchpath sont optionnels. host Cest un nom de machine ou une adresse IP. port Le num ero de port. Sil nest pas pr ecis e, la valeur 80 est prise par d efaut. path Cest un s electeur au sens du protocole http. searchpath Cest ce que lon appelle la query string, autrement dit la cha ne dinterrogation. ` lint A erieur de ces deux composantes, les caract` eres / ; ? sont r eserv es, ce qui signie que sils doivent etre employ es, ils doivent etre encod es pour eviter les ambigu t es. ` Le ? marque la limite entre lobjet interrogeable et la query string. A lint erieur de cette cha ne dinterrogation le caract` ere + est admis comme raccourci pour lespace (ascii 20 hex). Il doit donc etre encod e sil doit etre utilis e en tant que tel. De m eme, ` a lint erieur de la query string le caract` ere = marque la s eparation entre variable et valeur, le & marque la s eparation entre les couples variable = valeur. Exemple r ecapitulatif :
http://www.google.fr/search?q=cours+r%E9seaux\&hl=fr\&start=10\&sa=N

333

Notez le e cod e %E9, cest ` a dire le caract` ere de rang 14 16+9 = 233. On peut egalement observer quatre variables q, hl, start et sa dont la signication peut etre partiellement devin ee, mais dont le remplissage reste ` a la charge du serveur en question. Le r ole de la cha ne search est celui de ce que lon appelle une CGI ou Common Gateway Interface, cest ` a dire un programme qui eectue le lien entre le serveur interrog e et des programmes dapplication, ici une recherche dans une base de donn ees. Nous examinons succinctement le principe de fonctionnement de tels programmes page 347.

334

Anatomie dun serveur Web

Architecture interne du serveur Apache

Cette partie se consacre ` a l etude du fonctionnement du serveur Apache9 . Pour comprendre les m ecanismes internes dun tel serveur il est absolument n ecessaire de pouvoir en lire le code source, cette contrainte exclu les produits commerciaux. Au mois de mars 2002, dapr` es le Netcraft Web Server Survey10 le serveur le plus utilis e (55%) est tr` es majoritairement celui du projet Apache. Dapr` es ses auteurs, le serveur Apache est une solution de continuit e au serveur du NCSA11 . Il corrige des bugs et ajoute de nombreuses fonctionnalit es, particul` erement un m ecanisme dAPI pour permettre aux administrateurs de sites de d evelopper de nouveaux modules adapt es ` a leurs besoins propres. Plus g en eralement, tout ce qui nest pas strictement dans les attributions du serveur (gestion des processus, gestion m emoire, gestion du r eseau) est trait e comme un module dextension. Le chier apache 1.3.23/htdocs/manual/misc/API.html de la distribution standard apporte des pr ecisions, le serveur http://www.apacheweek.com/ pointe egalement sur grand nombre de documents tr` es utiles. Le serveur Apache introduit egalement la possibilit e de serveurs multidomaines (domaines virtuels), ce qui est fort appr eci e des h ebergeurs de sites.

3.1

Environnement dutilisation

La gure XV.2 qui suit, synth etise lenvironnement dutilisation.

SIGTERM SIGHUP

Serveur HTTPD
Accs clients HTTP

httpd.pid

access_log

error_log srm.conf httpd.conf access.conf

Arborescence des fichiers accessibles

Apache HTTP server project, http://www.apache.org, http://www.apacheweek. com/ est egalement une source int eressante dinformations 10 http://www.netcraft.com/survey/ 11 National Center for Supercomputing Applications Universit e de lIllinois, aux Etats Unis

Architecture interne du serveur Apache Le serveur se met en uvre simplement. La compilation fournit un ex ecutable, httpd, qui, pour sex ecuter correctement, a besoin des trois chiers ASCII de conguration : srm.conf, access.conf, httpd.conf. Cest en fait dans celui-ci que sont eectu es lessentiel des ajustements locaux ` a la conguration standard. Lors de lex ecution, trois chiers sont modi es12 : httpd.pid (PidFile) contient le process ID du leader de groupe ; ` a utiliser avec le signal SIGHUP (cf gure XV.2) pour provoquer la relecture et le re-d emarrage ` a chaud du serveur, ou avec SIGTERM pour mettre n ` a son activit e. access log (CustomLog) Qui contient le d etail des acc` es clients. Ce chier peut devenir tr` es volumineux. error log (ErrorLog) Qui contient le d etail des acc` es infructueux et des eventuels probl` emes de fonctionnement du serveur. Le daemon httpd est soit du type (ServerType) standalone ou si son invocation est occasionnelle, ` a la demande pilot e par inetd (cf page 4). Il d emarre son activit e par ouvrir le port (Port) d esign e dans la conguration, puis sex ecute avec les droits de lutilisateur User et du groupe Group. Sa conguration se trouve dans le r epertoire conf sous-r epertoire de ServerRoot. Les chiers accessibles par les connexions clientes, eux, se situent dans le r epertoire DocumentRoot qui en est la racine, cest ` a dire vue comme / par les browsers clients. Le chier httpd.pid contient un num ero de processus leader de groupe car en fait le serveur Apache, d` es son initialisation, d emarre un certain nombre de processus, autant de serveurs capables de comprendre les requ etes des clients. En voici un exemple : MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxClients 150 Cest le nombre minimum dinstances du serveur (non compris le processus ma tre) en attente dune connexion. Sil en manque, elles sont cr e ees. Cest le nombre maximum dinstances du serveur (non compris le processus ma tre) en attente dune connexion. Sil y en a de trop elles sont supprim ees. Cest le nombre minimum dinstances du serveur (non compris le processus ma tre) au d emarrage. Cest le nombre maximum de clients (requ etes HTTP) simultan es. Cette constante peut etre augment ee en fonction de la puissance de la machine.

335

Un processus joue le r ole de r egulateur, du point de vue Unix cest un processus chef de groupe (leader). La commande ps permet de visualiser une situation op erationnelle :
Entre parenth` eses le nom de la variable du le chier httpd.conf qui permet den modier le chemin
12

336
web root web web web web web web web web 17361 2794 17363 17270 17362 17401 17313 17312 17355 17314 2794 1 2794 2794 2794 2794 2794 2794 2794 2794 0 0 0 0 0 0 0 0 0 0 Mar Feb Mar Mar Mar Mar Mar Mar Mar Mar 13 23 13 13 13 13 13 13 13 13 ? ? ? ? ? ? ? ? ? ? 0:00 0:06 0:00 0:01 0:00 0:00 0:00 0:01 0:00 0:01

Anatomie dun serveur Web

/usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd -d -d -d -d -d -d -d -d -d -d /users/web /users/web /users/web /users/web /users/web /users/web /users/web /users/web /users/web /users/web

Ici il y a 9 instances du serveurs et le processus ma tre, quil est ais e de reconnaitre (2794) car il est le p` ere des autres processus (ce qui nimplique pas quil en est le chef de groupe, mais la suite de lanalyse nous le conrmera). La commande netstat -f inet -a | grep http ne donne quune ligne :
tcp 0 0 *.http *.* LISTEN

Cela signie quaucune connexion nest en cours sur ce serveur, et quune seule socket est en apparence ` a l ecoute du r eseau. Cest une situation qui peut sembler paradoxale eu egard au nombre de processus ci-dessus, le code nous fournira une explication au paragraphe suivant. La commande tail -1 logs/access.log fournit la trace de la derni` ere requ ete :
www.chezmoi.tld - - [01/Mar/2002:17:13:28 +0100] "GET / HTTP/1.0" 200 79

Il sagit de la trace de notre exemple dinterrogation du d ebut de ce chapitre !

3.2

Architecture interne

Attention, ce paragraphe concerne la version 1.1.1 du logiciel. Le fonctionnement de la version courante, 1.3.23, reste similaire mais le code ayant beaucoup chang e, les num eros de lignes sont devenus de fait compl` etement faux.

Ce qui nous int eresse plus particuli` erement pour expliquer le fonctionnement du serveur se trouve dans le r epertoire src/, sous r epertoire du r epertoire principal de la distribution :
$ ll apache_1.1.1/ total 19 -rw------- 1 fla -rw------- 1 fla -rw------- 1 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla

users users users users users users users users users users

3738 2604 3059 512 512 512 2048 512 2048 512

Mar 12 1996 CHANGES Feb 22 1996 LICENSE Jul 3 1996 README Feb 7 22:14 cgi-bin Feb 7 22:14 conf Feb 7 22:14 htdocs Feb 7 22:14 icons Jul 8 1996 logs Mar 12 10:42 src Feb 7 22:15 support

Architecture interne du serveur Apache Dans ce r epertoire qui compte au moins 75 chier (wc -l *.[ch] 27441 lignes) nous nous restreignons aux chiers essentiels d ecrits dans le README soit encore une petite dizaine dentres eux (wc -l 6821 lignes) : mod cgi.c, http protocol.c, http request.c, http core.c, http config.c, http log.c, http main.c, alloc.c Dans un premier temps nous allons examiner le fonctionnement de la gestion des processus, du mode de relation entre le p` ere et ses ls. Puis, dans un autre paragraphe, nous examinerons plus particuli` erement ce qui se passe lors dune connexion, avec le cas particulier de lex ecution 13 dune CGI qui comme son nom lindique est le programme qui eectue linterface entre le serveur HTTP et un programme dapplication quelconque. Dans la suite de ce document le terme cgi employ e seul d esigne ce type dapplication. 3.2.1 Gestion des processus

337

Au commencement est le main, et celui-ci se trouve dans le chier http main.c, comme il se doit ! ... 1035 1036 ... 1472 1473 1474 ... 1491 1492 1493 ... pool *pconf; /* Pool for config stuff */ pool *ptrans; /* Pool for per-transaction stuff */ ... int main(int argc, char *argv[]) { ... init_alloc(); pconf = permanent_pool; ptrans = make_sub_pool(pconf);

La fonction init alloc appelle make sub pool qui initialise un int eressant m ecanisme de buers cha n es, utilis e tout au long du code d` es lors quil y a besoin dallouer de la m emoire. ... 1523 ... setup_prelinked_modules();

Les di erents modules du serveurs sont ajout es dans une liste cha n ee. 1524 1525 1526 1527 1528
13

server_conf = read_config (pconf, ptrans, server_confname); if(standalone) { clear_pool (pconf);

/* standalone_main rereads... */

Common Gateway Interface

338 1529 1530 1531 ... 1580 1581 1582 }

Anatomie dun serveur Web standalone_main(argc, argv); } else { ... } exit (0);

Standalone est ` a 0 si le serveur est invoqu e depuis inetd 14 . Son mode de fonctionnement le plus ecace reste avec ce param` etre ` a 1 (voir le cours sur inetd), que nous supposons ici. La fonction standalone main (ligne 1362) pr epare le processus ` a son futur r ole de serveur. Pour bien comprendre le cette fonction, il faut imaginer quelle est invoqu ee au d emarrage, et ` a chaud, pour lire et relire la conguration. Ligne 1369 , la variable one process = 0 (sinon le processus est en mode debug) occasionne lappel ` a la fonction detach (ligne 876). Celle-ci transforme le processus en leader de groupe avec la succession bien connue fork + setsid (pour plus de d etails, voir le cours sur les daemons). Ligne 1374 , la fonction sigsetjmp enregistre la position de la pile et l etat du masque dinterruption (deuxi` eme argument non nul) dans erieur ` a siglongjmp forcera la reprise restart buffer. Tout appel ult de lex ecution en cette ligne. Ligne 1377 On ignore tout signal de type SIGHUP, cela bloque toute tentative cumulative de relecture de la conguration. Ligne 1382 (one process = 0) on envoie un signal SIGHUP ` a tous les processus du groupe. Cette disposition nest utile que dans le cas dun re-d emarrage ` a chaud. La variable pgrp est initialis ee par la fonction detach (ligne 876), elle contient le PID du chef de groupe. Lint eret davoir un groupe de processus est que le signal envoy e` a son leader est automatiquement envoy e` a tous les processus y appartenant. Chaque processus qui re coit ce signal, sil est en mesure de le traiter, ecute un exit(0) (ligne 943). Donc appelle la fonction just die qui ex tous les ls meurent, sauf le chef de groupe. Ligne 1390 , lappel ` a la fonction reclaim child processes() eectue autant de wait quil y avait de processus ls, pour eviter les zombis. Ligne 1398 Relecture des chiers de conguration. Ligne 1400 set group privs (ligne 960) change le user id et le group id si ceux-ci ont et e modi es.
Cette alternative est d ecid ee dans le chier httpd.conf, conguration du param` etre ServerType
14

Architecture interne du serveur Apache Ligne 1401 accept mutex init (ligne 166) fabrique un chier temporaire (/usr/tmp/htlock.XXXXXX), louvre, r eduit son nombre de lien ` a 0, de telle sorte quil sera supprim e d` es la n du processus. Ce chier est le verrou dacc` es ` a la socket principale, comme nous lexaminerons un peu plus loin. Ligne 1402 reinit scoreboard (ligne 596) Cette fonction remet ` a z ero, ou cr ee (setup shared mem ligne 432) la zone de m emoire commune entre le chef de groupe et ses processus ls. Cette zone m emoire est, soit un segment de m emoire partag ee (IPC du syst` eme V), soit de la m emoire rendue commune par un appel ` a la primitive mmap (Le choix est eectu e par configure qui analyse les possibilit es du syst` eme, avant compilation du serveur). La taille de cette zone est de HARD SERVER LIMIT sizeof(short score) octets, la structure short score, d enie dans scoreboard.h, recueille les statistiques dutilisation de chaque serveur et son statut (par exemple SERVER READY, SERVER DEAD. . .). Cest par ce moyen que le serveur ma tre contr ole les serveurs ls. HARD SERVER LIMIT d enit le nombre maximum de connexions actives, donc dinstances de serveur, ` a un instant donn e. En standard cette valeur est 150, elle peut etre augment ee dans le chier de conguration httpd.conf (voir ci-dessus au paragraphe II.1) Enn la gure XV.4 montre son r ole strat egique. Ligne 1413 (on suppose listeners = NULL), apr` es avoir initialis e une structure dadresse, appel ` a la fonction make sock (ligne 1298). Celleci cr ee et initialise une socket, et, d etail important, appelle par deux fois setsockopt, ce qui m erite un commentaire : ... 1312 1313 ... 1318 1319 ...

339

... if((setsockopt(s, SOL_SOCKET,SO_REUSEADDR,(char *)&one,sizeof(one))) == -1) { ... if((setsockopt(s, SOL_SOCKET,SO_KEEPALIVE,(char *)&keepalive_value, sizeof(keepalive_value))) == -1) { ...

SO REUSEADDR Indique que la r` egle dexclusivit e suivie par bind(2) pour lattribution dun port ne sapplique plus : un processus peut se servir dun m eme port pour plusieurs usages di erents (comme par exemple le client ftp qui attaque les port 21 et 20 du serveur avec le m eme port local), voire m eme des processus di erents (cest le cas ici) peuvent faire un bind avec le m eme port sans rencontrer la fatidique erreur 48 (Address already in use) ! Vue des clients HTTP, le serveur est accessible uniquement sur le port 80, ce que nous avons remarqu e au paragraphe II.1 (netstat) sans lexpliquer, voila qui est fait !

340

Anatomie dun serveur Web SO KEEPALIVE Indique ` a la couche de transport, ici TCP, quelle doit emettre ` a interval r egulier (non congurable) un message ` a destination de la socket distante. Que celle-ci ny r eponde pas et la prochaine tentative d ecriture sur la socket se solde par la r eception dun SIGPIPE, indiquant la disparition de la socket distante (voir plus loin la gestion de ce signal dans la fonction child main, ligne 1139). Ligne 1430 set signals (1007) pr evoit le comportement lors de la r eception des signaux : SIGHUP SIGTERM Appel de restart Appel de sig term

Ligne 1438 et la suivante, cr eation dautant de processus ls quil en est demand e dans le chier de conguration (StartServers). La fonction make child (1275) appelle fork, puis dans le ls modie le comportement face aux signaux SIGHUP et SIGTERM (just die appelle exit) avant dex ecuter child main.
main ()

standalone_main ()

Pour chaque fils demand Processus esclaves make_child () Processus maitre

child_main ()

Boucle infinie

accept () wait || make_child

read_request () process_request ()

gure XV.03 Arriv es ` a ce stade, il nous faut analyser lattitude des deux types de processus. Le processus ma tre Ligne 1444 d emarre une boucle innie de surveillance. Seule la r eception et le traitement dun signal peut linterrompre.

Architecture interne du serveur Apache Ligne 1458 Ici, si le nombre de serveurs disponibles est inf erieur au nombre minimal requis, il y reg en eration de ceux qui manquent avec la fonction make child

341

Les processus esclaves Ligne 1139 La gestion de ces processus, autant de serveurs Web op erationnels, d ebute avec lappel de la fonction child main. Ligne 1167 D ebut de la boucle innie qui g` ere cette instance du serveur. Au cours dune boucle le serveur g` ere lacceptation dune requ ete et son traitement. Ligne 1174 Gestion du SIGPIPE donc des clients qui d econnectent avant lheure ! Ligne 1180 Si le nombre de serveurs libres (count idle servers) est sup erieur ` a la limite congur ee, ou si Ligne 1182 le nombre de requ etes trait ees par ce processus a atteint la limite max requests per child, le processus sarr ete de lui-m eme. Cest lauto-r egulation pour lib erer des ressources occup ees par un trop grand nombre de processus serveurs inutiles. Ligne 1190 Lappel ` a la fonction accept mutex on v erouille lacc` es ` a la ressource d enie pr ec edement avec accept mutex init (ligne 166). Ce v erouillage est bloquant et exclusif. Cest ` a dire quil faut quun autre processus en d ev erouille lacc` es pour que le premier processus sur la liste dattente (g er ee par le noyau Unix) y acc` ede. Ce fonctionnement est assur e suivant la version dUnix par la primitive flock ou par la primitive fcntl. Les s emaphore du Syst` eme V (semget, semctl, semop. . .) assurent la m eme fonctionnalit e, en plus complet, ils sont aussi plus complexes ` a mettre en uvre. Cette op eration est ` a rapprocher de loption SO REUSEADDR prise ligne 1312. Il faut eviter que plusieurs processus serveurs disponibles ne r epondent ` a la requ ete. Il ny a quun seul processus pr et ` a r epondre ` a la fois et d` es que le accept (ligne 1217) retourne dans le code utilisateur la ressource est d ev erouill ee (on suppose toujours listeners = 0). Ligne 1221 La fonction accept mutex off d ev erouille lacc` es ` a la socket. Ligne 1245 read request lit la requ ete du client, donc un message HTTP. Ligne 1247 process request fabrique la r eponse au client, donc un autre message HTTP.

342

Anatomie dun serveur Web

Maitre

HARD_SERVER_LIMIT score_board

Accs la socket

httpd

httpd

... ...

httpd

MaxClients

gure XV.04 3.2.2 Prise en main des requ etes

Le chier concern e par la lecture de la requ ete est http protocol.c. La lecture de la premi` ere ligne du message HTTP est assur ee par la 15 fonction read request line, ligne 329 . La lecture de len-t ete MIME est assur ee par la fonction get mime headers, ligne 356. Attention, seule len-t ete lue le corps du message dans le cas de a m ethode POST est lu plus tard, lors du traitement du message, par le programme dapplication (CGI). Le chier concern e par la formulation de la r eponse est http request.c et la fonction principale process request, ligne 772. Celle-ci appelle en cascade process request internal, ligne 684. Cette derni` ere eectue un certain nombre de tests avant de traiter eectivement la requ ete. Parmi ceux-ci on peut relever, Ligne 716 La fonction unescape url (util.c, ligne 593) assure le d ecodage des caract` eres r eserv es et transcod es comme il est sp eci e par la RFC 1738. Ligne 723 La fonction getparents ltre les chemins (pathname) qui pr etent ` a confusion. Ligne 768 La fonction invoke handler est le point dentr ee dans le traitement de la requ ete. Cette fonction (http config.c, ligne 267) invoque le programme (module) qui se charge de fabriquer la r eponse, au vue ete. Si celui est inexisdu contenu du champ content type de la requ tant, comme dans notre exemple du paragraphe I, il est positionn e par d efaut ` a la valeur html/text.
15

La m ethode, lURL, et le protocole demand e

Architecture interne du serveur Apache 3.2.3 Deux types de CGIs

343

Pour la suite nous supposons que la prise en main de la requ ete est faite par le module cgi, d eni dans le chier mod cgi.c. Le point dentr ee est la fonction cgi handler (ligne 207), cest ` a dire celle qui appell ee par invoke handler, vue au paragraphe ci-dessus. La lecture du code permet de d eduire quil y a deux types de CGI, la distinction est faite parle nom de la cgi elle-m eme. La gure XV.5 r esume les 2 situations possibles dex ecution dune CGI.
Connexion client

HTTPD
Lecture client

HTTPD

1 cgi 2

0 Ecriture client

0 1 nphcgi 2

s>error_log (fichier error_log)

s>error_log (fichier error_log)

gure XV.05 Si le nom de lex ecutable commence par nph-16 le comportement du serveur http change. Dans le cas ordinaire (nom quelconque) les donn ees transmises depuis le client vers la cgi et r eciproquement, passent par le processus httpd et via un tube non nomm e (pipe). Dans le cas dune cgi nph, seules les donn ees lues depuis le client (par exemple avec la m ethode POST) transitent par le processus httpd, la r eponse, elle, est emise directement, ce qui am eliore les performances en evitant une s equence lecture/ ecriture inutile. Ce comportement est justi e d` es que de gros volumes doctets sont ` a transmettre au client (de grandes pages HTML, des images. . .). Attention, dans ce dernier cas, cest ` a la CGI de fabriquer lint egralit e du message HTTP, y compris len-t ete MIME. A elle egalement de g erer la d econnexion pr ematur ee du client (SIGPIPE). Ces deux modes de fonctionnement ne sont pas clairement document es, en fait il sagit dune caract eristique du serveur du CERN, maintenue pour assurer sans doute la compatibilit e avec les applicatifs d ej` a ecrits. Il nest pas assur e que cette possibilit e existera dans les futures versions du serveur
16

Non Parse Header

344

Anatomie dun serveur Web Apache, notamment celles qui utiliseront la version 1.1 dHTTP. Examinons le code du chier mod cgi.c : 207 int cgi_handler (request_rec *r) 208 { 209 int nph; ... ... 222 nph = !(strncmp(argv0,"nph-",4)); ... ... La variable nph vaut 1 si la cgi est de ce type. ... 251 ... ... add_common_vars (r); ...

Ici on commence ` a fabriquer lenvironnement dex ecution de la cgi Cette fonction (chier util script.c, ligne 126) compl` ete les variables qui ne d ependent pas du contenu de la requ ete, par exemple SERVER SOFTWARE, REMOTE HOST,. . . ... 277 278 279 280 281 282 ... ... if (!spawn_child (r->connection->pool, cgi_child, (void *)&cld, nph ? just_wait : kill_after_timeout, &script_out, nph ? NULL : &script_in)) { log_reason ("couldnt spawn child process", r->filename, r); return SERVER_ERROR; } ...

Lappel de cette fonction provoque la cr eation dun processus ls, celui qui nalement va ex ecuter la cgi. Il faut remarquer le deuxi` eme argument qui est un pointeur de fonction (cgi child), et le sixi` eme qui est nul dans le cas dune cgi du type nph. ee et sorscript in et script out sont respectivement les canaux dentr tie des donn ees depuis et vers le processus qui ex ecute la cgi. Il parait donc logique que dans le cas dune cgi de type nph script in soit nul. Un m ecanisme non encore analys e duplique la sortie de ce processus vers le client plut ot que vers le processus serveur. Nous continuons la description du point de vue du processus p` ere, donc httpd. Ligne 295 et les suivantes, jusqu` a la ligne 332, le processus lit ce que le client lui envoie, si la m ethode choisie est du type POST. Le contenu est renvoy e vers le processus ls, sans transformation :

Architecture interne du serveur Apache 311 312 ... 335 if (fwrite (argsbuffer, 1, len_read, script_out) == 0) break; ... pfclose (r->connection->pool, script_out);

345

Il est donc clair que cest ` a celui-ci dexploiter ce quenvoie le client, par exemple le r esultat dune forme de saisie. 337 338 ... 373 374 375 376 377 /* Handle script return... */ if (script_in && !nph) { ... send_http_header(r); if(!r->header_only) send_fd (script_in, r); kill_timeout (r); pfclose (r->connection->pool, script_in); }

Ce test traite le cas dune cgi normale, dont la sortie est lue par le serveur, puis renvoy ee au client (ligne 374). Examinons maintenant comment se pr epare et sex ecute le processus ls : 101 void cgi_child (void *child_stuff) 102 { ... ... 126 add_cgi_vars (r); 127 env = create_environment (r->pool, r->subprocess_env); Ces deux derni` eres lignes pr eparent lenvironnement du futur processus ls. Il sagit du tableau de variables accessibles depuis la variable externe environ, pour tout processus. La fonction add cgi vars (chier util script.c, ligne 192) ajoute, entres autres, les variables REQUEST METHOD et QUERY STRING ` a lenvironnement. Cette derni` ere variable joue un r ole majeur dans la transmission des arguments ` a la cgi quand la m ethode choisie est GET. En eet, dans ce cas, le seul moyen pour le client denvoyer des arguments ` a la cgi est dutiliser lURL, comme par exemple dans :
http://monweb.chez.moi/cgi-bin/nph-qtp?base=datas\&mot=acacia\&champ=.MC

La syntaxe de lURL pr evoit le caract` ere ? comme s eparateur entre le nom et ses arguments. Chaque argument est ensuite ecrit sous la forme : nom = valeur Les arguments sont s epar es les uns des autres par le caract` ere &.

346 135 136 ... 138

Anatomie dun serveur Web error_log2stderr (r->server); ... if (nph) client_to_stdout (r->connection);

Ligne 135, la sortie derreur est redirig ee vers le chier error log, et ligne 138, la sortie standard du processus, cest la socket, donc envoy ee directement vers le client ! 184 185 186 187

if((!r->args) || (!r->args[0]) || (ind(r->args,=) >= 0)) execle(r->filename, argv0, NULL, env); else execve(r->filename, create_argv(r->pool, argv0, r->args), env

Puis nalement on ex ecute la cgi ! Bien s ur, si le programme va au del` a de la ligne 187, il sagit dune erreur. . .

4 Principe de fonctionnement des CGIs

347

4
4.1

Principe de fonctionnement des CGIs

CGI M ethode GET, sans argument

Dans ce paragraphe nous examinons ce qui se passe lors de lex ecution dune CGI tr` es simple (shell script, le source suit) que lon suppose plac ee dans le r epertoire idoine, pour etre ex ecut ee comme lors de la requ ete suivante :
$ telnet localhost 80 Trying ... Connected to localhost. Escape character is ^]. GET /cgi-bin/nph-test-cgi HTTP/1.0 HTTP/1.0 200 OK Content-type: text/plain Server: Apache/1.1.1

La requ ete tap ee par lutilisateur. Len-t ete du message HTTP renvoy e par le serveur. La ligne de statut est g en er ee par la cgi car il sagit dune cgi de type nph-

CGI/1.0 test script report: argc is 0. argv is . SERVER_SOFTWARE = Apache/1.1.1 SERVER_NAME = www.chezmoi.tld GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/1.0 SERVER_PORT = 80 REQUEST_METHOD = GET SCRIPT_NAME = /cgi-bin/nph-test-cgi QUERY_STRING = REMOTE_HOST = labas.tresloin.tld REMOTE_ADDR = 192.168.0.1 REMOTE_USER = CONTENT_TYPE = CONTENT_LENGTH = Connection closed by foreign host.

Le corps du message. Ces octets sont g en er es dynamiquement par le programme nph-test-cgi.

Et voici le source de cet exemple (une modication du script de test livr e avec Apache) :
#!/bin/sh echo HTTP/1.0 200 OK echo Content-type: text/plain echo Server: $SERVER_SOFTWARE echo echo CGI/1.0 test script report: echo echo argc is $#. argv is "$*". echo

Remarquez la fabrication de lent ete MIME, r eduite mais susante. Le echo seul g en` ere une ligne vide, celle qui marque la limite avec le corps du message.

348
echo echo echo echo echo echo echo echo echo echo echo echo

Anatomie dun serveur Web

SERVER_SOFTWARE = $SERVER_SOFTWARE SERVER_NAME = $SERVER_NAME GATEWAY_INTERFACE = $GATEWAY_INTERFACE SERVER_PROTOCOL = $SERVER_PROTOCOL SERVER_PORT = $SERVER_PORT REQUEST_METHOD = $REQUEST_METHOD QUERY_STRING = $QUERY_STRING Toutes ces variables sont celles de REMOTE_HOST = $REMOTE_HOST lenvironnement g en er e par le moREMOTE_ADDR = $REMOTE_ADDR REMOTE_USER = $REMOTE_USER dule cgi handler avant deecCONTENT_TYPE = $CONTENT_TYPE tuer le exec. CONTENT_LENGTH = $CONTENT_LENGTH

4.2

CGI M ethode GET, avec arguments

Examinons maintenant un cas plus compliqu e, avec des arguments transmis, ou query string. Celle-ci est transmise ` a la cgi via la variable denvironnement QUERY STRING. Cest ` a la cgi de lanalyser puisque son contenu rel` eve de lapplicatif et non du serveur lui-m eme. Essayons de coder la cgi de lexemple :
http://www.chezmoi.tld/cgi-bin/query?base=datas\&mot=acacia\&champ=.MC

Premi` ere version : #!/bin/sh echo Content-type: text/plain echo echo "QUERY_STRING=>"$QUERY_STRING "<=" exit 0 Linterrogation avec un telnet produit la sortie : QUERY_STRING=>base=datas&mot=acacia&champ=.MC<= Se trouve tr` es facilement sur les sites ftp le source dun outil nomm e e` a lanalyse de la cha ne transmise. Do` u la cgiparse17 , parfaitement adapt deuxi` eme version :
#!/bin/sh CGIBIN=~web/cgi-bin BASE=$CGIBIN/cgiparse -value base MOT=$CGIBIN/cgiparse -value mot CHAMP=$CGIBIN/cgiparse -value champ
17

Cette partie du code montre lanalyse du contenu de la variable QUERY STRING avec loutil cgiparse.

Il est dans la distribution standard du serveur httpd-3.0.tar.gz du CERN

Principe de fonctionnement des CGIs

echo Content-type: text/plain echo echo "BASE="$BASE echo "MOT="$MOT echo "CHAMP="$CHAMP exit 0

349

Et l` a, la fabrication du message renvoy e. La cgi renvoie ses octets via un tube au serveur, cest donc celui-ci qui se charge de fabriquer un en-t ete MIME.

Puis le r esultat de lex ecution : BASE=datas MOT=acacia CHAMP=.MC

4.3

CGI M ethode POST

La m ethode POST autorise un client ` a envoyer au serveur une liste de couples variable=valeur. Chaque couple est s epar e des autres par une n de ligne, cest ` a dire (CR,LF). Cette m ethode est bien adapt ee ` a la transmission dinformations collect ees cot e client dans une forme18 de saisie, et dont le volume est variable. La liste des couples est ecrite dans le corps du message, par le programme client, et ne fait pas partie de lURL, comme cest le cas pour la m ethode GET. Il y a evidement une limite au nombre maximum doctets envoy e par 19 le client, cest le serveur qui en xe la valeur . Du cot e du client, il faut pr evenir le serveur, dans len-t ete du message HTTP, de la taille du corps du message. Cela seectue avec le champ Content-length :. Lexemple suivant ne fait que renvoyer la liste des couples lus, vers le client. Attention il ne fonctionne quavec telnet.
$ telnet www.chezmoi.tld 80 Trying 192.168.0.2... Connected to www.chezmoi.tld. Escape character is ^]. POST /cgi-bin/test-post HTTP/1.0 Content-length:14 areuh=tagada HTTP/1.0 200 OK Date: Mon, 24 Mar 1997 14:41:26 GMT Server: Apache/1.1.1 Content-type: text/plain REQUEST_METHOD = POST CONTENT_LENGTH = 14 Couple lu : areuh=tagada Connection closed by foreign host.
18 19

Le corps du message fait bien 14 caract` eres si on compte la n de ligne (CR+LF).

La r eponse du serveur liste les couples lus, ici un seul ! La variable globale REQUEST METHOD pourrait etre utilis ee pour adapter le comportement de la cgi en fonction de la m ethode demand ee.

Voir le tag FORM de lHTML HUGE STRING LEN qui vaut 8192 en standard, d enie dans le chier httpd.h

350 Et voici le source de la cgi :

Anatomie dun serveur Web

#!/bin/sh # # Ce script teste la methode POST # echo Content-type: text/plain echo echo REQUEST_METHOD = $REQUEST_METHOD echo CONTENT_LENGTH = $CONTENT_LENGTH while read l do echo "Couple lu :" $l done exit 0

4.4

Ecriture dune CGI en Perl

Voir cours de Jean-Jacques Dhenin. . .

5 Conclusion Bibliographie

351

Conclusion Bibliographie

Rien nest constant, tout change. . .Et il faut etre constamment ` a laut de la nouveaut e dans ce domaine tr` es r eactif quest celui du World Wide Web. Les quelques r ef erences bibliographique qui suivent illustrent ce cours, mais il est evident quelles sont bien insusantes pour couvrir tous les aspects que le terme web sous-entend ! RFC 1521 N. Borenstein, N. Freed, MIME (Multipurpose Internet Mail Extensions) Part One : Mechanisms for Specifying and Describing the Format of Internet Message Bodies, 09/23/1993. (Pages=81) (Format=.txt, .ps) (Obsoletes RFC1341) (Updated by RFC1590) RFC 1590 J. Postel, Media Type Registration Procedure, 03/02/1994. (Pages=7) (Format=.txt) (Updates RFC1521) RFC 1630 T. Berners-Lee, Universal Resource Identiers in WWW : A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web, 06/09/1994. (Pages=28) (Format=.txt) RFC 1738 T. Berners-Lee, L. Masinter, M. McCahill, Uniform Resource Locators (URL), 12/20/1994. (Pages=25) (Format=.txt) RFC 1945 T. Berners-Lee, R. Fielding, H. Nielsen, Hypertext Transfer Protocol HTTP/1.0, 05/17/1996. (Pages=60) (Format=.txt) RFC 2068 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. BernersLee,Hypertext Transfer Protocol HTTP/1.1, 01/03/1997. (Pages=162) (Format=.txt) TCP/IP Illustrated Volume 3 W. Richard Stevens Addison-Wesley Janvier 1996.

352

Anatomie dun serveur Web

Cinqui` eme partie Index g en eral & Annexes

Index
etats de liens, 111 aio read, 311 aio write, 311 close, 252, 255 exec, 308 fork, 255, 307, 315 open, 252 read, 252 rfork, 307 socket, 140, 253 vfork, 307, 308 write, 252 1000BaseT, 17 100BaseT, 16, 17 10Base2, 15, 15--16 10Base5, 15, 15 prise vampire, 15 10BaseT, 16 RJ45, 16 127.0.0.1, 37 224.0.0.5, 122 224.0.0.6, 122 802.11, 9 802.2, 9 802.3, 9 accept, 263--264 Accounting management, 221 active open, voir ouverture active adresse de loopback, 37 adresse Ethernet, voir Ethernet adresse IEEE 802.3, 11 adresse IP, voir IP adresse IP priv ee, 34 adresse IP publique, 34 adresse physique, 11 AF, 254, voir Address Family AFNIC, voir Association Fran caise pour le Nommage Internet en Coop eration AfriNIC, 34 agent, voir SNMP algorithme Bellman-Ford, 111, 113, 120 Algorithme concourant - Mode connect e, 306 Algorithme concourant - Mode datagramme, 305 algorithme de routage, voir routage Algorithme It eratif - Mode connect e, 305 Algorithme it eratif - Mode data-gramme, 303 alias IP, 44, 137 API, voir Application Program Interface APNIC, 34 Application Program Interface, 251 ARIN, 34 ARP, 12, 55, 60, 109 Fonctionnement, 55 Format du datagramme, 57 HARDWARE TYPE, 57 HLEN 1, 57 HLEN 2, 57 OPERATION, 57, 58 PROTOCOL TYPE, 57 Proxy arp, 56, 58 SENDER ADR, 57 SENDER HA, 57 TARGET ADR, 57

356 TARGET HA, 57 arp, voir commande Arpanet, 25, 47, 110, 121, 189 arpwatch, voir commande AS, 71, 110--111 ASN.1, 229--231, 247 Association Fran caise pour le Nommage Internet en Coop eration, 3 Authentication Header, 144 Autonomous systems, voir AS base de donn ees distribu ee, 169 bases whois, 168 Basic Encoding Rules, voir BER bcmp, 278 bcopy, 278 BER, 231, 247 Berkeley Internet Name Domain, 186 BGP, 71, 110 BGP-4, 40 big endian, 268, 277 BIND, voir Berkeley Internet Name Domain bind, 256--258, 260 Bind Operations Guide, 187 BOG, voir Bind Operations Guide BOOTP, 109 Border Gateway Protocol, voir BGP brodcast, 20 BSD 4.1c, 251 BSD 4.3, 252, 320 bzero, 278 cache dns, 174 CARP, 12, 137 CCITT, 229--231 chroot, 138 CIDR, voir Classless InterDomain Routing circuit virtuel, 89, 90, 302 Clamav, 209

INDEX Classless InterDomain Routing, 40 close, 264 closelog, 318 CMIP, 224 CMIS, 224 commade arpwatch, 223 commande arp -a, 56 -an, 232 cvs, 213 gated, 67 httptunnel, 140 ifconfig, 141 inetd, 301, 312, 320--322 init, 315 ipf, 154 ipfw, 154 m4, 212 mailq, 208 mbrowse, 244 mrtg, 245 mutt, 191 named, 186 natd, 150, 159 netstat -p tcp, 229 -rn, 68 -s -p icmp, 232 -s -p ip, 232 -s -p tcp, 232 -s -p udp, 232 newaliases, 207 nsupdate, 179 ntop, 226 ping, 142, 169 procmail, 209, 210 ps, 315 rcs, 213 route, 67, 141 routed, 67, 74, 119 sendmail, 195 snmpd, 238

INDEX snmpdelta, 238 snmpget, 238, 242 snmpgetnext, 238, 242 snmpset, 238, 243 snmptable, 238, 243 snmptranslate, 238 snmptrapd, 238 snmpwalk, 238, 244 sshd, 140 syslogd, 154, 315 tcpdump, 142, 270, 272, 282 tkined, 225, 247 traceroute, 169 Common Address Redundancy Protocol, voir CARP Common Management Information Protocol, voir SMIP Common Management Information Service, voir CMIS Community-based SNMPv2, 226 commutateur, 20--22 ISH, 21 VLAN, 22 Commutation de paquets, 4 concentrateur, 18--19 concurrent server, voir serveur concourant Configuration and name management, 221 congestion avoidance, 101 congestion window, 101 connect, 259 CRLF, 191 CSMA/CA, 9 CSMA/CD, 9, 19 Cyclades, 25, 121 daemon, 144, 315--316 Darpa, 25 DATA, 198 datagramme, 44 Dave Clark, 89 David H. Crocker, 191 descripteur de socket, 253 DHCP, 109, 177 diablotin, 318 Differentiated Services CodePoints, voir DSCP Diffie-Hellman, 179 DNS, 230, voir serveur de noms dns dynamique, 167 DNSBL, voir Domain Name Services BlackList DNSSEC, 178 domain completion, 170 Domain Name Services BlackList, 204 domaine, 167 Douglas E. Comer, 166 DSCP, 50 dynamic update, 179 dyndns, voir dns dynamique ECN, 50 Edsger W. Dijkstra, 73, 112 EGP, 71, 110, 232 EINTR, 313 en-t^ ete 802.2/802.3, 13 ARP, 57 Ethernet, 11 ICMP, 60 IGMP, 63 IP, 49 RARP, 57 TCP, 91 UDP, 84 Encapsulating Security Payload, 144 enveloppe dun mail, 190 Ethernet, 9, 9--11 adresse, 11 adresse dunicast, 13 adresse de broadcast, 13 adresse de multicast, 13 collision, 10 en-t^ ete, 11 fin, voir 10Base2 format dune trame, 10 paires torsad ees, voir 10BaseT RJ45, voir 10BaseT

357

358 standard, voir 10Base5 thick, voir 10Base5 thin, voir 10Base2 transceiver, 9 Twisted Pair, voir 10BaseT Explicit Congestion Notification, voir ECN Extensible Markup Language, voir XML Exterior Gateway Protocol, voir EGP, voir EGP eXternal Data Representation, voir XdR FAI, voir Fournisseur dAcc` es Internet Fault management, 221 fcntl, 311 FD CLR, 312 FD ISSET, 312, 313 FD SET, 312 FD ZERO, 312 fen^ etres glissantes, 98 Fibre optique, 16 fichier .forward, 209 .procmailrc, 209 /etc/bootptab, 58 /etc/host.conf, 173 /etc/hosts, 165, 171, 280 /etc/inetd.conf, 321 /etc/mail/access, 208 /etc/mail/aliases, 207 /etc/mail/local-host-names, 208 /etc/mail/mailertable, 208 /etc/mail/sendmail.cf, 207 /etc/mail/submit.cf, 207 /etc/mail/userdb, 208 /etc/mail/virtusertable, 208 /etc/nsswitch, 173 /etc/protocols, 50, 122, 140, 255, 291, 322 /etc/rc, 315 /etc/rc.firewall, 155

INDEX /etc/resolv.conf, 170, 170--171 /etc/services, 28, 85, 195, 258, 267, 275, 321 /etc/syslog.conf, 317 /var/log/syslog, 317 /var/spool/mqueue, 208 named.boot, 182, 186 named.conf, 182, 186 named.root, 175 resolv.conf, 173 sendmail.cf, 212 submit.cf, 212 syslog.conf, 318 FIFO, voir pile FIFO Firefox, 26 Fournisseur dAcc` es Internet, 34 FQDN, voir Fully Qualified Domain Name, 184 frame, voir trame full duplex, 91, 254 Fully Qualified Domain Name, 169 gated, voir commande gateway, voir passerelle generic tunnel interface, 140 gethostbyaddr, 282 gethostbyname, 170, 173, 280 getprotobyname, 291 getprotobynumber, 291 getservbyname, 283, 291 getservbyport, 284, 291 gif, voir generic tunnel interface HELO, 197 HUB, 16 hub, voir concentrateur IAB, 230 IANA, 28, 41, 43, 86, 231 ICANN, voir Internet Corporation for Assigned Names and Numbers

INDEX ICMP Echo Reply, 224 Echo Request, 224 IEEE, 9 IETF, 40 IGP, 71, 110 IMAP, 211--212 in-addr.arpa, 176 inaddr.arpa, 184, 175--184 index addr, 279 inet ntoa, 279 inet ntop, 279 inet pton, 279 Institute of Electrical and Electronics Engineers, voir IEEE Interface de loopback, 75 Interior Gateway Protocol, voir IGP Internet Activity Board, voir IAB Internet Corporation for Assigned Names and Numbers, 34, 43 Internet Key Exchange, 144 Internet Software Consortium, 3, 186 inverse queries, voir question inverse IP, 47 adresse, 33--44 CIDR, 40--41 classe A, 35 classe B, 35 classe C, 35 classe exp erimentale, 36 de broadcast, 37, 41 multicast, 13, 42--44 sous-r eseaux, 38--39 unicast, 36 All-subnets-directed broadcast, 41 DESTINATION ADDRESS, 50 DSCP/ECN, 50 FLAG, 54 FLAGS, 50, 53 Dont Fragment bit, 52 More fragment, 53 FRAGMENT OFFSET, 50, 53 fragmentation, 52, 83 HEADER CHECKSUM, 50, 54 HLEN, 49 ICMP, 30, 59 CHECKSUM, 60 CODE, 60, 62 Destination Unreachable, 61 Echo Reply, 61 Echo Request, 61 Format des messages, 60 Redirect, 62, 68 router advertisement, 73 Router solicitation, 62 router sollicitation, 73 Source Quench, 50, 62 Time exceeded, 62 TYPE, 60 IDENTIFICATION, 50, 53, 54 IGMP, 30, 43, 63 protocole, 64 Limited broadcast, 41, 114, 120 MTU, 47, 47, 49, 51, 52, 83, 99, 139 multicast, 114 Net-directed broadcast, 41 OFFSET, 54 OPTIONS, 51 PADDING, 51 PROTOCOL, 50, 82, 122 R eassemblage, 53 SOURCE ADDRESS, 50 Subnet-directed broadcast, 41 TOTAL LENGTH, 49, 53, 54 TTL, 50, 62, 65 TYPE OF SERVICE, 50 VERS, 49 IP aliasing, voir alias ip IP payload compression, 144

359

360 IPFIREWALL, 154 IPFIREWALL VERBOSE, 154 IPsec, 143--147 AH, voir Authentication Header ESP, voir Encapsulating Security Payload IKE, voir Internet Key Exchange IPcomp, voir IP payload compression mode transport, 145 mode tunnel, 145 SA, voir Security Association SPI, voir Security Parameter Index ipv6, 147, 166, 292 IS-IS, 40, 71 ISC, voir Internet Software Consortium ISN, voir Initial Sequence Number ISO 3166, 168 ISO 8824, 229 ISO 8825, 231 iterative server, voir serveur it eratif jail de FreeBSD, 138 Jon Postel, 25, 81, 89 Jonathan B. Postel, 195 KAME, 147 Konqueror, 26 LACNIC, 34 LAN, 3, 7--8 LDA, voir Local Delivery Agent libc, 170, 173, 186 Link State Packet, voir LSP Link-state request, voir LSR Link-state update, voir LSU LIR, voir Local Internet Registry listen, 263

INDEX little endian, 268, 277 Local Delivery Agent, 200 Local Internet Registry, 35 Louis Pouzin, 25 LSP, voir routage LSR, voir routage LSU, voir routage machine virtuelle, 138 MAIL, 198 Mail Submit Agent, 199 Mail Transfer Agent, 200 Mail User Agent, 199 mailing-list, 189 MAN, 8 Management Information Base, voir MIB manager, voir SNMP master, voir serveur principal Maximum Transfer Unit, 47 Mbone, 65 md5, 179 memcmp, 278 memcpy, 278 memset, 278 message, 44 MIB, 224, 227, 247, 228--247 MIB-2, 225, 232 mibs vendor, 228 mibs vendors, 225 milter, 209 milter-greylist, 209 MIME, 212 MIMEDefang, 209 mode connect e, 90, 254, 260, 262 datagramme, 83, 90, 254, 260 mode connect e, 302 mode datagramme, 303 Mosaic, 26 Mozilla, 26 MSA, voir Mail Submit Agent MTA, voir Mail Transfer Agent MTU, voir Maximum Transfer Unit

INDEX MUA, voir Mail User Agent multi-homed, 44 multicast, 20 224.0.0.1, 42, 64, 73 224.0.0.2, 42, 73 224.0.0.22, 42 224.0.0.255, 65 224.0.0.5, 42 224.0.0.9, 42 adresse MAC, 43 groupe, 42 IGMP, voir IP IGMP mutex, 309 neud, 167 name daemon control program, 187 name server control utility, 187 NAPT, voir Network Address Port Translation NAT, voir Network Address Translation National Science Foundation, 26 NBO, voir network Byte Order NCP, 47 ndc, voir name daemon control program NET-SNMP, 238 Netscape, 26 netstat, voir commande Network Address Port Translation, 149 Network Address Translation, 149 network Byte Order, 267 network byte order, 48, 277, 283 Network Control Protocol, voir NCP Network Information Center, 166, 168 Network Management Application, voir NMA Network Management Entity, voir NMS Network Management System, voir NMS NIC, voir Network Information Center NIS, 171, 280 NMA, 222, 247 NME, 222, 247 NMS, 222 nommage absolu, 169 nommage relatif, 169 notify, 182 NSF, voir National Science Foundation num ero de port, 81, 252, 267, 275 num ero de service, voir num ero de port Objet Identifier, voir OID OID, 230--231, 247 open mail relay, 202 Open Shortest Path First, voir OSPF openlog, 318 orderly release, 95 Organizationally Unique Identifier, voir OUI OSI, 230 7 couches de l, 5 application, 5 donn ee, 9 donn ees, 5, 14 LLC, 14 MAC, 14 physique, 5 pr esentation, 5, 226, 229 r eseau, 5 session, 5, 30 transport, 5 OSPF, 40, 50, voir routage OUI, 11 ouverture active, 94 ouverture passive, 94

361

362 paquet, 44 passerelle, 8, 22--23, 44 routeur, 22 passive open, voir ouverture passive Paul Baran, 4 PDU, 247 Performance management, 222 PF, 254, voir Protocol Family pile ARPA, 28, 143, 302 pile FIFO, 83 poids faible, 277 poids fort, 277 Point to Point Protocol, 55, 210 poll, 314 POLLERR, 314 POLLHUP, 314 POLLIN, 314 polling, 312 POLLOUT, 314 pont, 19--20 POP, voir Post Office Protocol, 210--211 port, voir num ero de port Post Office Protocol, 210 PPP, voir Point to Point Protocol, 118, voir Point to Point Protocol primary server, voir serveur principal Protocol Data Unit, voir PDU querie reverse, voir question inverse question inverse, 175 quintuplet, 90, 255, 258 QUIT, 198 r ep eteur, 17--18 r eseau dinterconnexion, 140 r eseau virtuel, 44 R eseaux IP europ een, 34 RARP, 12, 58, 60 bootp, 58 dhcp, 58

INDEX RCPT, 198, 202 read, 262 readv, 262 recv, 262 recvfrom, 262 recvmsg, 262 Regional Internet Registries, 34 relay mail, 200, 201 Remote Monitoring, voir RMON remote procedure call, 275 repeater, voir r ep eteur Requests For Comments, 27 resolver, 170, 170--171, 173, 280 Resource Record, voir RR, 205 RFC, voir Requests For Comments RFC 1025, 92 RFC 1028, 224 RFC 1034, 169, 175 RFC 1035, 83, 182 RFC 1042, 9 RFC 1112, 63 RFC 1155, 224, 226, 228 RFC 1156, 224, 226, 232 RFC 1157, 224, 226 RFC 1213, 225, 226, 229, 232 RFC 1611, 245 RFC 1631, 148 RFC 1700, 36, 42, 43, 86 RFC 1878, 38 RFC 1901, 226 RFC 1902, 226 RFC 1903, 226 RFC 1904, 226 RFC 1905, 226 RFC 1906, 226 RFC 1907, 226 RFC 1908, 226 RFC 1918, 34, 140, 149 RFC 1919, 148 RFC 1939, 210 RFC 2136, 179 RFC 2144, 144

INDEX RFC 2328, 73 RFC 2364, 139 RFC 2401, 143, 144 RFC 2402, 144 RFC 2405, 144 RFC 2406, 144 RFC 2409, 144 RFC 2451, 144 RFC 2476, 199 RFC 2516, 139 RFC 2535, 179 RFC 2845, 179 RFC 2930, 179 RFC 3168, 50 RFC 3411, 226 RFC 3412, 226 RFC 3413, 226 RFC 3414, 226 RFC 3415, 226 RFC 3416, 226 RFC 3417, 226 RFC 3418, 226 RFC 3501, 211 RFC 768, 81 RFC 791, 25, 47 RFC 793, 89, 265 RFC 821, 195 RFC 822, 189, 191 RFC 826, 55 RFC 867, 267 RFC 894, 9 RFC 896, 100 RFC 903, 58 RFC 922, 41 RFC 950, 38, 59 RFC 1256, 73 RFC 1700, 275 RFC 3493, 257 RIP, voir routage RIP-2, 40 RIPE, voir R eseaux IP europ een RIR, voir Regional Internet Registries RMON, 225 rndc, voir name server control utility root name server, voir serveur racine round trip time, 93, 97 routage, 66--74 algorithme de, 70 classless, 40 d ecouverte de routeurs, 73 direct, 66, 109 dynamique, 71, 109 indirect, 66, 109 OSPF, 73, 111, 121--134 adjacencies & neighbors, 130 adjacency database, 131 Area border routers, 129 Autonomous system boundary routeurs, 129 Backbone routers, 129 Backup designated router, 129 co^ ut des liens, 127 DataBase Description paquet, 131 Designated router, 129 Down, 130 Exchange, 131 ExStart, 130 flooding, 124, 126 Hello, 131 hi erarchie de routeurs, 127 Init, 130 Internal routers, 128 link-state database, 124 Loading, 131 LSAck, 132 LSP, 124 LSR, 131, 132 LSU, 131, 132 plus court chemin, 127 protocole HELLO, 131 Two-way, 130 redirection, 74 RIP, 72, 111, 113--120

363

364 chemin le plus court, 113 m etrique, 113 poisoned reverse, 116 split horizon, 116 Triggered updates, 117 statique, 69, 109 table de, 67 routed, voir commande Routing Information Protocol, voir RIP Routing policy, 110 RPC, voir remote procedure call RR, 182 A, 182, 184 CNAME, 185 HINFO, 185 KEY, 179, 185 MX, 182, 184, 205 NS, 182, 183--184 PTR, 182, 184 SOA, 167, 175, 182, 183 TXT, 185 WKS, 185 RS232, 52 RTT, voir round trip time s-mail, 190 sans fil, 9, 19 secondary server, voir serveur secondaire Security Association, 145 Security management, 222 Security Parameter Index, 145 select, 312--313 send, 260--261 sendmsg, 260--261 sendto, 260--261 Serial Line IP, 52 serveur concourant, 302 serveur de noms, 280 serveur de serveurs, voir inetd serveur it eratif, 301 serveur principal, 167, 175 serveur racine, 175

INDEX serveur secondaire, 167, 175 setsid, 315 SGMP, 224 shutdown, 264 SIGIO, 307, 311 SIGPOLL, 311 Simple Gateway Monitoring Protocol, voir SGMP Simple Mail Transfer Protocol, 195 slave, voir serveur secondaire sliding windows, voir fen^ etres glissantes SLIP, voir Serial Line IP slow start, 101 SMI, 125, 226, 228, 247 SMTP, voir Simple Mail Transfer Protocol SNMP, 18, 223--227 agent, 223, 225, 234, 247 communaut e, 235 GetBulkRequest, 236 GetNextRequest, 236 GetRequest, 236 GetResponse, 236 InformRequest, 236 manager, 223, 225, 234, 247 PDU, 237 PDU(textbf, 235 rmon, 225--226, 247 SNMPv1, 224, 226 SNMPv2c, 226 SNMPv3, 226, 237 Trap, 236 trap, 223, 234, 248 SO LINGER, 96 socket, 253--255 IPPROTO ICMP, 255, 291 IPPROTO IGMP, 255 IPPROTO IP, 291 IPPROTO RAW, 255 IPPROTO TCP, 255, 291 IPPROTO UDP, 255, 291 PF APPLETALK, 254 PF ATM, 254

INDEX PF INET, 254 PF INET6, 254 PF IPX, 254 PF ISO, 254 PF KEY, 254 PF LINK, 254 PF LOCAL, 254 PF NS, 254 PF ROUTE, 254 PF SNA, 254 PF UNIX, 254 SOCK DGRAM, 254 SOCK RAW, 254 SOCK STREAM, 254 source gethostbyname.c, 282 spam, 201--204 Spanning Tree Protocol, 20 static nat, 152 STP, voir Spanning Tree Protocol Structure of Management Information, voir SMI structure sockaddr, 257 structure sockaddr in, 258 subnet address, voir Adresse de sous-r eseau supernet, 40 switch, voir commutateur syslog, 187, 223, voir commande syslogd, 318 syslogd, 316--317 table de routage, voir routage TCP, 89 ACKNOWLEDGEMENT NUMBER, 91 CHECKSUM, 92 CODE, 92 ACK, 91, 92 ACNOWLEDGMENT NUMBER, 92 FIN, 92 PUSH, 92 RST, 92, 264 SYN, 92, 99 URGENT POINTER, 92 DESTINATION PORT, 91 Initial Sequence Number, 91 OFFSET, 91 OPTIONS, 92 mss, 93, 99 nop, 93 timestamp, 93 PADDING, 93 RESERVED, 92 SEQUENCE NUMBER, 91, 95 SOURCE PORT, 91 URGENT POINTER, 92 WINDOW, 92, 99 the internet superserver, voir inetd threads kernel, 310 threads user land, 310 three-way handshake, 95 time sharing, 307 TKERY, voir Transaction Key TKEY, 178 TLD, voir top levels domains TLI, voir Transport Layer Interface top levels domains, 168 trame, 44 Transaction Key, 179 Transaction SIGnature, 179 transfert de zone, 182 Transport Layer Interface, 251 trap, voir SNMP TSIG, 178, voir Transaction SIGnature Tunnel IP, 139 UDP, 81, 118 CHECKSUM, 84 DESTINATION PORT, 84 MESSAGE LENGTH, 84 SOURCE PORT, 84 umask, 315 Universit e de Berkeley, 26 UUCP, 195 Variable Length Subnet Mask, voir VLSM vecteur de distances, 111

365

366 Virtual Private Network, 143 VLSM, 122 VPN, voir Virtual Private Network, 145 W. Richard Stevens, 100 WAN, 8 wifi, voir sans fil wireless, voir sans fil write, 260--261 writev, 260--261 wscale, 92, 93 XdR, 5 XML, 5 zone, 167 zone de Solaris, 138 zone reverse, 176

INDEX

Annexe A Programme serv2prot.c

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 /* $Id: serv2prot .c 134 2009 -02 -27 16:38:44 Z fla $ * * Exemple de serveur d e cho , parall` e le et multiprotocole (TCP , UDP). * * Compiler avec -DBAVARD pour des commentaires sur les e tats du serveur . * Le serveur se stoppe avec un SIGHUP . * * Compiler avec -DBSD sur les OS BSD. * */ # include < s t d i o . h> /* De toute fa c on ! */ # include < e r r n o . h> /* Idem */ # include < s t d l i b . h> /* Pour "atoi ". */ # include < u n i s t d . h> /* Pour " getopt ". */ # include < s t r i n g s . h> /* Pour "bcopy ". */ # include < s i g n a l . h> /* Pour " signal ". */ # include < time . h> /* Pour " select ". */ # include < s y s e x i t s . h> /* Codes de retour */ # include < s y s / w a i t . h> /* Pour "wait ". */ # include < s y s / t y p e s . h> # include < s y s / s o c k e t . h> # include < n e t i n e t / i n . h> # include < arpa / i n e t . h> /* Pour " inet_ntoa " */ # include <netdb . h> /* Pour " getservbyname " */ extern extern int int int void void void void char int optarg ; optind , opterr ;

OuvrirSocketUDP ( char , int ) ; OuvrirSocketTCP ( char , int , int ) ; PortParLeNom ( char , char ) ; TraiterTCP ( int ) ; TraiterUDP ( int ) ; PasDeZombi ( int ) ; FinCanonique ( int ) ;

# define max( a , b ) (a > b ? a : b) # define USAGE "Usage :%s -p <num e ro de port > [-n|-w]\n\t-n : serveur parall` e le \n\t-w : serveur it e ratif ( d e faut )\n"

368
39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 # define VRAI # define FAUX # define MAXQ # ifdef # define # define #else # define # define # endif BSD CAST CAST2 CAST CAST2 (1) (0) 5

Programme serv2prot.c

fd set struct r u s a g e int int

# ifdef BAVARD # define PRINTF #else # define PRINTF # endif

( void ) p r i n t f if ( 0 ) ( void ) p r i n t f

int sudp , stcp ; pid_t tcp_pid , udp_pid ; int iteratif ; fd_set lect , alire ; struct sockaddr_in sclient ; int main ( int argc , char argv [ ] ) { int c ; int nport ; int ndes ; int sock ; int intcp pid_t pid ; socklen_t slen ;

/* /* /* /* /*

Descrip . de socket . ceux des fils. VRAI:serv. it e ratif . Pour le select . Pour le getpeername

*/ */ */ */ */

/* /* /* /*

Brouillon Nport du serveur . Retour de select . Pour le accept .

*/ */ */ */ */

/* Pour le "fork ".

nport = 1 ; /* Non configur e. */ iteratif = VRAI ; /* It e ratif par d e faut . */ opterr = 0 ; /* cf "man 3 getopt " */ while ( ( c=getopt ( argc , argv , "p:nw" ) ) != EOF ) { switch ( c ) { case p : /* Num e ro du port. */ nport = atoi ( optarg ) ; break ; case w : /* wait = It e ratif . */ iteratif = VRAI ; break ; case n : /* nowait = Parall` e le .*/ iteratif = FAUX ; break ; default : /* Erreur !! */ ( void ) fprintf ( stderr , USAGE , argv [ 0 ] ) ; exit ( EX_USAGE ) ; } }

369
93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 if ( nport < 0 ) { ( void ) fprintf ( stderr , USAGE , argv [ 0 ] ) ; exit ( EX_USAGE ) ; } if ( iteratif==VRAI ) PRINTF ( "*** D e but du server it e ratif \n" ) ; else PRINTF ( "*** D e but du server parall` e le \n" ) ; sudp = OuvrirSocketUDP ( "" , nport ) ; stcp = OuvrirSocketTCP ( "" , nport , MAXQ ) ; c = max ( sudp , stcp ) + 1 ; /* Rang bit + ` a gauche . */ FD_ZERO (& lect ) ; FD_SET ( sudp ,& lect ) ; FD_SET ( stcp ,& lect ) ; /* cf "<sys/types.h>" */

( void ) signal ( SIGCHLD , PasDeZombi ) ; /* Mort dun proc. fils */ ( void ) signal ( SIGHUP , FinCanonique ) ; /* Fin " propre ". */ while ( VRAI ) { /* Tourne toujours ! */ alire = lect ; PRINTF ( "*** Lecture bloquante du select \n" ) ; if ( ( ndes = select ( c , ( CAST )&alire , ( CAST ) 0 , ( CAST ) 0 , \ ( struct timeval ) 0 ) ) < 0) { if ( errno == EINTR ) /* A cause dune inter. */ continue ; perror ( " select " ) ; exit ( EX_OSERR ) ; } while ( ndes ) { /* ndes >= 0 */ if ( FD_ISSET ( stcp ,& alire ) ) { PRINTF ( "*** S e lection de lentr e e TCP\n" ) ; if ( ( sock=accept ( stcp , ( struct sockaddr ) 0 , ( socklen_t ) 0 ) ) <0) { perror ( " accept " ) ; exit ( EX_OSERR ) ; } intcp = VRAI ; } else if ( FD_ISSET ( sudp ,& alire ) ) { PRINTF ( "*** S e lection de lentr e e UDP\n" ) ; sock = sudp ; intcp = FAUX ; } if ( getpeername ( sock , ( struct sockaddr )&sclient ,& slen ) < 0 ) perror ( " Getpeername " ) ; else PRINTF ( "*** Nouveau client : %s:%d\n" , \ inet_ntoa ( sclient . sin_addr ) , ntohs ( sclient . sin_port ) ) ; retry :

370
144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197

Programme serv2prot.c
pid=fork ( ) ; switch ( pid ) { case 1 : /* Erreur . */ if ( errno==EINTR ) goto retry ; perror ( "fork" ) ; exit ( EX_OSERR ) ; case 0 : /* Fils. */ if ( intcp==VRAI ) { ( void ) close ( sudp ) ; ( void ) close ( stcp ) ; TraiterTCP ( sock ) ; } else { ( void ) close ( stcp ) ; TraiterUDP ( sock ) ; } exit ( EX_OK ) ; default : /* P` e re. */ if ( iteratif==VRAI ) FD_CLR ( intcp==VRAI ? stcp : sudp ,& lect ) ; if ( intcp==VRAI ) { ( void ) close ( sock ) ; FD_CLR ( stcp ,& alire ) ; tcp_pid = pid ; } else { udp_pid = pid ; FD_CLR ( sudp ,& alire ) ; } } ndes ; } } } /* * PasDeZombi : Gestion des processus fils qui se terminent . */ void PasDeZombi ( int nsig ) { pid_t pid ; int status ; PRINTF ( "*** On a re c u un SIGCHLD \n" ) ; /* * WNOHANG : e vite que wait3 soit bloquant , m^ e me si des fils sont * encore en activit e ( retour 0). */ while ( ( pid=wait3 (& status , WNOHANG , ( CAST2 ) 0 ) ) > 0 ) if ( iteratif==VRAI ) if ( pid==tcp_pid ) { FD_SET ( stcp ,& lect ) ; PRINTF ( "***Lentr e e TCP est r e activ e e \n" ) ;

371
198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 break ; } else if ( pid==udp_pid ) { FD_SET ( sudp ,& lect ) ; PRINTF ( "***Lentr e e UDP est r e activ e e \n" ) ; break ; } # ifndef BSD ( void ) signal ( SIGCHLD , PasDeZombi ) ; #endif } /* Selon OS */

/* * FinCanonique : On passe par l` a en cas de fin normale . */ void FinCanonique ( int nsig ) { PRINTF ( "*** Signal SIGHUP re c u - Fin du serveur !\n" ) ; exit ( EX_OK ) ; } /* * Serveur d e cho , TCP. */ void TraiterTCP ( int des ) { int n ; char buf [ 1 0 2 4 ] ; PRINTF ( "*** On entre dans TraiterTCP , cha^ ne lue :\n" ) ; while ( ( n = read ( des , buf , sizeof buf ) ) > 0 ) { /* == 0 -> EOF */ buf [ n ] = \0 ; PRINTF ( "*** On renvoie (TCP) %s" , buf ) ; if ( write ( des , buf , n ) < 0 ) perror ( " write - TCP" ) ; } PRINTF ( "\n" ) ; PRINTF ( "*** D e connexion de %s:%d\n" , inet_ntoa ( sclient . sin_addr ) , \ ntohs ( sclient . sin_port ) ) ; } /* * Serveur decho , UDP. */ void TraiterUDP ( int des ) { char buf [ BUFSIZ ] ; int n ; socklen_t ladr ;

372
251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 struct sockaddr adr ;

Programme serv2prot.c

PRINTF ( "*** On entre dans TraiterUDP , cha^ ne lue :\n" ) ; ladr = sizeof adr ; if ( ( n = recvfrom ( des , buf , sizeof buf , 0 , ( struct sockaddr )&adr ,& ladr ) ) < 0 ) return ; buf [ n ] = \0 ; PRINTF ( "*** On renvoie (UDP) :%s\n" , buf ) ; ( void ) sendto ( des , buf , n , 0 , ( struct sockaddr )&adr , ladr ) ; } /* * OuvrirSocketUDP : Ouvre une socket UDP et renvoie le descripteur */ int OuvrirSocketUDP ( char nserv , int nport ) { struct sockaddr_in sadr ; int sd ; int np = htons ( nport ) ; if ( np < 0 ) if ( ( np = PortParLeNom ( nserv , "udp" ) ) < 0 ) return 1 ; if ( ( sd=socket ( PF_INET , SOCK_DGRAM , 0 ) ) < 0 ) { perror ( " socket - SOCK_DGRAM " ) ; exit ( EX_OSERR ) ; } bzero ( ( char )&sadr , sizeof sadr ) ; sadr . sin_family = PF_INET ; sadr . sin_port = np ; if ( bind ( sd , ( struct sockaddr )&sadr , sizeof sadr ) < 0 ) { perror ( "bind - SOCK_DGRAM " ) ; exit ( EX_OSERR ) ; } return sd ; } /* * OuvrirSocketTCP : Ouvre une socket TCP et renvoie le descripteur */ int OuvrirSocketTCP ( char nserv , int nport , int queue ) { struct sockaddr_in sadr ; int sd ; int np = htons ( nport ) ; if ( np < 0 ) if ( ( np=PortParLeNom ( nserv , "tcp" ) ) < 0 ) return 1 ;

373
304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 if ( ( sd = socket ( PF_INET , SOCK_STREAM , 0 ) ) < 0 ) { perror ( " socket - SOCK_STREAM " ) ; exit ( EX_OSERR ) ; } bzero ( ( char )&sadr , sizeof sadr ) ; sadr . sin_family = PF_INET ; sadr . sin_port = np ; if ( bind ( sd , ( struct sockaddr )&sadr , sizeof sadr ) < 0 ) { perror ( "bind - SOCK_STREAM " ) ; exit ( EX_OSERR ) ; } if ( listen ( sd , queue ) < 0 ) { perror ( " listen - SOCK_STREAM " ) ; exit ( EX_OSERR ) ; } return sd ; } int PortParLeNom ( char nserv , char nprot ) { struct servent serv ; if ( getservbyname ( nserv , nprot ) == NULL ) return 1 ; return serv>s_port ; } /* Respecte le NBO. */