Cours dintroduction ` TCP/IP a

Franois Laissus c Version du 25 fvrier 2009 e

ii Copyright c 1999 - 2009 $Rev: 131 $ Franois Laissus c

Avant propos
Les sources de ce document sont dveloppes, gres et conserves grce e e ee e a aux services de FreeBSD1 , remarquable syst`me dexploitation OpenSource ! e Les divers chiers qui composent le source sont dits ` laide de lditeur e e a e de texte vi ; lhistorique des modications est con aux bons soins de loutil e subversion (gestionnaire de versions). Lensemble du processus de fabrication est pilot par une poigne de chiers Makefile (commande make). e e
A La mise en forme seectue grce au logiciel L TEX. Les gures sont desa sines sous X Window Systems (X11) ` laide du logiciel xfig et intgres e a e e directement dans le document nal sous forme de PostScript encapsul. Les e listings des exemples de code C ont t fabriqus ` laide du logiciel a2ps et ee e a inclus dans le document nal galement en PostScript encapsul. e e

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

Ou ` tlcharger au format PDF : a ee 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 rpertoire : e 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 $ Franois Laissus c

Historique des principaux changements

` A ce jour(25/02/2009), ce document existe et est accessible sur lInternet depuis le milieu des annes 90. De tr`s nombreux internautes lont tlcharg e e ee e et mont renvoy leurs commentaires. Il tait donc plus que temps de garder e e une trace des principales modications et restructurations an que ces lecteurs d`les puissent suivre les modications et, peut tre, tlcharger une e e ee nouvelle version en connaissance de cause !

Version du 25 Fvrier 2009 Restructuration de lensemble en quatre parties princie pales (A,B,C, D) et un index gnral. Ajout dune partie Rseaux IP avancs . e e e e Ajout dun chapitre sur SNMP et dun chapitre sur le routage dynamique. Ajout dun changelog, cette page. . . Le .pdf est maintenant ractif, les urls, les renvois de pages, le sommaire, les listes e de tableaux et gures. Nombreuses corrections et mises ` jour de tous les chapitres depuis la version du a 14 octobre 2007.

iv

Table des mati`res e

Prface e xxi

A
I 1 2

Introduction ` la pile ARPA a

Rseaux locaux e Prambule . . . . . . . . . . . . . . . . . . . . . . e Gnralits - LANs . . . . . . . . . . . . . . . . . e e e 2.1 Gnralits . . . . . . . . . . . . . . . . . e e e 2.2 Mod`le de communication OSI . . . . . . e Rseaux locaux . . . . . . . . . . . . . . . . . . . e 3.1 Quest-ce quun LAN ? . . . . . . . . . . . 3.2 WAN - MAN . . . . . . . . . . . . . . . . 3.3 Communications inter-rseaux . . . . . . . e Couche 2 - Liaison (Data Link) . . . . . . . . . . 4.1 Caractristiques dEthernet . . . . . . . . e 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 Dirences Ethernet - 802.2/802.3 . . . . . e Interconnexion - Technologie lmentaire . . . . . ee 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 Rpteur . . . . . . . . . . . . . . . . . . . e e 5.3 Concentrateur . . . . . . . . . . . . . . . . 5.4 Ponts . . . . . . . . . . . . . . . . . . . . 5.5 Commutateurs . . . . . . . . . . . . . . . 5.6 Passerelles Routeurs . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . Introduction ` IP a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 Caractristiques de TCP/IP . . . . . . . e 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 de ladresse . . . . . . . . . e 1.2 Dlivrance des adresses IPv4 . . . . e 2 Anatomie dune adresse IP . . . . . . . . . 2.1 Dcomposition en classes . . . . . . e 2.2 Adresses particuli`res . . . . . . . . e 2.3 Sous-rseaux . . . . . . . . . . . . . e 2.4 CIDR . . . . . . . . . . . . . . . . 2.5 Prcisions sur le broadcast . . . . . e 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-tte . . . . . . . e 1.2 Network Byte Order . . . . . . . 1.3 Description de len-tte . . . . . . e 1.4 Fragmentation IP - MTU . . . . 1.4.1 Fragmentation . . . . . 1.4.2 Rassemblage . . . . . . e Protocole ARP . . . . . . . . . . . . . . 2.1 Fonctionnement . . . . . . . . . . 2.2 Format du datagramme . . . . . 2.3 Proxy ARP . . . . . . . . . . . . Protocole RARP . . . . . . . . . . . . . Protocole ICMP . . . . . . . . . . . . . . 4.1 Le syst`me de messages derreur . e 4.2 Format des messages ICMP . . . 4.3 Quelques types de messages ICMP Protocole IGMP . . . . . . . . . . . . . . 5.1 Description de len-tte . . . . . . e 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 Dcouverte de routeur et propagation de routes . . e 6.5 Message ICMP redirect . . . . . . . . . . . . . 6.6 Interface de loopback . . . . . . . . . . . . . . Finalement, comment a marche ? . . . . . . . . . . . . . . c 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-tte . . . . . . . . . . . . . . . . e 1.3 Ports rservs ports disponibles . . . . . . . . . e e 1.3.1 Attribution des ports ancienne mthode e 1.3.2 Attribution des ports nouvelle mthode e 2 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . Protocole TCP TCP Transmission Control Protocol . . . 1.1 Caractristiques de TCP . . . . . . e 1.2 Description de len-tte . . . . . . . e Dbut et clture dune connexion . . . . . e o 2.1 Etablissement dune connexion . . 2.2 Clture dune connexion . . . . . . o 2.2.1 Clture canonique . . . . o 2.2.2 Clture abrupte . . . . . . o Contrle du transport . . . . . . . . . . . o 3.1 Mcanisme de lacquittement . . . e 3.2 Fentres glissantes . . . . . . . . . e Complments sur le fonctionnement de TCP e 4.1 Algorithme de Nagle . . . . . . . . 4.2 Dpart lent . . . . . . . . . . . . . e 4.3 Evitement de congestion . . . . . . Paquets capturs, comments . . . . . . . e e Conclusion sur TCP . . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

VI 1

5 6 7

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

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

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

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

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

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

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

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

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

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

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

viii

` TABLE DES MATIERES

Rseaux IP avancs e e

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`me autonome . . . . . . . . . e 1.2 Vecteur de distances vs Etat de liens . . . . . 2 Routage avec RIP . . . . . . . . . . . . . . . . . . . . 2.1 En fonctionnement . . . . . . . . . . . . . . . 2.1.1 Horizon partag ou Split horizon . . e 2.1.2 Mises ` jour dclenches ou Triggered a e e 2.2 Le protocole RIPv1 vs RIPv2 . . . . . . . . . 2.3 Algorithme Bellman-Ford . . . . . . . . . . . 2.3.1 Mtrique . . . . . . . . . . . . . . . e 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 tats . . . . . . . e 3.3.1 Valeur des tats de liens . . . . . . . e 3.4 Calcul du plus court chemin . . . . . . . . . . 3.5 Hirarchie de routeurs . . . . . . . . . . . . . e 3.6 Fonctionnement ` lintrieur dune zone . . . . a e 3.6.1 Voisinage et adjacence . . . . . . . . 3.7 Protocole HELLO . . . . . . . . . . . . . . . . 3.7.1 Cinq types de paquets . . . . . . . . 3.7.2 En-tte standard des paquets OSPF e 3.7.3 En-tte des paquets HELLO . . . . . e 4 Bibliographie . . . . . . . . . . . . . . . . . . . . . . e VIII Elments de rseaux e 1 Htes ou services virtuels . . . . . . . . . . . . . . . o 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 rsum . . . . . . . . . . e e 2.2.3 Comment utiliser IPsec ? . . . . . . 2.2.4 Implmentation dIPsec . . . . . . e 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 rseau priv . e 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 Gnralits sur le serveur de noms . . . . . . . . . e e e 1.1 Bref historique . . . . . . . . . . . . . . . 1.2 Syst`me hirarchis de nommage . . . . . e e e 1.2.1 Domaine & zone . . . . . . . . . 1.2.2 Hirarchie des domaines . . . . . e Fonctionnement du DNS . . . . . . . . . . . . . . 2.1 Convention de nommage . . . . . . . . . . 2.1.1 Completion . . . . . . . . . . 2.2 Le Resolver . . . . . . . . . . . . . . . 2.3 Stratgie de fonctionnement . . . . . . . . e 2.3.1 Interrogation locale . . . . . . . . 2.3.2 Interrogation distante . . . . . . 2.3.3 Interrogation par procuration 2.4 Hirarchie de serveurs . . . . . . . . . . . e 2.5 Conversion dadresses IP en noms . . . . . 2.6 Conclusion . . . . . . . . . . . . . . . . . . Mise ` jour dynamique . . . . . . . . . . . . . . . a Scurisation des changes . . . . . . . . . . . . . . e e 4.1 TSIG/TKEY pour scuriser les transferts . e 4.1.1 TSIG . . . . . . . . . . . . . . . 4.1.2 TKEY . . . . . . . . . . . . . . . 4.2 DNSSEC pour scuriser les interrogations e 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 lectronique e Gnralits sur le courrier lectronique . . . . . . . . . . e e e e 1.1 Mtaphore du courrier postal - Lenveloppe . . . e 1.2 Adresse lectronique . . . . . . . . . . . . . . . . e Format dun E-mail - RFC 822 . . . . . . . . . . . . 2.1 Quelques champs couramment rencontrs dans les e ttes . . . . . . . . . . . . . . . . . . . . . . . . . e 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 lectronique . . . . . . . e 3.4 Courriers indsirables - Le spam . . . . . . . . . . e 3.4.1 Caractriser le spam . . . . . . . . . . . e 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`me dexploitation . . . . . e 4.3 Le cas de POP . . . . . . . . . . . . . . . . . . . 4.4 Le cas de IMAP . . . . . . . . . . . . . . . . . . . Conguration du Sendmail . . . . . . . . . . . . . . . . . 5.1 Conguration ` laide de M4 . . . . . . . . . . . . a 5.2 Conguration manuelle . . . . . . . . . . . . . . . 5.2.1 R`gles de rcriture . . . . . . . . . . . e ee 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 rseaux avec SNMP e 1 Ncessit dun outil . . . . . . . . . . . . . . . . . . . . . e e 1.1 Problmatique de lISO . . . . . . . . . . . . . . . e 1.2 Syst`me de gestion de rseau . . . . . . . . . . . e e 1.3 SNMP Simple Network Management Protocol 1.4 Historique du protocole SNMP . . . . . . . . . . 1.5 Vocabulaire et architecture . . . . . . . . . . . . . 1.6 Direntes versions . . . . . . . . . . . . . . . . . e 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 donnes lmentaires . . . . . . . . . . . e ee

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 Gnralits sur les sockets de Berkeley e e e 1 Gnralits . . . . . . . . . . . . . . . . . . . . . . e e e 2 Prsentation des sockets . . . . . . . . . . . . . . . e 3 Etude des primitives . . . . . . . . . . . . . . . . . 3.1 Cration dune socket . . . . . . . . . . . . . e 3.1.1 Valeur retourne par socket . . . . e 3.2 Spcication dune adresse . . . . . . . . . . e 3.2.1 Spcication dun numro de port . e e 3.2.2 Spcication dune adresse IP . . . e 3.2.3 La primitive bind . . . . . . . . . 3.2.4 Les structures dadresses . . . . . . 3.2.5 Valeur retourne par bind . . . . . e 3.3 Connexion ` une adresse distante . . . . . . a 3.3.1 Mode connect . . . . . . . . . . . e 3.3.2 Mode datagramme . . . . . . . . . 3.3.3 Valeur retourne par connect : . . e 3.4 Envoyer des donnes . . . . . . . . . . . . . e 3.4.1 Envoi en mode connect . . . . . . e 3.4.2 Envoi en mode datagramme . . . . 3.5 Recevoir des donnes . . . . . . . . . . . . . e 3.5.1 Reception en mode connect . . . . e 3.5.2 Recevoir en mode datagramme . . 3.6 Spcier une le dattente . . . . . . . . . . e 3.7 Accepter une connexion . . . . . . . . . . . 3.8 Terminer une connexion . . . . . . . . . . . 4 Schma gnral dune session clientserveur . . . . e e e

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 Complments sur les sockets Berkeley e 275 1 Rservation des ports . . . . . . . . . . . . . . . . . . . . . . . 275 e 1.1 Rservation de port Ancienne mthode . . . . . . . 276 e e 1.2 Rservation de port Nouvelle mthode . . . . . . . . 276 e e 2 Ordre des octets sur le rseau . . . . . . . . . . . . . . . . . . 277 e 3 Oprations sur les octets . . . . . . . . . . . . . . . . . . . . . 278 e 4 Conversion dadresses . . . . . . . . . . . . . . . . . . . . . . . 279 4.1 Conversion dadresse - IPv4 seul . . . . . . . . . . . . . 279 4.2 Conversion dadresse - Compatible IPv4 et IPv6 . . . . 279 5 Conversion hte adresse IPv4 . . . . . . . . . . . . . . . . . 280 o 5.1 Une adresse IP ` partir dun nom dhte . . . . . . . . 280 a o 5.2 Un nom dhte ` partir dune adresse IP . . . . . . . . 282 o a 6 Conversion N de port service . . . . . . . . . . . . . . . . . 282 6.1 Le numro ` partir du nom . . . . . . . . . . . . . . . 282 e a 6.2 Le nom ` partir du numro . . . . . . . . . . . . . . . 284 a e 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 rsum . . . . . . . . . . . . . . . . . . . . 287 e e 7.1.5 Exemple dusage ` la place de gethostbyname 288 a 7.1.6 Exemple dusage ` la place de getservbyname 290 a 7.1.7 En rsum . . . . . . . . . . . . . . . . . . . . 290 e e 8 Conversion nom de protocole N de protocole . . . . . . . . 291 9 Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 10 Exemples de mise en application . . . . . . . . . . . . . . . . . 293 10.1 Ancienne mthode (usage de gethostbyname) . . . . . 293 e 10.2 Nouvelle mthode (usage de getaddrinfo) . . . . . . . 298 e 11 Conclusion et bibliographie . . . . . . . . . . . . . . . . . . . . 300 XIV 1 e Elments de serveurs Type de serveurs . . . . . . . . . . . . 1.1 Serveurs itratif et concourant . e 1.2 Le choix dun protocole . . . . . 1.2.1 Mode connect . . . . e 1.2.2 Mode datagramme . . 1.3 Quatre mod`les de serveurs . . e Technologie lmentaire . . . . . . . . ee 2.1 Gestion des tches esclaves . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 301 301 302 302 303 303 307 307

` TABLE DES MATIERES 2.2 fork, vfork et rfork . . . . . . . . . . . . 2.3 Processus lgers, les threads . . . . . e 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 Prsentation de inetd . . . . . . . . . . e 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 dchange avec http . . . . . e 1.2 Structure dun change . . . . . . . . . e 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 requtes . . e 3.2.3 Deux types de CGIs . . . . . 4 Principe de fonctionnement des CGIs . . . . . 4.1 CGI Mthode GET, sans argument e 4.2 CGI Mthode GET, avec arguments e 4.3 CGI Mthode POST . . . . . . . . e 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 gnral & Annexes e e

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`le en 7 couches de lOSI . . . . . . . . . e Exemple de LANs . . . . . . . . . . . . . . . . trame Ethernet . . . . . . . . . . . . . . . . . Dirences Ethernet 802.2/802.3 . . . . . . . . e Interconnexion - Technologie lmentaire . . . ee Prise vampire . . . . . . . . . . . . . . . . . . Technologie de liaison . . . . . . . . . . . . . . Plusieurs rpteurs mais toujours le mme lan e e e 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 Dcomposition en classes . . . . . e Sous-rseaux . . . . . . . . . . . . e Puissances de 2 . . . . . . . . . . . Adresses de multicast . . . . . . . Adresse physique de multicast . . . Usage combin des adresses logique e Structure du datagramme IP . . . Big endian vs Little endian Fragmentation IP . . . . . . . . . . Fragment ` transmettre . . . . . . a Rsum de la fragmentation . . . . e e Question ARP . . . . . . . . . . . Rponse ARP . . . . . . . . . . . . e 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-tte IGMP . . . . . . . . . . . . . . e Fonctionnement IGMP . . . . . . . . . . Table de routage . . . . . . . . . . . . . Situation rseau lors du netstat . . . . e 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 Numro de port comme numro e e UDP encapsul dans IP . . . . e Structure de len-tte UDP . . e Cas du checksum non nul . . . TCP encapsul dans IP . . . . e Structure de len-tte TCP . . e Etablissement dune connexion Clture dune connexion . . . . o Emission dun rst . . . . . . . . Mcanisme de lacquittement . e Principe de la fentre glissante e Dtail de la fentre glissante . . e e Exemple de fentre glissante . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 extrieur, le monde intrieur ! . . . . . . . 111 e e La route vers H depuis R a une mtrique de 2 et passe par R1113 e Fonctionnement lmentaire . . . . . . . . . . . . . . . . . . 115 ee L horizon partag ne rsout pas tout ! . . . . . . . . . . 116 e e RIP est transport par UDP/IP . . . . . . . . . . . . . . . . 118 e Format dun message RIPv2 . . . . . . . . . . . . . . . . . . 118 Relation dordre entre deux LSP . . . . . . . . . . . . . . . 125 Propagation des LSP par inondation ou ooding . . . . 126 Organisation en zones Hirarchie de routeurs . . . . . . . 128 e Propagation dun LSP, sans et avec un DR . . . . . . . . . . 129 Organisation globale de len-tte du protocole OSPF . . . . 132 e En-tte standard de 24 octets . . . . . . . . . . . . . . . . . 133 e En-tte du paquet HELLO . . . . . . . . . . . . . . . . . . 134 e Serveur HTTP virtuel Tunnel IP - Principe . Tunnel IP - cas concrt e En-ttes dIPsec . . . . e 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 numro de port) . . . . . . . . . . . . . . . . . . . . . . . e 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 hirarchique des domaines e Le resolver dans son environnement Subdivision hirarchique des domaines . e Interrogation locale . . . . . . . . . . . . Interrogation distante . . . . . . . . . . Rponse ` une requte non formule . . e a e e 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`me dexploitation e Le cas de POP . . . . . . . . . . . . . . . . . . . . . Concentration du mail sur un mailhub . . . . . . R`gles de rcriture . . . . . . . . . . . . . . . . . . e ee

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`se graphique des compteurs ifInOctets et e ifOutOctets sur 24h . . . . . . . . . . . . . . . . . . . . . . XI.07 Exemple dcran de surveillance avec tkined . . . . . . . e XII.01 XII.02 XII.03 XII.04 XII.05 Les sockets, une famille de primitives . . . . . Relation pile IP, numro de port et process ID e 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 rseau . . . . . . . . . . . . . . . . . 277 e

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

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

Structure dun message HTTP . . . Environnement syst`me . . . . . . . e 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-tte IP . . . . . . . . 11 e 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 rseaux privs . . . . . . . . e e Adresses IP avec une signication particuli`re e Partitionnement dune classe C en quatre sous Dtail des quatre sous rseaux dun /26 . . . e e Adresses IP prives, notation du CIDR . . . . e Agrgations rgionales des blocs IP . . . . . . e e Quelques adresses multicasts du LAN . . . . . . . . . . . . . . rseaux e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 37 38 39 40 41 42

IV.01 Bits du champ TOS . . . . . . . . . . . . . . . . . . . . . . 49 IV.02 En-tte des fragments IP vs en-tte datagramme original . . 54 e e 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-tte TCP) . . . . . . . . . . 92 e VII.01 Quelques valeurs dtats de liens pour OSPF . . . . . . . . . 127 e X.01 Quelques champs couramment rencontrs dans un tte de e e mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

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

xx

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

Prface e
Attention ! Ce document nest quun support de cours, cest ` dire quil ne remplace pas les documents a cits dans la bibliographie qui termine chacun des chae pitres qui le composent.
Evidement imparfaites, pleines derreurs involontaires, et surtout incompl`tes, ces pages rclament avant tout votre indulgence de lecteur biene e veillant : Rien nest constant, tout change comme le disait dj` Lao Tseu, ea 400 ans avant JC. Que dirait-il alors aujourdhui, concernant les rseaux ! ! e Ces cours saccompagnent de travaux pratiques dont le texte ne gure pas ici, ils sont initialement conus pour les tudiants du Mast`re de Syst`mes c e e e 2 dInformations Ouverts (SIO) de lEcole Centrale Paris, an de les aider ` a la comprhension thorique et pratique des rseaux TCP/IP. e e e

Ce support est en acc`s libre, cest ` dire mis ` la dise a a position de tous pour un usage personnel ou collectif, sans but lucratif. Sa revente, sil y a lieu, ne peut tre e envisage que pour couvrir les frais induits par sa ree production. Enn, sa redistribution sous quelque forme que ce soit, ne peut se concevoir sans cette prface. e
Ne pas hsiter ` me contacter en cas de doute sur lusage : e a Franois Laissus <fr.laissus@laissus.fr> c En aucun cas lauteur ne pourra tre tenu responsable des consquences e e de lusage de ce document, qui est fourni tel quel et sans garantie daucune sorte. Lusage des informations contenues est donc plac sous la responsabilit e e pleine et enti`re du lecteur. e Enn, si vous pensez que la lecture de ce support vous a apport quelque e chose, que vous avez une remarque ` me faire, ou tout simplement me coma plimenter (a fait toujours plaisir quoi que lon puisse en dire ! :) sentez-vous c libres de menvoyer un courrier lectronique, je suis toujours ravi dapprendre e que ce travail a pu servir ! Enn merci de votre intrt pour ce document, jesp`re que vous y trouee e verez ce que vous cherchez !
2

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

xxii

Prface e

Premi`re partie e Introduction ` la pile ARPA a

Chapitre I Rseaux locaux e

1 Prambule e

Ce cours nest pas un cours gnral sur les rseaux mais une prsentation e e e e minimale de cette technologie pour pouvoir aborder le cours de concepts et programmation TCP/IP sous UNIX. TCP/IP est le protocole le plus rpandu dans le monde grce ` lInternet. e a a En 1980 il ne comptait que quelques dizaines dhtes, en juin 1996 ce o nombre tait de 12 millions de machines, rparties en pr`s de 500 000 rseaux e e e e (Par comparaison, en fvrier 1995, les mmes chires taient 4 850 000 mae e e chines pour plus de 71 000 rseaux locaux). e En janvier 2003, le nombre de machines1 directement accessibles sur le rseau tait de 180 000 000 selon lISC2 . Depuis on ne compte plus tant e e la croissance est importante. . .Pour la france lAFNIC propose galement e 3 quelques statisques . . .Il nexiste pas de botin gnral du rseau, par e e e contre Bill Cheswick des Bell labs la cartographi, et le rsultat est fascinant : e e
http://www.cheswick.com/ches/map/gallery/index.html

2
2.1

Gnralits - LANs e e e
Gnralits e e e

Un rseau informatique met en relation des ordinateurs, comme un rseau e e tlphonique met en relation des personnes. ee Des ordinateurs sont dits en rseaux d`s lors quils partagent une e e technologie qui leur permet de communiquer ensemble. Le plus souvent cette technologie se matrialise physiquement par une e liaison avec un cble conducteur. Sur ce type de support, un signal lectrique a e
1 2

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

Rseaux locaux e vhicule les messages informatiques. Il existe dautres types de supports en e pleine expansion comme les liaisons par ondes hertziennes, rayon laser, infrarouge. . . Sans connaissance pralable concernant les rseaux informatiques on peut e e imaginer quantit dinterrogations ` partir de cette hypoth`se de raccordee a e ment : Comment reconnaitre un correspondant ? Comment dialoguer avec ? Comment diuser linformation ` plusieurs correspondants ? a Comment viter la cacophonie ? e Il y a til une hirarchie des machines ? e Il y a til un chef dorchestre ? ... Toutes ces questions (et bien dautres) trouveront une rponse dans ce e cycle de cours. Ces rponses sont gnralement formules dans un proe e e e tocole , une sorte de mode demploi des rseaux. Il y a des centaines de e protocoles dirents sur lInternet, certains sont tr`s populaires, dautres abe e solument pas.

2.2

Mod`le de communication OSI e

Le concept de base de tout ce cours est celui de la commutation de a paquets , une vieille ide de linformatique4 contrairement ` lapproche par e circuits virtuels plus utilise en tlphonie. e ee Les donnes ` transmettre dune machine ` une autre sont fragmentes e a a e ` lmission en petit blocs de quelques centaines doctets munis de ladresse a e du destinataire, envoyes sur le rseau et r-assembles ` la rception pour e e e e a e reproduire les donnes dorigine. e Ce concept facilite le partage des possibilits physiques du rseaux (bande e e passante) et est parfaitement adapt pour une implmentation sur machines e e squentielles travaillant en temps partag (plusieurs communications peuvent e e alors avoir lieu simultanment et sur une mme machine). e e Partant de ce concept, un mod`le darchitecture pour les protocoles de e communication a t dvelopp par lISO (International Standards Organisaee e e tion) entre 1977 et 1984. Ce mod`le sert souvent de rfrence pour dcrire la e ee e structure et le fonctionnement des protocoles de communication, mais nest pas une contrainte de spcication. e Ce mod`le se nomme OSI comme Open Systems Interconnection Ree ference Model . Les constituants de ce mod`le sont si largement employs e e quil est dicile de parler de rseaux sans y faire rfrence. e ee ` Le mod`le OSI est constitu de sept couches. A chaque couche est ase e socie une fonction bien prcise, linformation traverse ces couches, chacune e e y apporte sa particularit. e Cette forme dorganisation nest pas de au hasard, cest celle sur lau
4

Conu par lAmricain Paul Baran et publi en 1964 c e e

Gnralits - LANs e e e quelle les informaticiens ont beaucoup travaill dans les annes soixantes e e pour dnir les caractristiques des syst`mes dexploitation. e e e Une couche ne dnit pas un protocole, elle dlimite un service qui peut e e tre ralis par plusieurs protocoles de direntes origines. Ainsi chaque e e e e couche peut contenir tous les protocoles que lon veut, pourvu que ceux-ci fournissent le service demand ` ce niveau du mod`le. ea e Un des intrts majeurs du mod`le en couches est de sparer la notion de ee e e communication, des probl`mes lis ` la technologie employe pour vhiculer e e a e e les donnes. e Pour mmoire (gure I.01) : e 7 La couche application (Application layer) est constitue des programmes e dapplication ou services, qui se servent du rseau. Ils ne sont pas e forcment accessibles ` lutilisateur car ils peuvent tre rservs ` un e a e e e a usage dadministration. 6 La couche de prsentation (Prsentation layer) met en forme les donnes e e e suivant les standards locaux ou particuliers ` lapplication. Comme, a par exemple passer dune reprsentation big endian ou ` une e a reprsentation little endian ou encore plus complexe comme celle e dcrite pas les XdR (eXternal Data Representation) et qui autorise e la transmission de types abstraits de donnes (structures complexes, e arbres, listes chaines, la liste nest pas limitative. . .). e 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 simultanment ` travers le mme ordie a e nateur connect et le mme rseau. Deux utilisateurs dune mme mae e e e chine peuvent utiliser la mme application sans risque dinter-actions e parasites. 4 La couche de transport (Transport layer) garantie que le destinataire obtient exactement linformation qui lui a t envoye. Cette couche met ee e par exemple en uvre des r`gles de renvoi de linformation en cas dere reur de rception. e 3 La couche rseau (Network layer) isole les couches hautes du mod`le qui e e ne soccupent que de lutilisation du rseau, des couches basses qui ne e soccupent que de la transmission de linformation. 2 La couche de donne (Data link layer) eectue le travail de transmission e des donnes dune machine ` une autre. e a 1 La couche Physique (Physical layer) dnit les caractristiques du matriel e e e ncessaire pour mettre en euvre le signal de transmission, comme des e tensions, des frquences, la description dune prise. . . e
5

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

6 Mod`le en 7 couches de lOSI e

Rseaux locaux e

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`le en 7 couches de lOSI e

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 prc`de et celle qui la suit, avec le cas particulier des couches 1 et 7. e e Lintrt de travailler en couches est que lorsque les modalits dchanges ee e e entre chacune dentres elles sont prcisment dcrites, on peut changer lime e e plmentation et les spcicits de la couche elle-mme sans que cela aecte e e e e le reste de ldice. e Cest sur ce principe quest btie la suite de protocoles dsigne par a e e TCP/IP Quand deux applications A et B discutent entre-elles via le rseau, les e informations circulent de la couche 7 vers la couche 2 quand lapplication A envoie de linformation sur le rseau, et de la couche 2 vers la couche 7 pour e que lapplication B reoive linformation de A. c Le principe de base de cette discussion repose sur le fait que chaque couche du mod`le de la machine A est en relation uniquement avec son homologue e du mme niveau de la machine B. e Quand linformation descend de la couche 7 vers la couche 1, chaque couche en-capsule les donnes reues avant de les transmettre. Ainsi le e c volume dinformations sest accr de quelques centaines doctets arriv ` la u ea couche 1. De mani`re symtrique, quand linformation remonte de la couche phye e sique vers la couche Application, chaque couche prl`ve les octets qui lui sont ee propres, ainsi lapplication B ne voit-elle que les octets envoys par lapplie cation A, sans le dtail de lacheminement. e

3 Rseaux locaux e

Rseaux locaux e

Le probl`me intuitif et pratique qui se pose est de relier entre elles par un e cble toutes les machines qui veulent communiquer : cest impossible dabord a pour des raisons techniques, le monde est vaste, puis de politique demploi des ressources du rseau, tel rseau qui sert ` lenseignement ne doit pas pas e e a perturber le fonctionnement de tel processus industriel. La consquence est que les rseaux se dveloppent dabord en local, autour e e e dun centre dintrt commun, avant de se tourner (parfois) vers lextrieur. ee e

3.1

Quest-ce quun LAN ?

Le terme rseau local nest pas clairement dni, cependant tout le e e monde saccorde ` baptiser de la sorte un rseau, d`s lors quon lui reconnait a e e les caractristiques suivantes : e Cohabitation de plusieurs protocoles, Un mme mdia (mme cble par exemple) qui raccorde de multiples e e e a machines, peut tre de caractristiques direntes, e e e Une bande passante leve, partage par tous les htes e e e o La capacit de faire du broadcasting et du multicasting , e Une extension gographique de moins en moins limite, e e Un nombre de machines raccordes limit, e e Des relations entre les machines places sur un mode dgalit, (et non e e e par exemple sur un mode Ma tre/Esclave comme dans un rseau dont e la topologie serait en toile), e Une mise en uvre qui reste du domaine priv, cest ` dire qui ne e a dpend pas dun oprateur ociel de tlcommunications. e e ee Notez que les notions de bande passante et nombre limit (etc. . .) e sont volontairement qualitatives. Elles voluent rapidement avec le temps. e

Machine sur le LAN

gure I.02 Exemple de LANs Exemple de types de technologies utilises dans les LANs : e Token ring

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

Rseaux locaux e

3.2

WAN - MAN

Un WAN (Wide Area Network) dsigne des ordinateurs connects entre e e direntes villes (Metropolitan Area Network) ou pays. La technologie utie lise est traditionnellement moins performante que celle dun LAN, cest par e exemple une ligne tlphonique loue fonctionnant ` 64 kbps, une liaison ee e a RNIS, ou encore une liaison transatlantique ` 1Mbits/secondes. a Les amliorations technologiques apportes aux LANs permettent de les e e tendre de plus en plus gographiquement, celles apportes aux WAN auge e e mentent considrablement les bandes passantes, ces deux tendances font que e la distinction entre ces deux types de rseaux est de moins en moins claire. e

3.3

Communications inter-rseaux e

Les rseaux sont appels ` communiquer entres eux et quand cela se e e a produit on parle de communications inter-rseaux ( internetworking ). e Le rle dune communication inter-rseaux est de gommer les ventuelles o e e dirences de technologie dchange pour permettre ` deux rseaux, ou plus, e e a e le partage de ressources communes, lchange dinformations. e Un moyen de faire communiquer deux rseaux distincts passe par lutilie sation de gateway ou passerelle. Un tel dispositif est parfois appel routeur (router), mais cest un abus e de langage. Les hommes se connectent sur les ordinateurs Les ordinateurs se connectent sur un rseau e Les rseaux sinter-connectent dans un internet e

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 en 1982 par DEC, Intel Corp. e et Xerox. Cette technique repose sur une mthode dacc`s et de contrle dite e e o CSMA/CD ( Carrier Sense, Multiple Access with Collision Detection ). Elle est devenue tellement populaire quon parle dun cble Ethernet, a dune adresse Ethernet, dune liaison Ethernet. . . Plus tard lIEEE ( Institute of Electrical and Electronics Engineers ) 6 sous linstance de son commit 802, publia un ensemble de standards e lg`rement dirents, les plus connus concernant la couche 2 sont 802.2 e e e (Contrle logique de la liaison LLC7 ) et 802.3 (CSMA/CD) o Dans le monde TCP/IP, lencapsulation des datagrammes IP est dcrite e dans la RFC 894 [Hornig 1984] pour les rseaux Ethernet et dans la RFC 1042 e [Postel et Reynolds 1988] pour les rseaux 802. e En r`gle gnrale, toute machine utilisant TCP/IP sur ce type de rseaux e e e e doit : 1. tre capable denvoyer et de recevoir un paquet conforme ` la RFC 894, e a 2. tre capable de recevoir des paquets conformes aux deux standards, e 3. Par contre il est seulement souhaitable que cette machine soit capable denvoyer des paquets conformes ` la RFC 1042. a Par dfaut le standard est donc celui de la RFC 894, si une machine peut e faire les deux, cela doit tre congurable. e De nos jours la couche 802.11 (rseau sans l - wi) voit sa popularit e e cro tre tr`s vite. Elle est base sur une mthode dacc`s assez proche, le e e e e CSMA/CA ( Carrier Sense, Multiple Access with Collision Avoidance ). En eet les collisions ne peuvent pas toujours tre dtectes car les htes ne e e e o sont pas ncessairement ` porte radio directe. Les changes, quand ils ne e a e e sont pas de type point ` point , passent par un intermdiaire nomm en a e e gnral point dacc`s ce qui complique le protocole, et donc la trame, par e e e rapport au CSMA/CD.

4.1
4.1.1

Caractristiques dEthernet e
Quelques principes fondamentaux

1. Le support de transmission est un Segment = bus = cble coaxial. Il a ny a pas de topologie particuli`re (boucle, toile, etc. . .). e e 2. Un quipement est raccord sur un cble par un transceiver : e e a 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

Rseaux locaux e 3. Sur le cable circulent des trames, autant de paquets de bits. Il ny a pas de multiplexage en frquence, pas de full duplex 8 . Une trame mise e e par une station est reue par tous les coupleurs du rseau Ethernet, elle c e contient ladresse de lmetteur et celle du destinataire. e 4. Un coupleur doit tre ` lcoute des trames qui circulent sur le cble. Un e a e a coupleur connait sa propre adresse, ainsi si une trame lui est destine e il la prend, sinon il nen fait rien. 5. Une station qui veut mettre attend que toutes les autres stations se e taisent. Autrement dit, si le cble est libre elle envoie sa trame, sinon a elle attend. Si deux stations mettent en mme temps il y a collision. Les deux e e trames sont alors inexploitables, les deux (ou plus) stations dtectent e ce fait et remettent ultrieurement leur paquet en attente. e e 6. Un rseau Ethernet est donc un rseau ` caract`re probabiliste car il ny e e a e a pas de chef dorchestre pour synchroniser les missions. Cette absence e conduit ` dire que cest un rseau galitaire, une sorte de runion sans a e e e animateur entre personnes polies En conclusion, la technologie Ethernet est simple, sa mise en uvre se fait ` faible cot. Points ` retenir : a u a Simplicit et faible cot e u Peu de fonctions optionnelles Pas de priorit e Pas de contrle sur lattitude des voisins o Dbit dau moins 10Mb/s (jusqu` 1000Mb/s thorique). e a e Performances peu dpendantes de la charge, sauf en cas de collisions e 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 possibilits de full duplex que navaient pas leurs anctres des annes 80 e e e
8

Couche 2 - Liaison (Data Link) Quelques considrations en vrac : e D au dbit global de 10Mbits/seconde, le dbit est de 10 bits par u e e micro-seconde (en gros un facteur 1000 avec un cpu). Une trame a une longueur minimale (72) et une longueur maximale (1526). Si les donnes ne sont pas assez longues (46 octets) des carace t`res de remplissage sont ajouts ( padding ). e e Les octets circulent du premier octet du prambule au dernier octet du e CRC. A lintrieur de chaque octet le premier bit envoy est celui de poids e e faible, etc.. Le prambule et le SFD ( Start Frame Delimiter ) servent ` la syne a chronisation. Adresses dorigine et de destination sont celles respectivement de la machine mettrice et de la machine destinatrice. e Remarque importante : il faut conna ladresse de son correspondant tre ` pour pouvoir lui envoyer un paquet ! A ce stade de lexpos on ne sait e pas encore comment faire quand on ignore cette information. Le champ type est deux octets qui dsignent le type des donnes e e encapsules : e Type Donnes e 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 code sur 6 octets soit 48 bits. e Pour un hte sur un rseau, cette adresse est ce que lon appelle son adresse o e physique ( hardware addresse ) par opposition ` son adresse logique qui a interviendra lors de lexamen de la couche 3. En fait cette adresse est divise en deux parties gales, les trois premiers e e octets dsignent le constructeur, cest le OUI ( Organizationally Unique e Identier ) distribu par lIEEE 9 les trois derniers dsignent le numro de e e e carte, dont la valeur est laisse ` linitiative du constructeur qui poss`de le e a e prxe. e LIEEE assure ainsi lunicit de lattribution des numros de construce e 10 24 teurs, par tranches de 2 cartes Chaque constructeur assure lunicit du numro de chaque carte fae e
http://standards.ieee.org/regauth/oui/index.shtml La liste ` jour est accessible ` cette url http://standards.ieee.org/regauth/oui/ a a a oui.txt ou ` la n de la RFC 1700 (page 172) Ethernet vendors address components
10 9

12

Rseaux locaux e brique. Il y a au maximum 224 cartes par classe dadresses. e Cette unicit est primordiale car le bon fonctionnement dun LAN requiert e que toutes les stations aient une adresse physique dirente. Dans le cas e contraire le rseau et les applications qui lutilisent auront un comportement e imprvisible le rendant impraticable. e Nous aurons loccasion de rencontrer ` nouveau ce soucis dunicit de a e 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 htes virtuels, page 137. o Exemple dadresse physique en reprsentation hexadcimale : e e 08:00:09:35:d5:0b 08:00:09 est attribu ` la rme Hewlett-Packard ea 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, capturs au hasard des rseaux : e e 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 couter toutes les trames qui leur parviennent. Beaucoup dentres elles ne e leur sont pas destines, et sil fallait que le syst`me dexploitation qui g`re e e e linterface rseau sinterrompt ` chaque fois pour les examiner, il ne serait pas e a tr`s utilisable pour les applications de lutilisateur, parceque tout le temps e interrompu par ces vnements rseau. e e e Pour viter cette situation, le logiciel embarqu dans linterface rseau est e e e paramtr (par le syst`me dexploitation) pour ltrer les paquets non voulus e e e car non ncessaires au bon fonctionnement en rseau. Ce param`trage peut e e e changer dune station ` une autre. a Il est galement possible de ne pas ltrer, cest une proprit utilise e ee e 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 constitue de la combinaison de 48 bits qui la e rend unique. Ce mode dadressage est typique dchanges entre deux e 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 carter les autres trames de type unicast. e

Couche 2 - Liaison (Data Link) broadcast Tous les bits de ladresse MAC sont ` 1. a Toutes les stations dun rseau sont destinatrices de tels paquets, que e leur ltrage doit laisser passer, avec les inconvients cits prcdemment. e e e Ce mode dadressage ne devrait tre utilis par les protocoles quuniquee e ment quand il nest pas possible de faire autrement. Par exemple pour obtenir une information que seule une station inconnue sur le LAN poss`de. Cest le cas des protocoles ARP et RARP (cf cours ARP/e RARP pages 55 et 58) Utilis abusivement, le broadcast est une gne. e e multicast Il existe un prxe particulier 01:00:5E, non ddie ` un e e e a constructeur car dit de multicast , que nous examinerons dans le cas dIP page 42. Ce mode de dadressage est rserv le plus gnralement ` la dcouverte e e e e a e passive (par lcoute de messages davertissement) ou ` la recherche e a (par lmission de messages de sollicitation) de voisins de LAN ayant e des proprits particuli`res. ee e Le ltrage des sollicitations et leurs rponses peut tre congur ` la e e ea carte sur chaque station, en fonction des impratifs et besoins de fonce tionnement. Ce mode de fonctionnement est assez conome des ressources du rseau, e e puisquune seule station met une information qui est traite par toutes e e celles qui sont intresses, et elles seules. e e Toutes les adresses qui ne sont ni du type broadcast ni du type multicast sont du type unicast.

13

4.2

Dirences Ethernet - 802.2/802.3 e

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

6
dest.

6
source

RFC 894

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

14

Rseaux locaux e Tous les numros de protocole sont suprieurs ` 150011 qui est la lone e a gueur maximale des donnes encapsules. Donc une valeur infrieure e e e ou gale ` ce seuil indique une trame 802.3. e a MAC = Medium Access Control Cette couche est concerne par la gestion de ladresse physique de la e technologie de LAN employe (comme token-ring par exemple) e LLC = Logical Link Control Dnit ce qui est ncessaire aux multiples couches suprieures possibles e e e pour utiliser et partager les ressources du lan en mme temps. e Le commit 802.2 a galement prvu plusieurs options, dont deux prine e e cipalement utilises : e LLC type 1 Les trames sont dlivres en mode datagramme cest ` dire selon e e a le principe du best eort (on fait au mieux sans garantie de rsultat). e LLC type 2 Les trames sont dlivres avec une garantie de bon acheminement. e e Lusage du LLC de type 2 entra lajout de champs dans lenne tte pour numroter les paquets, ajouter des acquittements, des e e synchronisations, etc. . .Cest le protocole HDLC comme Highlevel Data Link Control . Un travail qui est normalement dvolu ` la couche de transport et e a qui donc parasite beaucoup la lisibilit de lensemble. e

Interconnexion - Technologie lmentaire ee

LLC MAC Cable transceiver Carte coupleur Ethernet Cable coaxial

Bus de station

Couche rseau

Couche liaison

Couche physique

gure I.05 Interconnexion - Technologie lmentaire ee

Le plus petit numro de protocole est celui dIP : 0800 hexadcimal. Ce qui fait en e e dcimal : 8 162 + 0 161 + 0 160 = 2048 e
11

Interconnexion - Technologie lmentaire ee Linterconnexion ne se limite pas au niveau Ethernet. Quelques notions de technologie de base et donc tr`s succintes sont e ncessaires pour bien comprendre la suite de ce cours. e

15

5.1

Raccordement
Rseau local Prise "vampire" Transceiver

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

Carte rseau

Bus informatique

gure I.06 Prise vampire 5.1.1 10Base5

Quelques particularits du 10Base5 : e Longueur maxi est 500 m`tres, pour un maximum de 100 stations. e Cest une vieille technologie tr`s bien normalise mais dpasse. e e e e Pas de perturbation quand on ajoute une station : la pose dune nouvelle prise ninterrompt pas la continuit du rseau. e e Cot non ngligeable. u e Dplacement dune station non ais, en plus on perd la prise vampire, e e elle reste sur le cble. a Pour les cblages rapides on prf`re le 10Base2 ou Thin Ethernet ou a ee encore Ethernet n (2 comme 200 m`tres). e 5.1.2 10Base2

Quelques particularits du 10Base2 : e Longueur maxi de 185 m`tres avec un maximum de 30 stations. e La topologie impose de mettre les stations en srie avec un minimum e de 0.5 m`tre entre chaque. e Le raccord se fait avec un transceiver en T (BNC bien connu des lectroniciens). e Il faut un bouchon de 50 ohms ` chaque extrmit du rseau (2). a e e e Technique tr`s bon march, souple, les cartes int`grent le transducteur. e e e Il faut rompre la continuit du rseau pour ajouter une nouvelle stae e tion, ce qui lempche de fonctionner durant lopration. Cest un ine e

16

Rseaux locaux e convnient de taille sur un rseau tr`s utilis. e e e e Cette technique est en outre assez sensible aux perturbations lectroe magntiques. e Les dsavantages du 10Base2 imposent gnralement lusage du 10BaseT e e e dans toute structure dpassant quelques machines (5 ` 10). Le 10BaseT r`gle e a e dnitivement le probl`me de lajout ou du retrait dune machine sur le LAN e e (T comme Twisted Pair ou paires torsades). e Cette technique impose lusage dune boite noire rseau nomme e e HUB 12 ou moyeu. Celle-ci simule la continuit dans le cas du retrait e dune station. 5.1.3 10BaseT

Quelques particularits du 10BaseT : e Une double paire torsade de cble sut. e a La longueur maximale entre le moyeu et la station est de 100 m`tres. e Le moyeu impose une architecture en toile. e Le raccordement au transducteur se fait ` laide dune prise du type a RJ45, tr`s fragile (ne pas marcher dessus ! :). Le raccordement du HUB e e (page 18) au reste du rseau se fait par 10Base2, en bre optique, ou tout simplement par cha nage avec un autre HUB ( Daisy chain ). Cette technique est dune tr`s grande souplesse dutilisation elle impose e nanmoins lacquisiton de HUB, tr`s peu onreux de nos jours. e e e Cette technique des paires torsades est tr`s sensible aux perturbations e e lectromagntiques. lectromagntiques. e e e e Aujourdhui le 100BaseT quipe la majeur partie des quipements proe e fessionnels, 100 comme 100 Mbits/s. Enn la bre optique est utilise de plus en plus souvent pour eectuer e les liaisons point ` point. a 5.1.4 Fibre optique

Quelques particularits de la bre optique : e La plus utilise est la bre multimode 62.5/125.0 m e Usage dun transducteur optique pour assurer la transformation entre le signal lumineux (un laser) et le signal lectrique. e La distance maximale entre deux points est 1,5 km. La bre est insensible aux perturbations lectromagntiques, elle pere e met en outre le cblage de site important (plusieurs km2 ). a La bre permet datteindre des vitesses de transmission suprieures e aux 10Mbits/100Mbits/1000Mbits maintenant courants sur des paires de ls en cuivre. Les nouvelles technologies issues des recherches les plus rcentes proe mettent des bres multifrquences (1024 canaux par bre) avec pour e
12

Voir au paragraphe 5.3 page 18

Interconnexion - Technologie lmentaire ee chaque canal une bande passante de plusieurs giga-octets. Ces nouveaux mdias auront une bande passante de plusieurs tra-octets par e e secondes. . . Son principal dsavantage est un cot lev au m`tre (de lordre dune e u e e e dizaine d pour un cble dun m`tre cinquante) et la ncessit davoir a e e e des transducteurs au raccordement de tous les appareils contenant de llectronique (serveur, switch, routeur). Un tel module peut coter de e u lordre de 500 ` 1000  . . . a 5.1.5 Conclusion

17

Construire un rseau local consiste ` juxtaposer des composants de base e a tr`s bien maitris, une sorte de mcano car tous les supports sont mixables. e e e Ne plus installer les technologies les plus anciennes 10Base5, 10Base2 ou mme 10BaseT, prfrer lusage du 100BaseT ou du 1000BaseT qui sont e ee devenus un standard courant du prcablage. e En eet le cblage constitue les fondations dun rseau, le faire proprea e ment dembl vite une source continuelle dennuis pas la suite ! Les besoins ee en bande passante daujourdhui ne prgurent sans doute pas encore les bee soins de demain (vido haute dnition sur tous les postes. . .), il faut donc e e prvoir tr`s large d`s la conception initiale. e e e

Machine A

Machine B

Rseau physique

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

gure I.07 Technologie de liaison

5.2

Rpteur e e

` A une technologie particuli`re correspond forcment des limitations dues e e aux lois de la physique. Par exemple en technologie Ethernet la longueur maximale dun brin ne peut pas excder 180 m`tres. Pour pallier ` cette e e a dcience on utilise des rpteurs ( repeaters ). e e e

18 Rpteurs : e e
Rpteur R

Rseaux locaux e

Brins physiques R diffrents mais meme LAN

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

5.3

Concentrateur
gure I.09 Concentateur
" Backbone "

Un concentrateur (ou HUB , moyeu) : Est aussi nomm toile ou mulee tirpteur. e e Les HUB nont pas dadresse Ethernet, sauf certains mod`les e volus, grables ` distance e e e a (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 lmentaire ee Un hub assure la continuit du rseau sur chacune de ses prises, que lon e e y branche ou pas un hte. En cela il agit uniquement au niveau de la couche o 1 ISO. Il ne limite pas le nombre de collisions et namliore pas lusage de e la bande passante. Son seul intrt est de donc permettre le branchement ou ee le dbranchement des stations sans perturber le fonctionnement global du e rseau. e Les hubs peuvent tre cha es entres-eux ; souvent ils sont relis au backe n e bone local par une autre technologie que la paire torsade (bre optique. . .). e Dans le cas de hubs intelligents les ports sont associs les uns aux e autres par groupes de fonctionnement.

19

5.4

Ponts

La technologie CSMA/CD atteint vite ses limites quand le rseau est ene combr. Une amlioration possible quand on ne peut pas changer de technoloe e gie (augmentation du dbit) est dutiliser un ou plusieurs ponts ( bridges ) e pour regrouper des machines qui ont entre-elles un dialogue privilgi. e 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 par e contre le principe de son fonctionnement se retrouve, entres autres, dans les commutateurs (paragraphe suivant) et dans les points dacc`s sans l e ( wireless ). Dialogue entre deux stations, avec pont :

Pont intelligent

P Meme rseau local

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

20

Rseaux locaux e multipli par deux la capacit globale du trac rseau vis ` vis de certains e e e a changes. e 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 interprtation des octets vhiculs. Le rsultat de ce travail e e e e logique (apprentissage) consiste ` isoler le trac sur certains tronons a c ` cause de ce travail on parle gnralement de ponts dun LAN. A e e intelligents ou de ponts transparents car la phase dapprentissage est automatique ! Rduit le taux de collisions en rduisant le trac inutile, donc amliore e e e 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 ` rien. a 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 ` lidentique. a Un pont contient un cpu, il est en gnral administrable ` distance car e e a 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 rseaux aient des boucles, un protocole e nomm STP ( Spanning Tree Protocol ) dsactive automatiquement e e 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 ` translations . a 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 et de lautre du pont, alors la bande passante globale e du LAN est multiplie par deux. Bien sr cette remarque nest plus e u valable d`s lors quune trame franchit le pont. e

5.5

Commutateurs

Aligner des stations sur un mme rseau local constitue une premi`re e e e tape simple et de faible cot pour un rseau local dentreprise. Le revers e u e dune telle architecture est que le nombre de collisions cro tr`s vite avec t e le trac, do` une baisse tr`s sensible de la rapidit des changes de ` ce u e e e u a gaspillage de la bande passante. Lusage de ponts peut constituer une premi`re solution mais elle nest pas e totalement satisfaisante dans tous les cas de gure, comme nous avons pu le remarquer au paragraphe prcdent. e e Depuis plus dune dizaine dannes est apparue une technologie nomme e e Intelligent Switching Hub (ISH) commutateur intelligent qui utilise

Interconnexion - Technologie lmentaire ee le concept de commutation parall`le et qui a rvolutionn lorganisation des e e e rseaux locaux. e Daspect extrieur ces quipements se prsentent comme un hub mais ont e e e en interne un cpu susamment puissant et un bus interne de donnes sue samment rapide pour mettre en uvre une logique de commutation rane. e Lorsquune trame se prsente sur lun des ports du commutateur elle est e (ou nest pas) re-route vers un autre port en fonction de ladresse physique e du destinataire. Il existe plusieurs dirences entre un pont et un commutae teur : Un commutateur peut mettre simultanment plusieurs ports en relae tion, sans que le dbit de chacun en soure. Par exemple un commue tateur de 8 ports en 100BaseT peut supporter quatre connexions port source/port destination simultanes ` 100 Mbit/s chacune, ce qui donne e a un dbit global de 400 Mbit/s qui doit pouvoir tre support par le bus e e e interne ou fond de panier . Dun point de vue plus thorique, un commutateur ` N ports ` 100 e a a Mbit/s chacun a un dbit maximum de N 100/2 = 50 N M bit/s. e Si une trame est ` destination dun port dj` occup, le commutateur a ea e la mmorise pour la dlivrer sitt le port disponible. e e o Un commutateur fonctionne comme un pont pour tablir sa carte des e adresses mais il peut aussi travailler ` partir dune table prcongure. a e e 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 dorganiser un rseau en fonction de e e la porte des serveurs des postes clients associs. La gure I.12 illustre ce e e principe :
S1 S2 Serveurs gnraux

21

Commutateur intelligent

Hub

Client 1

Serveur local

Client 2

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

22

Rseaux locaux e le trac entre le client 2 et le serveur S1 . De mme le trac entre le e client 1 et le serveur local nest pas vu du client 2 . Les commutateurs tiquettent les trames avec un identicateur du VLAN e auquel elles appartiennent. Cette tiquette se rsume par deux octets ajouts e e e dans la trame, selon les recommandations du comit 802 (norme 802.1Q). e

5.6

Passerelles Routeurs

Pour raccorder deux LANs non forcment contigus il faut faire appel ` e a ce que lon dsigne une passerelle ( gateway ). Son rle est de prendre e o une dcision sur la route ` suivre et de convertir le format des donnes pour e a e tre compatible avec le rseau ` atteindre (en fonction de la route). e e a Souvent, et cest le cas avec TCP/IP, la fonction de conversion nest pas utilise, la fonction de routage donne alors son nom ` lappareil en question e a (ponyme), qui devient un routeur ( router ). e Le probl`me du routage entre A et B : e

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 dcisions de destination. e

6 Bibliographie Poss`de au moins deux interfaces rseau (pas forcment identiques). e e e Contient un cpu et un programme tr`s volu, il est administrable ` e e e a distance. Remplit galement les fonctions dun pont (B-routeur) mais les brins e ainsi relis ne forment en gnral plus un LAN car les adresses physiques e e e contenues dans les trames ne servent plus ` identier le destinataire. Il a faut une autre adresse qui dpend de la pile au-dessus (exemple adresse e IP). Il existe cependant des possibilits de simuler un mme LAN bien e e 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

Rseaux locaux e

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

En 1969 aux Etats Unis, lagence gouvernementale DARPA lance un projet de rseau exprimental, bas sur la commutation de paquets. Ce rseau, e e e e nomm ARPANET, fut construit dans le but dtudier les technologies de e e communications, indpendamment de toute contrainte commerciale1 e Un grand nombre de techniques de communication par modems datent de cette poque. e Lexprience dARPANET est alors si concluante que toutes les organie sations qui lui sont rattaches lutilisent quotidiennement pour pour leurs e messages de service. En 1975, le rseau passe ociellement du stade exprimental au stade e e oprationnel. e Le dveloppement dARPANET ne sarrte pas pour autant, les bases des e e protocoles TCP/IP sont dvelopps ` ce moment, donc apr`s que ARPANET e e a e soit oprationnel. e En Juin 1978 Jon Postel2 dnit IPv4 et en 1981 IP est standardis dans e e la RFC 791 [J. Postel 1981]. En 1983 les protocoles TCP/IP sont adopts comme un standard mie litaire et toutes les machines sur le rseau commencent ` lutiliser. Pour e a faciliter cette reconversion, la DARPA demande ` luniversit de Berkeley a e dimplmenter ces protocoles dans leur version (BSD) dunix. Ainsi come mence le mariage entre ce syst`me dexploitation et les protocoles TCP/IP. e Lapport de lUniversit de Berkeley est majeur, tant au niveau thorique e e (concept des sockets) quau niveau de lutilisateur, avec des utilitaires tr`s e homog`nes qui sint`grent parfaitement au paradigme dusage existant (rcp, e e
Lanc en France en 1972, le projet Cyclades , sous la responsabilit de Louis Pouzin, e e tait galement bas sur la commutation de paquets et lusage de datagrammes. Il reliait e e e quelques grands centres universitaires en France (Lille, Paris, Grenoble,. . .) et en Europe. Il est rest oprationnel jusquen 1978, date ` laquelle faute de crdit il a t abandonn e e a e ee e au prot de X25, prfr par les oprateurs de tlcoms nationaux. eee e ee 2 Jon Postel est dcd le 16 Octobre 1998 ` lge de 55 ans, cest le premier pionner e e e a a de lInternet dcd, on peut consulter par exemple : http://www.isi.edu/postel.html e e e
1

26

Introduction ` IP a rsh, rlogin. . .). Depuis cette poque, un nouveau terme est apparu pour dsigner cette e e interconnexion de rseaux, lInternet, avec un i majuscule. e Le succ`s de cette technologie est alors tr`s important et suscite un e e intrt croissant de la part dacteurs tr`s divers, et en particulier La Naee e tional Science Foundation qui y voit un intrt majeur pour la recherche ee 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 dsigne maintenant un espace de communication qui englobe la plan`te tout e e enti`re. Des millions de sites partout sur la surface du globe y sont connects. e e 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 ` sa popularit fortement croissante et aux a e demandes de transactions scurises, le protocole volue et une nouvelle vere e e sion, la version 6 (IPng puis tout simplement IPv6), est dnie et en cours e de dploiement exprimental. e e Les protocoles dsigns par TCP/IP ont galement envahi les rseaux e e e e locaux eux-mmes, car il est plus facile dutiliser les mmes protocoles en e e interne et en externe. Pour les utilisateurs, lacc`s ` lInternet est possible ` laide dune collece a a tion de programmes spcialiss si faciles ` utiliser que lon peut ignorer tout e e a (ou presque) de leur fonctionnement interne. Seul les programmeurs dapplications rseaux et les administrateurs de e syst`mes ont besoin den conna les arcanes. e tre Les services rseaux les plus populaires sont principalement : e Le courrier lectronique qui permet lchange de messages entres usae e gers. Les innombrables forums de discussion ( news ). Le transfert de chiers entre machines ( ftp et ses drivs comme e e fetch , wget , curl . . .). Le remote login , ou ses quivalents crypts ( ssh , qui permet ` un e e a utilisateur de se connecter sur un site distant, depuis son poste local. Les serveurs inter-actifs. Les anciens se nommaient archie, gopher, veronica, wais... Dsormais ils sont rendus obsol`tes par le web e e (protocole http). Puis maintenant la radio, la vidoconfrence, la ralit virtuelle avec le e e e e VRML, le chat , les bourses dchanges point ` point, les blogs e a forme volue des pages personnelles, etc . . . e e ... En conclusion de ce paragraphe sur lhistorique on peut dire que lInternet est une collection apparemment anarchique (il ny a pas de structure hie
3

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

2 Caractristiques de TCP/IP e rarchique et centralise) de rseaux inter-connects et appartenant ` divers e e e a propritaires. e On distingue trois niveaux : les rseaux au sein des organisations (lans), e les rseaux rgionaux et les rseaux de transit. e e e Le site de lAssociation Fnet indique quelques pointeurs intressants sur e 4 lhistorique de lInternet (en anglais).

27

Caractristiques de TCP/IP e

Le succ`s de TCP/IP, sil vient dabord dun choix du gouvernement e amricain, sappuit ensuite sur des caractristiques intressantes : e e e 1. Cest un protocole ouvert, les sources (C) en sont disponibles gratuitement et ont t dvelopps indpendamment dune architecture paree e e e ticuli`re, dun syst`me dexploitation particulier, dune structure come e merciale propritaire. Ils sont donc thoriquement transportables sur e e nimporte quel type de plate-forme, ce qui est prouv de nos jours. e 2. Ce protocole est indpendant du support physique du rseau. Cela pere e met ` TCP/IP dtre vhicul par des supports et des technologies a e e e aussi dirents quune ligne srie, un cble coaxial Ethernet, une liaie e a son loue, un rseau token-ring, une liaison radio (satellites, wireless e e 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 ` tous les utilisateurs de TCP/IP a quelle que soit la plate-forme qui lutilise. Si lunicit de ladresse est e respecte, les communications aboutissent mme si les htes sont aux e e o antipodes. 4. Les protocoles de hauts niveaux sont standardiss ce qui permet des e dveloppements largement rpandus et inter-oprables sur tous types e e e de machines. La majeurs partie des informations relatives ` ces protocoles sont publies a e dans les RFCs (Requests For Comments). Les RFCs contiennent les derni`res e versions des spcications de tous les protocoles TCP/IP, ainsi que bien e dautres informations comme des propositions damliorations des outils ace tuels, la description de nouveaux protocoles, des commentaires sur la gestion des rseaux, la liste nest pas exhaustive. e

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

28

Introduction ` IP a

Comparaison TCP/IP ISO

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

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 fonctionnalits des couches du e mod`le OSI et celles des protocoles TCP/IP. e La gure II.02 elle, donne une vue densemble de larchitecture logicielle avec quelques protocoles dapplications de la famille IP. Ils sont tr`s nome breux, non reprsents tous ici, et il sen faut de beaucoup car il en existe des e e centaines. La lecture du chier /etc/services, prsent sur toute machine e de la famille des Unix, donne un aperu des principaux services enregistrs c e aupr`s de lIANA. Quand nous aurons expliqi la notion port (cf page e e 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`s au rseau. e e Chaque programme dapplication interagit avec la couche de transport pour envoyer ou recevoir des donnes. En fonction des caractristiques de e e lchange le programme a choisi un mode de transmission ` la couche de e a transport. La plus grande proportion des applications laissent ` la couche de transa port le soin deectuer le travail de Session , nanmoins il est possible e pour certaines applications de court-circuiter cette fonctionnalit pour agir e directement au niveau Rseau , comme on peut lobserver sur la gure e II.02 ` droite. a

3.2

Couche Transport Layer

La principale tche de la couche de transport est de fournir la communia cation dun programme dapplication ` un autre. Une telle communication a est souvent qualie de point ` point . e a Cette couche peut avoir ` rguler le ot de donnes et ` assurer la abilit a e e a e du transfert : les octets reus doivent tre identiques aux octets envoys. Cest c e e pourquoi cette couche doit grer des checksums et savoir re-mettre des e e paquets mal arrivs. e Cette couche divise le ux de donnes en paquets (terminologie de lISO) e et passe chacun avec une adresse de destination au niveau infrieur. e De plus, et cest surtout valable pour les syst`mes dexploitation multie tches multi-utilisateurs (Unix,. . .), de multiples processus appartenant ` a a des utilisateurs dirents et pour des programmes dapplications dirents, e e acc`dent au rseau au mme moment, ce qui implique la capacit de multie e e e plexer et de dmultiplexer les donnes, suivant quelles vont vers le rseaux e e e

30 ou vers les applications ( Session ).

Introduction ` IP a

3.3

Couche Internet Layer

Cette couche reoit des data-grammes en provenance de la couche rseau, c e quelle doit analyser pour dterminer sils lui sont adresss ou pas. Dans e e le premier cas elle doit dcapsuler son en-tte du data-gramme pour e e transmettre les donnes ` la couche de transport et au bon protocole de e a cette couche (TCP, UDP...), dans le deuxi`me cas elle les ignore. e Cette couche prend aussi en charge la communication de machine ` maa chine. Elle accepte des requtes venant de la couche de transport avec une e identication de la machine vers laquelle le paquet doit tre envoy. e e Elle utilise alors lalgorithme de routage (page 70) pour dcider si le pae quet doit tre envoy vers une passerelle ou vers une machine directement e e accessible. Enn cette couche g`re les datagrammes des protocoles ICMP et IGMP. e

3.4

Couche Network Access

Le protocole dans cette couche dnit le moyen pour un syst`me de e e dlivrer linformation ` un autre syst`me physiquement reli. Il dnit come a e e e ment les data-grammes IP sont transmis. La dnition de ceux-ci reste e indpendante de la couche rseau, ce qui leur permet de sadapter ` chaque e e a nouvelle technologie au fur et ` mesure de leur apparition. a Avant de sintresser au dtail des data-grammes IP, nous allons examiner e e le probl`me de ladressage IP, dans le chapitre suivant. e

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 dcrit avec le mod`le des couches OSI, les couches e e IP fonctionnent par encapsulations progressives. Chaque couche en-capsule la prcdente avec les informations de contrle e e o quelle destine ` la couche de mme niveau sur la machine distante. a e Cet ajout est nomm header (en-tte) parce-quil est plac en tte des e e e e donnes ` transmettre. e a Application Transport Internet Network | | Header | | Header | Header | | Header | Header | Header | datas datas datas datas | | | |

31

La taille des headers dpend des protocoles utiliss. Pour la couche e e IP le protocole comporte en standard 5 mots de 32 bits, mme chose pour la e 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 Numro spcial Internet numro 238 de fvrier 2000 e e e e

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

32

Introduction ` IP a

Chapitre III Anatomie dune adresse IP

1 Adressage IP

Nous avons dit que lInternet est un rseau virtuel, construit par intercone nexion de rseaux physiques via des passerelles. Ce chapitre parle de ladrese sage, le maillon essentiel des protocoles TCP/IP pour rendre transparents les dtails physiques des rseaux et faire apparaitre lInternet comme une entit e e e homog`ne. e

1.1

Unicit de ladresse e

Un syst`me de communication doit pouvoir permettre ` nimporte quel e a hte de se mettre en relation avec nimporte quel autre. An quil ny ait o pas dambigu e pour la reconnaissance des htes possibles, il est absolument t o ncessaire dadmettre un principe gnral didentication. e e e Lorsque lon veut tablir une communication, il est intuitivement indise pensable de possder trois informations : e 1. Le nom de la machine distante, 2. Son adresse, 3. La route ` suivre pour y parvenir. a Le nom dit qui est lhte distant, ladresse nous dit o` il se trouve o u et la route comment on y parvient. En r`gle gnrale les utilisateurs prf`rent des noms symboliques pour e e e ee identier les machines tandis que les processeurs de ces mmes machines ne e comprennent que les nombres exprims au format binaire. e Les adresses IP (version 4) sont standardises sous forme dun nombre e de 32 bits qui permet ` la fois lidentication de chaque hte et du rseau a o e auquel il appartient. Le choix des nombres composants une adresse IP nest pas laiss au hasard, au contraire il fait lobjet dune attention particuli`re e e notamment pour faciliter les oprations de routage. e Nous ludons la correspondance entre ce nombre et une ventuelle e e reprsentation symbolique, cest lobjet du serveur de noms, une application e examine page 165. e

34

Anatomie dune adresse IP Chaque adresse IP contient donc deux informations lmentaires, une ee adresse de rseau et une adresse dhte. La combinaison des deux dsigne e o e de mani`re unique une machine et une seule sur lInternet, sous rserve que e e cette adresse ait t attribue par un organisme ayant pouvoir de le faire ! ee e

1.2

Dlivrance des adresses IPv4 e

On distingue deux types dadresses IP : Les adresses prives que tout administrateur de rseau peut sattribuer e e librement pourvu quil(elle) ne cherche pas ` les router sur lInternet a les adresses publiques dlivres par une structure mondiale qui en assure e e lunicit. Ce dernier point est capital pour assurer lecience du roue tage, comme nous le comprendrons en dtaillant le fonctionnement dIP, e ` partir de la page 47. a Les adresses ` utiliser sur les rseaux privs sont dcrites par la RFC 1918 : a e e e 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 gnralement foure e 2 nies par le FAI . Quelles soient dlivres de mani`re temporaire ou attribues e e e e pour le long terme, elles doivent tre uniques sur le rseau. La question est e e donc de savoir de qui le FAI les obtient. Cest LICANN ou Internet Corporation for Assigned Names and Numbers3 qui est charg au niveau mondial de la gestion de lespace dadressage e IP. Il dnit les procdures dattribution et de rsolution de conits dans late e e tribution des adresses, mais dl`gue le dtail de la gestion de ces ressources ee e ` des instances rgionales puis locales, dans chaque pays, appeles RIR ou a e e Regional Internet Registries . Il y a actuellement cinq Regional Internet Registries oprationnels : e 4 5 lAPNIC pour la rgion Asie-Pacique, lARIN pour lAmrique, le e e RIPE NCC6 pour lEurope, lAfriNIC7 pour lAfrique enn LACNIC8 pour lAmrique Latine. e Pour ce qui nous concerne en Europe cest donc le RIPE NCC (Rseaux e IP europen Network Coordination Centre) qui dlivre les adresses que nous e e utilisons. Les adresses IP sont alloues ` lutilisateur nal qui en fait la demande e a par un Local Internet Registry , ou LIR, autoris par le RIPE NCC. e
2 3

Fournisseur dAcc`s Internet e 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 gnralement un FAI ou une grande organisation (entreprise e e multinationale). Il est sous lautorit de linstance rgionale de gestion de e e 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 t alloues statiquement par le LIR. Les adresses IP sont alors restitues ee e e puis r-attribues ` dautres utilisateurs. e e a On compte plus de 2000 de LIRs orant leurs services en Europe see lon le RIPE NCC9 . Le chire a forcement augment depuis 2003, avec llargissement des fronti`res europennes. e e e

35

Anatomie dune adresse IP

Une adresse IP est un nombre de 32 bits que lon a coutume de reprsenter e sous forme de quatre entiers de huit bits, spars par des points (parae e graphe 1.2). La partie rseau de ladresse IP vient toujours en tte, la partie hte est e e o donc toujours en queue. Lintrt de cette reprsentation est immdiat quand on sait que la partie ee e e rseau et donc la partie hte sont presque toujours codes sur un nombre e o e entier doctets. Ainsi, on a principalement les trois formes suivantes : Classe A Un octet rseau, trois octets dhtes. e o Classe B Deux octets rseau, deux octets dhtes. e o Classe C Trois octets rseau, un octet dhte. e o

2.1

Dcomposition en classes e
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
Dcomposition en classes e
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 rseau et de 24 bits e pour identier lhte. On a donc les o rseaux de 1 ` 127 et 224 htes pose a o sibles, cest ` dire 16 777 216 maa chines direntes (de 0 ` 16 777 215). e a Les lecteurs attentifs auront remarqu que le rseau 0 nest pas utie e lis, il a une signication particuli`re e e ( tous les rseaux ). Plus de dtails e e au paragraphe 2.2.

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

36

Anatomie dune adresse IP De mme, la machine 0 nest pas utilise, tout comme la machine ayant e e le plus fort numro dans le rseau (tous les bits de la partie hte ` 1, ici e e o a 16 777 215), ce qui rduit de deux units le nombre des machines nommables. e e 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 rseau et 16 bits pour identier la machine. Ce e 14 qui fait 2 = 16 384 rseaux (128.0 ` 191.255) et 65 534 (65 536 2) e a machines. Si les trois premiers bits sont 110 , ladresse est de classe C. Il reste 21 bits pour identier le rseau et 8 bits pour identier la machine. Ce e 21 qui fait 2 = 2 097 152 rseaux (de 192.0.0 ` 223.255.255) et 254 e a (256 2) machines. Si les quatre premiers bits de ladresse sont 1110 , il sagit dune classe dadressage spciale, la classe D. Cette classe est prvue pour e e faire du multicast , ou multipoint. (RFC 1112 [S. Deering, 1989]), contrairement aux trois premi`res classes qui sont ddies ` l unicast e e e a ou point ` point. a Ces adresses forment une catgorie ` part, nous en reparlons au parae a graphe 3. Si les quatre premiers bits de ladresse sont 1111 , il sagit dune classe exprimentale, la classe E. La RFC 1700 prcise Class E ade e dresses are reserved for future use mais nindique pas de quel futur il sagit. . . Enn, pour conclure ce paragraphe, calculons le nombre dhtes adreso sables thoriquement ` laide des classes A, B et C : e a 127 16777212 + 16384 65534 + 2097152 254 = 3737091588
10

Ce total, pour tre plus exact, doit tre amput des 17 890 780 htes des e e e o 11 rseaux privs prvus dans la RFC 1918 , soit donc tout de mme au total e e e e 3 719 200 808 htes adressables en utilisant IPv4 ! o

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`res e

Certaines adresses IP ont une signication particuli`re ! e Par convention le numro 0 dhte nest pas attribu. Si une adresse IP e o e contient cette zone nulle cela signie que lon adresse le rseau lui-mme et e e aucun hte en particulier, donc en r`gle gnrale lhte lui-mme. o e e e o e De mme, pour toutes les pile Arpa ladresse 127.0.0.1 indique la mae chine elle-mme ( localhost Voir chapitre IP page 47), indpendamment e e des autres adresses rseaux ventuellement attribues ` nimporte lequel de e e e a ses interfaces. ` A linverse, si tous les bits de la partie hte sont ` 1, cela dsigne toutes o a e les machines du rseaux, cest ce que lon appele une adresse de broadcast , e cest ` dire une information adresse ` tout le monde. a e a On vite au maximum lusage dune telle adresse IP sur les rseaux, pour e e des raisons decacit (encombrement de la bande passante). e Quelques exemples dadresses avec une signication particuli`re : e 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 Hte inconnu, sur ce rseau o e Lhte 1 de ce rseau o e Tous les htes o Lhte 52.1 du rseau 138.195.0.0 o e Cet hte sur le 138.195.0.0 o Tous les htes du 193.104.1.0 o Cet hte (boucle locale). o

Remarque : les deux premi`res adresses, avec un numro de rseau gal ` e e e e a 0, ne peuvent gurer que comme adresse source dans des cas bien particuliers comme le dmarrage dune station (cf chapitre IP page 47 et les travaux e pratiques associs). e

38

Anatomie dune adresse IP

2.3

Sous-rseaux e

En 1984 un troisi`me niveau de hirarchie est mis en place : le subnet e e ou sous-rseau. pour permettre aux administrateurs de grer plus nement e e de grands rseaux. La RFC 950 [J. Mogul, J. Postel, 1985] donne plus de e prcisions, la RFC 1878 [T. Pummill & B. Manning, 1995] est une table de e tous les sous-rseaux possibles. e
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 utiliss pour caractriser un souse e rseau. e Quelques rvisions des proprits e ee des puissances de 212 sont souvent ncessaires pour bien assimiler ce pae ragraphe. La gure suivante en rappelle les valeurs pour les huit premiers exposants : gure III.03 Puissances de 2

gure III.02 Sous-rseaux e Le subnet utilise les bits de poids fort de la partie hte de o ladresse IP, pour dsigner un rseau. e e Le nombre de bits employs est laiss e e ` linitiative de ladministrateur. a
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 caractriser 4 sous-rseaux de 62 machines e e (63 moins ladresse de broascast, le 0 ntant pas compt). Le calcul des e e masques et des adresses de diusion est expliqu dans le tableau suivant : e Numro du rseau e e 193.104.1.00 193.104.1.64 193.104.1.128 193.104.1.192 Netmask Broadcast Adressage hte o 255.255.255.192 00 + 63 = 63 .1 ` .62 a 255.255.255.192 64 + 63 = 127 .65 ` .126 a 255.255.255.192 128 + 63 = 191 .129 ` .190 a 255.255.255.192 192 + 63 = 255 .193 ` .254 a

12 13

et plus gnralement de la dcomposition dun nombre en ses facteurs premiers. . . e e e Donc 64 valeurs possibles de 0 ` 63 a

Sous-rseaux e Soit un total de 62 4 = 248 htes possibles pour cette classe C avec un o 14 masque de sous-rseau , au lieu des 254 htes sans. e o La machine dadresse 1 sur chaque sous-rseau, aura comme adresse IP : e Sous-rseau Adresse e Dcomposition e 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 dnir les sous-rseaux e e ne devrait pas vous poser de probl`me. . . e Numro e du subnet 000(0) 001(1) 010(2) 011(3) 100(4) 101(5) 110(6) 111(7) Numro e du rseau e 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`re Derni`re e e machine machine

39

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

Remarque : On pourra vrifer que la perte despace dadressage pour e adresser des htes se calcule avec la relation (2n 1)2, o` n est le nombre de o u bits du masque. Ainsi avec 3 bits de masque de sous-rseau, la perte despace e dadressage sl`ve ` 14 htes ! Les 254 possibilits (256 moins 0 et 255) de ee a o e numrotation de la classe C se rduisent ` 240, amputes de 31, 32, 63, 64, e e a e 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 des classes B taient alloues, et si le rythme avait e e e continu, au dbut de 1994 il ny aurait plus eu de classe B disponible et e e lInternet aurait bien pu mourrir par asphyxie ! De plus la croissance du nombre de rseaux se traduisait par un usage aux limites des routeurs, e proches de la saturation car non prvus au dpart pour un tel volume de e e routes (voir les RFC 1518 et RFC 1519). Deux considrations qui ont conduit lIETF a mettre en place le Classe less InterDomain Routing ou CIDR ou encore routage Internet sans classe, bas sur une constatation de simple bon sens : e Sil est courant de rencontrer une organisation ayant plus de 254 htes, o il est moins courant den rencontrer une de plus de quelques milliers. Les adresses alloues sont donc des classes C contiges, attribues par e u e rgion ou par continent. En gnrale, 8 ` 16 classes C mises bout ` e e e a a bout susent pour une entreprise. Ces blocs de numros sont souvent e appells supernet . e Ainsi par exemple il est courant dentendre les administrateurs de rseaux parler dun slash 22 (/22) pour dsigner un bloc de quatre e e classes C conscutives. . . e Il est plus facile de prvoir une table de routage pour un bloc de rseaux e e contiges que davoir ` le faire pour une multitude de routes indiviu a duelles. En plus cette opration all`ge la longueur des tables. e e Plus prcisement, trois caractristiques sont requises pour pouvoir utiliser e e ce concept : 1. Pour tre runies dans une mme route, des adresses IP multiples e e e doivent avoir les mmes bits de poids fort (seuls les bits de poids plus e faible di`rent)de poids faibles di`rent. e e 2. Les tables de routages et algorithmes doivent prendre en compte un masque de 32 bits, ` appliquer sur les adresses. a 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 concrtement comme dans la recriture du e e 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 unie quement sur la partie rseau des adresses. e

Prcisions sur le broadcast e Les agrgations dadresses sont ventiles selon le tableau suivant15 : e e Multirgionales e Europe Autres Amrique du Nord e Amrique centrale, e Amrique du Sud e 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

Prcisions sur le broadcast e

Tout dabord il faut prciser quune adresse de broadcast est forcment e e une adresse de destination, elle ne peut jamais appara comme une adresse tre source dans un usage normal des rseaux. e 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 (prcisions en cours). e Lusage de cette adresse est normalement limite ` un hte en phase e a o dinitialisation, quand il ne connait rien du rseau sur lequel il est e connect. e Net-directed broadcast Tous les bits de la partie hte sont ` 1. Un o a routeur propage ce type de broadcast, sur option. Subnet-directed broadcast Cest le mme cas que ci-dessus mais e avec une adresses IP comportant des subnets. All-subnets-directed broadcast Cest le cas o` tous les bits des subu nets et htes sont ` 1. Ce cas possible thoriquement est rendu obsol`te o a e e depuis la RFC 922 (1993).

Ce tableau est tr`s synthtique, pour une information plus dtaille et ` jour consultez e e e e a le site de lIANA http://www.iana.org/assignments/ipv4-address-space

15

42

Anatomie dune adresse IP

Adressage multicast

En r`gle gnrale ladressage multicast est employ pour sadresser en une e e e e seule fois ` un groupe de machines. a Dans le cas dun serveur vido/audio, cette approche induit une conomie e e de moyen et de bande passante vidente quand on la compare ` une dmarche e a e unicast : un seul datagramme est rout vers tous les clients intresss au e e e lieu dun envoi massif dautant de datagrammes quil y a de clients. Les adresses de type multicast ont donc la facult didentier un e groupe de machines qui partagent un protocole commun par opposition ` un a groupe de machines qui partagent un rseau commun. e La plupart des adresses multicast alloues le sont pour des applications e particuli`res comme par exemple la dcouverte de routeurs (que nous verrons e e ultrieurement lors du routage IP) ou encore la radio ou le tlphone/vido e ee e sur Internet ( Mbone ). Parmi les plus souvent utilises16 sur un lan : e 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-rseau e Tous les routeurs sur ce sous-rseau e 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 dmarre avec les bits 1110 par contre pour les 28 e bits suivants son organisation interne di`re de celle des classes A, B et C. e
"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`re par contre on continue ` e a utiliser la notation dcimale pointe : 224.0.0.0 ` 239.255.255.255. e e a Un groupe dhtes qui partagent un protocole commun utilisant une o adresse multicast commune peuvent tre rpartis nimporte o` sur le e e u rseau. e Lappartenance ` un groupe est dynamique, les htes qui le dsirent a o e rejoignent et quittent le groupe comme ils veulent. Il ny a pas de restriction sur le nombre dhtes dans un groupe et o un hte na pas besoin dappartenir ` un groupe pour lui envoyer un o a message.
16

Pour plus de prcisions on pourra se reporter page 56 de la RFC 1700 e

Adresse multicast et adresse MAC

43

3.2

Adresse multicast et adresse MAC

Une station Ethernet quelconque doit tre congure pour accepter le e e multicast, cest ` dire pour accepter les trames contenant un datagramme a munis dune adresse IP de destination qui est une adresse multicast. Cette opration sous entend que la carte rseau sait faire le tri entre les e e trames. En eet les trames multicast ont une adresse MAC particuli`re : elles e commencent forcment par les trois octets 01:00:5E17 . Ceux-ci ne dsignent e e pas un constructeur en particulier mais sont possds par lICANN (ex e e IANA). Restent trois octets dont le bit de poids fort est forcment ` 0 pour e a dsigner les adresses de multicast (contrainte de la RFC 1700), ce qui conduit e au schma suivant : e
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 mme e prciser que pour chaque trame comportant une adresse multicast il y a 25 e adresses IP de groupes multicast possibles ! Ce qui signie que si les 23 bits de poids faible ne susent pas ` discria miner la trame il faudra faire appel au pilote de priphrique ou ` la couche e e a IP pour lever lambigu e. t Quand une trame de type multicast est lue par la station Ethernet puis par le pilote de priphrique, si ladresse correspond ` lune des adresses e e a de groupe multicast pralablement congures, le datagramme franchit la e e couche IP et une copie des donnes est dlivre aux processus qui ont joint e e e le groupe multicast . La question est de savoir comment les trames de type multicast atteignent justement cette station Ethernet ? La rponse se trouve dans un protocole e nomm IGMP et que nous examinerons dans le prochain chapitre concernant e 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 prcisions supplmentaires. e e Jusqu` prsent nous avons dsign un hte par son adresse IP. Cette a e e e o dmarche nest pas exacte si on consid`re par exemple le cas dune passerelle, e e connecte physiquement ` au moins deux rseaux dirents, avec une adresse e a e e IP dans chacun de ces rseaux. e On dira donc maintenant quune adresse IP identie non pas un hte mais o un interface. La rciproque nest pas vraie car un mme interface peut collece e tionner plusieurs adresses IP. Toutes permettent datteindre cet interface, on parle alors d alias IP , d htes virtuels et de rseaux virtuels . . .Nous o e aurons loccasion de revenir sur ces notions ` la n de ce cours (page 137). a On dit dune machine ayant au moins deux adresses IP quelle est du type multi-homed . En gnral une passerelle qui met en relation n rseaux poss`de n adresses e e e e IP direntes (une dans chaque rseau), mais ce nest pas une obligation (nous e e verrons quelle peut en tre lutilit ` la n de ce cours). e ea
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 des adresses logique et physique e La gure III.06 met en situation deux htes, A et B, en relation via une o passerelle G. Si les messages et les paquets sont identiques, par contre les datagrammes et les trames di`rent puisquil ne sagit plus du e mme rseau physique. D`s que nous aurons examin le fonctionnement de e e e e 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 dni dans la RFC 791 e et a t conu en 1980 pour remplacer NCP ( Network Control Protocol ), ee c le protocole de lArpanet. Presque trente ans apr`s sa premi`re implmentation, ses limitations se e e e font de plus en plus pnalisantes pour les nouveaux usages sur les rseaux. e e Avant de le jeter aux orties, posons-nous la question de qui pouvait prvoir e ` cette poque o` moins de mille ordinateurs taient relis ensembles, que a e u e e trois dcennies plus tard des dizaines de millions dhtes lutiliseraient comme e o principal protocole de communication ? Sa longvit est donc remarquable et il convient de lanalyser de pr`s e e e avant de pouvoir le critiquer de mani`re constructive. e

1.1

Structure de len-tte e
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 encapsuls ` laide e a dun en-tte IP avant dtre proe e pags vers la couche rseau (Ethere e net par exemple), sont collectivement nomms datagramme IP , dae tagramme Internet ou datagramme tout court. Ces datagrammes ont une taille maximale lie aux cae ractristiques de propagation du supe port 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 caractristiques en vrac du protocole IP : e 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 donnes e quil envoie. Il nentretient aucun dialogue avec une autre couche IP distante, on dit aussi quil dlivre les datagramme au mieux . e Chaque datagramme est gr indpendamment des autres dataee e grammes mme au sein du transfert des octets dun mme chier. Cela e e signie que les datagrammes peuvent tre mlangs, dupliqus, perdus e e e e ou altrs ! ee Ces probl`mes ne sont pas dtects par IP et donc il ne peut en informer e e e la couche de transport. Les octets sont lus et transmis au rseau en respectant le Network e Byte Order ou NBO (cf paragraphe 1.2) quelle que soit larchitecture cpu de lhte. o Len-tte IP minimale fait 5 mots de 4 octets, soit 20 octets. Sil y a e 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 ` gauche (31. . .). Ils sont dailleurs transmis sur le rseau dans a e cet ordre1 , cest un standard, cest le Network Byte Order . Toutes les architectures de CPU ne sont pas bties sur le mme mod`le : a e e
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`s aux sources dune pile IP pourra aller consulter directee ment la structure de len-tte, par exemple le chier /usr/src/sys/netinet/ip.h sur e une machine FreeBSD
1

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

49

1.3

Description de len-tte e

VERS 4 bits qui spcient la version du protocol IP. Lobjet de ce champ est la e vrication que lmetteur et le destinataire des datagrammes sont bien e e en phases avec la mme version. Actuellement cest la version 4 qui est e principalement utilis sur lInternet, bien que quelques implmentations e e de la version 6 existent et soient dj` en exprimentation2 . ea e HLEN 4bits qui donnent la longueur de len-tte en mots de 4 octets. La e taille standard de cette en-tte fait 5 mots, la taille maximale fait : e (23 + 22 + 21 + 20 ) 4 = 60 octets3 TOTAL LENGTH Donne la taille du datagramme, en-tte plus donnes. Sil y e e fragmentation (voir plus loin) il sagit galement de la taille du fragment e (chaque datagramme est indpendant des autres). e La taille des donnes est donc ` calculer par soustraction de la taille de e a len-tte. e 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 TYPE OF SERVICE et joue potentiellement deux rles see o lon les bits examins (prsance et type de service). Pratiquement, la e ee prsance ne sert plus et la RFC 1349 dnit 4 bits utiles sur les huit ee e (3 ` 6). Ceux-ci indiquent au routeur lattitude ` avoir vis ` vis du a a a datagramme. Par exemple, des datagrammes dun transfert de chier (ftp) peuvent avoir ` laisser passer un datagramme repr comme contenant des caa ee ract`res frapps au clavier (session telnet). e e 0x00 0x10 0x08 0x04 0x02 Service normal Transfert banal bit 3,D Minimiser le dlai e Session telnet bit 4,T Maximiser le dbit e Transfert ftp bit 5,R Maximiser la qualit ICMP e bit 6,C Minimiser le cot u news (nntp)

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

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

50

Protocole IP bits ci-dessus. Les deux derniers bits dnissent lECN ou Explicit e Congestion Notication qui est un mcanisme permettant de prvenir e e les congestions, contrairement au mcanisme plus ancien bas sur les e e messages ICMP de type source quench (voir page 61) qui tente de rgler le ux en cas de congestion. e Il faut noter que les protocoles de routage qui tiennent compte de ltat e des liaisons (OSPF,IS-IS. . .) sont susceptibles dutiliser ce champ. Enn la RFC 3168 indique que ces deux critures du champ ne sont e pas compatibles entre elles. . . IDENTIFICATION, FLAGS et FRAGMENT OFFSET Ces mots sont prvus pour e contrler la fragmentation des datagrammes. Les donnes sont frago e mentes car les datagrammes peuvent avoir ` traverser des rseaux avec e a e 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. Prvu ` lorigine pour dcompter un temps, ce champ nest quun compe a e teur dcrment dune unit ` chaque passage dans un routeur. e e e ea Couramment la valeur de dpart est 32 ou mme 64. Son objet est e e dviter la prsence de paquets fantmes circulant indniment. . . e e o e Si un routeur passe le compteur ` zro avant dlivrance du datagramme, a e e e un message derreur ICMP (consultez le paragraphe 4) est renvoy ` lmetteur avec lindication du routeur. Le paquet en lui-mme est a e e perdu. PROTOCOL 8 bits pour identier le format et le contenu des donnes, un peu e comme le champ type dune trame Ethernet. Il permet ` IP dadresa ser les donnes extraites ` lune ou lautre des couches de transport. e a 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 numro du protocole e est prsente sur tout syst`me dexploitation digne de ce nom, dans le e e chier /etc/protocols. HEADER CHECKSUM 16 bits pour sassurer de lintgrit de len-tte. Lors du e e e calcul de ce checksum ce champ est ` 0. a A la rception de chaque paquet, la couche calcule cette valeur, si elle ne e correspond pas ` celle trouve dans len-tte le datagramme est oubli a e e e ( discard ) sans message derreur. SOURCE ADDRESS Adresse IP de lmetteur, ` lorigine du datagramme. e a DESTINATION ADDRESS Adresse IP du destinataire du datagramme. IP OPTIONS 24 bits pour prciser des options de comportement des e couches IP traverses et destinatrices. Les options les plus courantes e concernent :

Description de len-tte e Des probl`mes de scurit e e e Des enregistrements de routes Des enregistrements dheure Des spcications de route ` suivre e a ... Historiquement ces options ont t prvues d`s le dbut mais leur ee e e e implmentation na pas t termine et la plupart des routeurs ltrants e ee e 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 ` router les datagrammes en les acheminant au mieux , a on verra plus loin de quelle mani`re. Cest son travail principal. e 2. Il peut avoir ` fragmenter les donnes de taille suprieure au MTU du a e e support physique ` employer. a

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 tre de 256 avec SLIP ( Serial Line IP ) sur e liaison srie (RS232. . .). e Dans ces conditions, si la couche IP doit transmettre un bloc de donnes e de taille suprieure au MTU ` employer, il y a fragmentation ! e a Par exemple, un bloc de 1481 octets sur Ethernet sera dcompos en un e e datagramme de 1480 (1480 + 20 = 1500) et un datagramme de 1 octet ! Il existe une exception ` cette opration, due ` la prsence active du bit a e a e Dont Fragment bit du champ FLAGS de len-tte IP. La prsence ` 1 de e e a ce bit interdit la fragmentation dudit datagramme par la couche IP qui en aurait besoin. Cest une situation de blocage, la couche mettrice est tenue e au courant par un message ICMP (cf paragraphe 4 page 59) Fragmentation needed but dont fragment bit set et bien sr le datagramme nest pas u 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, il nest rassembl que par la e e e couche IP destinatrice nale. Cela implique trois remarques : 1. La taille des datagrammes reus par le destinataire nal est direcc tement dpendante du plus petit MTU rencontr. e e 2. Les fragments deviennent des datagrammes ` part enti`re. a e 3. Rien ne soppose ` ce quun fragment soit ` nouveau fragment. a a e Cette opration est absolument transparente pour les couches de transe port qui utilisent IP.

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

53

Le fragment transmettre

gure IV.04 Fragment ` transmettre a Pour tous les fragments : Les donnes doivent faire un multiple de 8 octets, sauf pour le dernier e fragment, videment. e Le champ TOTAL LENGTH change. Chaque fragment est un datagramme indpendant, susceptible dtre e e ` son tour fragment. a e Pour le dernier fragment : FLAGS est remis ` zro. a e Les donnes ont une taille quelconque. e

1.4.2

Rassemblage e

Tous les datagrammes issus dune fragmentation deviennent des datagrammes IP comme (presque) les autres. Ils arrivent ` destination, peut tre dans le dsordre, dupliqus. IP doit a e e e faire le tri. il y a susamment dinformation dans len-tte pour rassembler les e e fragments pars. e Mais si un fragment manque, la totalit du datagramme est perdu car e aucun mcanisme de contrle nest implment pour cela dans IP. e o e e Cest la raison principale pour laquelle il faut absolument viter de fragmenter un datagramme IP ! e La gure IV.05 rsume lopration de fragmentation dun datagramme IP. e e

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

e e gure IV.05 Rsum de la fragmentation

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-tte : e 1. IDENTIFICATION est le mme pour tous e 2. FLAG est 0 pour le dernier datagramme 3. OFFSET cro de la taille du fragment, ici N. t 4. TOTAL LENGTH est gnralement dirent pour le dernier fragment, sauf e e e cas particulier. 5. HEADER CHECKSUM change ` chaque fois car lOFFSET change (rappel : a il ne tient pas compte des donnes). e

2 Protocole ARP

55

Protocole ARP

ARP est lacronyme de Address Resolution Protocol , il est dnie dans e la RFC 826. Le probl`me ` rsoudre est issu de la constatation quune adresse IP e a e na de sens que pour la suite de protocole TCP/IP ; celle-ci tant e indpendante de la partie matrielle il faut avoir un moyen dtablir e e e un lien entre ces deux constituants. La norme Ethernet (vs IEEE) suppose lidentication unique de chaque carte construite et vendue4 . Sur une mme liaison physique (lire plus loin mme LAN ), Ethere e net 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 dcrit ici (ne fait pas partie du protocole). e Remarque importante : Cette information na pas de sens dans le cadre dune liaison de type point ` point avec un protocole tel que ppp. a Lors du premier change entre 2 machines dun mme LAN, si les e e adresses physiques ne sont pas dj` connues (on verra pourquoi plus ea loin), la solution ` ce probl`me passe par lusage du protocole ARP. a e Lusage de ARP est compl`tement transparent pour lutilisateur. e

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 spcial (cf paragraphe suivant), ddi ` ARP, qui e e ea lui permet de poser la question ( Arp question ) ` lensemble des machines a actives. Ladresse de la machine qui doit rpondre tant lobjet de la quese e tion, son adresse (champ destinataire) est donc remplace par une adresse de e broadcast (48 bits ` 1). a Toutes les machines du LAN coutent cet change et peuvent mettre ` e e a jour leur table de conversion (adresse IP adresse Ethernet) pour la machine A.
4

cf chapitre I Rseaux locaux e

56

Protocole IP Le broadcast , coteux en bande passante, est ainsi utilis au maximum u e de ses possibilits. Sur la gure IV.07 la rponse de B est du type unicast . e e Remarque : quand une station Ethernet ne rpond plus (cf ICMP) il y a e suppression de lassociation adresse IP - adresse MAC.

Rponse unicast.

B rpond directement A en lui communiquant son adresse physique.

gure IV.07 Rponse ARP e

Si la station B ne rpond pas, la station continuera ` poser la question ` e a a intervals rguliers pendant un temps inni. . . e Il nest pas besoin dutiliser ARP pralablement ` chaque change, car e a e heureusement le rsultat est mmoris. e e e En r`gle gnrale la dure de vie dune adresse en mmoire est de lordre e e e e e de 20 minutes et chaque utilisation remet ` jour ce compteur. a 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`s important, du fait de lutilisation de broade cast physiques, les messages ARP ne franchissent pas les routeurs. Il existe cependant un cas particulier : le proxy ARP, que nous voquerons succintee ment ` la n de ce paragraphe. a

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 dans une trame physique du type e 5 0x0806 . HARDWARE TYPE pour spcier le type dadresse physique dans les champs e SENDER HA et TARGET HA, cest 1 pour Ethernet. PROTOCOL TYPE pour spcier le type dadresse logique dans les champs e SENDER ADR et TARGET ADR, cest 0x0800 (mme valeur que dans la e trame Ethernet) pour des adresses IP. HLEN 1 pour spcier la longueur de ladresse physique (6 octets pour Ethere net). HLEN 2 pour spcier la longueur de ladresse logique (4 octets pour IP). e OPERATION ce champ prcise le type de lopration, il est ncessaire car la e e e trame est la mme pour toutes les oprations des deux protocoles qui e e lutilisent. Question Rponse e 1 2 3 4

ARP RARP

SENDER HA adresse physique de lmetteur e SENDER ADR adresse logique de lmetteur e TARGET HA adresse physique du destinataire TARGET ADR adresse logique du destinataire
5

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

58

Protocole IP

2.3

Proxy ARP

Le proxy ARP permet lextension du lan ` des htes qui ne lui sont a o pas directement physiquement relis, mais qui sy rattachent par exemple au e travers dune passerelle. Un exemple tr`s courant est celui dun hte qui acc`de ` un rseau via un e o e a e dialup (rtc, numris,. . .). Le NetID de son adresse IP peut alors tre le mme e e e que celui du rseau rejoint, comme sil y tait physiquement raccord. Ce e e e subterfuge est rendu possible apr`s conguration adquate de la passerelle e e de raccordement.

Protocole RARP

RARP est lacronyme de Reverse Address Resolution Protocol , il est dni dans la RFC 903 (BOOTP et DHCP en sont des alternatives avec plus de e possibilits). e Normalement une machine qui dmarre obtient son adresse IP par lece ture dun chier sur son disque dur (ou depuis sa conguration ge e dans une mmoire non volatile). e Pour certains quipements cette opration nest pas possible voire e e mme non souhaite par ladministrateur du rseau : e e e Terminaux X Windows Stations de travail diskless Imprimante en rseau e Boites noires sans capacit autonome de dmarrage e e PC en rseau e ... Pour communiquer en TCP/IP une machine a besoin dau moins une adresse IP, lide de ce protocole est de la demander au rseau. e e Le protocole RARP est adapt de ARP : lmetteur envoie une requte e e e RARP spciant son adresse physique dans un datagramme de mme e e 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 reoivent la requte, celles qui sont hae c e bilits ` rpondre (serveurs RARP) compl`tent le datagramme et le rene a e e voient directement ( unicast ) ` lmetteur de la requte puisquelle a e e connaissent son adresse physique. Sur une machine Unix congure en serveur RARP les correspondances e entres adresses IP et adresses physiques sont enregistres dans un chier e nomm gnralement /etc/bootptab. e e e

4 Protocole ICMP

59

Protocole ICMP

ICMP est lacronyme de Internet Control Message Protocol , il est historiquement dni dans la RFC 950. e Nous avons vu que le protocole IP ne vrie pas si les paquets mis sont e e arrivs ` leur destinataire dans de bonnes conditions. e a Les paquets circulent dune passerelle vers un autre jusqu` en trouver a une qui puisse les dlivrer directement ` un hte. Si une passerelle ne peut e a o router ou dlivrer directement un paquet ou si un venement anormal arrive e e sur le rseau comme un trac trop important ou une machine indisponible, e il faut pouvoir en informer lhte qui a mis le paquet. Celui-ci pourra alors o e ragir en fonction du type de probl`me rencontr. e e e ICMP est un mcanisme de contrle des erreurs au niveau IP, mais la e o gure II.02 du chapitre dintroduction ` IP (page 25) montre que le niveau a Application peut galement avoir un acc`s direct ` ce protocole. e e a

4.1

Le syst`me de messages derreur e

Dans le syst`me que nous avons dcrit, chaque passerelle et chaque hte e e o op`re de mani`re autonome, route et dlivre les datagrammes qui arrivent e e e sans coordination avec lmetteur. e Le syst`me fonctionne parfaitement si toutes les machines sont en ordre e de marche et si toutes les tables de routage sont ` jour. Malheureusement a cest une situation idale. . . e Il peut y avoir des rupture de lignes de communication, des machines peuvent tre ` larrt, en pannes, dconnectes du rseau ou incapables de e a e e e e router les paquets parcequen surcharge. Des paquets IP peuvent alors ne pas tre dlivrs ` leur destinataire et e e e a le protocol IP lui-mme ne contient rien qui puisse permettre de dtecter cet e e chec de transmission. e Cest pourquoi est ajout systmatiquement un mcanisme de gestion des e e e erreurs connu sous le doux nom de ICMP. Il fait partie de la couche IP6 et porte le numro de protocole 1. e Ainsi, quand un message derreur arrive pour un paquet mis, cest la e couche IP elle-mme qui g`re le probl`me, la plupart des cas sans en informer e e e les couches suprieures (certaines applications utilisent ICMP7 ). e Initialement prvu pour permettre aux passerelles dinformer les htes sur e o des erreurs de transmission, ICMP nest pas restreint aux changes passerellese htes, des changes entres htes sont tout ` fait possibles. o e o a Le mme mcanisme est valable pour les deux types dchanges. e e e

6 7

voir ou revoir la gure II.02 du chapitre dintroduction ` IP (page 25) a Mme gure quau point prcdent e e e

60

Protocole IP

4.2

Format des messages ICMP

Chaque message ICMP traverse le rseau dans la partie DATA dun dae tagramme IP :
Entete IP Message ICMP

gure IV.09 Message ICMP La consquence directe est que les messages ICMP sont routs comme e e les autres paquets IP au travers le rseau. Il y a toutefois une exception : e il peut arriver quun paquet derreur rencontre lui-mme un probl`me de e e transmission, dans ce cas on ne gn`re pas derreur sur lerreur ! e e Il est important de bien voir que puisque les messages ICMP sont encapsuls dans un datagramme IP, ICMP nest pas considr comme un protocole e ee de niveau plus lev. e e La raison de lutilisation dIP pour dlivrer de telles informations, est que e les messages peuvent avoir ` traverser plusieurs rseaux avant darriver ` leur a e a destination nale. Il ntait donc pas possible de rester au niveau physique e du rseau (` linverse de ARP ou RARP). e a La gure IV.10 dcrit le format du message ICMP : e
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 caractrise le probl`me e e quil signale. Un en-tte de 32 bits est compos comme suit : e e TYPE contient le code derreur. CODE compl`te linformation du champ prcdent. e e e CHECKSUM est utilis avec le mme mcanisme de vrication que pour les e e e e datagrammes IP mais ici il ne porte que sur le message ICMP (rappel : le checksum de len-tte IP ne porte que sur son en-tte et non sur les e e donnes vhicules). e e e En addition, les messages ICMP donnent toujours len-tte IP et les 64 pree miers bits (les deux premiers mots de quatre octets) du datagramme qui est ` a lorigine du probl`me, pour permettre au destinataire du message didentier e quel paquet est ` lorigine du probl`me. a e

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 utiliss. Il existe onze valeurs de TYPE direntes. e e 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 reoit une telle requte doit formuler un c e 8 message ICMP echo reply en retour Ce mcanisme est extrmement utile, la plupart des implmentations e e e 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 dlivrer un datagramme IP, elle envoie un message ICMP destination e unreachable ` lmetteur. a e Dans ce cas le champ CODE compl`te le message derreur avec : e 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 hte, il est rejet. o e Un paquet arrive trop vite quand la machine qui doit le lire est congestionne, trop de trac ` suivre.. . . e a Dans ce cas la machine en question envoie un paquet ICMP source quench qui est interprt de la faon suivante : ee c Lmetteur ralenti le rythme denvoi de ses paquets jusqu` ce quil e a cesse de recevoir ce message derreur. La vitesse est donc ajuste par e une sorte dapprentissage rustique. Puis graduellement il augmente le dbit, aussi longtemps que le message source quench ne revient pas e .
8

Pour des raisons de scurit certaines machines peuvent ne pas rpondre. e e e

62

Protocole IP Ce type de paquet ICMP a donc tendance ` vouloir rguler le ux des daa e tagrammes au niveau IP alors que cest une fonctionnalit de la couche e de transport (TCP). Cest donc une srieuse entorse ` la r`gle dindpendance des couches. e a e e Redirect (5) Les tables de routage (Voir le paragraphe 6) des stations restent assez statiques durant de longues priodes. Le syst`me dexploie e tation les lit au dmarrage sur le syst`me de chiers et ladministrateur e e en change de temps en temps les lments. ee Si entre deux modications une destination change demplacement, la donne initiale dans la table de routage peut savrer incorrecte. e e Les passerelles connaissent de bien meilleures routes que les htes euxo mmes, ainsi quand une passerelle dtecte une erreur de routage, elle e e fait deux choses : 1. Elle envoie ` lmetteur du paquet un message ICMP redirect a e 2. Elle redirige le paquet vers la bonne destination. Cette redirection ne r`gle pas les probl`mes de routage car elle est lie e mite aux interactions entres passerelles et htes directement connects. e o e La propagation des routes aux travers des rseaux multiples est un e autre probl`me. e 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 dtail e dans le paragraphe 6.4. Time exceeded (11) Chaque datagramme contient un champ TTL dit TIME TO LIVE appell aussi hop count . e An de prvenir le cas ou un paquet circulerait ` linni dune passerelle e a ` une autre, chaque passerelle dcrmente ce compteur et rejette le a e e paquet quand le compteur arrive ` zro et envoie un message ICMP ` a e a lmetteur pour le tenir au courant. e

5 Protocole IGMP

63

Protocole IGMP

IGMP, lacronyme de Internet Group Management Protocol , est historiquement dni dans lAnnexe I de la RFC 1112. e Sa raison dtre est que les datagrammes ayant une adresse multicast9 e sont ` destination dun groupe dutilisateurs dont lmetteur ne connait ni le a e nombre ni lemplacement. Lusage du multicast tant par construction ddi e e e 10 aux applications comme la radio ou la vido sur le rseau , donc consommae e trices 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 associes avec des e ux doctets que personne nutilise plus !

5.1

Description de len-tte e

IGMP est un protocole de communication entre les routeurs susceptibles de transmettre des datagrammes multicast et des htes qui veulent senregistrer o dans tel ou tel groupe. IGMP est encapsul dans IP11 avec le protocole numro e e 2. Comme le montre la gure Romanchapter.12, sa taille est xe (contrairement ` ICMP) : seulement 2 mots a 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-tte IGMP e 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 rponse dun hte. e o Inutilis . . . e Checksum Le checksum est calcul comme celui dICMP. e Adresse Cest ladresse multicast (classe D) ` laquelle appartient lhte qui a o rpond. e

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

64

Protocole IP

5.2

Fonctionnement du protocole

La RFC 1112 prcise que les routeurs multicast envoient des messages e de questionnement (Type=Queries) pour reconna quels sont les ventuels tre e htes appartenant ` quel groupe. Ces questions sont envoyes ` tous les htes o a e a o des LANs directement raccords ` laide de ladresse multicast du groupe e a 12 224.0.0.1 encapsul dans un datagramme IP ayant un champ TTL=1. Tous e les htes susceptibles de joindre un groupe multicast coutent ce groupe par o e hypoth`se. e Les htes, dont les interfaces ont t correctement congures, rpondent o ee e e ` une question par autant de rponses que de groupes auxquels ils apa e partiennent sur linterface rseau qui a reu la question. An dviter une e c e tempte de rponses chaque hte met en uvre la stratgie suivante : e e o e 1. Un hte ne rpond pas immdiatement ` la question reue. Pour chaque o e e a c groupe auquel il appartient, il attend un dlais compris entre 0 et 10 e secondes, calcul alatoirement ` partir de ladresse IP unicast de line e a terface qui a reu la question, avant de renvoyer sa rponse. La gure c e Romanchapter.13 montre un tel change, remarquez au passage la vae leur des adresses. 2. La rponse envoye est coute par tous les membres du groupe appare e e e tenant au mme LAN. Tout ceux qui sapprtaient ` envoyer une telle e e a rponse au serveur en interrompent le processus pour viter une redite. e e Le routeur ne reoit ainsi quune seule rponse pour chaque groupe, et c e 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 ` la stratgie ci-dessus. La premi`re est que si une a e e question est reue alors que le compte ` rebours pour rpondre ` une rponse c a e a e est en cours, il nest pas interrompu. La deuxi`me est quil ny a jamais de dlai appliqu pour lenvoi de dae e e tagramme 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 frquence tr`s faible de lordre de la minute, e e
12

tous les htes du LAN o

Protocole IGMP an de prserver au maximum la bande passante du rseau. Si aucune rponse e e e ne leur parvient pour tel ou tel groupe demand prcdement, le routage sine e e terrompt. Quand un hte rejoint un groupe, il envoie immdiatement une rponse o e e (type=report) pour le groupe (les) qui lintresse, plutt que dattendre une e o question du routeur. Au cas o` cette rponse se perdrait il est recommand u e e deectuer une rmission dans un court dlai. ee e Remarques : 1. Sur un LAN sans routeur pour le multicast, le seul trac IGMP est celui des htes demandant ` rejoindre tel ou tel groupe. o a 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 ddie aux applications utilisant une valeur de 1 pour le champ TTL e e (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 consquence les applications qui utilisent le multicast (avec une e adresse suprieure ` 224.0.0.225) pour dcouvrir des services, doivent e a e avoir une stratgie pour augmenter la valeur du champ TTL en cas de e non rponse. e

65

5.3

Fonctionnement du Mbone

Prcisions en cours. . . e

66

Protocole IP

Routage IP

Ce paragraphe dcrit de mani`re succincte le routage des datagrammes. e e Sur lInternet, ou au sein de toute entit qui utilise IP, les datagrammes ne e sont pas routs par des machines Unix, mais par des routeurs dont cest la e fonction par dnition. Ils sont plus ecaces et plus perfectionns pour cette e e tche par construction, et surtout autorisent lapplication dune politique de a routage ( routing policy ) ce que la pile IP standard dune machine Unix ne sait pas faire. Toutefois il est courant dans les petits rseaux , ou quand e le probl`me ` rsoudre reste simple, de faire appel ` une machine Unix pour e a e a 13 ce faire . Dans ce paragraphe nous examinons le probl`me du routage de mani`re e e synthtique, nous laborderons plus en dtail les aspects techniques du roue e tage 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 thoriquement capables deectuer cette opration. e e La dirence entre un routeur et un hte est que le premier est e o capable de transmettre un datagramme dun interface ` un autre et pas le a deuxi`me. e Cette opration est dlicate si les machines qui doivent dialoguer sont e e connectes ` de multiples rseaux physiques. e a e Dun point de vue idal tablir une route pour des datagrammes dee e vrait tenir compte dlments comme la charge du rseau, la taille des daee e tagrammes, le type de service demand, les dlais de propagation, ltat des e e e liaisons, le trajet le plus court. . . La pratique est plus rudimentaire ! Il sagit de transporter des datagrammes aux travers de multiples rseaux e physiques, donc aux travers de multiples passerelles. On divise le routage en deux grandes familles : Le routage direct Il sagit de dlivrer un datagramme ` une machine race a corde au mme LAN. e e Lmetteur trouve ladresse physique du correspondant (ARP), encape sule le datagramme dans une trame et lenvoie. Le routage indirect Le destinataire nest pas sur le mme LAN comme e prcdement. Il est absolument ncessaire de franchir une passerelle e e e connue davance ou demployer un chemin par dfaut. e En eet, toutes les machines ` atteindre ne sont pas forcment sur le a e mme rseau physique. Cest le cas le plus courant, par exemple sur e e lInternet qui regroupe des centaines de milliers de rseaux dirents. e e Cette opration est beaucoup plus dlicate que la prcdente car il faut e e e e slectionner une passerelle. e
On peut consulter par exemple http://www.freebsd.org/$\sim$picobsd/, o` le site u du projet Zebra de GNU http://www.zebra.org/
13

Table de routage IP Parceque le routage est une opration fondamentalement oriente e e rseau , le routage sappuie sur cette partie de ladresse IP du destinae taire. La couche IP dtermine celle-ci en examinant les bits de poids fort qui e conditionnent la classe dadresse et donc la segmentation network.host . Dans certain cas (CIDR) le masque de sous rseau est aussi employ. e e Muni de ce numro de rseau, la couche IP examine les informations e e contenues dans sa table de routage :

67

6.1

Table de routage

Sous Unix toutes les oprations de routage se font grce ` une table, dite e a a table de routage , qui se trouve dans le noyau lui-mme. La gure IV.14 e rsume la situation : e

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`s frquemment utilise par IP : sur un serveur plusieurs e e e centaines de fois par secondes. Comment est-elle cre ? e Au dmarrage avec la commande route, invoque dans les scripts de e e lancement du syst`me, et en fonctionnement : e Au coup par coup avec la commande route, ` partir du shell (admia nistrateur syst`me uniquement). e Dynamiquement avec les dmons de routage routed ou gated e (la frquence de mise ` jour est typiquement de lordre de 30 sec.). e a

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 mmoriser cette table comme tant essentiellement compose e e e dune colonne origine, dune colonne destination. De plus, chaque route qui dsigne une passerelle (ici la route par dfaut) e e doit saccompagner dun nombre de sauts ( hop ), ou encore mtrique, qui e permet le choix dune route plutt quune autre en fonction de cette valeur. o Chaque franchissement dun routeur compte pour un saut. Dans la table ci-dessus, la mtrique de la route par dfaut est 1. e e Remarque : la sortie de la commande netstat -rn ci-dessus a t simee 14 plie. e Les drapeaux ( ags ) les plus courants : C c D G H L M S U W
14

La route est gnre par la machine, ` lusage. e ee a La route a t cre dynamiquement (dmons de routage). ee e e La route dsigne une passerelle, sinon cest une route directe. e La route est vers une machine, sinon elle est vers un rseau. e Dsigne la conversion vers une adresse physique (cf ARP). e La route a t modie par un redirect . ee e La route a t ajoute manuellement. ee e La route est active. La route est le rsultat dun clnage. e o

Des colonnes Refs, Use et Netif

Routage statique La gure IV.15 prcise larchitecture du rseau autour de la machine sur e e laquelle a t excut le netstat. ee e e

69

Subnet 000

.14 link 1

.35 link 2

Subnet 001

.36

gure IV.15 Situation rseau lors du netstat e

6.2

Routage statique

Comme nous avons pu le deviner au paragraphe prcdent, les routes stae e tiques sont celles cres au dmarrage de la machine ou ajoutes manuellement e e e par ladministeur syst`me, en cours de fonctionnement. e Le nombre de machines possibles ` atteindre potentiellement sur lIna ternet est beaucoup trop lev pour que chaque machine puisse esprer en e e e conserver ladresse, qui plus est, mme si cela tait concevable, cette infore e mation ne serait jamais ` jour donc inutilisable. a Plutt que denvisager la situation prcdente on prf`re restreindre o e e ee ltendue du monde connu et utiliser la stratgie de proche en proche e e prcdement cite. e e e Si une machine ne peut pas router un datagramme, elle connait (ou est suppose conna e tre) ladresse dune passerelle suppose tre mieux informe e e e pour transmettre ce datagramme. Dans lexemple de sortie de la commande netstat du paragraphe 6.1, on peut reconna que ladministrateur syst`me na congur quune seule tre e e 15 route manuellement , toutes les autres lignes ont t dduites par la ee e couche IP elle-mme. e La gure IV.16 met en situation plusieurs rseaux et les passerelles qui e les relient. Voici une version tr`s simplie des tables de routage statiques e e prsentes sont les machines A, B, R1 et R2 : e 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 ` fait exact, nous verrons pourquoi au paragraphe concernant lina terface 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 rsume les oprations de la couche IP pour choie e e sir une destination, en fonction de sa table de routage. Cette opration est e essentiellement base sur le numro de rseau, IN , extrait de ladresse IP, ID . e e e M dsigne la machine sur laquelle seectue le routage. e Si IN est un numro de rseau auquel M est directement relie : e e e Obtenir ladresse physique de la machine destinatrice Encapsuler le datagramme dans une trame physique et lenvoyer directement. Sinon Si ID apparait comme une machine ` laquelle une route spciale est a e attribue, router le datagramme en fonction. e Sinon Si IN apparait dans la table de routage, router le datagramme en fonction. Sinon Sil existe une route par dfaut router le datagramme vers la e passerelle ainsi dsigne. e e Sinon Dclarer une erreur de routage (ICMP). e

Routage dynamique

71

6.3

Routage dynamique

Si la topologie dun rseau ore la possibilit de plusieurs routes pour e e atteindre une mme destination, sil est vaste et complexe, sujet ` des chane a gements frquents de conguration. . .Le routage dynamique est alors un bon e moyen dentretenir les tables de routages et de mani`re automatique. e Il existe de nombreux protocoles de routage dynamique dont certains sont aussi anciens que lInternet. Nanmoins tous ne conviennent pas ` tous les e a types de probl`me, il en existe une hirarchie. e e Schmatiquement on peut imaginer lInternet comme une hirarchie de e e 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`re avec ce que lon nomme les Autonomous systems , e cest ` dire des syst`mes de routeurs et de rseaux qui poss`dent leurs a e e e mcanismes propres de propagation des routes. Le protocole utilis par ces e e 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`me autonome on utilise un IGP ( Interior Gateway e Protocol ) cest ` dire un protocole de gateways intrieurs . Les protocoles a e les plus couramment employs sont RIP ( Routing Information Protocol ) e qui est simple ` comprendre et ` utiliser, ou encore OSPF ( Open Shortest a a Path First ) plus rcent, plus capable mais aussi beaucoup plus complexe ` e 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 dans la e RFC 1058 (1988 - Version 1 du protocole) et la RFC 1388 (1993 - Version 2 du protocole). Ce protocole est bas sur des travaux plus anciens mens par e e 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 tablie en nombre de sauts e ( hop ), ou mtrique, entre la source et la destination, cest ` dire en e a comptant toutes les liaisons. Cette distance est exprime comme un nombre e entier variant entre 1 et 15 ; la valeur 16 est considre comme linni et ee indique une mise ` lcart de la route. a e Chaque routeur met dans un datagramme portant une adresse IP de e broadcast, ` frquence xe (environ 30 secondes), le contenu de sa table de a e routage et coute celle des autres routeurs pour complter sa propre table. e e Ainsi se propagent les tables de routes dun bout ` lautre du rseau. Pour a e viter une temptes de mises ` jours , le dlais de 30 secondes est augment e e a e e dune valeur alatoire comprise entre 1 et 5 secondes. e Si une route nest pas annonce au moins une fois en trois minutes, la e distance devient innie , et la route sera retire un peu plus tard de la e table (elle est propage avec cette mtrique). e e Ladresse IP utilise est une adresse de multipoint ( multicast ) comme e nous verrons au paragraphe 6.4 Depuis la dnition de RIPv2 les routes peuvent tre accompagnes du e e e masque de sous rseau qui les caractrise. Ainsi on peut avoir la situation e e 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`s propagation des routes, la table de routage du routeur R1 pourrait e bien ressembler ` : a

Dcouverte de routeur et propagation de routes e Source 192.168.192.224 192.168.10.0 192.168.11.0 192.168.192.64 Destination R1 R1 R2 R3 Cot u 1 1 2 3

73

Avec une route par dfaut qui est le routeur R2. La constitution de cette e table nest possible quavec RIPv2 tant donn lexistence des deux souse e rseaux de la classe C 192.168.192. e Le fonctionnement de ce protocole est dtaill page 113 e e 6.3.2 OSPF Open Shortest Path First

Contrairement ` RIP, OSPF nutilise pas de vecteur de distances mais a base ses dcisions de routage sur le concept d tats des liaisons . Celuie e ci permet un usage beaucoup plus n des performances relles des rseaux e e traverss, parceque cette mtrique est changeante au cours du temps. Si on e e ajoute ` cela une mthode de propagation tr`s rapide des routes par inona e e dation, sans boucle et la possibilit de chemin multiples, OSPF, bien que e beaucoup plus complexe que RIP, a toutes les qualits pour le remplacer, e mme sur les tous petits rseaux. e e OSPF doit son nom ` lalgorithme dEdsger W. Dijkstra16 de recherche a 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 dtaill page 121 e e

6.4

Dcouverte de routeur et propagation de routes e

Au dmarrage dune station, plutt que de congurer manuellement les e o routes statiques, surtout si elle sont susceptibles de changer et que le nombre de stations est grand, il peut tre intressant de faire de la dcouverte e e e automatique de routeurs (RFC 1256). ` A intervals rguliers les routeurs diusent des messages ICMP de type 9 e ( router advertisement ) dannonces de routes. Ces messages ont ladresse multicast 224.0.0.1, qui est a destination de tous les htes du LAN. o Toutes les stations capables de comprendre le multicast (et convenablement congures pour ce faire) coutent ces messages et mettent ` jour leur e e a table. Les stations qui dmarrent peuvent solliciter les routeurs si lattente est e trop longue (environ 7 minutes) avec un autre message ICMP, de type 10 ( router sollicitation ) et avec ladresse multicast 224.0.0.2 (` destination a de tous les routeurs de ce LAN). La rponse du ou des routeurs est du type e unicast , sauf si le routeur sapprtait ` mettre une annonce. e ae
16

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

74

Protocole IP ` A chaque route est associ un niveau de prfrence et une dure de vae ee e lidit, dnis par ladministrateur du rseau. Une validit nulle indique un e e e e routeur qui sarrte et donc une route qui doit tre supprime. e e e Si entre deux annonces une route change, le mcanisme de ICMP redie rect , examin au paragraphe suivant, corrige lerreur de route. e La dcouverte de routeur nest pas un protocole de routage, son objectif e est bien moins ambitieux : obtenir une route par dfaut. e Il est intressant de noter sur les machines FreeBSD cest le dmon de e e 17 routage routed qui eectue ce travail ` la demande a

6.5

Message ICMP redirect

La table de routage peut tre modie dynamiquement par un message e e 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 reoit le datagramme, scrute sa table de routage et c sapperoit quil faut dsormais passer par R2. Pour se faire : c e 1. Il re-route le datagramme vers R2, ce qui vite quil soit mis deux e e fois sur le LAN. 2. Il envoie un message ICMP redirect (type 5) ` la station, lui a indiquant la nouvelle route vers R2. Ce travail seectue pour chaque datagramme reu de la station. c D`s que la station reoit le message ICMP redirect elle met ` jour sa e c a table de routage. La nouvelle route est employe pour les datagrammes e qui suivent (vers la mme direction). e La route modie est visible avec la commande netstat -r, elle gure e avec le drapeau M (modication dynamique). Pour des raisons videntes de scurit, cette possibilit nest valable que e e e e sur un mme LAN. e
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 implmentations dIP supportent une interface de type e loopback . Lobjet de cette interface est de pouvoir utiliser les outils du rseau en local, sans passer par un interface rseau rel (associ ` une e e e e a carte physique). La gure IV.22 ci-contre, montre que la couche IP peut utiliser, selon le routage, linterface standard du rseau, o` linterface de loopback. e u Le routage est ici bien sr bas u e sur ladresse IP associe ` chacune e a des interfaces. Cette association est eectue sur une machine Unix ` e a laide de la commande ifconfig, qui tablit une correspondance entre un e pilote de priphrique (repr par son e e ee chier spcial) et une adresse IP. e Dans le cas du pilote de loopback, ladresse est standardise ` nimporte e a quelle adresse valide du rseau 127 e (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` lexplication de la ligne ci-dessous u dj` rencontre (page 67) dans le cadre de la table de routage : ea e 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 dj` ea prvue demble dans les scripts de dmarrage. e e e Concr`tement, tout dialogue entre outils clients et serveurs sur une mme e e machine est possible et mme souhaitable sur cet interface pour amliorer les e e performances et parfois la scurit18 . e e 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 ultrieurement (cf chapitre VIII) que le ltrage IP sur le 127/8 est aussi e ais que sur nimporte quel autre rseau e e

18

76

Protocole IP

Finalement, comment a marche ? c

Dans ce paragraphe nous reprenons la gure III.06 (page 44) et nous y apportons comme tait annonc une explication du fonctionnement qui tienne e e compte des protocoles principaux examins dans ce chapitre. Pour cela nous e utilisons deux rseaux privs de la RFC 1918 : 192.168.10.0 et 192.168.20.0 e e et nous faisons lhypoth`se que la passerelle fonctionne comme une machine e 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 rsume ladressage physique et logique de la situation : e 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`ses suivantes : e 1. Les caches arp des machines A, B et R sont vides 2. La machine A a connaissance dune route vers le rseau 192.168.20 e passant par 192.168.10.249 et rciproquement la machine B voit le e rseau 192.168.10.0 via le 192.168.20.249 e 3. La machine A a connaissance de ladresse IP de la machine B La machine A envoie un datagramme ` la machine B, que se a passe t-il sur le rseau ? e Etape 1 La machine A applique lalgorithme de routage (page 70) et sapperoit que la partie rseau de ladresse de B nest pas dans le mme c e e LAN (192.168.10/24 et 192.168.20/20 di`rent). e Lhypoth`se 2 entraine quune route route existe pour atteindre ce e rseau, passant par R. Ladresse IP de R est dans le mme LAN, e e A peut donc atteindre R par un routage direct. La consquence de e lhypoth`se 1 implique que pour atteindre R directement il nous faut e dabord dterminer son adresse physique. Le protocole ARP (page 55) e doit tre utilis. e e

Finalement, comment a marche ? c A envoie en consquence une trame ARP (page 57 comportant les e lments suivants : ee 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 rpond ` la question ARP par une rponse ARP e a e (OPERATION contient 2) et un champ compl`t : ee 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 ` B en passant par R. a Il sagit de routage indirect puisque ladresse de B nest pas sur le mme e LAN. Les adresses physiques et logiques se rpartissent maintenant e 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 reu le datagramme depuis A et ` destination de B. Celle-ci c a est sur un LAN dans lequel R se trouve galement, un routage direct e est donc le moyen de transfrrer le datagramme. Pour la mme raison e e qu` ltape 1 R na pas ladresse MAC de B et doit utiliser ARP pour a e obtenir cette adresse. Voici les lments de cette question ARP : ee 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 rponse ARP : e 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`re tape, R envoie le datagramme en proe e venance de A, ` B : a

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 ltape 3. Si les adresses e IP nont pas chang, les adresses MAC, di`rent compl`tement ! e e e Remarque : Si A envoie un deuxi`me datagramme, les caches ARP ont e les adresses MAC utiles et donc les tape 1, 2, 4 et 5 deviennent inutiles. . . e

Conclusion sur IP

Apr`s notre tour dhorizon sur IPv4 nous pouvons dire en conclusion que e son espace dadressage trop limit nest pas la seule raison qui a motiv les e e travaux de recherche et dveloppement dIPv6 : e 1. Son en-tte comporte deux probl`mes, la somme de contrle (checksum) e e o doit tre calcule ` chaque traitement de datagramme, chaque routeur e e a doit analyser le contenu du champ option. 2. Sa conguration ncessite au moins trois informations que sont e ladresse, le masque de sous rseau et la route par dfaut. e e 3. Son absence de scurit est insupportable. Issu dun monde ferm o` la e e e u scurit ntait pas un probl`me, le datagramme de base nore aucun e e e e service de condentialit, dintgrit et dauthentication. e e e 4. Son absence de qualit de service ne rpond pas aux exigences des e e protocoles applicatifs modernes (tlphonie, vido, jeux interactifs en ee e rseau, . . .). Le champ TOS nest pas susant et surtout est interprt e ee de mani`re inconsistante par les quipements. e e

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 dni dans la e RFC 768 [Postel 1980]. Les donnes encapsules dans un en-tte UDP sont des e e e paquets UDP.

1.1

Identication de la destination

Rappel : Au niveau de la couche Internet les datagrammes sont routs e dune machine ` une autre en fonction des bits de ladresse IP qui identient le a numro de rseau. Lors de cette opration aucune distinction nest faite entre e e e les services ou les utilisateurs qui mettent ou recoivent des datagrammes, ie e tous les datagrammes sont mlangs. e e La couche UDP ajoute un mcanisme qui permet lidentication du service e (niveau Application). En eet, il est indispensable de faire un tri entre les divers applications (services) : plusieurs programmes de plusieurs utilisateurs peuvent utiliser simultanment la mme couche de transport et il ne doit pas e e y avoir de confusion entre eux. Pour le syst`me Unix les programmes sont identis de mani`re unique e e e par un numro de processus, mais ce numro est phm`re, non prvisible ` e e e e e e a distance, il ne peut servir ` cette fonction. a Lide est dassocier la destination ` la fonction quelle remplie. Cette e a identication se fait ` laide dun entier positif que lon baptise port. a Le syst`me dexploitation local a ` sa charge de dnir le mcanisme e a e e qui permet ` un processus daccder ` un port. a e a La plupart des syst`mes dexploitation fournissent le moyen dun acc`s e e synchrone ` un port. Ce logiciel doit alors assurer la possibilit de grer a e e la le dattente des paquets qui arrivent, jusqu` ce quun processus a (Application) les lise. A linverse, lOS, Operating System , bloque un processus qui tente de lire une donne non encore disponible. e Pour communiquer avec un service distant il faut donc avoir connaissance

82

Protocole UDP de son numro de port, en plus de ladresse IP de la machine elle-mme. e e On peut prvoir le numro de port en fonction du service ` atteindre, e e a cest lobjet du paragraphe 1.3. La gure V.01 explicite la notion de port. La couche IP spare les datae 1 grammes SCTP, TCP et UDP grce au champ PROTO de son en-tte, lassociaa e tion du protocole de transport et du numro de port identie un service sans e ambigu e. t Conceptuellement on sapperoit alors que rien ne soppose ` ce quun c a mme service (Numro de port) soit attribu conjointement aux trois protoe e e coles (en pointills sur la gure). Cette situation est dailleurs courante dans e la ralit des serveurs. e e

Application

Port 1

Port 2

Port 3 Message

Transport

UDP Paquet UDP

TCP

SCTP

Internet

IP

gure V.01 Numro de port comme numro de service e e

Cf description page 47

Description de len-tte e

83

1.2

Description de len-tte e

Un paquet UDP est conu pour tre encapsul dans un datagramme IP c e e et permettre un change de donnes entre deux applications, sans change e e e prliminaire. Ainsi, si les donnes ` transmettre nobligent pas IP ` frage e a a menter (cf page 52), un paquet UDP gn`re un datagramme IP et cest tout ! e e

Header IP

Paquet UDP = donnes dIP

PROTO

= UDP

gure V.02 UDP encapsul dans IP e UDP apporte un mcanisme de gestion des ports, au dessus de la couche e Internet. UDP est simplement une interface au dessus dIP, ainsi lmission e des messages se fait-elle sans garantie de bon acheminement. Plus gnralement, tous les dfauts dIP recenss au chapitre prcdent sont e e e e e e applicables ` UDP. a Plus particuli`rement, les paquets ` destination dune application UDP e a sont conservs dans une pile de type FIFO. Si lapplication destinae trice ne les consomme pas assez rapidement, les plus anciens paquets risquent dtre crass par les plus rcents. . .Un risque supplmentaire e e e e e (par rapport aux proprits dIP dj` connues) de perte de donnes. ee ea e Il ny a aucun retour dinformation au niveau du protocole pour apporter un quelconque moyen de contrle sur le bon acheminement des o donnes. e Cest au niveau applicatif quil convient de prendre en compte cette lacune. UDP est aussi dsign comme un mode de transport non connect, e e e ou encore mode datagramme, par opposition ` TCP ou SCTP que nous a examinerons dans les prochains chapitres. Parmis les utilisations les plus courantes dUDP on peut signaler le serveur e e de noms2 , base de donnes rpartie au niveau mondial, et qui saccomode tr`s bien de ce mode de transport. e En local dautres applications tr`s utiles comme tftp ou nfs sont e galement susceptibles demployer UDP. e

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

84 La gure V.03 dcrit la structure de len-tte. e e

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

Protocole UDP

0 UDP DESTINATION PORT CHECKSUM

gure V.03 Structure de len-tte UDP e UDP SOURCE PORT Le numro de port de lmetteur du paquet. Ce champ e e est optionnel, quand il est spci il indique le numro de port que le e e e destinataire doit employer pour sa rponse. La valeur zro (0) indique e e quil est inutilis, le port 0 nest donc pas celui dun service valide. e UDP DESTINATION PORT Le numro de port du destinataire du paquet. e MESSAGE LENGTH Cest la longueur du paquet, donc comprennant len-tte e 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 implmentations ne lutie lisent pas. Sil est employ, il porte sur un pseudo en-tte constitu de e e e la mani`re suivante : e
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-tte est prvu initialement pour apporter une protection e e en cas de datagrammes mal routs ! e

Ports rservs disponibles e e

85

1.3

Ports rservs ports disponibles e e

Le numro de port est un entier 16 bits non sign, les bornes sont donc e e [0, 65535], par construction. Nous avons vu prcdement que le port 0 nest e e pas exploitable en tant que dsignation de service valide, donc le segment e rellement exploitable est [1, 65535]. e Toute machine qui utilise la pile TCP/IP se doit de conna un certain tre nombre de services bien connus, reprs par une srie de ports bien connus ou ee e well known port numbers, pour pouvoir dialoguer avec les autres machines de lInternet (vs Intranet). Sur une machine Unix, cette liste de services est place dans le chier /etc/services et lisible par tous les utilisateurs et e toutes les applications. En eet, comme nous lexaminerons en dtail dans le cours de programe mation, un service (comprendre un programme au niveau applicatif) qui dmarre son activit rseau (et qui donc est considr comme ayant un rle e e e ee o de serveur) sattribue le (les) numro(s) de port qui lui revient (reviennent) e conformment ` cette table. e a 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 prsente quelques uns des ports bien connus e plus connus les plus utiliss, il y en a quantit dautres. . . e e 3 Une autorit, lIANA , centralise et diuse linformation relative ` tous e a
3

Internet Assigned Numbers Authority

86

Protocole UDP les nombres utiliss sur lInternet via une RFC. La derni`re en date est la e e RFC 1700, elle fait plus de 200 pages ! Par voie de consquence cette RFC concerne aussi les numros de ports. e e 1.3.1 Attribution des ports ancienne mthode e

Historiquement les ports de 1 ` 255 sont rservs aux services bien connus, a e e plus rcemment, ce segment ` t largi ` [1, 1023]. Aucune application ne e aeee a peut sattribuer durablement et au niveau de lInternet un numro de port e dans ce segment, sans en rfrrer ` lIANA, qui en contrle lusage. ee a o ` A partir de 1024 et jusqu` 65535, lIANA se contente denregistrer les a demandes dusage et signale les ventuels conits. e 1.3.2 Attribution des ports nouvelle mthode e

Devant lexplosion du nombre des services enregistrs lIANA a modi e e 4 la segmentation qui prc`de. Dsormais les numros de ports sont classs e e e e e selon les trois catgories suivantes : e 1. Le segment [1, 1023] est toujours rservs aux services bien connus. e e Les services bien connus sont dsigns par lIANA et sont mis en uvre e e par des applications qui sexcutent avec des droits privilgis (root sur e e e une machine Unix) 2. Le segment [1024, 49151] est celui des services enregistrs. e Ils sont numrs par lIANA et peuvent tre employs par des procese ee e e sus 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 privs ; nous en examinerons lusage dans le cours de proe grammation.

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 dni e dans la RFC 793 [Postel 1981c]. Les donnes encapsules dans un en-tte e e e TCP sont des paquets TCP .
Header IP Segment TCP = donnes IP

PROTO

= TCP

gure VI.01 TCP encapsul dans IP e

1.1

Caractristiques de TCP e

e e e TCP est bien plus compliqu1 quUDP examin au chapitre prcdent, il e apporte en contrepartie des services beaucoup plus labors. e e Cinq points principaux caractrisent ce protocole : e 1. TCP contient un mcanisme pour assurer le bon acheminement des e donnes. Cette possibilit est absolument indispensable d`s lors que e e e les applications doivent transmettre de gros volumes de donnes et de e faon able. c Il faut prciser que les paquets de donnes sont acquitts de bout en e e e bout et non de point en point. Dune mani`re gnrale le rseau assure e e e e lacheminement et les extrmits le contrle (Dave Clark). e e o 2. Le protocole TCP permet ltablissement dun circuit virtuel entre e les deux points qui changent de linformation. On dit aussi que TCP e
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 (par opposition ` UDP qui est en mode e a non connect ou encore mode datagramme). e Avant le transfert les 2 applications se mettent en relation avec leurs OS2 respectifs, les informent de leurs dsirs dtablir ou de recevoir e e 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 rseau pour vrier que le transfert est possible e e (autoris) et que les deux applications sont prtes pour leurs rles. e e o Une fois ces prliminaires tablis, les modules de protocole informent e e les applications respectives que la connexion est tablie et que le e transfert peut dbuter. e Durant le transfert, le dialogue entre les protocoles continue, pour vrier le bon acheminement des donnes. e e Conceptuellement, pour tablir une connexion un circuit virtuel e il faut avoir runis les lments du quintuplet : e ee Le protocole Cest TCP mais il y pourrait y avoir dautres transports qui assurent le mme service. . . e IP locale Adresse de la machine qui met. e Port local Le numro de port associ au processus. Il est impos ou e e e est dtermin automatiquement comme nous le verrons dans le e e cours de programmation. IP distante Adresse de la machine distante. Port distant Le numro de port associ au service ` atteindre. Il est e e a obligatoire de le conna prcisement. tre e Lensemble de ces cinq lments dnit un circuit virtuel unique. Que ee e lun deux change et il sagit dune autre connexion ! 3. TCP a la capacit de mmoriser3 des donnes : e e e Aux deux extrmits du circuit virtuel, les applications senvoient e e des volumes de donnes absolument quelconques, allant de 0 octet ` e a des centaines (ou plus) de Mo. ` A la rception, le protocole dlivre les octets exactement comme ils e e ont t envoys. ee e Le protocole est libre de fragmenter le ux de donnes en paquets e de tailles adaptes aux rseaux traverss. Il lui incombe cependant e e e deectuer le rassemblage et donc de stocker temporairement les e fragments avant de les prsenter dans le bon ordre ` lapplication. e a 4. TCP est indpendant vis ` vis des donnes transportes, cest un e a e e ux doctets non structur sur lequel il nagit pas. e
2 3

Operating System dans un buer

Description de len-tte e 5. TCP simule une connexion en full duplex . Pour chacune des deux applications en connexion par un circuit virtuel, lopration qui consiste e ` lire des donnes peut seectuer indpendamment de celle qui consiste a e e ` en crire. a e Le protocole autorise la clture du ot dans une direction tandis que o lautre continue ` tre active. Le circuit virtuel est rompu quand les a e deux parties ont clos le ux.

91

1.2

Description de len-tte e

La gure suivante montre la structure dun en-tte TCP. Sa taille normale e est de 20 octets, ` moins que des options soient prsentes. a e
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-tte TCP e TCP SOURCE PORT Le numro de port de lapplication locale. e TCP DESTINATION PORT Le numro de port de lapplication distante. e SEQUENCE NUMBER Cest un nombre qui identie la position des donnes ` e a transmettre par rapport au segment original. Au dmarrage de chaque e connexion, ce champ contient une valeur non nulle et non facilement prvisible, cest la squence initiale ou ISN4 e e TCP numrote chaque octet transmis en incrmentant ce nombre 32 bits e e non sign. Il repasse ` 0 apr`s avoir atteint 232 1 (4 294 967 295). e a e Pour le premier octet des donnes transmis ce nombre est incrment e e e de un, et ainsi de suite. . . ACKNOWLEDGEMENT NUMBER Cest un numro qui identie la position du dere nier octet reu dans le ux entrant. c Il doit saccompagner du drapeau ACK (voir plus loin). OFF pour OFFSET, il sagit dun dplacement qui permet datteindre les e donnes quand il y a des options. Cod sur 4 bits, il sagit du nombre e e de mots de 4 octets qui composent len-tte. Le dplacement maximum e e 4 est donc de 60 octets (2 1 4 octets). Dans le cas dun en-tte e 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 rservs pour un usage futur ! e e

Protocole TCP

CODE Six bits pour inuer sur le comportement de TCP en caractrisant e lusage du segment : URG Le champ URGENT POINTER doit tre exploit. e e ACK Le champ ACNOWLEDGMENT NUMBER doit tre exploit. e e PSH Cest une notication de lmetteur au rcepteur, pour e e lui indiquer que toutes les donnes collectes doivent tre e e e transmises ` lapplication sans attendre les ventuelles a e donnes qui suivent. e RST SYN FIN Re-initialisation de la connexion Le champ SEQUENCE NUMBER contient la valeur de dbut de connexion. e Lmetteur du segment a ni dmettre. e e

En fonctionnement normal un seul bit est activ ` la fois mais ce nest ea pas une obligation. La RFC 1024 [Postel 1987] dcrit lexistence de e paquets tcp dnomms Christmas tree ou paquet kamikaze e e comprenant les bits SYN+URG+PSH+FIN ! WINDOW Le ux TCP est control de part et dautre pour les octets come pris dans une zone bien dlimite et nomme fentre . La taille e e e e de celle-ci est dnie par un entier non sign de 16 bits, qui en limite e e donc thoriquement la taille ` 65 535 octets (ce nest pas compl`tement e a e exact, voir plus loin loption wscale). Chaque partie annonce ainsi la taille de son buer de rception. Par e construction, lmetteur nenvoie pas plus de donnes que le rcepteur e e e ne peut en accepter. Cette valeur varie en fonction de la nature du rseau et surtout de la e bande passante devine ` laide de statistiques sur la valeur du RTT. e a Nous y reviendrons au paragraphe 4. CHECKSUM Un calcul qui porte sur la totalit du segment, en-tte et donnes. e e e URGENT POINTER Ce champ nest valide que si le drapeau URG est arm. Ce e pointeur contient alors un oset ` ajouter ` la valeur de SEQUENCE a a NUMBER du segment en cours pour dlimiter la zone des donnes urgentes e e ` transmettre ` lapplication. a a Le mcanisme de transmission ` lapplication dpend du syst`me dexe a e e ploitation. OPTIONS Cest un param`trage de TCP. Sa prsence est dtecte d`s lors que e e e e e lOFFSET est suprieur ` 5. e a Les options utilises : e

Description de len-tte e mss La taille maximale du segment5 des donnes applicatives que e lmetteur accepte de recevoir. Au moment de ltablissement e e dune connexion (paquet comportant le ag SYN), chaque partie annonce sa taille de MSS. Ce nest pas une ngociation. Pour e de lEthernet la valeur est 1460 ( = M T U 2 20). timestamp pour calculer la dure dun aller et retour (RTT ou e round trip time ). wscale Facteur dchelle ( shift ) pour augmenter la taille de la e fentre au del` des 16 bits du champ WINDOW (> 65535). e a Quand cette valeur nest pas nulle, la taille de la fentre est de e 65535 2shif t . Par exemple si shift vaut 1 la taille de la fentre e est de 131072 octets soit encore 128 ko. nop Les options utilisent un nombre quelconque doctets par contre les paquet TCP sont toujours aligns sur une taille de mot de quatre e octets ; ` cet eet une option No Operation ou nop, code sur a e 1 seul octet, est prvue pour complter les mots. e e PADDING Remplissage pour se caler sur un mot de 32 bits. DATAS Les donnes transportes. Cette partie est de longueur nulle ` e e a ltablissement de la connexion, elle peut galement tre nulle par choix e e e de lapplication.

93

MSS= Maximum Segment Size

94

Protocole TCP

2
2.1

Dbut et clture dune connexion e o

Etablissement dune connexion

Ltablissement dune connexion TCP seectue en trois temps, comme le e schma de la gure 3 lexplicite. e
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 lmetteur du premier paquet avec le bit SYN a connaise sance du couple (adresse IP du rcepteur, numro de port du service soue e hait). e Lmetteur du premier paquet est ` lorigine de ltablissement du circuit e a e virtuel, cest une attitude gnralement qualie de cliente . On dit aussi e e e que le client eectue une ouverture active (active open). Le rcepteur du premier paquet accepte ltablissement de la connexion, e e ce qui suppose quil tait prt ` le faire avant que la partie cliente en prenne e e a 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 squence initiale (ISN = x). e 2. Le serveur rpond avec sa propre squence (ISN = y), mais il doit e e galement acquitter le paquet prcdent, ce quil fait avec ACK (seq = e e e x + 1). 3. Le client doit acquitter le deuxi`me segment avec ACK (seq = y + 1). e

Clture dune connexion o Une fois acheve cette phase nomme three-way handshake , les deux e e applications sont en mesure dchanger les octets qui justient ltablissement e e de la connexion.

95

2.2
2.2.1

Clture dune connexion o

Clture canonique o

Un change de trois segments est ncessaire pour ltablissement de la e e e connexion ; il en faut quatre pour quelle sach`ve de mani`re canonique ( ore e derly 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 Clture dune connexion o La raison est quune connexion TCP est full-duplex , ce qui implique que les donnes circulent indpendamment dans un sens et dans lautre. Les deux e e directions doivent donc pouvoir tre interrompues indpendamment lune de e e lautre. Lapplication qui envoie un paquet avec le drapeau FIN indique ` la couche a TCP de la machine distante quelle nenverra plus de donne. La machine e distante doit acquitter ce segment, comme il est indiqu sur la gure VI.04, e en incrmentant dune unit le sequence number . e e La connexion est vritablement termine quand les deux applications ont e e eectu ce travail. Il y a donc change de 4 paquets pour terminer la cone e nexion.

96

Protocole TCP Au total, sans compter les changes propres au transfert des donnes, les e e deux couches TCP doivent grer 7 paquets, il faut en tenir compte lors de la e conception des applications ! Sur la gure on constate que le serveur continue denvoyer des donnes e bien que le client ait termin ses envois. Le serveur a dtect cette attitude e e e par la rception dun caract`re de EOF (en C sous Unix). e e Cette possibilit a son utilit, notamment dans le cas des traitements dise e tants qui doivent saccomplir une fois toutes les donnes transmises, comme e par exemple pour un tri. 2.2.2 Clture abrupte o

Au lieu dun change de quatre paquets comme prcdement, un e e e mcanisme de reset est prvu pour terminer une connexion au plus vite (abore e tive release). Ce type darrt est typiquement gr par la couche TCP elle-mme quand e ee e lapplication est brutalement interrompue sans avoir eectu un appel ` e a la primitive close(2), comme par exemple lors dun appel ` la primitive a abort(2), ou apr`s avoir rencontr une exception non prise en compte ( core e e dump . . .). Lextremit qui arrte brutalement la connexion met un paquet assorti e e e du bit RST, apr`s avoir (ou non) envoy les derniers octets en attente6 . Ce e e paquet clt lchange. Il ne reoit aucun acquittement. o e c Lextrmit qui reoit le paquet de reset (bit RST), transmet les ventuelles e e c e derni`res donnes ` lapplication et provoque une sortie derreur du type e e a Connection reset par peer pour la primitive de lecture rseau. Comme e cest le dernier change, si des donnes restaient ` transmettre ` lapplication e e a a qui a envoy le RST elles peuvent tre dtruites. e e e

Emetteur
RST

Rcepteur

gure VI.05 Emission dun rst

6

Voir dans le cours de programmation, loption SO LINGER

3 Contrle du transport o

97

Contrle du transport o

Le bon acheminement des donnes applicatives est assur par un e e mcanisme dacquittement des paquets, comme nous avons dj` pu lexae ea miner partiellement au paragraphe prcdent. e e

3.1

Mcanisme de lacquittement e
Emetteur
Paquet i Horloge

Rcepteur

RTT

ACK Paquet i+1

gure VI.06 Mcanisme de lacquittement e Au dpart du Paquet i une horloge se dclenche. Si cette horloge dpasse e e e une valeur limite avant rception de lACK le Paquet i est retransmis e Cette valeur limite est base sur la constante MSL7 qui est un choix e dimplmentation, gnralement de 30 secondes ` 2 minutes. Le temps e e e a maximum dattente est donc de 2 M SL. Le temps qui scoule entre lmission dun paquet et la rception de son e e e 8 acquittement est le RTT , il doit donc tre infrieur ` 2 M SL. Il est e e a 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 dans les diverses les dattente sur les roue teurs. Lmetteur conserve la trace du Paquet i pour ventuellement le rene e voyer. Si on consid`re des dlais de transmission de lordre de 500 ms (voire plus), e e un tel mcanisme est totalement inadapt au transfert de ux de donnes. e e e On peut aussi remarquer quil sous-emploie la bande passante du rseau. e
7 8

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

98

Protocole TCP

3.2

Fentres glissantes e

Cette attente de lacquittement est pnalisante, sauf si on utilise un e 9 mcanisme de fentres glissantes , comme le sugg`re la gure VI.07 : e e e

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 fentre glissante e Avec ce principe, la bande passante du rseau est beaucoup mieux e employe. e Si lun des paquets doit tre remis, la couche TCP du destinataire aura e e toute linformation pour le replacer dans le bon ordre. ` A chaque paquet est associe une horloge comme sur la gure VI.06. e Le nombre de paquets ` envoyer avant dattendre le premier acquittea ment est fonction de deux param`tres : e 1. La largeur de la fentre prcise dans le champ WINDOW de len-tte. e e e e 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 ` la taille de cette fentre. a e (b) Chaque acquittement ACK envoy est assorti dune nouvelle e valeur de taille de la fentre, permettant ainsi ` lmetteur e a e dajuster ` tout instant le nombre de segment quil peut ena voyer simultanment. Celle valeur peut tre nulle, comme par e e exemple lorsque lapplication cesse de lire les donnes reues. e c Cest ce mcanisme qui assure le contrle de ux de TCP. e o
9 10

sliding windows voir le cours de programmation

Fentres glissantes e 2. La taille maximale des donnes, ou MSS11 vaut 512 octets par e dfaut. Cest la plus grande taille du segment de donnes que TCP e e enverra au cours de la session. Le datagramme IP a donc une taille gale au MSS augmente de e e 40 octets (20 + 20), en labsence doption de TCP. Cette option apparait uniquement dans un paquet assorti du drapeau SYN, donc ` ltablissement de la connexion. a e Comme de bien entendu cette valeur est fortement dpendante du e 12 support physique et plus particuli`rement du MTU . e Sur de lEthernet la valeur maximale est 1500220 = 1460, avec des trames lencapsultation 802.3 de lIEEE un calcul similaire conduit ` une longueur de 1452 octets. a Chaque couche TCP envoie sa valeur de MSS en mme temps que le e paquet de synchronisation, comme une option de len-tte. Cette e valeur est calcule pour viter absolument la fragmentation de IP e e au dpart des datagrammes. e

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 Dtail de la fentre glissante e e Le dbit obtenu dpend de la taille de la fentre et bien sr de la bande e e e u passante disponible. On conoit aisment quentre la situation de la gure c e VI.06 et celle de la gure VI.07 lusage de la bande passante samliore. Par e contre lagrandissement de la taille de la fentre ne se conoit que jusqu` une e c a limite optimale au dela de laquelle des paquets sont perdus parcequenvoys e trop rapidement pour tre reus par le destinataire. Or, pour fonctionner de e c mani`re optimale, TCP se doit de limiter au maximum la perte de paquets et e donc leur rmission. ee
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 fentre est, comme on e peut le deviner, fonction de la bande passante thorique du rseau et surtout e e de son taux doccupation instantann. Cette derni`re donne est uctuante, e e e aussi TCP doit-il asservir continuement les tailles de fentre pour en tenir e compte.

Complments sur le fonctionnement de TCP e

Lusage du protocole TCP di`re considrablement en fonction des applie e cations mises en uvre et des rseaux ` parcourir. e a Dapr`s [W. Richard Stevens], 10% des donnes changes sur le e e e e rseau concernent des applications interactives et 90% des applications qui e changent des ux de donnes. e e Si le protocole TCP reste le mme pour tous, les algorithmes qui le pilotent e sajustent en fonction de lusage. Pour le trac en volume ( bulk data ), TCP tente dutiliser des paquets les plus larges possibles pour maximiser le dbit, alors que le trac interactif e utilise des paquets quasiment vides mis le plus souvent ` la frquence de e a e frappe des utilisateurs ou au rythme des mouvements dune souris. Un exemple typique est celui de lapplication telnet pour laquelle les caract`res sont envoys un ` un dans un paquet dirent, chaque caract`re e e a e e tant ` lorigine de quatre paquets : mission dun caract`re, acquittement, e a e e retour de lcho du caract`re, acquittement. e e Si ce comportement nest absolument pas pnalisant sur un rseau rapide e e (LAN) par contre d`s que la bande passante commence ` tre stature il e a e e est prfrable de regrouper un maximum doctets (deux ou trois en pratique) ee dans un seul paquet pour en diminuer le nombre. Cest ce que fait lalgorithme de Nagle.

4.1

Algorithme de Nagle

Pour rduire le trac de ces tinygrams (RFC 896), lalgorithme de e Nagle (1984) dit quune connexion TCP ne peut pas attendre plus dun acquittement. Deux cas se prsentent donc : e 1. Le rseau est lent. Dans ce cas TCP accumule dans un mme buer les e e octets en partance. D`s rception de lacquittement il y a mission du e e e contenu du buer en un seul paquet. 2. Le rseau est rapide. Les acquittements arrivent rapidement les agrgats e e doctets peuvent tendre vers un seul caract`re par paquet. e La qualit lent/rapide du rseau est calcule ` partir du timestamp e e e a envoy dans les options de TCP et qui est tabli d`s le premier change (puis e e e e revalue statistiquement par la suite). e e Llgance de cet algorithme est quil est tr`s simple et quil sauto-rgule ee e e suivant le dlais de propagation. e

Dpart lent e Certaines applications dsactivent cet algorithme13 comme le serveur e Apache ou le syst`me de multi-fentrage X11. e e

101

4.2

Dpart lent e

Un paquet est remis parcequil arrive corrompu ou parcequil narrive e jamais. Une rmission entraine un blocage de lavancement de la fentre ee e glissante , pnalisant pour le dbit (cf conclusion du chapitre page 105). e e TCP consid`re quun paquet perdu est la consquence dun routeur (ou e e plus) congestionn, cest ` dire pour lequel les les dattente ne sont pas e a assez larges pour absorber tous les paquets entrants14 Dans ce contexte, on comprend bien quil vaut mieux ne pas envoyer la totalit du contenu de la fentre d`s le dbut de la connexion. Au contraire, e e e e TCP utilise un algorithme nomm slow start qui asservit lmission des e e paquets au rythme de la rception de leurs acquittements, plutt que de les e o mettre dun coup aussi rapidement que lautorise le syst`me ou le dbit e e e thorique du rseau. e e Ainsi, au dbut de chaque connexion ou apr`s une priode de calme e e e ( idle ) lmetteur envoie un premier paquet de taille maximale (le mss e du destinataire), et attend son acquittement. Quand celui-ci est reu, il enc voie deux paquets, puis quatre, et ainsi de suite jusqu` atteindre louverture a maximale de la fentre. e Durant cette progression, si des paquets sont perdus, il y a congestion suppose sur lun des routeurs franchis et louverture de la fentre est rduite e e e pour retrouver un dbit qui minimise le taux de retransmission. e Louverture de la fentre est nomme fentre de congestion ou encore e e e congestion window .

4.3

Evitement de congestion

Le contrle du ux voqu prcdement, pour viter la congestion des o e e e e e routeurs, est implment ` laide dune variable (cwnd) nomme congestion e ea e window que lon traduit par fentre de congestion. e Concr`tement, le nombre maximum de segments de donnes (M SS en e e octets) que lmetteur peut envoyer avant den recevoir le premier acquite tement est le minimum entre cette variable (cwnd) et la taille de la fentre e annonce par le rcepteur ` chaque acquittement de paquet. e e a Le contenu de cette variable est pilot par les algorithmes de dpart lent e e e slow start , voir 4.2 et dvitement de congestion ( congestion avoidance ) examin ici. e La limite de croissance de la variable cwnd est la taille de la fentre ane nonce par le rcepteur. Une fois la capacit de dbit maximale atteinte, e e e e si un paquet est perdu lalgorithme dvitement de congestion en diminue e
13 14

` laide de loption TCP NODELAY a Ce cas arrive frquemment quand un routeur spare un rseau rapide dun rseau lent e e e e

102

Protocole TCP linairement la valeur (contrairement au slow start qui laugmente expoe nentiellement).

Paquets capturs, comments e e

Le premier exemple montre un change de paquets de synchronisae tion (SYN) et de n (FIN) entre la machine clnt.chezmoi et la machine srv.chezmoi. Ltablissement de la connexion se fait ` laide de la commande e a telnet sur le port discard (9) du serveur srv.chezmoi. La machine qui est ` lorigine de ltablissement de la connexion est dite cliente, et celle qui a e est suppose prte ` rpondre, serveur. Pour information, le service discard e e a e peut tre considr comme lquivalent du chier /dev/null sur le rseau : e ee e e les octets quon lui envoie sont oublis ( discard ). e Lutilisateur tape :
Simultanment e la $ telnet srv discard capture des paquets Trying... est lance, e par Connected to srv.chezmoi. exemple dans une Escape character is ^]. autre fentre xterm. e

telnet> quit Connection closed. Et loutil danalyse rseau15 permet la capture pour lobservation des e changes suivants. Le numro qui gure en tte de chaque ligne a t ajout e e e ee e manuellement, le nom de domaine chezmoi a t retir, le tout pour ee e 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 amliorer la lisibilit les numros de squences vrais ne sont ine e e e diqus quau premier change. Les suivants sont relatifs. Ainsi le ack 1 e e de la ligne 2 doit tre lu 2072448002 (2072448001 + 1). e ` chaque change la valeur entre parenth`ses indique le nombre doctets A e e changs. e e
15

tcpdump que nous aurons loccasion dutiliser en TP

Exemples de ux 2. Les tailles de fentre (win) et de segment maximum (mss) ne sont pas e 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, repr par un point. ee Le deuxi`me exemple montre une situation de transfert de chier avec e 16 loutil ftp . Il faut remarquer que ltablissement de la connexion TCP est ici ` linie a tiative du serveur, ce qui peut laisser le lecteur perplexe. . .Lexplication est simple. En fait le protocole ftp fonctionne avec deux connexions TCP, la premi`re, non montre ici, est tablie du client vers le serveur, suppos ` e e e e a lcoute sur le port 21. Elle sert au client pour assurer le contrle du transfert. e o Lorsquun transfert de chier est demand via cette premi`re connexion, le e e serveur tablit une connexion temporaire vers le client. Cest cette connexion e que nous examinons ici. Elle est cloture d`s que le dernier octet demand e e e est transfrr. e 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 mcanisme e des fentres glissantes. Les lignes ont t numrotes manuellement et la date e ee e e associe ` chaque paquet supprime. e a e
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 : File Transfer Protocol e

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 reoit un tel paquet c est informe quelle doit transmettre ` lapplication toutes les donnes e a e reues, y compris celles transmises dans ce paquet. c Le positionnement de ce drapeau est ` linitiative de la couche TCP a mettrice et non ` lapplication. e a 2. Le type de service ( Type Of service tos 0x8) est demand par e lapplication pour maximiser le dbit (consulter le cours IP page 49). e
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 fentre glissante e

6 Conclusion sur TCP

105

Conclusion sur TCP

Le protocole TCP a t conu ` une poque o` lusage de la commande ee c a e u ligne tait universel, et les applications graphiques utilisant le rseau tr`s e e e rares. . . ! Une trentaine dannes plus tard, on peut faire le constat pratiquement e inverse : les applications textes interactives (beaucoup de petits messages applicatifs) disparaissent au prot dapplications moins interactives et qui sont plus orientes ux de donnes (vido, audio, tlphonie. . .) avec des e e e ee changes plus volumineux et des besoins en transport qui ont volu. e e e Le principe de la fentre glissante, si performant quil soit pour assurer e le bon acheminement des donnes, est bloquant pour certaines applications e comme le web. En eet, si le paquet de donnes de tte nest pas acquitt, les e e e suivants, mme reus, sont en attente avant dtre dlivrs ` lapplication. e c e e e a Si la rponse comporte par exemple de nombreuses zones graphiques e et textuelles direntes la uidit de la consultation est considrablement e e e amoindrie, et tenter de la compenser en tablissant un grand nombre de e connexions simultannes pour rcuprer individuellement les lments de e e e ee la page, consomme beaucoup de ressources syst`me et rseaux (celles de e e ltablissement des connexions) qui ne compense que partiellement ce soucis. e Lindpendance de TCP vis ` vis de la structure des donnes est galement e a e e un inconvnient dans certaines applications comme la tlphonie pour lae ee quelle la notion de messages successifs est bien plus intressante. e Depuis le dbut des annes 2000 lIETF met au point le protocole SCTP e e qui fournit des services similaires ` ceux de TCP, en abandonne certains et a apporte les nouvelles fonctionnalits adaptes aux nouveaux besoins. e e

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`me partie e Rseaux IP avancs e e

Chapitre VII Routage dynamique dIP

1 Introduction & rappels

La notion de routage est inhrente au fonctionnement du datagramme IP e (examin page 47). e Le routage des datagrammes IP nest rien dautre que lopration qui e consiste ` trouver une route pour les conduire vers la destination, cest ` dire a a ladresse du champ destination de len-tte (page 49). e Un premier examen du routage nous a conduit ` distinguer le routage a direct, sur un mme lan et associ ` lusage des services du protocole ARP e ea (Voir page 55) puis le routage indirect, appell ainsi parcequil fait appel aux e services dune ou plusieurs passerelles avant datteindre la destination. Dans les deux cas la dcision de routage porte sur la partie rseau de ladresse IP e e du destinataire, ou encore le netid. Le routage indirect se subdivise en deux catgories : le routage stae tique, qui implique lusage dune passerelle par dfaut et enn le routage e dynamique, sujet qui concerne ce chapitre. Lide dune route statique est sduisante par sa facilit de mise en uvre e e e pour lorganisation des petits rseaux . Elle se rsume le plus souvent ` e e a ajouter une simple ligne dans la conguration de lappareil ` raccorder au a rseau, et cette information vitale peut mme tre rcupre automatiquee e e e ee ment ` laide de protocoles comme BOOTP ou DHCP ! a 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 tre e envoys ` ladresse 138.195.52.129. Une seule route par dfaut peut tre e a e e dnie pour une pile IP comme il a t expliqu lors de lanalyse de lalgoe ee e rithme de routage page 70. Cette disposition tr`s simple est bien commode car elle vite de se poser e e des questions compliques sur le choix de la route, en dlguant ` dautres ce e ee a travail dlicat. En eet, il faudra bien ` un certain moment du trajet suivi par e a
1

http://www.cisco.com

110

Routage dynamique dIP les datagrammes, quun dispositif particulier, tymologiquement un routeur, e prenne une dcision face ` des possibilits multiples. e a e Ce routeur plus intelligent sera probablement celui qui permet ` vos daa tagrammes de rejoindre linternet si vous appartenez ` une entit qui a son a e autonomie (voir plus loin), ou le routeur du prestataires FAI pour un particulier, ou une plus petite entit, abonn ` un service xDSL quelconque. e ea La prsence de plusieurs routes possibles pour rejoindre une destination e implique de facto lusage dun protocole de routage dynamique. Une route statique privilgie une seule route et ignore les autres. Lexistence de plusieurs e routes est une ncessit pour assurer la redondance du service, voire mme e e e lquilibrage du trac sur plusieurs liens. e

1.1

IGP, EGP, Syst`me autonome e

Au commencement, lArpanet tait un seul rseau gr de mani`re hoe e ee e mog`ne, du moins par un ensemble de personnes dpendantes de la mme e e e entit administrative, ce qui permettait den orienter le dveloppement de la e e mme mani`re partout. Le protocole de routage dynamique tait un anctre e e e e du protocole RIP tudi dans ce chapitre. Ce protocole, comme on va le voir, e e implique que les routeurs schangent continuement des informations sur les e meilleures routes ` employer. Sans entrave, chaque routeur nit par avoir une a route pour atteindre tout le monde, partout ! Lextension de ce rseau ` des entits tr`s direntes entres elles, a conduit e a e e e les architectes rseaux de lpoque ` crer la notion de syst`me autonomes e e a e e (autonomous systems ou AS dans le texte), an de permettre ` chacun de a dvelopper son rseau interne sans risque den diuser le contenu ` lextrieur e e a e (soucis de condentialit et de scurit). e e e Un syst`me autonome se caractrise par un numro, ou numro dAS, sur e e e e 16 bits dont lattribution dpend de lIANA et de ses dlgations, par exemple e ee 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 adapts que dautres ` router des e a blocs dadresses IP conformment ` des politiques de routage (routing poe a licy) internationales, ce sont les EGP comme external gateway protocol. Leur anctre se nomme dailleurs EGP, il est remplac aujourdhui par BGP (Bore e der Gateway Protocol). ` A lintrieur du syst`me autonome, les protocoles de routages sont des e e IGP comme Interior Gateway Protocol et ne sont plus du tout adapts ` la e a gestion de linternet moderne. Par contre ils rpondent plus ou moins bien e au besoin des rseaux internes si compliqus et vastes soient-ils. Ces IGP e e changent bien entendu des routes avec les EGP, le routage ne serait pas e 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 extrieur, le monde intrieur ! e e Ce chapitre de cours examine deux IGP tr`s classiques, RIP et OSPF ! e Si ces deux protocoles se rencontrent tr`s frquemment sur les rseaux, ils e e e di`rent beaucoup dans leurs proprits comme nous allons le voir. . . e ee

1.2

Vecteur de distances vs Etat de liens

RIP Routing Information Protocol et OSPF Open Shortest Path First sont construits sur des approches direntes. e Les algorithmes de routage ` vecteur de distances (bass sur lalgoa e rithme de Bellman-Ford) conduisent les routeurs ` transmettre ` leurs voisins a a rseaux immdiats une copie de leur table de routage. Ces tables se modie e ent au fur et ` mesure de leur propagation, car chaque route est associe ` a e a une mtrique qui cro par dfaut dune unit au passage de chaque routeur e t e e (le routeur voisin accessible sur le mme LAN est associ ` une mtrique de e ea e 1, etc. . .). Le choix de la meilleure route est tabli par chaque routeur en e considrant la valeur minimale de cette mtrique pour toutes les routes qui e e aboutissent ` la mme destination. Seule la meilleure route est propage, les a e e autres sont oublies. e Pour ces considrations on dit que le calcul de la route est distribu et par e e consquence chaque routeur na pas la connaissance de la topologie globale e du rseau : il nen connait quune version interprte par ses voisins. e ee Les algorithmes ` tats de liens btissent les tables de routages a e a diremment. Chaque routeur est responsable de la reconnaissance de tous e ses voisins, plus ou moins lointains, ` qui il envoie une liste compl`te des a e noms et des cots (en terme de bande passante, par dfaut) contenu dans u e une base de donnes ` sa charge et qui reprsente lintgralit de tous les e a e e e 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 ` partir de cette reprsentation quil a e calcule ses routes ` laide dun algorithme connu de recherche du plus court a 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 , dni dans la RFC 1058 (historique) de e 1988. Il est amusant de constater que lcriture de cette RFC vient de e lanalyse fonctionelle du dmon routed prsent sur les machines BSD de e lpoque4 . e Le principe de fonctionnement de RIP est bas sur le calcul distribu e e du chemin le plus court dans un graphe, selon lalgorithme Bellman-Ford5 dcrit ` la n des annes 1950. e a e Le terme chemin le plus court dsigne implicitement lusage dune e mtrique pour comparer les longueurs. Ici, la mtrique est basiquement le e e nombre de sauts (hops) entre deux routeurs. Pour tout routeur, les rseaux e directement rattachs sont accessibles avec un nombre de saut gal ` 1 (par e e a dfaut). La mtrique pour satteindre soit-mme tant toujours 0 par hye e e e poth`se. e Les routes qui sont propages dun routeur ` un autre voient leur mtrique e a e augmenter de 1 (ou plus) ` chaque franchissement dun routeur. En pratique a on ne dpasse gu`re une profondeur de quelques units, sinon le protocole dee e e vient inecace comme on le verra au paragraphe suivant. Plus prcisement, e une route assortie de la mtrique 16 est considre comme innie, donc e ee dsigne une destination (devenue) inaccessible. e Cette limitation du protocole laisse quand mme aux architectes dine frastructures rseaux la possibilit de concevoir des rseaux spars les uns e e e e e des autres par un maximum de 15 routeurs. . .Au del` de cette limite il faut a forcment envisager lusage dun autre protocole ! e
R N R1 R2

N mtrique == 2

N mtrique == 1

gure VII.02 La route vers H depuis R a une mtrique de 2 et passe par R1 e Sur la gure VII.02 Le routeur R peut atteindre lhte H avec une route o dont la mtrique est 2 et qui passe par le routeur R1. e Il faut bien noter quavec RIP, chaque routeur nest en relation quavec ses voisins directs, cest ` dire ceux avec lesquels il partage un LAN6 . Typia quement 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`s visuelle et soigne du fonctionnement de lalgorithme e e 6 Cf page 7
4 3

114

Routage dynamique dIP tre virtuelles), donc voit deux LANs. Ici R1 a un rle central et incontoure o nable car ni R ni R2 ne schangent directement des routes. e Pour cette raison, les routes sont globalement issues dun calcul distribu. Pour chaque routeur ltablissement de sa table de routage seectue e e ` partir des informations fournies par les routeurs de son voisinage, cest ` a 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 rsultat des calculs de routes eectus par ses voisins, calculs quil e e confrontera ` sa propre table de routage et ` son propre calcul de route (le a a choix dune route plus courte ` laide de la mtrique annonce), puis diusera a e e ` son tour. Par ce principe, dans la gure VII.02, R1 a connaissance du rseau a e N indirectement grce aux annonces de routes diuses par R2. a e Le terme vecteurs de distances est employ parceque la propagation e des routes seectue sous la forme de vecteurs : Pour atteindre telle destination, il faut passer par ce routeur et la mtrique associe e e vaut cette valeur . Donc une direction et une mtrique, do` lanalogie e u 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 dmarrage, chaque routeur a connaissance des rseaux auxquels il e e est directement rattach, ainsi que du cot associ ` chacune de ses e u e a liaisons (1 par dfaut). e Le cot de la liaison locale, cest ` dire celle du routeur vers lui-mme, u a e est 0 alors que celle pour atteindre nimporte quel autre point est inni (valeur 16 par dfaut). e Le routeur envoie un paquet de questionnement (request packet) ` ses a voisins pour constituer sa table de routage initiale. La RFC 2453 prcise que celle-ci contient 5 informations pour chaque e entre : e (a) (b) (c) (d) Ladresse IPv4 de la destination, La mtrique pour atteindre cette destination, e Ladresse IPv4 de premi`re passerelle (next router) ` utiliser, e a Un drapeau qui indique si la route a chang rcemment (route e e change ag) (e) Deux chronom`tres associs ` la route, lun pour signier que la e e a 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 routes en dehors du LAN e

Routage avec RIP durant lequel une route non utilisable doit tre maintenue dans la e table avant dtre supprime et lespace mmoire utilis recycl e e e e 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 vnement a lieu priodiquement (30 secondes) o` d`s que quelque e e e u e chose change dans la table de routage (Triggered updates page 117), ou encore ` rception dun paquet de demande de route, par exemple par a e un hte dun rseau directement raccord (voir page 73) ; o e e 3. Chaque routeur calcule son propre vecteur de distance, le cot miniu mum est le crit`re de slection. Ce calcul intervient d`s que : e e e Le routeur reoit un vecteur de distance qui di`re avec ce quil a dj` c e ea en mmoire, e Le constat de la perte de contact (link ou absence de rception des e annonces) avec un voisin. 4. Quand une route na pas t rafra ee chie depuis 180 secondes (6 paquets de broadcast non reus) sa mtrique prend la valeur innie (16) puis c e elle est dtruite (deuxi`me chronom`tre dni prcdemment). e e e e e e Le fonctionnement de RIP a un cot magique et pourtant lalgorithme e converge vers un tat stable, cest dmontr ! e e e Examinons-en le fonctionnement lmentaire sur un rseau thorique de ee e e trois routeurs aligns lors dun dmarrage ` froid : e e a
R1 N1 R2 N2 R3

115

gure VII.03 Fonctionnement lmentaire ee ` A linstant 0 Chaque routeur dcouvre les rseaux qui lui sont directement e e rattachs et se connait lui-mme, cest ` dire quil connait sa ou ses e e a adresses IP. On peut le formaliser par un triplet (Destination, gateway, mtrique), pour R1 a donne (R1,local,0)8 ; e c 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`re asynchrone, met ` jour e a sa table de routage et annonce celle-ci, tout a de mani`re un peu c e asynchrone. On examine les tables de routages une fois ces changes e stabiliss. e
Notons au passage quune route peut tre formule vers un hte ou un rseau, ine e o e direment e
8

116

Routage dynamique dIP R2 reoit les annonces de route en provenance de R1 et R3. Il ajoute c le cot de la liaison et obtient en nal une table qui ressemble ` : u a (R2,local,0) (R1,R1,1) (R2,R2,1), De la mme mani`re R1 enrichit sa table avec deux routes : (R2,R2,1) e e et (R3,R2,2). Pour R3 de mani`re symtrique : (R2,R2,1), (R1,R2,2). e e Que se passe t-il maintenant si R3 devient inaccessible (coupure rseau, e hte arrt. . .) ? o ee Basiquement R2 devrait supprimer la route vers R3. Il nen fait rien pour linstant puisque R1 annonce une route (R3,R2,2). R2 dcide donc quil existe e une route (R3,R1,3) et annonce sa nouvelle table. R1 ayant reu une route modie de R2 modie sa propre route qui c e devient (R3,R2,4) et ainsi de suite dans une boucle infernale qui tend ` a compter jusqu` linni. For heureusement le calcul sarrtera ` 16 par dfaut, a e a e 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 de cette dmarche e e ainsi (et cest surtout ce quon lui reproche) de la perte de temps engendre. e Do` les amliorations apportes : u e e 2.1.1 Horizon partag ou Split horizon e

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 ` R2 des routes passant par R2. Les routes a annonces ne sont donc plus identiques sur chaque rseau mais tiennent e e compte des destinations qui sont atteintes via chacune de ces liaisons pour viter ce type dannonce. e
R1 R3 R2 H

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

Routage avec RIP La gure VII.03 reprsente donc un cas thorique facile. En pratique, un e e des intrts du routage dynamique tant davoir plusieurs routes possibles ee e pour atteindre une destination, on aura plutt la situation de la gure VII.04 o ce qui am`ne au cas de gure suivant : e Supposons que lhte H devienne inaccessible, la technique ci-dessus o empchera R3 de tenter de router les datagrammes vers R1 et R2, mais, e du fait du caract`re asynchrone des mises ` jours, R1 ayant reu de R3 le e a c fait que H est inaccessible peut conclure que R2 est le meilleur chemin avec un cot de 3 et cette fausse information peut se propager ` R3 via R2 et le u a comptage ` linni est reparti. . . a Pour y remdier le protocole comporte un dispositif de mises ` jours e a dclenches : e e 2.1.2 Mises ` jour dclenches ou Triggered updates a e e

117

Lventualit dune situation de comptage ` linni voque dans le e e a e e contexte de la gure VII.04 peut tre endigue par ce dispositif. e e Seules des mises ` jours tr`s rapides peuvent conduirent R1 et R2 ` a e a converger vers la conclusion que la distance vers H est devenue innie. La r`gle initiale est que quand un routeur change la mtrique dune route, e e il doit envoyer un message de mise ` jour aussi vite que possible ` tous a a ses voisins immdiats. Ce message ne contient que ce qui a chang et non e e lintgralit de la table. e e Mises ` jour rapides ne signient pas pour autant temptes de paa e quets sur le rseau , dune part parceque le principe de lhorizon partag est e e conserv, et que dautre part, une temporisation alatoire (de 1 ` 5 secondes) e e a limite la frquence dmission de chaque mise ` jour. Durant ce laps de temps e e a la rception dune mise ` jour peut tre galement prise en compte et donc e a e e entrainer un changement des routes tablies. e La dirence entre ce dipositif et les annonces rguli`res tient ` sa e e e a frquence dmission et au contenu restreint aux seules routes dont la e e mtrique a chang. e e La RFC 2453 conclue toutefois However, counting to innity is still possible . Qui nest vraiment pas tr`s satisfaisant. . . e

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 dans paquet UDP avec 520 comme port de destination : e

gure VII.05 RIP est transport par UDP/IP e Etant donn le mode de propagation des annonces de routes, le choix du e protocole UDP est tout ` fait appropri. Cependant, la RFC 2453 spcie a e e que le nombre maximum de routes est limit ` 25, comme il faut 20 octets ea (gure VII.06) pour dcrire une route, la partie utile du datagramme fait e 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 ` point modernes (PPP par exemple). a Par contre, sil faut propager plus de 25 routes, il faut envisager lmission e dautant de datagramme que ncessaire ! e ` A lintrieur du message RIP de la gure VII.03 les octets sorganisent e de la mani`re suivante : e
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 marqus dune sur la gure). Lalignement e des champs sur des mots de 32 bits en est ` lorigine. a

Routage avec RIP Commande 1 pour signier une demande, request, et 2 pour une rponse, e reply. Dautres commandes existent mais elles sont obsol`tes ou non e documentes dans la RFC. . . e Version 1 pour RIPv1 et 2 pour RIPv2. Domaine (RIPv2) Pour pouvoir faire tourner simultanment sur une mme e e 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 galement contenir la valeur hexadcimale 0xffff e e 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 ` gauche et complt par des zros ! ea ee e Rien nest dni dans la RFC 2453 pour tre plus condentiel. . . e e 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 propage par RIP. e Adresse IPv4 Il sagit de la destination ` atteindre par le routeur qui met a e cette annonce. Masque de sous-rseau (RIPv2) Le masque de sous-rseau ` appliquer e e a au champ qui prc`de. Cest un des apports principaux de RIPv2 par e e rapport ` RIPv1. a 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, dirente e de celle de lannonceur. Celui-ci nutilise pas RIP (sinon il ferait lannonce lui-mme), mais sans doute un autre protocole de routage. e Ce cas de gure arrive ` la fronti`re entre deux rseaux, quand par a e e exemple un routeur interne annonce une meilleure route via un routeur du mme lan. e Mtrique Il sagit de lannonce de la mtrique, de 0 (hte local) ` 16 (inni e e o a non accessible) en pratique. En rsum, les apports de RIPv2 sont les suivants : e e 1. Transmission dun masque de sous-rseau avec chaque route. Ce point e est majeur parcequil permet dutiliser RIP avec des rseaux compore tant des sous-rseaux ; e 2. Authentication (tr`s insusante puisque le mot de passe circule en e clair). Le constructeur Cisco a ajout des extension permettant lusage e 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 (plutt quun limited broadcast IP, plus perturbateur parceque lu par o tous les htes. o

2.3

Algorithme Bellman-Ford

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

2.3.1

Mtrique e

Dans les rseaux simples, le plus courant est dutiliser le nombre de sauts, e hop, cest ` dire le nombre de routeurs ` franchir pour arriver ` destination. a a a Les rseaux plus complexe, on privilgira une mtrique base sur le dlais, e e e e e par exemple.

2.4

Conclusion

Lapparition des protocoles ` tats de liens na pas empch son a e e e dveloppement, la RFC 2453 de 1998, dcrit RIPv2 encore en usage dans e e bon nombre de (petits) rseaux. e 2.4.1 Points forts

Simplicit de mise en uvre ; e Simplicit du protocole permettant une comprhension aise des e e e change ; e Robustesse des implmentations. e 2.4.2 Points faibles

Limitation ` une profondeur de 15 ; a Probl`me de la vitesse de convergence (lente) de lalgorithme, et du e comptage ventuel jusqu` la route innie ; e a La mtrique nest pas adapte ` des rseaux dont les nuds sont spars e e a e e e par des liaisons utilisant des bandes passantes disparates ; Lauthentication de lmetteur des donnes est tr`s pauvre en fonce e e tionnalit et pas du tout secure ; e La topologie des rseaux RIP reste ` un seul niveau (pas de hirarchie e a e par exemple entre lar`te centrale dun rseau (backbone) et des rseaux e e e terminaux.

3 Routage avec OSPF

121

Routage avec OSPF

Lorigine du protocole OSPF, et de la technologie de routage par tats e des liaisons , datent du tout dbut des annes 1980, pour faire face aux e e insusances du protocole ` vecteurs de distances, constates sur les rseaux a e e Arpanet et Cyclades. Son dveloppement est d aux eorts du groupe OSPF e u de lIETF.

3.1

Grandes lignes de fonctionnement

Les explications qui suivent font lhypoth`se dun rseau IP qui supporte e e la propagation de trames avec une adresse de destination de type multicast9 , autrement dit ne traite pas le cas des rseaux sans diusion ce type ou encore e NBMA (Non Broadcast Multi-Access networks). Basiquement un protocole ` tats de liens a un fonctionnement simple : ae 1. Chaque routeur est responsable de la reconnaissance de ses voisins (et donc de leur nom) directs, cest ` dire accessibles sur un des LANs a directement raccords ; e 2. Chaque routeur tablit un paquet nomm link state packet (LSP) qui e e contient la liste des noms et des cots (paragraphe 3.3.1) dans la u mtrique choisie pour atteindre chacun de ses voisins ; e 3. Le LSP est propag ` tous les routeurs et chacun conserve le plus e a rcent LSP reu des autres routeurs dans une base de donnes (linke c e state database). Chaque routeur du nuage travaille ainsi ` partir des a mmes donnes, une sorte de carte globale des tats ; e e e 4. Chaque routeur a la responsabilit par ses propres moyens (puissance e CPU) du calcul du chemin ` cot minimum (shortest path) ` partir de a u a lui-mme et pour atteindre tous les nuds du rseau ; e e 5. Les changements de topologie du nuage (comme la perte de connectivit e sur un interface) de routeurs sont rapidement dtects, annoncs au e e e voisinage, et pris en compte pour recalculer les routes. En rsum un tel protocole a deux grandes activits, la premi`re est de e e e e propager ses tats et dcouter ceux de ces voisins au sein de lAS, cest ce e e quon appelle le ooding, en franais procd par inondation, la deuxi`me c e e e est de calculer des routes ` partir de tous les tats de liens reus. Ce calcul a e c est eectu ` laide de lalgorithme de Dijkstra de recherche du plus court ea chemin dans un graphe. Pour les rseaux complexes, OSPF permet le groupement de routeurs en e zones distinctes, areas, qui tablissent des nuages autonomes qui routent les e datagrammes entres eux, mais ne laissent pas ltrer leur trac interne de LSP. Se dgage ainsi une hirarchie de routeurs, ceux qui sont au milieu de e e
9

Page 42

122

Routage dynamique dIP la zone, ceux qui en sont ` la fronti`re et assurent les changes avec les autres a e e zones, enn ceux qui assurent les changent avec les EGP (comme BGP) pour e le trac externe ` lAS. a Tous les changes sont authentis. Par ce biais, seulement les routeurs e e prvus dans la conguration participent au routage. La technique dauthene tication peut direr dune zone ` une autre (cf paragraphe 3.7.2) e a Enn, les changes de donnes sont structures autour dun protocole e e e nomm HELLO. Ce protocole applicatif est vhicul par deux adresses e e e multicast (page 42) qui lui sont attribues : principalement 224.0.0.5 et e 224.0.0.6 dans certains cas, voir le paragraphe 3.6). Le protocole est encapsul directement dans les datagrammes IP, et le champ PROTO contient la e valeur 89 (chier /etc/protocols).

3.2

RIP vs OSPF

Le choix de lun ou de lautre est assujeti ` lexamen de ce qui les a direncie, que lon rsume dans les X points suivants : e e 1. RIP est limit ` 15 sauts (hop), qui limite de facto la structure du nuage ea de routeurs ; 2. Il faut utiliser RIPv2 car RIPv1 ne supporte la notion de masque de sous-rseau (Variable Length Subnet Mask ou VLSM) ; e 3. Plus le nuage est important et les liaisons moins performantes (comme sur un WAN) plus la diusion priodique des tables de routages e consomme des ressources (bande passante) ; 4. RIP converge beaucoup plus lentement quOSPF. La consquence e dun changement de la topologie peut mettre plusieurs minutes ` tre ae compl`tement intgre, mme avec lusage des adresses multicast, des e e e e mises ` jours dclenches et du concept dhorizon partag ; a e e e 5. Le principe fondateur, nombre de sauts, ne tient pas compte des dlais e de propagation, le plus court chemin en terme de nombre de sauts ne dsigne pas ncessairement le chemin qui ore le meilleur dbit, sauf si e e e toutes les liens qui le composent sont de la mme technologie (Ethernet e 100BT par exemple) ; 6. Labsence de la possibilit dune structuration des routeurs RIP en e zones ne permet pas une structuration intelligente des grands rseaux, e surtout quand ils sont organiss avec des classes dadresses que lon e puisse agrger entres elles en supernet (page 40) ; e 7. RIP na aucun mcanisme able dauthentication des annonces, ainsi e nimporte quel hte du rseau peut empoisonner lensemble avec des o e routes farfelues (ou malveillantes, ou les deux. . .) ; 8. Le calcul des routes est distribu pour RIP, chaque routeur nayant e quune vue partielle du nuage, alors que pour OSPF chaque routeur de

RIP vs OSPF la zone a une vue compl`te de ltat de tous les liens et tablit lui-mme e e e e le calcul des routes en se plaant ` la racine du graphe de destination. c a En synth`se OSPF est plus performants sur les points suivants : e 1. Pas de limitation en nombre de sauts, cette donne nentre pas en ligne e de compte puisque ce sont des tats de liens qui sont propags ; e e 2. Les tats de liens sont envoys avec une adresse de destination multie e cast, et seules des mises ` jour des tats qui changent sont envoyes. a e e La bande passante est prserve au maximum ; e e 3. OSPF converge tr`s vite, du fait de son mcanisme de propagation e e rapide (ooding) des tats ; e 4. Le calcul du plus court chemin peut conduire ` des routes de mme a e valeur et OSPF est capable de grer alors ecacement lquilibre de la e e charge (load balancing) entre tous ces cheminements possibles ; 5. Lorganisation des grands rseaux en zones est compl`tement possibles, e e ce qui dune part rduit le trac des tats de liens et dautre part permet e e des regroupement plus logiques bass sur les classes dadresses IP ; e 6. Les informations changes entres routeurs peuvent tre authenties e e e e selon plusieures mthodes, voir paragraphe 3.7.2 ; e 7. Les routes peuvent tre tiquettes, ainsi les routes en provenance des e e e EGP seront traces et traites spciquement. e e e

123

124

Routage dynamique dIP

3.3

Principe de propagation des tats e

Ltablissement des tables de routages dpend de la compltude dune e e e table appele link-state database, base de donnes dtats de liens, prsente e e e e ` lidentique sur chaque routeur de la zone. Cette table est alimente par les a e tats de liens, Link State Packet (LSP), que senvoient les routeurs entres e eux. Or cette distribution dpend du routage. . . e Contrairement ` ce que lon pourrait en dduire, il ny a pas de probl`me a e e de prcdence entre ces deux oprations, car la stratgie de distribution ree e e e pose sur lusage dune adresse de multicast, valable uniquement dans un LAN (page 42) donc qui ne dpend pas de ltat de la table de routage ! e e Chaque changement dtat sur un lien doit tre signal au plus vite ` tous e e e a les voisins except celui qui a signal le changement. Cest un procd par e e e e inondation, ou ooding dans la littrature. e Intuitivement ce mod`le de propagation semble rapide mais gn`re poe e e tentiellement un nombre exponentiel de copies de chaque paquet. . . Pour viter une tempte prvisible de LSP, lide initiale des concepteurs e e e e consiste ` ajouter ` chaque LSP un numro de squence : a a e e Chaque routeur conserve un trace du dernier numro de squence utie e lis. Quand il gn`re un nouveau LSP il incrmente cette valeur ; e e e e Quand un routeur reoit un LSP depuis un voisin, il compare son c numro de squence avec celui ventuellement dj` prsent dans sa e e e ea e base de donnes. e Si le numro est plus ancien, il oublie le paquet, e Si le numro est plus rcent il remplace ventuellement celui dj` e e e ea prsent en mmoire. e e Ce dispositif tend ` modrer la tempte de mises ` jour mais induit a e e a dautres interrogations : 1. Que faire quand on arrive ` la valeur maximale du compteur (mme a e avec des registre 64bits a arrive un jour) ? Plus gnralement comment c e e dterminer la relation dordre entre deux LSP de valeur a et b ? e 2. Que se passe t-il quand un routeur redmarre ? e Il annonce des LSP avec un numro de squence plus petit que ceux e e dj` en circulation et qui donc seront ignors, mme si plus pertinents. ea e e Cette constatation est voisine de la situation de deux parties dun mme e rseau, spares ` la suite dune rupture de connectivite et qui se e e e a e retrouvent mais apr`s que lun des compteurs soit repass par 0 ? e e

Principe de propagation des tats e Qui am`nent les rponses suivantes : e e 1. Le numro de squence est un compteur, avec une valeur minimale e e et maximale nie. Quand la valeur maximale est atteinte, il repasse par zro, exactement comme un counter de SMI (page 228, chapitre e concernant SNMP). Ensuite, pour tablir une relation dordre entre les LSP, la r`gle suivante e e est adopte : e
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 dclarer que le LSP b est plus rcent que a si les conditions : e e |a b| < a<b
n 2

ou encore

|a b| > a>b

n 2

sont runies. Cest ce que schmatise graphiquement la gure VII.07 e e ci-dessus ; 2. Pour rpondre ` la deuxi`me interrogation, on introduit une nouvelle e a e donne : lge du LSP. e a Cest une valeur numrique (code sur 16 bits selon la RFC 2328) poe e sitionne non nulle par le routeur qui met le LSP. e e Chaque routeur qui reoit un LSP doit dcrmenter lge dau moins c e e a 1 unit et continuera ainsi dans le temps jusqu` la valeur 0, e a ` a e A lge 0 le LSP ne doit plus tre transmis mais peut participer encore au calcul des routes, Nimporte quel LSP (en terme de numro de squence) qui arrive e e avec un ge non nul peut remplacer un LSP dge nul. a a En rsum : e e Quand un routeur R gn`re un LSP, son numro de squence doit e e e e tre plus grand de 1 (modulo n, cette derni`re valeur tant la valeur e e e 32 maximale du compteur lui mme, par exemple 2 1) que la prcdente e e e squence gnre. Lge doit tre positionn ` une valeur maximale. e e ee a e ea

126

Routage dynamique dIP Quand un routeur autre que R reoit le LSP, il laccepte en remplacec ment de tout LSP avec un plus petit numro de squence (donc plus e e ancien). Si lge du LSP stock tait 0, le nouvel LSP le remplace de mani`re a ee e inconditionnelle : on ne peut propager un LSP dge nul. a Le vritable algorithme est plus complexe, voir la RFC 2328 page 143, e 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 dtat initi par le nud C. En trois tapes tous les routeurs sont e e e ` ltape 2 on peut remarquer que les routeurs B,F et G mis au courant. A e sinterdisent de renvoyer le LSP ` C, son metteur. On remarque galement a e e que F et G senvoient le mme paquet, mais celui issu de F a un ge plus e a ancien, il sera donc oubli immdiatement, comme celui issu de G, pour la e e mme raison. e Le Nud E reoit le mme LSP depuis B et F, le premier arriv sera c e e pris en compte, le deuxi`me oubli. Mme remarque pour D ` la n de la e e e a troisi`me tape. e e

Valeur des tats de liens e La dure totale de ces trois tapes est pratiquement celle ncessaire pour e e e propager les datagrammes (donc fortement dpendante de la bande pase sante), de quelques milli-secondes ` quelques centaines de milli-secondes, a donc ! 3.3.1 Valeur des tats de liens e

127

Le cot des liens, nomm galement la mtrique, agit directement sur le u ee e choix dune route plutt quune autre comme on le voit dans le paragraphe o qui suit. Le constructeur Cisco prconise10 une formule qui est reprise partout : e 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 cot de 108 /107 = 10. u Le petit tableau ci-dessous indique quelques valeurs pour des dbit connus : e Mdia e Liaison srie 56kbps e T1 (srie 1544 kbps) e E1 (srie 2048 kbps) e Token ring 4Mbps Ethernet 10Mbps Token ring 16Mbps Ethernet 100Mbps ... Cot u 1785 64 48 25 10 6 1 ...

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

3.4

Calcul du plus court chemin

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

3.5

Hirarchie de routeurs e

Les rseaux ` administrer peuvent tre vastes et complexes, dans ces e a e 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 zone ou e (area) et qui se traduit par une hirarchisation du routage. e Outre la structuration plus claire du rseau global en sous rseaux, lavane e tage de cette approche est galement de diminuer le nombre de routes sur e lequel porte le calcul de plus court chemin, et aussi de diminuer le trac des mises ` jour, non ngligeable sur un rseau vaste et complexe. a e e La RFC prcise quune zone doit faire le lien avec toutes les autres, il e sagit forcment de la zone 0, qui joue donc le rle de larte centrale (OSPF e o e Backbone). De cette structuration dcoule le fait que tous les routeurs nont pas e le mme rle, certain sont au milieu dune zone et dautres ` la fronti`re e o a e entre deux zones, voire mme ` la fronti`re entre le nuage OSPF et dautres e a e mcanismes de routage, vers dautres AS : e
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 Hirarchie de routeurs e La RFC prcise quatre types de routeurs dans ce cas de gure : e Internal routers (IR) Cest le cas le plus simple dun routeur au milieu dun nuage ` lintrieur dune zone. Il na quune seule base dtats de a e e liens quil met ` jour avec les autres routeurs de son voisinage ; a Area border routers (ABR) Ces routeurs se trouvent attachs ` au moins e a deux zones. Ils poss`dent autant de bases de donnes dtats de liens e e e quils ont dinterfaces connects ` des zones direntes. Ces bases e a e di`rent car elles concernent des nuages dirents. Elles doivent tre e e e propages vers la zone 0 sous forme dune route rsume (summarized) e e e

Fonctionnement ` lintrieur dune zone a e qui utilise au mieux les possibilit du CIDR. Bien entendu cela suppose e que les rseaux puissent tre aggrgs entres eux ; e e e e Backbone routers (BR) Il sagit de routeurs qui sont raccords au moins e ` la zone 0. LA RFC nest pas claire sur leur signication exacte. . . a Autonomous system boundary routeurs (ASBR) Cest le (les) routeur(s) qui marque(nt) la fronti`re dinuence de lIGP. Il peut tre en e e relation avec nimporte quel autre protocole de routage, par exemple RIP et BGP sur la gure VII.09 avec lesquelles il tablit des passerelles e et change des routes. Les usagers de lIGP ont besoin dchanges avec e e lextrieur (autres rseaux, autres AS). e e

129

3.6

Fonctionnement ` lintrieur dune zone a e

Le fonctionnement du mcanisme dinondation ` lintrieur dune zone, e a e tel que nous lavons succintement dcrit au paragraphe 3.3, induit que lors e de la diusion dun LSP chaque routeur propage le changement dtat reu e c 2 ` son voisinage rseau. Ce comportement induit un trac en N , si N est le a e nombre de routeurs sur le LAN en question. OSPF essaie de rduire ce nombre ` seulement N en faisant jouer un rle e a o particulier ` lun des routeurs, le routeur dsign, ou Designated Router (DR). a e e Celui-ci reoit les mises ` jours car il coute sur une autre adresse multicast, c a e 224.0.0.6 (tous les routeurs OSPF dsigns) et si besoin est propage ` nouveau e e a cette information vers les autres routeurs du LAN, avec ce coup-ci ladresse 224.0.0.5 (tous les routeurs OSPF). Se pose immdiatement la question de la panne ventuelle du routeur e e ` DR, celle-ci bloquerait la mise ` jour des bases dtats de liens. A cet eet un a e routeur dsign de sauvegarde est galement lu, cest le Backup Designated e e e e Router, mis ` jour en mme temps que le DR mais qui reste muet sur le a e rseau tant que le protocole HELLO na pas dtect un dysfonctionnement e e e du DR.
R DR BDR

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

130

Routage dynamique dIP pour lesquels il na rien reu. Le nombre de paquets est alors en thorie celui c e N 1 11 du nombre de paires possibles , soit encore : N 2 , 10 pour cet exemple. Pour le schma de droite, le routeur DR a reu un LSP et le diuse aux e c trois routeurs concerns. Notons que le BDR ne fait rien, il a galement reu e e c la mise ` jour mais sabstient de toute action tant que le DR est oprationnel. a e Avant de pouvoir tablir une hirarchie entres eux et dchanger ecacee e e ment des tats de liens, les routeurs doivent dterminer qui sont leurs voisins, e e autrement dit la topologie du rseau qui les entoure. e 3.6.1 Voisinage et adjacence

La RFC 2328 dnit une progression selon 8 tats (7 pour les rseaux avec e e e propagation par multicast) pour chaque routeur OSPF, avant de pouvoir changer ecacement avec ses voisins. Il est utile den avoir connaissance e pour diagnostiquer une situation. Ltablissement (ou non) de ces tats repose sur la structuration du proe e tocole HELLO, qui se dcline en cinq types de paquets dirents, nous les e e examinons au paragraphe 3.7 Down Cest ltat initial, pralable ` tout tablissement dune conversation e e a e avec le voisinage. Il indique quaucune activit de voisinage na t e ee dtecte depuis un moment ; e e Init Les routeurs envoient des paquets de type Hello ` frquence rguli`re a e e e (environ 10 secondes). La rception dun tel paquet sut pour passer e ` cet tat. a e 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 tat sil se voit dans le paquet Hello e propag par un voisin. La communication est alors bi-directionnelle. e Cet tat est la relation de voisinage la plus basique. e Pour pouvoir changer des tats de liens et construire des routes, chaque e e routeur doit former une contigu e (adjacency) avec chacun de ses voit sins. Cest une relation avance entre routeurs OSPF. Elle stablit en e e commenant par ltat suivant ; c e ExStart Cest le premier pas pour constituer une contigu e de routeurs t entre deux voisins. Le but de cette tape est de dcider qui sera le ma e e tre et lesclave dans la relation. Des paquets de type DataBase Description e e paquet (cf page 131) sont changes, et le routeur ayant la plus forte valeur de RID (Router ID) gagne. Cette derni`re valeur est fonction de e ladresse IP la plus leve pour tous les interfaces du routeur, et dun e e coecient congur manuellement (non dmocratique) ; e e
Cest le nombre de paires du triangle de Pascal http://fr.wikipedia.org/wiki/ Triangle_de_Pascal
11

Protocole HELLO Exchange Les routeurs schangent lintgralit de leur base dtats de liens e e e e ` laide de paquets DBD ; a ` Loading A ce stade les routeurs terminent de complter leur table de liens. e Les tats qui ont besoin dtre rafra e e chis font lobjet de requtes ` laide e a de paquets de type Link-state request (LSR) auxquels sont rpondus e des paquets de type Link-state update (LSU) (Voir paragraphe 3.7) qui contiennent les LSP, appels LSA en pratique, cur du fonctionnement e du protocole. Les LSU sont acquitts par des Link-state acknowledgment (LSAck) ; e Full Une fois atteint cet tat, ladjacence dun routeur avec un voisin est e compl`te. Chaque routeur conserve une liste de ses voisins dans une e base de donnes adjacency database. e

131

3.7

Protocole HELLO

Le protocole HELLO est en charge de ltablissement et du maintien des e relations de voisinage entre routeurs. Il sassure galement que les commue nications entre chaque voisin sont bi-directionnelles. Comme nous lavons prcis en introduction ce paquet est encapsul dans un datagramme IP, e e e donc en lieu et place dun protocole de transport (quil ne remplace pas). Des paquets de type HELLO sont envoys ` frquence priodique sur tous e a e e les interfaces des routeurs. Les communications sont repres comme tant ee e bi-directionnelles si un routeur se reconnait dans la liste (des voisins connus) mise dans le paquet HELLO dun voisin. Le protocole sert galement ` e e a llection du Routeur Dsign (DR). e e e Sur les rseaux permettant le multicast, chaque routeur sannonce luie mme en envoyant priodiquement des paquets HELLO. Ce dispositif permet e e aux routeurs voisins de se conna dynamiquement, de vrier continuelletre e ment laccessibilit des voisins dj` connus. e ea 3.7.1 Cinq types de paquets

Le protocole HELLO se compose principalement dun en-tte de 6 mots e de 4 octets (24 octets) et dun complment qui dpend du type de paquet. e e Ce type est dni d`s le premier mot de len-tte. e e e Hello (type 1) Ce paquet tablit et maintient les relations de voisinage e (adjacency information) ; DataBase Description paquet (type 2) (DBD) Sert ` dcrire le a e contenu des bases de donnes dtats de liens des routeurs OSPF lors e e de ltablissement dune contigu e de routeurs. De multiples paquets e t de ce type peuvent tre envoys pour dcrire lintgralit de la base de e e e e e donnes ; e Link-state request (type 3) (LSR) Une fois change la descriptions de e e la base dtats, un routeur peut sapercevoir quune partie des liens sont e

132

Routage dynamique dIP prims (date de fra e e cheur). Ce type 3 est alors utilis pour requrir du e e voisin une mise ` jour. De multiples paquets peuvent tre envoys ; a e e Link-state update (type 4) (LSU) Ces paquets sont utiliss par le e procd dinondation prsent au paragraphe 3.3. Chacun deux transe e e e porte une collection de LSP (on les nomme galement LSA) ` destie a nation du voisinage immdiat. Pour rendre la procdure dinondation e e ecace ces paquets doivent tre explicitement acquitts par des paquets e e de type 5 ; Link-state acknowledgment (type 5) (LSAck) Chaque LSA envoy est e acquitt par lmission dun paquet de type 5. Plusieurs acquittements e e peuvent tre combins dans un seul paquet. e e 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-tte du protocole OSPF e

En-tte standard des paquets OSPF e 3.7.2 En-tte standard des paquets OSPF e

133

Tous les paquets OSPF dmarrent par un en-tte standard de 24 octets : e e

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-tte standard de 24 octets e Version La valeur 2 est requise, cest la version du protocole. Type Une valeur comprise entre 1 et 5 qui dtermine la partie variable de e len-tte. e Packet length Longueur du paquet en octets, y compris len-tte. e Routeur ID Cest lidentiant du routeur (RID). Area ID Cest le numro de la zone. La reprsentation dcimale pointe est e e e e utilise, par exemple pour la zone backbone ce champ vaut 0.0.0.0. e Checksum Il porte sur la totalit du paquet moins cette zone et les 8 octets e du champ Authentication. AuType Tous les changes sont authentis. Ce champ en dcrit la e e e mthode. Trois valeurs sont prvues par la RFC : e e AuType Description 0 Pas dauthentication 1 Mot de passe en clair sur le rseau e 2 Crypto ` partir dun secret partag a e Authentication 64 bits qui sont utiliss selon la valeur du champ prcdent. e e e 3.7.3 En-tte des paquets HELLO e

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

134

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

gure VII.13 En-tte du paquet HELLO e Network Mask Le masque de sous rseau associ ` linterface. e ea Options Les options du routeur. Cinq bits sont utiliss seulement pour e dcrire des possibilits annexes au fonctionnement global. e e Hello Interval Le nombre de secondes entre deux paquets de ce type. Rtr Prio La priorit de ce routeur. Cest une valeur positionne manuellee e ment dans la conguration et qui a un impact direct sur le rsultat de e llection des DR et BDR. Une valeur 0 na aucun impact, alors que e 255 assure quasiment le routeur dtre DR. e Router Dead Interval Le nombre de secondes avant de dclarer inatteie gnable un routeur devenu silencieux. Designated Router Cest ladresse IP du DR pour ce LAN. Ce champ est ` 0.0.0.0 sil ny en a pas. a 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 reu rcemment (cest ` dire avec un dlai infrieur ` la valeur c e a e e a du champ Router Dead Interval) un paquet de type 1. La description des 4 autres types de paquets se trouve ` lannexe a 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 rfrences : ee 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 e Elments de rseaux e

1 Htes ou services virtuels o

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) hberge par exemple le service e HTTP dadresse ip ipWWW. Cette opration est rendue possible si le e syst`me dexploitation de B autorise la notion dalias IP. e Si les machines A, C et D excutent galement un serveur HTTP, elles e e peuvent potentiellement prendre le relais de la machine B, d`s lors que e ladresse ipWWW aura t retire de la machine B pour tre recongure ee e e e sur lune dentres elles. Cette opration peut se faire manuellement ou via un outil dadministrae tion. Elle permet de faire transiter tr`s rapidement des services dune machine e ` une autre, sans rupture ou presque de la continuit. Vu des clients il sagit a e toujours de la mme machine, mais elle est virtuelle puisquelle nexiste pas e physiquement. Les syst`mes dexploitations modernes facilitent la construction de mae

138

e Elments de rseaux e chines virtuelles. FreeBSD a un mcanisme tr`s adapt nomm jail1 , e e e e autrement dit une prison. Cest une version tr`s amliore de la primitive e e e unix chroot. Les jails permettent de virtualiser ` la demande les services a puisquils peuvent tre dmarrs ou stopps ` la demande. e e e e a Solaris 10, poss`de un mcanisme qui fonctionne de la mme e e e 2 mani`re. . .Nomm zone . e e Aussi bien les zones de Solaris que les jails de FreeBSD peuvent utiliser des alias IP pour assurer leur autonomie sur le rseau, mais ces deux mcanismes e e manquent ` ce jour dune virtualisation compl`te de la stack IP qui leur a e permettrait davoir une route par dfaut dans chaque instance virtuelle du e syst`me, ce qui les rendrait beaucoup plus indpendants de lhte hbergeur e e o e et autoriserait des congurations beaucoup plus souples. La consolidation des htes A, B,C et D (et potentiellement en nombre bien o plus grand encore) est possible de nos jours sur une seule machine. Lnorme e monte en puissance des processeurs multi-cores et de lvolution des archie e tectures SMP3 dune part, et dautre part la maturit des technologies de e 4 virtualisation des syst`mes dexploitation e Cette opration permet dviter lparpillement des petits serveurs e e e au prot de machines sur lesquelles on peut concentrer un eort de maintenance matrielle plus grand tout en ralisant mme une conomie dchelle e e e e e pour le matriel. Au niveau de la maintenance des syst`mes dexploitation e e leort dadministration reste le mmes, puisque proportionnel au nombre e 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 mme niveau e ou suprieur. Prcdemment, page 30, nous avons dj` analys lencapsulae e e ea e tion des couches de la pile Arpa selon une progression naturelle de fonctionnalits. Ici, si le principe dencapsulation est conserv, la logique initiale de e e construction, elle, est bouscule. Par exemple on peut envisager dencapsuler e IP dans de multiple protocole autres quEthernet, comme PPP5 , IP, dans une couche de transport comme TCP, voire mme dans une couche applicae tive comme HTTP. Ce dernier exemple peut para contre nature et tre pourtant cela fonctionne. . . Construire un tunnel a un cot : dune part celui de la perte desu pace de donnes dans le datagramme (il faut loger un ou plusieurs en-ttes e e supplmentaires et le MTU reste constant lui !) et dautre part celui du traie tement supplmentaire (dcapsulation, analyse) engendr par lajout de ces e e e nouveaux en-ttes. e En rsum, construire un tunnel se traduit par une perte despace pour e e les donnes dans les datagrammes et par une consommation accrue de e cycles cpus pour traiter les en-ttes supplmentaires. Heureusement le gain e e en fonctionnalits pour le rseau est substanciel, comme les exemples qui e e vont suivre tchent de lillustrer ! a Les tunnels qui transitent par une couche de transport sont grs par ee 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 tre mis en uvre par un utilisateur nayant pas e ncessairement les droits de ladministrateur6 , mais par contre, outre une e consommation supplmentaire de cycles cpu et des changements de contexte e e e e ea inhrents ` larchitecture logicielle7 , a linconvnient dtre ddi ` un seul e a
Point to Point Protocol , lui -mme ventuellement encapsul dans de lEthernet e e e (PPPoE RFC 2516) ou de lATM (PPPoA pour lADSL, RFC 2364) 6 Pour encapsuler IP dans IP par exemple, il faut pouvoir crire directement dans IP e ce qui ncessite une socket en mode raw et donc un uid 0 ` lexcution e a e 7 Rappelons que les processus applicatifs standards sexcutent en mode utilisateur, e et que les transferts entre la couche de transport (dans le noyau) et la couche applicative seectuent via un jeu de primitives du syst`me, voir la description des sockets de Berkeley e page 251
5

140

e Elments de rseaux e port (par exemple celui dune application non crypte comme pop au travers e une liaison ssh. Il faut noter que depuis la version 4.3 dOpenSSH les tunnels sont possibles, non limits ` un seul port)8 . e a Encapsuler IP dans IP a lavantage de rester gnraliste du point de vue e e des applications. Sur la gure VIII.02 le tunnel IP encapsule donc de lIP dans lui mme. Pour les routeurs qui acheminent ce trac il sagit de datagrammes e 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 grce ` lusage du a a generic tunnel interface 9 . Il sagit dun pseudo-device (pas dinterface rel associ au device), qui permet dencapsuler de lIP (version 4 ou 6) e e dans de lIP (version 4 ou 6)10 . Le but de cet exemple de tunnel est de montrer un routage de datagrammes issus dun rseau priv, le 192.168.2.0/24 (RFC 1918), depuis la e e machine B (IPB ), vers la machine A (IPA ) et qui traverse un rseau public e rout quelconque, non nomm sur la gure, de telle sorte que A soit intgre e e e e au LAN 192.168.2.0/24. Par hypoth`se la machine A sait comment router vers le e 192.168.2.0/24. Un de ses interfaces rseaux peut tre surcharg avec e e e une adresse dans cette classe C. Le rseau 192.168.249.0/30 sert de rseau dinterconnexion entre les e e deux machines. Concr`tement, il sagit dattribuer une adresse IP ` e a chacun des pseudo-devices, qui ne soit pas dj` dans lun des rseaux ea e attachs ` chacune des machines. e a Conceptuellement, il serait parfaitement possible dutiliser, par exemple, des adresses dans le 192.168.2.0/24, mais lauteur prf`re ee lusage dun rseau dinterconnexion qui permet de bien sparer fonce e tionnellement les adresses IP qui constituent le tunnel en lui-mme de e celles qui sont amenes ` lemprunter. e a 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 pour la conception des r`gles de ltrage de considrer lorigine e e e des datagrammes ayant une adresse source dans le 192.168.2.0/24 uniquement derri`re le ltre. e

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

Tunnel IP avec linterface gif Examinons maintenant quelle pourrait tre la conguration spcique ` e e 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 spcique vers le rseau non directement race e cord. Puis, excution des oprations symtriques sur la machine B : e e e e
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 concrt e Notez que la premi`re ligne de conguration prcise la source et la destie e nation relle des datagrammes alors que la deuxi`me indique ladresse locale e e et distante des extrmits du tunnel. Cest une criture particuli`re, adapte e e e e e au pilote de linterface gif0 pour la conguration des tunnels. Sur la machine B, on peut voir le rsultat de la conguration comme a : e c
$ 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

e Elments de rseaux e Enn, si on examine11 sur les interfaces hme0 puis gif0 de B le passage des datagrammes dun ping, envoys depuis A vers 192.168.2.200, lobsere vation pratique rejoint la thorie : on retrouve bien sur linterface du tunnel e (gif0) len-tte 2, dcapsul de son en-tte 1. Le datagramme est alors dise e e e ponible au niveau de la pile IP de B pour tre rout (routage direct12 ici) e e vers 192.168.2.200. Le tableau qui suit rsume le contenu des en-ttes observes : e e e En-tte 1 e Src IPA Dst IPB Code ipencap(4) En-tte 2 e 192.168.249.1 192.168.2.200 icmp

Sur linterface hme0

Sur linterface gif0

Src Dst Code

En-tte e 192.168.249.1 192.168.2.200 icmp

Remarques : Attention, les routeurs ltrants doivent tre spcialement congurs pour e e e 13 laisser passer ce type de trac . Les core gateway le laissent passer. Il est intressant de noter que le dploiement dIPv6 est dabord bas sur e e e 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 ncessaire de prciser que mme encape e e suls dans IP, nos datagrammes nen sont pas moins lisibles par des e yeux indiscrts ? Pour sen prmunir il nous faut examiner une technologie e e compltementaire. . . Dans le paragraphe suivant ! e

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

11

IPsec et VPN

143

2.2

IPsec et VPN

IPsec est un protocole de scurit inclus dans la couche IP elle-mme. Il e e e est dni dans la RFC 2401. Ce paragraphe aborde bri`vement la question e e du point de vue du protocole et de sa place dans la pile Arpa, tout en laissant volontairement dans un certain ou les aspects lis ` la cryptographie, e a 14 clairement absents des objectifs de ce cours . 2.2.1 IPsec dans quel but ?

IPsec est un point de passage oblig pour tout administrateur de rseau e e qui souhaite mettre en place une politique de scurit. Dailleurs, pour faire e e le lien avec le paragraphe qui prc`de, prcisons quIPsec encapsul dans IP e e e e (formellement, un tunnel) porte un nom, le VPN ( Virtual Private Network ) ! Nous avons examin comment un tunnel accro ltendue dun e t e rseau au travers dautres rseaux. Ajouter Ipsec introduit, entre autres, une e e dimension de scurit tr`s utilise pour relier des machines - ou des rseaux e e e e e - physiquement localiss nimporte o` il y a un acc`s IP, en rseaux virtuels e u e e scuriss ! Cest pour cette raison quIpsec est un artefact incontournable de e e la panoplie scuritaire sur les rseaux. e e 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 indiscrts et e que quasiment nimporte quel bricoleur peut forger de faux datagrammes ( fake datagrams ) pour empoisonner un rseau, voire dtourner les services e e dune machine. Ainsi, tout ce qui renforce la scurit IP est une bonne chose, e e surtout ` lheure des rseaux wi dont les limites de porte ne sont pas a e e ma trisables. IPsec renforce la scurit dIP sur plusieurs points : e e Condentialit Les donnes dIP (protocole de transport et donnes ape e e plicatives) sont cryptes, donc normalement non inspectables avec tout e outil danalyse de rseau accessible sur le rseau lui-mme. e e e Authentication La source du datagramme ne peut tre quun seul e metteur, et non un intermdiaire non prvu. e e e Intgrit La totalit des donnes est protge par une somme de contrle e e e e e e o (checksum), travail normalement dvolu ` la couche de transport mais e a qui au niveau dIP permet dcarter tout datagramme qui aurait t e ee modi pendant son transport. e Dispositif anti-rejeux pour viter les attaques du type man-in-thee middle consistants ` capturer un ou plusieurs datagrammes (crypts) a e dans le but de les envoyer ` nouveau pour bncier du mme eet a e e e produit que lenvoi initial.
Les RFCs donnes page 160 sont le bon point de dpart pour se documenter sur les e e aspects cryptographiques dIPsec
14

144 2.2.2 IPsec en rsum e e

e Elments de rseaux e

Ipsec (RFC 2401) est un assemblage de quatre protocoles : ESP ( Encapsulating Security Payload ) est dni par la RFC 2406. Il e assure la condentialit par lusage dalgorithmes de cryptage comme e 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 bass sur lexistence un secret e partag (manuellement dans un chier ou cre dynamiquement avec e e IKE, voir plus bas) entre les parties qui changent des messages, et e non sur lchange dune clef publique. Cette remarque a un impact sur e la mani`re avec laquelle on doit les congurer ! e AH ( Authentication Header ) est dni par la RFC 2402. Il assure e lauthentication, cest ` dire quil cherche ` certier que les deux a a couches IP qui dialoguent sont bien celles quelles prtendent tre, puis e e lintgrit des donnes par le calcul dun checksum. Il faut noter que e e e ce dernier travail empi`te largement sur les attributions de la couche e de transport mais se justie compte-tenu des exigences inhrentes au e fonctionnement dIPsec. IPcomp ( IP payload compression ) sert ` compresser les donnes avant de a e les crypter. Son action est rendue ncessaire pour tenter de compenser e la perte de la place occupe par les en-ttes ajouts. Bien entendu e e e IPcomp peut tre utilis seul. e e IKE ( Internet Key Exchange ) est dni par la RFC 2409. Ce protocole e nest pas formellement indispensable au bon fonctionnement dIPsec mais lui apporte un mcanisme dchange de clefs, au dmarrage des e e e changes et au cours du temps. Ainsi la clef de chirement nest plus e dnie de mani`re statique dans un chier mais change continuellement e e au cours du temps, ce qui est meilleur du point de vue de la scurit. e e Du point de vue de ladministration syst`me et rseau, la mise en place e e 15 de ce protocole passe par lusage dun daemon , par exemple racoon, et par une ouverture de port UDP (isakmp/500) supplmentaire dans le e ltrage du rseau. Une ngociation dcrite dans la RFC 2409 se droule e e e e entre les htes qui doivent dialoguer, ce qui peut entrainer une certaine o latence au dbut des changes. e e e Les 32 bits de ladresse IP de destination16 permettent thoriquement dexprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de gures sont tous thoriquement possibles, les implmentations dIPsec ne e e supportent que lunicast. La consquence est importante sur le dploiement e e dIPsec, il est eectu point ` point plutt que gnralis pour tout un e a o e e e rseau. e
15 16

Voir page 315 pour le fonctionnement des daemons Rvision possible page 35 e

IPsec et VPN Ce travail est inclus dans ce qui est nomm politique de scurit e e e dans la RFC 2401. Pour AH comme pour ESP, lajout de donnes vient se placer e entre len-tte IP et les donnes. e e Les deux protocoles peuvent tre utie liss ensembles ou sparement, cest e e un choix qui rel`ve de la politique e de scurit. Pour en tenir compte, e e la ngociation qui a lieu lors de e ltablissement dIPsec repose sur ce e que la RFC appelle des SA ( Security Association ). Une SA est formellement un triplet unique constitu dun index e unique , le SPI

145

gure Romanchapter.04 En-ttes dIPsec e

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 numro didentication IP e supplmentaire17 inclus dans len-tte AH ou ESP, de ladresse IP du dese e tinataire et du protocole ESP ou dAH. Si les deux protocoles doivent tre e utiliss, il faut ngocier deux SAs. e e 2.2.3 Comment utiliser IPsec ?

Aux deux protocoles AH et ESP, sajoutent deux mani`res dutiliser IPe sec, soit directement dune machine ` une autre, on parle alors de mode a 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 implmentation se rclamant dIPsec doit e e supporter les 4 associations qui suivent. La scurit entre deux htes qui e e o 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

e Elments de rseaux e Remarque : En mode tunnel pour ce premier cas il ny a pas dobligation du support dAH et ESP simultanment. Quand ils sont appliqus tous les e e 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 scurit e e entre les htes terminaux ` celle dj` o a ea apporte par les routeurs. e 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 ` lintranet a de son entreprise via un modem ou un acc`s IP non sr, et qui utilise un protoe u cole non crypt comme AppleTalk, ou e PoP, par exemple. Le mode tunnel est seul requis entre lhte H1 et la passerelle G1. Ensuite, o entre H1 et H2 on revient au premier cas.

IPsec et VPN 2.2.4 Implmentation dIPsec e

147

Limplmentation dIPsec sur les machines FreeBSD et NetBSd est issue e du projet KAME18 et est ainsi fortement li au dveloppement de la pile e e 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 situe elle aussi dans le noyau, grce ` des e a a socket de type PF KEY Les clefs sont soit places de mani`re semi-dnitive dans le chier de e e e conguration dipsec lui-mme (par exemple /etc/ipsec.conf soit cone e e aux bons soins dun programme externe qui se charge de les cre et de les e propager ` laide du protocole IKE. Quelques daemons savent faire cela, noa tamment racoon du projet KAME. Si nous reconsidrons la gure VIII.03 les machines A et B jouent le rle e o des passerelles G1 et G2 de la gure VIII.06 (association 2). Les chiers de conguration IPsec (AH et ESP) pourraient tre : e 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 dnir sa e politique de scurit, cest ` dire ce que lon souhaite en entre (in), en e e a e sortie (out) puis un choix de protocole (esp, ah, ipcomp), un mode (tunnel ici) avec lentre et la sortie du tunnel, enn un niveau dusage (require ici e indique que tous changes doivent utiliser IPsec). e 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, ` laide de loutil racoon. a 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

e Elments de rseaux e

Proxy

gure VIII.09 Proxy Le propos dun proxy est de concentrer le trac rseau via une seule e machine pour toute une varit de protocoles (telnet, http, smtp, . . .). Il ee existe des proxy spcialiss sur tel ou tel protocole, qui eectuent donc des e e tches potentiellement tr`s complexes (par exemple squid pour http) ou a e tr`s gnraux et donc moins performants sur chaque protocole (cf nat au e e e paragraphe suivant). Tout le trac rseau qui passe par un proxy sy arrte pour en repartir. Les e e conditions de ce rebond peuvent tre param`tres par des r`gles dacc`s, e e e e e ce qui en fait un lment utile en scurit des rseaux (voir la RFC 1919). ee e e e Section en chantier, prcisions en cours. . . e

Translation dadresses

La pnurie dadresses IP est ` lorigine du besoin de translation des e a adresses. Son principe se trouve dcrit dans la RFC 1631. e Un tel dispositif se situe gnralement ` la fronti`re entre un rseau de e e a e e type priv et un autre de type publique. Le cas le plus gnral est lorsque le e e e rseau publique est linternet lui-mme, et le rseau priv celui dune entit e e e e e quelconque abonne aux services dacc`s rseau dun FAI, mais ce nest pas e e e une obligation conceptuelle.
Rseau publique C R S Rseau priv

gure VIII.10 R translate dynamiquement des couples (adresse IP, numro de port) e Sur la gure 10 le rseau priv comporte plus dhtes que dadresses IP e e o fournies dans le rseau publique. Pour pouvoir se dvelopper en saranchise e sant 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 rseau priv est bti avec des adresses non e e a

Translation dadresse routables (cf page 34) de la RFC 1918, potentiellement illimites ` lchelle e a e dune entit prive, mme grande. . . e e e R dispose de quelques adresses (un pool dune adresse au minimum) routables sur le rseau publique, quil peut assigner aux htes du rseau priv e o e e (C) qui initient une connexion vers le rseau publique (S). Cette assignation e peut tre dynamique ou statique. e Un datagramme qui part de C vers S a une adresse source non exploitable sur le rseau publique. R maintient une table, si C nest pas dj` associ ` une e ea ea adresse routable du pool allou ` R, celui-ci lui en attribue une et modie ` la ea a vole ladresse source du datagramme, de telle sorte que le retour de S puisse e tre rout convenablement jusqu` R. Puis R modie ladresse de destination e e a du datagramme pour lui donner ladresse de C, sur le rseau priv. e e Si on fait lhypoth`se que la plupart des htes du rseau priv ntablissent e o e e e pas simultanment des connexions vers le rseau publique, le pool dadresses e e publiques peut rester beaucoup plus petit que le nombre dhtes du rseau o e priv. Mais cette hypoth`se est fragile considrant les besoins toujours plus e e e grands daccder ` linformation rpartie. e a e Ce premier mcanisme se compl`te alors dun second qui est le NAPT. En e e plus de traduire ladresse IP ` la vole, R attribue galement un numro de a e e e port dirent. Ce dispositif autorise lusage simultann dune mme adresse e e e IP publique par des milliers dhtes du rseau priv. o e e Le fonctionnement de la translation dadresse et de port engendre une proprit intressante pour R : il ne laisse passer aucun paquet du rseau ee e e publique vers le rseau priv qui ne soit pas la rponse ` une sollicitation e e e a venue du rseau priv, cest donc en standard un fonctionnement ` sens e e a unique. Cette proprit peut tre remise en question, voir le paragraphe 4.2. ee e Enn, du fait du changement dadresse source ` laller puis dadresse a de destination au retour du datagramme, le NAPT rend impossible lusage dIPSEC (page 143) entre une machine quelconque du rseau publique et line terface de R dans ce rseau et sur laquelle seectue le travail de translation e (il a modication de len-tte, ce contre quoi justement IPSEC est sens nous e e protger. . .). Le seul moyen dans ce cas de gure est de passer par lusage e dun tunnel, comme vu paragraphe 2 (page 139). Tous les routeurs modernes ont les fonctions de translation dadresses et de ports incluses dans leurs fonctionnalits standards. e

149

150

e Elments de rseaux e

4.1

NAPT sur un routeur de type PC avec natd

Natd est loutil logiciel libre bien connu des administrateurs rseaux. Il e 19 fonctionne selon le mod`le de la gure 11 . e
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`se congure en e e routeur. Elle reprsente la route par dfaut pour la machine A. e e Natd convertit les adresses IP ` la vole. Un datagramme voit ses adresses a e sources (et ventuellement de destination, voir plus loin) changer dynamiquee ment. Examinons en dtail les composantes dune connexion tablie depuis e e A vers B, donc lors dun trac sortant vis ` vis de R. a Pour la machine A La machine A sadresse directement ` la machine 193.104.112.163 en a utilisant son routeur par dfaut. e Lutilisateur de la machine A voit la connexion soit la forme : {tcp, IP Hte A, port A, IP Hte B, port B} o o 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 Hte B, port B, IP Hte NAT, port A} o o Pour la machine NAPT La machine NAPT a connaissance des 2 rseaux, elle translate dynae miquement 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 arrte puis en repart sans congue ration particuli`re de la part de ladministrateur de A ou de B. e La translation (ou IP masquerading ) seectue dynamiquement selon ladresse demande. e
Les implmentation commerciales que lon trouve dans les routeurs, si elles ne se e congurent pas de la mme mani`re, ont des proprits tr`s voisines en fonctionnement e e ee e
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 rseau priv , via linterface if int ne fait pas lobjet e e dune translation dadresse. La situation de la machine A est plutt celle dun poste client car o non vu de lextrieur de son rseau. Etre serveur est toutefois possible e e comme il lest expliqu avec lusage de natd au paragraphe ??. e 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 supplmentaires : ils sont traits par un processus qui e e sexcute en mode utilisateur. Sur la gure 12 le processus natd ouvre une e socket en mode raw pour communiquer directement avec la couche IP : divertInOut = socket (PF INET, SOCK RAW, IPPROTO DIVERT) ; Le noyau IP, muni du mcanisme adquat 20 redirige tout le trac ene e trant et sortant dun interface rseau, vers un numro de port convenu ` la e e a conguration, par exemple le port 6668, ` ajouter dans /etc/services : a natd 6668/divert # Network Address Translation socket Natd lit tous les datagrammes et ne retient pour traitements que ceux qui sont ` destination du port ddi. a e 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 numros de ports sont recrits et reinjects dans le noyau IP qui e e e les traite comme dautres datagrammes (routage, ltrage. . .).
Par exemple pour FreeBSD il faut ajoute loption IPDIVERT dans la conguration du noyau
20

152

e Elments de rseaux e

4.2

Translation dadresses vers le rseau priv e e

Les gures qui prc`dent ne concernent que les connexions sortantes du e e rseau priv, mais on peut envisager linverse. Bien entendu vu du rseau e e e publique on ne voit que les adresses du pool attribu au routeur R. Le e mcanisme de translation de port permet ventuellement de ventiler les e e connexions entrantes vers une ou plusieurs machines prives. Le crit`re dise e criminant est le numro de port demand. e e On distingue deux attitudes, soit tout le ux entrant est redirig sur une e seule machine, soit il est est eectu en fonction du port, donc du service e demand. e ` La littrature appelle ce cas le static nat . A linsu des utilisateurs de e la machine NAPT du rseau publique, tout le trac IP (cest ainsi quil e faut comprendre ladresse IP 0.0.0.0) est renvoy sur la machine S, et celle-ci e nest pas visible du rseau public. e
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 tre : e natd -interface if ext -redirect address IP(S) 0.0.0.0 La gure 14 nous montre un exemple de trac clat en fonction du service e e demand, ce qui permet une gestion beaucoup ne des ressources du rseau. e e Une demande de connexion de lhte distant R sur la machine NAT et o au port 80 va tre rachemine vers la machine interne HTTP et sur le port e e e que lon souhaite, par exemple 8080. Mme remarque pour les deux autres services prsents. e e e La machine HTTP voit la connexion en provenance de la machine R sous sa forme exacte : {tcp, IP Hte R, Port R, IP Hte HTTP, 8080} o o La machine R ne voit que la partie publique de la connexion : {tcp, IP Hte R, Port R, IP Hte NAT, 80} o o 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

e Elments de rseaux e

Filtrage IP

Le propos du ltrage IP est dappliquer des r`gles de ltrage ` un ux de e a datagrammes IP an de prendre une dcision qui est le plus souvent binaire : e laisser passer ou ne pas laisser passer avec en option de conserver une trace de passage (des logs). Par son usage on cherche ` protger un site ou une machine dun ux a e de datagrammes pour lesquels on suspecte que tous ne sont pas envoys par e des utilisateurs bienveillants. Le ltre seorce dliminer le trac indsirable e e ` partir de considrations ` priori, mais il ne reprsente pas la panace en a e a e e mati`re de scurit sur les rseaux, autrement dit il ne faut pas penser quun e e e e ltre IP sut ` r`gler tous les probl`mes de scurit dun site ou dun hte. a e e e e o En eet, ` partir du moment o` le ltre laisse passer certains dataa u grammes, mme ` priori innocents, une porte est ouverte au dtournement e a e de lusage initial du service oert. Dans ces conditions il faut se rendre ` a 21 lvidence : il ny a pas de scurit absolue sur le rseau ! e e e e Dans la littrature, un routeur ltrant est nomm FireWall , quil faut e e traduire en pare-feux . Le ltrage IP est une caractristique essentielle de tout routeur digne de e 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 ` toutes les bourses. . . a Si les dtails de mise en uvre di`rent dune implmentation ` une autre, e e e a le fond du probl`me reste le mme. Limplmentation choisie ici est ipfw, le e e e ltre natif de FreeBSD22 . Il existe dautres ltre, notamment ipf, encore une fois le principe reste toujours le mme. e

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 implment dans le noyau, il est activ e e e d`s lors que loptions IPFIREWALL est ajoute dans le noyau. On peut e e galement y adjoindre loption IPFIREWALL VERBOSE pour le rendre bae vard23 , ce quapprcient par dessus tout les administrateurs rseaux, soucieux e e davoir une connaissance prcise de la nature du trac sur leurs rseaux. . . e e Le ltre est un module du noyau, charg au dmarrage, et qui se param`tre e e e ` laide de la commande ipfw. Celle-ci est utilise dans les scripts de dmara e e rage pour dicter au noyau les r`gles de ltrage, lues dans un chier nomm e e
21 22

Les seuls rseaux srs sont isols du monde extrieur dans une cage de Faraday. . . e u e e http://www.freebsd.org 23 Via syslogd

Filtrage IP par defaut /etc/rc.firewall. les scripts de dmarrage pour dicter au noyau e les r`gles de ltrage, e Etablir des r`gles de ltrage IP sous-entend avoir une connaissance exe haustive de tous les lments qui sy rattachent : ee Nom des interfaces rseaux impliques e e Protocoles rseaux employs (tcp, udp, icmp,. . .) e e Protocoles applicatifs autoriss (smtp, domain, http. . .) e Adresses IP, numro de ports, masque de sous-rseaux e e Sens du trac par rapport aux interfaces ci-dessus

155

Il est assez ais de mettre en place un ltrage simple, par contre cette e opration peut devenir complexe d`s lors quon utilise des protocoles applie e catifs compliqus, mettant en jeux une stratgie dutilisation des ports et des e e adresses non triviale. Considrons un site simple, comme celui de la gure VIII.15. La machine e C acc`de depuis lextrieur ` la machine S, protge par le ltrage IP activ e e a e e 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`gles du mod`le de base, extraites du chier e e /etc/rc.firewall de la conguration standard dune machine FreeBSD rcente (cest un script shell). Lexamen de ces r`gles nous permet de e e dcouvrir la nature du trac autoris ou non. e e

156

e Elments de rseaux e

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 considrations : e Les r`gles sont parcourues de la premi`re ` la derni`re, si aucune e e a e convient, laction par dfaut consiste ` bloquer le trac (peut tre e a e change). e D`s quune r`gle convient, elle est applique et le ltrage sarrte. e e e e Le ltrage IP consomme des ressources cpu, donc pour amliorer les e performances il vaut mieux placer en tte de liste les r`gles employes e e e le plus couramment. Il faut remarquer que la machine 193.104.1.228 est visible depuis lextrieure et utilise une adresse ociellement route. e e Une tentative dacc`s sur un service non autoris se traduit par un mese e

6 Exemple complet sage derreur (syslogd). Par exemple supposons que lutilisateur de la station C excute la commande suivante : e 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 rseau 193.104.1.0 va constater la tentae tive dintrusion par le message :
ipfw : 3310 Deny TCP Adr.IP H^te C :2735 193.104.1.228 :23 in via o ed0

Par contre, si lintrusion consiste ` dtourner lusage du service SMTP, a e ladministrateur du rseau 193.104.1.0 ne verra rien par ce biais puisque e lacc`s SMTP est autoris sur la machine 193.104.1.22824 e e

Exemple complet

Dans cette partie nous examinons le cas de la conguration de la gure VIII.16, synth`se des gures e Romanchapter.13, Romanchapter.14 et Romanchapter.15. Cest une conguration tr`s employe du fait de la distrie e bution parcimonieuse dadresses IP par les fournisseurs dacc`s. e
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`gles de ltrage. e
24

Toute ressemblance avec la conguration relle de ce rseau ne peut tre que fortuite e e e

158 Commenons par les r`gles de ltrage : c e

e Elments de rseaux e

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 lhte 193.104.1.228 nest plus visible de lextrieur, o e les services sont en apparence hbergs par la machine R qui se charge de e e re-router les datagrammes en modiant dynamiquement ladresse de destination. Dans lordre des oprations, la translation dadresses est eectue avant e e le ltrage IP. Ce sont donc des adresses IP modies qui sont introduites e dans les r`gles de ltrage ! e 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` lon sapperoit que la conguration na pratiquement pas chang u c e fondamentalement ormis par lintroduction de la r`gle : e 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 dj` subit la translation dadresse avant dtre ea e soumis au ltrage IP. Ainsi une demande de connexion sur le port 25 de la machine 193.104.1.1 sera transforme en une demande de connexion sur le e 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. Moskowitz, D. Karrenberg, G. J.de Groot & E. Lear. February 1996. (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`me partie e Protocoles applicatifs

Chapitre IX Serveur de noms - DNS

1 Gnralits sur le serveur de noms e e e

Sil est obligatoire dattribuer au moins une adresse IP ` une pile ARPA a pour pouvoir linterconnecter en rseau avec dautres piles de mme nature, e e en revanche, lui attribuer un nom symbolique nest absolument pas ncessaire e 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, mme sous forme e dcimale pointe (adresses IP page 33). Il nintervient donc quau niveau e e applicatif, ainsi la majeure partie des applications rseaux font usage de e noms symboliques avec, de mani`re sous-jacente, une rfrence implicite ` e ee a leur(s) correspondant(s) numrique(s). e 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 prciser que le e serveur de noms est en gnral le premier service mis en route sur un rseau, e e e tout simplement parceque beaucoup de services le requi`rent pour accepter e de fonctionner (le courrier lectronique en est un exemple majeur). Cest la e raison pour laquelle lusage dadresses IP sous la forme dcimale pointe reste e e de mise lors de la conguration des lments de commutation et de routage1 . ee

1.1

Bref historique

Au dbut de lhistoire de lInternet, la correspondance entre le nom (les e noms sil y a des synonymes ou alias ) et ladresse (il peut y en avoir plusieurs associes ` un seul nom) dune machine est place dans le chier e a e /etc/hosts, prsent sur toutes les machines unix dotes dune pile Arpa. e e Ci-apr`s le chier en question, prlev (et tronqu partiellement) sur une e e e e 2 a machine FreeBSD ` jour. On y remarque quil ne contient plus que ladresse
1 2

Eviter un blocage d ` linterrogation des serveurs de noms ua 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 dbut des annes 1980 cest le NIC3 qui g`re la mise ` jour continuelle e e e a de cette table (HOSTS.TXT), avec les inconvnients suivants : e Absence de structure claire dans le nommage do` de nombreux conits u entre les noms des stations. Par exemple entre les dieux de la mythologie grecque, les plan`tes du syst`me solaire, les hros historiques ou de e e e bandes dessines. . . e Centralisation des mises ` jour, ce qui entraine : a 1. Une lourdeur du processus de mise ` jour : il faut passer par un a intermdiaire pour attribuer un nom ` ses machines. e a 2. Un trac rseau (ftp) en forte croissance (N 2 si N est le nombre e de machines dans cette table) et qui devient rapidement ingrable e au vu des bandes passantes de lpoque (quelques kilo bits par e seconde), et surtout jamais ` jour compte tenu des changements a continuels. Dapr`s Douglas E. Comer, au milieu des annes 1980 (1986) la liste e e ocielle des htes de lInternet contient 3100 noms et 6500 alias ! o La forte croissance du nombre des machines, a rendu obsol`te e cette approche.

1.2

Syst`me hirarchis de nommage e e e

Lespace de noms, pralablement non structur, est dsormais rorganis e e e e e de mani`re hirarchique, sous forme dun arbre (et non dun graphe). e e Cette organisation entraine une hirarchisation des noms de machines et e des autorits qui ont le pouvoir de les nommer, de les maintenir. e Chaque nud de larbre porte un nom, la racine nen a pas. Les machines, feuilles de larbre, sont nommes ` laide du chemin parcouru de la feuille e a (machine) ` la racine (non nomme). a e
3

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

Syst`me hirarchis de nommage e e e Le sparateur entre chaque embranchement, ou nud, est le point e dcimal. Voici un exemple de nom de machine : e www.sio.ecp.fr Derri`re ce nom il faut imaginer un point (.) qui est omis la plupart du e temps car il est implicite4 . La lecture seectue naturellement de gauche ` a droite, par contre la hirarchie de noms sobserve de droite ` gauche. e a 1.2.1 Domaine & zone

167

Le rseau peut tre considr comme une hirarchie de domaines. Lespace e e ee e des noms y est organis en tenant compte des limites administratives ou e organisationnelles. Chaque nud, appel un domaine, est baptis par une e e cha de caract`res et le nom de ce domaine est la concatnation de toutes ne e e les tiquettes de nuds lues depuis la racine, donc de droite ` gauche. Par e a 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, mme sil est terminal, cest e ` dire na pas de sous domaine. Un sous domaine est un domaine ` part enti`re a a e et, excepte la racine, tout domaine est un sous domaine dun autre. e Bien que le serveur de noms, Domain Name Server fasse rfrence ee explicitement au concept de domaine, pour bien comprendre la conguration dun tel service il faut galement comprendre la notion de zone . e Une zone est un point de dlgation dans larbre DNS, autrement dit une ee zone concerne un sous arbre du DNS dont ladministration lui est propre. Ce sous arbre peut comprendre plusieurs niveaux, cest ` dire plusieurs sous a domaines. Une zone peut tre confondue avec le domaine dans les cas les plus e simples. Dans les exemples ci-dessus, on peut parler de zone sio.ecp.fr puisque celle-ci est gre de mani`re autonome par rapport ` la zone ecp.fr. ee e a Le serveur de noms est concern par les zones . Ses chiers de cone guration5 prcisent la porte de la zone et non du domaine. e e Chaque zone doit avoir un serveur principal ( master ) qui dtient e ses informations dun chier congur manuellement ou semi manuellement e (DNS dynamique). Plusieurs serveurs secondaires ( slave ) recoivent une copie de la zone via le rseau et pour assurer la continuit du service (par la e e redondance des serveurs). Le fait dadministrer une zone est le rsultat dune dlguation de pouvoir e ee de ladministrateur de la zone parente et se concrtise par la responsabilit e 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 Hirarchie des domaines e

Serveur de noms - DNS

Cette organisation du nommage pallie aux inconvnients de la premi`re e e mthode : e Le NIC g`re le plus haut niveau de la hirarchie, appel aussi celui des e e e top levels domains (TLD). Les instances rgionales du NIC g`rent les domaines qui leur sont e e dvolus. Par exemple le NIC France 6 g`re le contenu de la zone .fr. e e Le nommage sur deux lettres des pays est issu de la norme ISO 31667 . Chaque administrateur de domaine (universits, entreprises, associae tions, entits administratives,. . .) est en charge de son domaine et des e sous domaines quil cre. Sa responsabilit est nomminative vis ` vis e e a du NIC. On dit aussi quil a lautorit sur son domaine ( authoritative e 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 dtail ` cette adresse http://www.nw.com/zone/ e a iso-country-code 8 Une base de donnes sur les administrateurs de DNS est entretenue par les NICs, cest e la base whois , interrogeable par lutilitaire du mme nom. Consulter le site http: e //www.ripe.net/ pour plus dinformations, galement man whois sur une machine e unix
7

2 Fonctionnement du DNS gure IX.01 Organisation hirarchique des domaines e Les ventuels conits de nommage sont ` la charge des administrateurs e a de domaine. Du fait de la hirarchisation, des machines de mme nom e e peuvent se trouver dans des domaines dirents sans que cela pose le e moindre probl`me. e Le nom www est de loin le plus employ 9 , pourtant il ny a aucune e 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 donnes sur le nommage de e ses machines. Celle-ci est mise ` disposition de tous les utilisateurs du a rseau. e Chaque site raccord de mani`re permanente proc`de de cette mani`re, e e e e ainsi il ny a pas une base de donnes pour lInternet mais un ensemble e structur de bases de donnes relies entres elles et formant une gigane e e tesque base de donnes distribue. e e

169

2
2.1

Fonctionnement du DNS
Convention de nommage

La RFC 1034 prcise que les noms de machines sont dvelopps un peu e e e comme les noms dun syst`me de chiers hirarchiss (Unix,. . .) et utilisent e e e les caract`res ascii 7 bits assortis des contraintes suivantes : e Le . est le sparateur e Chaque nud ne peut faire que 63 caract`res au maximum ; le bon e usage les limite ` 12 caract`res et commenant par une lettre. a e c Les majuscules et minuscules sont indirencies. e e Les chires [0-9] et le tiret peuvent tre utiliss, le soulign ( ) est un e e e abus dusage. Le point . et le blanc sont proscrits. Les cha nes de caract`res comme NIC ou dautres acronymes bien e connus sont ` viter absolument, mme encadres par dautres caa e e e ract`res. e Les noms complets ne doivent pas faire plus de 255 caract`res de long. e Il y a des noms relatifs et des noms absolus , comme des chemins dans un syst`me de chiers. Lusage du . en n de nom, qui indique un e e ea nommage absolu10 , est rserv ` certains outils comme ping ou traceroute et aux chiers de conguration du serveur de noms. En r`gle gnrale il nest e e e 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 mme rseau logique on a coutume de ne pas utiliser le nom e e complet des machines auxquelles on sadresse couramment et pourtant a c fonctionne ! La raison est que le resolver , partie du syst`me qui est en charge e de rsoudre les probl`mes de conversion entre un nom de machine et son e e adresse IP, utilise un mcanisme de compltion ( domain completion ) e e pour complter le nom de machine simpli, jusqu` trouver un nom plus e e a complet que le serveur de noms saura reconna dans sa base de donnes. tre e Le resolver connait par hypoth`se le ou les noms de domaine (lus dans e le chier de conguration /etc/resolv.conf) qui concernent la machine locale. Une station de travail nen a gnralement quun seul alors quun e e serveur peut en comporter plusieurs, par exemple si on souhaite consolider toute une palette de services pour plusieurs domaines sur une mme machine. e 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 gnralement ce nom de domaine se prsente sous forme d1 .d2 ...dn . e e e Ainsi, en prsence dun nom symbolique x, le resolver teste pour chaque i, e i {1, 2, . . . , n} lexistence de x.di .di+1 ...dn et sarrte si celle-ci est reconnue. e Dans le cas contraire la machine en question nest pas atteignable. Exemple, avec le domaine ci-dessus : a) machine = www (requte) e www.sio.ecp.fr = Succ`s ! e b) machine = www.sio (requte) e www.sio.sio.ecp.fr = Echec ! www.sio.ecp.fr = Succ`s ! e

2.2

Le Resolver

Le resolver dsigne un ensemble de fonctions11 places dans la bie e blioth`que standard (gethostbyname vu en cours de programmation invoque e les fonctions du resolver ) qui font linterface entre les applications et les serveurs de noms. Par construction les fonctions du resolver sont compiles avec lapplication qui les utilise (physiquement dans la libc, donc e accessibles par dfaut). e
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 stratgie locale de recherche, dnie par ladmie e nistrateur de la machine, pour rsoudre les requtes de rsolution de noms. e e e Pour cela il sappuie sur son chier de conguration /etc/resolv.conf et sur la stratgie locale (voir paragraphe suivant) demploi des possibilits (serveur e e 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 prcise au moins le domaine local assorti e de directives optionnelles.

172

Serveur de noms - DNS

2.3

Stratgie de fonctionnement e

La gure IX.03 illustre le fait que chaque serveur de noms a la ma trise de ses donnes mais doit interroger ses voisins d`s quune requte concerne e e e une zone sur laquelle il na pas lautorit de nommage. e Ainsi, un hte du domaine R2 qui veut rsoudre une adresse du o e domaine R1 doit ncessairement passer par un serveur intermdiaire e e pour obtenir linformation. Cette dmarche sappuie sur plusieurs stratgies e e possibles, que nous examinons dans les paragraphes suivants.

Subdivistion hirarchiques des domaines

Domaine R1 Domaines

Domaine R2

gure IX.03 Subdivision hirarchique des domaines e 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

Stratgie de fonctionnement e Un processus ( browser http par exemple) recherche ladresse dun nom de serveur. Sur les machines Unix cela se traduit par lappel ` la fonca tion gethostbyname. Cette fonction est systmatiquement prsente dans la e e biblioth`que standard (libc) et est donc accessible potentiellement ` tout e a excutable lors dune compilation. e La fonction gethostbyname fait systmatiquement appel au resolver e dj` cit. Cest donc toujours en passant par ce mcanisme que les processus ea e e acc`dent ` lespace de noms. Le resolver utilise une stratgie gnrale ` e a e e e a la machine (donc qui a t choisie par son administrateur) pour rsoudre de ee e telles requtes : e 1. Interrogation du serveur de noms (DNS) si prsent e 2. Utilisation des services type YP (NIS) si congurs e 3. Utilisation du chier /etc/hosts Cette stratgie est param`trable en fonction du constructeur. Le e e nsswitch sous HP-UX12 ou Solaris13 permet de passer de lun ` lautre en a cas dindisponibilit, le chier /etc/nsswitch.conf sous FreeBSD eectue e un travail assez proche. Enn, quelle que soit larchitecture logicielle le resolver est congur e ` laide du chier /etc/resolv.conf. a 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 reoit la demande, parcequil a lautorit sur le domaine c e demand (le sien), il rpond directement au resolver . e e 2.3.2 Interrogation distante

173

1. Un processus demande ladresse IP dune machine. Le resolver envoie sa requte au serveur local. e 2. Le serveur local reoit la requte et dans ce deuxi`me cas il ne peut pas c e e rpondre directement car la machine nest pas dans sa zone dautorit. e e Pour lever lindtermination il interroge alors un serveur racine pour e avoir ladresse dun serveur qui a lautorit sur la zone demande par e e le processus. 3. Le serveur racine renvoie ladresse dun serveur qui a ociellement lautorit sur la zone e 4. Le serveur local interroge ce nouveau serveur distant. 5. Le serveur distant renvoie linformation demande au serveur local. e 6. Le serveur local retourne la rponse au resolver e
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 mcanisme de cache accl`re le processus ci-dessus : Si un processus e ee redemande la mme machine distante on se retrouve dans le cas dune e interrogation locale , du moins pendant la dure de validit des e e donnes (cf page 186). e Si un processus demande une machine du mme domaine que la e prcdente (mais pas du mme nom ! :), les tapes 2 et 3 deviennent e e e e inutiles et le serveur local interroge alors directement le serveur distant. La dure de vie de ladresse du serveur distant est elle aussi assortie e dune date limite dutilisation. Dans le cas gnral les serveurs racines ne voient pas plus de 1 ou deux e e 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 tre ladresse dun serveur pour e C et ainsi jouera le rle de serveur racine de ltape prcdente. o e e e On dit galement que le serveur L de la gure IX.05 fonctionne en mode e rcursif. e 2.3.3 Interrogation par procuration

Le processus de recherche dcrit au paragraphe prcdent ne convient pas e e e dans tous les cas, notamment vis ` vis des deux crit`res suivants : a e 1. Scurit dun domaine e e 2. Conservation de la bande passante 1. La gure Romanchapter.05 montre le serveur local qui interroge directement les serveurs distants, cette dmarche pose des probl`mes de scurit dans le cas e e e e dun domaine au sein duquel seuls un ou deux serveurs sont autoriss. e

Hirarchie de serveurs e 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 au serveur de noms peut consommer une partie non e ngligeable de la bande passante, cest pourquoi il peut tre stratgique de e e e concentrer les demandes vers un seul serveur rgional et donc de bncier e e e au maximum de leet de cache dcrit prcdement. e e e

175

2.4

Hirarchie de serveurs e

Si tous les serveurs de noms traitent de donnes dun format identique, e leur position dans larborescence leur conf`re un statut qui se nomme : e serveur racine ( root name server ) Un serveur ayant autorit sur la e racine de lespace de nommage. Actuellement il y a 13 serveurs de ce type, nomms [A-M].ROOT-SERVERS.NET14 e serveur primaire ( master ) Un serveur de noms qui a lautorit pour un e ou plusieurs domaines (est dtenteur dautant de SOA Voir page 183). e Il lit ses donnes dans un chier stock sur disque dur, ` son dmarrage. e e a e Ladministrateur du (des) domaine(s) met ` jour les informations des a domaines concerns depuis cette machine. e serveur secondaire ( slave ) Dans le cas dune panne ou dun engorgement du serveur primaire, les serveurs secondaires reoivent en c prvision une copie de la base de donnes. e e Stratgiquement il est prfrable de les placer en dehors du domaine, e ee sur le rseau dun autre FAI. Il peut y avoir autant de serveurs secone daires que souhait, de lordre de trois ou quatre est souvent recontr. e e Au dmarrage ils reoivent les informations du serveur primaire, ou e c ils les lisent sur leur disque dur sils ont eu le temps de les y stocker au prcdent arrt du serveur, et si elles sont encore valides. e e e 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 est indique comme optionnelle dans la RFC 1034 mais e e est nanmoins bien commode voire mme frquement requise pour le client e e e rseau de services comme le courrier lectronique, ltablissement de sessions e e e ` distance avec ssh ou mme les serveurs de chiers anonymes (ftp). Si a e une machine est enregistre dans le TLD in-addr.arpa, cest un indicateur e favorable quant ` la qualit dadministration du rseau qui lhberge, mais a e e e ne prouve rien quant aux bonnes intentions de son (ses) utilisateur(s).
14

chier named.root, par exemple dans le rpertoire /etc/namedb e

176

Serveur de noms - DNS Il faut ajouter que le bon usage sur les rseaux est de prvoir une entre e e e dans la zone reverse pour toutes les machines utiles et utilises dun rseau e e accessible de lInternet. Le contraire provoque bien souvent la grogne (` juste a titre) des administrateurs. ` Il faut reconsidrer la gure IX.01. A gauche de la gure on distingue e un domaine un peu particulier in-addr.arpa . Toutes les adresses sont exprimes dans le top level domain : e in-addr.arpa Du fait de la lecture inverse de larbre, les adresses IP sont exprimes en e mirroir de la ralit. Par exemple pour la classe B de lecp : e e 195.138.in-addr.arpa (Classe B 138.195) Le fonctionnement par dlgation est calqu sur celui utilis pour les noms ee e e 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 tre en charge de ladministrae tion des zones reverses , portion du domaine arpa , des classes dadresses dont il dispose pour nommer ses machines, sil en reoit la dlgation. Il faut c ee bien noter que cette dlgation est une opration indpendante de celle qui ee e e a lieu pour les autres domaines. Notons galement que la notion de sous rseau (cf page 38) nest pas e e 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`s nayant comme adresses IP e ocielles que celles dlimites par un masque de sous rseau large seulement e e e que de quelques units (< 254), la gestion de la zone reverse reste du domaine e 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 donnes qui associe de mani`re e e structure des noms ` des adresses IP. e a 2. Des serveurs de noms, qui sont comptents pour rpondre sur une ou e e plusieurs zones. 3. Des resolver capables dinterroger les serveurs avec une stratgie e dnie par ladministrateur du syst`me. e e TCP ou UDP ? Le port 53 bien connu pour le serveur de noms est prvu pour fonce tionner avec les deux protocoles. Normalement la majeure partie du trac se fait avec UDP, mais si la taille dune rponse dpasse les 512 octets, un drapeau de len-tte du e e e protocole lindique au client qui reformule sans question en utilisant TCP. Quand un serveur secondaire dmarre son activit, il eectue une cone e nexion TCP vers le serveur primaire pour obtenir sa copie de la base de donnes. En gnral, toutes les trois heures (cest une valeur courante) e e e il eectue cette dmarche. e

Mise ` jour dynamique a

La mise ` jour dynamique de serveur de noms (RFC 2136) est une fonca tionnalit assez rcente sur le rseau, elle permet comme son nom lindique e e e de mettre ` jour la base de donne rpartie. a e e Aussi bien au niveau du rseau local qu` lchelle de lInternet il sagit le e a e 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 son e domaine chez un vendeur quelconque et qui au gr des changements dadresse e ip (attribue dynamiquement par exemple avec DHCP15 ) par son fournisseur e dacc`s, met ` jour le serveur de noms pour tre toujours accessible. e a e Avec comme mot clef dyndns , les moteurs de recherche indiquent lexistence de sites commerciaux ou ` caract`re associatif, qui proposent cette a e fonctionnalit. e

15

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

178

Serveur de noms - DNS

Scurisation des changes e e

Le serveur de noms est la clef de vote des rseaux, et cest en mme temps u e e un de ses talons dAchille parceque les programmes que nous employons quotidiennement utilisent sans discernement linformation acquise du rseau. En e 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 tablissement ? Lapparence de la page de garde ? e Typiquement il y a deux situations de vulnrabilit : e e 1. Dialogue serveur ` serveur, notament lors de transferts de zones a 2. Interrogation dun serveur par un resolveur Pour faire conance en ce que vous dit le serveur de noms interrog il faut e dune part que vous soyez certains dinterroger la bonne machine et dautre part que celle-ci soit dtentrice dune information incontestable. e Cest une cha de conance, comme toujours en scurit, qui rene e e monte par construction du fonctionnement du serveur de noms interrog e par votre application (comme nous lavons examin dans les paragraphes qui e prc`dent) jusquaux serveurs racines. e e La version ISC (consultez le paragraphe 7) du programme BIND utilise deux stratgies direntes, selon les cas ci-dessus. Dans le premier cas il sagit e e dun mcanisme nomm TSIG/TKEY, dans le deuxi`me DNSSEC. e e e TSIG/TKEY utilisent une clef symtrique, donc partage par les deux e e serveurs (cette clef leur est connue par des mcanismes dirents). DNSSEC e e utilise un mcanisme bas sur le principe dun change de clefs publiques. e e e Outre les dysfonctionnements ds ` une information errone on observe u a e 16 galement des attaques de type dni de service utilisant le fonctionnant e e intrins`que du protocole (voir plus loin5). e

4.1

TSIG/TKEY pour scuriser les transferts e

Lusage dune clef symtrique indique quil sagit dun secret partag entre e e 2 serveurs. La mme clef sert au chirement et au dchirement des donnes. e e e Le bon usage veut que lon ddie une clef ` un certain type de transaction (par e a exemple le transfert dune zone) entre deux serveurs donns. Cette mani`re e e de procder se traduit donc rapidement par un grand nombre de clefs ` grer e a e ce qui interdit un dploiement gnralis sur lInternet. e e e e Pour viter de trop longs temps de chirement, ce ne sont pas les donnes e e ` transfrer qui sont chires (de plus elles ne sont pas condentielles), mais a e e 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 hsiter ` faire un man md5 ou man sha1 sur une machine Unix pour en savoir e a plus !
16

DNSSEC pour scuriser les interrogations e Cette empreinte, seule, est crypte. e Le serveur qui reoit un tel paquet sign, calcule lempreinte du paquet c e avec le mme algorithme, dchire celle jointe avec la clef secr`te partage e e e e et compare les deux empreintes. Le rsultat de cette comparaison dit si les e donnes sont valides ou non. e Lintrt de ces transferts signs est que les serveurs secondaires sont ee e certains de mettre ` jour leur zones avec des donnes qui proviennent bien a e du dtenteur du SOA et qui sont absolument semblables ` ce qui a t mis. e a eee 4.1.1 TSIG

179

TSIG comme Transaction SIGnature est la mthode dcrite dans e e la RFC 2845 et base sur lusage dune clef symtrique. La gnration e e e e de cette clef peut tre manuelle ou automatise avec le programme e e 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 rseau), e donc mise en place au coup par coup. TSIG sert galement ` la mise ` jour dynamique ( dynamic update ), e a a la connaissance de la clef par le client sert ` la fois ` lauthentier et ` signer a a a 18 les donnes . e 4.1.2 TKEY

TKEY, dcrit dans la RFC 2930, rend les mmes services que TSIG tout e e en vitant le transport du secret (TSIG). Cette caractristique est base e e e sur le calcul la clef symtrique automatiquement avec lalgorithme de Diee Hellman plutt que par un change manuel 19 . o e Par contre, cet algorithme ` base du tandem clef publique clef prive a e suppose lajout dun champ KEY dans les chiers de conguration du serveur. Comme dailleurs le mcanisme suivant. . . e

4.2

DNSSEC pour scuriser les interrogations e

DNSSEC dcrit dans la RFC 2535 permet : e 1. La distribution dune clef publique (champ KEY) 2. La certication de lorigine des donnes e 3. Lauthentication des transactions (transferts, requtes) e Mis en place, le DNSSEC permet de construire une cha de conance, ne depuis le top level jusquau serveur interrog par votre station de travail. e
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-tte e (page 84) est facilement falsiable, notamment sur ladresse de retour. Il est ainsi tr`s facile denvoyer une requte ` un serveur, avec une adresse de e e a retour qui est celle dune machine victime plutt que la sienne : o
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 Rponse ` une requte non formule e a e e Sur la gure IX.06 la machine dadresse IPv reoit un message du serveur c de noms dadresse IPs, non sollicit. Il est bien vident quun seul message e e de ce type reste sans eet, cependant : 1. Le volume en octets de la rponse peut tre considrablement plus e e e important que celui de la requte, notamment si le serveur de noms est e congur par lassaillant. Par exemple dun facteur 5 ou 10. e 2. Lassaillant peut envoyer un tr`s grand nombre de requtes ` des sere e a veurs ouverts en mode rcursif pour toute requte ne portant pas sur e e les domaines sur lequels ils ont autorit. e La machine victime est alors submerge par un ot de rponses qui sae e turent compl`tement ses acc`s rseaux, cest une une attaque DNS par ame e e e plication20 et qui provoque un dni de service sur le site qui la subit. Le schma densemble dune telle attaque est rsum sur la gure IX.07. e e e La machine assaillante (elles peuvent tre nombreuses, des centaines de e milliers) bombardent les serveurs (S1, S2,. . .Sn) de fausses requtes. e Ces serveurs sont utiliss parcequils combinent deux proprits e ee intressantes : e 1. Ils sont ouverts aux requtes extrieures mme et surtout celles qui ne e e e portent pas sur leurs donnes. Cette proprit est hrite de lpoque e ee e e e ou lInternet tait encore un rseau duniversitaires et dinformaticiens. e e Cette proprit devrait tendre ` dispara e a tre, mais cest loin dtre encore e
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 comptences techniques ne sont pas assez nombreuses. e 2. Ils utilisent un cache DNS. Leet de ce cache est que mme si la mae chine source est isole du rseau, les enregistrements lus, pourvu e e quils soient assortis dun temps de vie susant (TTL, page 183) peuvent continuer dtre exploits. e e
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 ncessairement complice, cest e tout simplement un serveur avec de gros enregistrements. 2. Les serveurs S1 ` Sn sont utiliss ` leur insu mais une conguration a e a soigneuse peut viter cet abus dusage. e 3. Une fois attaqu le serveur victime ne peut pas faire grand chose. Ses e services ne sont plus accessibles car le rseau est satur. e e 4. La parade avec un serveur de type Bind de lISC (page 186) consiste ` explicitement limiter louverture extrieure du serveur aux seules a e donnes sur lesquelles il a autorit 22 . e e Lacc`s aux donnes dans le cache doit galement tre protg car e e e e e e dautres techniques existent pour peupler les caches, par exemple envoyer un mail qui ncessite linterrogation du serveur source. e

Un test sur son serveur depuis une machine hors de son rseau local est possible ` e 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 donnes, le serveur de nom a un format pour e ses champs, ou Resource Record , RR dans la suite de ce texte, dni ` e a lorigine dans la RFC 1035. En pratique toutes les distributions (commerciales ou libres) du serveur de noms conservent ce format de base de donnes, la mise en uvre du serveur e seule change (chier de conguration du daemon). Un serveur de noms a autorit (responsabilit du SOA) sur une ou plusieurs e e zones, celles-ci sont repres dans ses chiers de conguration (named.conf ee 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 dcrite dans le paragraphe suivant. e Sil est serveur secondaire, le chier de conguration indique au server de quelle(s) zone(s) il est secondaire (il peut tre secondaire dun grand nombre e de zones) et donc o` (adresse IP) il devra aller chercher cette information. u Cette action se traduit par ce que lon nomme un transfert de zone . Ce transfert est eectu automatiquement ` la frquence prvue par ladminise a e e trateur du champ SOA et donc connue d`s le premier transfert. En cas de e changement sur le serveur principal, celui-ci avertit ( Notify ) ses serveurs secondaires de la ncessit de recharger la zone pour tre ` jour. e e e a Le propos de ce qui suit nest pas de se substituer ` une documentaa tion nombreuse et bien faite sur le sujet, mais dapporter quelques lments ee 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 gnral crits sur une seule ligne de texte (sauf pour e e e le champ SOA qui stale sur plusieurs lignes. Le marqueur de n de ligne e (CR+LF) est aussi celui de la n de lenregistrement. Le contenu gnral e e dun tel enregistrement a la forme suivante (les accolades indique des donnes e 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 dsigne le dbut e e oblig et unique dune zone. Il doit gurer dans chaque chier db.domain et e db.adresse Le nom de cette zone est ici repr par le caract`re @ qui signie ee e la zone courante, repre par la ligne au dessus $(ORIGIN) sio.ecp.fr. . ee La ligne aurait galement pu scrire : e e
sio.ecp.fr. IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. (...)

Un probl`me concernant cette zone devra tre signal par e-mail ` e e e a hostmaster@sio.ecp.fr (notez le . qui sest transform en @). e Les param`tres de ce SOA sont dcrits sur plusieurs lignes, regroupes e e e entres parenth`ses. Le caract`re ; marque le dbut dun commentaire, qui e e e sarrte ` la n de ligne. e a Les points en n de noms sont ncessaires. e Le numro de srie doit changer ` chaque mise ` jour de la zone (sur le sere e a a veur principal). Le Refresh indique la frquence, en secondes, ` laquelle les e a serveurs secondaires doivent consulter le primaire pour ventuellement lancer e un transfert de zone (si le numro de srie est plus grand). Le Retry indique e e combien de secondes un serveur secondaire doit attendre un transfert avant de le dclarer impossible. Le Expire indique le nombre de secondes maxie mum pendant lesquelles un serveur secondaire peut se servir des donnes du e primaire en cas dchec du transfert. Minimum ttl est le nombre de secondes e par dfaut pour le champ TTL si celui-ci est omis dans les RR. e

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 ` un nom, cest donc celui qui est potentiellement le plus frquement a e utilis. Il doit y avoir un RR de type A pour chaque adresse dune machine. e

{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 spcier les adresses pour la rsolution inverse, donc dans le domaine spcial e e e IN-ADDR.ARPA. Notez le . en n de nom qui interdit la compltion (il sagit e 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 lectronique. Nous examinerons son e fonctionnement ultrieurement dans le chapitre sur le courrier lectronique e e (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 mme zone (ecp.fr.) naide en rien au bon fonctionnement du dise positif. La machine msio-bipro pourrait tre hberge nimporte o` ailleurs e e e u sur un autre rseau dans une autre zone. . . ! e Cette possibilit est tr`s employe pour constituer des machines virtuelles, e e e comme nous le verrons au chapitre VIII.

6.7

Autres RR. . .

Il existe dautres RR, entres autres HINFO , TXT, WKS et KEY, non traits e dans cette prsentation parcequils napportent rien ` la comprhension du e a e fonctionnement du serveur de noms. Le lecteur est fortement incit ` se e a 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 dveloppe et favorise lemploi de loutil Open Source comme BIND e (acronyme de Berkeley Internet Name Domain ). Cette version libre du serveur de nom est la plus employe sur les machines e Unix du rseau, ce qui justie que lon sy intresse. Elle fournit une version e e du daemon named et un resolver intgr dans la libc. On peut e e aisment installer ce logiciel sur ` peu pr`s toutes les implmentations dunix e a e e connues (cf le chier INSTALL du rpertoire src). e
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 schma gnral de lorganisation logicielle du e e e daemon named . Au dmarrage celui-ci lit sa conguration dans un chier qui peut se e 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 dmarrage. Sa structure e dpend de la version du logicielle, heureusement dans les deux cas la e smantique reste proche ! e
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 donne du localhost . Pere sonne ne poss`de en particulier le rseau 127, donc chacun doit le grer e e e pour lui-mme. Labsence de ce chier nempche pas le serveur de e e fonctionner, mais ne lui permet pas de rsoudre 127.0.0.xx (o` xx est e u le numro de la machine courante, souvent 1). e db.terminal Exemple de chier de base de donnes pour le domaine face tice 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 donnes de la zone reverse e pour le domaine terminal.fr, cest ` dire le chier qui permet au a 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-mme. Cest une e alternative ` lusage direct des signaux. Le canal de communication a 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 examins en travaux pratiques, tout comme les chiers lus ou crits e e dans les rpertoires /var/run et /var/tmp/. e Enn la `che vers syslog signie que named utilise ce service pour laisser e une trace de son activit (cf cours sur larchitecture des serveurs). e Enn, le BOG, cest ` dire le Bind Operations Guide , dtaille le a e contenu des champs de la base de donnes des versions 4.x et 8.x. Pour la e version 9.x est distribue avec BIND 9 Administrator Reference Manual e une documentation galement tr`s bien faite. e e

187

Bibliographie

Quand on sait dj` , la page de man de named sut ` vrier un ea a e point obscur ! Sinon il existe une documentation tr`s fournie sur le sujet, avec e 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 ` cette adresse : http://www.isc. a org/products/BIND/ 26 on trouve galement la derni`re version de ce document sur le site de lISC e e
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 lectronique e

Gnralits sur le courrier lectronique e e e e

Le courrier lectronique, ou mail est lun des deux services les plus e populaires sur le rseau, avec le web. e Cest aussi lun des plus vieux services du rseau, bien avant que le e rseau existe sous la forme que lon pratique aujourdhui1 . La prface de e e la [RFC 822], document fondamental parmi les documents fondamentaux pour ce chapitre, laisse supposer lexistence de nombreux formats dchanges e lectroniques sur lArpanet, et ce avant 1977. e Sa popularit repose sur sa grande souplesse et rapidit demploi. Il pere e met aussi bien les changes professionnels que les changes privs ; son mode e e e dadressage donne la possibilit denvoyer un courrier ` une personne comme e a ` une liste de personnes ou encore ` un automate capable de rediuser vers a a un groupe ( mailing-list ). De nombreux outils dvelopps, ` lorigine essentiellement sur le syst`me e e a e Unix, autour de ce concept ouvrent un vaste champs de possibilits aux utilie sateurs de tous les syst`mes dexploitation, comme la ventilation des courriers e par th`me, le renvoi automatique, le rpondeur (pendant les absences), lacc`s e e e ` sa boite aux lettres depuis des endroits dirents, la rception de fax,. . .La a e e liste ne peut pas tre exhaustive ! e Cest souvent pour avoir lusage du courrier lectronique que les entits e e (sil en reste) non encore relies ` lInternet franchissent le pas. Lusage des e a autres services arrivent plus tard, si besoin est.

Un historique intressant http://www.fnet.fr/history/ e

190

Courrier lectronique e

1.1

Mtaphore du courrier postal - Lenveloppe e

Un courrier postal (ou de surface, s-mail ) a fondamentalement besoin de ladresse du destinataire et de ladresse de lmetteur (pour la rponse). e e Lusage du timbre et de lenveloppe rpondent ` dautres crit`res. e a e Une fois dans la bo aux lettres, lenveloppe est route de la poste locale te e vers la poste la plus proche du destinataire, pour tre nalement dlivre par e e e un facteur. Pour un courrier lectronique les besoins sont quasiment idene tiques ! Le concept denveloppe est conserv, il sagit de ladresse de lmetteur e e du courrier et de celle(s) du (des) destinataire(s), propages de mani`re bien e e spare du corps du message an que le protocole SMTP qui joue le rle du e e o service postale (Voir page 195) puisse router et nalement dlivrer le courrier e ` son (ses) destinataire(s). a Il existe de tr`s nombreux outils pour lire/crire un mail, des outils pour e e jouer le rle du bureau de poste et/ou du facteur. Sous Unix le facteur est le o syst`me lui-mme, le bureau de poste un programme nomm sendmail2 . e e e Il existe dautres alternatives non abordes dans ce document, comme le e programme qmail3 ou encore le programme postx4 .

1.2

Adresse lectronique e

Tous les courriers lectroniques ont un destinataire prcis par son adresse e e e 5 e lectronique, ou E-mail . Celle-ci prcise le nom du destinataire et le site e o` il reoit son courrier lectronique. u c e Le nom du destinaire est une cha de caract`res. Traditionnellement ne e et pour des raisons techniques, sur le syst`me Unix, le login de lutilisateur e peut tre galement le nom de sa boite aux lettres. Cette possibilit est de e e e moins en moins vraie ` mesure que dautres syst`mes avec dautres logiques a e de fonctionnement existent galement sur le rseau (notamment la lecture du e e mail via un interface html ou encore lorsque le mail est dlivr directement e e dans une une base de donnes et non dlivr dans un chier). e e e Par exemple, il est assez frquent de voir employer le nom complet e (prnom et nom de famille) pour dsigner linterlocuteur distant. La convere e sion ultime entre cette convention et la bo aux lettres de lutilisateur est te laaire du bureau de poste le plus proche , cest ` dire le programme a sendmail pour ce document (voir plus loin au paragraphe 4). Le caract`re @ (lire at ) spare lidenticateur du destinataire de e e 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 en m`l , ou couriel pour les documents administratifs. . . ;-) e e

2 Format dun E-mail - RFC 822 La destination est peut tre vide (il sagit alors dun destinataire sur e la machine courante, ou dun synonyme ( alias ) que le sendmail local sait traiter), tre un nom de machine du domaine local, le nom dun autre e 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 mcanisme de compltion dans le resole e ver page 170 !). user3@nom de machine.domaine Destinataire sur une machine particuli`re e dun domaine particulier (non forcment local). e user4@domaine Destinataire sur un domaine particulier (mme remarque e que ci-dessus). On devine aisment que le fonctionnement du courrier lectronique sur e e une machine distante est fortement lie au bon fonctionnement du serveur e de noms (chapitre IX). Qui plus est, lorsque seul un nom de domaine est prcis ` droite du e e a caract`re @ , une information manque apparemment quant ` la machine e a susceptible de recevoir le mail. Le lecteur en qute de plus de prcisions trouvera une description exhause e tive 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 lectronique obissent ` une struce e a ture bien dnie par la [RFC 822] de David H. Crocker : un en-tte et un e e 6 corps de message, spars par une ligne blanche (deux CRLF qui se suivent). e e Le contenu de len-tte dans son intgralit nest pas toujours spone e e tanment montr par les outils qui nous permettent de lire et denvoyer du e e courrier lectronique. Une option est toujours accessible pour ce faire, comme e h sous mutt 7 . Une partie de len-tte est gnre automatiquement par le programme e e ee qui se charge du transfert (le paragraphe suivant nous dira quil sagit dun MTA), une autre est ajoute par le programme qui permet de composer le e mail, le MUA, une autre enn est tape par lutilisateur lui-mme. e e Len-tte est constitu de lignes construites sur le mod`le : e e e identicateur : [ valeur ] CRLF
6 7

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

192

Courrier lectronique e Lidenticateur ne peut pas contenir le caract`re : parcequil sert de e sparateur avec la partie droite. Il est constitu de caract`res ASCII cods e e e e sur 7 bits et imprimables (cest ` dire comprise dans le segment [33, 126]), a except lespace. e Valeur est optionnelle. Lusage des majuscules ou des minuscules est indirenci. e 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 tre globalement respecte. Le lecteur soucieux dune e e description exhaustive de ce en quoi peut tre constitu un en-tte pourra se e e e repporter au paragraphe 4.1 de la RFC (SYNTAX). Certains champs de len-tte proviennent de la conguration du MTA, e dautres sont cres en interne par le MTA lui-mme, dautres enn sont gres e e ee par le MUA, donc accessible ` lutilisateur nal. a

2.1

Quelques champs couramment rencontrs dans les e en-ttes e

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

Quelques champs couramment rencontrs dans les en-ttes e e

193

To (The primary recipients) Il sagit du (des) destinataire(s) principaux du message ( recipient ). Ce champ peut ventuellement tre vide, e e le MTA prend alors une dcision param`trable pour le complter. La e e e 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(s). e Bcc (Blind carbon copy) Une copie du message est transmise au(x) destinataire(s) list(s), sans que les destinaitaires principaux des champs e To et Cc en soit informs. e From (The sender) il sagit de lmetteur du message. Le plus souvent e il sagit dune seule personne, quand ce champ en liste plusieurs (le sparateur est la virgule , ) le champ Sender doit prciser ladresse e e de celui qui a eectivement envoy le message. e Reply-To (Alternative reply address) Ce champ prcise une adresse ale ternative ` celle du champ From pour lenvoi de la rponse. Cette a e disposition est utilise par les robots de gestion des mailing-list, pour e distinguer lauteur du message et le destinataire de la rponse. e Message-ID (Unique identier for message) Ce champ est cens idene ti de mani`re unique le message. Il est fabriqu d`s sa soumission au e e e e premier MTA (MSA). Il est constitu traditionnellement de la mani`re e e suivante : nombre de secondes.identificateur de queue@domaine nombre de secondes Correspond ` la date courante en secondes cala 8 cules depuis le 01/01/1970 e identificateur de queue Identie la queue locale sur laquelle ce mail est dpos en entre. e e e domaine Cest le domaine dmission du message. e 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` sa dlivrance nale. Chaque a e MTA ajoute un champ de ce type. Le cheminement est ` suivre en a commenant en n de len-tte. c e Chaque champ est constitu au minimum de from, le nom canonique e de la machine de qui le MTA a reu le message, de by le nom canonique c du MTA qui a reu le message et ajout ce champ et enn de la date c e de la transaction.

Epoch pour les unixiens !

194 Exemple :

Courrier lectronique e

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 tre dlivrs immdiatement sont placs dans une le dattente dont la e e e e e date dexpiration est dautant plus courte que le message est urgent. Lmetteur du message reoit dabord un avertissement puis une erreur e c si le message nest pas dlivr quand arrive la date dexpiration. e e Content-Transfer-Encoding (Auxiliary MIME encoding) Indique comment est encod le corps du message pour supporter les caract`res e e hors jeu ascii 7 bits (SMTP ne transporte que des caract`res 7 bits). e Des valeurs courantes sont base64, quoted-printable, 8bit,.... Content-Type (The nature of the body of the message) Ce champ indique comment est constitu le corps du message. Par dfaut il est e e suppos tre constitu que de caract`res 8 bits dont le bit de poids fort ee e e est sans signication (7 bits eectifs). Pour crire e les caract`res e accentus e du franais, c 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`ces jointes, une e balise introduite en supplment dans len-tte va servir ` sparer les e e a e direntes parties du message comme dans : e Content-Type: multipart/mixed; boundary="opJtzjQTFsWocga" La chaine opJtzjQTFsWocga sert alors de marqueur pour reprer e chaque partie du mail (corps du message et pi`ces jointes). e Date (The origin date) Cest la date ` laquelle le message a t envoy a ee e initialement. Ce champ est obligatoire. Subject (Topic of the message) Cest une courte cha de caract`res ne e qui rsume le message. Les MUA montre ce champ pour permettre une e meilleure slection des messages avant de les lire. e MIME-Version (This message conforms to MIME standards) Niveau de MIME pour lencodage du corps de message (voir page 197). X- Cest un en-tte spciquement ajout par le MUA ou par un processus e e e de la cha de traitement du courrier. Un exemple parmi tellement ne dautre :
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2

Ajout par un mcanisme extrieur au MTA, qui agit contre le spam, e e e et nomm le Greylisting9 e
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 lectronique de mani`re able et ecace. Il est dni e e e dans la [RFC 821] de Jonathan B. Postel. Indpendant par sa conception dun quelconque sous-syst`me de transe e port, il est principalement aujourdhui encapsul dans des paquets TCP ` e a destination du port 25 (cf le chier /etc/services). Dans un pass pas si loine tain lacc`s rseau de beaucoup de sites se rsumait au courrier lectronique e e e e encapsul dans des trames du protocole UUCP10 , donc sur liaison srie via e e 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 rpond par des codes numriques qui e e indiquent le statut de la prise en compte de la commande. Cest pourquoi il est ais de se connecter sur un MTA avec un simple e 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 rpond ` la e a connexion par un code 220 pour dire que le service est oprationnel ( service e ready ), suivi du nom de la machine, de la banni`re du programme, de la e version de sa conguration, et de sa date courante. Puis lutilisateur a tap la commande NOOP qui na dautre eet que de e forcer le serveur ` rpondre et renvoyer un code (250) pour dire que tout va a e bien. Enn Lutilisateur a tap QUIT pour nir proprement la transaction. La e rponse du serveur est un code 221 pour signier la n canonique de la e 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 dmarr par le pass ` laide un dtournement de sendmail. Les administrateurs e e ea e rseaux sont donc attentifs au trac sur le port 25 ; il est prfrable de rserver ce genre e ee e de tests uniquement sur son propre site. 12 http://www.sendmail.org/
11 10

196

Courrier lectronique e Dans un deuxi`me essai nous utilisons loption -v du programme mail, e pour visualiser les changes entre le MUA (machine athome.mondomain.fr) e 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 reu, lu aussi avec mail : c

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, a passe ! :) c Il est galement intressant dobserver ` ce niveau que les caract`res du e e a e courrier ont t considrablement enrichis par un en-tte volumineux (relaee e e tivement). En eet, chaque nud travers (MTA), ajoute un champ Received e permettant apr`s coup de suivre le trajet du courrier. Les autres champs e

Protocole SMTP comme Date :, Subject : ou Message-Id : sont ajouts dans len-tte par e e le MUA de lcrivain du message. e Cette partie de len-tte ajoute par le MUA dorigine est souvent dese e tine ` piloter le comportement du MUA du destinataire du message plus e a que pour tre lue. Cette attitude sest gnralise au point de devenir assez e e e e complique et tre formalise dans un ensemble de r`gles baptises MIME e e e e e comme Multipurpose Internet Mail Extensions ([RFC 2184]). La fonction la plus rpandue et la plus simple de MIME est dautoriser e lusage des caract`res accentus (codage sur 8 bits ou plus) ` lintrieur du e e a e corps du message (len-tte SMTP reste code sur 7 bits). Lutilisateur voit e e alors appara des lignes supplmentaires comme celles-ci : tre e
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`res e accentus, dnie dans la [RFC 822]. Le plus souvent on trouve des lignes e e 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 ` lexcution dun proa e gramme extrieur au MUA, ce qui constitue une dangereuse faille potentielle e dans la scurit des rseaux, donc ` viter. e e e ae

3.2

Principales commandes de SMTP

Exprimentalement nous avons dcouvert quelques uns des mots rservs e e e e du protocole : HELO, MAIL, RCPT, DATA, QUIT. Une implmentation minie male 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 organiss sur trois chires, le premier chire e donne le sens gnral de la rponse, tr`s succintement ce qui dbute par 1,2 e e e e e ou 3 a une signication positive, 4 ou 5 signie une erreur. Une information plus dtaille se trouve ` lannexe E de la RFC. e e a Les cinq commandes dcouvertes prcdement sutilisent toujours dans e e e cet ordre. Examinons succintement leur usage : 3.2.1 Commande HELO

Synopsis : HELO <espace> <domaine> <CRLF> Cette commande est utilise pour identier lmetteur du mail. Largue e ment qui suit, domain est le nom de la machine ou du domaine do` provient u la connexion.

198

Courrier lectronique e En rponse le serveur envoie une banni`re dans laquelle il sidentie et e e 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 dbute un transfert de mail. En argument sont transmis e (chemin inverse) ladresse e-mail de lmetteur et la liste des machines qui e ont relay le mail courant. La premi`re machine est la plus rcente. Cette ine e e formation est utilise pour renvoyer, sil y a lieu, une notication de probl`me e e ` lmetteur du mail. a e 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`me tape dans la procdure denvoi dun e e e mail. Il y a une commande de ce type par destinataire du courrier ( recipient ). Par exemple : RCPT TO:<Lambda@mondomain.fr> Il est intressant de noter que les arguments de cette commande et ceux e de la prcdente (MAIL) forment lenveloppe du mail (expditeur et dese e e tinataire) comme nous en avons signal lexistence conceptuelle page 190. e 3.2.4 Commande DATA

Synopsis : DATA <CRLF> Apr`s rception de la commande, le serveur lit les lignes de texte en proe e venance du client jusqu` rencontrer la squence <CRLF>.<CRLF> qui a e marque la n du message. Il faut remarquer que celui-ci comprend lintgralit e e de la gure X.01. 3.2.5 Commande QUIT

Synopsis : QUIT <CRLF> Marque la n de la session et entraine la clture de la connexion. o

Protocole SMTP

199

3.3

Propagation du courrier lectronique e

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

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 crire le corps du courrier et de paramtrer quelques e e lments de len-tte, principalement ladresse du destinaire, et le sujet ee e du message. Il existe un tr`s grand nombre de MUAs sous Unix, il est coue rant de rencontrer mail, mailx, elm, pine, mutt, mh, eudora, kmail, thundermail, sylpheed... Il y en a pour tous les gots ! u MSA Mail Submission Agent , cest une nouveaut dnie par la e e [RFC 2476] et qui joue le rle dinterface entre le MUA et le MTA. o Lobjet du MSA est de sparer les fonctions de transfert du courrier e et dacceptation de nouveaux courriers mis depuis les MUA. Cette e sparation des tches amliore deux aspects : e a e La scurit Les nouveaux mails sont soumis ` un daemon qui ne e e a nexcutent pas avec les droits du root13 . e La conformit aux standards Les messages proviennent de MUAs e qui ne respectent pas forcment tous les prrequis de formulation e e des en-ttes. e Le rle du MSA est de vrier et de compl`ter ces en-ttes avant o e e e 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 lectronique e Les MTAs coutent le rseau sur le port 25 et dialoguent entre-eux avec e e le protocole SMTP (ESMTP14 ). LDA Local Delivery Agent , cest lentit qui dlivre eectivement le e e mail, soit dans une boite au lettres soit dans une base de donnes, par e exemple une base Cyrus15 . OS Operating System , le syst`me dexploitation sur lequel fonctionnent e ces programmes. La gure X.2 illustre la possibilit la plus simple dchange entre deux e e MTA : la connexion directe. Cela signie que le MTA de la station mettrice e contacte le MTA de la station rceptrice et lui dlivre directement le message. e e La vie relle est plus complique car elle tient compte de lorganisation e e hirarchique des rseaux et surtout de la scurit qui est un aspect devenu e e e e important sur lInternet. Cela se traduit par un emploi gnralis de machines e e e 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 lectroniques dun site, vers e lextrieur et inversement. Elle a des avantages, notamment : e
14 15

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

Courriers indsirables - Le spam e Avoir une politique de scurit concentre sur un petit nombre de mae e e 16 chines exposes , plutt que sur toutes les stations du rseau : le roue o e teur ltrant nautorise les acc`s extrieurs que sur le port smtp(25) de e e ces quelques machines ddies. e e Avoir une politique centralise pour le ltrage des contenus indsirables e e (virus) et des metteurs suspects (spams). e Limiter le nombre de congurations compliques de sendmail ` un pee a tit nombre de machines. Les stations des utilisateurs peuvent se contenter dune conguration standard plus facile ` distribuer et ` adapter a a automatiquement. Permettre de masquer plus facilement les machines internes du rseau e vis ` vis de lextrieur. En clair, les courriers auront lair de provenir a e de cette machine plutt que de la station dun utilisateur sur le rseau o e interne. Ladresse de lmetteur aura la forme : e user@domaine au lieu de : user@machine.domaine. Permettre le stockage intermdiaire du courrier en attente dune e dlivrance : les stations des utilisateurs ne sont pas toujours en fonce tionnement. Cette architecture est thorique, en pratique il peut y avoir une hirarchie e e de relay mail plus complique. Par exemple une grappe de machines e distinctes suivant que le courrier entre ou sort du site, une arborescence de machines relais quand lentreprise est elle-mme rpartie sur plusieurs sites e e gographiques et ne poss`de quune liaison vers lextrieur,. . . e e e

201

3.4

Courriers indsirables - Le spam e

Le spam est laspect tr`s dsagrable du courrier lectronique. e e e e Par spam on dsigne ces innombrables courriers, le plus souvent ` e a caract`re commercial, qui envahissent nos boites aux lettres lectroniques. e e Certaines estimations tablent sur au moins 30% de spam dans le trac mail mondial et cette estimation est rguli`rement revue ` la hausse. e e a Deux questions se posent, comment le caractriser et surtout comment e lviter ? e 3.4.1 Caractriser le spam e

1. Un contenu commercial, publicitaire, nancier, ou qui tente de retenir lattention du lecteur ` partir dune histoire dont lissue est toujours a pcuniaire et au dtriment du destinataire. e e
Ce qui nexclue pas bien entendu davoir une politique de scurit pour le mail sur le e e rseau interne e
16

202

Courrier lectronique e 2. Une importante liste de destinataires. Le champ Cc : peut contenir par exemple des centaines de destinataires. 3. Un en-tte de message truqu. Par exemple le champ Message-ID : e e qui est cens identier le message de mani`re unique est absent ou e e incohrent (page 193). e 4. Un grand nombre dexemplaires du mme message envoy dans un court e e laps de temps. Cette caractristique ne concerne pas le contenu du mail e mais la mani`re avec laquelle il est envoy. Cest le MTA qui reoit les e e c demandes de connexions qui peut dtecter cette caractristiques. e e 5. Utilisation de ladresse dun destinataire sans son consentement explicite pour ce type denvoi. 6. Usage dun site open mail relay pour lmission. Lmetteur du mail e e peut alors usurper le nom du domaine dmission. e Pour mmoire, un site open mail relay autorise un RCPT qui ne e dsigne pas un destinataire pour lequel la dlivrance des mails est aue e torise sur ce site. Le site sert alors en quelque sorte de tremplin pour e le mail, avec un eet de dissimulation du site metteur vritable. Les e e versions modernes des MTA interdisent cette possibilit par dfaut. e e 7. Champs To et From de len-tte invalides e Comme par exemple lutilisation comme adresse e-mail dorigine du mail celle dun utilisateur nayant strictement rien ` voir avec le message a (cest lenveloppe qui compte pour la dlivrance du mail). e 8. Le contenu du mail contient un virus, soit dans le corps du message soit dans une pi`ce jointe. Par abus ce genre de mail est parfois trait e e comme du spam. 3.4.2 Eviter le spam

Cest une question ouverte. . . Sil est vident que lil humain reconnait un tel courrier de mani`re e e quasi infaillible, il nen est pas de mme pour la machine. e Il nexiste pas de mthode de lutte unique et infaillible. Un bon rsultat e e (plus de 99% du trac de spam bloqu) peut cependant tre atteint en pase e sant par lusage dune palette doutils et de dispositifs extrieurs. Toutefois e lensemble de ce dispositif a un cot non ngligeable en terme de cycles cpu u e consomms pour un mail dlivr, dune part, et dautre part en terme de e e e cot de maintenance car larchitecture logicielle qui en dcoule est complexe u e et demande du temps de spcialiste de bon niveau pour sa maintenance. e Tout dabord, une bonne partie de lorigine du spam vient du fait que le protocole SMTP lui-mme est beaucoup trop permissif. e Conu ` une poque o` le rseau tait constitu sur la base de la conance c a e u e e e et de la collaboration entre sites honorables, il nest plus adapt ` ce quest ea devenu le rseau. La faille la plus navrante est que lenveloppe transmise lors e

Courriers indsirables - Le spam e de lchange protocolaire nest pas ncessairement identique ` ce qui gure e e a dans len-tte du mail. Lexemple qui suit illustre cette faille : e
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 dlivr dans la boite aux lettres de lutilisateur lambda e e avec des champs From : et To : compl`tement inexploitables ! e Pour viter la dlivrance de ce mail, la conguration du MTA de e e mondomain.fr pourrait mettre en place une protection agissant en trois temps : lors de ltablissement de la connexion, lors de la rception e e de lenveloppe puis ` la rception du message lui-mme. a e e Le protocole SMTP ne comprend pas daccus de rception. Si lhonnte e e e utilisateur de ce protocole envoie un courrier rout silencieusement, par ere reur, dans une boite aux lettres de courriers indsirables (en gnral non lus e e e et souvent supprims automatiquement), cest regrettable et dautant plus e prjudiciable que le contenu du mail est important. Il est donc bien plus ee cace de refuser le message tant que la connexion avec le MTA qui lmet est e maintenue, car quel que soit le contenu de lenveloppe (les Reply-to et From sont peut tre faux ou inexistants), le MTA qui route ce mail est ` lautre e a bout de la connexion et est suppos, par construction, tre le mieux plac e e e pour prvenir lauteur du mail que la transaction actuelle est refuse. e e Autrement dit, il est bien prfrable deectuer le tri en temps rel plutt ee e o quen temps dir lors de la dlivrance dans la boite de lutilisateur ou apr`s ee e e rapatriement (voir page 210) des mails par son MUA. Si lorigine du mail est honnte, lmetteur sera tout de suite prvenu e e e (mail derreur) et pourra agir en consquence, dans le cas contraire le spame meur rceptionnera autant de messages derreurs que de spams envoys (un e e rve. . .) ce qui ne manquera pas de le gner considrablement. Nous ne le e e e plaindrons pas.

204

Courrier lectronique e ` e A ltablissement de la connexion le MTA peut vrier que le taux de e demandes de connexions nexc`de pas un certain ratio (par exemple e pas plus de 30 connexions TCP par minutes). Les lments de la connexion (voir page 90) fournissent ladresse IP et ee le port dorigine. Ladresse IP doit pouvoir tre rsolue dans le tld in-addr.arpa, le cas e e contraire est rdhibitoire. e Ladresse IP peut tre tout simplement rfute localement, tout comme e e e le domaine (au sens du DNS). Ladresse IP peut tre galement rfute apr`s interrogation des e e e e e DNSBL ( Domain Name Services BlackList ) qui sont des bases de donnes de sites reconnus comme tant ` lorigine de spams ou connus e e a comme open mail relay . ` A la rception de lenveloppe le MTA peut demander une authenticae tion de lmetteur (login et mot de passe) du mail. e Le MTA peut galement consulter une base locale de champs From et e To refuss. e Il existe un mcanisme assez ingnieux et rcent, nomm le GreyLise e e e ting17 qui stoppe bon nombre de spams en spculant sur le fait que les e spammeurs sont des gens presss et que leur mails sont envoys en tr`s e e e grand nombre (des centaines de milliers dunits) et le plus vite pose sible. En consquence, si ltablissement du protocole SMTP ne fonce e tionne pas du premier coup, la plupart dentre eux se dcouragent et e ne ressaient pas (contrairement ` ce que le protocole SMTP prvoit). e a e Ce dispositif consiste donc ` faire patienter tout le monde (sauf peut a tre une liste dadresses de correspondants ou de domaines rputs e e e ables) et seuls ceux qui respectent le procotole ` la lettre nissent a par pouvoir transmettre leur mail, dautant plus que sils ont patient e une fois ils sont placs dans une liste dacc`s sans dlai pendant un e e e temps programmable (par exemple 24h). En pratique la connexion est coupe apr`s mission dun message derreur qui invite ` recommencer e e e a ultrieurement. e ` A la rception du corps du mail des ltres peuvent tre appliqus sur e e e len-tte pour en vrier la consistance, sur le corps du message pour e e ragir sur la prsence de tels ou tels mots clefs (de tels ltres ont en e e gnral un fonctionnement statistique bas sur lapprentissage dune e e e base de spams et dune base de non-spams et sont enrichis continuellement avec les messages indsirables) enn les pi`ces jointes sont e e extraites du courrier et examines ` laide dun dispositif de recone a naissance des virus (une base de virus doit tre mise ` jour tr`s e a e rguli`rement). e e
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 voqu au paragraphe 1.2 page 190, la relation entre e e le MTA et le DNS est troite. Sendmail a besoin du serveur de noms pour e les oprations suivantes : e
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. Dterminer quelles sont les machines susceptibles de recevoir du coure rier pour le domaine ` atteindre. a Le quatri`me point est le plus crucial. Si le DNS du domaine ` atteindre e a (une adresse est toujours mise sous la forme nom@domain ) ne dsigne e 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 spcie une liste dhtes pondrs par des e o ee prfrences, ` qui on peut envoyer du courrier. La pondration indique lordre ee a e ` suivre pour les tentatives de connexions : il faut commencer par la valeur a la plus basse. Si cette liste est explore de bout en bout sans succ`s il y a e e chec de la transmission du courrier. e

206

Courrier lectronique e Sil y a chec de la rmission, le mail est conserv un certain temps, puis e ee e est nalement rejet sil y a persistance de lchec. Le rsultat est matrialis e e e e e dans un chier nomm dead.letter e Figure X.4, Le contenu du champ RR renvoy par le DNS pourrait avoir e 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 baptise MX par le e DNS nest pas forcment localise dans le domaine pour lequel elle reoit le e e c courrier, cest mme souvent le cas pour les machines relay . Cest le cas e de la troisi`me ligne, machineC.domaineX e

4.2

Relations avec le syst`me dexploitation e

Sendmail a de multiples relations avec le syst`me dexploitation. La gure e X.5 en fait un rsum : e 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`me dexploitation e Lactivit oprationnelle de sendmail est consigne ` laide de syslog18 , e e e a ce qui explique la prsence de la ligne suivante trouve dans le chier e e /etc/syslog.conf : mail.info /var/log/maillog
18

e Chapitre III du cours de programmation Elments de serveurs

Relations avec le syst`me dexploitation e UUCP, X.400, SMTP Sont autant de moyens de propager le courrier. Ces supports peuvent cohabiter au sein dune mme conguration ; autant de e Mailer slectionns en fonction de ladresse du destinataire (cf e e sendmail.cf). /etc/mail/sendmail.cf Est le chier de conguration de sendmail qui fonctionne en tant que MTA. Sa prsence est indispensable. e La conguration standard livre est en gnrale ` adapter aux e e e a impratifs de fonctionnement du rseau local. Voir ` ce propos le parae e a graphe 5 page 212. /etc/mail/submit.cf Est le chier de conguration de sendmail en tant que MSA. Sa prsence est optionnelle si le chier prcdent indique e e e explicitement le contraire. /etc/mail/aliases est une base de synonymes. Quand sendmail reoit un c courrier, il tente de reconna le nom du destinataire dans cette base tre et si cest le cas de lui appliquer la transformation prescrite. Un certain nombre dalias sont requis par la [RFC 1123], dautres sont conseills par la [RFC 2142]. Un court extrait du-dit chier : e
# 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 au e postmaster de ce site, sendmail transforme postmaster en root , puis root en user . Si cette derni`re cha ne fait e ne 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 de ladmie nistrateur de la machine. La table des alias dun domaine est un chier stratgique quil convient de mettre ` jour soigneusement (droits e a dacc`s, utilisateurs inexistants, boucles. . .). e ` A chaque changement dans cette table ladministrateur doit fabriquer une table dacc`s rapides ( hash table ) ` laide de la commande e a sendmail -bi souvent lie ` newaliases e a /etc/mail/access Cest un chier qui regroupe des autorisations spciques dacc`s ou de rejet des mails entrants. Par exemple : e e

208

Courrier lectronique e 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 excute le MTA est connue ce qui vite que celui rejette e e 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 rcritures ee dadresses dun domaine vers un autre domaine avec plus de possibilits e dexpression que le chier des aliases. Par exemple : @MonAncienDomaine.tld %1-old@MonNouveauDomaine.tld webmaster@MonNouveauDomaine.tld wbm-new@AutreDomaine.tld Dans la premi`re ligne le %1 est remplac dynamiquement par tout e e ce qui prc`de le @ de @MonAncienDomaine.tld ce qui permettra par e e exemple deectuer un tri au moment de la dlivrance des messages, e entre ceux envoys pour le nouveau domaine et lancien. e /etc/mail/userdb Cette table, User Database permet au sendmail deffectuer une traduction de cha sur les noms des utilisateurs pour ne 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 rpertoire sont stocks les mails en attente e e dune dlivrance. Il peuvent y rester plusieurs jours (cest un param`tre e e 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 a peut tre le c e cas pour les machines relais, la section du disque dur qui supporte cette partition (ici /var) doit faire lobjet dun dimensionnement en consquence, sous peine dobliger sendmail ` refuser les mails faute de e a place disque. /var/mail/userX Chaque utilisateur de la machine locale (il peut ne pas y en avoir sur un serveur) a une bo aux lettres ( mail box ) te repre comme un chier ayant comme nom son login. Par exemple ee /var/spool/mail/root. Ce chier est mis ` jour automatiquement par le MTA local en cas a darrive de courrier. e

Relations avec le syst`me dexploitation e De mme que pour le rpertoire de le dattente, le rpertoire des bo e e e tes aux lettres des utilisateurs doit faire lobjet dune attention particuli`re e de la part de ladministrateur ; la prolifration des documents ate tachs aux courriers lectroniques est un aux contre lequel il est e e e dicile de se prmunir sauf ` agrandir perptuellement la taille de la e a e partition /var. . . ! :( ${HOME}/.forward Avant dtre nalement dlivr dans la bo aux lettres e e e te de lutilisateurs, sendmail lit le contenu de ce chier, ${HOME} tant le e rpertoire racine des chiers de lutilisateur en question. e Le chier .forward est la base personnelle dalias pour chaque utilisateur, a permet de renvoyer son courrier vers dautres sites, voire aussi c deectuer des transformations avant de stocker les mails (procmail). Si le .forward contient la cha suivante : moi@ailleurs.tld Tous les ne courriers envoy ` cette utilisateurs sont renvoys ` ladresse indique. ea e a e Ou encore : "|exec /usr/local/bin/procmail" Qui permet dinvoquer lusage du programme procmail, celui-ci est un tr`s puissant ltre qui permet de faire un tri des courriers lectroniques e e avec des expressions rguli`res (indispensable pour grer de multiples e e e abonnements ` des mailing-lists ). Par exemple, avec la conguration a virtusertable ci-dessus, pour forcer la dlivrance des mails adresss e e ` @MonAncienDomaine.tld dans un chier spcial plutt que la boite a e o par dfaut, on pourrait crire un chier .procmailrc de conguration e e contenant les lignes suivantes : :0 H: * ^To[ :]+.*-old@MonNouveauDomaine.tld ${HOME}/Mail/Rougnes Socket locale Sendmail peut communiquer avec des programmes extrieurs e par le biais dune socket locale (UNIX). Le dialogue est facilit par une e biblioth`que nomme MILTER19 lie ` sendmail lors de sa compilation. e e e a Lide est quil est plus intressant de refuser ventuellement un mail e e e d`s que les premiers lments du protocole SMTP (ou ultrieurement en e ee e examinant le corps du message) sont connus, plutt que dattendre que o la connexion soit close et que le mail soit dlivr. De ce fait, lmetteur, e e e quel quil soit (honnte utilisateur ou spammeur) sera immdiatement e e prvenu que son mail est refus et pourra agir en consquence. e e e 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 lectronique e Outil externe de dlivrance Le message prt ` tre dlivr est con par e e ae e e e sendmail aux bons soins dun programme extrieur. Si la dlivrance e e seectue dans une boite aux lettres unix (un chier au format mailbox qui porte comme nom le login de lutilisateur et est situ gnralement e e e dans le rpertoire /var/mail/), ce programme se nomme local.mail e en standard. Il peut tre remplac par dautres, notamment par le e e programme procmail dj` cit, si on souhaite eectuer un ltrage ea e supplmentaire ` ce niveau du traitement, par exemple pour mettre e a dans une boite aux lettres spciale les mails considrs comme tant du e ee e spam en laissant ` lutilisateur le soin de les dtruire par lui-mme. a e e Enn on peut remarquer quaucun signal nest prvu pour indiquer ` e 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 arrter puis le e 23 relancer manuellement .

4.3

Le cas de POP

POP est lacronyme de Post Oce Protocol , il permet lacc`s ` un e a serveur de courrier depuis des clients PC sous Windows, voire mme des e stations unix distantes, par exemple via ppp, qui ne sont pas congures e pour faire un trac SMTP entrant. POP dans sa version 3 est dni par la e [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 lgions sur les PCs et sur les stations de travail sous e 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`me dexploitation e POP est un protocole tr`s simple qui fonctionne parfaitement mais qui e nest pas dnu de dfauts : e e e 1. Lauthentication (login/password) est bien souvent change en e e clair sur le rseau e 2. Sur larchitecture Unix, lutilisateur doit avoir un compte sur la machine serveur (Une base de donnes des utilisateurs est toutefois pose sible) 3. Les messages doivent tre rcuprs sur le poste client pour tre manie e ee e puls (en POP3 un double peut rester sur le serveur) e 4. La boite aux lettres ne peut tre consulte que par un seul client ` la e e a fois Ces points deviennent vite rdhibitoires quand le poste client doit accder e e au serveur au travers dun rseau non sr, et surtout lorsque le dtenteur de e u e la boite aux lettres veut consulter ses mails depuis des postes dirents. Ce e cas de gure est de plus la ralit de toute personne qui se dplace et souhaite e e e un contact mail permanent avec ses correspondants. Cest pourquoi dautres solutions se sont dveloppes et sont de plus en e e plus utilises : les messageries accessibles via un browser web (webmail), e donc qui utilisent comme support le protocole HTTP (voir page 327), ou un remplaant du procole POP, le protocole IMAP ! c

211

4.4

Le cas de IMAP

Bien que largement dploy que depuis quelques annes, le protocole e e e IMAP Internet Message Access Protocol a t dvelopp ` luniveree e ea sit de Stanford en 1986. Cest actuellement la version 4rev1 qui est utilise, e e dnie dans la [RFC 3501]. e Larchitecture prsente gure X.06 reste valable, pratiquement il sut e e dy remplacer le mot POP par IMAP25 ! Les fonctionnalits sont plus riches et surtout pallient aux inconvnients e e lists pour POP. En clair, les points ngatifs lists pour POP sont tous rgls. e e e e e Imap est conu pour pouvoir accder ` ses boites aux lettres depuis de mulc e a tiples machines, nimporte o` sur le rseau, alors que POP est plus adapt ` u e ea une machine unique. Voici ses objectifs principaux : 1. Etre compatible avec les standards, MIME par exemple 2. Permettre lacc`s et la gestion des mails depuis plus dune machine e 3. Fournir un mode de fonctionnement en-ligne et hors-ligne 4. Supporter les acc`s concourrants aux mmes boites aux lettres e e 5. Etre indpendant du stockage des mails (chiers ou base de donnes, e e par exemple)
25

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

212

Courrier lectronique e 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`gles de e rcritures (gure X.05 page 206) par dfaut regroupes dans les chiers ee e e /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`s complet et puissant sut pour gnrer les congurations ci-dessus, apr`s e e e e lcriture dun chier de requtes de quelques lignes. M4 gn`re ensuite les e e e e chiers attendus ` partir de ces requtes, et dun mod`le ( template ) a e e install avec le programme sendmail. e Il faut noter quun certain nombre dadministrateurs syst`me, forms ` e e a la vieille cole , aiment bien conserver la ma e trise totale de ce quils produisent et prf`rent donc crire eux-mmes manuellement leurs r`gles, ces ee e e e macros ne leur sont donc pas destines ! e

5.1

Conguration ` laide de M4 a

Le point dentre pour utiliser cet outil est une documentation livre avec e e la distribution du programme sendmail et nomme : e <prfixe dinstallation>/cf/README e Considrons la situation rseau de la gure X.07. Le courrier au e e dpart de la station, soumis par exemple au MSA local, doit tre rout e e e systmatiquement vers une machine nomme mailhub.mondomain.fr, et qui e e concentre tout le trac local sortant, do` dailleurs son nom de mailhub . u Celle-ci est cense savoir router le mail quelle reoit, mais ce nest pas notre e c proccupation ici. e
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 tre : e

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 de cette mani`re : e e

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

Pour gnrer en nal le chier attendu, dont le nombre de lignes exc`dent e e e 1400 ! Il faut noter que le MSA se congurent de mani`re similaire, ` partir e a de son propre chier de conguration. Ligne 1 Cest la dnition dun canal de sortie pour m4 (cf man m4). e Ligne 2 Cest une tiquette ( tag ) insre dans le chier gnr et qui e ee e ee servira ` lidentier, par exemple avec la commande ident si ltiquette a e est un identiant de rcs ou cvs. Remarque : dnl est un mot clef de m4, au mme titre que divert, et e qui signie quon peut ignorer (discard) tous les caract`res jusquau e prochain retour ` la ligne (nl). a Ligne 3 Cest un identiant du syst`me dexploitation pour que m4 puisse e faire les choix adapts (choix des chemins standards par exemple). e Ligne 4 Dnition de la banni`re de HELO du protocole SMTP. $j est une e e variable qui contient le nom canonique (FQDN - Voir page 169)) de la machine hte. La banni`re de HELO smtp de la station ressemblera ` o e a a : c
220 stationYXZ.mondomain.fr ESMTP --- STATION LAMBDA --- (date du jour)

Ligne 6 Ajout systmatique du nom de domaine, mme et surtout pour les e e courriers locaux (donc dans le domaine local par dfaut). e Ligne 7 et 8 Ces deux lignes entrainent la rcriture des adresses ee From de telle sorte quelles se prsentent toujours sous la e forme <untel@mondomain.fr> au lieu de leur forme par dfaut e <untel@station.mondomain.fr> qui est nuisible au retour du courrier car la machine station.mondomain.fr nest tr`s vraisemblablee ment pas atteignable directement depuis le rseau global sur son port e 25.

214

Courrier lectronique e Ligne 10 Tout le mail local doit tre envoy ` la machine e e a mailhub.mondomain.fr. Ligne 11 Tout le mail autre que local doit tre envoy ` la machine e e a mailhub.mondomain.fr. Ligne 13 Normalement inutile dans le cas prsent (pas de delivery sur e cette machine). Pour conclure, sendmail comme tous les outils, volue plusieurs fois e par an. Si ` chaque version il est ncessaire de reconstruire manuellement a e son chier sendmail.cf il est probable que votre emploi du temps va tre e srieusement amput dun temps prcieux. . .Mieux vaut avoir juste ` taper e e e a make dans le bon rpertoire pour reconstruire un chier de conguration e tout beau tout propre !

5.2

Conguration manuelle

Cette section est une extraction libre et incompl`te du parae graphe 5 du document intitul Sendmail Installation and Operae tion Guide , disponible dans toute distribution de la V8. On peut galement trouver ce document dans la section System Managers Manual e (SMM) des syst`mes BSD27 . e Le chier de conguration (sendmail.cf est organis comme une srie de e e lignes, le premier caract`re de chacune delles en prcise le type. Une ligne e e vide ou qui dbute par un # est ignore (commentaire), une ligne qui dbute e e e par un espace ou une tabulation est la continuation de la prcdente. e e 5.2.1 R`gles de rcriture e ee

Les r`gles de rcritures sont reprables comme ces lignes qui dmarrent e ee e e par un S (dbut dun paquet de r`gles) ou un par un R (simple r`gle). e e e Les paquets de r`gles (organisation densemble gure X.7 ) ont comme e but essentiel danalyser puis de prendre les bonnes dcisions en fonction des e adresses trouves dans len-tte. Cest une dmarche purement formelle. e e e Ces r`gles utilisent une syntaxe dense qui rebute gnralement les admie e e nistrateurs. Il faut imaginer quelles sont intgralement analyses chaque fois e e que le programme sendmail est invoqu, cest ` dire en gros pour chaque e a e-mail entrant ou sortant. Elles doivent donc tre faciles ` analyser, mme e a e par un cpu de modeste performance (ou tr`s charg, ce qui revient nalement e e au mme). e Lensemble fonctionne comme un syst`me de production, cest ` dire e a qui consomme des r`gles lues squentiellement et les applique ` un jeux de e e a donnes initiales, ici une ou plusieurs adresses lectroniques. e e e La partie gauche (ou lhs28 ) sert de dclencheur ( pattern matching )
pour FreeBSD, NetBSD ou OpenBSD a se trouve dans le rpertoire /usr/share/c e doc/smm/08.sendmailop/ 28 left hand side
27

Conguration du Sendmail pour une r`gle. e La partie droite (ou rhs29 ) est dclenche si le motif de la partie gauche est e e reconnu dans le ux de donnes. Le rsultat produit, sil existe, est reinject e e e dans le syst`me de production et ce jusqu` puisement des possibilits. e ae e La gure X.7 donne un aperu du fonctionnement de lautomate, les c chires (0,1,2,3,4) sont autant de ruleset , comprendre des paquets de r`gles qui sont regroupes ensembles parcequelles traitent dun objectif come e mun.

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`gles de rcriture e ee Les r`gles sont numrotes, le premier chire dit ` quel paquet elles ape e e a partiennent. Le paquet de r`gles 0 sert essentiellement ` dterminer le mailer cest e a e ` dire le moyen denvoyer le courrier (SMTP, ESMTP, UUCP. . .). a Les paquets de r`gles 1 et 2 sont appliqus respectivement ` len-tte des e e a e messages qui sortent ( send ) ou qui entrent ( receive ). Le paquet de r`gles 3 est appliqu systmatiquement ` toutes les adresses. e e e a Le paquet de r`gles 4 est appliqu ` toutes les adresses dans le message, e ea typiquement pour passer dune forme interne ` une forme externe. a Le paquet de r`gles 5, non reprsent sur lautomate, sert ` traiter les e e e a adresses locales apr`s que les aliases aient t appliqus. e ee e Les paquets de r`gles sont reprs par la lettre S, qui en balise le nom, e ee comme dans :
###################################### ### Ruleset 0 -- Parse Address ### ###################################### Sparse=0

Quant aux r`gles, elles dmarrent toutes avec la lettre R, comme dans : e e
29

right hand side

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

Courrier lectronique e
initial parsing special case error msgs handle local hacks final parsing

Deux remarques simposent : 1. Chaque ligne forme une r`gle, sur le mod`le : e e Rlhs rhs commentaire 2. Le sparateur de champ entre les trois partie de ces r`gles est la tabue e lation (une au minimum) Ladresse postmaster@mondomain.fr, par exemple, quand elle se prsente devant le paquet de r`gles 0 qui dmarre ci-dessus, a t mise sous e e e ee une forme canonique par dautres r`gles appliques pralablement (notament e e e 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`gles (lhs) pour dterminer celles qui peuvent e e tre dclenches. e e e Dans la partie gauche $ sapplique ` toute suite de tokens, mme vide. a e Donc la premi`re ligne convient. La deuxi`me ne le pourrait pas car la cha e e ne postmaster prc`de le caract`re < et le @ est suivi de mone e e domain . fr . . La troisi`me et la quatri`me r`gle sont galement dclenchables mais e e e e e prsentement lordre dapparition est galement lordre de dclenchement, e e e cette possiblit sera donc examine ventuellement plus tard. e e e La partie droite de la premi`re r`gle commence par $ : $>Parse0 ce qui e e signie lappel dun autre paquet de r`gles que lon pourra trouver plus loin e 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 schma en tte quand on dbogue les r`gles : avec e e e e loption -bt de sendmail on peut suivre la progression de la transformation, r`gle par r`gle. e e
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 lectronique e

Bibliographie

Pour en savoir davantage, on pourra consulter les bons auteurs suivants : Eric Allman Sendmail Installation and Operation Guide document au format PostScript jointe ` toutes les distributions de la V8.xx. a 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 lectronique e

Chapitre XI Instrumentalisation de rseaux avec SNMP e

1 Ncessit dun outil e e

La majeure partie des activits informatiques dpendent du bon fonce e tionnement des rseaux et des services associs. Leurs nombres et leur come e plexit ne cessent de saccro e tre, mais bien souvent le personnel responsable de lvolution et du bon fonctionnement de lensemble ne voit pas ses eectifs e humains voluer dans le mme sens, du moins aussi rapidement que le parc e e de machines ` administrer ! a Or, le bon fonctionnement dun grand rseau ne peut dpendre pour seule e e composante que de leort intellectuel dindividus ou de groupe dindividus, fussent-ils comptents et dvous. Il faut des outils ! e e e

1.1

Problmatique de lISO e

LISO, sest pench sur la question et a segment le probl`me de la gestion e e e technique de rseau en cinq points : e La gestion des pannes (Fault management) Il sagit de dtecter les e pannes, de les localiser et dy remdier en minimisant limpact de la e perte de fonctionnalit sur le reste du syst`me dinformation. e e La panne nest pas une erreur, mais un grand nombre derreurs peuvent conduire ` dclarer une panne. Par exemple la croissance anormale du a e nombre de collisions sur un rseau, lengorgement dun disque. . . e La comptabilisation de lusage des ressources (Accounting management) Il sagit darchiver et de mettre en ordre tous les compteurs gnrs par les applicatifs et les couches rseaux an de pouvoir tirer e ee e un enseignement de lusage des ressources. Laspect condentiel de ces donnes doit tre pris en compte. e e La gestion des congurations (Conguration and name management) Il sagit de la mise en uvre et de la conguration de tous les quipements e qui inter-agissent sur le rseau. e

222

Gestion de rseaux avec SNMP e Laudit des performances (Performance management) Il sagit davoir une approche quantitative sur le fonctionnement du rseau an de poue voir rpondre ` des questions aussi basiques que : e a 1. 2. 3. 4. 5. Quel est le niveau actuel dutilisation ? Il y a t-il un (des) trac(s) excessif(s) ? Le dbit nominal est-il rduit ` une valeur inacceptable ? e e a O` sont les goulots dtranglement ? u e Quelle est lvolution du temps de rponse ? e e

La gestion de la scurit (Security management) Il sagit de maintenir e e cohrent et eectif lensemble des protections sur les autorisations e dacc`s et donnes sensibles collectes. e e e Les logs (syslog) sont un point important de la gestion de la scurit. e e En conclusion, les buts dune gestion technique ecace dun rseau sont e multiples : il sagit dorir aux usagers un service de qualit, de permettre e les volutions du syst`me dinformation en y incluant de nouvelles fonctione e nalits, doptimiser lusage des ressources et de minimiser les cots dexploie u tation ou dinvestissement.

1.2

Syst`me de gestion de rseau e e

Un syst`me de gestion de rseau (Network Management System) est une e e collection doutils pour la surveillance et le contrle an de permettre ` un o a oprateur deectuer la plupart des oprations de gestion depuis un interface e e le plus simple et ergonomique possible ! Cest un ensemble de logiciels (Network Management Entity) associs e ventuellement ` des matriels spciques, qui sont dploys sur tous les e a e e e e composants du syst`me dinformation. e Un NMS est donc conu pour donner une image unie du rseau, quelle c e e que soit son tendue et son htrognit. Le logiciel utilis pour visualiser e ee e e e e limage du rseau est un NMA (Network Management Application). e Un NME : Collecte des donnes sur lactivit rseau e e e Conserve ces donnes dans une base e Rpond aux requtes du NMA, notamment sur les points suivants : e e 1. Transmission des donnes collectes e e 2. Changement dun param`tre de conguration e 3. Fourniture de statut de composants logiciels ou matriels e 4. Gnration de tests e e Envoi des messages dalerte (trap) en cas de dtection dvnements e e e exceptionnels. Au moins un nud du rseau est dsign comme tant le manager, et e e e e supportant le NMA. Cette architecture nest pas ncessairement centralis, e e la supervision du rseau peut seectuer par secteurs. e

Ncessit dun outil e e

223

1.3

SNMP Simple Network Management Protocol

SNMP est un terme un peu gnrique qui dsigne ` la fois un protocole e e e a rseau applicatif bien prcis, une collection de spcications pour le manae e e gement de rseau et la dnition de structures de donnes ainsi que leurs e e e concepts associs. e SNMP est n en 1988 de la ncessit de disposer dun outil de supervision e e e du rseau d`s lors que celui-ci comporte un grand nombre dhtes qui intere e o agissent, stations, serveurs, lments de routage ou de commutation ou encore ee boites noires. Leur nombre grandissant sur les LANs (des machines en clusters par exemples) implique davoir un outil qui permette dexpliquer le rseau. e Ce besoin est moins vident quand tout va bien, mais il sut parfois dun e simple petit grain de sable. . . Dans ces moments l`, disposer dun outil qui a dlivre une information de synth`se est indispensable ! e e Les logs, au sens de syslog (paragraphe 3.2 page 316) , mme concentrs, e e ltrs, et tris ne dlivrent une information parfois trop verbeuse et en e e e tout cas structure diremment selon les applications ou les noyaux. Les e e vnements rseaux y sont le plus souvent absents, sauf dans le cas tr`s pare e e e 1 ticulier de dmons qui surveillent le rseau, arpwatch en est un exemple. e e Le tri par niveau de criticit ne retire rien ou presque au fait que cest une e information brute quil faut ltrer pour en extraire linformation pertinente. Larchitecture dun rseau gr avec SNMP comporte essentiellement e ee deux entits : le manager et lagent, ou encore le client et le serveur. Le e client (manager) interroge le serveur pour rcolter de linformation ou cone gurer une valeur, le serveur (agent) est capable de prvenir le client en cas e dvnements exceptionnels (traps). e e Enn, nimporte quelle machine munie dune stack IP est susceptible de supporter SNMP, depuis le calepin lectronique, en passant par la borne wi e et jusquau mainframe. En quelques mots, SNMP permet : De cartographier le rseau e De fournir un panel tr`s complet de rsultats de mesures pour chaque e e hte o De mesurer en temps rel la consommation de ressources dune applie cation De signaler les dysfonctionnements De changer certains param`tres rseaux de fonctionnement e e Avantages : Protocole est simple et facile dutilisation Permet une gestion centralise dun parc e Dispose dun mod`le extensible e Est indpendant de larchitecture matrielle e e

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

224
Station de management NMA SNMP MIBs

Gestion de rseaux avec SNMP e

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 htes. Le couple (echo request,echo reply) est le plus o utilis pour maintenir un tat des machines accessibles. e e Le point de dpart est SGMP ( Simple Gateway Monitoring Protocol e RFC 1028 de novembre 1987) mais trop orient sur la gestion des routeurs. e Du cot de lOSI dautres tentatives avec CMIS et CMIP ( Common Mae nagement Information Service & Protocol ) SNMP est sorti en 1988, comme une version amliore de SGMP. Les e e RFCs fondatrices sont les 1155, 1156 et 1157 conserves actuellement au e rang dhistoriques bien que tous les quipements soient thoriquement encore e e compatibles SNMPv1 (mme sils rpondent ` un niveau de version SNMP e e a plus rcent, cest ` dire 2 ou 3). e a

1.5

Vocabulaire et architecture

Un syst`me dexploitation peut tre vu comme une vaste collection de e e compteurs et dhorloges auxquels SNMP nous permet daccder ` distance e a pour les lire et les modier (certaines, sous rserve dy avoir acc`s). e e An que les agents et les managers soient inter-oprables les variables e sont collectionnes selon une reprsentation arborescente tr`s structure et e e e e standardise, ce sont les MIBs ( Management Information Base ). On les e retrouve partout o` SNMP est support. Ainsi, une mme information se u e e nomme de la mme mani`re quelle que soit limplmentation de SNMP et e e e indpendamment de sa valeur qui est fonction du contexte. Cest donc tr`s e e commode pour automatiser les traitements (scripts de collecte et de surveillance. . .) dans un rseau qui est htrog`ne la plupart du temps ! e ee e

Ncessit dun outil e e Les feuilles de cet arbre sont les variables et on y acc`de en connaissant le e chemin ` priori depuis la racine, un peu ` la mani`re dun syst`me de chiers, a a e e sauf quici les chemins sont codis ` lavance. e a Actuellement cest la MIB-2 qui est la plus rpandue (RFC 1213), elle e rpond parfaitement aux besoins lementaires. Si un appareil ou un syst`me e e e a des besoins spciques il est toujours possible dajouter des branches au e tronc commun, un embranchement est prvu pour cela, on parle alors dune e extension vendor . Tous les vendeurs dhtes rseaux prvoient des MIBs pour leurs o e e quipements ( mibs vendors donc), d`s lors quils sont accessibles via ip e e (routeurs, commutateurs, ponts, htes, imprimantes, boites noires diverses) o mme si celle-ci nest pas montre ` lutilisateur nal. Telle borne wi dun e e a cl`bre constructeur informatique ` la pomme , utilise SNMP pour se ee a congurer mais lutilisateur ne le voit pas, cest masqu par un interface e utilisateur convivial. La gure XI.01 prsente la relation entre les deux entits logicielles qui e e dans le cas de SNMP se nomment : Agent SNMP, ou NME (le serveur) Cest un logiciel qui sexcute sur e lappareil que lon souhaite administrer ` distance. Il rpond aux a e requtes du gestionnaire, et gn`re des alarmes (traps) si besoin est. e e e La conguration dun agent est en gnral assez simple (par rapport ` e e a celle dun logiciel Manager). Manager NMA (le client) Cest le logiciel qui sexcute sur la station e dadministration. Sa conguration est forcmement plus dlicate que e e celle de lagent parcequil ncessite une adaptation au rseau local qui e e 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 tre aussi complet, loutil e tkined est dj` tr`s satisfaisant pour lessentiel des besoins (voir la ea e recopie dcran page 247). e Sonde RMON (alternative de serveur) La gure 01 est en fait incompl`te dans le cadre dune architecture de supervision globale de e rseau : si chaque agent sur chaque hte peut rpondre individuellee o e ment sur les vnements rseau le concernant, il manque un maillon e e e plus global qui fasse la supervision du rseau en lui-mme, le vritable e e e networking management . Cet lment existe, cest ce quon appelle ee une sonde RMON, ou encore Remote Monitoring . Cest une entit logicielle, comme un agent SNMP. Elle sappuie sur e une extension de la MIB de base. On la trouve principalement sur les lments de commutation ou de routage, l` o` se concentre le trac ee a u rseau, mais on peut la trouver sur un hte galement, par exemple sur e o e un serveur critique. LOpen Source nous en fournit un tr`s bel exemple avec le logiciel e

225

226 ntop2 .

Gestion de rseaux avec SNMP e

La reprsentation des donnes dans les variables nest pas laisse au hae e e sard des besoins des dveloppeurs mais est structure selon une spcication e e e appell SMI Structure of Management Information , dnie par la e e RFC 1155, qui dit par exemple quun entier positif va de 0 ` 232 1. Pour a tre indpendant du formalisme local de la plateforme (problmatique de la e e e couche 6 OSI).

1.6

Direntes versions e

Enn cet change de donnes prend place dans un protocol rseau qui e e e est dni par les RFC 1155 ` 1157, nomm Simple Network Management e a e 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 supporte e pour des raison historiques , la v2 est la plus couramment supporte par les e appareillages. Elle pose quelques soucis que tente de rgler la v3 (notamment e la scurisation de lauthentication). e La premi`re version sourait dun certain nombre de lacunes au niveau du e protocole et de la scurit que la deuxi`me version (SNMPv2c Communitye e e based SNMPv2 ) dnie par les RFC 1901 ` 1908, tente de combler. Rien e a nest malheureusement fait cot scurit dans cette deuxi`me version mais e e e e des amliorations sont apportes aux mibs standards et au protocole. e e Plus rcemment un nouveau cadre de travail a t dvelopp, qui safe ee e e franchit compl`tement de la notion de communaut , obstacle ` lusage e e a de SNMP en criture, et qui introduit des amliorations signicatives de la e e scurit (RFC 3411 ` 3418). e e a Linertie des habitudes retarde son dploiement gnralis, ainsi que la e e e e ncessit de continuer ` grer des appareils ne le supportant pas (encore). e e a e 1.6.1 Trois composantes pour SNMP

Dapr`s la RFC 1213 (MIB II) le cadre de travail de SNMP repose sur e trois composantes : SMI dnit les types dobjets utiliss dans les mibs. Cest une sorte de e e mta mod`le de donnes. Par exemple pour dnir une adresse physique e e e e (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/

Ncessit dun outil e e La MIB dcrit une collection structure des ressources ` grer. Une rese e a e source ` grer est reprsente par un objet. a e e e Le protocole SNMP qui rgit le contenu des dialogues clients/serveurs e cest ` dire linterrogation des donnes structures par la MIB. a e e 1.6.2 Conclusion

227

le protocole SNMP est simple dans sa conception ce qui permet son dploiement sur de tr`s nombreux appareils htrog`nes mis en rseau. e e ee e e En pratique la situation est moins simple du fait de la coexistence de 3 versions des MIB non toutes supportes par tous les htes du rseau. e o e La conguration de la station dadministration demande du temps, une connaissance tr`s approfondie de la topologie du rseau ` administrer, et e e a beaucoup de comptences techniques. Cest un travail ` haute valeur ajoute ! e a e

228

Gestion de rseaux avec SNMP e

SMI Structure of Management Information

La RFC 1155 fondatrice pose le cadre de travail ` lintrieur duquel on a e peut btir les MIBs. En eet, la SMI prcises les types de donnes et les a e e ressources qui peuvent tre spcies dans une MIB. e e e Les donnes ont t prvues simples, le tableau (par exemple pour e ee e reprsenter un ensemble de connexions tcp tcpConnTable) et la liste (les e lments dun quintuplet tcp tcpConnEntry) sont les formes les plus comee plexes prvues. e Ces structures de donnes sont remplies avec les 5 types suivants : e networkaddress Il sagit dune zone pouvant contenir une adresse rseau, e avec comme format possible IpAddress (ipv4 32 bits). counter Cest un compteur qui prend sa valeur maxi ` 232 1 (on reconnait a un entier 32 bits non sign) et qui ne peut pas tre dcrment. Quand e e e e e il atteind sa valeur maxi il repasse ` 0. a gauge Cest un compteur, qui a la mme valeur maximale que le prcdent e e e mais qui au contraire peut tre dcrment. Par contre il ne repasse e e e e pas automatiquement ` 0 en cas de valeur maximale atteinte. a timeticks Le nombre de secondes coules depuis epoch, cest ` dire le 1er e e a janvier 1970. opaque Cest un ux doctets banaliss qui permet dencoder tout ce qui ne e rel`ve pas des types prcdents, une sorte de fourre-tout en quelque e e e sorte. . . Toutes les ressources auxquelles on souhaite accder dcrites dans un e e document qui est une MIB.

MIB Management Information Base

Les MIBs sont des chiers au format ascii qui dcrivent dans le dtail e e chacune des ressources ` quantier. Ces ressources sont des lments simples a ee (scalaire ou tableaux ` deux dimensions). Chaque unit de description se a e nomme un objet (sans aucun rapport avec la programmation du mme e nom). Une MIB est une collection structure de tous ces objets. Un mme e e objet est accessible de la mme mani`re partout sur le rseau. e e e Le propos dune MIB peut tre celui de respecter un standard ouvert, e dcrit alors par une RFC et distribu librement, ou dtre spcique pour un e e e e type particulier dappareil et de constructeur ( mibs vendor ). Sa diusion est alors ` linitiative de son auteur. a Le contenu dune MIB est toujours dcrit ` laide dun langage formel e a 3 e e e e e nomm ASN.1 utilis gnralement pour dnir des structures de donnes e
3

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

MIB Management Information Base applicatives complexes (couche 6 du mod`le de lOSI) et qui est indpendant e e de tout langage de programmation. Un extrait de la MIB II (RFC 1213) concernant le dbut de la description e de lobjet tcpConnTable, ` savoir la table des connexions tcp, celle l` mme a a e 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 dbut de la dnition e e 2. (SYNTAX) La syntaxe dusage. Ici une liste dobjets tcpConnEntry. On y reconna sans peine les lments du quintuplet vus en cours TCP. tra ee 3. (ACCESS) Lacc`s (lecture, criture, lecture-criture, pas accessible). Ici e e e On ne peut ni lire ni crire dans cet objet. e 4. (STATUS) Ltat de lobjet, valeur ` prendre dans obligatoire e a (MANDATORY), obsol`te ou optionnel. e 5. (DESCRIPTION) Un texte qui dcrit ce que reprsente lobjet. e e Les lignes qui dbutent par un sont des commentaires. e Enn on peut remarquer que ce bloc de texte se termine par ::= { tcp 13 } qui signie que cet objet est le treizi`me ls de lobjet p`re e e tcp. Tous les objets de toutes les MIBs (propritaires ou non) sont organiss e e 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 rseaux avec SNMP e

3.1

OID Objet Identier

Le nommage des objets utilise une reprsentation arborescente dont la e racine est ge mais qui est extensible ` volont. Le nommage dun objet e a e passe par la dnition (en ASN.1) dun Objet IDentier ou OID, qui e peut sapparenter au path dun chier. Ce chemin peut sexprimer de mani`re symbolique, par exemple e .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 ou encore dans une reprsentation numrique absolument quivalente .1.3.6.1.2.1.1.1 e e e En pratique on pourra le plus frquemment faire rfrence seulement ` e ee a sysDescr.04 . La racine de larbre est ` gauche, contrairement, par exemple, a au syst`me de nommage du DNS qui place la racine ` droite. e a En eet un OID est une squence dentiers, parcours dans larbre de la e racine jusqu` la feuille terminale. Chaque noeud travers est tiquett par a e e e un nombre et un bref texte descriptif. Bien entendu lunicit de ltiquettage e e ` un niveau donn de larbre est primordial pour son bon fonctionnement. a e La racine nest pas nomme, do` le point (.) ` gauche des deux critures e u a e qui prc`dent. e e ` A ce jour deux entits se partagent les trois noeuds du premier niveau de e 5 larbre : lISO et le CCITT6 , le troisi`me noeud sexplique par une entit e e mixte des deux et nomme joint-iso-ccitt . e
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 prvu pour dautres organisations, e lune delle est le dpartement de la dfense US (dod). La RFC 1155 pose e e le fait quun sous arbre du dod est allou ` lIAB (Internet Activity Board), ea sans doute une trace des origines militaires de la pile Arpa. Et voila pourquoi les OIDs standards sont placs sous le noeud nomm e e
Notez la prsence du 0 en n de cha qui ne fait pas partie du nommage mais e ne est un artice ` linterrogation pour indiquer quil sagit dune feuille de larbre et non par a 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 prxe le plus commun est .1.3.6.1.2.1, indices des e noeuds p`res traverss ` partir de la racine ! e e a Directory(1) Rserv pour lOSI e e mgmt(2) Ladministration de ce sous arbre est dlgu ` lIANA7 et est donc ee ea rgit par des RFCs ! e Experimental(3) Utilis pour identier des objets utiliss pour des e e dploiements exprimentaux sur lInternet. Dlgu ` lIANA. e e ee ea Private(4) Comme son nom lindique ce sous arbre est celui des dlgations ee prives. Le sous arbre enterprise(1) permet aux entreprises dy placer e leurs MIBs, apr`s stre enregistres aupr`s de lIANA. e e e e ...

231

3.2

Types de donnes lmentaires e ee

Le type des objets utiliss dans les MIBs est limit ` un sous ensemble des e ea types disponibles dans ASN.1, mais susant pour exprimer les compteurs, les tables et les identicateurs que lon trouve dans la mmoire dun syst`me e e dexploitation. INTEGER De nombreux compteurs du syst`me dexploitation utilisent un tel e type, comme par exemple ceux des statistiques extraites du noyau par la commande netstat -s -p ip. OCTETS STRINGS Pour dnir une cha de caract`res comme une suite de e ne e 0 ou plus octets de 8 bits. NULL Pour dire quil ny a pas de valeur. OBJECT IDENTIFIER Pour dnir les objets (OID). e 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 donnes puissent ressembler ` ceux de tel ou tel e a langage de programmation, leur reprsentation interne di`re tr`s certainee e e 8 ment puisquelle respecte les Basic Encoding Rules , ou BER, an dtre e abolument portables sur tout type de plateforme. BER est une mthode dene codage des valeurs pour tous les types dnis par ASN.1, sous forme dune e cha doctets et base sur lusage dun triplet de valeurs (type, longueur, ne e valeur) ou TLV. Ainsi par exemple les cha nes de caract`res ne sont pas termines par e e un caract`re null (Ascii 0) comme dans le langage C mais sont encodes e e directement avec leur longueur.
7 8

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

232

Gestion de rseaux avec SNMP e

La MIB-2

la mib standard la plus courante est la MIB-2 dnie dans la RFC 1213, e cest un sur-ensemble de la mib dorigine (MIB-I) dnie dans la RFC 1156. e Cette mib regroupe les compteurs les plus courants associs ` une pile Arpa et e a dautres comme ceux associs ` la technologie Token-Ring, FDDI, Microsoft e a Lan Manager, DECnet, pour information. La racine du sous-arbre concerne est clairement mgmt, cest ` dire e a .1.3.6.1.2 et le noeud concern est mib-2(1) qui est lOID dni ligne e e 15. Puis viennent les 10 sous arbres dcrits plus avant dans cette mib : e system(1) Le groupe system fournit des informations dordre gnral sur le e e system lui-mme, comme le-mail dun contact, la valeur de l uptime e ou encore la location physique de lappareil. interfaces(2) Le groupe interfaces regroupe toutes les informations sur les interfaces physiques ou virtuels prsents, leur type, le fabricant, leur e caractristiques et enn les statistiques dusage. e 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 tre extraite par la come mande arp -an. ip(4) Le groupe ip contient toutes informations relatives ` ce protocole a (adresse, netmask), notamment la table de routage et tous les compteurs auxquels on peut accder ` laide de netstat -s -p ip. e a icmp(5) Le groupe icmp contient toutes les informations relatives ` ce proa tocole. Le compteur du nombre d echo request est par exemple accessible, tout comme il peut ltre avec un netstat -s -p icmp. e Tous les messages sont associs ` deux compteurs. e a tcp(6) Le groupe tcp contient toutes les informations relatives ` ce protoa cole, par exemple celles que lon peut obtenir ` laide dun netstat -s a -p tcp plus dautres comme la liste des connexions en cours avec leur tat. e udp(7) Le groupe udp regroupe toutes les informations relative ` ce proa tocole (netstat -s p -udp). G`re galement la liste des applications e e 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 dj` ea dnies dans le Interfaces(2). mais selon dautres crit`res, comme e e par exemple les protocoles supports. e snmp(11) Ce groupe donne des informations sur limplmentation et e lexcution de SNMP lui-mme, cest ` dire le nombre de message ene e a trants, sortants, la rpartition du type de requtes reues, mises. e e c e

La MIB-2 Voici un extrait du dbut de cette mib : e

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 rseaux avec SNMP e

Protocole SNMP

le protocole SNMP est du type client/serveur classique. Un vocabulaire spcique : le serveur est nomm Agent SNMP alors que le client est un e e Manager ou encore Network Management Software (NMS). Le serveur (agent) coute les requtes du client (manager) sur le port 161 e e (UDP) et peut lui envoyer des messages dexception (trap) sur son port 162. Le choix du transport UDP est justi par le trac de petits datagrammes e (la RFC 1157 An implementation of this protocol need not accept messages whose length exceeds 484 octets . Les besoins ont volu mais ce choix initial e e perdure. Aux parties applicatives la tche de faire le travail dune couche de a transport si besoin est (gestion dun time-out et de la remission des e datagrammes manquants). Le client (manager), interroge ` son rythme les agents sur leur port 161 et a coute sur le port 162 (UDP) les ventuels messages dexceptions envoys par e e e ces mmes agents. Il faut noter que le protocole permet non seulement la lece ture de variables mais aussi leur modication, ce qui pose des probl`mes daue thentication et de condentialit, non rsolus avec SNMPv1 et SNMPv2. e e En eet, ce qui fait oce de mcanisme dauthentication est une cha de e ne caract`res qui circule en clair sur le rseau, cest la fameuse commue e naut dont la valeur par dfaut sur les quipement est traditionnellement e e e public . La plupart du temps on se borne donc ` laspect read only du protocole a et seulement pour des changes sur des rseaux qui devraient tre protgs, e e e e e par exemple cantonns sur un vlan dadministration sur lequel ne circule e aucun trac applicatif inutile et surtout auquel aucun utilisateur standard nacc`de. e
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 SNMP est une relation entre un agent et les stations e dadministration qui linterrogent. Cette unique cha de caract`res dnit ne e e ` la fois lauthentication et le contrle dacc`s. a o e Il peut y avoir autant de communauts que dagents, cest au manager e den conserver la liste. Chaque message dune station dadministration vers un agent comporte le nom de la communaut et donc permet ` lagent dauthentier la source e a de la requte. Ce mode dauthentication nest bien sr plus adapt aux e u e contraintes de scurit quimpose lexploitation moderne des rseaux. e e e Le minimum pour exploiter malgr tout SNMPv2 est davoir au moins e trois communauts direntes : une pour la lecture (GET), une pour lcriture e e e (SET) et une troisi`me pour les traps. e

5.2

PDUs

Que ce soit pour des requtes, des rponses aux requtes, ou lenvoi dun e e e trap, SNMPv2 sappuie sur un message dont le format est dcrit succintement e 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-tte, comporte deux champs : e Version Il sagit de la version du protocole, 1, 2 ou 3. Communaut Une cha doctets qui identie la communaut, public e ne e par dfaut. . . e

236

Gestion de rseaux avec SNMP e Ensuite le message est compos dune partie dont la longueur et le contenu e sont assez variables, selon les oprations. Cest ce quon appelle le PDU e ( Protocol Data Unit ). Il y en a sept possibles. En eet, le protocole de base (SNMPv1) prvoit cinq types de requtes : e e GetRequest Cest une question du manager ` lagent. Une liste de a couples (variable,valeur) est fournie. Les valeurs sont positionnes ` e a unSpecified. GetNextRequest Cette requte est assez voisine de la prcdente ` ceci pr`s e e e a e que lOID exact de la variable est dtermin en prenant le plus proche e e dans lordre lexicographique (dou le sens de next ). SetRequest Cest une demande du manager ` lagent pour positionner une a certaine valeur ` chacune des variables listes. a e GetResponse Cest la rponse ` toutes les requtes Get/Set qui prc`dent. e a e e e Trap Envoy depuis lagent vers le manager, associ ` une liste de couples e ea (variable,valeur). Il ny a pas de rponse ` un trap. e a Auquels SNMPv2 en ajoute deux autres : GetBulkRequest Pour rcuprer des donnes de grande taille, cest ` dire e e e a des morceaux complets de larbre. Les deux champs non repeaters et max repetitions servent alors ` param`trer les limites de ce transfert, a e dans la limite de la taille dun message. InformRequest Sert ` la communication entre managers. Une station dada ministration envoie des donnes vers une autre station qui centralise les e informations contenues dans la MIB manager to manager . Le message a le mme format quun Get. Ce type de message est une sorte de e mcanisme de traps entre managers (conguration dalarmes, ensemble e dvnements choisis). e e Ainsi le champ PDU type peut-il prendre lune de ces sept valeurs et conduire ` autant de PDUs dirents, en taille et en signication. a e Chaque champ de len-tte SNMP ` une taille variable, selon e a limplmentation des OIDs de la MIB. e PDU type Valeur ` prendre dans la liste get-request, get-next-request, a get-bulk-request, response, set-request, inform-request, snmpv2-trap. RequestID Cest un numro de requte, la rponse doit porter le mme e e e e numro que celui de la requte. e e Error-status Une valeur non nulle indique une erreur pendant le traitement de la requte. e Error-index Quand error-status nest pas nul, ce champ identie le numro dordre du couple (variable,valeur) qui pose probl`me. Le pree e mier a 1 comme index. (variable,valeur) Il sagit de couple, la variable est un OID et la valeur est celle associe ` lOID. e a

Protocole SNMP

237

5.3

SNMPv3

238

Gestion de rseaux avec SNMP e

Loutil NET-SNMP

Dabord nomm UCD-SNMP au dbut des annes 1990 ` luniversit de e e e a e Carnegie-Mellon, le projet sest transform en NET-SNMP au dbut des annees e e e 2000 et est maintenant la base de nombreux outils open-source ou non. Sa abilit est telle quun OS industriel tel que Solaris 109 nhsite pas ` le e e a 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`me donc e est essentiellement compos de commandes ` taper dans un shell. Il existe e a 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 dacc`s en mode e e 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 ` dire a au sens de SNMP le nombre de centi`mes de seconde coules depuis que la e e e partie rseau a t initialise. Son nom textuel est SNMPv2-MIB::sysUpTime. e ee e
$ 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 galement utiliser une expression rguli`re : e e e

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 rseaux avec SNMP e

| 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 dbut de la e 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 rseaux avec SNMP e

6.2

snmpget

Cette commande correspond ` lopration la plus lmentaire du protocole a e ee SNMP, aller chercher linformation relative ` un OID prcis sur un agent. a e
$ 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 donne demande. Le cas le plus courant est pour les e e donnes de type scalaire, il ny a quune seule valeur alors il ne semble pas e ncessaire de prciser un index. Cet index est toujours un simple zro (0) e e e 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 dtail technique sav`re vite lassant, cest pourquoi on utilise e e plus frquemment la commande suivante. . . e

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 associe ` lOID (ou aux OIDs) suivant, e a 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`s employ de cette commande est de lutiliser avec une OID e e incompl`te, par exemple sans lindex ( instance subidentier ) et lagent e en dtermine la procha instance compl`te associe ` sa valeur. Cest une e ne e e a sorte de mcanisme rudimentaire de compltion. e e

6.4

snmpwalk

Cette commande eectue des requte de type get-next pour explorer toute e larborescence des sous-arbres lis ` un OID. Par exemple : e a
$ 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 daccder dun seul coup ` toutes les compteurs relatifs ` SNMP e a a (la sortie a t tronque). Le lecteur pourra essayer lOID 1.3.6 en arguee e ment. . .

6.5

snmptable

Comme son nom le sugg`re, cette commande est plutt utilise pour mae o e nipuler des tables. Ici il sagit de la liste des interfaces et de leurs compteurs associs. e
$ 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 donne, donc dconseill en SNMPv2. e e e

244

Gestion de rseaux avec SNMP e

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`me exemple, il sagit dextraire le contenu de la table e ifTable, comme nous avons pu le faire prcdemment avec snmptable, e e ce coup-ci avec la commande snmpwalk, puis de traiter graphiquement le rsultat. e
$ 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` lon sapperoit que cette machine a trois interfaces, nommes respecu c e tivement fxp0, plip0 et lo0. On voit galement que le mtu de linterface e de loopback (lo0) est de 16384 octets et que linterface fxp0 est le seul qui travaille rellement au vu des compteurs qui lui sont associs, 29017357 oce e tets en entre et 3117625 en sortie, depuis que la machine est en route (voir e sysUpTime). Bien entendu cette approche manuelle est trop lourde pour tre utilise e e telle que pour surveiller un rseau ! Il est indispensable dutiliser des outils e capables de faire la synth`se de tous ces compteurs, par exemple pour les e prsenter sous forme graphique. Loutil mrtg11 est capable de produire tr`s e e simplement un tel graphique avec jusqu` une anne dhistorique pour nima e porte quel interface :

gure XI.06 Synth`se graphique des compteurs ifInOctets et ifOutOctets sur e

24h

Il existe dautres MIBs, notamment applicatives comme celle dnie par e la RFC 1611 qui concerne le serveur de noms et celle dnie par la RFC 2790 e qui concernes les ressources de lhte lui-mme (espace disque, charge...) et o e que lon peut surveiller galement avec loutil mrtg. Il est ainsi ais de faire e e des graphiques dusage de la mmoire, des disques, de la charge de la machine, e etc. . .
11

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

246

Gestion de rseaux avec SNMP e

7 Glossaire des acronymes SNMP

247

La page prcdente est un exemple dcran de surveillance dun rseau e e e e aujourdhui compl`tement dmantel, et obtenu ` laide de loutil open-source e e e a tkined !

Glossaire des acronymes SNMP

Agent Cest le logiciel embarqu dans lhte rseau, quel quil soit. Il fonce o e tionne en mode serveur et est ` lcoute en UDP sur le port 161 (snmp) a e Il est galement susceptible denvoyer des traps vers le port 162 du e ou des manager(s). ASN1 Abstract Syntax Notation One est une norme internationale 12 dont la vocation premi`re est la spcication de donnes utilises dans e e e e les protocoles de communication. BER Basic Encoding Rules Mthode dencodage des valeurs pour tous e les types dnis dans ASN.1. e 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 rceptionne en UDP sur le port 162 e (snmptrap). MIB Management Information Base . Cest la description de tous les composants logiciels ou matriels surveills par lagent. Chaque come e posant est dsign par son OID. La MIB est crite ` laide du langage e e e a ASN.1 et selon une SMI bien prcise. Cest un arbre, dont les nu ds e et les feuilles sont reprs de mani`re unique par un chire. ee e NMA Network Management Application . Est une autre mani`re, non e spcique ` SNMP, de dsigner le manager. e a e NME Network Management Entity . Est une autre mani`re, non e spcique ` SNMP, de dsigner lagent. e a e NMS Network Management Software . Synonyme de NMA. OID Object IDentier . Cest la dsignation unique dun objet dans la e structure en arbre de la MIB. PDU Protocol Data Unit . Il sagit des paquets rseau, structurs selon e e le dtail du protocol applicatif SNMP. e RMON Remote Network Monitoring . Il sagit dun agent particulier dont lobjet est la surveillance du rseau lui mme et non un hte en e e o particulier. On dsigne souvent ces agents sous la terminologie de sonde e RMON. SMI Structure of Management Information . Cest la description du contenu et du formatage des donnes dune MIB. e
12

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

248

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

Liens & Bibliographie

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

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 rfrence : ee 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`me partie e Sockets BSD et architecture de serveurs

Chapitre XII Gnralits sur les sockets de e e e Berkeley

1 Gnralits e e e

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

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 t dveloppes en C. ee e e Les fonctionnalits des sockets que nous allons dcrire, sont celles appae e rues ` partir de la version 4.3 de BSD Unix, en 1986. Il faut noter que les a
Pour un historique tr`s intressant de cette priode on pourra consulter http://www. e e e 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 tude. e Pour conforter ce point de vue il nest pas sans intrt dajouter que toutes ee 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 schma ci-dessous rappelle e 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, numro de port et process ID e

Prsentation des sockets e

Les crateurs des sockets ont essay au maximum de conserver la e e smantique des primitives syst`mes dentres/sorties sur chiers comme open, e e e read, write, et close. Cependant, les mcanismes propres aux oprations e e sur les rseaux les ont conduits ` dvelopper des primitives complmentaires e a e e (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`me place un pointeur e sur les structures internes de donnes correspondantes dans la table des dese cripteurs ouverts de ce processus et renvoie lindice utilis dans cette table. e Par la suite, lutilisateur manipule ce chier uniquement par lintermdiaire e de lindice, aussi nomm descripteur de chier. e Comme pour un chier, chaque socket active est identie par un petit e entier appel descripteur de socket. Unix place ce descripteur dans la mme e e
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-mme, elles sont e prsentes dans des biblioth`ques prcises lors de la compilation des sources e e e e
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 mme valeur. e Pour crer une socket, une application utilisera la primitive socket et e non open, pour les raisons que nous allons examiner. En eet, il serait tr`s agrable si cette interface avec le rseau conservait la smantique des e e e e primitives de gestion du syst`me de chiers sous Unix, malheureusement e les entres/sorties sur rseau mettent en jeux plus de mcanismes que les e e e entres/sorties sur un syst`me de chiers, ce nest donc pas possible. e e Il faut considrer les points suivants : e 1. Dans une relation du type client-serveur les relations ne sont pas symtriques. Dmarrer une telle relation suppose que le programme sait e e quel rle il doit jouer. o 2. Une connexion rseau peut tre du type connecte ou non. Dans le e e e premier cas, une fois la connexion tablie le processus origine discute e uniquement avec le processus destinataire. Dans le cas dun mode non connect, un mme processus peut envoyer plusieurs data-grammes ` e e a plusieurs autres processus sur des machines direntes. e 3. Une connexion est dnie par un quintuplet (cf cours TCP page 89) e qui est beaucoup plus compliqu quun simple nom de chier. e 4. Linterface rseau supporte de multiples protocoles comme XNS, IPX, e APPLETALK3 , la liste nest pas exhaustive. Un sous syst`me de gestion e de chiers sous Unix ne supporte quun seul format. En conclusion de ce paragraphe on peut dire que le terme socket dsigne, e dune part un ensemble de primitives, on parle des sockets de Berkeley, et dautre part lextrmit dun canal de communication (point de communie e cation) par lequel un processus peut mettre ou recevoir des donnes. Ce e e point de communication est reprsent par une variable enti`re, similaire ` e e e a un descripteur de chier.

253

Etude des primitives

Ce paragraphe est consacr ` une prsentation des primitives essentielles ea e pour programmer des applications en rseaux. Pour tre bien complet il est e e fortement souhaitable de consulter les pages de manuels associes aux primie tives et la documentation cite en n de chapitre page 273. e

3.1
3

Cration dune socket e

La cration dune socket se fait par lappel syst`me socket. e e

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 Spcie la famille de protocole ( Protocol Family ) ` utiliser avec la e a 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`s ` la table de routage e a Acc`s ` une table de clefs (IPsec) e a Acc`s ` la couche Link e a implmentations notamment avec les protoe : Pour les rseaux Apple e : 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 prxe PF est la contraction de Protocol Family On peut e galement utiliser le prxe AF, pour Address Family . Les deux e e nommages sont possibles ; lquivalence est dnie dans le chier dene e tte socket.h. e TYPE Cet argument spcie le type de communication dsir. En fait avec e e e la famille PF INET, le type permet de faire le choix entre un mode connect, un mode non connect ou une intervention directe dans la e e 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 reprciser que seules les sockets en mode connect permettent e e les liaisons full-duplex ? PROTOCOL Ce troisi`me argument permet de spcier le protocole ` utie e a 6 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 dans ce cours e
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 ` zro car lassociation de la famille de a e protocole et du type de communication dnit explicitement le protoe cole de transport : PF INET + SOCK STREAM PF INET + SOCK DGRAM = = TCP = IPPROTO TCP UDP = IPPROTO UDP

Cest une constante dnie dans le chier den-ttes e e /usr/include/netinet/in.h et qui re`te le contenu du chier e syst`me /etc/protocols. e 3.1.1 Valeur retourne par socket e

La primitive socket retourne un entier qui est le descripteur de la socket nouvellement cre par cet appel. ee Par rapport ` la connexion future cette primitive ne fait que donner le a premier lment du quintuplet : ee {protocole, port local, adresse locale, port loign, adresse loigne} e e e e Si la primitive renvoie -1, la variable globale errno donne lindice du mese sage derreur idoine dans la table sys errlist, que la biblioth`que standard 7 sait parfaitement exploiter . Remarque importante : Comme pour les entres/sorties sur chiers, un appel syst`me fork due e plique la table des descripteurs de chiers ouverts du processus p`re dans le e processus ls. Ainsi les descripteurs de sockets sont galement transmis. e Le bon usage du descripteur de socket partag entre les deux processus e incombe donc ` la responsabilit du programmeur. a e 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 ` sinterrompre pour une a raison quelconque, en interne la socket est ferme et si plus aucun processus e 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

Spcication dune adresse e

Il faut remarquer quune socket est cre sans ladresse de lmetteur ee e comprendre le couple (numro de port, adresse IP) - ni celle du destinataire. e Il y a deux couples ` prciser, celui cot client et lautre cot serveur. La a e e e primitive bind eectue cette opration pour la socket de lhte local. e o 3.2.1 Spcication dun numro de port e e

Lusage dun numro de port est obligatoire. Par contre le choix de sa e valeur est largement conditionn par le rle que remplit la socket : client e o versus serveur. Sil sagit dun serveur, lusage dune valeur de port bien connue est essentiel pour tre accessible systmatiquement par les clients (par exemple e e le port 25 pour un serveur SMTP ou 80 pour un serveur HTTP). ` A linverse, le codage de la partie cliente dune application rseau ne e ncessite pas une telle prcaution (sauf contrainte particuli`re de au proe e e u tocole de lapplication elle-mme) parceque le numro de port associ ` la e e e a socket cliente est communiqu au serveur via len-tte de la couche de transe e port choisie, d`s la prise de contact par le rseau. e e Le serveur utilise alors la valeur lue dans len-tte pour rpondre ` la e e a requte du client, quel que soit le choix de sa valeur initiale. Ltablissement e e de cette valeur par le client peut donc tre le rsultat dun automate, e e ventuellement dbrayable. e e 3.2.2 Spcication dune adresse IP e

Pour des raisons videntes de communication, il est ncessaire de prciser e e e ladresse IP du serveur avec lequel on souhaite tablir un trac rseau. e e Par contre, concernant le choix sa propre adresse IP, cest ` dire celle qui a va servir dadresse pour le retour des datagrammes, un comportement par dfaut peut tre choisi lors de la construction de la socket, qui consiste ` e e a laisser au noyau du syst`me le soin den choisir la valeur la plus approprie. e e Pour une machine unix standard mise en rseau, cest le cas par exemple e dune station de travail, celle-ci poss`de au moins deux adresses IP : une sur e le rseau local et une autre sur linterface de loopback (cf page 75). La socket e est alors associe aux deux adresses IP, voire plus si la machine est du type e multi-homed (page 44). On peut galement choisir pour sa socket un comportement plus slectif, e e consistant ` ncouter que sur une seule des adresses IP de la station. a e 3.2.3 La primitive bind

La primitive bind eectue ce travail dassocier une socket ` un a couple (adresse IP, numro de port) associs dans une structure de type e e e e sockaddr in, pour IPv4. Mais la primitive bind est gnraliste, ce qui

Spcication dune adresse e explique que son prototype fasse tat dune structure gnrique nomme e e e e sockaddr, plutt qu` une structure ddie dun protocole particulier (IPv4 o a e e ici).
int bind(int sockfd, struct sockaddr *myaddr, socklen t addrlen) ;

257

socket myaddr addrlen

: : :

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

sockaddr est constitue (dans sa forme POSIX) de deux octets qui rape pellent la famille de protocole, suivis de 14 octets qui dnissent ladresse en e elle-mme. e 3.2.4 Les structures dadresses

Avec la prsence de plus en plus eective dIPv6, les implmentations e e les plus rcentes tiennent compte des recommandations de la RFC 34938 , e ajoutent un champ sa len dune longueur de 8 bits et font passer de 16 ` 8 a 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 prsent au mme eme e placement 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 dnie de la mani`re suivante : e e
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 numros de e port, par exemple si un numro de port est dj` utilis par un autre processus, e ea e ou encore si ladresse internet est invalide. Trois utilisations typiques de la primitive : 1. En r`gle gnral les serveurs fonctionnent avec des numros de port e e e e bien connus (cf /etc/services). Dans ce cas bind indique au syst`me e cest mon adresse, tout message reu ` cette adresse doit mtre renc a e voy . En mode connect ou non, les serveurs ont besoin de prciser e e e cette information avant de pouvoir accepter les requtes des clients. e 2. Un client peut prciser sa propre adresse, en mode connect ou non. e e 3. Un client en mode non connect a besoin que le syst`me lui assigne e e une adresse particuli`re, ce qui autorise lusage des primitives read et e write traditionnellement ddies au mode connect. e e e 3.2.5 Valeur retourne par bind e

Bind retourne 0 si tout va bien, -1 si une erreur est intervenue. Dans ce cas la variable globale errno est positionne ` la bonne valeur. e a Cet appel syst`me compl`te ladresse locale et le numro de port du quine e e tuplet qui qualie une connexion. Avec bind+socket on a la moiti dune e connexion, ` savoir un protocole, un numro de port et une adresse IP : a e {protocole, port local, adresse locale, port loign, adresse loigne} e e e e

Connexion ` une adresse distante a

259

3.3

Connexion ` une adresse distante a

Prendre linitiative de ltablissement dune connexion est typique de la e dmarche dun client rseau.. e e La primitive connect permet dtablir la connexion avec une socket dise tante, suppose ` lcoute sur un port connu ` lavance de la partie cliente. e a e a Son usage principal est dutiliser une socket en mode connect . Lusage e 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 par la prie mitive socket. : La structure qui dnit ladresse du destinae taire, du mme type que pour bind. e : La longueur de ladresse, en octets.

Mode connect e

Pour les protocoles orients connexion, cet appel syst`me rend la main au e e code utilisateur une fois tabli le circuit virtuel entre les deux piles TCP/IP. e Durant cette phase, des paquets sont changs comme nous avons pu dj` e e ea lexaminer page 89 dans le cas de TCP. Tant que cette connexion nest pas compl`tement tablie au niveau de la e e couche de transport, la primitive connect reste en mode noyau, et est donc bloquante vis ` vis du code de lapplication. a Dans le cas gnral, les clients nont pas besoin de faire appel ` bind e e a avant dinvoquer connect, la dnition de la socket locale est complte e ee automatiquement : le port est attribu automatiquement selon une dmarche e e dcrite page 276, et ladresse IP est lune de celles de linterface quemprunte e le datagramme pour son routage initial9 . 3.3.2 Mode datagramme

Dans le cas dun client en mode datagramme, un appel ` connect nest a pas faux mais il ne sert ` rien au niveau protocolaire, il redonne aussitt a o la main au code utilisateur. Le seul intrt que lon peut y trouver est que ee ladresse du destinataire est alors xe et que lon peut alors utiliser les prie mitives read, write, recv et send, traditionnellement rserves au mode e e connect. e
Est-il ncessaire de rappeler quun interface peut comporter plusieurs adresses IP et e quil peut y avoir plusieurs interfaces reseau sur un mme hte. . . ? e o
9

260 3.3.3 Valeur retourne par connect : e

Sockets de Berkeley

En cas derreur elle renvoie la valeur -1 et positionne la variable globale errno ` la valeur idoine, par exemple ` ETIMEOUT, sil ny a pas eu de rponse a a e ` lmission des paquets de synchronisation (cf page 94). Bien dautres erreurs a e lies ` des probl`mes du rseau sont ` consulter dans la section ERRORS de la e a e e a page de manuel. Un code 0 indique que la connexion est tablie sans probl`me e e particulier. Tous les lments du quintuplet sont en place : ee {protocole, port local, adresse locale, port loign, adresse loigne} e e e e

3.4

Envoyer des donnes e

Une fois quun programme dapplication a cr une socket, il peut lutiliser ee pour transmettre des donnes. Il y a cinq primitives possibles pour ce faire : e 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 de prciser ladresse du destinataire. e e Les dirences entre ces trois primitives sont mineures. e
ssize t write(int descripteur, const void *buffer, size t longueur) ;

Quand on utilise write, le descripteur dsigne lentier renvoy par la e e primitive socket. Le buffer contient les octets ` transmettre, et longueur a leur cardinal. Tous les octets ne sont pas forcment transmis dun seul coup, et ce nest e pas une condition derreur. En consquence il est absolument ncessaire de e e tenir compte de la valeur de retour de cette primitive, ngative ou non. e La primitive writev est sensiblement la mme que write simplement elle e permet denvoyer un tableau de structures du type iovec plutot quun simple buer, largument vectorlen spcie le nombre dentres dans iovector : e e
ssize t writev(int descriptor, const struct iovec *iovector, int vectorlen) ;

La primitive send ` la forme suivante : a

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

s Dsigne lentier renvoy par la primitive socket. e e

Envoyer des donnes e msg Donne ladresse du dbut de la suite doctets ` transmettre. e a len Spcie le nombre doctets ` transmettre. e a flags Ce drapeau permet de param`trer la transmission du data-gramme, e notamment si le buer dcriture est plein ou si lon dsire, par exemple e e et avec TCP, faire un envoi en urgence (out-of-band) : 0 MSG OOB MSG PEEK : Non oprant, cest le cas le plus courant. e : Pour envoyer ou recevoir des messages out-of-band. : Permet daller voir quel message on a reu sans le lire, c cest ` dire sans quil soit eectivement retir des buers a e internes (ne sapplique qu` recv (page 262). a

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. Toutes deux e rclament que lon spcie le destinataire ` chaque appel. e e a
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 mmes que pour send, e les deux derniers permettent de spcier une adresse et sa longueur avec une e structure du type sockaddr, comme vu prcdemment avec bind. e e Le programmeur soucieux davoir un code plus lisible pourra utiliser la deuxi`me primitive : e
ssize t sendmsg(int sockfd, const struct msghdr *messagestruct,int flags) ;

O` messagestruct dsigne une structure contenant le message ` envoyer u e a sa longueur, ladresse du destinataire et sa longueur. Cette primitive est tr`s e commode ` employer avec son pendant recvmsg car elle travaille avec la a mme structure. e

262

Sockets de Berkeley

3.5

Recevoir des donnes e

Symtriquement aux cinq primitives denvoi, il existe cinq primitives de e rception : read, readv, recv, recvfrom, recvmsg. e 3.5.1 Reception en mode connect e

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

Bien sur, si cette primitive est utilise avec les sockets BSD, le descripteur e est lentier renvoy par un appel prcdent ` la primitive socket. buffer et e e e a longueur spcie respectivement le buer de lecture et la longueur de ce que e lon accepte de lire. Chaque lecture ne renvoie pas forcment le nombre doctets demands, e e mais peut tre un nombre infrieur. e e Mais le programmeur peut aussi employer le readv, avec la forme :
ssize t readv(int descripteur, const struct iovec *iov, int vectorlen) ;

Avec les mme caractristiques que pour le readv. e e En addition aux deux primitives conventionnelles, il y a trois primitives nouvelles pour lire des messages sur le rseau : e
ssize t recv(int s, void *buf, size t len, int flags) ;

s buf len flags 3.5.2

: : : :

Lentier qui dsigne la socket. e Une adresse o` lon peut crire, en mmoire. u e e La longueur du buer. Permet au lecteur deectuer un contrle sur les paquets lus. o

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 ` recv sont des pointeurs a vers une structure de type sockaddr et sa longueur. Le premier contient ladresse de lmetteur. Notons que la primitive sendto fournit une adresse e dans le mme format, ce qui facilite les rponses. e e La derni`re primitive recvmsg est faite pour fonctionner avec son homoe logue sendmsg :
ssize t recvmsg(int sockfd, struct msghdr *messagestruct,int flags) ;

La structure messagestruct est exactement la mme que pour sendmsg e ainsi ces deux primitives sont faites pour fonctionner de paire.

Spcier une le dattente e

263

3.6

Spcier une le dattente e

Imaginons un serveur en train de rpondre ` un client, si une requte e a e arrive dun autre client, le serveur tant occup, la requte nest pas prise en e e e compte, et le syst`me refuse la connexion. e La primitive listen est l` pour permettre la mise en le dattente des a demandes de connexions. Elle est gnralement utilise apr`s les appels de socket et de bind et e e e e immdiatement avant le accept. e
int listen(int sockfd, int backlog) ;

sockfd backlog

: :

lentier qui dcrit la socket. e Le nombre de connexions possibles en attente (quelques dizaines). La valeur maximale est fonction du param`trage du noyau. Sous FreeBSD la valeur maximale e par dfaut est de 128 (sans param`trage spcique du e e e noyau), alors que sous Solaris 10, There is currently no backlog limit . Le nombre de fois o` le noyau refuse une connexion u est comptabilis et accessible au niveau de la ligne de e commande via le rsultat de lexcution de la come e mande netstat -s -p tcp (chercher listen queue overow ). Ce param`tre est important ` suivre dans e a le cas dun serveur tr`s sollicit. e e

3.7

Accepter une connexion

Accepter une connexion est typique de la dmarche dun serveur sur le e rseau. e nous lavons examin, un serveur utilise les primitives socket, bind et e listen pour se prparer ` recevoir les connexions. Il manque cependant ` e a a ce trio le moyen de dire au protocole jaccepte dsormais les connexions e entrantes . La primitive accept est le cha non manquant ! Quand le serveur invoque cette primitive, le noyau est prvenu que le e processus est en attente dun vnement rseau le concernant. Le retour dans e e e le code de lapplication ne fait que sous deux conditions, rception dune e demande de connexion ou rception dun signal par le processus. e
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 par la primitive du mme nom. e e

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 tre modie par le noyau lorsque la primitive est utie e lise avec des sockets dautres type pour lesquelles la taille de la structure e dadresse est variable (sockaddr un pour les sockets locales par exemple), ce qui justie un pointeur l` o` nous ne pourrions attendre quun simple a u passage dargument par valeur. Puis le syst`me cre une nouvelle socket par clonage de celle transmise et e e pour laquelle il renvoie un descripteur, rcupr ici dans newsock. Par cet are ee tice, la socket originale reste disponible pour dventuelles autres connexions e (elle est clone avant que le quintuplet soit complet). e En conclusion, lorsquune demande de connexion arrive, lappel ` la pria mitive accept redonne la main au code utilisateur.

3.8

Terminer une connexion

Dans le cas du mode connect on termine une connexion avec la primitive e close ou shutdown.
int close(descripteur) ;

La primitive bien connue sous Unix peut tre aussi employe avec un dese e cripteur de socket. Si cette derni`re est en mode connect, le syst`me assure e e e que tous les octets en attente de transmission seront eectivement transmis dans de bonnes conditions. Normalement cet appel retourne immdiatement, e 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 contrle o sur les connexions en full-duplex .
int shutdown(int sockfd, int how) ;

Sockfd est le descripteur ` fermer, how permet de fermer partiellement le a descripteur suivant les valeurs quil prend : 0 Aucune donne ne peut plus tre reue par la socket. e e c 1 Aucune donne ne peut plus tre mise. e e e 2 Combinaison de 0 et de 1 (quivalent de close). e Enn, pour une socket en mode connect, si un processus est interrompu e de mani`re inopine (rception dun signal de n par exemple), un reset e e e (voir page 92) est envoy ` lhte distant ce qui provoque la n brutale de la ea o connexion. Les octets ventuellement en attente sont perdus. e

4 Schma gnral dune session clientserveur e e e

265

Schma e serveur

gnral e e

dune

session

client

Il est temps de donner un aperu de la structure dun serveur et dun c client, mettant en uvre les APIs vus dans ce chapitre, et de rapprocher les vnements rseaux de ceux observables sur le syst`me et dans le processus e e e e qui sexcute. e 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 tablir une comparaison entre cette gure et les gures VI.03 e page 94 et VI.04 page 95. Les sockets cot client ou cot serveur, si elles e e participent ` ltablissement dun canal de communication symtrique en a e e fonctionnement, ne passent pas par les mmes tats, de leur cration juse e e quau recyclage des octets qui les composent. La RFC 793 prcise 11 tats pour une socket et la gure ci-dessus les met e e en situation de mani`re simplie. Ces tats peuvent tre visualiss avec la e e e e e 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 ltat de la socket cliente qui a envoy le premier paquet de e e demande dune connexion avec un ag SYN mais non encore acquitt e (ouverture active). SYN-RCVD La socket du serveur ` reu un paquet de demande de connexion, a c lacquitte et envoi sa propre demande de connexion. Elle attend lacquittement de sa demande.

266

Sockets de Berkeley ESTABLISHED Les demandes de connexions sont acquittes aux deux e extrmits. La connexion est tablie. La totalit du trac TCP ape e e e plicatif seectue dans cet tat. Sa dure est indnie, la clture est ` e e e o a linitiative des applications. FIN-WAIT-1 Celui qui est ` linitiative de lenvoi du premier paquet de dea mande de n est dans cet tat (fermeture active). e FIN-WAIT-2 On a reu lacquittement ` la demande de n de connexion. c a TIME-WAIT La socket tait en FIN-WAIT-2 et a reu la demande de n de la e c socket distante. On doit attendre le temps susant pour tre certain e que la socket distante a bien reu lacquittement (re-mission sinon). c e Cet tat peut donc tre long dans le temps, 2M SL prcise la RFC 793. e e e Cette constante peut aller de quelques dizaines de secondes ` une ou a deux minutes selon les implmentations. e CLOSE-WAIT La socket tait en ESTABLISHED et a reu une demande de n. e c Cet tat perdure jusqu` ce que la socket envoie ` son tour une demande e a a de n (fermeture passive). CLOSING Si la rponse ` une demande de n saccompagne immdiatement e a e de la demande de n de la socket locale, cet tat remplace FIN-WAIT-1 e et FIN-WAIT-2. LAST-ACK La derni`re demande de n est en attente du dernier acquittement. e CLOSED Etat de n. Les octets de la socket vont tre recycls. e e Ltat TIME-WAIT est support par celui qui clt la connexion. Les archie e o tectures de serveurs prf`rent une clture ` linitiative du serveur, ce qui se ee o a comprend du point de vue de lecacit (rester ma de la dure de la come tre e munication), mais le fonctionnement interne du protocole TCP implique ce temps dattente. Sur un serveur tr`s charg les sockets dans cet tat peuvent e e e tre en tr`s grand nombre (des dizaines de milliers. . .) bloquant ainsi les e e 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 ) prsent sur toute machine unix10 . e Ce serveur fonctionne en mode connect ou non, sur le port 13 qui lui est e rserv (/etc/services). Ici le serveur est une machine portant ladresse IP e e 192.168.52.232. La connaissance de ladresse IP du client nest absolument pas utile pour la comprhension de lexemple. e En mode TCP le simple fait de se connecter provoque lmission de la e cha ascii contenant la date vers le client et sa dconnexion. ne e En mode UDP il sut denvoyer un datagramme quelconque (1 caract`re) e au serveur puis dattendre sa rponse. e

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 rseau changes lors de lexcution de cette e e e e commande se trouve page 270. ligne 29 Dclaration de la structure saddr du type sockaddr in, ` utiliser e a avec IPv4. Attention, il sagit bien dune structure et non dun pointeur de structure. ligne 35 La variable sfd, reoit la valeur du descripteur de socket. Celle-ci c est ddie au protocole TCP. e e 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 ` la valeur du numro de port sur ea e lequel coute le serveur. Il faut remarquer lusage de la fonction htons e (en fait une macro du pr-processeur cpp) qui sassure que ce numro e e de port respecte bien le NBO ( Network Byte Order ), car cette valeur est directement recopie dans le champ PORT DESTINATION e du protocole de transport employ (voir page 84 pour UDP et page 91 e 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 inverss (le NBO est du type big ene dian ). Vous croyez crire 13 alors quen ralit pour le rseau vous e e e e avez crit 3328 (0x0D00) ce qui bien videment ne conduit pas au mme e e e rsultat, sauf si un serveur de date coute galement sur le port 3328, e e e non conventionnel donc tr`s peu probable ` priori. e a
10

Son activation est ventuellement ` faire ` partir du serveur de serveur inetd, page 320 e a a

268

Sockets de Berkeley En rsum, si le programmeur nutilise pas la fonction htons, ce code e e 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 de e ladresse IP. Cest donc lcriture de quatre octets (IPv4), pouvant come

5 Exemples de code client porter un caract`re ascii 0, donc interprtable comme le caract`re de e e e n de cha du langage C. ne Cest pourquoi ` cet endroit on ne peut pas employer les habituelles a fonctions de la biblioth`que standard (celles qui commencent par str). e Ici le probl`me se complique un peu dans la mesure o` lon dispose e u au dpart dune adresse IP sous sa forme dcimale pointe. La gestion e e e derreur prot`ge le code des erreurs de syntaxe ` la saisie. e a La fonction inet pton g`re parfaitement ce cas de gure. Nous en e dirons plus ` son sujet au chapitre suivant. a ligne 45 Appel ` la primitive connect pour tablir la connexion avec le a e serveur distant. Quand celle-ci retourne dans le code du programme, soit la connexion a chou et il faut traiter lerreur, soit la connexion e e est tablie. Lchange prliminaire des trois paquets sest eectu dans e e e e de bonnes conditions (page 94). Du point de vue TCP, les cinq lments du quintuplet qui caractrisent ee e la connexion sont dnis (page 90). e Sur la capture des paquets de la page 270 nous sommes arrivs ` la e a ligne 6, cest ` dire lenvoi de lacquittement par le client du paquet de a synchronisation envoy par le serveur (ligne 3 et 4). e Il faut noter que bien que nous ayons transmis la structure saddr par adresse (caract`re &) et non par valeur, la primitive connect ne modie e pas son contenu pour autant. Notons galement lusage du cast du C pour forcer le type du e pointeur (le prototype de la primitive exige ` cet endroit un pointeur a de type sockaddr). ligne 49 Appel ` la primitive read pour lire le rsultat en provenance du a e serveur, ` laide du descripteur sfd. a Sur la capture dcran on voit ligne 8 (et 9) lenvoi de la date en proe venance du serveur, dune longueur de 26 caract`res. e Ce nombre de caract`res eectivement lus est aect ` la variable n. e ea Ce nombre ne peut excder le rsultat de lvaluation de e e e M AXM SG 1, qui correspond ` la taille du buer buf moins 1 a caract`re prvu pour ajouter le caract`re 0 de n de cha e e e ne. En eet, celui-ci fait partie de la convention de reprsentation des e cha nes de caract`res du langage C. Rien ne dit que le serveur qui e rpond ajoute un tel caract`re ` la n de sa rponse. Le contraire est e e a e mme certain puisque la RFC 867 ny fait pas mention. e Remarque : le buer buf est largement surdimensionn compte tenu e de la rponse attendue. La RFC 867 ne prvoit pas de taille maximum e e si ce nest implicitement celle de lexpression de la date du syst`me en e anglais, une quarantaine doctets au maximum. ligne 53 Ajout du caract`re de n de cha en utilisant le nombre de cae ne ract`res renvoys par read. e e

269

270

Sockets de Berkeley ligne 55 La sortie du programme induit une clture de la socket cot client. o e Cot serveur elle est dj` ferme (squence write + close) comme on e ea e e peut le voir ligne 8 (ag FP, page 92) ci-apr`s dans la capture du trac e entre le client et le serveur. Remarque : rien nest explicitement prvu dans le code pour tablir la e e socket cot client, ` savoir lassociation dun numro de port et dune adresse e a e IP. En fait cest la primitive connect qui sen charge. Ladresse IP est celle de la machine. Le numro de port est choisi dans la zone dattribution autoe matique comme nous lavons examin page 85. e Il existe bien entendu une possibilit pour le programme davoir connaise sance 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 avec tcpdump e Un autre exemple dinterrogation, mais avec un autre hte du mme LAN o e 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 avec tcpdump e Lenvoi dun reset (drapeau R) envoy par le serveur en guise de rponse e e 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`re (NULL) au serveur, sans quoi il na aucun e moyen de conna notre existence. tre ligne 38, 39 et 40 Le remplissage de la structure saddr est identique ` a celui de la version TCP. ligne 49 Rception de caract`res en provenance du rseau. e e e 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 rponse du serveur). e Le raisonnement sur la taille du buer est identique ` celui de la version a TCP. La capture de trames suivante montre lextrme simplicit de lchange e e e 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 avec tcpdump e Un autre essai avec la machine 192.168.52.233 qui ne rpond pas plus e 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 avec tcpdump e Et le code client reste bloqu en lecture, malgr lenvoi dun code ICMP e e qui nest pas interprt par dfaut par recv. . .Pour viter une telle situation ee e e de blocage, il faudrait congurer la socket en lui ajoutant un dlai au del` e a 11 duquel elle retourne dans le code du client avec un code spcique derreur . e

11

voir la page de manuel de setsockopt assortie du param`tre SO RCVTIMEO e

6 Conclusion et Bibliographie

273

Conclusion et Bibliographie
Protocole Adresses locale Adresse loigne e e et N de port. et N de port. bind listen, accept connect bind recvfrom bind sendto

En conclusion on peut tablir le tableau suivant : e

Serveur orient connexion e Client orient connexion e Serveur non orient connexion e Client non orient connexion e

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 cites e dans ce chapitre, on pourra consulter les documents de rfrence suivants : ee Stuart Sechrest An Introductory 4.4BSD Interprocess Communication Tutorial Re imprim dans Programmers Supplementary e 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 comprhension des mcanismes internes : e e 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 galement e trouver ce document dans /usr/share/doc/psd/20.ipctut/ des OS dinspiration Berkeley 4.4
12

le

rpertoire e

274

Sockets de Berkeley

Chapitre XIII Complments sur les sockets e Berkeley

1 Rservation des ports e

Au chapitre prcdent nous avons utilis la primitive bind pour assigner e e e une adresse ` une socket, dans ce paragraphe nous prcisons comment choisir a e le numro de port qui va bien, selon le type dapplication envisag. Nous avons e e dj` examin ce point dans les grandes lignes page 85. ea e Il y a deux mani`res dassigner un N de port ` une socket : e a 1. Le processus spcie le numro. Cest typiquement ce que fait un sere e veur. On suppose bien videment que les clients sont au courant ou e quils disposent dun mcanisme qui peut les renseigner (cf cours sur e les RPC). 2. Le processus laisse le syst`me lui assigner automatiquement un numro e e 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`gle gnrale le dveloppeur dapplication ne sattribue pas au hasard e e e e un (ou plus) numro de port. Il doit respecter quelques contraintes comme e ne pas utiliser les ports dj` attribus. Ceux-ci gurent dans une RFC parea e ticuli`re. La derni`re en date est la RFC 1700 [Reynolds & Postel 1994]) au e e paragraphe WELL KNOWN PORT NUMBERS . Plus simplement, sur toute machine Unix ` jour, une liste de ces ports se trouve dans le chier a /etc/services 1 . Cod sur deux octets non signs, le numro de port permet 65536 possibie e e lits de 0 ` 65535. Cette chelle est fragmente de deux mani`res, lancienne e a e e e ou la nouvelle mthode. Toutes les applications sur tous les syst`mes dexe e ploitation nont pas encore adopt la nouvelle approche, les deux vont donc e cohabiter un certain temps, ne serait-ce qu` cause dapplications plus ana ciennes non encore mises ` jour. . . a
http://www.iana.org/assignments/port-numbers pour se tenir au courant des volutions de cette liste e
1

276

Complments sur les sockets Berkeley e

1.1

Rservation de port Ancienne mthode e e

Port N 0 Ce numro nest pas utilisable pour une application, cest une e sorte de jocker qui indique au syst`me que cest ` lui de complter e a e automatiquement le numro (voir plus loin de 1024 ` 5000). e a Port de 1 ` 255 Pour utiliser cette zone il faut avoir les droits du root a ` lexcution (U ID = 0) pour que le bind ne retourne pas une era e reur. Les serveurs classiques (domain, ftp, smtp, telnet, ssh, http, snmp...) se situent tous dans cette partie. Ports de 256 ` 511 Jadis considr comme une rserve des serveurs a ee e ociels commencent ` sy installer, faute de place dans la zone a prcdente. Il faut galement avoir un U ID = 0 pour utiliser un numro e e e e de port dans cette zone. Port de 512 ` 1023 Une fonction rresvport permet lattribution automaa tique dun numro de port dans cette zone, pour des applications ayant e 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 ` 5000 Zone dattribution automatique par bind. Lorsque a lutilisateur (non root) utilise 0 comme numro, cest le premier e port libre qui est employ. Si tous les utilisateurs peuvent sattribuer e manuellement un numro dans cette zone, il vaut mieux viter de e e le faire, la suivante est prvue pour cela. e 5001 ` 65535 Zone libre attention cependant car de tr`s nombreux a e serveurs y ont un port rserv, et pas des moindres comme le serveur e e X11 sur le port 6000 !

1.2

Rservation de port Nouvelle mthode e e

Port N 0 Ce numro nest pas utilisable pour une application, cest une e sorte de jocker qui indique au syst`me que cest ` lui de complter e a e automatiquement le numro (voir plus loin de 49152 ` 65535). e a Port de 1 ` 1023 Pour utiliser cette zone il faut avoir les droits du root a ` lexcution pour que le bind ne retourne pas une erreur. Les sera e veurs classiques (domain, ftp, smtp, telnet, ...) se situent tous dans cette partie. Port de 1024 ` 49151 est la zone des services enregistrs par lIANA et a e qui fonctionnent avec des droits ordinaires. Port de 49152 ` 65535 est la zone dattribution automatique des ports, a pour la partie cliente des connexions (si le protocole nimpose pas une valeur particuli`re) et pour les tests de serveurs locaux. e

2 Ordre des octets sur le rseau e

277

Ordre des octets sur le rseau e

15 Un mot de deux octets : 0 87 1 0

Nous reprenons ici un point dj` voqu page 48 : eae e

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 rseau e Le probl`me de lordre des octets sur le rseau est dautant plus crucial e e que lon travaille dans un environnement avec des architectures htrog`nes. ee e La couche Rseau (page 30) ne transforme pas les octets de la couche Ine ternet (page 30) qui elle mme ne modie pas ceux de la couche de Transport2 e (page 29). Pour cette raison, le numro de port inscrit dans len-tte TCP (vs UDP) e e de lmetteur est exploit tel quel par la couche de transport du rcepteur e e e et donc il convient de prendre certaines prcautions pour sassurer que les e couches de mme niveau se comprennent. e Dun point de vue plus gnral, les rseaux imposent le poids fort avant e e e le poids faible , cest le Network Byte Order . Les architectures qui travaillent naturellement avec cette reprsentation nont donc thoriquement e e pas besoin dutiliser les fonctions qui suivent, de mme pour les applications e qui doivent dialoguer avec dautres ayant la mme architecture matrielle. e e Nanmoins crire du code portable consiste ` utiliser ces macros dans e e a 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 numro de port par exemple. e long Entier long sur 32 bits, une adresse IP par exemple. host La machine sur laquelle sexcute le programme. e network Le rseau sur lequel on envoie les donnes. e e

Nous nabordons pas ici la question de la transmission de donnes htrog`nes au e ee e niveau applicatif, elle sera examine dans le cours sur les XDR e 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 ` toutes les architectures de type i386 a

278 Do` les protoptypes : u

#include u long u short u long u short <sys/types.h> htonl (u long) ; htons (u short) ; ntohl (u long) ; ntohs (u short) ;

Complments sur les sockets Berkeley e

/* /* /* /*

host to host to network network

network network to host to host

---------

long */ short */ long */ short */

Par exemple, pour aecter le numro de port 13 (service daytime ) au e champ sin port dune structure de type sockaddr in :
saddr.sin port = htons(13) ;

Cette criture est valable quelle que soit larchitecture sur laquelle elle e est compile. Sil avait fallu se passer de la macro htons sur une architecture e Intel ( little endian ), pour laection du mme numro de port, il eut fallu e e crire : e
saddr.sin port = 0x0D00 ; /* 0D hexadcimal == 13 dcimal */ e e

Oprations sur les octets e

Dans le mme ordre dide quau paragraphe prcdent, les rseaux ine e e e e terconnectent des architectures htrog`nes et donc aussi des conventions de ee e rprsentation des cha e e nes de caract`res direntes. Pour tre plus prcis, le e e e e caract`re NULL marqueur de n de cha bien connu des programmeurs C, e ne nest pas valide partout, voire mme est associ ` une autre signication ! e ea En consquence, pour toutes les fonctions et primitives qui lisent et e crivent des octets sur le rseau, les cha e e nes de caract`res sont toujours ase socies au nombre de caract`res qui les composent. e e Le corollaire est que les fonctions classiques de manipulation de cha nes en C (strcpy, strcat, ...) ne sont ` utiliser quavec une extrme prua e dence. Pour copier des octets dune zone vers une autre il faut utiliser bcopy, pour comparer deux buers, bcmp, enn pour mettre ` zro (remplir doctets a e 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 copis dans dst et non linverse, e 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 ` vis a dune quelconque relation dordre (` la dirence de strcmp qui supa e pose les caract`res dans la table ASCII). e bzero Met des octets NULL (0) len fois ` ladresse b. a Il exite des outils similaires, issus du syst`me V : memcpy, memcmp, memset,.... e

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 dcimal point , or la structure dadresse (sockaddr in) a besoin e e dun entier non sign sur 32 bits qui respecte le NBO. Une conversion est e donc ncessaire pour passer dune reprsentation ` une autre. e e a

4.1

Conversion dadresse - IPv4 seul

La fonction inet addr convertit une adresse dcimale pointe en un entier e e long non sign et qui respecte le NBO. La fonction inet ntoa eectue le e travail inverse. Ces deux fonctions ne sont valables que pour les adresses 32 bits dIPv4 et sont prsentes dans la majeure partie des codes rseaux. Dans e e le cadre dun nouveau dveloppement on leur prf`rera les fonctions dcrites e ee e apr`s. e
#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 symtriques, le fait que e inet addr ne renvoie pas une structure du type in addr nest pas une inconsistance mais est d au fait que la structure in addr tait prvue au dpart u e e e pour voluer. e 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 mmes chiers den-tte, les deux nouvelles fonctions de conversion : e e
const char * int

Le p signie presentation , comprendre lisible par lhumain, alors que le n signie numeric , cest ` dire comprhensible par le noyau (entier qui a e respecte le NBO). Donc ntop convertit le format syst`me vers lhumain et e pton eectue le travail inverse.

280

Complments sur les sockets Berkeley e Du fait de leur compatibilit entre les familles de protocoles, ces fonctions e sont un peu plus compliques ` lusage : Il faut prciser PF INET ou PF INET6. e a e 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 transcode est e utilisable. Le code de retour de inet ntop est soit NULL si la conversion a chou, e e ou un pointeur sur la cha achable. Ici, par construction, on suppose que ne la conversion sera toujours russie. e

Conversion hte adresse IPv4 o

Se pose rguli`rement le probl`me de convertir un nom symbolique en e e e une adresse IP et inversement. Lorigine de cette information dpend de la e conguration de la station de travail : cest un serveur de noms (DNS), cest un chier (/etc/hosts) ou tout autre syst`me de propagation des informae tions (NIS. . .). Dans tous les cas linformation arrive ` un programme via a une entit nomme le resolver, qui unie les sources dinformations. e e Les paragraphes 5.1, 5.2 (p. 282), 6.1 (p. 282) et 6.2 (p. 284 prsentent une e approche traditionnelle, seulement valable avec IPv4 alors que le paragraphe 7 (p. 285) expose une dmarche beaucoup plus rcente et adapte galement e e e e ` IPv6. Lcriture de nouveaux codes ne devraient faire appel qu` cette a e a nouvelle api.

5.1

Une adresse IP ` partir dun nom dhte a o

#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 e e la macro h addr sert ` assurer la compatibilit avec les premi`res versions dans lesquelles il ny avait quune seule adresse IP possible par hte. o

Conversion hte adresse IPv4 o Le nom ociel soppose aux noms synonymes. Par exemple, soit une machine ociellement baptise pasglop.mon-domain.fr ; si pour rpondre e e au besoin dune certaine application ladministrateur du rseau lui donne le e surnom www.mon-domain.fr, celui-ci sera considr comme un alias vis ee ` vis du nom ociel et donc lu dans h aliases. (voir page 185) a

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 marque par un pointeur NULL. e

282

Complments sur les sockets Berkeley e La liste des adresses est un tableau de pointeurs, le marqueur de n de liste est galement un pointeur NULL. Chaque adresse est une zone de h length e octets (cf fonction impnet dans lexemple ci-apr`s). e Le programme dusage qui suit ache toutes les informations contenues dans cette structure pour les htes dont le nom est pass en argument (le o e code source de cet exemple, gethostbyname.c, est ` la page suivante). a $ 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 dhte ` partir dune adresse IP o a

le probl`me inverse se rsoud avec la fonction gethostbyaddr. La e e dnition du prototype se trouve au mme endroit que prcdement, e e e e 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 donns par leur nom plutt que e o par leur valeur numrique, comme par exemple dans les sorties de la come mande tcpdump.

6.1

Le numro ` partir du nom e a

Un tel programme a besoin de faire la conversion symbolique numrique, la fonction getservbyname eectue ce travail. Lutilisateur e rcup`re un pointeur sur une structure du type servent, NULL dans le e e cas dune impossibilit. La source dinformations se trouve dans le chier e /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 ` NULL. a s port Le numro du port (il respecte le Network Byte Order). e s proto Le nom du protocole ` utiliser pour contacter le service (TCP vs a UDP). Voici un programme de mise en application de la fonction, le code source de lexemple, getservbyname.c se trouve ` la page suivante. a $ 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

Complments sur les sockets Berkeley e

6.2

Le nom ` partir du numro a e

Symtriquement la fonction getservbyport eectue le travail inverse. e 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 prc`dent (gethostbyname et e e getservbyname et leur symtrique) sont des standards de facto et ce dee puis le dbut des annes 80. On les trouve sur toutes les variantes dUnix et e e mme au del`, ce qui a particip ` une grande portabilit du code crit qui e a ea e e les utilise. Larrive dIPv6 et de sa probable tr`s longue cohabitation avec IPv4 e e oblige ` modier les habitudes de programmation au prot dune nouvelle a approche, que ces concepteurs souhaitent aussi stable et largement rpandue e que la prcdente. Lcriture de tout nouveau code devrait sappuyer sur e e e cette nouvelle API, dnie dans la RFC 3493. e La nouvelle fonction getaddrinfo de la libc ne se contente pas seulement de synthtiser gethostbyname et getservbyname en une seule fonction, elle e banalise galement lusage dIPv6. e La dmarche est plus concise (une fonction au lieu dune), et la manipue lation des adresses IP est rendue plus aise en retour, puisque que la struce ture de donnes utilise par la fonction contient directement une structure e e dadresse conforme ` la famille de protocole utilise, sockaddr in pour IPv4, a e 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 fonctionnalits de gethostbyname e et getservbyname pour les protocoles IPv4 et IPv6. Son prototype est donc le reet de sa relative complexit, par contre son fonctionnement est tr`s e e logique , il dcoule de celui des deux fonctions quelle remplace. e

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 ` transmettre et ` recevoir, a a tout (ou presque) seectue via une nouvelle structure de donnes nomme e e addrinfo. Elle apparait en troisi`me argument (informations fournies ` lape a pel) et quatri`me (dernier) argument, le rsultat. e e Si cette fonction ne retourne pas une valeur nulle (0), le code derreur est ` exploiter ` laide dune fonction spcialise, gai strerror qui ajoute une a a e e bonne dizaine de messages derreurs supplmentaires spcialiss. e e e

286 7.1.2

Complments sur les sockets Berkeley e Description des arguments

Les deux premiers arguments, hostname ou servname, sont soit des cha nes de caract`res, soit un pointeur nul. Il ne peuvent pas tre tous les e e deux nuls. hostname Les valeurs acceptables sont soit un nom dhte valide ou une o adresse IP exprime sous sa forme dcimale pointe. e e e servname est soit un nom, soit un numro de service prsent dans e e /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 mme type que hints. Cest par ce moyen que la fonction va renvoyer le e rsultat construit, en modiant la valeur du pointeur (il nous faut pase ser ladresse du pointeur puisque sa valeur va changer, do` le pointeur u de pointeur). La fonction alloue la mmoire ncessaire pour le stockage des donnes, e e e au programme appelant de la restituer au syst`me. Il dispose ` cet eet e a dune fonction spcialise : freeaddrinfo. e e 7.1.3 La structure addrinfo

Voici les membres de la structure addrinfo, dnis dans le chier dene ttes netdb.h : e
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 mme type que celui de la structure elle mme (structure e e auto-rfrente en langage C) ce qui signie quil peut pointer vers une autre ee structure du mme type. Il sagit alors dune liste cha ee4 an de retourner e n une information multiple, comme peut ltre par exemple la rponse dune e e requte DNS (type A ou PTR en loccurence), ou la liste des protocoles e
Type Abstrait de Donnes (TAD) tr`s rpandu, cf : http://fr.wikipedia.org/wiki/ e e e Liste_chainee
4

Getaddrinfo, pour IPv4 et IPv6 prvus pour un service donn. La n de la liste est marque par un pointeur e e e de valeur nulle (NULL). La structure hints doit tre mise ` zro avant chaque usage. Les quatre e a e premiers champs sont utiliss ` lappel, les autres lments sont ` zro lors e a ee a e de la transmission ` la fonction. a ai family Pour indiquer la famille de protocole utilise. Cest le mme are e gument que celui quon utilise en premi`re position avec la primitive e socket, cf page 253. Il peut prendre la valeur PF UNSPEC quand le protocole nest pas x. e ai socktype Pour prciser le type de socket demand, cest ` dire le mode e e a connect ou datagramme. Cest le deuxi`me argument de la primite e e socket. Si la valeur est laisse ` 0 cela signie que nimporte quel protocole est e a accept. e ai protocol Pour prciser le nom du protocole. Cest le troisi`me argument e e de socket. Mme remarque que prcdement concernant la valeur 0. e e e ai flags Ce drapeau est ventuellement une combinaison de valeurs binaires e assembles avec loprateur | du langage C (ou inclusif). e e AI ADDRCONFIG Seules les adresses (IPv4 ou IPv6) congures sur le e syst`me local sont retournes. e e AI ALL Combin avec AI V4MAPPED donne toutes les adresses IPv4 et e IPv6. Sans eet si AI V4MAPPED nest pas prsent. e AI CANONNAME Si linformation est accessible (DNS. . .) le champ ai canonname de la premi`re structure res pointe sur le nom cae nonique de hostname. AI NUMERICHOST Prcise que hostname doit tre trait comme une e e e adresse IP dlivre sous sa forme numrique, cest ` dire dcimale e e e a e pointe pour IPv4. e AI NUMERICSERV Indique que si servname est un port donn sous forme e numrique (la cha encode la reprsentation du nombre, comme e ne e par exemple 23 ). AI PASSIVE Sert pour lattribution automatique du numro de port de e la structure dadresse, sockaddr in pour IPv4, accessible via le pointeur gnrique sockaddr. e e AI V4MAPPED Utilis avec IPv6 (AF INET6). e 7.1.4 En rsum e e

287

Il y a 6 variables ` congurer, non toutes utiles selon les utilisations. Il est a vident que certaines des nombreuses possibilits oertes par la combinatoire e e ne sont pas consistante. Le bon sens doit prdominer et le test de retour de e la fonction tre toujours exploit. . . ! e e

288 7.1.5

Complments sur les sockets Berkeley e Exemple dusage ` la place de gethostbyname a

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-ttes pour avoir le prototype de e getaddrinfo. Ligne 26 Dclaration dune structure de type addrinfo et de deux poine teurs du mme type. e

Getaddrinfo, pour IPv4 et IPv6 Ligne 31 On dcrmente avant de faire le test. Donc quand argc passe par e e 0 on sort de la boucle. La derni`re valeur utilise de argc est 1. e e Ligne 32 pt pointe sur argv[1], puis sur argv[2], etc. . .On utilise argc valeurs tr`s exactement. e Lignes 33 Mise ` zro de tous les bits de la structure a e Lignes 34, 35 et 36 On veut les noms canoniques, pour IPv4. Lusage de SOCK DGRAM est un artice pour viter davoir deux rponses, une avec e e TCP et lautre avec UDP. Ligne 37 Ne pas oublier de conserver le code de retour pour pouvoir ventuellement lexploiter ` laide de la fonction gai strerror, comme e a ligne 38. Ligne 41 et 42 Achage des informations de la premi`re structure e (lstres0). Ligne 43 Boucle for pour explorer tous les lments de la liste cha ee. La ee n condition darrt est de rencontrer un pointeur nul. e 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 lments de la structure dinformation pour ee complter les arguments dappel de inet ntop. Il faut utiliser un e cast (struct sockaddr in *) an daccder au champ sin addr de e la structure dadresse IPv4. La structure ai addr est gnrique et ny e e donne pas acc`s. e Ligne 50 Restitution de la mmoire alloue, pour lexemple parceque le e e noyau va de toute mani`re recycler toute la mmoire du processus lors e e de lopration de n provoque ligne 51. e e

289

290 7.1.6

Complments sur les sockets Berkeley e Exemple dusage ` la place de getservbyname a

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 prcise IPv4. e Ligne 33 Usage de la fonction getprotobynumber dont le prototype est dcrit au paragraphe 8 page 291 et qui sert ` retrouver la valeur e a symbolique dun protocole, connaissant son codage numrique (chier e /etc/protocols). Ligne 34, 35 et 36 Achage du numro de port et du nom du protocole. e Notez lusage de la fonction ntohs pour prsenter les octets du numro e e de port dans le bon ordre ! 7.1.7 ... En rsum e e

8 Conversion nom de protocole N de protocole

291

Conversion nom de protocole N de protocole

Les fonctions getservbyname et getservbyport dlivrent un nom de e protocole, donc un symbole. Lors de la dclaration dune socket le troisi`me argument est numrique, e e e il est donc ncessaire davoir un moyen pour convertir les numros de proe e tocoles (IPPROTO UDP, IPPROTO TCP, IPPROTO IP,IPPROTO ICMP,...) en symboles et rciproquement. e 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 numro du protocole, dans /etc/services. e
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

Complments sur les sockets Berkeley e Le source qui prc`de donne un exemple de programmation de la fonction e e 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 tre soigneusement test, le code e e gnr nen est que plus able et les ventuels disfonctionnements plus aiss e ee e e ` dtecter. a e Quelques unes des erreurs ajoutes au chier den-tte errno.h e e 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 Opration non supporte e e Famille dadresse non supporte e Adresse dj` utilise ea e Ladresse ne peut pas tre aecte e e Rseau hors service e Pas de route pour atteindre ce rseau e Connexion coupe par le rseau e e Connexion interrompue Connexion interrompue par lhte distant o Le buer est satur e La socket est dj` connecte ea e La socket nest pas connecte e Transmission apr`s un shutdown e time-out expir e Connexion refuse e Lhte distant a interrompue sa connexion o Lhte nest pas en marche o Pas de route vers cet hte o

10 Exemples de mise en application

293

10
10.1

Exemples de mise en application

Ancienne mthode (usage de gethostbyname) e

Deux premiers exemples de fonctions de connexion ` un serveur : a tcp open et udp open. Toutes les deux renvoient un descripteur de socket prt ` lemploi, ou -1 en cas derreur (le message derreur doit tre gnr e a e e ee par les fonctions elles mmes). Ces deux fonctions sont bases sur lusage de e e 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 de caract`res qui est ladresse de lhte distant. Cette ne e o adresse est soit sous forme dcimale pointe, soit cest un nom syme e bolique. Elle ne peut pas tre nulle. e service Si cette cha nest pas nulle, elle contient le nom symbolique du ne service distant sur lequel il faut se connecter. port Le numro du port distant. Sil est ngatif alors service est oblie e gatoirement non nulle. Dans le cas o` service est non nulle et u port > 0, cette derni`re valeur lemporte sur celle trouve dans le chier e e /etc/services. conn Cet argument na dusage que pour la fonction udp open. Egal ` un, a il prcise que la socket cre est ddie au serveur host (avec un bind), e e e e 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

Complments sur les sockets Berkeley e

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 ` la fonca tion appelante, La fonction udp open compl`te une structure globale. e
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

Complments sur les sockets Berkeley e

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

Complments sur les sockets Berkeley e

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 mthode (usage de getaddrinfo) e

/* $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 e e e a fonction sock open gn`re un descripteur de socket prt ` lemploi, comme

Exemples de mise en application prcdemment. Le main appelle quatre fois cette nouvelle fonction avec les e e mmes hypoth`ses de travail que pour les anciennes versions. e e
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

Complments sur les sockets Berkeley e

11

Conclusion et bibliographie

Outre les pages de manuel (man) des primitives et fonctions rencontres, e 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 rfrences : ee 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 redit dans Programmers Supplementary Documents e e diteur OReilly, ou sous forme de chier ascii dans le rpertoire : e e /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 e Elments de serveurs

Dans ce chapitre nous abordons quelques grands principes de fonctionnement des logiciels serveurs. Dabord nous tentons de rsumer leurs comportee ments selon une typologie en quatre mod`les gnriques, puis nous examinons e e e quelques points techniques remarquables de leur architecture logicielle comme la gestion des tches multiples, des descripteurs multiples, le fonctionnement a en arri`re plan (les fameux daemon ), la gestion des logs. . . e Enn nous concluons ce chapitre avec une prsentation tr`s synthtique e e e du serveur de serveurs sous Unix, cest ` dire la commande inetd, suivie a dune lecture commente dun petit code en langage C qui sinspire de son e fonctionnement, pour mieux comprendre sa stratgie ! e

Type de serveurs

Lalgorithme intuitif dun serveur, dduit des schmas (revoir la page 265) e e dutilisation des sockets, pourrait tre celui-ci : e 1. Crer une socket, lui aecter une adresse locale avec un numro de port e e connu des clients potentiels. 2. Entrer dans une boucle innie qui accepte les requtes des clients, les e lit, formule une rponse et la renvoie au client. e Cette dmarche, que nous pourrions qualier de na e ve, ne peut convenir qu` des applications tr`s simples. Considrons lexemple dun serveur a e e de chiers fonctionnant sur ce mode. Un client rseau qui sy connecte et e tlcharge pour 10 Go de donnes accapare le serveur pendant un temps siee e gnicativement long, mme au regard des bandes passantes modernes. Un e deuxi`me client rseau qui attendrait la disponibilit du mme serveur pour e e e e transfrer 1Ko aurait des raisons de simpatienter ! e

1.1

Serveurs itratif et concourant e

Un serveur itratif ( iterative server ) dsigne une implmentation qui e e e traite une seule requte ` la fois. e a

302

e Elments de serveurs Un serveur concourant ( concurrent server ) dsigne une e implmentation capable de grer plusieurs tches en apparence simule e a tanes. Attention, cette fonctionnalit nimplique pas ncessairement que e e e ces tches concourantes doivent toutes sexcuter en parall`le. . . a e e Dans cette premi`re approche purement algorithmique nous nabordons e pas la mise en uvre technique, le paragraphe 2 sy consacrera ! Dun point de vue conceptuel, les serveurs itratifs sont plus faciles ` e a concevoir et ` programmer que les serveurs concourants, mais le rsultat a e nest pas toujours satisfaisant pour les clients. Au contraire, les serveurs concourants, sils sont dune conception plus savante, sont dun usage plus agrable pour les utilisateurs parceque naturellement plus disponibles. e

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 tre compl`tement boulevers e e e par le choix de lun ou de lautre. Avant toute chose il faut se souvenir des caractristiques les plus marquantes de lun et de lautre. e

1.2.1

Mode connect e

Le mode connect avec TCP est le plus facile ` programmer, de plus il e a assure que les donnes sont transmises, sans perte. e Par contre, Il tablit un circuit virtuel bi-directionnel ddi ` chaque e e e a client ce qui monopolise une socket, donc un descripteur, et interdit par construction toute possibilit de broadcast . e Ltablissement dune connexion et sa terminaison entra lchange de 7 e ne e paquets. Sil ny a que quelques octets ` changer entre le client et le serveur, ae cet change est un gaspillage des ressources du rseau. e e Il y a plus proccupant. Si la connexion est au repos , cest ` dire quil e a ny a plus dchange entre le client et le serveur, rien nindique ` celui-ci que e a le client est toujours l` ! TCP est silencieux si les deux parties nont rien ` a a 1 schanger . e Si lapplication cliente a t interrompue accidentellement2 , rien nindique ee au serveur que cette connexion est termine et il maintient la socket et les e buers associs. Que cette opration se rp`te un grand nombre de fois et le e e e e serveur ne rpondra plus, faute de descripteur disponible, voire de mmoire e e libre au niveau de la couche de transport (allocation au niveau du noyau, en fonction de la mmoire totale et au dmarrage de la machine) ! e e
Nous verrons au chapitre suivant comment on peut modier ce comportement par dfaut e 2 crash du syst`me, retrait du rseau,. . . e e
1

Quatre mod`les de serveurs e 1.2.2 Mode datagramme

303

Le mode datagramme ou non connect avec UDP hrite de tous les e e dsagrments de IP, ` savoir perte, duplication et dsordre introduit dans e e a e lordre des datagrammes. Pourtant malgr ces inconvnients UDP reste un protocole qui ore des e e avantages par rapport ` TCP. Avec un seul descripteur de socket un serveur a peut traiter un nombre quelconque de clients sans perte de ressources due ` de a mauvaises dconnexions. Le broadcast et le multicast sont possibles. e Par contre les probl`mes de abilit du transport doivent tre grs au e e e ee niveau de lapplication. Gnralement cest la partie cliente qui est en charge e e de la rmission de la requte si aucune rponse du serveur ne lui parvient. ee e e La valeur du temps au del` duquel lapplication consid`re quil doit y avoir a e rmission est videment dlicate ` tablir. Elle ne doit pas tre ge aux ee e e a e e e caractristiques dun rseau local particulier et doit tre capable de sadapter e e e aux conditions changeantes dun internet.

1.3

Quatre mod`les de serveurs e

Deux comportements de serveurs et deux protocoles de transport combins induisent quatre mod`les de serveurs : e e

Itratif Datagramme

Itratif Connect

Concourant Datagramme

Concourant Connect

gure XIV.01 La terminologie tche esclave employe dans les algorithmes qui suia e vent se veut neutre quant au choix technologique retenu pour les implmenter. e Ce qui importe cest leur nature concourante avec la tche ma a tre qui les pilote. Algorithme itratif - Mode data-gramme : e

1. Crer une socket, lui attribuer un port connu des clients. e 2. Rpter : e e Lire une requte dun client, e Formuler la rponse, e Envoyer la rponse, conformment au protocole dapplication. e e

304

e Elments de serveurs Critique : Cette forme de serveur est la plus simple, elle nest pas pour autant inutile. Elle est adapte quand il y a un tout petit volume dinformation ` changer et e ae en tout cas sans temps de calcul pour llaboration de la rponse. Le serveur e e de date daytime ou le serveur de temps time en sont dexcellents exemples.

Quatre mod`les de serveurs e Algorithme Itratif - Mode connect : e e

305

1. Crer une socket, lui attribuer un port connu des clients. e 2. Mettre la socket ` lcoute du rseau, en mode passif. a e e 3. Accepter la connexion entrante, obtenir une socket pour la traiter. 4. Entamer le dialogue avec le client, conformment au protocole e de lapplication. 5. Quand le dialogue est termin, fermer la connexion et aller en 3). e Critique : Ce type de serveur est peu utilis. Son usage pourrait tre ddi ` des e e e e a relations clients/serveurs mettant en jeu de petits volumes dinformations avec la ncessit den assurer ` coup sr le transport. Le temps dlaboration e e a u e de la rponse doit rester court. e Le temps dtablissement de la connexion nest pas ngligeable par rape e port au temps de rponse du serveur, ce qui le rend peu attractif. e Algorithme concourant - Mode datagramme : Ma tre : 1. Crer une socket, lui attribuer un port connu des clients. e 2. Rpter : e e Lire une requte dun client e Crer une tche esclave pour laborer la rponse. e a e e Esclave : 1. Recevoir la demande du client, 2. Elaborer la rponse, e 3. Envoyer la rponse au client, conformment au protocole e e de lapplication, 4. Terminer la tche. a

306

e Elments de serveurs Critique : Si le temps dlaboration de la rponse est rendu indirent pour cause de e e e cration de processus esclave, par contre le cot de cration de ce processus e u e ls est prohibitif par rapport ` son usage : formuler une seule rponse et a e lenvoyer. Cet inconvnient lemporte gnralement sur lavantage apport e e e e par le paralllisme . e Nanmoins, dans le cas dun temps dlaboration de la rponse long par e e e rapport au temps de cration du processus esclave, cette solution se justie. e Algorithme concourant - Mode connect : e Ma tre : 1. Crer une socket, lui attribuer un port connu des clients. e 2. Mettre la socket ` lcoute du rseau, en mode passif. a e e 3. Rpter : e e Accepter la connexion entrante, obtenir une socket pour la traiter, Crer une tche esclave pour traiter la rponse. e a e Esclave : 1. Recevoir la demande du client, 2. Amorcer le dialogue avec le client, conformment au protocole e de lapplication, 3. Terminer la connexion et la tche. a Critique : Cest le type le plus gnral de serveur parce-quil ore les meilleurs cae e ractristiques de transport et de souplesse dutilisation pour le client. Il est e sur-dimensionn pour les petits services et sa programmation soigne e e nest pas toujours ` la porte du programmeur dbutant. a e e

2 Technologie lmentaire ee

307

Technologie lmentaire ee

De la partie algorithmique dcoulent des questions techniques sur le e comment le faire . Ce paragraphe donne quelques grandes indications tr`s e lmentaires que le lecteur soucieux dacqurir une vraie comptence devra ee e e complter par les lectures indiques au dernier paragraphe ; la Bibliographie e e du chapitre (page 325). Notamment il est ncessaire de consulter les ouvrages e de W. R. Stevens pour la partie syst`me et David R. Butenhof pour la e programmation des threads. La suite du texte va se consacrer ` clairer les points suivants : ae 1. Gestion des tches esclaves (paragraphes 2.1, 2.2, 2.3, 2.4) a 2. Gestion de descripteurs multiples (paragraphes 2.5, 2.6) 3. Fonctionnement des processus en arri`re plan ou daemon (parae graphe 3)

2.1

Gestion des tches esclaves a

La gestion des tches esclaves signales dans le paragraphe 1 induit que a e le programme serveur est capable de grer plusieurs actions concourantes, e cest ` dire qui ont un comportement qui donne lillusion ` lutilisateur que a a sa requte est traite dans un dlai raisonnable, sans devoir patienter jusqu` e e e a lach`vement de la requte prcdente. e e e e Cest typiquement le comportement dun syst`me dexploitation qui ore donnance des processus entre-eux pour donner ` chacun deux un peu de la a puissance de calcul disponible ( time-sharing ). La dmarche qui parait la plus naturelle pour implmenter ces tches e e a esclaves est donc de tirer partie des proprits mmes de la gestion des ee e processus du syst`me dexploitation. e Sur un syst`me Unix lusage de processus est une bonne solution dans un e premier choix car ce syst`me dispose de primitives (APIs) bien rodes pour e e les grer, en particulier fork(), vfork() et rfork(). e Nanmoins, comme le paragraphe suivant le rappelle, lusage de procese sus ls nest pas la panace car cette solution comporte des dsagrments. e e e Deux autres voies existent, non toujours valables partout et dans tous les cas de gure. La premi`re passe par lusage de processus lgers ou threads e e e (paragraphe 2.3), la deuxi`me par lusage du signal SIGIO qui autorise ce que lon nomme la programmation asynchrone (paragraphe 2.4). Pour conclure il faut prciser que des tches esclaves ou concourantes e a peuvent sexcuter dans un ordre alatoire mais pas ncessairement en mme e e e e temps. Cette derni`re caractristique est celle des tches parall`les. Autree e a e ment dit, les tches parall`les sont toutes concourantes mais linverse nest a e pas vrai. Concr`tement il faut disposer dune machine avec plusieurs procese seurs pour avoir, par exemple, des processus (ou des threads kernel , si elles sont supportes) qui sexcutent vraiment de mani`re simultane donc sur e e e e

308

e Elments sur les serveurs des processeurs dirents. Sur une architecture mono-processeur, les tches e a ne peuvent tre que concourantes ! e

2.2

fork, vfork et rfork

Il ne sagit pas ici de faire un rappel sur la primitive fork() examine e dans le cadre du cours sur les primitives Unix, mais dexaminer lincidence de ses proprits sur larchitecture des serveurs. ee Le rsultat du fork() est la cration dun processus ls qui ne di`re de e e e son p`re que par les points suivants : e 1. Le code de retour de fork : 0 pour le ls, le pid du ls pour le p`re e 2. Le numro de processus (pid) ainsi que le numro de processus du e e processus p`re (ppid) e 3. Les compteurs de temps (utime, stime, . . .) qui sont remis ` zro a e 4. Les verrous (flock) qui ne sont pas transmis 5. Les signaux en attente non transmis galement e Tout le reste est doublonn, notamment la stack et surtout la heap e qui peuvent tre tr`s volumineuses et donc rendre cette opration pnalisante e e e e voire quasi rdhibitoire sur un serveur tr`s charg (des milliers de processus e e e et de connexions rseaux). e Si le but du fork dans le processus ls est deectuer un exec immdiatement, alors il tr`s intressant dutiliser plutt le vfork. Celui-ci e e e o ne fait que crer un processus ls sans copier les donnes. En consquence, e e e durant le temps de son excution avant le exec le ls partage strictement e les mmes donnes que le p`re (` utiliser avec prcaution). Jusqu` ce que le e e e a e a processus rencontre un exit ou un exec, le processus p`re reste bloqu (le e e vfork ne retourne pas). En allant plus loin dans la direction prise par vfork, le rfork3 autorise la continuation du processus p`re apr`s le fork, la consquence est que deux e e e processus partagent le mme espace dadressage simultanment. Largument e e dappel du rfork permet de param`trer ce qui est eectivement partag ou e e non. RFMEM, le principal dentre eux, indique au noyau que les deux processus partagent tout lespace dadressage. Si cette derni`re primitive est tr`s riche de potentialits4 , elle est e e e galement dlicate ` manipuler : deux (ou plus) entits logicielles excutant e e a e e le mme code et accdant aux mmes donnes sans prcaution particuli`re e e e e e e vont tr`s certainement converger vers de srieux ennuis de fonctionnement si e e le droulement de leurs oprations nest pas rigoureusement balis. e e e En eet, le soucis principal de ce type de programme multi-entits est e de veiller ` ce quaucune de ses composantes ne puisse changer les tats de a e
clone() sous Linux dailleurs limplmentation actuelle des threads sous Linux emploie cette primitive e avec des avantages et beaucoup dinconvnients par rapport ` ce que prvoit la norme e a e Posix et ` la gestion des processus a
4 3

Processus lgers, les threads e sa mmoire simultanment. Autrement dit, il faut introduire presque oblie e gatoirement un mcanisme de smaphore qui permette ` lune des entits e e a e logicielles de vrouiller lacc`s ` telle ou telle ressource mmoire pendant le e e a e temps ncessaire ` son usage. e a Cette opration de vrouillage elle-mme pose probl`me, parceque e e e e les entits logicielles pouvent sexcuter en parall`le (architecture multie e e processeurs) et donc il est indispensable que lacquisition du smaphore qui e prot`ge une ressource commune soit une opration atomique, cest ` dire qui e e a sexcute en une fois, sans quil y ait possibilit que deux (ou plus) entits e e e logicielles tentent avec succ`s de lacqurir. Cest toute la probl`matique des e e e mutex5 .

309

2.3

Processus lgers, les threads e

Les processus lgers ou threads sont une ide du milieu des annes e e e 80. La norme Posix a pos les bases de leur dveloppement durable en 1995 e e (Posix 1.c), on parle dans ce cas des pthreads. Lide fondatrice des threads est de ne pas faire de fork mais plutt e o de permettre le partage de lespace dadressage ` autant de contextes a dexcution du mme code6 que lon souhaite. e e
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 crer un nouveau processus on cre une nouvelle thread, ce e e qui revient (en gros) ` ajouter un nouveau contexte dexcution sur la pile a e syst`me dans le processus. Lusage de mutex (cf paragraphe 2.2) est fore tement recommand pour srialiser les acc`s aux sections critiques du e e e code. Sur une machine ayant une architecture mono-processeur, le premier type de threads est susant, mais d`s que la machine est construite avec une are 7 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

e Elments sur les serveurs des congurations ` plusieurs processeurs chacun tant lui-mme compos de a e e e plusieurs curs) lusage de threads grables par le noyau devient beaucoup e plus intressant car il utilise au mieux les ressources de la machine : un mme e e processus pourrait avoir deux threads, une sexcutant sur chacun des deux e processeurs (ou plus bien entendu, sil y a plus de processeurs). Le principe tant pos, on distingue plusieurs familles dimplmentation. e e e Dun cot il y a les threads user land cest ` dire qui sont e a compl`tement gres par le processus utilisateur et de lautre les threads e ee kernel , qui sont gres par le noyau. Ces derni`res threads sont supportes ee e e par les constructeurs de machines ` architectures parall`les, traditionnellea e ment Sun (Solaris), Ibm (Aix), et Compaq (ex Digital, avec True64) et plus rcemment Hewlett-Packard avec la version 11.xx dHP-UX. Le probl`me est e e tr`s complexe et chaque constructeur dveloppe ses propres stratgies. e e e Du cot des OS libres le probl`me a stagn un peu pendant des annes e e e e car il monopolise beaucoup de programmeurs de haut niveau, non toujours disponibles pour des tches au long court. . .Nanmoins la famille des BSD a e (FreeBSD et NetBSD principalement) bncie depuis peu dune gestion e e oprationnelle des threads. e Les threads Linux utilisent rfork qui est simple et tr`s ecace. Cette e approche nest pas satisfaisante car chaque thread est excute dans un proe e cessus dirent (pid dirent donc) ce qui est contraire aux recommandations e e POSIX, dune part, et dautre par ne permet pas dutiliser les r`gles de prioe rit dnies galement par POSIX. Une application avec un grand nombre e e e de threads prend lavantage sur les autres applications par le fait quelle consomme en temps cumul bien plus que les autres processus mono-thread. e Les threads de FreeBSD sont devenues tr`s ecaces et performantes dee puis la version 7 du syst`me, ` lissue dun travail de longue haleine dont e a lhistorique se trouve sur cette page http://www.freebsd.org/smp/. Conclusion : Les threads user land ne sexcutent que sur un seul processeur quelle e que soit larchitecture de la machine qui les supporte. Sur une machine de type smp/cmt il faut que le syst`me dexploitation supporte les threads kere nel pour quun mme processus puisse avoir des sous-tches sur tous les e a processeurs existants.

Programmation asynchrone

311

2.4

Programmation asynchrone

Les paragraphes qui prc`dent utilisent un processus ou une thread pour e e pouvoir eectuer au moins deux tches simultanment : couter le rseau et a e e e traiter une (ou plusieurs) requte(s). Dans le cas dun serveur peu sollicit e e il tout ` fait envisageable de mettre en uvre une autre technique appelle a e programmation asynchrone . La programmation asynchrone sappuie sur lusage du signal, SIGIO (SIGPOLL sur syst`me V), ignor par dfaut, qui prvient le processus dune e e e e activit sur un descripteur. e La gestion des entres/sorties sur le descripteur en question est alors e traite comme une exception, par un handler de signaux. e Le signal SIGIO est ignor par dfaut, il faut demander explicitement au e e noyau de le recevoir, ` laide dun appel ` la primitive fcntl. Une fois activ, a a e il nest pas reu pour les mmes raisons selon le protocole employ : c e e UDP : Arrive dun paquet pour la socket e Une erreur TCP : Une demande de connexion (attente sur un accept) qui arrive Une dconnexion e Une demi-dconnexion (shutdown) e Arrive de donnes sur une socket e e Fin de lmission de donnes (buer dmission vide) sur une socket e e e Une erreur O` lon voit que cette technique, du moins en TCP, ne peut tre envisage u e e pour que pour des serveurs peu sollicits. Un trop grand nombre dinterrupe tions possibles nuit ` lecacit du syst`me (changements de contexte). De a e e plus la distinction entre les causes du signal est dicile ` faire, donc ce signal a en TCP est quasi inexploitable. Conclusion : La dnomination programmation asynchrone base seulement sur e e lusage du signal SIGIO (versus SIGPOLL) est abusive. Pour tre vraiment e asynchrones, ces oprations de lecture et dcriture ne devraient pas tre ase e e sujetties au retour des primitives read ou write9 . Cette technique permet lcriture du code de petits serveurs bas sur le protocole UDP (En TCP e e les causes de rception dun tel signal sont trop nombreuses) sans fork ni e thread.

La norme POSIX permet un tel comportement avec les primitives aio read et aio write

312

e Elments sur les serveurs

2.5

La primitive select

Un serveur qui a la charge de grer simultanment plusieurs sockets (sere e veur multi-protocoles par exemple, comme inetd. . .) se trouve par construction dans une situation o` il doit examiner en mme temps plusieurs descripu e teurs (il pourrait sagir aussi de tubes de communication). Il est absolument dconseill dans cette situation de faire du polling. e e Cette activit consisterait ` examiner chaque descripteur lun apr`s lautre e a e dans une boucle innie qui devrait tre la plus rapide possible pour tre la e e plus ractive possible face aux requtes entrantes. Sous Unix cette opration e e e entra une consommation exagre des ressources cpu, au dtriment des ne ee e 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`s que lun des descripteurs devient actif (il peut y en avoir plusieurs e ` la fois) le noyau rveille le processus et lappel de select rend la main a e ` la procdure appelante avec susemment dinformation pour que celle-ci a e puisse identier quel(s) descripteur(s) justie(nt) son rveil ! e
#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 dcrit dans <sys/types.h>, ainsi que les macros e 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 immdiatement apr`s avoir test les descripteurs. Tous les e e e champs de timeout doivent tre ` 0 ( polling dans ce cas). e a 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 prt, et en tout cas jamais au del` de la valeur prcise par timeout e a e e (cf MAXALARM dans <sys/param.h>). Si timeout est un pointeur NULL, la primitive est bloquante jusqu` a ce quun descripteur soit prt (ou quun signal intervienne). e Remarque : select travaille au niveau de la micro-seconde, ce que ne fait pas sleep (seconde), do` un usage possible de timer de prcision. u e readfs descripteurs ` surveiller en lecture. a writefs descripteurs ` surveiller en criture. a e exceptfs Ce champ permet de traiter des evnements exceptionnels sur les e descripteurs dsigns. Par exemple : e e Donnes out-of-band sur une socket. e Contrle du statut sur un pseudo-tty ma o tre. maxfd prend ` lappel la valeur du plus grand descripteur ` tester, plus a a un. Potentiellement un syst`me BSD (4.3 et versions suivantes) permet e dexaminer jusqu` 256 descripteurs. a A lappel, le programme prcise quels sont les descripteurs ` surveiller e a dans readfs, writefs et exceptfs. Au retour, la primitive prcise quels sont les descripteurs qui sont e actifs dans les champs readfs, writefs et exceptfs. Il convient donc de conserver une copie des valeurs avant lappel si on veut pouvoir les rutiliser ultrieurement. La primitive renvoie -1 en cas derreur (` tester e e a systmatiquement) ; une cause derreur classique est la rception dun signal e e (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

e Elments sur les serveurs

2.6

La primitive poll

La primitive poll (System V) permet la mme chose que la primitive e select, mais avec une approche dirente. e
#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 oprations dentre/sortie. -1 indique une condition derreur. 0 e e indique lexpiration dun dlai ( time-out ). e 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`trent respectivement les souhaits du programmeur et ce que le e noyau retourne. On utilise principalement : POLLIN POLLOUT POLLERR POLLHUP nfds Taille du vecteur. timeout Est un compteur de millisecondes qui prcise le comportement de e poll : Le nombre de millisecondes est positif strictement. Quand le temps prvu est coul, la primitive retourne dans le code de lutilisateur e e e mme si aucun vnement nest intervenu. e e e Le nombre de millisecondes est INFTIM (-1), la primitive est bloquante. 0. La primitive retourne immdiatement. e On sapperoit immdiatement que la valeur du param`tre de timeout c e e 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 implments le plus souvent sous forme de e e daemons10 . La raison principale est que ce type de processus est le plus adapt e ` cette forme de service, comme nous allons lexaminer. a

3.1

Programmation dun daemon

Les daemons sont des processus ordinaires, mais : ils ne sont pas rattachs ` un terminal particulier (ils sont en arri`re e a e plan ) ; ils sexcutent le plus souvent avec les droits du super-utilisateur , e voire, mieux, sous ceux dun pseudo-utilisateur sans mot de passe ni shell dni. e ils sont le plus souvent lancs au dmarrage du syst`me, lors de e e e lexcution des shell-scripts de conguration (par exemple ` partir de e a /etc/rc) ; ils ne sarrtent en principe jamais (sauf bien sr avec le syst`me !). e u e La conception dun daemon suit les r`gles suivantes : e 1. Excuter un fork, terminer lexcution du p`re et continuer celle du e e e ls qui est alors adopt par init (traditionnellement cest le processus e N 1). Le processus ls est alors dtach du terminal, ce que lon peut e e visualiser avec un ps -auxw (versus ps -edalf sur un syst`me V) en e 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 rpertoire courant, gnralement la racine (/) ou tout autre e e e rpertoire ` la convenance de lapplication ; e a 4. Modier le masque de cration des chiers umask = 0 pour que le e troisi`me argument de open ne soit pas biais par la valeur du umask e e lorsque cette primitive sert aussi ` crer des chiers ; a e 5. Fermer tous les descripteurs devenus inutiles, et en particulier 0, 1 et 2 (entre et sorties standards nont plus de sens pour un processus e dtach dun terminal). e e le source ci-apr`s est un exemple de programmation de daemon, les appels e ` la fonction syslog font rfrence ` un autre daemon nomm syslogd que a ee a e nous examinons au paragraphe suivant.
Si lon en croit la premi`re dition de UNIX System Administration Handbook , e e 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

e Elments sur les serveurs

/* $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 dtach dun terminal, les daemons ne e e peuvent plus dlivrer directement de message par les canaux habituels e (perror. . .). Pour pallier ` cette dcience un daemon est spcialis dans a e e e 11 lcoute des autres daemons (coute passive :), il sagit de syslogd . e e Pour dialoguer avec ce daemon un programme doit utiliser les fonctionnalits que le lecteur trouvera tr`s bien dcrites dans man syslog, sinon e e e c le paragraphe 3.4 en donne un aperu rapide. La gure XIV.3 suivante schmatise le circuit de linformation dans le cas e dune utilisation de syslogd. Le chier /etc/syslog.conf est le chier standard de conguration du daemon syslogd. Il est constitu de lignes de deux champs : un dclencheur e e
11

Ce rle stratgique lui vaut dtre lanc le premier et dtre stopp le dernier o e e e e e

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 dclencheur sont remplies laction est excute, plus e e e prcisement : e Le dclencheur est un ltre qui associe un type de daemon avec un niveau e de message. Par exemple mail.debug signie les messages de niveau DEBUG pour le syst`me de routage du courrier. e Les mots clefs possibles pour le type de daemon sont auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp, et local0 ` local7. Une toile ( ) ` la place, signie nimporte quel a e a mot clef. Le niveau de message est lun des mots clefs suivants : emerg, alert, crit, err, warning, notice, et debug. Une toile ( ) signie nime porte lequel. Un point () spare les deux parties du ltre, comme dans e mail.debug. Dans les syslog plus volus ladministrateur a la possibilit de drouter e e e e tous les messages contenant un nom de programme ( !nom du prog) ou un nom de machine (+nom de machine) Laction est soit : Un chier dsign par un chemin absolu, comme /var/log/syslog. e e Une liste de logins dutilisateurs, comme root,fla. . . Un nom de machine distante (@machine.domaine.fr) Tous les utilisateurs connects avec une toile . e e

318

e Elments sur les serveurs

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 *.*

Rsultat de lexcution de diablotin sur la machine glups, et dans le e e 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 dclarer son intention dutiliser le syst`me de log en faisant appel ` la fonce e a tion openlog : logopt Donne la possibilit de prciser o` le message est envoys et dans e e u e quelle condition. facility Est ltiquette par dfaut des futurs messages envoys par syslog. e e e logopt LOG LOG LOG LOG CONS NDELAY PERROR PID description Ecriture sur /dev/console. Ouverture immdiate de la connexion avec syslogd. e 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`re les procdures batch. e e Tous les daemons du syst`me, comme gated. e Messages du noyau. Messages du gestionnaire dimprimante. Messages du gestionnaire de courrier. Messages du gestionnaire de news . Messages du daemon syslogd lui-mme. e Messages des processus utilisateur (defaut). Messages du syst`me de transfert de chiers. e Rserv pour un usage local. e e

319

Puis chaque appel ` la fonction syslog est compos dun message (gnr a e e ee par lapplication) et dun code de priorit, compos dun niveau durgence e e prcis par le tableau ci-dessous (niveaux dcroissants) et dune tiquette e e e e optionnelle, prise dans le tableau ci-dessus ; elle prime alors sur celle prcise e e 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 immdiate requise. e Probl`mes de matriels e e Erreurs. Messages davertissement. Messages qui ne sont pas des erreurs. Informations sans consquence. e Messages pour le debug.

Enn le closelog matrialise la n dutilisation de ce syst`me dans le e e code.

320

e Elments sur les serveurs

Exemple de daemon inetd

Dans cette partie nous allons tudier un serveur de serveurs nomm inetd e e qui est un tr`s bel exemple pour conclure ce chapitre. e Ce chapitre pourra se prolonger par la lecture du code source C dinetd.

4.1

Prsentation de inetd e

Sous Unix on peut imaginer facilement que chacun des services rseaux e oerts soient programms comme un daemon, avec une ou plusieurs sockets, e chacun surveillant son ou ses ports de communication. Un tel fonctionnement existe, gnralement repr par le vocabulaire e e ee stand alone . Avec cette stratgie, chaque service comme ftp , rlogin , e 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`me est que pour faire fonctionner les services de base du e rseau on devait maintenir en mmoire (primaire en ram ou secondaire e e sur la zone de swap ) un grand nombre de processus souvent compl`tement e inutiles ` un instant donn, simplement au cas ou. . . a e Linconvnient de cette stratgie est la consommation importante de rese e sources surtout avec le nombre croissant des services rseaux de base . e De plus, on peut remarquer que lancs au dmarrage de la machine, tous e e ces processus eectuent des oprations similaires (cf 3), seuls di`rent les e e traitements propres aux serveurs eux-mmes cest ` dire ceux qui rel`vent du e a e protocole de lapplication. La version 4.3 de BSD a apport une simplication en introduisant une e 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 ` un seul processus (celui dinetd) dattendre de multiples a demandes de connexions au lieu davoir 1 processus par type de connexion. Cette stratgie rduit dautant le nombre de processus. e e 2. Il simplie lcriture des serveurs eux-mmes, puisquil g`re toute la e e e prise en charge de la connexion. Les serveurs lisent les requtes sur leur e entre standard et crivent la rponse sur leur sortie standard. e e e Inetd est un serveur parall`le en mode connect ou data-gramme. De plus e e il combine des caractristiques particuli`res, puisquil est galement multie e e protocoles et multi-services. Un mme service peut y tre enregistr et accese e e sible en udp comme en tcp. Bien sr cela sous entend que le programmeur u de ce service ait prvu ce fonctionnement. e Le prix ` payer pour une telle souplesse est lev, inetd invoque fork a e e puis exec pour pratiquement tous les services quil ore (cf lecture de code). Sur les Unix ` architecture Berkeley, inetd est invoqu au dmarrage de a e e la machine, dans les scripts de lancement, /etc/rc par exemple. D`s le dbut e e de son excution il se transforme en daemon (cf paragraphe IV.5.3) et lit un e

Exemple de daemon inetd chier de conguration gnralement nomm /etc/inetd.conf. Ce chier e e e est en ASCII, il est lisible normalement par tous, cependant, sur certains sites et pour des raisons de scurit, il peut ne pas ltre. e e e La gure XIV.04 montre larchitecture gnrale (tr`s simplie) de fonce e e e tionnement.

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 de la mani`re suivante : e e Un # en dbut de ligne indique un commentaire, comme pour un shelle script. Les lignes vides ne sont pas prises en compte. Les lignes bien formes sont constitues de 7 champs. Chaque ligne bien e e forme dcrit un serveur. e e Description des champs : 1. Le nom du service, qui doit galement se trouver dans le chier e /etc/services. Cest grce ` lui que inetd connait le numro de a a e port ` employer a 2. Le type de socket, connecte (stream) ou non (dgram). e

322

e Elments sur les serveurs 3. Le protocole qui doit tre tcp ou udp et doit en tout cas se troue ver dans le chier /etc/protocols. Ce dernier chier donne une correspondance numrique aux dirents protocoles. e e 4. wait ou nowait suivant que le serveur est itratif ou parall`le. e e 5. Le nom du propritaire (pour les droits ` lexcution). Le plus e a e souvent cest root, mais ce nest pas une r`gle gnrale. e e e 6. Le chemin absolu pour dsigner lexcutable du serveur. e e 7. Les arguments transmis ` cet excutable lors du exec, il y en a e a 20 au maximum dans les implmentations Berkeley de inetd e (certaines re-critures, comme celle dHP, limitent ce nombre). e

Exemple de code serveur

Lexemple qui suit est le code en langage C dun serveur dcho multi e protocoles, cest ` dire qui fonctionne avec TCP et UDP simultanment sur a e un mme numro de port pour les deux protocoles. La contrainte est que e e lusage du serveur pour lun des protocoles nempche pas lacc`s au serveur e e pour lautre procotole. Ce serveur ore galement le choix de travailler en mode itratif ou en e e mode parall`le. Cette alternative est pilote ` partir de la ligne de commande, e e a donc au lancement du serveur (option -n ou -w). Il est intressant de remarquer que le cur du serveur est construit autour e de lusage de la primite select pour grer lcoute sur des sockets multiples, e e ici au nombre de deux. Dun point de vue plus gnral ce serveur reprend larchitecture globale e e du serveur de serveur inetd mais le simpliant ` lextrme, cest ` dire sans a e a 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 ` lAnnexe A, page 367. a Le programme serv2prot le lance avec les options suivantes : -p numro du port e -n mode concourant -w mode itratif e La fonction main (ligne 64 ` 178) contient la structure principale du a 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 effectue ligne 80 (usage de la fonction atoi pour transformer la cha e ne de caract`res en entier. e

5 Exemple de code serveur Ligne 102 Ouverture dune socket UDP utilisant le port nport lu sur la ligne de commande Ligne 103 Mme chose que ligne 102 mais avec une socket TCP. e Ligne 104 Cest le majorant de sudp et stcp (pour select). Ligne 106 Mise ` zro de tous les bits de la variable lect (fd set) a e 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 appelle. e 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 Entre de la boucle principale et innie du serveur e Ligne 114 Recopie dans alire des descripteurs ` surveiller en lecture a Ligne 116 Appel de la primitive select, sans time-out, donc bloquante indniment (cad jusqu` larrive dune demande de cnx) e a e Ligne 118 Si on arrive ` cette ligne cest quun signal a interrompu la pria mitive. Le rsultat du test est VRAI si la primitive a t interrompu e ee par un signal (par exemple SIGCHLD), le continue permet de retourner ` lvaluation de la condition de sortie de boucle immdiatement. a e e Sinon il sagit dune erreur non contournable, achage dun message et sortie. Ligne 124 select a renvoy le nombre de descripteurs qui justient son e retour en user land . Ce nombre est 1 ou 2 au maximum (seulement 2 sockets ` surveiller). On boucle jusqu` puisement du nombre de a a e descripteurs ` examiner. a Ligne 125 FD ISSET permet de tester si la socket stcp est active. Si oui alors on passe ` la ligne 127... a Ligne 127 Appel de accept pour la socket tcp. Il faut noter quon ne tient pas compter de ladresse du client rseau (deuxi`me et troisi`me argue e e ment). 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 + numro de port). e 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 tiquette, point dentre du goto qui se situe ligne e e 148. Ligne 145 On tente de lancer le service demand, ` excuter dans un proe a e cessus ls.

323

324

e Elments sur les serveurs Ligne 147 En cas derreur, si le fork a t interrompu par un signal, par ee exemple eaSIGCHLD, on eectue un saut inconditionnel ` ltiquette a e retry signale ligne 144. Sinon cest une vraie erreur ` traiter ! e a Ligne 151 Il sagit du code excut dans le processus ls. intcp==VRAI sil e e sagit de la socket TCP. Fermeture des sockets devenues inutiles (cest sock qui est utile). Ligne 155 Invocation la fonction qui g`re lcho en TCP e e Ligne 158 Fermeture de la socket TCP inutile. La socket UDP est indispensable. Ligne 159 Invocation de la fonction qui g`re lcho en UDP e e Ligne 161 Sortie du code pour les processus ls Ligne 162 Il sagit du code excut dans le processus p`re. Si le mode de e e e fonctionnement est itratif la socket en question (TCP vs UDP) doit e tre retire des descripteurs ` surveiller. Elle y sera remise lorsque le e e a processus ls qui traite la session en cours sera termin (cf fonction e PasDeZombi ligne 184). Ligne 165 Si on vient de traiter la socket TCP on fait le mnage avant la e prochaine boucle : fermeture de sock devenu inutile, retrait de stcp de alire et conservation dune trace du pid. Ligne 175 on dcrmente le nombre de descripteurs ` examiner. e e a Ligne 177 Fin de la boucle principale commence ligne 124. e 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, envoys par le noyau au processus p`re d`s que lun de ses ls fait exit. e e e Ligne 194 Usage de la primitive wait3 qui permet de faire une attente non bloquante (cest justi dans la mesure o` on a reu un SIGCHLD) de e u c la mort dun ls. Chaque appel renvoie le pid dun processus ls mort, sil ny a plus de processus ls mort ` examiner le retour est ngatif. a e Cest la condition de sortie de boucle. Ligne 195 Si on entre dans ce test, la variable pid contient le pid du ls termin et le mode de fonctionnement est itratif. e e Ligne 197 Pour la socket TCP on remet stcp dans les descripteurs ` sura veiller Ligne 202 Pour la socket UDP on remet sudp dans les descripteurs ` sura veiller Ligne 207 Certains OS ont besoin que lon repositionne le handler de signaux ` chaque rception du signal. Ce nest pas le cas des BSD. a e Ligne 215 FinCanonique est appelle sur rception du signal de n SIGHUP. e e Cest la sortie inconditionnelle du programme.

6 Bibliographie Les fonctions OuvrirSocketUDP et OuvrirSocketTCP sont une reformulation de ce qui a dj` t examin prcdemment. eaee e e e Les fonctions TraiterTCP et TraiterUDP ne prsentent pas de dicult e 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 comprhension des mcanismes internes : e e 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

e Elments sur les serveurs

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 prsentation suce cincte du protocole HTTP 1.0 et du serveur Apache qui lutilise. Le protocole HTTP1 est le protocole dapplication utilis pour vhiculer, e e entres autres, de lHTML2 sur lInternet. Cest le protocole le plus utilis en volume depuis 1995, devant FTP, e NNTP et SMTP ; il accompagne lexplosion de lutilisation du syst`me global e dinformation WorldWide Web. Depuis 1990, date dapparition du Web, le protocole HTTP volue e doucement mais surement. Il est longtemps rest sous forme de draft. La e premi`re version dploye largement a t la 1.0, dnie dans la RFC 1945 e e e ee e de mai 1996. Depuis le dbut du mois de janvier 1997 est apparue la version e 1.1, deux fois plus volumineuse pour tenir compte des nouvelles orientations de lusage du service. Aujourdhui ce protocole est tellement rpandu que pour bon nombre de e nouveaux utilisateurs du rseau, lInternet cest le web ! e Techniquement, lusage de ce protocole se conoit comme une relation c entre un client et un serveur. Le client, appel gnriquement un browser, e e e un User Agent, ou encore butineur de toile, interroge un serveur connu par e son url3 dont la syntaxe est bien dcrite dans la RFC 1738. Par exemple la cha de caract`res http://www.sio.ecp.fr/ est une ne e url ; il sut de la transmettre en tant quargument ` un quelconque outil a dexploration et celui-ci vous renverra (si tout se passe comme prvu !) ce qui e est prvu sur le serveur en question pour rpondre ` cette demande (car il e e a sagit bien dune requte comme nous le verrons plus loin dans ce chapitre). e
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 ` lcoute du rseau au moment o` la partie cliente ea e e u linterroge, utilise un port connu ` lavance. Le port 80 est ddi ociellement a e e 4 au protocole http , mais ce nest pas une obligation (cette dcision est prise ` e a la conguration du serveur). Lurl qui dsigne un serveur peut contenir dans e sa syntaxe le numro de port sur lequel il faut linterroger, comme dans : e http://www.sio.ecp.fr:11235/.

1.1

Exemple dchange avec http e

Le transport des octets est assur par TCP5 et le protocole est human e readable, ce qui nous autorise des essais de connexion avec le client tcp ` tout faire : telnet ! Bien entendu on pourrait utiliser un browser plus a classique, mais celui-ci grant pour nous le dtail des changes il ne serait e e e plus possible de les examiner.
$ telnet localhost 80 Trying... Connected to localhost. Escape character is ^]. GET / HTTP/1.0

Ce qui est tap par lutilisateur e et la rponse du serveur. e

La requte, suivie dune ligne e vide. HTTP/1.1 200 OK Enn la rponse du serveur, e Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix) que lon peut dcomposer en e Last-Modified: Sat, 10 Nov 2001 16:13:02 trois parties : GMT
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-tte MIME e 3. Des octets, ici ceux dune page crite en HTML. e Notons galement la decone nexion ` linitiative du sera veur, 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 change e

Lexemple qui prc`de est typique dun change entre le client et le sere e e veur : une question du client gn`re une rponse du serveur, le tout lors dune e e e connexion TCP qui se termine lors de lenvoi du dernier octet de la rponse e (clture ` linitiative du serveur). o a
4 5

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

Le protocole HTTP Le serveur ne conserve pas la mmoire des changes passs, on dit aussi e e e quil est sans tat, ou stateless. e La question et la rponse sont bties sur un mod`le voisin : le message e a e HTTP.
Message HTTP

329

B
Dbut du message

D C

gure XV.01 Les parties A, B et C forment len-tte du message, et D le corps. e A La premi`re ligne du message, est soit la question pose (request-line), e e soit le statut de la rponse (status-line). e La question est une ligne termine par CRLF, elle se compose de trois e champs : Une mthode ` prendre dans GET, HEAD, ou POST. e a GET Plus de 99% des requtes ont cette mthode, elle retourne e e linformation demande dans lURL (ci-dessous). e HEAD La mme chose que GET, mais seul len-tte du serveur e e est envoy. Utile pour faire des tests daccessibilit sans sure e charger la bande passante. Utile galement pour vrier de e e la date de fraicheur dun document (information contenue dans len-tte). e POST Cette mthode permet denvoyer de linformation au sere veur, cest typiquement le contenu dun formulaire rempli par lutilisateur. Une ressource que lon dsigne par une URL6 . e Par exemple http://www.site.org/. La version du protocole , sous forme HTTP-Numro de version. e Par exemple HTTP/1.1 ! La rponse. Cette premi`re ligne nest que le statut de la rponse, e e e les octets qui la dtaillent se trouvent plus loin, dans le corps du e message. Trois champs la composent, elle se termine par CRLF : La version du protocole , sous forme HTTP-Numro de version, e comme pour la question.
6

Uniform Resource Locator, consulter la RFC 1630

330

Anatomie dun serveur Web Statut Cest une valeur numrique qui dcrit le statut de la rponse. e e e Le premier des trois digits donne le sens gnral : e e 1xx 2xx 3xx 4xx 5xx Nest pas utilis Futur Use e Succ`s, laction demande a t comprise et excute e e ee e e correctement. Redirection. La partie cliente doit reprendre linterrogation, avec une autre formulation. Erreur cot client. La question comporte une erreur de e syntaxe ou ne peut tre accepte. e e Erreur cot serveur. Il peut sagir dune erreur interne, e due ` lOS ou ` la ressource devenue non accessible. a a

Phrase Cest un petit commentaire (Reason- Phrase) qui accompagne le statut, par exemple le statut 200 est suivi gnralement e e du commentaire OK ! B Cest une partie optionnelle, qui contient des informations ` propos du a corps du message. Sa syntaxe est proche de celle employe dans le coure rier lectronique, et pour cause, elle repecte aussi le standard MIME7 . e Un en-tte de ce type est constitu dune suite dune ou plusieurs lignes e e (la n dune ligne est le marqueur CRLF) construite sur le mod`le : e Nom de champ : Valeur du champ CRLF Eventuellement le marqueur de n de ligne peut tre omis pour le e sparateur ;. e Exemple den-tte MIME : e
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 ` laquelle le message a t envoy. Bien sr il sagit a ee e u de la date du serveur, il peut exister un dcalage incohrent si les e e machines ne sont pas synchronises (par exemple avec XNTP). e Server : Contient une information relative au serveur qui a fabriqu e la rponse. En gnrale la liste des outils logiciels et leur version. e e e Content-type : Ce champ permet didentier les octets du corps du message. Content-length : Dsigne la taille (en octets) du corps du message, e cest ` dire la partie D de la gure XV.1. a
7

Multipurpose Internet Mail Extension, consulter la RFC 1521

Le protocole HTTP Last-modified : Il sagit de la date de derni`re modication du e chier demand, comme lillustre le rsultat de la commande ll e e (voir aussi la co ncidence de la taille du chier et la valeur du champ prcdent). e e
-rw-r--r-1 web doc 139 Nov 10 17:13 index.html

331

ETag : Cest un identicateur du serveur, constant lors des changes. e Cest un moyen de maintenir le dialogue avec un serveur en particulier, par exemple quand ceux-ci sont en grappe pour quilibrer e la charge et assurer la redondance. C Une ligne vide (CRLF) qui est le marqueur de n den-tte. Il est donc e absolument obligatoire quelle gure dans le message. Son absence entraine une incapacit de traitement du message, par le serveur ou par e le client. D Le corps du message. Il est omis dans certains cas, comme une requte e avec la mthode GET ou une rponse ` une requte avec la mthode e e a e e 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 ` celui annonc dans len-tte, e a e e plus prcisement dans le champ Content-Type. e Par exemple : Content-Type : text/html = Le corps du message contient des octets ` interprter comme ceux dune page crite en HTML. a e e Content-Type : image/jpg = Le corps du message contient des octets ` interprter comme ceux dune image au format jpeg a e

332

Anatomie dun serveur Web

URIs et URLs

Le succ`s du web sappuie largement sur un syst`me de nommage des e e objets accessibles, qui en uniformise lacc`s, quils appartiennent ` la mae a chine sur laquelle on travaille ou distants sur une machine en un point quelconque du rseau (mais suppos accessible). Ce syst`me de nommage univere e e sel est lurl (Uniform Resource Locator RFC 1738) driv dun syst`me e e e de nommage plus gnral nomm uri (Universal Resource Identier e e e RFC 1630). La syntaxe gnrale dun(e) url est de la forme : e e <scheme> :<scheme-specic-part> Succintement la scheme est une mthode que lon spare ` laide du e e a caract`re : dune cha de caract`res ascii 7 bits dont la structure est e ne e essentiellement fonction de la scheme qui prc`de et que lon peut imaginer e e comme un argument. Une scheme est une squence de caract`res 7bits. Les lettres a ` z, e e a les chires de 0 ` 9, le signe +, le . et le - sont admis. Majuscules a et minuscules sont indirencis. e e Exemples de schemes : http, ftp, le, mailto, . . .Il en existe dautres (cf la RFC) non indispensables pour la comprhension de cet expos. e e 8 Globalement une url doit tre encode en ascii 7 bits sans caract`re e e e de contrle (cest ` dire entre les caract`res 20 et 7F), ce qui a comme o a e consquence que tous les autres caract`res doivent tre encods. e e e e La mthode dencodage transforme tout caract`re non utilisable direce e tement en un triplet form du caract`re % et de deux caract`res qui en e e e reprsente la valeur hexadcimale. Par exemple lespace (20 hex) doit tre e e e cod %20. e Un certain nombre de caract`res, bien que thoriquement reprsentables, e e e sont considrs comme non srs (unsafe) et devraient tre galement enee u e e cods de la mme mani`re que ci-dessus, ce sont : e e e % < > " # { } | \ ^ ~ [ ] Pour un certain nombre de schemes (http. . .) certains caract`res sont e rservs car ils ont une signication particuli`re. Ce sont : e e e ; / ? : @ = & Ainsi, sils apparaissent dans lurl sans faire partie de sa syntaxe, ils doivent tre encods. e e

2.1
8

Scheme http

Une url avec la scheme http bien forme doit tre de la forme : e e
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 numro de port. Sil nest pas prcis, la valeur 80 est prise par e e e dfaut. e path Cest un slecteur au sens du protocole http. e searchpath Cest ce que lon appelle la query string, autrement dit la cha dinterrogation. ne ` A lintrieur de ces deux composantes, les caract`res / ; ? sont rservs, e e e e ce qui signie que sils doivent tre employs, ils doivent tre encods pour e e e e viter les ambigu es. e t ` Le ? marque la limite entre lobjet interrogeable et la query string. A lintrieur de cette cha dinterrogation le caract`re + est admis comme e ne e raccourci pour lespace (ascii 20 hex). Il doit donc tre encod sil doit tre e e e utilis en tant que tel. e De mme, ` lintrieur de la query string le caract`re = marque la e a e e sparation entre variable et valeur, le & marque la sparation entre les couples e e variable = valeur. Exemple rcapitulatif : e
http://www.google.fr/search?q=cours+r%E9seaux\&hl=fr\&start=10\&sa=N

333

Notez le cod %E9, cest ` dire le caract`re de rang 1416+9 = 233. e e a e On peut galement observer quatre variables q, hl, start et sa dont la e signication peut tre partiellement devine, mais dont le remplissage reste e e ` la charge du serveur en question. a Le rle de la cha search est celui de ce que lon appelle une CGI ou o ne Common Gateway Interface, cest ` dire un programme qui eectue le lien a entre le serveur interrog et des programmes dapplication, ici une recherche e dans une base de donnes. Nous examinons succinctement le principe de e fonctionnement de tels programmes page 347.

334

Anatomie dun serveur Web

Architecture interne du serveur Apache

Cette partie se consacre ` ltude du fonctionnement du serveur Apache9 . a e Pour comprendre les mcanismes internes dun tel serveur il est absolue ment ncessaire de pouvoir en lire le code source, cette contrainte exclu les e produits commerciaux. Au mois de mars 2002, dapr`s le Netcraft Web Server Survey10 le e serveur le plus utilis (55%) est tr`s majoritairement celui du projet Apache. e e Dapr`s ses auteurs, le serveur Apache est une solution de continuit au e e serveur du NCSA11 . Il corrige des bugs et ajoute de nombreuses fonctionnalits, particul`rement un mcanisme dAPI pour permettre aux administrae e e teurs de sites de dvelopper de nouveaux modules adapts ` leurs besoins e e a propres. Plus gnralement, tout ce qui nest pas strictement dans les ate e tributions du serveur (gestion des processus, gestion mmoire, gese tion du rseau) est trait comme un module dextension. Le chier e e apache 1.3.23/htdocs/manual/misc/API.html de la distribution standard apporte des prcisions, le serveur http://www.apacheweek.com/ pointe e galement sur grand nombre de documents tr`s utiles. e e Le serveur Apache introduit galement la possibilit de serveurs multie e domaines (domaines virtuels), ce qui est fort apprci des hbergeurs de sites. e e e

3.1

Environnement dutilisation

La gure XV.2 qui suit, synthtise lenvironnement dutilisation. e

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 galement une source intressante dinformations e e 10 http://www.netcraft.com/survey/ 11 National Center for Supercomputing Applications Universit de lIllinois, aux e Etats Unis

Architecture interne du serveur Apache Le serveur se met en uvre simplement. La compilation fournit un excutable, httpd, qui, pour sexcuter correctement, a besoin des trois e e chiers ASCII de conguration : srm.conf, access.conf, httpd.conf. Cest en fait dans celui-ci que sont eectus lessentiel des ajustements locaux e ` la conguration standard. a Lors de lexcution, trois chiers sont modis12 : e e 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-dmarrage ` chaud du serveur, ou avec SIGTERM pour e a mettre n ` son activit. a e access log (CustomLog) Qui contient le dtail des acc`s clients. Ce chier e e peut devenir tr`s volumineux. e error log (ErrorLog) Qui contient le dtail des acc`s infructueux et des e e ventuels probl`mes de fonctionnement du serveur. e e Le daemon httpd est soit du type (ServerType) standalone ou si son invocation est occasionnelle, ` la demande pilot par inetd (cf page 4). a e Il dmarre son activit par ouvrir le port (Port) dsign dans la cone e e e guration, puis sexcute avec les droits de lutilisateur User et du groupe e Group. Sa conguration se trouve dans le rpertoire conf sous-rpertoire de e e ServerRoot. Les chiers accessibles par les connexions clientes, eux, se situent dans le rpertoire DocumentRoot qui en est la racine, cest ` dire vue e a comme / par les browsers clients. Le chier httpd.pid contient un numro de processus leader de groupe e car en fait le serveur Apache, d`s son initialisation, dmarre un certain e e nombre de processus, autant de serveurs capables de comprendre les requtes e 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 cres. ee 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 supprimes. e Cest le nombre minimum dinstances du serveur (non compris le processus ma tre) au dmarrage. e Cest le nombre maximum de clients (requtes HTTP) e simultans. Cette constante peut tre augmente en e e e fonction de la puissance de la machine.

335

Un processus joue le rle de rgulateur, du point de vue Unix cest un o e processus chef de groupe (leader). La commande ps permet de visualiser une situation oprationnelle : e
Entre parenth`ses le nom de la variable du le chier httpd.conf qui permet den e 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 de e reconnaitre (2794) car il est le p`re des autres processus (ce qui nimplique pas e 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 ` lcoute du rseau. Cest une situation qui a e e peut sembler paradoxale eu gard au nombre de processus ci-dessus, le code e nous fournira une explication au paragraphe suivant. La commande tail -1 logs/access.log fournit la trace de la derni`re e requte : e
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 dbut de ce e 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, les numros de lignes sont devenus de fait e e compl`tement faux. e

Ce qui nous intresse plus particuli`rement pour expliquer le fonctione e nement du serveur se trouve dans le rpertoire src/, sous rpertoire du e e rpertoire principal de la distribution : e
$ 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 rpertoire qui compte au moins 75 chier (wc -l *.[ch] e 27441 lignes) nous nous restreignons aux chiers essentiels dcrits dans le e 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`re et ses ls. e Puis, dans un autre paragraphe, nous examinerons plus particuli`rement e ce qui se passe lors dune connexion, avec le cas particulier de lexcution e 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 seul dsigne ce type e e 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 intressant mcanisme de buers cha es, utilis tout au long du code d`s e e n e e lors quil y a besoin dallouer de la mmoire. e ... 1523 ... setup_prelinked_modules();

Les dirents modules du serveurs sont ajouts dans une liste cha ee. e e n 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 ` 0 si le serveur est invoqu depuis inetd 14 . Son mode a e de fonctionnement le plus ecace reste avec ce param`tre ` 1 (voir le cours e a sur inetd), que nous supposons ici. La fonction standalone main (ligne 1362) prpare le processus ` son fue a tur rle de serveur. Pour bien comprendre le cette fonction, il faut imaginer o quelle est invoque au dmarrage, et ` chaud, pour lire et relire la cone e a guration. Ligne 1369 , la variable one process = 0 (sinon le processus est en mode debug) occasionne lappel ` la fonction detach (ligne 876). Celle-ci a transforme le processus en leader de groupe avec la succession bien connue fork + setsid (pour plus de dtails, voir le cours sur les e daemons). Ligne 1374 , la fonction sigsetjmp enregistre la position de la pile et ltat du masque dinterruption (deuxi`me argument non nul) dans e e e a restart buffer. Tout appel ultrieur ` siglongjmp forcera la reprise de lexcution en cette ligne. e 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 ` tous les proa cessus du groupe. Cette disposition nest utile que dans le cas dun re-dmarrage ` chaud. La variable pgrp est initialise par la fonction e a e detach (ligne 876), elle contient le PID du chef de groupe. Lintret davoir un groupe de processus est que le signal envoy ` son e ea leader est automatiquement envoy ` tous les processus y apparteea nant. Chaque processus qui reoit ce signal, sil est en mesure de le traiter, c e appelle la fonction just die qui excute un exit(0) (ligne 943). Donc tous les ls meurent, sauf le chef de groupe. Ligne 1390 , lappel ` la fonction reclaim child processes() eectue aua tant de wait quil y avait de processus ls, pour viter les zombis. e 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 t modis. ee e
Cette alternative est dcide dans le chier httpd.conf, conguration du param`tre e e e ServerType
14

Architecture interne du serveur Apache Ligne 1401 accept mutex init (ligne 166) fabrique un chier temporaire (/usr/tmp/htlock.XXXXXX), louvre, rduit son nombre de lien ` 0, de e a telle sorte quil sera supprim d`s la n du processus. Ce chier est le e e verrou dacc`s ` la socket principale, comme nous lexaminerons un peu e a plus loin. Ligne 1402 reinit scoreboard (ligne 596) Cette fonction remet ` zro, a e ou cre (setup shared mem ligne 432) la zone de mmoire commune e e entre le chef de groupe et ses processus ls. Cette zone mmoire est, e soit un segment de mmoire partage (IPC du syst`me V), soit de la e e e mmoire rendue commune par un appel ` la primitive mmap (Le choix e a est eectu par configure qui analyse les possibilits du syst`me, avant e e e compilation du serveur). La taille de cette zone est de HARD SERVER LIMIT sizeof(short score) octets, la structure short score, dnie e 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 contrle les serveurs ls. tre o HARD SERVER LIMIT dnit le nombre maximum de connexions actives, e donc dinstances de serveur, ` un instant donn. En standard cette a e valeur est 150, elle peut tre augmente dans le chier de conguration e e httpd.conf (voir ci-dessus au paragraphe II.1) Enn la gure XV.4 montre son rle stratgique. o e Ligne 1413 (on suppose listeners = NULL), apr`s avoir initialis une e e structure dadresse, appel ` la fonction make sock (ligne 1298). Cellea ci cre et initialise une socket, et, dtail important, appelle par deux e e fois setsockopt, ce qui mrite un commentaire : e ... 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`gle dexclusivit suivie par bind(2) e e pour lattribution dun port ne sapplique plus : un processus peut se servir dun mme port pour plusieurs usages dirents (comme e e par exemple le client ftp qui attaque les port 21 et 20 du serveur avec le mme port local), voire mme des processus dirents (cest e e e le cas ici) peuvent faire un bind avec le mme port sans rencontrer e 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 au paragraphe II.1 (netstat) e sans lexpliquer, voila qui est fait !

340

Anatomie dun serveur Web SO KEEPALIVE Indique ` la couche de transport, ici TCP, quelle doit a mettre ` interval rgulier (non congurable) un message ` destie a e a nation de la socket distante. Que celle-ci ny rponde pas et la proe chaine tentative dcriture sur la socket se solde par la rception e e 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) prvoit le comportement lors de la e rception des signaux : e SIGHUP SIGTERM Appel de restart Appel de sig term

Ligne 1438 et la suivante, cration dautant de processus ls quil en est e demand dans le chier de conguration (StartServers). La fonction e make child (1275) appelle fork, puis dans le ls modie le comportement face aux signaux SIGHUP et SIGTERM (just die appelle exit) avant dexcuter child main. e
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 Arrivs ` ce stade, il nous faut analyser lattitude des deux types de e a processus. Le processus ma tre Ligne 1444 dmarre une boucle innie de surveillance. Seule la rception e e et le traitement dun signal peut linterrompre.

Architecture interne du serveur Apache Ligne 1458 Ici, si le nombre de serveurs disponibles est infrieur au nombre e minimal requis, il y regnration de ceux qui manquent avec la fonction e e make child

341

Les processus esclaves Ligne 1139 La gestion de ces processus, autant de serveurs Web oprationnels, dbute avec lappel de la fonction child main. e e Ligne 1167 Dbut de la boucle innie qui g`re cette instance du serveur. e e Au cours dune boucle le serveur g`re lacceptation dune requte et e e son traitement. Ligne 1174 Gestion du SIGPIPE donc des clients qui dconnectent avant e lheure ! Ligne 1180 Si le nombre de serveurs libres (count idle servers) est suprieur ` la limite congure, ou si e a e Ligne 1182 le nombre de requtes traites par ce processus a atteint la lie e mite max requests per child, le processus sarrte de lui-mme. Cest e e lauto-rgulation pour librer des ressources occupes par un trop grand e e e nombre de processus serveurs inutiles. Ligne 1190 Lappel ` la fonction accept mutex on vrouille lacc`s ` la a e e a ressource dnie prcdement avec accept mutex init (ligne 166). Ce e e e vrouillage est bloquant et exclusif. Cest ` dire quil faut quun autre e a processus en dvrouille lacc`s pour que le premier processus sur la e e e liste dattente (gre par le noyau Unix) y acc`de. ee e Ce fonctionnement est assur suivant la version dUnix par la primitive e flock ou par la primitive fcntl. Les smaphore du Syst`me V (semget, semctl, semop. . .) assurent e e la mme fonctionnalit, en plus complet, ils sont aussi plus complexes e e ` mettre en uvre. a Cette opration est ` rapprocher de loption SO REUSEADDR prise ligne e a 1312. Il faut viter que plusieurs processus serveurs disponibles ne e rpondent ` la requte. Il ny a quun seul processus prt ` rpondre e a e e a e ` la fois et d`s que le accept (ligne 1217) retourne dans le code utilia e sateur la ressource est dvrouille (on suppose toujours listeners = e e e 0). Ligne 1221 La fonction accept mutex off dvrouille lacc`s ` la socket. e e e a Ligne 1245 read request lit la requte du client, donc un message HTTP. e Ligne 1247 process request fabrique la rponse au client, donc un autre e 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 requtes e

Le chier concern par la lecture de la requte est http protocol.c. e e La lecture de la premi`re ligne du message HTTP est assure par la e e 15 fonction read request line, ligne 329 . La lecture de len-tte MIME est assure par la fonction e e get mime headers, ligne 356. Attention, seule len-tte lue le corps du e message dans le cas de a mthode POST est lu plus tard, lors du traitement e du message, par le programme dapplication (CGI). Le chier concern par la formulation de la rponse est http request.c et e e la fonction principale process request, ligne 772. Celle-ci appelle en cascade process request internal, ligne 684. Cette derni`re eectue un certain nombre de tests avant de traiter eece tivement la requte. Parmi ceux-ci on peut relever, e Ligne 716 La fonction unescape url (util.c, ligne 593) assure le dcodage e des caract`res rservs et transcods comme il est spci par la RFC e e e e e e 1738. Ligne 723 La fonction getparents ltre les chemins (pathname) qui prtent ` confusion. e a Ligne 768 La fonction invoke handler est le point dentre dans le traitee ment de la requte. Cette fonction (http config.c, ligne 267) invoque e le programme (module) qui se charge de fabriquer la rponse, au vue e e du contenu du champ content type de la requte. Si celui est inexistant, comme dans notre exemple du paragraphe I, il est positionn par e dfaut ` la valeur html/text. e a
15

La mthode, lURL, et le protocole demand e 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 requte est e faite par le module cgi, dni dans le chier mod cgi.c. Le point dentre e e est la fonction cgi handler (ligne 207), cest ` dire celle qui appelle par a e invoke handler, vue au paragraphe ci-dessus. La lecture du code permet de dduire quil y a deux types de CGI, la e distinction est faite parle nom de la cgi elle-mme. e La gure XV.5 rsume les 2 situations possibles dexcution dune CGI. e e
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 lexcutable commence par nph-16 le comportement du sere veur http change. Dans le cas ordinaire (nom quelconque) les donnes transe mises depuis le client vers la cgi et rciproquement, passent par le processus e httpd et via un tube non nomm (pipe). e Dans le cas dune cgi nph, seules les donnes lues depuis le client (par e exemple avec la mthode POST) transitent par le processus httpd, la rponse, e e elle, est mise directement, ce qui amliore les performances en vitant une e e e squence lecture/criture inutile. Ce comportement est justi d`s que de e e e e gros volumes doctets sont ` transmettre au client (de grandes pages HTML, a des images. . .). Attention, dans ce dernier cas, cest ` la CGI de fabriquer lintgralit a e e du message HTTP, y compris len-tte MIME. A elle galement de grer la e e e dconnexion prmature du client (SIGPIPE). e e e Ces deux modes de fonctionnement ne sont pas clairement documents, e en fait il sagit dune caractristique du serveur du CERN, maintenue pour e assurer sans doute la compatibilit avec les applicatifs dj` crits. Il nest e ea e pas assur que cette possibilit existera dans les futures versions du serveur e e
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 ` fabriquer lenvironnement dexcution de la cgi Cette a e fonction (chier util script.c, ligne 126) compl`te les variables qui ne e dpendent pas du contenu de la requte, par exemple SERVER SOFTWARE, e e 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 cration dun processus ls, celui e qui nalement va excuter la cgi. Il faut remarquer le deuxi`me argument e e qui est un pointeur de fonction (cgi child), et le sixi`me qui est nul dans le e cas dune cgi du type nph. e script in et script out sont respectivement les canaux dentre et sortie des donnes depuis et vers le processus qui excute la cgi. Il parait donc e e logique que dans le cas dune cgi de type nph script in soit nul. Un mcanisme non encore analys duplique la sortie de ce processus vers le client e e plutt que vers le processus serveur. o Nous continuons la description du point de vue du processus p`re, donc e httpd. Ligne 295 et les suivantes, jusqu` la ligne 332, le processus lit ce que a le client lui envoie, si la mthode choisie est du type POST. Le contenu est e renvoy vers le processus ls, sans transformation : e

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 ` celui-ci dexploiter ce quenvoie le client, par a exemple le rsultat dune forme de saisie. e 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 renvoye au client (ligne 374). e Examinons maintenant comment se prpare et sexcute le processus ls : e e 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`res lignes prparent lenvironnement du futur proe e cessus 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 ` lenvironnement. a Cette derni`re variable joue un rle majeur dans la transmission des are o guments ` la cgi quand la mthode choisie est GET. En eet, dans ce cas, a e le seul moyen pour le client denvoyer des arguments ` la cgi est dutiliser a lURL, comme par exemple dans :
http://monweb.chez.moi/cgi-bin/nph-qtp?base=datas\&mot=acacia\&champ=.MC

La syntaxe de lURL prvoit le caract`re ? comme sparateur entre le e e e nom et ses arguments. Chaque argument est ensuite crit sous la forme : e nom = valeur Les arguments sont spars les uns des autres par le caract`re &. e e e

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 redirige vers le chier error log, et ligne e 138, la sortie standard du processus, cest la socket, donc envoye directement e 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 excute la cgi ! Bien sr, si le programme va au del` e u 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 Mthode GET, sans argument e

Dans ce paragraphe nous examinons ce qui se passe lors de lexcution e dune CGI tr`s simple (shell script, le source suit) que lon suppose place e e dans le rpertoire idoine, pour tre excute comme lors de la requte suie e e e e vante :
$ 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 requte tape par lutilisateur. e e Len-tte du message HTTP rene voy par le serveur. La ligne de e statut est gnre par la cgi car il e ee 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 gnrs dynamiquement par e ee 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 lentte MIME, rduite mais sue e sante. Le echo seul gn`re une e e 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 gnr par le moe ee REMOTE_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 Mthode GET, avec arguments e

Examinons maintenant un cas plus compliqu, avec des arguments transe mis, ou query string. Celle-ci est transmise ` la cgi via la variable denvia ronnement QUERY STRING. Cest ` la cgi de lanalyser puisque son contenu a rel`ve de lapplicatif et non du serveur lui-mme. Essayons de coder la cgi de e e lexemple :
http://www.chezmoi.tld/cgi-bin/query?base=datas\&mot=acacia\&champ=.MC

Premi`re version : e #!/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`s facilement sur les sites ftp le source dun outil nomm e e ea ne u cgiparse17 , parfaitement adapt ` lanalyse de la cha transmise. Do` la deuxi`me version : e
#!/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`, la fabrication du message a renvoy. La cgi renvoie ses octets e via un tube au serveur, cest donc celui-ci qui se charge de fabriquer un en-tte MIME. e

Puis le rsultat de lexcution : e e BASE=datas MOT=acacia CHAMP=.MC

4.3

CGI Mthode POST e

La mthode POST autorise un client ` envoyer au serveur une liste de e a couples variable=valeur. Chaque couple est spar des autres par une n e e de ligne, cest ` dire (CR,LF). a Cette mthode est bien adapte ` la transmission dinformations cole e a lectes cot client dans une forme18 de saisie, et dont le volume est variable. e e La liste des couples est crite dans le corps du message, par le programme e client, et ne fait pas partie de lURL, comme cest le cas pour la mthode e GET. Il y a videment une limite au nombre maximum doctets envoy par e e 19 le client, cest le serveur qui en xe la valeur . Du cot du client, il faut e prvenir le serveur, dans len-tte du message HTTP, de la taille du corps du e e 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`res si on compte la n de e ligne (CR+LF).

La rponse du serveur liste les e couples lus, ici un seul ! La variable globale REQUEST METHOD pourrait tre utilise pour adape e ter le comportement de la cgi en fonction de la mthode dee mande. e

Voir le tag FORM de lHTML HUGE STRING LEN qui vaut 8192 en standard, dnie dans le chier httpd.h e

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 tre constamment ` laut e a de la nouveaut dans ce domaine tr`s ractif quest celui du World Wide e e e Web. Les quelques rfrences bibliographique qui suivent illustrent ce cours, ee mais il est vident quelles sont bien insusantes pour couvrir tous les aspects e 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`me partie e Index gnral & Annexes e e

Index
tats de liens, 111 e 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 prive, 34 e adresse IP publique, 34 adresse physique, 11 AF, 254, voir Address Family AFNIC, voir Association Franaise pour le c Nommage Internet en Coopration e AfriNIC, 34 agent, voir SNMP algorithme Bellman-Ford, 111, 113, 120 Algorithme concourant - Mode connect, 306 e Algorithme concourant - Mode datagramme, 305 algorithme de routage, voir routage Algorithme Itratif - Mode e connect, 305 e Algorithme itratif - Mode e 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 Franaise pour c le Nommage Internet en Coopration, 3 e Authentication Header, 144 Autonomous systems, voir AS base de donnes distribue, e e 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^te e 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^te, 11 e fin, voir 10Base2 format dune trame, 10 paires torsades, voir e 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`s e Internet Fault management, 221 fcntl, 311 FD CLR, 312 FD ISSET, 312, 313 FD SET, 312 FD ZERO, 312 fen^tres glissantes, 98 e 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`s Internet, e 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 exprimentale, 36 e de broadcast, 37, 41 multicast, 13, 42--44 sous-rseaux, 38--39 e 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 Rassemblage, 53 e 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 itratif e 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, 90, 254, 260, 262 e datagramme, 83, 90, 254, 260 mode connect, 302 e 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 numro de port, 81, 252, 267, e 275 numro de service, voir numro e e 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 donne, 9 e donnes, 5, 14 e LLC, 14 MAC, 14 physique, 5 prsentation, 5, 226, 229 e rseau, 5 e 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 numro de port e 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 rpteur, 17--18 e e rseau dinterconnexion, 140 e rseau virtuel, 44 e Rseaux IP europen, 34 e e 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 rpteur e e 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 Rseaux IP europen e e 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 dcouverte de routeurs, 73 e 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^t des liens, 127 u DataBase Description paquet, 131 Designated router, 129 Down, 130 Exchange, 131 ExStart, 130 flooding, 124, 126 Hello, 131 hirarchie de routeurs, e 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 mtrique, 113 e 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 itratif, 301 e 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^tres e 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, 235 e 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-rseau e 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 de Berkeley, 26 e 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 cho , parall` le et multiprotocole (TCP , UDP). e e * * Compiler avec -DBAVARD pour des commentaires sur les tats du serveur . e * Le serveur se stoppe avec un SIGHUP . * * Compiler avec -DBSD sur les OS BSD. * */ # include <s t d i o . h> /* De toute fa on ! c */ # 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 ro de port > [-n|-w]\n\t-n : serveur e parall` le \n\t-w : serveur it ratif ( d faut )\n" e e e

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 ratif . e 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 ratif par d faut . */ e e opterr = 0 ; /* cf "man 3 getopt " */ while ( ( c=getopt ( argc , argv , "p:nw" ) ) != EOF ) { switch ( c ) { case p : /* Num ro du port. e */ nport = atoi ( optarg ) ; break ; case w : /* wait = It ratif . e */ iteratif = VRAI ; break ; case n : /* nowait = Parall` le .*/ e 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 but du server it ratif \n" ) ; e e else PRINTF ( "*** D but du server parall` le \n" ) ; e e sudp = OuvrirSocketUDP ( "" , nport ) ; stcp = OuvrirSocketTCP ( "" , nport , MAXQ ) ; c = max ( sudp , stcp ) + 1 ; /* Rang bit + ` gauche . */ a 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 lection de lentr e TCP\n" ) ; e e 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 lection de lentr e UDP\n" ) ; e e 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` re. e */ 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 u un SIGCHLD \n" ) ; c /* * WNOHANG : vite que wait3 soit bloquant , m^ me si des fils sont e e * encore en activit ( retour 0). e */ while ( ( pid=wait3 (&status , WNOHANG , ( CAST2 ) 0 ) ) > 0 ) if ( iteratif==VRAI ) if ( pid==tcp_pid ) { FD_SET ( stcp ,& lect ) ; PRINTF ( "***Lentr e TCP est r activ e \n" ) ; e e e

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 UDP est r activ e \n" ) ; e e e break ; } # ifndef BSD ( void ) signal ( SIGCHLD , PasDeZombi ) ; #endif } /* Selon OS */

/* * FinCanonique : On passe par l` en cas de fin normale . a */ void FinCanonique ( int nsig ) { PRINTF ( "*** Signal SIGHUP re u - Fin du serveur !\n" ) ; c exit ( EX_OK ) ; } /* * Serveur d cho , TCP. e */ 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 connexion de %s:%d\n" , inet_ntoa ( sclient . sin_addr ) , \ e 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. */