Le document présente une étude approfondie de la pile réseau sous GNU/Linux, détaillant son développement historique, les protocoles gérés, et l'architecture du réseau. Il aborde également les drivers réseau, leur fonctionnement, ainsi que les structures de données associées dans le noyau Linux. Enfin, l'étude examine les performances et la latence lors du traitement des paquets dans la pile TCP/IP.

1. Etude de la stack réseau sous GNU Linux Thierry GAYET (ALTEN) – 11/2007 – v1.0 – OSP 005 – Creative Common [email_address]

2. PLAN Historique Support du réseau dans le kernel Protocoles gérés Les drivers réseau La stack réseau Les primitives kernel pour le réseau Support d'IPv6 Administration réseau Références Liens

3. Historique Le développement de la couche réseau dans le noyau Linux a été orchestré par plusieurs programmeurs indépendants. Le but est d'implémenter un système qui soit au moins aussi performant que les autres tout en restant dans le domaine du logiciel libre. C'est avant tout le protocole TCP/IP qui a été développé avec des primitives de base par Ross Biro . Orest Zborowski produisit la première interface socket BSD pour le noyau GNU Linux. Le code fut ensuite repris par Alan Cox de Red Hat.

4. Protocoles gérés Linux gère une multitude de protocoles réseau : OSI 2 : couche liaison (Driver réseaux) : Ethernet ARP / RARP Tokenring ATM OSI 3 : couche réseau : OSI 4 : couche transport : TCP UDP Netbios IP ICMP IGMP ATM La pile réseau de GNU Linux peut être considéré comme la plus complète et disponible à ce jour. UNIX Unix domain sockets INET TCP/IP AX25 Amateur radio IPX Novell IPX APPLETALK Appletalk X25 X.25 Etc… ( define in include/linux/socket.h )

5. Protocoles gérés Disponibilité des fonctionnalités dans la pile réseau en fonction des versions du noyau Linux 2.2, 2.4 et 2.6 

6. Support du réseau dans le Kernel Modèle Internet de la pile réseau. Architecture de la pile réseau .  La pile réseau couvre le protocole TCP/IP de la couche liaison (drivers) jusqu'à la couche transport (sockets BSD).  D'un point de vue de Linux, la pile est localisée dans le noyau avec une API (les sockets BSD) pouvant être appelée depuis l'espace utilisateur. Couche matérielle Couche de liaison Couche réseau Couche transport Couche applicative Application utilisateur Driver réseau Protocoles réseaux Interface de diagnostique des devices Interface de diagnostique des protocoles Appels système Carte réseau Application User space Kernel space

7. LES DRIVERS RESEAUX Exemple de drivers réseau Les buffers de socket (sk_buffer = s oc k et buffer )

8. Les drivers réseaux : introduction Un driver réseau est la troisième catégorie de drivers Linux après les drivers de blocs et de caractères. Le fonctionnement d'une interface réseau au sein du système est assez similaire à un driver de blocs. Un driver de blocs est utilisé par le noyau pour transmettre ou recevoir des blocs de données. D'un point de vue similaire, un driver réseau s'enregistre auprès du noyau de Façon à pouvoir échanger des paquets de données avec l'extérieur. Il y a cependant une différence avec un driver de blocs qui consiste à ne pas avoir de point d'entrée dans le répertoire dédié aux devices /dev. Il n'est donc pas possible de mettre en application la règle qui veut que sous Unix / GNU Linux tout soit considéré comme un fichier. La différence la plus importante entre ces deux types de drivers est que le driver de blocs n'est utilisé que lorsque le driver y fait appel tandis qu'un drivers réseau reçoit les paquets réseau de façon asynchrone depuis l'extérieur. Ainsi, alors qu'un driver de blocs demande avant d'envoyer quelque chose au noyau, le driver réseau demande à pusher des données. 

9. Les drivers réseaux : découpage modulaire  http://docs.huihoo.com/linux/kernel/a1/index.html L'architecture réseau permet au noyau Linux de se connecter à d'autres système via le réseau. Il existe un certain nombre important de matériel ainsi qu'un nombre important de protocole supportés . Chaque objet réseau est représenté via une socket. Les sockets sont associées aux process dans le même sens que les i-nodes d'un système de fichiers peuvent être associées. Une socket peut être partagée par plusieurs processus. L'architecture réseau utilise le scheduler de process du noyau Linux schedule() pour suspendre ou reprendre un process en état d'attente de données (géré par un système de gestion du contrôle et du flow de données). De plus, la couche VFS apporte un système de fichiers logique (comme pour le cas de NFS ; il existe des possibilités en mode user via libfuse)

10. Interaction entre une carte réseau et le noyau : Toutes les cartes peuvent interagir avec le noyau de deux façon différentes : Polling : L e noyau vérifie le status du device à intervalle régulier de façon à vérifier s'il y a quelque chose à faire ; Interruptions : L a carte envoie un signal au noyau sous la forme d'une interruption pour lui indiquer qu'il y a quelque chose à faire. Matériel : elle accepte les paquets entrant en provenance des interfaces réseaux et les positionne directement en file d'entrée. Software ( NET_RX_SOFTIRQ) : elle exécute le handle de paquets de réception. Elle est responsable de la gestion des protocoles. Les paquets entrant sont gérés par cette interruption et placés dans une file d'attente. Les paquets à forwarder sont placés dans la file de sortie de l'interface de sortie. Les drivers réseaux : liens

11. Chargement d'un driver réseau dynamiquement dans le kernel  Kmod est le chargeur de module dans le noyau GNU Linux. Le chargement initialise le nom du module (argv[0]) à charger. Si au lieu d'utiliser insmod, modprobe est utilisé, kmod ira regarder la configuration /etc/modprobe.conf

12. Les drivers réseaux : enregistrement Machine à états pour l'enregistrement d'un device réseau.

13. Les drivers réseaux : exemple d'implémentation (old) #if defined(MODULE) && LINUX_VERSION_CODE > 0x20115 MODULE_AUTHOR(&quot;Donald Becker <becker@cesdis.gsfc.nasa.gov>&quot;); MODULE_DESCRIPTION(&quot;3Com 3c590/3c900 series Vortex/Boomerang driver&quot;); MODULE_PARM(debug, &quot;i&quot;); ... #endif ... #ifdef MODULE int init_module(void) { ... } #else int tc59x_probe(struct device *dev) { ... } #endif /* not MODULE */ ... static int vortex_scan(struct device *dev, struct pci_id_info pci_tbl[]) { ... #if defined(CONFIG_PCI) || (defined(MODULE) && !defined(NO_PCI)) ... #ifdef MODULE if (compaq_ioaddr) { vortex_probe1(0, 0, dev, compaq_ioaddr, compaq_irq, compaq_device_id, cards_found++); dev = 0; } #endif return cards_found ? 0 : -ENODEV; } ... #ifdef MODULE void cleanup_module(void) { ... ... ... } #endif Example de code issue du code source du drivers réseau ( drivers/net/3c59x.c) destiné au Noyau 2.2.14. Il y a un nombre important de #ifdef MODULE et de #if defined (MODULE). Cela est assez représentatif de l'ancienne façon de programmer qui définissait le fonctionnement d'un module dynamique en fonction de la façon dont il était compilé tel un module statique au sein De l'image d'un noyau.

14. Les drivers réseaux : exemple d'implémentation (new) static char version[] _ _devinitdata = DRV_NAME &quot; ... &quot;; static struct vortex_chip_info { ... } vortex_info_tbl[] _ _devinitdata = { {&quot;3c590 Vortex 10Mbps&quot;, ... ... ... } static int _ _init vortex_init (void) { ... } static void _ _exit vortex_cleanup (void) { ... } module_init(vortex_init); module_exit(vortex_cleanup); Dans cette nouvelle version, les directives de pré-processing ne sont plus nécessaires ce qui enlève tous les #ifdef et #endif. Cela le rend plus facile à lire pour les développeurs de drivers via l'utilisation d'un ensemble de macros ( _ _init , _ _exit , et _ _devinitdata ).

15. Les drivers réseaux : exemple d'implémentation (macros 1/2) Liste des sections de mémoire pouvant être initialisées par des macros dans les drivers réseau. La plupart de ces macros sont définies dans le header include/linux/init.h

16. Les drivers réseaux : exemple d'implémentation (macros 2/2) A utiliser par les structures de données marquées par le tag __exitcall. _exitdata Initialise une structure à la séquence de BOOT. _initdata Anciennement appelée par la routine de sortie du drivers lors de son déchargement. _ _exitcall Macro obsolète. _ _initcall Ensemble de routine pour modifier l'ordre de priorité dans les routines de virtualisation exécutées lors de la séquence de BOOT. core_initcall, postcore_initcall, arch_initcall, subsys_initcall, fs_initcall, device_initcall, late_initcall Appelée lorsque le composant kernel est déchargé du noyau. _ _exit Routine d'initialisation lors de la séquence de boot. _ _init Description Macro

17. Les buffer sk 1/4 Un paquet issu ou à destination du réseau n’est qu’une suite d’octets, un buffer, à émettre/recevoir. Il est associé dans le noyau Linux à une structure de contrôle de type sk_buff appelée sk_buffers (socket buffer). A cette structure est attaché un bloc mémoire contenant le buffer reçu ou à émettre. Lorsqu’un paquet doit être émis ou est reçu par la carte réseau, un sk_buff est créé. Cette structure de contrôle se compose notamment de : structures représentant les couches Ethernet, réseau et transport pointeurs pour la gestion du sk_buffer dans la liste des sk_buffers informations sur les périphériques (devices) d’entrée/sortie informations sur le type de paquet (broadcast, multicast, …) du buffer contenant le paquet à proprement parlé Des pointeurs *head, *data, *tail , et *end servent à la gestion du bloc mémoire associé au sk_buffer. head et end pointent respectivement sur le début et la fin du bloc mémoire. data pointe sur un en-tête du paquet en fonction de l’endroit où le paquet se situe dans la pile de protocoles. Par exemple un paquet capturé à l’aide d’un hook netfilter aura son pointeur data positionné sur le premier octet de l’en-tête IP. tail pointe sur le premier octet de bourrage du bloc mémoire (le bloc mémoire pouvant être plus grand que le paquet à stocker).

18. Description d'un bloc mémoire associé à un sk_buffer, l'un vide et l'autre initialisé avec un bloc mémoire initialisé avec un paquet : Les buffers sk 2/4 Il est possible de déplacer ces pointeurs pour, par exemple, positionner le pointeur data sur un en-tête différent. Il faut cependant garder à l’esprit qu’en mode noyau aucun contrôle n’est effectué sur les accès mémoire et qu’un plantage du noyau peut donc se produire du fait d’une manipulation hasardeuse de pointeur. Les fonctions pour manipuler les sk_buffers sont définies dans le fichier header linux/skbuff.h .

19. Les buffers sk 3/4 La structure du buffer_sk est géré via une liste doublement chaînée.

20. struct sk_buff_head { /* These two members must be first. */ struct sk_buff * next; struct sk_buff * prev; _ _u32 qlen; spinlock_t lock; }; Les buffers sk 4/4 Structure de données  Init. 

21. LA STACK RESEAU Architecture Circulation des paquets Routage Netfilter et réalisation d'un hook Contraintes pour l'embarqué

22. L'équipe de Netfilter et son leader actuel Patrick McHardy : Team Leader du projet Netfilter . The core Team du projet Netfilter.

23. Architecture La pile TCP/IP est directement implémentée dans le noyau. Les trames émises et reçues peuvent être amenées à traverser l’ensemble des couches (matérielles et logicielles) : Emission Réception Représentation des trames dans le Kernel Space les paquets sont manipulés par le noyau dans des structures de type sk_buffer. Le parcours d’une trame reçue ou à émettre, le traitement dans la pile IP peut être découpé en phases.

24. Circulation des paquets 1/2 Le traitement IP comporte 4 grandes phases :  La réception de trame : point d’entrée dans la couche IP pour les trames reçues sur les interfaces réseau.  Le routage : choix de la route à suivre par le paquet (réémission sur une autre interface/ réseau ou destination locale)  Le forwarding : contrôle du TTL et du MTU avant de passer à la phase de réémission.  L’émission : les paquets à émettre ou à réémettre passent par cette étape. Juste avant de quitter la couche IP l’en-tête Ethernet est complété.

25. Circulation des paquets 2/2 Couche transport OSI #4 Couche réseau OSI #3 Couche liaison OSI #2 Couche physique OSI #1 Cheminement des paquets dans les différentes couches de la stack réseau du kernel GNU Linux  Une carte réseau utilise 2 listes permettant de gérer les paquets entrants ( rx_ring ) et les paquets sortants ( tx_ring ) de la ou des interfaces réseaux. On peut ainsi distinguer la procédure d’émission de la procédure de réception. Pour les noyaux 2.2 et inférieurs, le traitement des trames est différent (ex : on ne retrouve pas les files tx et rx ).

26. Estimation du coût (temps et consommation mémoire) des recopie de paquets dans la pile réseau 1/5 1: Physical Layer 4: Transport 3: Network 7: Application 6: Presentation 5: Session TCP / IP vs. OSI model Le but étant de faire une estimation des recopies mémoire d'un paquet réseau de la carte réseau à la socket BSD  2: Data Link Interface Layer (Ethernet, etc.) Protocol Layer (TCP / IP) Socket layer Process

27. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 2/5 Application 1: sosend (……………... ) Couche des sockets BSD 2: tcp_output ( ……. ) Couche transport (TCP / UDP) 3: ip_output ( ……. ) Couche liaison (Ethernet Device Driver) 5: recvfrom(……….) 3: ip_input ( ……... ) 4: tcp_input ( ……... ) Couche protocole (IP) 4: ethernet_output ( ……. ) 2: ethernet_input ( …….. ) Carte réseau Résumé des couches  Queue de sortie Queue d'entrée

28. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 3/5 send (int socket, const char *buf, int length, int flags) Userspace Kernelspace sendto (int socket, const char *data_buffer, int length, int flags, struct sockaddr *destination, int destination _length) sendit (struct proc *p, int socket, struct msghdr *mp, int flags, int *return_size) sosend (struct socket *s, struct mbuf *addr, struct uio *uio, struct mbuf *top, struct mbuf *control, int flags )  uipc_syscalls.c  uipc_socket.c tcp_userreq (struct socket *s, int request, struct mbuf *m, struct mbuf * nam, struct mbuf * control )  tcp_userreq.c tcp_output (struct tcpcb *tp)  tcp_output.c TCP Layer

29. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 4/5 Réception d'un paquet

30. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 5/5 Algorigramme de la fonction tcp recvmsg 

31. Latence 1/2 L'étude de la latence des couches de la pile réseau TCP/IP sur l'envoi d'un paquet de 1024 octets en UDP et en TCP toutes les secondes montre les résultats suivant : Globalement le temps de recopie pour 1024 octets est de 1 µs, l'appel à la primitive système de la socket BSD est D'environ 2 µs et le temps de checksum en UDP est aussi de 2 µs. L'utilisation du DMA pour le transfert des données entre le device et la mémoire est un réel atout d'un point de vue des Performances. Le temps d'émission par le driver réseau d'un paquet réseau est en dessous des 2 µs mais il monte à environ 4 µs en réception du fait de la complexité inhérente du driver dans son mode réception. De plus, ce dernier mode possède une recopie mémoire non négligeable. UDP: Le temps d'émission pour 1024 octets en UDP quand le checksum est requis est de 18.9 µs alors qu'en réception cela Demande 35 µs. La capacité maximum d'envoie en UDP est donc de 433 Mbits/s alors qu'en réception le taux est de 234 Mbits/s. TCP: Avec le protocole TCP, l'envoie d'un paquet de 1024 octets met 22.5 µs et 36 µs en réception. La vitesse maximum en Émission est de 364Mbits/s alors qu'en réception elle est de 228Mbits/s. Lorsque le destinataire/expéditaire est local (localhost) la capacité maximale est d'environ 150 Mbit/s. Le temps global nécessaire dans le noyau GNU Linux pour les recopies mémoires, les checksums et les appels systèmes sont de 22% pour la partie émission en TCP et 16.7% pour la partie réception avec le même protocole. Idem pour UDP.

32. Latence 2/2 Résumé du benchmark précédent : Emission  Réception 

33. Spécificité du protocole ARP Par définition, les hooks netfilter servent à capturer des trames IP. Il n’est ainsi pas possible de voir les requêtes ARP. On peut cependant les capturer à la sortie du driver de la carte réseau au moment du choix du traitement à appliquer sur la trame en fonction du protocole identifié par le champs skb->protocol de la structure sk_buffer. Pour cela, à chacun de ces protocoles (IPv4, IPv6, ARP, BOOTP, ...) est associé une structurede type packet_type enregistré dans une file ( ptype_all ou la table de hash ptype_base ). La file ptype_all est utilisée pour capturer tous les paquets provenant (ou à destination) de toutes les interfaces réseaux. ptype_base est « hashée » par identifiant de protocole et permet de décider à quelle fonction est destiné le paquet (sk_buffer). Un sk_buffer peut « matcher » une ou plusieurs entrées dans la table. A l ‘émission, seuls les paquets de type ETH_P_ALL peuvent être capturés. Il est important de noter que, comme pour le chemin suivi par les trames dans le noyau, les fonctions utilisées dans le packet handling peuvent changer selon la version du noyau utilisé. Pour récupérer les trames ARP, il suffit d’enregistrer une structure packet_type dans une des listes ptype (ptype_base ou ptype_all) avec la fonction de callback dev_add_pack() (définie dans linux/netdevice.h ). Comme pour les netfilter hooks, il faut supprimer ce hook (packet handling) lorsque le module est retiré du noyau. Ceci se fait grâce à la fonction dev_remove_pack() ( linux/netdevice.h ). En enregistrant une fonction pour ETH_P_ALL notre packet type se retrouvera dans la liste ptype_all. On va ainsi récupérer toutes les trames arrivant (ou à destination) du driver de la carte réseau. Lorsque l’on récupère un sk_buffer avec ce type de hook, c’est en fait une copie du sk_buffer capturé sur laquelle on va travailler. La copie doit être détruite en fin de fonction avec la fonction kfree_skb() . Ce type de hook n’est donc pas destiné à modifier le paquet capturé. Position des hooks de type « packet handling » dans la chaîne de traitement des trames reçues ou à émettre.

34. Netfilter 1/2 L'intégration de netfilter, le firewall de Linux, se fait au travers de hook [1] , de la façon suivante. Les différents passages de fonctions s'effectuent via l'appel de NF_HOOK, une constante préprocesseur, avec les paramètres suivants : protocole du HOOK, exemple : PF_INET pour IPv4 ; chaîne, exemple : NF_IP_PRE_ROUTING, NF_IP_LOCAL_IN, etc ; pointeur vers une structure struct sk_buff, qui contient en fait des données relative au paquet ; interface d'entrée ; interface de sortie (peut être NULL) ; la fonction à appeler si le paquet n'est pas supprimé. Ainsi, si CONFIG_NETFILTER, n'est pas définie, la constante NF_HOOK est définie à : #define NF_HOOK(pf, hook, skb, indev, outdev, okfn) (okfn)(skb) se résumant à un simple appel de la fonction okfn, avec le paramètre skb. [1] on peut traduire hook par crochet, ou bien encore intercepteur

35. Netfilter 2/2 Un hook peut se définir comme un point d’accès dans une chaîne de traitement (par exemple : saisie au clavier, parcours de la pile TCP/IP…). Netfilter est un ensemble de hooks à l’intérieur du noyau Linux permettant aux modules noyau d’enregistrer des fonctions de callback dans la pile IP. Les trames ainsi capturées peuvent être analysées, jetées ou modifiées. Le firewall « natif » de linux iptables n’est qu’un module « sur-couche » de netfilter permettant de définir un système de règles de filtrage et masquerading (translation d’adresse) de trames IP à partir des hooks.

36. Netfilter : étude de cas 1/2 Ecriture d'un driver gérant un hook netfilter : // Fonction standard de chargement d'un driver sous GNU linux : int init_module () { nfho_tunnel_in.hook = hook_func_tunnel_in; nfho_tunnel_in.hooknum = NF_IP_PRE_ROUTING; nfho_tunnel_in.pf = PF_INET; nfho_tunnel_in.priority = NF_IP_PRI_FIRST; nf_register_hook(&nfho_tunnel_in); printk(&quot;\n\tNF_HOOK: Module instale\n\n&quot;); return 0; } // Fonction standard de déchargement d'un driver // sous GNU Linux : void cleanup_module () { printk(&quot;\n\t NF_HOOK: I'll be back ....\n\n&quot;); nf_unregister_hook(&nfho_tunnel_in); }

37. unsigned int hook_func_tunnel_in (unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_ device *out, int (*okfn)(struct sk_buff *)) { struct sk_buff* sb= *skb; struct iphdr* ip; struct net_device *dev= NULL; struct Qdisc *q; int len; len = sb->len; ip = sb->nh.iph; if((strcmp(&quot;eth0&quot;, in->name)==0) && (ip->daddr == ip1) ) { affic_skb(sb,0); sb->data -= 14; sb->len = len+ 14; memcpy(sb->data, hd_mac2, 14); dev = dev_get_by_name(&quot;eth1&quot;); spin_lock_bh (&(dev->queue_lock)); q = dev->qdisc; q->enqueue(sb,q); qdisc_run(dev); spin_unlock_bh(&(dev->queue_lock)); affic_skb(sb,1); return( NF_STOLEN ); } Netfilter : étude de cas 2/2 (SUITE) if((strcmp(&quot;eth1&quot;, in->name)==0) &&(ip->daddr == ip0)) { affic_skb(sb,0); sb->data -= 14; sb->len = len+14 ; memcpy(sb->data,hd_mac1, 14); dev = dev_get_by_name(&quot;eth0&quot;); spin_lock_bh (&(dev->queue_lock)); q = dev->qdisc; q->enqueue(sb,q); qdisc_run(dev); spin_unlock_bh(&(dev->queue_lock)); return NF_STOLEN; } return( NF_ACCEPT ); } Exemple d'implémentation de la fonction de hook utilisée dans le driver réseau.

38. Routage 1/5 : routage statique vs dynamique Routage statique vs routage dynamique Le paramétrage statique d'une interface se fait de différente façon selon les familles de linux. Sous GNU Debian/Ubuntu il y a le fichier /etc/network/interfaces qui contient le paramétrage des interfaces réseau alors que sous Redhat/Fedora/suze c'est le fichier /etc/sysconfig/network-scripts/ifcfg-eth0 Statique (paramétrage manuel) : $ ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up Par convention l'adresse réseau est celle la plus basse : 192.168.1.0. L'adresse de broadcast celle la plus haute : 192.168.1.255. Pour finir, la gateway est : 192.168.1.1. Au dela de cette convention, les adresses peuvent être choisis séparément. Pour un paquet réseau destiné à être émis sur le réseau, le routage statique consiste à utiliser l'adresse réseau (Ex: 192.168.1.X) pour savoir sur quelle interface envoyer le paquet. Lorsqu'aucune interface ne possède d'adresse en adéquation avec celle des interfaces, la table de routage envoie sur celle désigné pour être associée à la route par défault (plus précisément à la passerelle). Pour spécifier une route manuellement il suffit d'utiliser la commande suivante : $ route add default gw 192.168.1.1 eth0  Il ne s'agit pas ici de routage interne ou externe utilisé sur les WAN comme RIP ou OSPF mais d'un routage local sur un LAN. Définition d'une adresse virtuelle ou alias : $ ifconfig eth0 : 0 192.168.10.12 netmask 255.255.255.0 broadcast 192.168.10.255 $ route add -host 192.168.10.12 dev eth0 $ route add -host 192.168.10.14 dev eth0

39. Routage 2/5 Déclaration en statique d'une interface Debian/Ubuntu (/etc/network/interfaces) : auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 208.88.34.106 netmask 255.255.255.248 broadcast 208.88.34.111 network 208.88.34.104 gateway 208.88.34.110 RedHad/Fedora/Suse/Mandriva (/etc/sysconfig/network) : DEVICE=eth0 BOOTPROTO=static BROADCAST=XXX.XXX.XXX.255 IPADDR= XXX.XXX.XXX.XXX NETMASK=255.255.255.0 NETWORK= XXX.XXX.XXX.0 ONBOOT=yes  http://www.subnetmask.info/  http://www.subnet-calculator.com/ Déclaration dynamique (DHCP) d'une interface Debian/Ubuntu (/etc/network/interfaces) : auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp RedHad/Fedora/Suse/Mandriva (/etc/sysconfig/network) : DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp lo : Loopback interface (network within your system without slowing down for the real ethernet based network) eth x : Ethernet interface card wlan x : wireless card Dynamique : c'est un moyen supplémentaire (par rapport au routage statique) pour résoudre un nom de machine.

40. Fichier /etc/ resolv.conf : fichier de résolution des noms d'hôtes (hostname) Search nom-de_domaine.com : nom du nom de domaine (souvent celui du fournisseur d'accès à l'Internet). nameserver IPADDRESS : adresse IP du serveur DNS primaire, secondaire Cela configure la résolution avec le DNS (Domain Name Server) et les adresses IP. Si la configuration cliente utilise le protocole DHCP avec une interface réseau il sera possible de récupérer une configuration réseau complète : $ dhclient eth0 Fichier /etc/hosts : fichier de résolution adresse IP / Nom d'hôte IPADDRESS HOSTNAME : associe une adresse IP à un nom d'hôte. Ex : 127.0.0.1 localhost Ce système est utilisé pour les systèmes n'utilisant ni DNS, ni NIS ou bien lorsqu'il est nécessaire de forcer l'association d'une adresse IP à un nom d'hôte. Fichier: /etc/ nsswitch.conf : fichier de configuration vers le système base de données de noms via le protocole DNS, NIS, NIS+ Le système résoud premièrement les noms d'hôte par le fichier d'association /etc/hosts, ensuite essaye une résolution DNS (/etc/resolv.conf) et enfin recherche le serveur NIS/NIS+. Anciennement, il y avait une recherche dans les fichiers suivants /etc/nsswitch.conf, /etc/svc.conf, /etc/netsvc.conf …. suivant la distribution. Définition du hostname d'une machine : $ hostname : permet de connaître le nom du host courant. Pour le modifier : /etc/hostname (sous Debian/Ubuntu) Ou sous toutes les distrib : sysctl -w kernel.hostname=&quot; superserver &quot; Routage 3/5 : résolution de noms

41. Routage 4/5 : chemin de recherche Pour bien comprendre la fonction de recherche de route décrite plus tard, il faut commencer par comprendre comment les routes sont définies dans le noyau  Vérification de l'activation du routage : sudo sysctl -a | grep forward Activation du routage : echo &quot;1&quot; > /proc/sys/net/ipv4/ip_forward Inhibition du routage : echo &quot;0&quot; > /proc/sys/net/ipv4/ip_forward L'activation du routage (prise en compte dynamique, c'est-à-dire sans avoir à rebooter permet à la pile réseau de se comporter comme un &quot;routeur&quot; de paquets IP 

42. Routage 5/5 Le rôle de la couche IP est de décider comment orienter les paquets vers leur destination finale. Pour rendre cela possible, chaque interface sur le réseau est associée à un contexte réseau obtenu soit statiquement, soit dynamiquement. Une adresse IP est constituée de quatre nombres séparés par des points, comme `167.216.245.249'. Chaque nombre étant compris entre zéro et 255. Consultation de la table de routage : $ ip route ls 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.4 10.194.61.0/24 dev eth1 proto kernel scope link src 10.194.61.86 default via 10.194.61.1 dev eth1 default via 192.168.1.1 dev eth2 default via 192.168.1.1 dev eth0  http://mirabellug.org/wikini/upload/Documentations_routage.pdf $ /sbin/route –n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 10.194.61.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 10.194.61.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth2 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

43. Filtrage 1/9 : iptables / ip6tables http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables http://www.c-sait.net/cours/iptables.php http://www.linux-france.org/prj/inetdoc/telechargement/iptables-tutorial.pdf http://ploug.eu.org/doc/iptables-tutorial.pdf Sous Linux, les pares-feu, le NAT (traduction d'adresses réseau), les connexions réseau et l'accounting sont tous fournis par le sous-système Netfilter, aussi connu des administrateurs sous le nom de la commande iptables. L'interface d'iptables est l'une des plus sophistiquées que Linux propose. Grâce à elle et à son large éventail de règles, le filtrage des paquets entrant et sortant du réseau s'effectue de manière très souple et aussi finement que nécessaire. Les iptables apportent une réponse élégante aux administrateurs qui se posent des questions quant à la surveillance du trafic ICMP, la simplification de la gestion des connexions TCP, le choix du type de trafic à autoriser. Le filtrage du trafic nécessite, du moins pour les noyaux 2.4, l’emploi du module ip_tables. La commande lsmod permet de lire la liste des modules chargés par le noyau.

44. NetFilter avec IPtables n'a pas du tout la même architecture, le fonctionnement est différent, même si la syntaxe d'IPtables peut paraître proche de celle d'IPchains. En particulier, les chaînes INPUT et OUTPUT ne contrôlent pas tout ce qui entre et sort de la passerelle, routage compris, mais uniquement ce qui entre en direction de la passerelle elle même et sort de la passerelle elle même. Entendez par là que tout le trafic entre le réseau privé masqué par le NAT et l'Internet ne sera aucunement influencé par ces deux chaînes. Nous verrons en détail plus loin pourquoi et comment. Filtrage 2/9 : iptables / ip6tables Exemple d'une machine Linux disposant de deux interfaces Ethernet : Eth0 sur le réseau local (privé) Eth1 sur l'Internet via le modem câble du fournisseur d'accès. Cette interface, le plus souvent, sert de support à PPPoE. En tout état de cause, dans l'explication qui suit, quelles que soient l'origine et la destination des paquets, ils vont entrer dans la pile de protocoles IP par le même point et en sortir par le même autre point. Netfilter se présente comme une série de 5 &quot;hooks&quot; (points d'accrochage), sur lesquels des modules de traitement des paquets vont se greffer. Ces points sont: NF_IP_PRE_ROUTING NF_IP_LOCAL_IN NF_IP_FORWARD NF_IP_POSTROUTING NF_IP_LOCAL_OUT

45. Filtrage 3/9 : iptables / ip6tables La branche gauche représente le trajet des paquets qui entrent et qui sortent vers et depuis un processus local (SMB, FTP, HTTP etc.) La branche de droite représente le trajet des paquets qui traversent notre passerelle dans sa fonction de routeur. Diagramme simplifié de l'emplacement des hooks de netfilter avec lesquels iptables peut interragir   Attention toutefois, ces diagrammes sont faux, dans la mesure où ils sont largement simplifiés. Leur but est uniquement de montrer où Netfilter vient interagir avec la pile IP, en aucun cas il ne représente l'architecture complète de la pile IP !!

46. Ce que sait faire Netfilter : A travers ces cinq points d'insertion, Netfilter va être capable : D'effectuer des filtrages de paquets, principalement pour assurer des fonctions de Firewall. On pourra par exemple interdire à tous les paquets venant de l'Internet et s'adressant au port 80 (HTTP) de passer. Notre serveur APACHE est un serveur Intranet et ne doit pas être accessible depuis l'extérieur. D'effectuer des opérations de NAT (Network Address Translation) Ces fonctions sont particulièrement utiles lorsque l'on veut faire communiquer tout ou partie d'un réseau privé, monté avec des adresses IP privées (192.168.x.x par exemple) avec l'Internet. D'effectuer des opérations de marquage des paquets, pour leur appliquer un traitement spécial. Ces fonctionnalités sont particulièrement intéressantes sur une passerelle de réseau d'entreprise, un peu moins pour notre cas de réseau domestique. Netfilter dispose d'une commande à tout faire : IPtables. Cette commande va permettre, entre autres, d'écrire des chaînes de règles dans des tables. Il y a dans Netfilter trois tables qui correspondent aux trois principales : Filtrage 4/9 : iptables / ip6tables

47. La table &quot;Filter&quot; Cette table va contenir toutes les règles qui permettront de filtrer les paquets. Cette table contient trois chaînes: La chaîne INPUT. Cette chaîne décidera du sort des paquets entrant localement sur l'hôte. La chaîne OUTPUT. Ici, ce ne sont que les paquets émis par l'hôte local qui seront filtrés La chaîne FORWARD. Enfin, les paquets qui traversent l'hôte, suivant les routes implantées, seront filtrés ici. La table NAT Cette table permet d'effectuer toutes les translations d'adresses nécessaires. La chaîne PREROUTING. Permet de faire de la translation d'adresse de destination. Cette méthode est intéressante si l'on veut faire croire au monde extérieur, par exemple, qu'il y a un serveur WEB sur le port 80 de la passerelle, alors que celui-ci est hébergé par un hôte du réseau privé, sur le port 8080. La chaîne POSTROUTING. Elle permet de faire de la translation d'adresse de la source, comme du masquage d'adresse, la méthode classique pour connecter un réseau privé comme client de l'Internet, avec une seule adresse IP &quot;officielle&quot;. La chaîne OUTPUT. Celle-ci va permettre de modifier la destination de paquets générés localement (par la passerelle elle-même). La table MANGLE Cette table permet le marquage des paquets entrants (PREROUTING) et générés localement (OUTPUT). Le marquage de paquets va permettre un traitement spécifique des paquets marqués dans les tables de routage avec IPROUTE 2. Ceci nous mènerait trop loin. Si vous êtes intéressé par cette question, voyez à ce sujet le document: &quot; Linux 2.4 Advanced Routing HOWTO &quot;. Depuis la version 2.4.18 du noyau, d'autres tables ont été rajoutées sur tous les &quot;hooks&quot;. Nous avons ainsi à notre disposition les tables supplémentaires INPUT, POSTROUTING et FORWARD Filtrage 5/9 : iptables / ip6tables

48. Les chaînes Les chaînes sont des ensembles de règles que nous allons écrire dans chaque table. Ces chaînes vont permettre d'identifier des paquets qui correspondent à certains critères. Les cibles Les cibles enfin sont des sortes d'aiguillage qui dirigeront les paquets satisfaisant aux critères . Les cibles préconstruites sont : ACCEPT Les paquets qui satisfont aux critères sont acceptés, ils continuent leur chemin dans la pile, DROP Les paquets qui satisfont aux critères sont rejetés, on les oublie, on n'envoie même pas de message ICMP . Un trou noir, quoi. LOG C'est une cible particulière qui permet de tracer au moyen de syslog les paquets qui satisfont aux critères. Suivant les contextes, d'autres cibles deviennent accessibles, comme REJECT (similaire à DROP, mais avec envoi d'un message d'erreur ICMP à la source du paquet rejeté), RETURN, REDIRECT, SNAT, DNAT, MASQUERADE... En français, nous pourrons faire des choses de ce genre : Par défaut, tous les paquets qui entrent sont rejetés (DROP) Les paquets qui entrent par le port 80 sur l'interface eth0 sont acceptés Les paquets qui sortent par le port 80 sur l'interface eth0 sont acceptés etc. IPtables est en quelques sortes l'interface utilisateur de Netfilter. Dans sa partie &quot;visible&quot;, ça ressemble à IPchains, mais ici, ce n'est qu'une interface de commande de Netfilter. La syntaxe est plus complète et plus rigoureuse. Filtrage 6/9 : iptables / ip6tables

49. La table de filtrage C'est la table qui va permettre de filtrer tous les paquets qui entrent et sortent de notre machine. Il n'y a ici aucune modification de ces paquets, ils seront comparés à des critères définis dans la table Filter. Dans notre cas, il peut se passer deux choses différentes: Un paquet qui entre est destiné à un processus de l'hôte (serveur HTTP, FTP...). Un paquet qui entre est destiné à un autre réseau, c'est alors une fonction de routage. Filtrage 7/9 : iptables / ip6tables Un paquet entre dans notre machine. Peu importe par quelle interface il entre, il peut venir aussi bien du réseau local que de l'Internet. Il passe d'abord par la fonction de décision de routage. C'est elle qui va déterminer si le paquet est destiné à un processus local de l'hôte ou à un hôte sur un autre réseau. Si le paquet est destiné à l'hôte local: - Il traverse la chaîne INPUT - S'il n'est pas rejeté, il est transmis au processus impliqué. Ce processus va donc le traiter et éventuellement émettre un nouveau paquet en réponse. - Ce nouveau paquet traverse la chaîne OUTPUT - S'il n'est pas rejeté, il va vers la sortie. Si le paquet est destiné à un hôte d'un autre réseau: - Il traverse la chaîne FORWARD. - S'il n'est pas rejeté, il poursuit alors sa route. Avec IPtables, SEULS les paquets destinés à un process local traversent la chaîne INPUTSEULS les paquets issus d'un process local traversent la chaîne OUTPUTSEULS les paquets destinés au routage traversent la chaîne FORWARD.  La chaîne INPUT sera raccrochée au &quot;hook&quot; NF_IP_LOCAL_IN la chaîne OUTPUT au &quot;hook&quot; NF_IP_LOCAL_OUT et la chaîne FORWARD à NF_IP_FORWARD.

50. Initialisation de Netfilter Tapez successivement les commandes suivantes pour initialiser votre système: iptables -F iptables -X iptables -t nat -F iptables -t nat -X De cette manière, vous avez toutes vos chaînes vides, avec par défaut la règle &quot;ACCEPT&quot; iptables -L L'affichage va vous assurer que les trois chaînes INPUT, FORWARD et OUTPUT sont vides et ont bien la règle par défaut ACCEPT iptables -t nat -L L'affichage va vous assurer que les trois chaînes PREROUTING, POSTROUTING et OUTPUT sont vides et ont bien la règle par défaut ACCEPT. Mise en place de Masquerade iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE Où ppp0 représente l'interface connectée à l'Internet. Remplacez éventuellement, si votre configuration est différente. Ceci signifie en gros: Tout ce qui sort du routage (-A POSTROUTING) et qui doit passer vers l'Internet (-o ppp0) doit subir un masquage d'adresse (-j MASQUERADE) echo 1 > /proc/sys/net/ipv4/ip_forward Ceci pour être certain que votre noyau autorise le routage. Vous n'en avez pas besoin, si votre machine est configurée par défaut pour assurer le routage. Pour bien montrer que les chaînes INPUT et OUTPUT n'interviennent pas dans le routage, nous allons tout simplement leur mettre DROP comme règle par défaut (Attention, il faut que vos clients utilisent un DNS situé ailleurs que sur votre passerelle Linux, sinon, ça ne fonctionnera pas à cause du DNS) : iptables -P INPUT DROP iptables -P OUTUT DROP iptables -L (pour vérifier que INPUT et OUTPUT &quot;droppent&quot; bien tout ce qui passe). Filtrage 8/9 : iptables / ip6tables

51. Filtrage 9/9 : iptables / ip6tables Diagramme général permettant la gestion des paquets via le module iptables 

52. LES PRIMITIVES KERNEL POUR LE RESEAU

53. Primitives réseau du kernel 1/6 Check if a queue is empty : int skb_queue_empty (struct sk_buff_head * list); Reference buffer : struct sk_buff * skb_get (struct sk_buff * skb); Free an sk_buff : void kfree_skb (struct sk_buff * skb); Is the buffer a clone : int skb_cloned (struct sk_buff * skb); Is the buffer shared : int skb_shared (struct sk_buff * skb); Make a copy of a shared buffer : struct sk_buff * skb_unshare (struct sk_buff * skb, int pri); struct sk_buff * skb_peek (struct sk_buff_head * list_); Get queue length : __u32 skb_queue_len (struct sk_buff_head * list_); Queue a buffer at the list head : void __skb_queue_head (struct sk_buff_head * list, struct sk_buff * newsk); void skb_queue_head (struct sk_buff_head * list, struct sk_buff * newsk); Queue a buffer at the list tail : void __skb_queue_tail (struct sk_buff_head * list, struct sk_buff * newsk); void skb_queue_tail (struct sk_buff_head * list, struct sk_buff * newsk); Remove from the head of the queue : struct sk_buff * __skb_dequeue (struct sk_buff_head * list); struct sk_buff * skb_dequeue (struct sk_buff_head * list);

54. Primitives réseau du kernel 2/6 Insert a buffer : void skb_insert (struct sk_buff * old, struct sk_buff * newsk); Append a buffer : void skb_append (struct sk_buff * old, struct sk_buff * newsk); Remove a buffer from a list : void skb_unlink (struct sk_buff * skb); Remove from the tail of the queue : struct sk_buff * __skb_dequeue_tail (struct sk_buff_head * list); Remove from the head of the queue : struct sk_buff * skb_dequeue_tail (struct sk_buff_head * list); Add data to a buffer : unsigned char * skb_put (struct sk_buff * skb, unsigned int len); Add data to the start of a buffer : unsigned char * skb_push (struct sk_buff * skb, unsigned int len); Remove data from the start of a buffer : unsigned char * skb_pull (struct sk_buff * skb, unsigned int len); Bytes at buffer head : int skb_headroom (const struct sk_buff * skb); Bytes at buffer end : int skb_tailroom (const struct sk_buff * skb); Adjust headroom : void skb_reserve (struct sk_buff * skb, unsigned int len); Remove end from a buffer : void skb_trim (struct sk_buff * skb, unsigned int len);

55. Orphan a buffer : void skb_orphan (struct sk_buff * skb); Empty a list : void skb_queue_purge (struct sk_buff_head * list); void __skb_queue_purge (struct sk_buff_head * list); Allocate an skbuff for sending : struct sk_buff * dev_alloc_skb (unsigned int length); Copy a buffer if need be : struct sk_buff * skb_cow (struct sk_buff * skb, unsigned int headroom); Private function : void skb_over_panic (struct sk_buff * skb, int sz, void * here); void skb_under_panic (struct sk_buff * skb, int sz, void * here); void __kfree_skb (struct sk_buff * skb); Allocate a network buffer : struct sk_buff * alloc_skb (unsigned int size, int gfp_mask); Duplicate an sk_buff : struct sk_buff * skb_clone (struct sk_buff * skb, int gfp_mask); Copy an sk_buff : struct sk_buff * skb_copy (const struct sk_buff * skb, int gfp_mask); Copy and expand sk_buff : struct sk_buff * skb_copy_expand (const struct sk_buff * skb, int newheadroom, int newtailroom, int gfp_mask); Test if a device exists : int dev_get (const char * name); Primitives réseau du kernel 3/6

56. Primitives réseau du kernel 4/6 Run a filter on a socket : int sk_run_filter (struct sk_buff * skb, struct sock_filter * filter, int flen); Register ethernet device : struct net_device * init_etherdev (struct net_device * dev, int sizeof_priv ); Add packet handler : void dev_add_pack (struct packet_type * pt); Remove packet handler : void dev_remove_pack (struct packet_type * pt); Find a device by its name : struct net_device * __dev_get_by_name (const char * name); struct net_device * dev_get_by_name (const char * name); Find a device by its ifindex : struct net_device * __dev_get_by_index (int ifindex); struct net_device * dev_get_by_index (int ifindex); Allocate a name for a device : int dev_alloc_name (struct net_device * dev, const char * name); Allocate a network device and name : struct net_device * dev_alloc (const char * name, int * err); Device changes state : void netdev_state_change (struct net_device * dev); Load a network module : void dev_load (const char * name); Prepare an interface for use : int dev_open (struct net_device * dev);

57. Primitives réseau du kernel 5/6 Shutdown an interface : int dev_close (struct net_device * dev); Register a network notifier block : int register_netdevice_notifier (struct notifier_block * nb); Unregister a network notifier block : int unregister_netdevice_notifier (struct notifier_block * nb); Transmit a buffer : int dev_queue_xmit (struct sk_buff * skb); Post buffer to the network code : void netif_rx (struct sk_buff * skb); void net_call_rx_atomic (void (*fn) (void)); Register a SIOCGIF handler : int register_gifconf (unsigned int family, gifconf_func_t * gifconf); Set up master/slave pair : int netdev_set_master (struct net_device * slave, struct net_device *master); Update promiscuity count on a device : void dev_set_promiscuity (struct net_device * dev, int inc); Update allmulti count on a device : void dev_set_allmulti (struct net_device * dev, int inc); Network device ioctl : int dev_ioctl (unsigned int cmd, void * arg); Allocate an ifindex : int dev_new_index ( void);

58. Primitives réseau du kernel 6/6 Register a network device : int register_netdevice (struct net_device * dev); Complete unregistration : int netdev_finish_unregister (struct net_device * dev); Remove device from the kernel : int unregister_netdevice (struct net_device * dev);

59. LES SOCKETS BSD

60. Les sockets BSD 1/4 : introduction L'utilisation des primitives réseau ne se fait pas directement mais via une API disponible en userspace   http://www-adele.imag.fr/users/Didier.Donsez/cours/socketunix.pdf

61. Les sockets BSD 2/4 : les primitives système Les primitives de l'API des sockets BSD permettent d'implémenter tant des clients que des serveurs. • Côté Client (demandeur de la connexion - le socket est dit actif) : • crée un socket socket() • se connecte à une <adresse,port> connect() • lit et écrit dans le socket read(),recv();write(),send() • ferme le socket close() • Côté Serveur (en attente de connexion - le socket est dit passif) : • crée un socket socket() • associe une adresse au socket bind() • se met à l ’écoute des connexions entrantes listen() • accepte une connexion entrante accept() • lit et écrit sur le socket read(),recv();write(),send() • ferme le socket close() Fonctions de gestion du byteorder : char * inet_ntoa (const struct in_addr in) convertit la structure en adresse lisible unsigned long inet_addr (const char *cp) donne la forme condensée d’une adresse

62. Les sockets BSD 3/4 : données utiles Format générique des adresses de sockets : struct sockaddr { short sa_family; /* domaine AF_UNIX, AF_INET */ char sa_data[14]; /* adresse */ } Type associé aux adresses dans le domaine Unix : #include<sys.un.h> struct sockaddr_un { short sun_family; /* domaine AF_UNIX */ char sun_path[128]; /* chemin */ } Type associé aux adresses dans le domaine Internet : #include <netinet/in.h> struct in_addr { u_long s_addr; }; struct sockaddr_in { short sin_family; /* domaine AF_INET */ u_short sin_port; /* port de la socket */ struct in_addr sin_addr; /* N° IP de la machine format réseau */ char sin_zero[8]; /* 8 caractères nuls de bourrage */ }; Domaine d ’adresse : • Internet AF_INET, Unix AF_UNIX • mais aussi AF_OSI, AF_NS, AF_SNA, AF_CCITT, AF_APPLETALK, ... Type : • au niveau bas du protocole (exemple : datagramme IP) SOCK_RAW • en mode non connecté SOCK_DGRAM, SOCK_RDM, SOCK_SEGPACKET • en mode connecté SOCK_STREAM Protocole : • par défaut à 0, le système choisit le protocole • IPPROTO_UDP pour UDP avec les sockets de type SOCK_DGRAM, SOCK_RDM, SOCK_SEGPACKET • IPPROTO_TCP pour TCP avec une socket de type SOCK_STREAM • il existe d ’autres protocoles • dans le domaine AF_UNIX, il n ’y a pas de protocole

63. Les sockets BSD 4/4 Vue synthétique des couches montrant la localisation de l'API des sockets BSD   http://docs.huihoo.com/linux/kernel/a2/index.html

64. Admin & Tuning (depuis l'espace utilisateur) Tuning via /proc Commandes en ligne

65. Administration réseau ifconfig : permet de configurer les interfaces réseau résidentes dans le noyau Ex: sudo ifconfig eth0:1 192.168.5.96 netmask 255.255.255.0 /sbin/ifconfig eth0 down ifconfig eth0 inet6 add 2001:6ff:10:1::1000/64 route : permet la gestion de la table de routage Ex : route add default gw 192.168.0.1 netmask 0.0.0.0 route -A inet6 add default gw 2001:6ff:10:1::ffff ip (ou iproute2) : permet un gestion précise du réseau Ex : ip addr add 192.168.0.2/24 dev eth0 brodcast 192.168.0.255 ip addr ls ip link set dev eth0 up ip -6 addr add 2001:6ff:10:1::1000/64 dev eth0 ip -6 route add default via 2001:6ff:10:1::ffff iwconfig : permet la gestion des interfaces sans fil. ipsysctl : permet la gestion du procfs /proc/sys/net TCP tuning guide : http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html

66. /PROC $ ls /proc/sys/net/ipv4 conf/ ip_autoconfig tcp_abc tcp_low_latency Etc … $ ls /proc/sys/net/ipv4/route error_burst gc_elasticity gc_min_interval_ms x_delay min_delay redirect_load Etc …  http://linuxgazette.net/issue77/lechnyr.html $ echo &quot;0&quot; > /proc/sys/net/ipv4/conf/all/accept_redirects Listing des paramètres disponible dans le RAMFS du KERNEL : Affichage et modifications des paramètres : $ cat /proc/sys/net/ipv4/ip_forward 1 PROCFS est un RAMFS géré par le noyau. C'est un lien entre le monde user et le monde kernel.  http://mirrors.deepspace6.net/Linux+IPv6-HOWTO-fr/proc-net.html

67. SUPPORT D'IPV6

68. Le protocole IPv4 permet d'utiliser un peu plus de quatre milliards d'adresses différentes pour connecter les ordinateurs et les autres appareils reliés au réseau. Du temps des débuts d'Internet, quand les ordinateurs étaient rares, cela paraissait plus que suffisant. Il était pratiquement inimaginable qu'il y aurait un jour suffisamment de machines sur un unique réseau pour que l'on commence à manquer d'adresses disponibles. Une grande partie des quatre milliards d'adresses IP théoriquement disponibles ne sont pas utilisables , soit parce qu'elles sont destinées à des usages particuliers (par exemple, le multicast ), soit parce qu'elles appartiennent déjà à des sous-réseaux importants. En effet, d'immenses plages de 16,8 millions d'adresses, les réseaux dits de classe A, ont été attribuées aux premières grandes organisations connectées à Internet, qui les ont conservées jusqu'à aujourd'hui sans parvenir à les épuiser. Les Nord-Américains, et dans une moindre mesure les Européens, se sont partagé les plus grandes plages d'adresses, relativement peu nombreuses, tandis que les régions connectées plus tardivement, comme l'Amérique du Sud et surtout l'Asie, sont restées sur la touche. En conséquence, il y a aujourd'hui, principalement en Asie, une pénurie d'adresses que l'on doit compenser par des mécanismes comme la Traduction d'adresse et de port réseau (NAPT) et l'attribution dynamique d'adresses, et en assouplissant le découpage en classes des adresses ( CIDR ). Au vu de l'importance et de la croissance d'Internet, cette situation pose de plus en plus de problèmes. Il est de plus prévisible que la demande d'adresses Internet va augmenter dans les années à venir, même dans les régions du monde épargnées jusqu'ici, suite à des innovations comme les téléphones mobiles (et bientôt, sans doute, les automobiles et divers appareils) connectés à Internet. C'est principalement en raison de cette pénurie, mais également pour résoudre quelques-uns des problèmes révélés par l'utilisation à vaste échelle d'IPv4, qu'a commencé en 1995 la transition vers IPv6. Parmi les nouveautés essentielles, on peut citer : l'augmentation de 2 32 (soit environ 10^10) à 2 128 (soit environ 10^38) du nombre d'adresses disponibles ; des mécanismes de configuration et de renumérotation automatique ; IPsec , QoS et le multicast implémentés nativement ; la simplification des en-têtes de paquets, qui facilite notamment le routage. IPv6 1/3 : rappels

69. Une adresse IPv6 est longue de 16 octets, soit 128 bits, contre 4 octets (32 bits) pour IPv4. On dispose ainsi d'environ 3,4 × 1038 adresses, soit 340 282 366 920 938 463 463 374 607 431 768 211 456, soit encore, pour reprendre l'image usuelle, plus de 667 132 000 milliards (6,67 x 10^17) d'adresses par millimètre carré de surface terrestre. On abandonne la notation décimale pointée employée pour les adresses IPv4 (par exemple 172.31.128.1 ) au profit d'une écriture hexadécimale, où les 8 groupes de 16 bits sont séparés par un signe deux-points : 1fff : 0000 : 0a88 : 85a3 : 0000 : 0000 : ac1f : 8001 La notation canonique complète ci-dessus comprend exactement 39 caractères. Les 64 premiers bits de l'adresse IPv6 (préfixe) servent généralement à l'adresse de sous-réseau, tandis que les 64 bits suivants identifient l'hôte à l'intérieur du sous-réseau : ce découpage joue un rôle un peu similaire aux masques de sous-réseau d'IPv4. Différentes sortes d'adresses IPv6 jouent des rôles particuliers. Ces propriétés sont indiquées par le début de l'adresse, appelé préfixe . L'Internet IPv6 est défini comme étant le sous-réseau 2000::/3 (les adresses commençant par un 2 ou un 3). Seules ces adresses peuvent être routées. Toutes les autres adresses ne peuvent être utilisées que localement sur un même réseau physique (de niveau 2), ou par un accord privé de routage mutuel. Parmi les adresses de 2000::/3 , on distingue : Les adresses 6to4 ( 2002::/16 ) permettant d'acheminer le trafic IPv6 via un ou plusieurs réseaux IPv4. Les adresses du 6bone ( 3ffe::/16 ) pour l'expérimentation des interconnexions de réseaux IPv6. (Le 6bone n'est plus opérationnel depuis le 6/6/2006) IPv6 2/3 : rappels

70. IPv6 : 3/3 Test du support d'IPv6 : test -f /proc/net/if_inet6 && echo &quot;Support IPv6 available.&quot; Test si IPv6 est activé : lsmod |grep -w 'ipv6' && echo &quot;IPv6 enabled&quot; Résumé : http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-distributions.html Guide : http://deepspace6.net/sections/docs.html IPv6 théorie et pratique : http://livre.point6.net/index.php/Accueil La souche IPv6 a été intégrée officiellement au noyau depuis les versions 2.2, mais ces noyaux étaient incomplets et non conformes aux RFC. Les noyaux 2.4 sont plus corrects, mais eux aussi présentent quelques lacunes. Les noyaux 2.6 sont donc préférables ; ils intègrent un partie des développements du projet japonais USAGI, en particulier la sécurité (IPsec). Il faut aussi un noyau compilé avec l'option IPv6 (dans le noyau ou en module). Ce type de noyau est en général disponible dans toutes les distributions (au moins comme paquetage optionnel). Les applications, quand à elles, doivent utiliser une librairie C supportant IPv6. La GNU Libc 2 intègre correctement le support IPv6 à partir de la version 2.2 de la Glibc. Aussi, il est important d'utiliser une distribution Linux qui réponde à ces critères. Aujourd'hui la pile réseau est complètement opérationnelle avec IPv6.

71. Lectures de référence

72. Livres de référence sur TCP-IP  http://www.kohala.com/start/  http://www.uic.rsu.ru/doc/inet/tcp_stevens/ TCP/IP illustré – Volume 1 Editeur : Vuibert Édition : Nouv. éd (28 septembre 1998) Langue : Français ISBN-10: 2711786390 ISBN-13: 978-2711786398 TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols (Hardcover) Hardcover: 328 pages Publisher: Addison-Wesley Professional (January 29, 1996) Language: English ISBN-10: 0201634953 ISBN-13: 978-0201634952 Product Dimensions: 9.4 x 7.4 x 1 inches TCP/IP Illustrated, Volume 2: The Implementation (Addison-Wesley Professional Computing Series) (Hardcover) Hardcover: 1200 pages Publisher: Addison-Wesley Professional (February 10, 1995) Language: English ISBN-10: 020163354X ISBN-13: 978-0201633542 Product Dimensions: 9.3 x 7.7 x 1.9 inches

73. Liens 1/2 GNU Linux DDK : http://www.kroah.com/log/2006/05/24/#ddk Linux Device Drivers, Third Edition - Network Drivers : http://lwn.net/images/pdf/LDD3/ch17.pdf Ipsysctl tutorial : http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html Linux IP Networking : http://www.cs.unh.edu/cnrg/gherrin/linux-net.html UNIX IP Stack Tuning Guide : http://www.cymru.com/Documents/ip-stack-tuning.html Performance Analysis of the TCP/IP Stack of Linux Kernel : http://user.informatik.uni-goettingen.de/~kperf/gaug-ifi-tb-2005-03.pdf Linux IP Masquerade mini HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/IP-Masquerade-HOWTO.pdf Pont + pare-feu + DSL Mini-HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/Bridge+Firewall+DSL.pdf Mini How-To sur la configuration de l’aliasing IP sous Linux : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/IP-Alias.pdf Linux Network Administrators Guide : http://tldp.org/LDP/nag2/nag2.pdf The Linux Networking Overview HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/Networking-Overview-HOWTO.pdf TCP/IP Stack Hardening : http://www.cromwell-intl.com/security/security-stack-hardening.html Voyage au centre de la pile TCP/IP de Linux : http://asyd.net/docs/kernel/tcpip-stack.html A Measurement Study of the Linux TCP/IP Stack Performance and Scalability on SMP systems : http://www.cse.iitb.ac.in/~varsha/allpapers/mypapers/comswarepaper.pdf Berkeley sockets : http://en.wikipedia.org/wiki/Berkeley_sockets Linux TCP/IP Stack : http://www.cs.odu.edu/~csi/tcpipstack.ppt IP & Ethernet Interfaces : http://www.beyondlogic.org/etherip/ip.htm Implementation of TCP/IP in Linux : http://netweb.usc.edu/~rsinha/docs/tcp-ip.ppt Conception du sous-système réseau de linux : http://lacl.univ-paris12.fr/cegielski/reseau.html

74. Liens 2/2 Serial Line IP Implementation for Linux Kernel TCP/IP Stack : http://www.cse.iitb.ac.in/~bestin/pdfs/slip.pdf HOWTO du routage avancé et du contrôle de trafic sous Linux : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/lartc.pdf Linux NAT HOWTO : http://www.linux-france.org/prj/inetdoc/guides/NAT-HOWTO/ Linux Packet Filtering HOWTO : http://www.linux-france.org/prj/inetdoc/guides/packet-filtering-HOWTO/ Linux inetdoc : http://www.linux-france.org/prj/ Linux IPv6 HOWTO : http://cvs.tldp.org/go.to/LDP/LDP/users/Peter-Bieringer/Linux+IPv6-HOWTO.fr.pdf Nisnet (network emulator) : http://www-x.antd.nist.gov/nistnet/ TCPStackPerformance : http://www.gelato.unsw.edu.au/IA64wiki/TCPStackPerformance Anatomy of the Linux networking stack : http://www.ibm.com/developerworks/linux/library/l-linux-networking-stack/ Guide pratique du multicast sur les réseaux TCP/IP : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/Multicast-HOWTO.pdf Historique de la stack IP : http://www.linuxfranch-county.org/docs/guideLLLinux/implementation_reseau_5-2.pdf Fonctions réseau du noyau Linux : http://www.linux-france.org/prj/inetdoc/telechargement/interco.noyau.pdf Understanding Linux Network Internals : http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/ Algorithmic Complexity Attacks and the Linux Networking Code : http://www.enyo.de/fw/security/notes/linux-dst-cache-dos.html Linux Network Stack Walkthrough : http://gicl.cs.drexel.edu/people/sevy/network/Linux_network_stack_walkthrough.html Data Link Layer : http://lion.cs.uiuc.edu/courses/cs498hou_spring05/lectures/lecture8.pdf skb - Linux network buffers : http://ftp.gnumonks.org/pub/doc/skb-doc.html

75. MERCI DE VOTRE ATTENTION DES QUESTIONS ?