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

Projet Open STB / Orange Labs - R&D – Présentation pile réseau sous GNU Linux1 interne Groupe France Télécom

Etude de la stack réseau sous GNU Linux

Thierry GAYET (ALTEN) – 11/2007 – v1.0 – OSP 005 – Creative [email protected]


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


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) : 1. Ethernet2. ARP / RARP3. Tokenring4. ATM

OSI 3 : couche réseau :

OSI 4 : couche transport :

1. TCP2. UDP3. Netbios

1. IP2. ICMP3. IGMP4. 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/IPAX25 Amateur radioIPX Novell IPXAPPLETALK AppletalkX25 X.25Etc…

(define in include/linux/socket.h)


Protocoles gérés

Disponibilité des fonctionnalités dans la pile réseau enfonction 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/IPde la couche liaison (drivers) jusqu'à la couche transport (sockets BSD).

D'un point de vue de Linux, la pile est localiséedans 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

ApplicationUserspace

Kernelspace


LES DRIVERS RESEAUX

Exemple de drivers réseau Les buffers de socket (sk_buffer = socket buffer)


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 ausein du système est assez similaire à un driverde blocs. Un driver de blocs est utilisé par lenoyau pour transmettre ou recevoir des blocsde données. D'un point de vue similaire, undriver réseau s'enregistre auprès du noyau deFaçon à pouvoir échanger des paquets dedonné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 possiblede 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 blocsn'est utilisé que lorsque le driver y fait appeltandis qu'un drivers réseau reçoit les paquetsré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 unesocket. Les sockets sont associées aux processdans 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)


Interaction entre une carte réseau et le noyau :

Toutes les cartes peuvent interagir avec le noyau de deux façon différentes :

Polling : Le noyau vérifie le status du device à intervalle régulier de façon à vérifier s'il y a quelque chose à faire ;

Interruptions : La carte envoie un signal au noyau sous la forme d'une interruption pour lui indiquer qu'il y a quelque chose à faire.

1. Matériel : elle accepte les paquets entrant en provenance des interfaces réseaux et les positionne directement en file d'entrée.

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


Chargement d'un driverréseau dynamiquementdans le kernel

Kmod est le chargeur de module dans le noyau GNU Linux. Lechargement initialise le nom dumodule (argv[0]) à charger. Si aulieu d'utiliser insmod, modprobeest 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 > 0x20115MODULE_AUTHOR("Donald Becker <[email protected]>");MODULE_DESCRIPTION("3Com 3c590/3c900 series Vortex/Boomerang driver");MODULE_PARM(debug, "i");...#endif...#ifdef MODULEint init_module(void){...}#elseint 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 MODULEif (compaq_ioaddr) {vortex_probe1(0, 0, dev, compaq_ioaddr, compaq_irq,compaq_device_id, cards_found++);dev = 0;}#endifreturn cards_found ? 0 : -ENODEV;}...#ifdef MODULEvoid cleanup_module(void){... ... ...}#endif

Example de code issue du code source du drivers réseau (drivers/net/3c59x.c) destiné auNoyau 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 fonctionnementd'un module dynamique en fonction de la façon dont il était compilé tel un module statique au seinDe l'image d'un noyau.


Les drivers réseaux : exemple d'implémentation (new)

static char version[] _ _devinitdata = DRV_NAME " ... ";static struct vortex_chip_info {...}

vortex_info_tbl[] _ _devinitdata = {{"3c590 Vortex 10Mbps",... ... ...}

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 depré-processing ne sont plus nécessaires cequi enlève tous les #ifdef et #endif.

Cela le rend plus facile à lire pour les développeurs de drivers via l'utilisation d'unensemble 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 lesdrivers réseau.

La plupart de ces macros sont définies dansle header include/linux/init.h


Les drivers réseaux : exemple d'implémentation (macros 2/2)

Macro Description

_ _init Routine d'initialisation lors de la séquence de boot.

_ _exit Appelée lorsque le composant kernel est déchargé du noyau.

core_initcall,

postcore_initcall,

arch_initcall,

subsys_initcall,

fs_initcall,

device_initcall,late_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.

_ _initcall Macro obsolète.

_ _exitcall Anciennement appelée par la routine de sortie du drivers lors de son déchargement.

_initdata Initialise une structure à la séquence de BOOT.

_exitdata A utiliser par les structures de données marquées par le tag __exitcall.


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 structurede contrôle se compose notamment de :

1. structures représentant les couches Ethernet, réseau et transport2. pointeurs pour la gestion du sk_buffer dans la liste des sk_buffers 3. informations sur les périphériques (devices) d’entrée/sortie4. informations sur le type de paquet (broadcast, multicast, …)5. 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 premieroctet 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).


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êtedifférent. Il faut cependant garder à l’esprit qu’en mode noyau aucun contrôle n’est effectué sur les accèsmé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.


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

Structurededonnées

Init.


LA STACK RESEAU

Architecture Circulation des paquets Routage Netfilter et réalisation d'un hook Contraintes pour l'embarqué


L'équipe de Netfilter et son leader actuel

Patrick McHardy : Team Leader du projetNetfilter .

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éedans la couche IP pour les trames reçues surles interfaces réseau.

Le routage : choix de la route à suivre parle paquet (réémission sur une autre interface/réseau ou destination locale)

Le forwarding : contrôle du TTL et duMTU avant de passer à la phase deréé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 transportOSI #4

Couche réseauOSI #3

Couche liaisonOSI #2

Couche physiqueOSI #1

Cheminement des paquets dans les différentes couches de la stack réseau du kernel GNU Linux

Une carte réseau utilise 2 listespermettant de gérer les paquetsentrants (rx_ring) et les paquets sortants (tx_ring) de la ou desinterfaces réseaux.

On peut ainsi distinguer la procédure d’émission de laprocédure de réception.

Pour les noyaux 2.2 et inférieurs, le traitement des trames est différent (ex : on ne retrouvepas les files tx et rx).


1: PhysicalLayer

2: DataLink

4: Transport3: Network

7: Application6: Presentation5: Session

Interface Layer (Ethernet, etc.)

Protocol Layer (TCP / IP)

Socket layer

Process

TCP / IP vs. OSI model

Estimation du coût (temps et consommation mémoire) des recopie de paquets dans la pile réseau 1/5

Le but étant de faire uneestimation des recopiesmémoire d'un paquetréseau de la carte réseauà la socket BSD


Application

1: sosend (……………... )

Couche des sockets BSD

2: tcp_output ( ……. )

Couche transport (TCP / UDP)

3: ip_output ( ……. )

Couche liaison (Ethernet Device Driver)

Queue de sortie

5: recvfrom(……….)

Queue d'entrée

3: ip_input ( ……... )

4: tcp_input ( ……... )

Couche protocole (IP)

4: ethernet_output ( ……. ) 2: ethernet_input ( …….. )

Carte réseau

Résumédescouches

Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 2/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.cTCP Layer




Réception d'un paquet


Algorigramme de la fonction tcp recvmsg

Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pileréseau 5/5


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 octetsen 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 desPerformances.

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 unerecopie 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 celaDemande 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èmessont 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 sortiedu driver de la carte réseau au moment duchoix du traitement à appliquer sur la trameen fonction du protocole identifié par le champsskb->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 tousles paquets provenant (ou à destination) detoutes les interfaces réseaux.

ptype_base est « hashée » par identifiantde protocole et permet de décider à quellefonction 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 fonctionsutilisées dans le packet handling peuvent changerselon la version du noyau utilisé.

Pour récupérer les trames ARP, il suffit d’enregistrerune structure packet_type dans une des listesptype (ptype_base ou ptype_all) avec la fonction decallback dev_add_pack() (définie danslinux/netdevice.h).Comme pour les netfilter hooks, il faut supprimer cehook (packet handling) lorsque le module est retirédu noyau. Ceci se fait grâce à la fonctiondev_remove_pack() (linux/netdevice.h).

En enregistrant une fonction pour ETH_P_ALL notrepacket 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înede traitement des trames reçues ou à émettre.


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


Netfilter 2/2

Un hook peut se définir comme unpoint d’accès dans une chaîne de traitement (par exemple : saisie auclavier, parcours de la pile TCP/IP…).

Netfilter est un ensemble de hooksà l’intérieur du noyau Linux permettantaux modules noyau d’enregistrer desfonctions 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 iptablesn’est qu’un module « sur-couche » denetfilter permettant de définir un système de règles de filtrage etmasquerading (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("\n\tNF_HOOK: Module instale\n\n");return 0;

}

// Fonction standard de déchargement d'un driver // sous GNU Linux :void cleanup_module(){

printk("\n\t NF_HOOK: I'll be back ....\n\n");nf_unregister_hook(&nfho_tunnel_in);

}


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("eth0", 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("eth1");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("eth1", 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("eth0");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 dynamiqueRoutage 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


Routage 2/5

http://www.subnetmask.info/ http://www.subnet-calculator.com/

Déclaration en statique d'une interface

Debian/Ubuntu (/etc/network/interfaces) :

auto loiface lo inet loopback

auto eth0iface eth0 inet staticaddress 208.88.34.106netmask 255.255.255.248broadcast 208.88.34.111network 208.88.34.104gateway 208.88.34.110

RedHad/Fedora/Suse/Mandriva (/etc/sysconfig/network) :

DEVICE=eth0BOOTPROTO=staticBROADCAST=XXX.XXX.XXX.255IPADDR=XXX.XXX.XXX.XXX NETMASK=255.255.255.0 NETWORK=XXX.XXX.XXX.0 ONBOOT=yes

Déclaration dynamique (DHCP) d'une interface

Debian/Ubuntu (/etc/network/interfaces) :

auto loiface lo inet loopback

auto eth0iface eth0 inet dhcp

RedHad/Fedora/Suse/Mandriva (/etc/sysconfig/network) :

DEVICE=eth0ONBOOT=yesBOOTPROTO=dhcp

lo: Loopback interface (network within your systemwithout slowing down for the real ethernet based network) ethx: Ethernet interface card wlanx : wireless card

• Dynamique : c'est un moyen supplémentaire (par rapport au routage statique) pour résoudre un nom de machine.


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="superserver"

Routage 3/5 : résolution de noms


Routage 4/5 : chemin de recherche

Pour bien comprendre la fonction de recherche deroute 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 "1" > /proc/sys/net/ipv4/ip_forward

• Inhibition du routage :echo "0" > /proc/sys/net/ipv4/ip_forward

L'activation du routage (prise en comptedynamique, c'est-à-dire sans avoir à rebooterpermet à la pile réseau de se comporter comme un "routeur" de paquets IP


Routage 5/5Le 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. Uneadresse IP est constituée de quatre nombres séparés par des points, comme `167.216.245.249'. Chaque nombre étantcompris 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.3192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.410.194.61.0/24 dev eth1 proto kernel scope link src 10.194.61.86default via 10.194.61.1 dev eth1default via 192.168.1.1 dev eth2default via 192.168.1.1 dev eth0

http://mirabellug.org/wikini/upload/Documentations_routage.pdf

$ /sbin/route –n

Table de routage IP du noyauDestination Passerelle Genmask Indic Metric Ref Use Iface192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth210.194.61.0 0.0.0.0 255.255.255.0 U 0 0 0 eth10.0.0.0 10.194.61.1 0.0.0.0 UG 0 0 0 eth10.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth20.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0


Filtrage 1/9 : iptables / ip6tables

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptableshttp://www.c-sait.net/cours/iptables.phphttp://www.linux-france.org/prj/inetdoc/telechargement/iptables-tutorial.pdfhttp://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'effectuede manière très souple et aussi finement que nécessaire.

Les iptables apportent une réponse élégante aux administrateurs qui se posent desquestions quant à la surveillance du trafic ICMP, la simplification de la gestion desconnexions 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.


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.


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 destinationdes paquets, ils vont entrer dans la pile de protocoles IP par le même point et en sortir par lemême autre point. Netfilter se présente comme une série de 5 "hooks" (points d'accrochage), sur lesquelsdes 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



La branche gauche représente le trajet des paquets quientrent et qui sortent vers et depuis un processus local(SMB, FTP, HTTP etc.)

La branche de droite représente le trajet des paquetsqui 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 !!


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 :



La table "Filter"

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 "officielle".

– 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: "Linux 2.4 Advanced Routing HOWTO".

Depuis la version 2.4.18 du noyau, d'autres tables ont été rajoutées sur tous les "hooks". Nous avons ainsi à notre disposition les tables supplémentaires INPUT, POSTROUTING et FORWARD



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 :

– ACCEPTLes paquets qui satisfont aux critères sont acceptés, ils continuent leur chemin dans la pile,

– DROPLes 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.

– LOGC'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 "visible", ça ressemble à IPchains, mais ici, ce n'est qu'une interface de commande de Netfilter. La syntaxe est plus complète et plus rigoureuse.



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.


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 fonctionde 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 paquetsissus d'un process local traversent la chaîne OUTPUTSEULS les paquets destinés au routage traversent la chaîneFORWARD.

La chaîne INPUT sera raccrochéeau "hook" NF_IP_LOCAL_INla chaîne OUTPUT au "hook"NF_IP_LOCAL_OUTet la chaîne FORWARD àNF_IP_FORWARD.


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 "ACCEPT"

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 "droppent" bien tout ce qui passe).




Diagramme général permettant lagestion des paquets via le moduleiptables


LES PRIMITIVES KERNEL POUR LE RESEAU


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 1/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);



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);



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);



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éseaune se fait pas directement maisvia 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

Les primitives de l'API des sockets BSD permettentd'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


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


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)

Tuning via /proc Commandes en ligne


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_latencyEtc …

$ ls /proc/sys/net/ipv4/route

error_burst gc_elasticity gc_min_interval_ms x_delay min_delay redirect_loadEtc …

http://linuxgazette.net/issue77/lechnyr.html

$ echo "0" > /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_forward1

PROCFS est un RAMFS géré par lenoyau. C'est un lien entre le monde useret le monde kernel.

http://mirrors.deepspace6.net/Linux+IPv6-HOWTO-fr/proc-net.html


SUPPORT D'IPV6


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 232 (soit environ 10^10) à 2128 (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


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


IPv6 : 3/3

Test du support d'IPv6 : test -f /proc/net/if_inet6 && echo "Support IPv6 available."

Test si IPv6 est activé : lsmod |grep -w 'ipv6' && echo "IPv6 enabled"

Résumé : http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-distributions.htmlGuide : http://deepspace6.net/sections/docs.htmlIPv6 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 pluscorrects, 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 lenoyau 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 GNULibc 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 1Editeur : 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/#ddkLinux Device Drivers, Third Edition - Network Drivers : http://lwn.net/images/pdf/LDD3/ch17.pdfIpsysctl tutorial : http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.htmlLinux IP Networking : http://www.cs.unh.edu/cnrg/gherrin/linux-net.htmlUNIX IP Stack Tuning Guide : http://www.cymru.com/Documents/ip-stack-tuning.htmlPerformance Analysis of the TCP/IP Stack of Linux Kernel :http://user.informatik.uni-goettingen.de/~kperf/gaug-ifi-tb-2005-03.pdfLinux IP Masquerade mini HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/IP-Masquerade-HOWTO.pdfPont + pare-feu + DSL Mini-HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/Bridge+Firewall+DSL.pdfMini How-To sur la configuration de l’aliasing IP sous Linux : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/IP-Alias.pdfLinux Network Administrators Guide : http://tldp.org/LDP/nag2/nag2.pdfThe Linux Networking Overview HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/Networking-Overview-HOWTO.pdfTCP/IP Stack Hardening : http://www.cromwell-intl.com/security/security-stack-hardening.htmlVoyage au centre de la pile TCP/IP de Linux : http://asyd.net/docs/kernel/tcpip-stack.htmlA Measurement Study of the Linux TCP/IP Stack Performance andScalability on SMP systems : http://www.cse.iitb.ac.in/~varsha/allpapers/mypapers/comswarepaper.pdfBerkeley sockets : http://en.wikipedia.org/wiki/Berkeley_socketsLinux TCP/IP Stack : http://www.cs.odu.edu/~csi/tcpipstack.pptIP & Ethernet Interfaces : http://www.beyondlogic.org/etherip/ip.htmImplementation of TCP/IP in Linux : http://netweb.usc.edu/~rsinha/docs/tcp-ip.pptConception 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.pdfHOWTO du routage avancé et du contrôle de trafic sous Linux : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/lartc.pdfLinux 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.pdfNisnet (network emulator) : http://www-x.antd.nist.gov/nistnet/TCPStackPerformance : http://www.gelato.unsw.edu.au/IA64wiki/TCPStackPerformanceAnatomy 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.pdfHistorique de la stack IP : http://www.linuxfranch-county.org/docs/guideLLLinux/implementation_reseau_5-2.pdfFonctions réseau du noyau Linux : http://www.linux-france.org/prj/inetdoc/telechargement/interco.noyau.pdfUnderstanding 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.htmlLinux Network Stack Walkthrough : http://gicl.cs.drexel.edu/people/sevy/network/Linux_network_stack_walkthrough.htmlData Link Layer : http://lion.cs.uiuc.edu/courses/cs498hou_spring05/lectures/lecture8.pdfskb - Linux network buffers : http://ftp.gnumonks.org/pub/doc/skb-doc.html


MERCI DE VOTRE ATTENTION

DES QUESTIONS ?

Technology

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