Tgosp005etude Dtaille de La Stack Rseau 1234984699748917 2

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

Thierry.Gayet@yahoo.fr
1 Projet Open STB / Orange Labs - R&D – Présentation pile réseau sous GNU Linux interne Groupe France Télécom
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
UNIX Unix domain sockets
INET TCP/IP
Linux gère une multitude de protocoles réseau : AX25 Amateur radio
IPX Novell IPX
APPLETALK Appletalk
1. TCP X25 X.25
2. UDP Etc…
OSI 4 : couche transport : 3. Netbios
(define in include/linux/socket.h)
1. IP
OSI 3 : couche réseau : 2. ICMP
3. IGMP
4. ATM
OSI 2 : couche liaison (Driver réseaux) : 1. Ethernet

2. ARP / RARP
3. Tokenring
4. ATM

La pile réseau de GNU Linux peut être considéré comme la plus complète et disponible à ce jour.
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
User
Application
Application utilisateur space
Couche applicative Appels système
Couche transport Interface de diagnostique des protocoles
Kernel
Protocoles réseaux
space
Couche réseau
Interface de diagnostique des devices
Couche de liaison
Driver réseau
Couche matérielle
Carte réseau
Modèle Internet de la pile réseau. Architecture de la pile réseau.
 La pile réseau couvre le protocole TCP/IP  D'un point de vue de Linux, la pile est localisée
de la couche liaison (drivers) jusqu'à la dans le noyau avec une API (les sockets BSD)
couche transport (sockets BSD). pouvant être appelée depuis l'espace utilisateur.
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 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
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)  http://docs.huihoo.com/linux/kernel/a1/index.html
Les drivers réseaux : liens
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.
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("Donald Becker static int vortex_scan(struct device *dev, struct pci_id_info pci_tbl[])
<becker@cesdis.gsfc.nasa.gov>"); {
...
MODULE_DESCRIPTION("3Com 3c590/3c900 series #if defined(CONFIG_PCI) || (defined(MODULE) && !defined(NO_PCI))
Vortex/Boomerang driver"); ...
MODULE_PARM(debug, "i"); #ifdef MODULE
... if (compaq_ioaddr) {
#endif vortex_probe1(0, 0, dev, compaq_ioaddr, compaq_irq,
compaq_device_id, cards_found++);
... dev = 0;
#ifdef MODULE }
int init_module(void) #endif
{ return cards_found ? 0 : -ENODEV;
... }
...
} #ifdef MODULE
#else void cleanup_module(void)
int tc59x_probe(struct device *dev) {
{ ... ... ...
... }
#endif
}
#endif /* not MODULE */
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 " ... ";

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

{
...
}
module_init(vortex_init);
module_exit(vortex_cleanup);
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)
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, Ensemble de routine pour modifier l'ordre de priorité dans les routines de virtualisation exécutées lors de la
séquence de BOOT.
subsys_initcall,
fs_initcall,
device_initcall,
late_initcall
_ _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 structure
de contrôle se compose notamment de :
1. structures représentant les couches Ethernet, réseau et transport

2. pointeurs pour la gestion du sk_buffer dans la liste des sk_buffers
3. informations sur les périphériques (devices) d’entrée/sortie
4. 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 premier
octet de l’en-tête IP. tail pointe sur le premier octet de bourrage du bloc mémoire (le bloc mémoire pouvant
être plus grand que le paquet à stocker).
Les buffers sk 2/4
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 :
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.
Les buffers sk 4/4
struct sk_buff_head
{
/* These two members must be first. */
Structure
struct sk_buff * next;
de struct sk_buff * prev;
données _ _u32 qlen;
 spinlock_t lock;
};
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 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é.
Couche transport
OSI #4
Circulation des paquets

2/2
Cheminement des paquets

dans les différentes couches
de la stack réseau du kernel
GNU Linux 
Couche réseau
OSI #3
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

Couche liaison
procédure d’émission de la OSI #2
procédure de réception.
Pour les noyaux 2.2 et inférieurs,

le traitement des trames est
différent
25
(ex : on
Projet
neSTB
Open
retrouve
/ Orange Labs - R&D – Présentation pile réseau sous GNU Linux Couche physique
interne Groupe France Télécom
pas les files tx et rx). OSI #1
Estimation du coût (temps et consommation mémoire) des recopie de
paquets dans la pile réseau 1/5
TCP / IP vs. OSI model

7: Application
6: Presentation
Process
5: Session
Le but étant de faire une

estimation des recopies
mémoire d'un paquet Socket layer
4: Transport
3: Network
réseau de la carte réseau
à la socket BSD 
2: Data
Protocol Layer (TCP / IP)
Link
1: Physical
Interface Layer (Ethernet, etc.) Layer
Estimation du coût (temps et consommation mémoire) des recopies
de paquets dans la pile réseau 2/5
Application
1: sosend (……………... ) 5: recvfrom(……….)
Couche des sockets BSD
2: tcp_output ( ……. ) 4: tcp_input ( ……... )
Résumé
des Couche transport (TCP / UDP)
couches
 3: ip_output ( ……. )
3: ip_input ( ……... )
Couche protocole (IP)
4: ethernet_output ( ……. ) 2: ethernet_input ( …….. )
Couche liaison (Ethernet Device Driver)
Carte réseau
Queue de sortie Queue d'entrée
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)  uipc_syscalls.c
sosend (struct socket *s, struct mbuf *addr, struct uio *uio, struct mbuf *top, struct mbuf *control, int flags )  uipc_socket.c
tcp_userreq (struct socket *s, int request, struct mbuf *m, struct mbuf * nam, struct mbuf * control )  tcp_userreq.c
TCP Layer tcp_output (struct tcpcb *tp)  tcp_output.c
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 pile
ré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 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.
Emission
Latence 2/2 
Résumé du benchmark précédent :
Réception

Spécificité du protocole ARP
APar
l ‘émission, seuls
définition, les paquets
les hooks deservent
netfilter type ETH_P_ALL
à
peuvent être capturés.
capturer des trames IP. Il n’est ainsi pas
possible de voir les requêtes ARP.
Il est important de noter que, comme pour le chemin
suivi par les
On peut trames dans
cependant le noyau,
les capturer lessortie
à la fonctions
utilisées dans
du driver le carte
de la packet handling
réseau peuvent du
au moment changer
selon
choixladu
version du noyau
traitement utilisé. sur la trame
à appliquer
en fonction du protocole identifié par le champs
Pour récupérer les
skb->protocol detrames ARP,sk_buffer.
la structure il suffit d’enregistrer
une
Pourstructure
cela, à packet_type
chacun de ces dans une des(IPv4,
protocoles listes
ptype
IPv6,(ptype_base
ARP, BOOTP, ou ...)
ptype_all) avecune
est associé la fonction de
callback dev_add_pack()
structurede (définie
type packet_type dans
enregistré dans une
linux/netdevice.h).
file (ptype_all ou la table de hash ptype_base).
Comme pour les netfilter hooks, il faut supprimer ce
hook (packet
La file handling)
ptype_all lorsquepour
est utilisée le module
capturer esttous
retiré
dulesnoyau. Ceci
paquets se fait grâce
provenant (ou àà destination)
la fonction de
dev_remove_pack()
toutes les interfaces (linux/netdevice.h).
réseaux.
En enregistrantest
ptype_base une fonction pour
« hashée » ETH_P_ALL notre
par identifiant
packet type seet
de protocole retrouvera
permet dedans la liste
décider ptype_all.
à quelle
fonction est destiné le paquet (sk_buffer). Position des hooks de type « packet handling » dans la chaîne
OnUnvask_buffer
ainsi récupérer toutes les trames
peut « matcher » une ou arrivant
plusieurs
de traitement des trames reçues ou à émettre.
(ou à destination)
entrées du driver de la carte réseau.
dans la table.
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
33 onProjet
va travailler. La copie
Open STB / Orange doit
Labs - R&D être détruite
– Présentation ensous
pile réseau finGNU
de Linux
fonction avec la fonction kfree_skb().
interne Groupe France Télécom
Ce type de hook n’est donc pas destiné à modifier le paquet capturé.
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 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("\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);
}
Netfilter : étude de cas 2/2
unsigned int hook_func_tunnel_in (unsigned int hooknum,

(SUITE)
struct sk_buff **skb,
const struct net_device *in, if((strcmp("eth1", in->name)==0) &&(ip->daddr == ip0))
{
const struct net_
affic_skb(sb,0);
device *out, sb->data -= 14;
int (*okfn)(struct sk_buff *)) sb->len = len+14 ;
{
struct sk_buff* sb= *skb; memcpy(sb->data,hd_mac1, 14);
struct iphdr* ip; dev = dev_get_by_name("eth0");
struct net_device *dev= NULL; spin_lock_bh (&(dev->queue_lock));
struct Qdisc *q; q = dev->qdisc;
int len;
q->enqueue(sb,q);
len = sb->len; qdisc_run(dev);
ip = sb->nh.iph;
spin_unlock_bh(&(dev->queue_lock));
if((strcmp("eth0", in->name)==0) && (ip->daddr == ip1) )
{ return NF_STOLEN;
affic_skb(sb,0); }
sb->data -= 14;
sb->len = len+ 14; return( NF_ACCEPT );
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 );
}
Exemple d'implémentation de la fonction de hook utilisée dans le driver réseau.
Routage 1/5 : routage statique vs dynamique
Routage statique vs routage dynamique
Le paramétrage statique d'une interface se fait de différente façon selon les familles de linux.
Sous GNU Debian/Ubuntu il y a le fichier /etc/network/interfaces qui contient le paramétrage
des interfaces réseau alors que sous Redhat/Fedora/suze c'est le fichier /etc/sysconfig/network-
scripts/ifcfg-eth0
 Statique (paramétrage manuel) :
$ ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up
Par convention l'adresse réseau est celle la plus basse : 192.168.1.0. L'adresse de broadcast celle
la plus haute : 192.168.1.255. Pour finir, la gateway est : 192.168.1.1. Au dela de cette
convention, les adresses peuvent être choisis séparément.
Pour un paquet réseau destiné à être émis sur le réseau, le routage statique consiste à utiliser
l'adresse réseau (Ex: 192.168.1.X) pour savoir sur quelle interface envoyer le paquet.
Lorsqu'aucune interface ne possède d'adresse en adéquation avec celle des interfaces, la table
de routage envoie sur celle désigné pour être associée à la route par défault (plus précisément
à la passerelle). Pour spécifier une route manuellement il suffit d'utiliser la commande
suivante :
$ route add default gw 192.168.1.1 eth0
 Il ne s'agit pas ici de routage interne ou externe utilisé sur les WAN comme RIP ou OSPF
mais d'un routage local sur un LAN.
Définition d'une adresse virtuelle ou alias :

$ ifconfig eth0:0 192.168.10.12 netmask 255.255.255.0 broadcast 192.168.10.255
$ route add -host 192.168.10.12 dev eth0
$ route add -host 192.168.10.14 dev eth0
Routage 2/5
•
Dynamique : c'est un moyen supplémentaire (par rapport au routage statique) pour résoudre un nom de machine.
Déclaration en statique d'une interface Déclaration dynamique (DHCP) d'une interface

Debian/Ubuntu (/etc/network/interfaces) : Debian/Ubuntu (/etc/network/interfaces) :
auto lo auto lo
iface lo inet loopback
iface lo inet loopback
auto eth0
iface eth0 inet static auto eth0
address 208.88.34.106 iface eth0 inet dhcp
netmask 255.255.255.248
broadcast 208.88.34.111 RedHad/Fedora/Suse/Mandriva (/etc/sysconfig/network) :
network 208.88.34.104
gateway 208.88.34.110 DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
RedHad/Fedora/Suse/Mandriva (/etc/sysconfig/network) :
DEVICE=eth0
BOOTPROTO=static
BROADCAST=XXX.XXX.XXX.255 lo: Loopback interface (network within your system
IPADDR=XXX.XXX.XXX.XXX NETMASK=255.255.255.0 without slowing down for the real ethernet based
NETWORK=XXX.XXX.XXX.0 ONBOOT=yes network)
ethx: Ethernet interface card
wlanx : wireless card
http://www.subnetmask.info/ http://www.subnet-calculator.com/
Routage 3/5 : résolution de noms
 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 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 
L'activation du routage (prise en compte

dynamique, c'est-à-dire sans avoir à rebooter
permet à la pile réseau de se comporter
comme un "routeur" de paquets IP 
•
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
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 :

$ /sbin/route –n $ ip route ls
Table de routage IP du noyau 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3
Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.4
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.194.61.0/24 dev eth1 proto kernel scope link src 10.194.61.86
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 default via 10.194.61.1 dev eth1
10.194.61.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 default via 192.168.1.1 dev eth2
0.0.0.0 10.194.61.1 0.0.0.0 UG 0 0 0 eth1 default via 192.168.1.1 dev eth0
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
 http://mirabellug.org/wikini/upload/Documentations_routage.pdf
Filtrage 1/9 : iptables / ip6tables
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.

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables

http://www.c-sait.net/cours/iptables.php

http://www.linux-france.org/prj/inetdoc/telechargement/iptables-tutorial.pdf

http://ploug.eu.org/doc/iptables-tutorial.pdf
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 destination
des paquets, ils vont entrer dans la pile de protocoles IP par le même point et en sortir par le
même autre point. Netfilter se présente comme une série de 5 "hooks" (points d'accrochage), sur lesquels
des modules de traitement des paquets vont se greffer. Ces points sont:
•
NF_IP_PRE_ROUTING
•
NF_IP_LOCAL_IN
•
NF_IP_FORWARD
•
NF_IP_POSTROUTING
•
NF_IP_LOCAL_OUT
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 !!
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 :
– ACCEPT
Les paquets qui satisfont aux critères sont acceptés, ils continuent leur chemin dans la pile,
– DROP
Les paquets qui satisfont aux critères sont rejetés, on les oublie, on n'envoie même pas de message ICMP . Un trou noir,
quoi.
– LOG
C'est une cible particulière qui permet de tracer au moyen de syslog les paquets qui satisfont aux critères.
Suivant les contextes, d'autres cibles deviennent accessibles, comme REJECT (similaire à DROP, mais avec envoi d'un message
d'erreur ICMP à la source du paquet rejeté), RETURN, REDIRECT, SNAT, DNAT, MASQUERADE...
En français, nous pourrons faire des choses de ce genre :
– Par défaut, tous les paquets qui entrent sont rejetés (DROP)
– Les paquets qui entrent par le port 80 sur l'interface eth0 sont acceptés
– Les paquets qui sortent par le port 80 sur l'interface eth0 sont acceptés
– etc.
IPtables est en quelques sortes l'interface utilisateur de Netfilter. Dans sa partie "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 fonction
de décision de routage. C'est elle qui va déterminer si le paquet est destiné à un
processus local de l'hôte ou à un hôte sur un autre réseau.
Si le paquet est destiné à l'hôte local:

- Il traverse la chaîne INPUT
- S'il n'est pas rejeté, il est transmis au processus impliqué. Ce processus va donc le
traiter et éventuellement émettre un nouveau paquet en réponse.
- Ce nouveau paquet traverse la chaîne OUTPUT
- S'il n'est pas rejeté, il va vers la sortie.
 La chaîne INPUT sera raccrochée
au "hook" NF_IP_LOCAL_IN •
Si le paquet est destiné à un hôte d'un autre réseau:
la chaîne OUTPUT au "hook" - Il traverse la chaîne FORWARD.
NF_IP_LOCAL_OUT - S'il n'est pas rejeté, il poursuit alors sa route.
et la chaîne FORWARD à
NF_IP_FORWARD.
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.
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 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);
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é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
Les primitives de l'API des sockets BSD permettent

d'implémenter tant des clients que des serveurs.
• Côté Client (demandeur de la connexion - le socket est dit actif) :


• crée un socket socket()

• se connecte à une <adresse,port> connect()
• lit et écrit dans le socket read(),recv();write(),send()
• ferme le socket close()
• Côté Serveur (en attente de connexion - le socket est dit passif) :


• crée un socket socket()

• associe une adresse au socket bind() Fonctions de gestion du byteorder :
• se met à l ’écoute des connexions entrantes listen()
• accepte une connexion entrante accept() char *inet_ntoa(const struct in_addr in) convertit la
• lit et écrit sur le socket read(),recv();write(),send() structure en adresse lisible
• ferme le socket close()
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 : 
Domaine d ’adresse :
struct sockaddr { • Internet AF_INET, Unix AF_UNIX
short sa_family; /* domaine AF_UNIX, AF_INET */ • mais aussi AF_OSI, AF_NS, AF_SNA, AF_CCITT,
char sa_data[14]; /* adresse */ AF_APPLETALK,
} ...

Type associé aux adresses dans le domaine Unix : 
Type :
#include<sys.un.h> • au niveau bas du protocole (exemple : datagramme IP)
SOCK_RAW
struct sockaddr_un { • en mode non connecté SOCK_DGRAM, SOCK_RDM,
short sun_family; /* domaine AF_UNIX */ SOCK_SEGPACKET
char sun_path[128]; /* chemin */ • en mode connecté SOCK_STREAM
}

Protocole :

Type associé aux adresses dans le domaine Internet : • par défaut à 0, le système choisit le protocole
#include <netinet/in.h> • IPPROTO_UDP pour UDP avec les sockets de type
SOCK_DGRAM,
struct in_addr { u_long s_addr; }; SOCK_RDM, SOCK_SEGPACKET
struct sockaddr_in { • IPPROTO_TCP pour TCP avec une socket de type
short sin_family; /* domaine AF_INET */ SOCK_STREAM
u_short sin_port; /* port de la socket */ • il existe d ’autres protocoles
struct in_addr sin_addr; /* N° IP de la machine format réseau • dans le domaine AF_UNIX, il n ’y a pas de protocole
*/
char sin_zero[8]; /* 8 caractères nuls de bourrage */
};
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
Listing des paramètres disponible dans le RAMFS du KERNEL :

$ 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 …
Affichage et modifications des paramètres : PROCFS est un RAMFS géré par le

noyau. C'est un lien entre le monde user
$ cat /proc/sys/net/ipv4/ip_forward et le monde kernel.
1
$ echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
 http://mirrors.deepspace6.net/Linux+IPv6-HOWTO-fr/proc-net.html  http://linuxgazette.net/issue77/lechnyr.html
SUPPORT D'IPV6
IPv6 1/3 : rappels
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 2/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 : 3/3
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.
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.html
Guide : http://deepspace6.net/sections/docs.html
IPv6 théorie et pratique : http://livre.point6.net/index.php/Accueil
Lectures de référence
Livres de référence sur TCP-IP
TCP/IP illustré – Volume 1
Editeur : Vuibert
Édition : Nouv. éd (28 septembre 1998)
Langue : Français
ISBN-10: 2711786390
ISBN-13: 978-2711786398
 http://www.uic.rsu.ru/doc/inet/tcp_stevens/
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
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)
http://www.kohala.com/start/ Language: English
ISBN-10: 0201634953
ISBN-13: 978-0201634952
Product Dimensions: 9.4 x 7.4 x 1 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 ?

Langue

Tgosp005etude Dtaille de La Stack Rseau 1234984699748917 2

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Tgosp005etude Dtaille de La Stack Rseau 1234984699748917 2

Titre original :

Transféré par

Droits d'auteur :

Etude de la stack réseau sous GNU Linux

Thierry GAYET (ALTEN) – 11/2007 – v1.0 – OSP 005 – Creative Common

Le développement de la couche réseau dans le noyau Linux a été

Le but est d'implémenter un système qui soit au moins aussi

C'est avant tout le protocole TCP/IP qui a été

Le code fut ensuite repris par Alan Cox de

OSI 2 : couche liaison (Driver réseaux) : 1. Ethernet

Disponibilité des fonctionnalités dans la pile réseau en

Couche applicative Appels système

Couche transport Interface de diagnostique des protocoles

Un driver réseau est la troisième catégorie

Le fonctionnement d'une interface réseau au

Il y a cependant une différence avec un

La différence la plus importante entre ces

Ainsi, alors qu'un driver de blocs demande

L'architecture réseau permet au noyau

Il existe un certain nombre important de

Chaque objet réseau est représenté via une

Une socket peut être partagée par plusieurs

L'architecture réseau utilise le scheduler de

De plus, la couche VFS apporte un système de

Interaction entre une carte réseau et le noyau :

2. Software (NET_RX_SOFTIRQ) : elle exécute le handle de paquets de réception. Elle est

Kmod est le chargeur de module

Machine à états pour l'enregistrement d'un device réseau.

#if defined(MODULE) && LINUX_VERSION_CODE > 0x20115 ...

Example de code issue du code source du drivers réseau (drivers/net/3c59x.c) destiné au

static char version[] _ _devinitdata = DRV_NAME " ... ";

static void _ _exit vortex_cleanup (void)

Liste des sections de mémoire pouvant

La plupart de ces macros sont définies dans

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

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

1. structures représentant les couches Ethernet, réseau et transport

La structure du buffer_sk est géré via une liste doublement chaînée.

 Netfilter et réalisation d'un hook

 Contraintes pour l'embarqué

The core Team du projet Netfilter.

La pile TCP/IP est directement implémentée dans le noyau.

Le traitement IP comporte 4 grandes phases :

 La réception de trame : point d’entrée

 Le routage : choix de la route à suivre par

 Le forwarding : contrôle du TTL et du

 L’émission : les paquets à émettre ou à

Circulation des paquets

Cheminement des paquets

Une carte réseau utilise 2 listes

On peut ainsi distinguer la

Pour les noyaux 2.2 et inférieurs,

TCP / IP vs. OSI model

Le but étant de faire une

1: sosend (……………... ) 5: recvfrom(……….)

Couche des sockets BSD

2: tcp_output ( ……. ) 4: tcp_input ( ……... )

Couche protocole (IP)

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

Couche liaison (Ethernet Device Driver)

Queue de sortie Queue d'entrée

TCP Layer tcp_output (struct tcpcb *tp)  tcp_output.c

Réception d'un paquet

Estimation du coût (temps et consommation

Résumé du benchmark précédent :

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)