Routage avancé et contrôle du trafic sous linux

Routage avancé et contrôle du trafic sous Linux
Par Bert Hubert - Thomas Graf - Gregory Maxwell - Remco van Mook - Martijn van Oosterhout
- Paul B. Schroeder - Jasper Spaans - Pedro Larroy - Laurent Foucher (traducteur)
Date de publication : 4 janvier 2014
Ce document a pour but de vous éclairer sur la manière de faire du routage avancé avec
Linux 2.2/2.4. Méconnus par les utilisateurs, les outils standard de ces noyaux permettent
de faire des choses spectaculaires. Les commandes comme route et ifconfig sont des
interfaces vraiment pauvres par rapport à la grande puissance potentielle d'iproute2.
N'hésitez pas à commenter cet article !

Routage avancé et contrôle du trafic sous Linux par Bert Hubert - Thomas Graf - Gregory Maxwell
- Remco van Mook - Martijn van Oosterhout - Paul B. Schroeder - Jasper Spaans - Pedro Larroy
- 2 -
Copyright (c) 2001 par Bert Hubert, Gregory Maxwell et Martijn van Oosterhout, Remco van Mook, Paul B. Schroeder et
autres. Ce document ne peut être distribué qu'en respectant les termes et les conditions exposés dans la Open Publication
License, v1.0 ou supérieure (la dernière version est actuellement disponible sur http://www.opencontent.org/openpub/).
http://inetdoc.developpez.com/tutoriels/routage-avance-linux/
1 - Dédicace.................................................................................................................................................................5
2 - Introduction.............................................................................................................................................................5
2-1 - Conditions de distribution et mise en garde................................................................................................. 5
2-2 - Connaissances préalables............................................................................................................................ 5
2-3 - Ce que Linux peut faire pour vous............................................................................................................... 6
2-4 - Notes diverses...............................................................................................................................................6
2-5 - Accès, CVS et propositions de mises à jour................................................................................................ 6
2-6 - Liste de diffusion........................................................................................................................................... 7
2-7 - Plan du document......................................................................................................................................... 7
3 - Introduction à iproute2........................................................................................................................................... 7
3-1 - Pourquoi iproute2 ?....................................................................................................................................... 7
3-2 - Un tour d'horizon d'iproute2.......................................................................................................................... 8
3-3 - Prérequis........................................................................................................................................................8
3-4 - 3.4. Explorer votre configuration courante.................................................................................................... 8
3-4-1 - ip nous montre nos liens...................................................................................................................... 8
3-4-2 - ip nous montre nos adresses IP.......................................................................................................... 9
3-4-3 - ip nous montre nos routes..................................................................................................................10
3-5 - ARP..............................................................................................................................................................10
4 - Règles - bases de données des politiques de routage.......................................................................................11
4-1 - Politique de routage simple par l'adresse source....................................................................................... 12
4-2 - Routage avec plusieurs accès Internet/fournisseurs d'accès..................................................................... 13
4-2-1 - Accès séparé...................................................................................................................................... 13
4-2-2 - Balance de charge..............................................................................................................................14
5 - GRE et autres tunnels......................................................................................................................................... 14
5-1 - Quelques remarques générales à propos des tunnels :............................................................................. 15
5-2 - IP dans un tunnel IP................................................................................................................................... 15
5-3 - Le tunnel GRE.............................................................................................................................................16
5-3-1 - Le tunnel IPv4.....................................................................................................................................16
5-3-2 - Le tunnel IPv6.....................................................................................................................................17
5-4 - Tunnels dans l'espace utilisateur................................................................................................................ 18
6 - Tunnel IPv6 avec Cisco et/ou une dorsale IPv6 (6bone)....................................................................................18
6-1 - Tunnel IPv6..................................................................................................................................................18
7 - IPSEC : IP sécurisé à travers Internet................................................................................................................ 20
7-1 - Introduction sur la gestion manuelle des clés.............................................................................................21
7-2 - Gestion automatique des clés.....................................................................................................................24
7-2-1 - Théorie................................................................................................................................................ 24
7-2-2 - Exemple.............................................................................................................................................. 25
7-2-2-1 - Problèmes et défauts connus.................................................................................................... 27
7-2-3 - Gestion automatique des clés en utilisant les certificats X.509..........................................................27
7-2-3-1 - Construire un certificat X.509 pour votre hôte........................................................................... 27
7-2-3-2 - Configuration et lancement........................................................................................................ 28
7-2-3-3 - Comment configurer des tunnels sécurisés...............................................................................29
7-3 - tunnels IPSEC............................................................................................................................................. 30
7-4 - Autre logiciel IPSEC....................................................................................................................................31
7-5 - Interopérabilité d'IPSEC avec d'autres systèmes....................................................................................... 31
7-5-1 - Windows..............................................................................................................................................31
7-5-2 - Check Point VPN-1 NG...................................................................................................................... 31
8 - Routage multidistribution (multicast)....................................................................................................................31
9 - Gestionnaires de mise en file d'attente pour l'administration de la bande passante........................................... 32
9-1 - Explication sur les files d'attente et la gestion de la mise en file d'attente................................................. 33
9-2 - Gestionnaires de mise en file d'attente simples, sans classe.....................................................................33
9-2-1 - pfifo_fast..............................................................................................................................................34
9-2-1-1 - Paramètres et usage..................................................................................................................34
9-2-2 - Filtre à seau de jetons (Token Bucket Filter)..................................................................................... 36
9-2-2-2 - Configuration simple...................................................................................................................37
9-2-3 - Mise en file d'attente stochastiquement équitable (Stochastic Fairness Queueing)........................... 38

- 3 -
9-3 - Conseils pour le choix de la file d'attente...................................................................................................39
9-4 - Terminologie.................................................................................................................................................39
9-5 - Gestionnaires de file d'attente basés sur les classes.................................................................................42
9-5-1 - Flux à l'intérieur des gestionnaires basés sur des classes et à l'intérieur des classes.......................42
9-5-2 - La famille des gestionnaires de mise en file d'attente : racines, descripteurs, descendances et
parents.............................................................................................................................................................42
9-5-2-1 - Comment les filtres sont utilisés pour classifier le trafic............................................................ 42
9-5-2-2 - Comment les paquets sont retirés de la file d'attente et envoyés vers le matériel.....................43
9-5-3 - Le gestionnaire de mise en file d'attente PRIO..................................................................................43
9-5-3-1 - Paramètres PRIO et usage........................................................................................................44
9-5-4 - Le célèbre gestionnaire de mise en file d'attente CBQ......................................................................46
9-5-4-1 - Mise en forme CBQ en détail.................................................................................................... 46
9-5-4-2 - Le comportement CBQ classful................................................................................................. 48
9-5-4-3 - Paramètres CBQ qui déterminent le partage et le prêt du lien..................................................48
9-5-4-5 - D'autres paramètres CBQ : split et defmap............................................................................... 50
9-5-5 - Seau de jetons à contrôle hiérarchique (Hierarchical Token Bucket).................................................51
9-6 - Classifier des paquets avec des filtres....................................................................................................... 52
9-6-1 - Quelques exemples simples de filtrage..............................................................................................53
9-6-2 - Toutes les commandes de filtres dont vous aurez normalement besoin............................................54
9-7 - Le périphérique de file d'attente intermédiaire (The Intermediate queueing device (IMQ)).........................55
9-7-1 - Configuration simple........................................................................................................................... 55
10 - Équilibrage de charge sur plusieurs interfaces................................................................................................. 56
10-1 - Avertissement............................................................................................................................................ 57
11 - Netfilter et iproute - marquage de paquets........................................................................................................57
12 - Filtres avancés pour la (re)classification des paquets.......................................................................................58
12-1 - Le classificateur u32..................................................................................................................................59
12-1-1 - Le sélecteur U32.............................................................................................................................. 60
12-1-2 - Sélecteurs généraux......................................................................................................................... 60
12-1-3 - Les sélecteurs spécifiques................................................................................................................61
12-2 - Le classificateur route............................................................................................................................... 62
12-3 - Les filtres de réglementation (Policing filters)........................................................................................... 63
12-3-1 - Techniques de réglementation..........................................................................................................63
12-3-1-1 - Avec l'estimateur du noyau......................................................................................................63
12-3-1-2 - Avec le Token Bucket Filter..................................................................................................... 63
12-3-2 - Actions de dépassement de limite (Overlimit actions)......................................................................64
12-3-3 - Exemples...........................................................................................................................................64
12-4 - Filtres hachés pour un filtrage massif très rapide.....................................................................................64
12-5 - Filtrer le trafic IPv6....................................................................................................................................66
12-5-1 - Comment se fait-il que ces filtres tc IPv6 ne fonctionnent pas ?......................................................66
12-5-2 - Marquer les paquets IPv6 en utilisant ip6tables...............................................................................66
12-5-3 - Utiliser le sélecteur u32 pour repérer le paquet IPv6.......................................................................66
13 - Paramètres réseau du noyau............................................................................................................................ 67
13-1 - Filtrage de Chemin Inverse (Reverse Path Filtering)................................................................................67
13-2 - Configurations obscures............................................................................................................................68
13-2-1 - ipv4 générique.................................................................................................................................. 68
13-2-2 - Configuration des périphériques.......................................................................................................73
13-2-3 - Politique de voisinage.......................................................................................................................74
13-2-4 - Configuration du routage.................................................................................................................. 75
14 - Gestionnaires de mise en file d'attente avancés et moins communs................................................................77
14-1 - bfifo/pfifo.................................................................................................................................................... 77
14-1-1 - Paramètres et usage........................................................................................................................ 77
14-2 - Algorithme Clark-Shenker-Zhang (CSZ)................................................................................................... 77
14-3 - DSMARK....................................................................................................................................................77
14-3-1 - Introduction........................................................................................................................................78

- 4 -
14-3-2 - À quoi DSMARK est-il relié ?........................................................................................................... 78
14-3-3 - Guide des services différenciés........................................................................................................78
14-3-4 - Travailler avec DSMARK.................................................................................................................. 78
14-3-5 - Comment SCH_DSMARK travaille ?................................................................................................79
14-3-6 - Le filtre TC_INDEX........................................................................................................................... 80
14-4 - Gestionnaire de mise en file d'attente d'entrée (Ingress qdisc)................................................................ 81
14-4-1 - Paramètres et usage........................................................................................................................ 82
14-5 - Random Early Detection (RED)................................................................................................................ 82
14-6 - Generic Random Early Detection..............................................................................................................83
14-7 - Émulation VC/ATM.................................................................................................................................... 83
14-8 - Weighted Round Robin (WRR).................................................................................................................83
15 - Recettes de cuisine........................................................................................................................................... 84
15-1 - Faire tourner plusieurs sites avec différentes SLA (autorisations)............................................................84
15-2 - Protéger votre machine des inondations SYN..........................................................................................85
15-3 - Limiter le débit ICMP pour empêcher les dénis de service...................................................................... 85
15-4 - Donner la priorité au trafic interactif..........................................................................................................86
15-5 - Cache Web transparent utilisant netfilter, iproute2, ipchains et squid.......................................................87
15-5-1 - Schéma du trafic après l'implémentation..........................................................................................90
15-6 - Circonvenir aux problèmes de la découverte du MTU de chemin en configurant un MTU par routes.......90
15-6-1 - Solution............................................................................................................................................. 91
15-7 - Circonvenir aux problèmes de la découverte du MTU de chemin en imposant le MSS (pour les
utilisateurs de l'ADSL, du câble, de PPPoE & PPtP)..........................................................................................91
15-8 - Le Conditionneur de Trafic Ultime : faible temps de latence, téléchargement vers l'amont et l'aval
rapide.................................................................................................................................................................... 92
15-8-1 - Pourquoi cela ne marche-t-il pas bien par défaut ?......................................................................... 92
15-8-2 - Le script (CBQ).................................................................................................................................94
15-8-3 - Le script (HTB)................................................................................................................................. 95
15-9 - Limitation du débit pour un hôte ou un masque de sous-réseau..............................................................97
15-10 - Exemple d'une solution de traduction d'adresse avec de la QoS...........................................................97
15-10-1 - Commençons l'optimisation de cette rare bande passante............................................................98
15-10-2 - Classification des paquets..............................................................................................................99
15-10-3 - Améliorer notre configuration........................................................................................................101
15-10-4 - Rendre tout ceci actif au démarrage............................................................................................101
16 - Construire des ponts et des pseudoponts avec du Proxy ARP...................................................................... 101
16-1 - État des ponts et iptables....................................................................................................................... 102
16-2 - Pont et mise en forme............................................................................................................................ 102
16-3 - Pseudopont avec du Proxy-ARP.............................................................................................................102
16-3-1 - ARP et Proxy-ARP..........................................................................................................................102
16-3-2 - Implémentez-le................................................................................................................................103
17 - Routage Dynamique - OSPF et BGP..............................................................................................................103
17-1 - Configurer OSPF avec Zebra..................................................................................................................104
17-1-1 - Prérequis.........................................................................................................................................105
17-1-2 - Configurer Zebra.............................................................................................................................105
17-1-3 - Exécuter Zebra............................................................................................................................... 106
17-2 - Configurer BGP4 avec Zebra..................................................................................................................108
17-2-1 - schéma réseau (exemple).............................................................................................................. 108
17-2-2 - Configuration (exemple)..................................................................................................................108
17-2-3 - Vérification de la configuration....................................................................................................... 109
18 - Autres possibilités............................................................................................................................................ 110
19 - Lectures supplémentaires................................................................................................................................ 112
20 - Remerciements................................................................................................................................................ 112
21 - Remerciements Developpez............................................................................................................................ 114

- 5 -
1 - Dédicace
Ce document est dédié à beaucoup de gens ; dans ma tentative de tous me les rappeler, je peux en citer quelques-
uns :
• Rusty Russell ;
• Alexey N. Kuznetsov ;
• La fine équipe de Google ;
• L'équipe de Casema Internet.
2 - Introduction
Bienvenue, cher lecteur.
Ce document a pour but de vous éclairer sur la manière de faire du routage avancé avec Linux 2.2/2.4. Méconnus par
les utilisateurs, les outils standard de ces noyaux permettent de faire des choses spectaculaires. Les commandes
comme route et ifconfig sont des interfaces vraiment pauvres par rapport à la grande puissance potentielle
d'iproute2.
J'espère que ce HOWTO deviendra aussi lisible que ceux de Rusty Russell, très réputé (parmi d'autres choses) pour
son netfilter.
Vous pouvez nous contacter en nous écrivant à l'équipe HOWTO. Cependant, postez, s'il vous plaît, vos questions
sur la liste de diffusion (voir la section correspondante) pour celles qui ne sont pas directement liées à ce HOWTO.
Avant de vous perdre dans ce HOWTO, si la seule chose que vous souhaitez faire est de la simple mise en forme de
trafic, allez directement au chapitre http://www.inetdoc.net/guides/lartc/lartc.other.html, et lisez ce qui concerne
CBQ.init.
2-1 - Conditions de distribution et mise en garde
Ce document est distribué dans l'espoir qu'il sera utile et utilisé, mais SANS AUCUNE GARANTIE ; sans même une
garantie implicite de qualité légale et marchande ni aptitude à un quelconque usage.
En un mot, si votre dorsale STM-64 est tombée ou distribue de la pornographie à vos estimés clients, cela n'est pas
de notre faute. Désolé.
Copyright (c) 2001 par Bert Hubert, Gregory Maxwell et Martijn van Oosterhout, Remco van Mook, Paul B.
Schroeder et autres. Ce document ne peut être distribué qu'en respectant les termes et les conditions exposés
dans la Open Publication License, v1.0 ou supérieures (la dernière version est actuellement disponible sur http://
www.opencontent.org/openpub/).
Copiez et distribuez (vendez ou donnez) librement ce document, dans n'importe quel format. Les demandes de
corrections et/ou de commentaires sont à adresser à la personne qui maintient ce document.
Il est aussi demandé que, si vous publiez cet HOWTO sur un support papier, vous en envoyiez des exemplaires aux
auteurs pour une « relecture critique » :-)
2-2 - Connaissances préalables
Comme le titre l'implique, ceci est un HOWTO « avancé ». Bien qu'il ne soit pas besoin d'être un expert réseau,
certains prérequis sont nécessaires.

- 6 -
Voici d'autres références qui pourront vous aider à en apprendre plus :
• Rusty Russell's networking-concepts-HOWTO : très bonne introduction, expliquant ce qu'est un réseau, et
comment on le connecte à d'autres réseaux ;
• Linux Networking-HOWTO (ex Net-3 HOWTO) : excellent document, bien que très bavard. Il vous apprendra
beaucoup de choses qui sont déjà configurées si vous êtes capable de vous connecter à Internet. Il peut
éventuellement être situé à /usr/doc/HOWTO/NET-HOWTO.txt, mais peut également être trouvé en ligne.
2-3 - Ce que Linux peut faire pour vous
Une petite liste des choses qui sont possibles.
• Limiter la bande passante pour certains ordinateurs.
• Limiter la bande passante VERS certains ordinateurs.
• Vous aider à partager équitablement votre bande passante.
• Protéger votre réseau des attaques de type « déni de service ».
• Protéger Internet de vos clients.
• Multiplexer plusieurs serveurs en un seul, pour l'équilibrage de charge ou une disponibilité améliorée.
• Restreindre l'accès à vos ordinateurs.
• Limiter l'accès de vos utilisateurs vers d'autres hôtes.
• Faire du routage basé sur l'ID utilisateur (eh oui !), l'adresse MAC, l'adresse IP source, le port, le type de
service, l'heure ou le contenu.
Peu de personnes utilisent couramment ces fonctionnalités avancées. Il y a plusieurs raisons à cela. Bien que la
documentation soit fournie, la prise en main est difficile. Les commandes de contrôle du trafic ne sont pratiquement
pas documentées.
2-4 - Notes diverses
Il y a plusieurs choses qui doivent être notées au sujet de ce document. Bien que j'en ai écrit la majeure partie,
je ne veux vraiment pas qu'il reste tel quel. Je crois beaucoup à l'open source, je vous encourage donc à envoyer
des remarques, des mises à jour, des corrections, etc. N'hésitez pas à m'avertir des coquilles ou d'erreurs pures et
simples. Si mon anglais vous paraît parfois peu naturel, ayez en tête, s'il vous plaît, que l'anglais n'est pas ma langue
maternelle. N'hésitez pas à m'envoyer vos suggestions [NdT : en anglais !]
Si vous pensez que vous êtes plus qualifié que moi pour maintenir une section ou si vous pensez que vous pouvez
écrire et maintenir de nouvelles sections, vous êtes le bienvenu. La version SGML de ce HOWTO est disponible via
CVS. J'envisage que d'autres personnes puissent travailler dessus.
Pour vous aider, vous trouverez beaucoup de mentions FIXME (NdT : À CORRIGER). Les corrections sont toujours
les bienvenues. Si vous trouvez une mention FIXME, vous saurez que vous êtes en territoire inconnu. Cela ne veut
pas dire qu'il n'y a pas d'erreurs ailleurs, faites donc très attention. Si vous avez validé quelque chose, faites-le-nous
savoir, ce qui nous permettra de retirer la mention FIXME.
Je prendrai quelques libertés tout au long de cet HOWTO. Par exemple, je pars de l'hypothèse d'une connexion
Internet à 10 Mbit, bien que je sache très bien que cela n'est pas vraiment courant.
2-5 - Accès, CVS et propositions de mises à jour
L'adresse canonique de cet HOWTO est ici.
Nous avons maintenant un CVS en accès anonyme disponible depuis le monde entier. Cela est intéressant pour
plusieurs raisons. Vous pouvez facilement télécharger les nouvelles versions de ce HOWTO et soumettre des mises
à jour.

- 7 -
En outre, cela permet aux auteurs de travailler sur la source de façon indépendante, ce qui est une bonne chose aussi.
$ export CVSROOT=:pserver:anon@outpost.ds9a.nl:/var/cvsroot
$ cvs login
CVS password: [enter 'cvs' (sans les caractères ')]
$ cvs co 2.4routing
cvs server: Updating 2.4routing
U 2.4routing/lartc.db
Si vous avez fait des changements et que vous voulez contribuer au HOWTO, exécutez cvs -z3 diff -uBb, et envoyez-
nous le résultat par courrier électronique de façon à pouvoir facilement intégrer les modifications. Merci ! Au fait,
soyez sûr que vous avez édité le fichier .db, les autres documents étant générés à partir de celui-ci.
Un fichier Makefile est fourni pour vous aider à créer des fichiers PostScript, dvi, pdf, html et texte. Vous pouvez avoir
à installer les docbook, docbook-utils, ghostscript et tetex pour obtenir tous les formats de sortie.
Faites attention de ne pas éditer le fichier 2.4routing.sgml ! Il contient une ancienne version du HOWTO. Le bon
fichier est lartc.db.
2-6 - Liste de diffusion
Les auteurs reçoivent de plus en plus de courriers électroniques à propos de cet HOWTO. Vu l'intérêt de la
communauté, il a été décidé la mise en place d'une liste de diffusion où les personnes pourront discuter du routage
avancé et du contrôle de trafic. Vous pouvez vous abonner à la liste ici.
Il devra être noté que les auteurs sont très hésitants à répondre à des questions qui n'ont pas été posées sur la liste.
Nous aimerions que la liste devienne une sorte de base de connaissances. Si vous avez une question, recherchez,
s'il vous plaît, d'abord dans l'archive, et ensuite postez-la dans la liste de diffusion.
2-7 - Plan du document
Nous allons essayer de faire des manipulations intéressantes dès le début, ce qui veut dire que tout ne sera pas
expliqué en détail tout de suite. Veuillez passer sur ces détails, et accepter de considérer qu'ils deviendront clairs
par la suite.
Le routage et le filtrage sont deux choses distinctes. Le filtrage est très bien documenté dans le HOWTO de Rusty,
disponible ici :
• The netfilter/iptables HOWTO's
Nous nous focaliserons principalement sur ce qu'il est possible de faire en combinant netfilter et iproute2.
3 - Introduction à iproute2
3-1 - Pourquoi iproute2 ?
La plupart des distributions Linux et des UNIX utilisent couramment les vénérables commandes arp, ifconfig et
route. Bien que ces outils fonctionnent, ils montrent quelques comportements inattendus avec les noyaux Linux des
séries 2.2 et plus. Par exemple, les tunnels GRE font partie intégrante du routage de nos jours, mais ils nécessitent
des outils complètement différents.
Avec iproute2, les tunnels font partie intégrante des outils.

- 8 -
Les noyaux Linux des séries 2.2 et plus ont un sous-système réseau complètement réécrit. Ce nouveau codage de la
partie réseau apporte à Linux des performances et des fonctionnalités qui n'ont pratiquement pas d'équivalent parmi
les autres systèmes d'exploitation. En fait, le nouveau logiciel de filtrage, routage et de classification possède plus
de fonctionnalités que les logiciels fournis sur beaucoup de routeurs dédiés, de pare-feu et de produits de mise en
forme (shaping) du trafic.
Dans les systèmes d'exploitation existants, au fur et à mesure que de nouveaux concepts réseau apparaissaient, les
développeurs sont parvenus à les greffer sur les structures existantes. Ce travail constant d'empilage de couches
a conduit à des codes réseau aux comportements étranges, un peu comme les langues humaines. Dans le passé,
Linux émulait le mode de fonctionnement de SunOS, ce qui n'était pas l'idéal.
La nouvelle structure d'iproute2 a permis de formuler clairement des fonctionnalités impossibles à implémenter dans
le sous-système réseau précédent.
3-2 - Un tour d'horizon d'iproute2
Linux possède un système sophistiqué d'allocation de bande passante appelé Contrôle de trafic (Traffic Control). Ce
système supporte différentes méthodes pour classer, ranger par ordre de priorité, partager et limiter le trafic entrant
et sortant.
Nous commencerons par un petit tour d'horizon des possibilités d'iproute2.
3-3 - Prérequis
Vous devez être sûr que vous avez installé les outils utilisateur (NdT : userland tools, par opposition à la partie
« noyau » d'iproute2). Le paquet concerné s'appelle iproute sur RedHat et Debian. Autrement, il peut être trouvé à
ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??????.tar.gz.
Vous pouvez aussi essayer iproute2-current.tar.gz pour la dernière version.
Certains éléments d'iproute vous imposent l'activation de certaines options du noyau. Il devra également être noté
que toutes les versions de RedHat jusqu'à la version 6.2 incluse n'ont pas les fonctionnalités du contrôle de trafic
activées dans le noyau fourni par défaut.
RedHat 7.2 contient tous les éléments par défaut.
Soyez également sûr que vous avez le support netlink, même si vous devez choisir de compiler votre propre noyau ;
iproute2 en a besoin.
3-4 - 3.4. Explorer votre configuration courante
Cela peut vous paraître surprenant, mais iproute2 est déjà configuré ! Les commandes courantes ifconfig et route
utilisent déjà les appels système avancés d'iproute2, mais essentiellement avec les options par défaut (c'est-à-dire
ennuyeuses).
L'outil ip est central, et nous allons lui demander de nous montrer les interfaces.
3-4-1 - ip nous montre nos liens
[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

- 9 -
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
link/ppp
La sortie peut varier, mais voici ce qui est affiché pour mon routeur NAT (NdT : traduction d'adresse) chez moi.
J'expliquerai seulement une partie de la sortie, dans la mesure où tout n'est pas directement pertinent.
La première interface que nous voyons est l'interface loopback. Bien que votre ordinateur puisse fonctionner sans,
je vous le déconseille. La taille de MTU (unité maximum de transmission) est de 3924 octets, et loopback n'est
pas supposé être mis en file d'attente, ce qui prend tout son sens dans la mesure où cette interface est le fruit de
l'imagination de votre noyau.
Je vais passer sur l'interface dummy pour l'instant, et il se peut qu'elle ne soit pas présente sur votre ordinateur. Il y
a ensuite mes deux interfaces physiques, l'une du côté de mon modem câble, l'autre servant mon segment Ethernet
à la maison. De plus, nous voyons une interface ppp0.
Notons l'absence d'adresses IP. Iproute déconnecte les concepts de « liens » et « d'adresses IP ». Avec l'IP aliasing,
le concept de l'adresse IP canonique est devenu, de toute façon, sans signification.
ip nous montre bien, cependant, l'adresse MAC, l'identifiant matériel de nos interfaces Ethernet.
3-4-2 - ip nous montre nos adresses IP
[ahu@home ahu]$ ip address show
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
link/ppp
inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0
Cela contient plus d'informations : ip montre toutes nos adresses, et à quelles cartes elles appartiennent. inet signifie
Internet (IPv4). Il y a beaucoup d'autres familles d'adresses, mais elles ne nous concernent pas pour le moment.
Examinons l'interface eth0 de plus près. Il est dit qu'elle est reliée à l'adresse Internet 10.0.0.1/8. Qu'est-ce que cela
signifie ? Le /8 désigne le nombre de bits réservés à l'adresse réseau. Il y a 32 bits, donc il reste 24 bits pour désigner
une partie de notre réseau. Les 8 premiers bits de 10.0.0.1 correspondent à 10.0.0.0, notre adresse réseau, et notre
masque de sous-réseau est 255.0.0.0.
Les autres bits repèrent des machines directement connectées à cette interface. Donc, 10.250.3.13 est directement
disponible sur eth0, comme l'est 10.0.0.1 dans notre exemple.
Avec ppp0, le même concept existe, bien que les nombres soient différents. Son adresse est 212.64.94.251, sans
masque de sous-réseau. Cela signifie que vous avez une liaison point à point et que toutes les adresses, à l'exception
de 212.64.94.251, sont distantes. Il y a cependant plus d'informations. En effet, on nous dit que de l'autre côté du
lien, il n'y a encore qu'une seule adresse, 212.64.94.1. Le /32 nous précise qu'il n'y a pas de « bits réseau ».
Il est absolument vital que vous compreniez ces concepts. Référez-vous à la documentation mentionnée au début
de ce HOWTO si vous avez des doutes.

- 10 -
Vous pouvez aussi noter qdisc, qui désigne la gestion de la mise en file d'attente (Queueing Discipline). Cela
deviendra vital plus tard.
3-4-3 - ip nous montre nos routes
Nous savons maintenant comment trouver les adresses 10.x.y.z, et nous sommes capables d'atteindre 212.64.94.1.
Cela n'est cependant pas suffisant, et nous avons besoin d'instructions pour atteindre le monde. L'Internet est
disponible via notre connexion PPP, et il se trouve que 212.64.94.1 est prêt à propager nos paquets à travers le
monde, et à nous renvoyer le résultat.
[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0 proto kernel scope link src 212.64.94.251
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0
Cela se comprend de soi-même. Les quatre premières lignes donnent explicitement ce qui était sous-entendu par
ip address show, la dernière ligne nous indiquant que le reste du monde peut être trouvé via 212.64.94.1, notre
passerelle par défaut. Nous pouvons voir que c'est une passerelle à cause du mot « via », qui nous indique que nous
avons besoin d'envoyer les paquets vers 212.64.94.1, et que c'est elle qui se chargera de tout.
En référence, voici ce que l'ancien utilitaire route nous propose :
[ahu@home ahu]$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
212.64.94.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 212.64.94.1 0.0.0.0 UG 0 0 0 ppp0
3-5 - ARP
ARP est le Protocole de Résolution d'Adresse (Address Resolution Protocol). Il est décrit dans le RFC 826. ARP
est utilisé par une machine d'un réseau local pour retrouver l'adresse matérielle (la localisation) d'une autre machine
sur le même réseau. Les machines sur Internet sont généralement connues par leur nom auquel correspond une
adresse IP. C'est ainsi qu'une machine sur le réseau foo.com est capable de communiquer avec une autre machine
qui est sur le réseau bar.net. Une adresse IP, cependant, ne peut pas vous indiquer la localisation physique de la
machine. C'est ici que le protocole ARP entre en jeu.
Prenons un exemple très simple. Supposons que j'aie un réseau composé de plusieurs machines, dont la machine
foo d'adresse IP 10.0.0.1 et la machine bar qui a l'adresse IP 10.0.0.2. Maintenant, foo veut envoyer un ping vers bar
pour voir s'il est actif, mais foo n'a aucune indication sur la localisation de bar. Donc, si foo décide d'envoyer un ping
vers bar, il a besoin d'envoyer une requête ARP. Cette requête ARP est une façon pour foo de crier sur le réseau
« Bar (10.0.0.2) ! Où es-tu ? ». Par conséquent, toutes les machines sur le réseau entendront foo crier, mais seul
bar (10.0.0.2) répondra. Bar enverra une réponse ARP directement à foo ; ce qui revient à dire : « Foo (10.0.0.1) ! je
suis ici, à l'adresse 00:60:94:E:08:12 ». Après cette simple transaction utilisée pour localiser son ami sur le réseau,
foo est capable de communiquer avec bar jusqu'à ce qu'il (le cache ARP de foo) oublie où bar est situé (typiquement
au bout de 15 minutes sur Unix).
Maintenant, voyons comment cela fonctionne. Vous pouvez consulter votre cache (table) ARP (neighbor) comme
ceci :
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

- 11 -
Comme vous pouvez le voir, ma machine espa041 (9.3.76.41) sait où trouver espa042 (9.3.76.42) et espagate
(9.3.76.1). Maintenant, ajoutons une autre machine dans le cache ARP.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Par conséquent, lorsque espa041 a essayé de contacter espa043, l'adresse matérielle de espa043 (sa localisation)
a alors été ajoutée dans le cache ARP. Donc, tant que la durée de vie de l'entrée correspondant à espa043 dans le
cache ARP n'est pas dépassée, espa041 sait localiser espa043 et n'a plus besoin d'envoyer de requête ARP.
Maintenant, effaçons espa043 de notre cache ARP.
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
9.3.76.43 dev eth0 nud failed
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale
Maintenant, espa041 a à nouveau oublié la localisation d'espa043 et aura besoin d'envoyer une autre requête ARP la
prochaine fois qu'il voudra communiquer avec lui. Vous pouvez aussi voir ci-dessus que l'état d'espagate (9.3.76.1)
est passé en stale. Cela signifie que la localisation connue est encore valide, mais qu'elle devra être confirmée à
la première transaction avec cette machine.
4 - Règles - bases de données des politiques de routage
Si vous avez un routeur important, il se peut que vous vouliez satisfaire les besoins de différentes personnes, qui
peuvent être traitées différemment. Les bases de données des politiques de routage vous aident à faire cela, en
gérant plusieurs ensembles de tables de routage.
Si vous voulez utiliser cette fonctionnalité, assurez-vous que le noyau est compilé avec les options IP : Advanced
router et IP : policy routing.
Quand le noyau doit prendre une décision de routage, il recherche quelle table consulter. Par défaut, il y a trois tables.
L'ancien outil route modifie les tables principale (main) et locale (local), comme le fait l'outil ip (par défaut).
Les règles par défaut :
[ahu@home ahu]$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Ceci liste la priorité de toutes les règles. Nous voyons que toutes les règles sont appliquées à tous les paquets (from
all). Nous avons vu la table main précédemment, sa sortie s'effectuant avec ip route ls, mais les tables local et
default sont nouvelles.
Si nous voulons faire des choses fantaisistes, nous pouvons créer des règles qui pointent vers des tables différentes
et qui nous permettent de redéfinir les règles de routage du système.

- 12 -
Pour savoir exactement ce que fait le noyau en présence d'un assortiment de règles plus complet, référez-vous à la
documentation ip-cref d'Alexey [NdT : dans le paquet iproute2 de votre distribution].
4-1 - Politique de routage simple par l'adresse source
Prenons encore une fois un exemple réel. J'ai deux modems câble, connectés à un routeur Linux NAT
(masquerading). Les personnes habitant avec moi me paient pour avoir accès à Internet. Supposons qu'un de mes
colocataires consulte seulement Hotmail et veuille payer moins. C'est d'accord pour moi, mais il utilisera le modem
le plus lent.
Le modem câble « rapide » est connu sous 212.64.94.251 et est en liaison PPP avec 212.64.94.1. Le modem câble
« lent » est connu sous diverses adresses IP : 212.64.78.148 dans notre exemple avec un lien vers 195.96.98.253.
La table locale :
[ahu@home ahu]$ ip route list table local
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 10.0.0.1 dev eth0 proto kernel scope host src 10.0.0.1
broadcast 10.0.0.0 dev eth0 proto kernel scope link src 10.0.0.1
local 212.64.94.251 dev ppp0 proto kernel scope host src 212.64.94.251
broadcast 10.255.255.255 dev eth0 proto kernel scope link src 10.0.0.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 212.64.78.148 dev ppp2 proto kernel scope host src 212.64.78.148
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Il y a beaucoup de choses évidentes, mais aussi des choses qui ont besoin d'être précisées quelque peu, ce que
nous allons faire. La table de routage par défaut est vide.
Regardons la table principale (main) :
[ahu@home ahu]$ ip route list table main
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0
Maintenant, nous générons une nouvelle règle que nous appellerons John, pour notre hypothétique colocataire. Bien
que nous puissions travailler avec des nombres IP purs, il est plus facile d'ajouter notre table dans le fichier /etc/
iproute2/rt_tables.
# echo 200 John >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table John
# ip rule ls
0: from all lookup local
32765: from 10.0.0.10 lookup John
32766: from all lookup main
32767: from all lookup default
Maintenant, tout ce qu'il reste à faire est de générer la table John, et de vider le cache des routes :
# ip route add default via 195.96.98.253 dev ppp2 table John
# ip route flush cache
Et voilà qui est fait. Il ne reste plus, comme exercice laissé au lecteur, qu'à implémenter cela dans ip-up.

- 13 -
4-2 - Routage avec plusieurs accès Internet/fournisseurs d'accès
Une configuration classique est la suivante, où deux fournisseurs d'accès permettent la connexion d'un réseau local
(ou même d'une simple machine) à Internet.
________
+--------------+ /
| | |
+-------------+ Fournisseur 1+-------
__ | | | /
___/ _ +------+-------+ +--------------+ |
_/ __ | if1 | /
/ | | |
| Réseau Local -----+ Routeur Linux| | Internet
_ __/ | | |
__ __/ | if2 |
___/ +------+-------+ +--------------+ |
| | |
+-------------+ Fournisseur 2+-------
| | |
+--------------+ ________
Il y a généralement deux questions à se poser pour cette configuration.
4-2-1 - Accès séparé
La première est de savoir comment router les réponses aux paquets entrants par un fournisseur particulier, disons
le Fournisseur 1, vers ce même fournisseur.
Commençons par définir quelques symboles. $IF1 sera le nom de la première interface (if1 sur la figure au-dessus) et
$IF2 le nom de la deuxième interface. $IP1 sera alors l'adresse IP associée à $IF1 et $IP2 sera l'adresse IP associée
à $IF2. $P1 sera l'adresse IP de la passerelle du fournisseur d'accès 1 et $P2 sera l'adresse IP de la passerelle
du fournisseur d'accès 2. Enfin, $P1_NET sera l'adresse réseau à l'intérieur duquel se situe $P1 et $P2_NET sera
l'adresse réseau à l'intérieur duquel se situe $P2.
Deux tables de routage supplémentaires sont créées, par exemple T1 et T2. Celles-ci sont ajoutées dans /etc/
iproute2/rt_tables. La configuration du routage dans ces tables s'effectue de la façon suivante :
ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
Rien de vraiment spectaculaire. Une route est simplement positionnée vers la passerelle et une route par défaut via
cette passerelle est mise en place, comme nous le ferions dans le cas d'un seul fournisseur d'accès. Ici, les routes
sont placées dans des tables séparées, une par fournisseur d'accès. Il est à noter que la route vers le réseau suffit,
dans la mesure où elle indique comment trouver n'importe quel hôte dans ce réseau, ce qui inclut la passerelle.
La table de routage principale est maintenant configurée. C'est une bonne idée de router les éléments à destination
d'un voisin direct à travers l'interface connectée à ce voisin. Notez les arguments « src » qui assurent que la bonne
adresse IP source sera choisie.
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
Indiquez maintenant votre préférence pour votre route par défaut :
ip route add default via $P1

- 14 -
Vous configurez ensuite les règles de routage. Celles-ci définissent la table qui sera vraiment choisie pour le routage. Il
faut s'assurer que le routage s'effectue à travers une interface donnée si vous avez l'adresse source correspondante :
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
Cet ensemble de commandes vous assure que toutes les réponses au trafic entrant sur une interface particulière
seront envoyées par cette interface.
Notes d'un lecteur : si $P0_NET est le réseau local et $IF0 est son interface, alors les entrées
suivantes sont désirables :
ip route add $P0_NET dev $IF0 table T1
ip route add 127.0.0.0/8 dev lo table T1
ip route add 127.0.0.0/8 dev lo table T2
Nous avons maintenant une configuration très basique. Elle marchera pour tous les processus exécutés sur le routeur
lui-même, ainsi que pour le réseau local si celui-ci est masqué. Si ce n'est pas le cas, soit vous avez une plage
d'adresses IP pour chaque fournisseur d'accès, soit vous masquez vers l'un des deux fournisseurs d'accès. Dans
les deux cas, vous ajouterez des règles indiquant, en fonction de l'adresse IP de la machine du réseau local, vers
quel fournisseur vous allez router.
4-2-2 - Balance de charge
La seconde question concerne la balance de charge du trafic sortant vers les deux fournisseurs d'accès. Ceci n'est
pas vraiment très dur si vous avez déjà configuré l'accès séparé comme décrit ci-dessus.
Au lieu de choisir l'un des deux fournisseurs d'accès comme route par défaut, celle-ci peut être une route multichemin.
Par défaut, le noyau répartira les routes vers les deux fournisseurs d'accès. Ceci est réalisé de la façon suivante
(construit également sur l'exemple de la section de l'accès séparé) :
ip route add default scope global nexthop via $P1 dev $IF1 weight 1
nexthop via $P2 dev $IF2 weight 1
Ceci réalisera la balance des routes vers les deux fournisseurs. Les paramètres weight peuvent permettre de
favoriser un fournisseur par rapport à un autre.
Il est à noter que la balance de charge ne sera pas parfaite dans la mesure où elle est basée sur les routes et que
celles-ci sont mises dans des caches. Ceci signifie que les routes vers les sites les plus souvent utilisés passeront
toujours par le même fournisseur d'accès.
De plus, si vous voulez vraiment mettre en œuvre ceci, vous devriez également aller consulter les mises à jour de
Julien Anastasov à http://www.ssi.bg/~ja/#routes. Elles rendront le travail plus facile.
5 - GRE et autres tunnels
Il y a trois sortes de tunnels sous Linux : l'IP dans un tunnel IP, le tunnel GRE et les tunnels qui existent en dehors
du noyau (comme PPTP, par exemple).

- 15 -
5-1 - Quelques remarques générales à propos des tunnels :
Les tunnels peuvent faire des choses très inhabituelles et vraiment sympas. Ils peuvent aussi absolument tout
détraquer si vous ne les avez pas configurés correctement. Ne définissez pas votre route par défaut sur un tunnel,
à moins que vous ne sachiez EXACTEMENT ce que vous faites.
De plus, le passage par un tunnel augmente le poids des en-têtes (overhead), puisqu'un en-tête IP supplémentaire
est nécessaire. Typiquement, ce surcoût est de 20 octets par paquet. Donc, si la taille maximum de votre paquet
sur votre réseau (MTU) est de 1500 octets, un paquet qui est envoyé à travers un tunnel sera limité à une taille de
1480 octets. Ce n'est pas nécessairement un problème, mais soyez sûr d'avoir bien étudié la fragmentation et le
réassemblage des paquets IP quand vous prévoyez de relier des réseaux de grande taille par des tunnels. Et bien
sûr, la manière la plus rapide de creuser un tunnel est de creuser des deux côtés.
5-2 - IP dans un tunnel IP
Ce type de tunnel est disponible dans Linux depuis un long moment. Il nécessite deux modules, ipip.o et
new_tunnel.o.
Disons que vous avez trois réseaux : deux réseaux internes A et B, et un réseau intermédiaire C (ou disons Internet).
Les caractéristiques du réseau A sont :
réseau 10.0.1.0
masque de sous-réseau 255.255.255.0
routeur 10.0.1.1
Le routeur a l'adresse 172.16.17.18 sur le réseau C.
et le réseau B :
réseau 10.0.2.0
routeur 10.0.2.1
Le routeur a l'adresse 172.19.20.21 sur le réseau C.
En ce qui concerne le réseau C, nous supposerons qu'il transmettra n'importe quel paquet de A vers B et vice-versa.
Il est également possible d'utiliser l'Internet pour cela.
Voici ce qu'il faut faire :
Premièrement, assurez-vous que les modules sont installés :
insmod ipip.o
insmod new_tunnel.o
Ensuite, sur le routeur du réseau A, faites la chose suivante :
ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0
et sur le routeur du réseau B :
ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0

- 16 -
Et quand vous aurez terminé avec votre tunnel :
ifconfig tunl0 down
Vite fait, bien fait. Vous ne pouvez pas transmettre les paquets de diffusion (broadcast), ni le trafic IPv6 à travers
un tunnel IP-IP. Vous ne pouvez connecter que deux réseaux IPv4 qui, normalement, ne seraient pas capables de
se « parler », c'est tout. Dans la mesure où la compatibilité a été conservée, ce code tourne depuis un bon moment,
et il reste compatible depuis les noyaux 1.3. Le tunnel Linux IP dans IP ne fonctionne pas avec d'autres systèmes
d'exploitation ou routeurs, pour autant que je sache. C'est simple, ça marche. Utilisez-le si vous le pouvez, autrement
utilisez GRE.
5-3 - Le tunnel GRE
GRE est un protocole de tunnel qui a été à l'origine développé par Cisco, et qui peut réaliser plus de choses que
le tunnel IP dans IP. Par exemple, vous pouvez aussi transporter du trafic multidiffusion (multicast) et de l'IPv6 à
travers un tunnel GRE.
Dans Linux, vous aurez besoin du module ip_gre.o.
5-3-1 - Le tunnel IPv4
Dans un premier temps, intéressons-nous au tunnel IPv4 :
Disons que vous avez trois réseaux : deux réseaux internes A et B, et un réseau intermédiaire C (ou disons Internet).
Les caractéristiques du réseau A sont :
réseau 10.0.1.0
routeur 10.0.1.1
Le routeur a l'adresse 172.16.17.18 sur le réseau C. Appelons ce réseau neta.
Et pour le réseau B :
réseau 10.0.2.0
routeur 10.0.2.1
Le routeur a l'adresse 172.19.20.21 sur le réseau C. Appelons ce réseau netb.
En ce qui concerne le réseau C, nous supposerons qu'il transmettra n'importe quels paquets de A vers B et vice-
versa. Comment et pourquoi, on s'en moque.
Sur le routeur du réseau A, nous faisons la chose suivante :
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb
Discutons un peu de cela. Sur la ligne 1, nous avons ajouté un périphérique tunnel, que nous avons appelé netb (ce
qui est évident, dans la mesure où c'est là que nous voulons aller). De plus, nous lui avons dit d'utiliser le protocole
GRE (mode gre), que l'adresse distante est 172.19.20.21 (le routeur de l'autre côté), que nos paquets « tunnelés »
devront être générés à partir de 172.16.17.18 (ce qui autorise votre serveur à avoir plusieurs adresses IP sur le

- 17 -
réseau C et ainsi vous permet de choisir laquelle sera utilisée pour votre tunnel) et que le champ TTL de vos paquets
sera fixé à 255 (ttl 255).
La deuxième ligne active le périphérique.
Sur la troisième ligne, nous avons donné à cette nouvelle interface l'adresse 10.0.1.1. C'est bon pour de petits
réseaux, mais quand vous commencez une exploitation minière (BEAUCOUP de tunnels !), vous pouvez utiliser une
autre gamme d'adresses IP pour vos interfaces « tunnel » (dans cet exemple, vous pourriez utiliser 10.0.3.0).
Sur la quatrième ligne, nous positionnons une route pour le réseau B. Notez la notation différente pour le masque de
sous-réseau. Si vous n'êtes pas familiarisé avec cette notation, voici comment ça marche : vous écrivez le masque de
sous-réseau sous sa forme binaire, et vous comptez tous les 1. Si vous ne savez pas comment faire cela, rappelez-
vous juste que 255.0.0.0 est /8, 255.255.0.0 est /16 et 255.255.255.0 est /24. Et 255.255.254.0 est /23, au cas où
ça vous intéresserait.
Mais arrêtons ici, et continuons avec le routeur du réseau B.
ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set neta up
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta
Et quand vous voudrez retirer le tunnel sur le routeur A :
ip link set netb down
ip tunnel del netb
Bien sûr, vous pouvez remplacer netb par neta pour le routeur B.
5-3-2 - Le tunnel IPv6
Voir la section 6 pour une courte description des adresses IPv6.
À propos des tunnels.
Supposons que vous ayez le réseau IPv6 suivant, et que vous vouliez le connecter à une dorsale IPv6 (6bone) ou
à un ami.
Réseau 3ffe:406:5:1:5:a:2:1/96
Votre adresse IPv4 est 172.16.17.18, et le routeur 6bone a une adresse IPv4 172.22.23.24.
ip tunnel add sixbone mode sit remote 172.22.23.24 local 172.16.17.18 ttl 255
ip link set sixbone up
ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
ip route add 3ffe::/15 dev sixbone
Voyons cela de plus près. Sur la première ligne, nous avons créé un périphérique tunnel appelé sixbone. Nous lui
avons affecté le mode sit (qui est le tunnel IPv6 sur IPv4) et lui avons dit où l'on va (remote) et d'où l'on vient (local).
TTL est configuré à son maximum : 255. Ensuite, nous avons rendu le périphérique actif (up). Puis, nous avons ajouté
notre propre adresse réseau et configuré une route pour 3ffe::/15 à travers le tunnel.
Les tunnels GRE constituent actuellement le type de tunnel préféré. C'est un standard qui est largement adopté,
même à l'extérieur de la communauté Linux, ce qui constitue une bonne raison de l'utiliser.

- 18 -
5-4 - Tunnels dans l'espace utilisateur
Il y a des dizaines d'implémentations de tunnels à l'extérieur du noyau. Les plus connues sont bien sûr PPP et PPTP,
mais il y en a bien plus (certaines propriétaires, certaines sécurisées, d'autres qui n'utilisent pas IP), qui dépassent
le cadre de ce HOWTO.
6 - Tunnel IPv6 avec Cisco et/ou une dorsale IPv6 (6bone)
Par Marco Davids <marco@sara.nl>
NOTE au mainteneur :
En ce qui me concerne, ce tunnel IPv6-IPv4 n'est pas, par définition, un tunnel GRE. Vous pouvez réaliser un
tunnel IPv6 sur IPv4 au moyen des périphériques tunnels GRE (tunnels GRE N'IMPORTE QUOI vers IPv4), mais le
périphérique utilisé ici (sit) ne permet que des tunnels IPv6 sur IPv4, ce qui est quelque chose de différent.
6-1 - Tunnel IPv6
Voici une autre application des possibilités de tunnels de Linux. Celle-ci est populaire parmi les premiers adeptes
d'IPv6 ou les pionniers si vous préférez. L'exemple pratique décrit ci-dessous n'est certainement pas la seule manière
de réaliser un tunnel IPv6. Cependant, c'est la méthode qui est souvent utilisée pour réaliser un tunnel entre Linux
et un routeur Cisco IPv6 et l'expérience m'a appris que c'est ce type d'équipement que beaucoup de personnes ont.
Dix contre un que ceci s'appliquera aussi pour vous ;-).
De petites choses à propos des adresses IPv6.
Les adresses IPv6 sont, en comparaison avec les adresses IPv4, vraiment grandes : 128 bits contre
32 bits. Et ceci nous fournit la chose dont nous avons besoin : beaucoup, beaucoup d'adresses IP :
340,282,266,920,938,463,463,374,607,431,768,211,465 pour être précis. À part ceci, IPv6 (ou IPng génération
suivante (Next Generation)) est supposé fournir des tables de routage plus petites sur les routeurs des dorsales
Internet, une configuration plus simple des équipements, une meilleure sécurité au niveau IP et un meilleur support
pour la Qualité de Service (QoS).
Un exemple : 2002:836b:9820:0000:0000:0000:836b:9886
Écrire les adresses IPv6 peut être un peu lourd. Il existe donc des règles qui rendent la vie plus facile :
• ne pas utiliser les zéros de tête, comme dans IPv4 ;
• utiliser des deux-points de séparation tous les 16 bits ou 2 octets ;
• quand vous avez beaucoup de zéros consécutifs, vous pouvez écrire ::. Vous ne pouvez, cependant, faire
cela qu'une seule fois par adresse et seulement pour une longueur de 16 bits.
L'adresse 2002:836b:9820:0000:0000:0000:836b:9886 peut être écrite 2002:836b:9820::836b:9886, ce qui est plus
amical.
Un autre exemple : l'adresse 3ffe:0000:0000:0000:0000:0000:34A1:F32C peut être écrite 3ffe::20:34A1:F32C, ce qui
est beaucoup plus court.
IPv6 a pour but d'être le successeur de l'actuel IPv4. Dans la mesure où cette technologie est relativement récente,
il n'y a pas encore de réseau natif IPv6 à l'échelle mondiale. Pour permettre un développement rapide, la dorsale
IPv6 (6bone) a été introduite.

- 19 -
Les réseaux natifs IPv6 sont interconnectés grâce à l'encapsulation du protocole IPv6 dans des paquets IPv4, qui
sont envoyés à travers l'infrastructure IPv4 existante, d'un site IPv6 à un autre.
C'est dans cette situation que l'on monte un tunnel.
Pour être capable d'utiliser IPv6, vous devrez avoir un noyau qui le supporte. Il y a beaucoup de bons documents qui
expliquent la manière de réaliser cela. Mais, tout se résume à quelques étapes :
• récupérer une distribution Linux récente, avec une glibc convenable ;
• récupérer alors les sources à jour du noyau.
Si tout cela est fait, vous pouvez alors poursuivre en compilant un noyau supportant l'IPv6 :
• allez dans /usr/src/linux et tapez :
make menuconfig,
choisissez Networking Options ;
• Sélectionnez The IPv6 protocol, IPv6: enable EUI-64 token format, IPv6: disable provider based addresses.
ASTUCE :Ne compilez pas ces options en tant que module. Ceci ne marchera souvent pas bien.
En d'autres termes, compilez IPv6 directement dans votre noyau. Vous pouvez alors sauvegarder votre configuration
comme d'habitude et entreprendre la compilation de votre noyau.
ASTUCE: Avant de faire cela, modifiez votre Makefile comme suit : EXTRAVERSION = -x ; --> ; EXTRAVERSION
= -x-IPv6.
Il y a beaucoup de bonnes documentations sur la compilation et l'installation d'un noyau. Cependant, ce document
ne traite pas de ce sujet. Si vous rencontrez des problèmes à ce niveau, allez et recherchez dans la documentation
des renseignements sur la compilation du noyau Linux correspondant à vos propres spécifications.
Le fichier /usr/src/linux/README peut constituer un bon départ. Après avoir réalisé tout ceci, et redémarré avec votre
nouveau noyau flambant neuf, vous pouvez lancer la commande /sbin/ifconfig -a et noter un nouveau périphérique
sit0. SIT signifie Transition Simple d'Internet (Simple Internet Transition). Vous pouvez vous autocomplimenter :
vous avez maintenant franchi une étape importante vers IP, la prochaine génération ;-)
Passons maintenant à l'étape suivante. Vous voulez connecter votre hôte ou peut-être même tout votre réseau LAN
à d'autres réseaux IPv6. Cela pourrait être la dorsale IPv6 « 6bone » qui a été spécialement mise en place dans
ce but particulier.
Supposons que vous ayez le réseau IPv6 suivant : 3ffe:604:6:8::/64 et que vous vouliez le connecter à une dorsale
IPv6 ou à un ami. Notez, s'il vous plaît, que la notation sous-réseau /64 est similaire à celle des adresses IPv4.
Votre adresse IPv4 est 145.100.24.181 et le routeur 6bone a l'adresse IPv4 145.100.1.5.
# ip tunnel add sixbone mode sit remote 145.100.1.5 [local 145.100.24.181 ttl 225]
# ip link set sixbone up
# ip addr add 3FFE:604:6:7::2/96 dev sixbone
# ip route add 3ffe::0/15 dev sixbone
Discutons de ceci. Dans la première ligne, nous avons créé un périphérique appelé sixbone. Nous lui avons donné
l'attribut sit (mode sit) (qui est le tunnel IPv6 dans IPv4) et nous lui avons dit où aller (remote) et d'où nous venions
(local). TTL est configuré à son maximum, 255.
Ensuite, nous avons rendu le périphérique actif (up). Après cela, nous avons ajouté notre propre adresse réseau et
configuré une route pour 3ffe::/15 (qui est actuellement la totalité du 6bone) à travers le tunnel. Si la machine sur
laquelle vous mettez en place tout ceci est votre passerelle IPv6, ajoutez alors les lignes suivantes :

- 20 -
# echo 1 >/proc/sys/net/ipv6/conf/all/forwarding
# /usr/local/sbin/radvd
En dernière instruction, radvd est un démon d'annonce comme zebra qui permet de supporter les fonctionnalités
d'autoconfiguration d'IPv6. Recherchez-le avec votre moteur de recherche favori. Vous pouvez vérifier les choses
comme ceci :
# /sbin/ip -f inet6 addr
Si vous arrivez à avoir radvd tournant sur votre passerelle IPv6 et que vous démarrez une machine avec IPv6 sur
votre réseau local, vous serez ravi de voir les bénéfices de l'autoconfiguration IPv6 :
# /sbin/ip -f inet6 addr
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue inet6 ::1/128 scope host
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 3ffe:604:6:8:5054:4cff:fe01:e3d6/64 scope global dynamic
valid_lft forever preferred_lft 604646sec inet6 fe80::5054:4cff:fe01:e3d6/10
scope link
Vous pouvez maintenant configurer votre serveur de noms pour les adresses IPv6. Le type A a un équivalent pour
IPv6 : AAAA. L'équivalent de in-addr.arpa est : ip6.int. Il y a beaucoup d'informations disponibles sur ce sujet.
Il y a un nombre croissant d'applications IPv6 disponibles, comme le shell sécurisé, telnet, inetd, le navigateur Mozilla,
le serveur web Apache et beaucoup d'autres. Mais ceci est en dehors du sujet de ce document de routage ;-).
Du côté Cisco, la configuration ressemblera à ceci :
!
interface Tunnel1
description IPv6 tunnel
no ip address
no ip directed-broadcast
ipv6 address 3FFE:604:6:7::1/96
tunnel source Serial0
tunnel destination 145.100.24.181
tunnel mode ipv6ip
!
ipv6 route 3FFE:604:6:8::/64 Tunnel1
Si vous n'avez pas un Cisco à votre disposition, essayez un des prestataires de tunnel IPv6 disponibles sur Internet.
Ils sont prêts à configurer leur Cisco avec un tunnel supplémentaire pour vous, le plus souvent au moyen d'une
agréable interface web. Cherchez ipv6 tunnel broker avec votre moteur de recherche favori.
7 - IPSEC : IP sécurisé à travers Internet
À ce jour, deux versions d'IPSEC sont disponibles pour Linux. FreeS/WAN, qui fut la première implémentation
majeure, existe pour les noyaux Linux 2.2 et 2.4. Ce projet a un site officiel et également un site non officiel, qui
est bien maintenu. FreeS/WAN n'a jamais été intégré dans le noyau pour un certain nombre de raisons. Celle qui est
la plus souvent mentionnée concerne un problème « politique » avec les Américains travaillant sur la cryptographie
qui freinent son exportabilité. De plus, la mise en place de FreeS/WAN dans le noyau Linux est délicate, ce qui n'en
fait pas un bon candidat pour une réelle intégration.
De plus, des personnes se sont inquiétées de la qualité du code. Pour configurer FreeS/WAN, de nombreuses
documentations sont disponibles.
Une implémentation native d'IPSEC est présente dans le noyau à partir de la version Linux 2.5.47. Elle a été écrite
par Alexey Kuznetsov et Dave Miller, qui se sont inspirés des travaux du groupe USAGI IPv6. Avec cette fusion, les
CryptoAPI de James Morris deviennent également une partie du noyau, qui fait ainsi vraiment du cryptage.

- 21 -
Ce HOWTO ne documente que la version 2.5 d'IPSEC. FreeS/WAN est recommandé pour l'instant pour les
utilisateurs de Linux 2.4.Faites cependant attention, dans la mesure où sa configuration est différente de l'IPSEC
natif. Il y a maintenant une mise à jour qui permet au code FreeS/WAN de l'espace utilisateur de fonctionner avec
l'IPSEC natif de Linux.
À partir du noyau 2.5.49, IPSEC fonctionne sans l'ajout de mises à jour supplémentaires.
Les outils de l'espace utilisateur sont disponibles ici. Il y a plusieurs programmes disponibles ;
celui qui est proposé dans le lien est basé sur Racoon.
Lors de la compilation du noyau, soyez sûr d'activer 'PF_KEY', 'AH' et tous les éléments de
CryptoAPI !
L'auteur de ce chapitre est un complet nigaud en ce qui concerne IPSEC ! Si vous trouvez les
inévitables erreurs, envoyez un courrier électronique à Bert Hubert <ahu@ds9a.nl>.
Tout d'abord, nous montrerons comment configurer manuellement une communication sécurisée entre deux hôtes.
Une grande partie de ce processus peut être automatisée, mais nous le ferons ici à la main afin de comprendre ce
qui se passe « sous le capot ».
Passez à la section suivante si la seule gestion automatique des clés vous intéresse. Soyez cependant conscient
que la compréhension de la gestion manuelle des clés est utile.
7-1 - Introduction sur la gestion manuelle des clés
IPSEC est un sujet compliqué. De nombreuses informations sont disponibles en ligne. Ce HOWTO se concentrera
sur la mise en place et à l'explication des principes de base. Tous les exemples sont basés sur Racoon dont le lien
est donné au-dessus.
Certaines configurations iptables rejettent les paquets IPSEC ! Pour transmettre IPSEC,
utilisez : iptables -A xxx -p 50 -j ACCEPT et 'iptables -A xxx -p 51 -j ACCEPT.
IPSEC offre une version sécurisée de la couche IP (Internet Protocol). La sécurité dans ce contexte prend deux
formes : l'encryptage et l'authentification. Une vision naïve de la sécurité ne propose que le cryptage. On peut
cependant montrer facilement que c'est insuffisant : il se peut que vous ayez une communication cryptée, mais vous
n'avez aucune garantie que l'hôte distant est bien celui auquel vous pensez.
IPSEC supporte 'Encapsulated Security Payload' (Encapsulation Sécurisée de la Charge utile) (ESP) pour le cryptage
et 'Authentication Header' (En-tête d'Authentification) (AH) pour authentifier le partenaire distant. Vous pouvez
configurer les deux, ou décider de ne faire que l'un des deux.
ESP et AH s'appuient tous les deux sur des Associations de Sécurité (Security Associations (SA)). Une Association
de Sécurité (SA) consiste en une source, une destination et une instruction. Un exemple simple d'Association de
Sécurité (SA) pour l'authentification peut ressembler à ceci :
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
Ceci indique que le trafic allant de 10.0.0.11 vers 10.0.0.216 a besoin d'un En-tête d'Authentification (AH) qui peut
être signé en utilisant HMAC-MD et le secret 1234567890123456. Cette instruction est repérée par l'identificateur
SPI (Security Parameter Index) 15700, dont nous parlerons plus par la suite. Le point intéressant à propos des
Associations de Sécurité (SA) est qu'elles sont symétriques. Les deux côtés de la conversation partagent exactement
la même Association de Sécurité (SA), qui n'est pas recopiée sur l'hôte distant. Notez cependant qu'il n'y a pas
de règles « d'inversion automatique ». Cette Association de Sécurité (SA) décrit une authentification possible de
10.0.0.11 vers 10.0.0.216. Pour un trafic bidirectionnel, deux Associations de Sécurité (SA) sont nécessaires.

- 22 -
Un exemple d'Association de Sécurité (SA) pour le cryptage ESP :
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
Ceci signifie que le trafic allant de 10.0.0.11 vers 10.0.0.216 est chiffré en utilisant 3des-cbc avec la clé
123456789012123456789012. L'identificateur SPI est 15701.
Jusqu'ici, nous avons vu que les Associations de Sécurité (SA) décrivent les instructions possibles, mais pas la
politique qui indique quand ces SA doivent être utilisées. En fait, il pourrait y avoir un nombre arbitraire de SA presque
identiques ne se différenciant que par les identificateurs SPI. Entre parenthèses, SPI signifie Security Parameter
Index, ou Index du Paramètre de Sécurité en français. Pour faire vraiment du cryptage, nous devons décrire une
politique. Cette politique peut inclure des choses comme « utiliser ipsec s'il est disponible » ou « rejeter le trafic à
moins que vous ayez ipsec ».
Une « Politique de Sécurité » (Security Policy (SP)) typique ressemble à ceci :
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
esp/transport//require
ah/transport//require;
Si cette configuration est appliquée sur l'hôte 10.0.0.216, cela signifie que tout le trafic allant vers 10.0.0.11 doit être
encrypté et encapsulé dans un en-tête d'authentification AH. Notez que ceci ne décrit pas quelle SA sera utilisée.
Cette détermination est un exercice laissé à la charge du noyau.
En d'autres termes, une Politique de Sécurité spécifie CE QUE nous voulons ; une Association de Sécurité décrit
COMMENT nous le voulons.
Les paquets sortants sont étiquetés avec le SPI SA ('le comment') que le noyau utilise pour l'encryptage et
l'authentification et l'hôte distant peut consulter les instructions de vérification et de décryptage correspondantes.
Ce qui suit est une configuration très simple permettant le dialogue de l'hôte 10.0.0.216 vers l'hôte 10.0.0.11 en
utilisant l'encryptage et l'authentification. Notez que le trafic de retour de cette première version est en clair et que
cette configuration ne doit pas être déployée.
Sur l'hôte 10.0.0.216 :
#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";
Sur l'hôte 10.0.0.11, nous donnons les mêmes Associations de Sécurité (SA). Nous ne donnons pas de Politique
de Sécurité :
#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";
Avec la mise en place de la configuration ci-dessus (ces fichiers peuvent être exécutés si 'setkey' est installé dans /
sbin), la commande ping 10.0.0.11 exécutée sur 10.0.0.216 va donner la sortie suivante avec tcpdump :
22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)
22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply

- 23 -
Notez que le paquet de retour provenant de 10.0.0.11 est en effet complètement visible. Le paquet ping émis par
10.0.0.216 ne peut évidemment pas être lu par tcpdump, mais celui-ci montre l'Index du Paramètre de Sécurité
(SPI) de l'AH, ainsi que l'ESP, qui indique à 10.0.0.11 comment vérifier l'authenticité de notre paquet et comment
le décrypter.
Quelques éléments doivent être mentionnés. La configuration ci-dessus est proposée dans de nombreux exemples
d'IPSEC, mais elle est très dangereuse. Le problème est qu'elle contient la politique indiquant à 10.0.0.216 comment
traiter les paquets allant vers 10.0.0.11 et comment 10.0.0.11 doit traiter ces paquets, mais ceci n'INDIQUE pas à
10.0.0.11 de rejeter le trafic non authentifié et non encrypté !
N'importe qui peut maintenant insérer des données « spoofées » (NdT : usurpées) et entièrement non cryptées que
10.0.0.1 acceptera. Pour remédier à ceci, nous devons avoir sur 10.0.0.11 une Politique de Sécurité pour le trafic
entrant :
#!/sbin/setkey -f
spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
Ceci indique à 10.0.0.11 que tout le trafic venant de 10.0.0.216 nécessite d'avoir un ESP et AH valide.
Maintenant, pour compléter cette configuration, nous devons également renvoyer un trafic encrypté et authentifié. La
configuration complète sur 10.0.0.216 est la suivante :
#!/sbin/setkey -f
flush;
spdflush;
# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";
spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
Et sur 10.0.0.11 :
#!/sbin/setkey -f
flush;
spdflush;
# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";
spdadd 10.0.0.216 10.0.0.11 any -P in ipsec

- 24 -
Notez que, dans cet exemple, nous avons utilisé des clés identiques pour les deux directions du trafic. Ceci n'est
cependant en aucun cas exigé.
Pour examiner la configuration que nous venons de créer, exécuter setkey -D, qui montre les SA ou setkey -DP
qui montre les politiques configurées.
7-2 - Gestion automatique des clés
Dans la section précédente, l'encryptage était configuré pour utiliser simplement le partage de secrets. En d'autres
termes, pour rester sécurisé, nous devons transférer la configuration de notre encryptage à travers un tunnel sécurisé.
Si nous avons configuré l'hôte distant par telnet, n'importe quel tiers pourrait avoir pris connaissance de notre secret
partagé et, ainsi, notre configuration ne serait plus sûre.
De plus, puisque le secret est partagé, ce n'est pas un secret. L'hôte distant ne peut pas en faire grand-chose, mais
nous devons être sûrs d'utiliser un secret différent pour les communications avec tous nos partenaires. Ceci nécessite
un grand nombre de clés. Pour 10 partenaires, nous devrions avoir au moins 50 secrets différents.
En plus du problème des clés symétriques, le renouvellement des clés est également nécessaire. Si un tiers écoute
suffisamment le trafic, il peut être en position de retrouver la clé par rétro-ingénierie. On peut s'en prémunir en
modifiant la clé de temps en temps, mais ce processus a besoin d'être automatisé.
Un autre problème est que la gestion manuelle des clés décrite au-dessus impose de définir précisément les
algorithmes et les longueurs de clés utilisés, ce qui nécessite une grande coordination avec l'hôte distant. Il serait
préférable d'avoir la capacité à décrire une politique des clés plus large comme par exemple « Nous pouvons faire
du 3DES et du Blowfish avec les longueurs de clés suivantes ».
Pour résoudre ces problèmes, IPSEC fournit l'Echange de Clé sur Internet (Internet Key Echange (IKE)) permettant
d'automatiser l'échange de clés générées aléatoirement. Ces clés sont transmises en utilisant une technologie
d'encryptage asymétrique négociée.
L'implémentation IPSEC de Linux 2.5 fonctionne avec le démon IKE « KAME racoon ». Depuis le 9 novembre, la
version de racoon présente la distribution iptools d'Alexey peut être compilée en supprimant, au préalable #include
<net/route.h> dans deux fichiers. Je fournis une version précompilée.
L'Echange de Clé sur Internet (IKE) doit avoir accès au port UDP 500. Soyez sûr que iptables
ne le bloque pas.
7-2-1 - Théorie
Comme expliqué avant, la gestion automatique des clés réalise beaucoup d'opérations pour nous. Spécifiquement,
elle crée à la volée les Associations de Sécurité. Elle ne configure cependant pas la politique pour nous, ce qui est
le fonctionnement attendu.
Donc, pour bénéficier de IKE, configurez une politique, mais ne fournissez aucune Association de Sécurité. Si le
noyau découvre qu'il y a une politique IPSEC, mais pas d'Association de Sécurité, il va le notifier au démon IKE qui
va chercher à en négocier une.
De nouveau, rappelons que la Politique de Sécurité spécifie CE QUE nous voulons tandis que l'Association de
Sécurité décrit COMMENT nous le voulons. L'utilisation de la gestion automatique des clés nous permet de ne
spécifier que ce que nous voulons.

Routage avancé et contrôle du trafic sous linux

Routage avancé et contrôle du trafic sous linux

Recommended

Recommended

More Related Content

What's hot

What's hot (7)

Viewers also liked

Viewers also liked (15)

Similar to Routage avancé et contrôle du trafic sous linux

Similar to Routage avancé et contrôle du trafic sous linux (20)

Routage avancé et contrôle du trafic sous linux