SlideShare une entreprise Scribd logo
1  sur  75
Télécharger pour lire hors ligne
Etude de la stack réseau sous GNU Linux Thierry GAYET (ALTEN) – 11/2007 – v1.0 – OSP 005 – Creative Common [email_address]
PLAN ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
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.
Protocoles gérés Linux gère une multitude de protocoles réseau :  OSI 2  : couche liaison (Driver réseaux) :  ,[object Object],[object Object],[object Object],[object Object],OSI 3  : couche réseau :  OSI 4  : couche transport :  ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
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  
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
LES DRIVERS RESEAUX ,[object Object],[object Object]
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.  
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)
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Les drivers réseaux : liens
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
Les drivers réseaux : enregistrement Machine à états pour l'enregistrement d'un device réseau.
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.
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  ).
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
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
Les buffer sk 1/4 ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
[object Object],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 .
Les buffers sk 3/4 La structure du buffer_sk est géré via une liste doublement chaînée.
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Les buffers sk 4/4 Structure de données   Init. 
LA STACK RESEAU ,[object Object],[object Object],[object Object],[object Object],[object Object]
L'équipe de Netfilter et son leader actuel Patrick McHardy  :  Team Leader du projet Netfilter . The core Team du projet Netfilter.
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.
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é.
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 ).
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
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
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
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
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  
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.
Latence 2/2 Résumé du benchmark précédent : Emission  Réception 
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.
Netfilter 1/2 ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[1]  on peut traduire hook par crochet, ou bien encore intercepteur
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.
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;NF_HOOK: Module instale&quot;); return 0; } // Fonction standard de déchargement d'un driver  // sous GNU Linux : void  cleanup_module () { printk(&quot; NF_HOOK: I'll be back ....&quot;); nf_unregister_hook(&nfho_tunnel_in); }
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],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.
Routage 1/5 : routage statique vs dynamique ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Routage 2/5 ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object], 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 ,[object Object]
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Routage 3/5 : résolution de noms
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   ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],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  
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
Filtrage 1/9 : iptables / ip6tables ,[object Object],[object Object],[object Object],[object Object],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.
[object Object],[object Object],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.  ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
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 !!
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Filtrage 4/9 : iptables / ip6tables
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Filtrage 5/9 : iptables / ip6tables
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Filtrage 6/9 : iptables / ip6tables
[object Object],[object Object],[object Object],[object Object],[object Object],Filtrage 7/9 : iptables / ip6tables ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],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.
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Filtrage 8/9 : iptables / ip6tables
Filtrage 9/9 : iptables / ip6tables Diagramme général permettant la gestion des paquets via le module iptables  
LES PRIMITIVES KERNEL POUR LE RESEAU
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);
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);
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
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);
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);
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);
LES SOCKETS BSD
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
Les sockets BSD 2/4 : les primitives système ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],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
Les sockets BSD 3/4 : données utiles ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
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
Admin & Tuning (depuis l'espace utilisateur) ,[object Object],[object Object]
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
/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
SUPPORT D'IPV6
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],IPv6 1/3 : rappels
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],IPv6 2/3 : rappels
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.
Lectures de référence
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
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
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
MERCI DE VOTRE ATTENTION DES QUESTIONS ?

Contenu connexe

Tendances

service NFS sous linux
 service NFS sous linux service NFS sous linux
service NFS sous linuxSouhaib El
 
Cours linux complet
Cours linux completCours linux complet
Cours linux completaubin82
 
Notes de cours et tp - Administation Systèmes
Notes de cours et tp  - Administation Systèmes Notes de cours et tp  - Administation Systèmes
Notes de cours et tp - Administation Systèmes Ikram Benabdelouahab
 
Les commandes CISCO (routeur)
Les commandes CISCO (routeur)Les commandes CISCO (routeur)
Les commandes CISCO (routeur)EL AMRI El Hassan
 
09 02 configuration du serveur nfs
09 02 configuration du serveur nfs09 02 configuration du serveur nfs
09 02 configuration du serveur nfsNoël
 
Firewalls
FirewallsFirewalls
Firewallsc0r3war
 
Firewall opensource et gestion de configuration pour l'infrastructure
Firewall opensource et gestion de configuration pour l'infrastructureFirewall opensource et gestion de configuration pour l'infrastructure
Firewall opensource et gestion de configuration pour l'infrastructureJohan Moreau
 
PostgreSQL sous linux
PostgreSQL sous linuxPostgreSQL sous linux
PostgreSQL sous linuxKhalid ALLILI
 
Fr E Routing Slm V40
Fr E Routing Slm V40Fr E Routing Slm V40
Fr E Routing Slm V40boukna abdou
 
Chargez un noyau linux sans reboot avec kexec
Chargez un noyau linux sans reboot avec kexecChargez un noyau linux sans reboot avec kexec
Chargez un noyau linux sans reboot avec kexecThierry Gayet
 
Compilation noyau linux depuis les sources
Compilation noyau linux depuis les sourcesCompilation noyau linux depuis les sources
Compilation noyau linux depuis les sourcesThierry Gayet
 

Tendances (20)

service NFS sous linux
 service NFS sous linux service NFS sous linux
service NFS sous linux
 
Cours linux complet
Cours linux completCours linux complet
Cours linux complet
 
2020 (1)
2020 (1)2020 (1)
2020 (1)
 
Ccna4
Ccna4Ccna4
Ccna4
 
Notes de cours et tp - Administation Systèmes
Notes de cours et tp  - Administation Systèmes Notes de cours et tp  - Administation Systèmes
Notes de cours et tp - Administation Systèmes
 
Les commandes CISCO (routeur)
Les commandes CISCO (routeur)Les commandes CISCO (routeur)
Les commandes CISCO (routeur)
 
09 02 configuration du serveur nfs
09 02 configuration du serveur nfs09 02 configuration du serveur nfs
09 02 configuration du serveur nfs
 
Rapport projet
Rapport projetRapport projet
Rapport projet
 
02 java-socket
02 java-socket02 java-socket
02 java-socket
 
Cours SNMP
Cours SNMPCours SNMP
Cours SNMP
 
Firewalls
FirewallsFirewalls
Firewalls
 
Firewall opensource et gestion de configuration pour l'infrastructure
Firewall opensource et gestion de configuration pour l'infrastructureFirewall opensource et gestion de configuration pour l'infrastructure
Firewall opensource et gestion de configuration pour l'infrastructure
 
Introduction aux-sockets
Introduction aux-socketsIntroduction aux-sockets
Introduction aux-sockets
 
PostgreSQL sous linux
PostgreSQL sous linuxPostgreSQL sous linux
PostgreSQL sous linux
 
Projet reseaux
Projet reseaux Projet reseaux
Projet reseaux
 
Fr E Routing Slm V40
Fr E Routing Slm V40Fr E Routing Slm V40
Fr E Routing Slm V40
 
Chargez un noyau linux sans reboot avec kexec
Chargez un noyau linux sans reboot avec kexecChargez un noyau linux sans reboot avec kexec
Chargez un noyau linux sans reboot avec kexec
 
Compilation noyau linux depuis les sources
Compilation noyau linux depuis les sourcesCompilation noyau linux depuis les sources
Compilation noyau linux depuis les sources
 
Cours syslog
Cours syslogCours syslog
Cours syslog
 
Linux Scripting
Linux Scripting Linux Scripting
Linux Scripting
 

En vedette

Medecin AnesthéSiste RéAnimateur El Haloui Leila
Medecin AnesthéSiste RéAnimateur   El Haloui LeilaMedecin AnesthéSiste RéAnimateur   El Haloui Leila
Medecin AnesthéSiste RéAnimateur El Haloui Leilagawronski
 
ErgothéRapeuthe Haas Sophie
ErgothéRapeuthe   Haas SophieErgothéRapeuthe   Haas Sophie
ErgothéRapeuthe Haas Sophiegawronski
 
Rechercher une publication scientifique dans les archives ouvertes
Rechercher une publication scientifique dans les archives ouvertesRechercher une publication scientifique dans les archives ouvertes
Rechercher une publication scientifique dans les archives ouvertesMagalie Le Gall
 
IngéNieur En MéCanique Brach LoïC
IngéNieur En MéCanique   Brach LoïCIngéNieur En MéCanique   Brach LoïC
IngéNieur En MéCanique Brach LoïCgawronski
 
Vente maison Lamorlaye
Vente maison LamorlayeVente maison Lamorlaye
Vente maison LamorlayeMarc Foujols
 
ACHAT APPARTEMENT FAMILIAL PARIS TROCADERO
ACHAT APPARTEMENT FAMILIAL PARIS TROCADEROACHAT APPARTEMENT FAMILIAL PARIS TROCADERO
ACHAT APPARTEMENT FAMILIAL PARIS TROCADEROMarc Foujols
 
IMMOBILIER PRESTIGE PARIS PASSY TERRASSE
IMMOBILIER PRESTIGE PARIS PASSY TERRASSEIMMOBILIER PRESTIGE PARIS PASSY TERRASSE
IMMOBILIER PRESTIGE PARIS PASSY TERRASSEMarc Foujols
 
Comparacion entre el constructivismo vs eclecticismo
Comparacion entre el constructivismo vs eclecticismoComparacion entre el constructivismo vs eclecticismo
Comparacion entre el constructivismo vs eclecticismocristhian0586
 
Terrain - our work
Terrain - our workTerrain - our work
Terrain - our workDavid Aubert
 
La Marelle Du Savoir SEREC
La Marelle Du Savoir SERECLa Marelle Du Savoir SEREC
La Marelle Du Savoir SERECregiosuisse
 
Sage Femme AdèLe Richter
Sage Femme   AdèLe RichterSage Femme   AdèLe Richter
Sage Femme AdèLe Richtergawronski
 
截图1~6
截图1~6截图1~6
截图1~6omtact
 
Oenologue Matthieu Kremer
Oenologue   Matthieu KremerOenologue   Matthieu Kremer
Oenologue Matthieu Kremergawronski
 
Tema 1. conceptos_gestion_proy
Tema 1. conceptos_gestion_proyTema 1. conceptos_gestion_proy
Tema 1. conceptos_gestion_proyJuan Ortiz M
 
Si Les Hommeslevaient Seuls Les Enfants
Si Les Hommeslevaient Seuls Les EnfantsSi Les Hommeslevaient Seuls Les Enfants
Si Les Hommeslevaient Seuls Les Enfantscatavrio
 
Le noël dans france
Le noël dans franceLe noël dans france
Le noël dans franceblancadn
 

En vedette (20)

Medecin AnesthéSiste RéAnimateur El Haloui Leila
Medecin AnesthéSiste RéAnimateur   El Haloui LeilaMedecin AnesthéSiste RéAnimateur   El Haloui Leila
Medecin AnesthéSiste RéAnimateur El Haloui Leila
 
ErgothéRapeuthe Haas Sophie
ErgothéRapeuthe   Haas SophieErgothéRapeuthe   Haas Sophie
ErgothéRapeuthe Haas Sophie
 
Rechercher une publication scientifique dans les archives ouvertes
Rechercher une publication scientifique dans les archives ouvertesRechercher une publication scientifique dans les archives ouvertes
Rechercher une publication scientifique dans les archives ouvertes
 
IngéNieur En MéCanique Brach LoïC
IngéNieur En MéCanique   Brach LoïCIngéNieur En MéCanique   Brach LoïC
IngéNieur En MéCanique Brach LoïC
 
Vente maison Lamorlaye
Vente maison LamorlayeVente maison Lamorlaye
Vente maison Lamorlaye
 
ACHAT APPARTEMENT FAMILIAL PARIS TROCADERO
ACHAT APPARTEMENT FAMILIAL PARIS TROCADEROACHAT APPARTEMENT FAMILIAL PARIS TROCADERO
ACHAT APPARTEMENT FAMILIAL PARIS TROCADERO
 
IMMOBILIER PRESTIGE PARIS PASSY TERRASSE
IMMOBILIER PRESTIGE PARIS PASSY TERRASSEIMMOBILIER PRESTIGE PARIS PASSY TERRASSE
IMMOBILIER PRESTIGE PARIS PASSY TERRASSE
 
Comparacion entre el constructivismo vs eclecticismo
Comparacion entre el constructivismo vs eclecticismoComparacion entre el constructivismo vs eclecticismo
Comparacion entre el constructivismo vs eclecticismo
 
Terrain - our work
Terrain - our workTerrain - our work
Terrain - our work
 
La Marelle Du Savoir SEREC
La Marelle Du Savoir SERECLa Marelle Du Savoir SEREC
La Marelle Du Savoir SEREC
 
Maria Moleon AlbertoHenares
Maria Moleon AlbertoHenaresMaria Moleon AlbertoHenares
Maria Moleon AlbertoHenares
 
Sage Femme AdèLe Richter
Sage Femme   AdèLe RichterSage Femme   AdèLe Richter
Sage Femme AdèLe Richter
 
截图1~6
截图1~6截图1~6
截图1~6
 
Grupo nº 6 ambientalistas humedad
Grupo nº 6 ambientalistas  humedadGrupo nº 6 ambientalistas  humedad
Grupo nº 6 ambientalistas humedad
 
Oenologue Matthieu Kremer
Oenologue   Matthieu KremerOenologue   Matthieu Kremer
Oenologue Matthieu Kremer
 
Tema 1. conceptos_gestion_proy
Tema 1. conceptos_gestion_proyTema 1. conceptos_gestion_proy
Tema 1. conceptos_gestion_proy
 
Si Les Hommeslevaient Seuls Les Enfants
Si Les Hommeslevaient Seuls Les EnfantsSi Les Hommeslevaient Seuls Les Enfants
Si Les Hommeslevaient Seuls Les Enfants
 
Le noël dans france
Le noël dans franceLe noël dans france
Le noël dans france
 
Plat Pays
Plat PaysPlat Pays
Plat Pays
 
Filosofia reporte3 sofia-
Filosofia reporte3 sofia-Filosofia reporte3 sofia-
Filosofia reporte3 sofia-
 

Similaire à Etude DéTailléé de la pile réseau sous GNU Linux

Admin_Réseaux_linux_cours.pptx
Admin_Réseaux_linux_cours.pptxAdmin_Réseaux_linux_cours.pptx
Admin_Réseaux_linux_cours.pptxsimomjidi
 
Présentation CoreOS
Présentation CoreOSPrésentation CoreOS
Présentation CoreOSgcatt
 
Premiers pas avec snort
Premiers pas avec snortPremiers pas avec snort
Premiers pas avec snortFathi Ben Nasr
 
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...Jérôme Petazzoni
 
Notions de base sur le routage
Notions de base sur le routageNotions de base sur le routage
Notions de base sur le routageInes Kechiche
 
utilisation des core dump sous linux
utilisation des core dump sous linuxutilisation des core dump sous linux
utilisation des core dump sous linuxThierry Gayet
 
PostgreSQL sous linux
PostgreSQL sous linuxPostgreSQL sous linux
PostgreSQL sous linuxKhalid ALLILI
 
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesBreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesXavier MARIN
 
Généralités sur le routeur
Généralités sur le routeurGénéralités sur le routeur
Généralités sur le routeurStany Mwamba
 
Composants routeur cisco et différent mode de Configuration
Composants routeur cisco et différent mode de ConfigurationComposants routeur cisco et différent mode de Configuration
Composants routeur cisco et différent mode de ConfigurationZakariaBouzzitMadrid
 
laboratoire formation ccna cisco materiel .ppt
laboratoire formation ccna cisco materiel .pptlaboratoire formation ccna cisco materiel .ppt
laboratoire formation ccna cisco materiel .pptprofsn
 
Cours Firewalls.pdf
Cours Firewalls.pdfCours Firewalls.pdf
Cours Firewalls.pdfAnisSalhi3
 
formation docker.pdf
formation docker.pdfformation docker.pdf
formation docker.pdfMohammedHdi1
 
Rapport systéme embarqué busybox
Rapport systéme embarqué busyboxRapport systéme embarqué busybox
Rapport systéme embarqué busyboxAyoub Rouzi
 
Programmation de systèmes embarqués : BeagleBone Black et Linux embarqué
Programmation de systèmes embarqués : BeagleBone Black et Linux embarquéProgrammation de systèmes embarqués : BeagleBone Black et Linux embarqué
Programmation de systèmes embarqués : BeagleBone Black et Linux embarquéECAM Brussels Engineering School
 
Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1
Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1
Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1mazurus
 

Similaire à Etude DéTailléé de la pile réseau sous GNU Linux (20)

Admin_Réseaux_linux_cours.pptx
Admin_Réseaux_linux_cours.pptxAdmin_Réseaux_linux_cours.pptx
Admin_Réseaux_linux_cours.pptx
 
Présentation CoreOS
Présentation CoreOSPrésentation CoreOS
Présentation CoreOS
 
01 tcpip
01 tcpip01 tcpip
01 tcpip
 
Premiers pas avec snort
Premiers pas avec snortPremiers pas avec snort
Premiers pas avec snort
 
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...
 
Notions de base sur le routage
Notions de base sur le routageNotions de base sur le routage
Notions de base sur le routage
 
Ccna2
Ccna2Ccna2
Ccna2
 
utilisation des core dump sous linux
utilisation des core dump sous linuxutilisation des core dump sous linux
utilisation des core dump sous linux
 
PostgreSQL sous linux
PostgreSQL sous linuxPostgreSQL sous linux
PostgreSQL sous linux
 
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesBreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
 
8-socket.pdf
8-socket.pdf8-socket.pdf
8-socket.pdf
 
Généralités sur le routeur
Généralités sur le routeurGénéralités sur le routeur
Généralités sur le routeur
 
Composants routeur cisco et différent mode de Configuration
Composants routeur cisco et différent mode de ConfigurationComposants routeur cisco et différent mode de Configuration
Composants routeur cisco et différent mode de Configuration
 
laboratoire formation ccna cisco materiel .ppt
laboratoire formation ccna cisco materiel .pptlaboratoire formation ccna cisco materiel .ppt
laboratoire formation ccna cisco materiel .ppt
 
Cours Firewalls.pdf
Cours Firewalls.pdfCours Firewalls.pdf
Cours Firewalls.pdf
 
Snort implementation
Snort implementationSnort implementation
Snort implementation
 
formation docker.pdf
formation docker.pdfformation docker.pdf
formation docker.pdf
 
Rapport systéme embarqué busybox
Rapport systéme embarqué busyboxRapport systéme embarqué busybox
Rapport systéme embarqué busybox
 
Programmation de systèmes embarqués : BeagleBone Black et Linux embarqué
Programmation de systèmes embarqués : BeagleBone Black et Linux embarquéProgrammation de systèmes embarqués : BeagleBone Black et Linux embarqué
Programmation de systèmes embarqués : BeagleBone Black et Linux embarqué
 
Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1
Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1
Tgosp006dveloppement Noyau Et Driver Sous Gnu Linux 1234984890078859 1
 

Dernier

GUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - MontréalGUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - MontréalNicolas Georgeault
 
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...OCTO Technology
 
Intelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imaginationIntelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imaginationTony Aubé
 
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IAMilo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IAUGAIA
 
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...Faga1939
 
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdfEtude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdfsnapierala
 
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...OCTO Technology
 
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudLe Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudOCTO Technology
 

Dernier (8)

GUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - MontréalGUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - Montréal
 
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
 
Intelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imaginationIntelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imagination
 
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IAMilo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
 
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
 
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdfEtude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
 
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
 
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudLe Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
 

Etude DéTailléé de la pile réseau sous GNU Linux

  • 1. Etude de la stack réseau sous GNU Linux Thierry GAYET (ALTEN) – 11/2007 – v1.0 – OSP 005 – Creative Common [email_address]
  • 2.
  • 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.
  • 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.
  • 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.
  • 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.
  • 18.
  • 19. Les buffers sk 3/4 La structure du buffer_sk est géré via une liste doublement chaînée.
  • 20.
  • 21.
  • 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.
  • 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;NF_HOOK: Module instale&quot;); return 0; } // Fonction standard de déchargement d'un driver // sous GNU Linux : void cleanup_module () { printk(&quot; NF_HOOK: I'll be back ....&quot;); nf_unregister_hook(&nfho_tunnel_in); }
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 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.
  • 44.
  • 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.
  • 47.
  • 48.
  • 49.
  • 50.
  • 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);
  • 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.
  • 62.
  • 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.
  • 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
  • 68.
  • 69.
  • 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.
  • 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 ?