|
Background
Le tunneling est une pratique
courante visant à transporter un protocole (et ses
données) dans un autre. Pour les personnes qui ne
sont pas familières avec la notion de couche
réseau, le modèle de référence habituel est le
modèle OSI de l'ISO qui comporte 7 couches :
 Théoriquement,
chaque couche se veut indépendante des autres donc
le protocole correspondant à chacune de ces
couches transporte en fait le protocole de niveau
supérieur. Prenons l'exemple d'une stack TCP/IP
classique (sur Ethernet, et en faisant abstraction
des couches supérieures) :
 On
a donc bien du TCP sur de l'IP sur de l'Ethernet
(en anglais "over", ou "o"). Mais puisqu'il s'agit
de l'ordre normal respectant le standard ISO, on
ne parle pas alors d'encapsulation à proprement
parler; il est par contre tout à fait envisageable
de transporter, au moyen d'un protocole donné,
d'autres protocoles de niveau équivalent dans le
modèle OSI, voir inférieur. Et lorsque le
protocole d'encapsulation permet de protéger les
données qu'il transporte (d'une manière ou d'une
autre, sans parler forcément de chiffrement), on
préferera employer le terme de tunnel. Prenons
quelques exemples d'encapsulations courantes :
- Pour établir une liaison point-à-point sur
de l'ethernet, on pourra utiliser PPPoE
(RFC
2516 : PPP over Ethernet, les 2 étant au
même niveau liaison).
- Pour les utilisateurs de modems ADSL, il est
courant de rencontrer PPPoA
(RFC
2364 : PPP over ATM-AAL5) qui permet
d'obtenir une liaison point-à-point avec le
fournisseur d'accès internet.
- Plus communément, l'ATM requiert une
encapsulation particulière pour tous les
protocoles (avec AAL5); cette encapsulation est
définie dans la RFC
2684.
- L2TP (Layer 2 Tunneling Protocol, RFC
2661) est un protocole issu de la
normalisation de PPTP et L2F, 2 protocoles de
tunneling de niveau 2. Bien qu'il soit lui aussi
-comme son nom l'indique- un protocole de niveau
2, il est souvent utilisé sur UDP et IP pour
transporter du PPP (et un autre protocole
au-dessus). On obtient donc :
.../PPP/L2TP/UDP/IP/...
Nous
verrons plus tard un exemple d'utilisation
concret de ce genre de technique.
- Le dernier cas que nous nous devons
d'aborder (sécurité oblige) est celui d'IPSec
(voir fiche correspondante). Ce protocole
est par définition de niveau 3 (réseau), tout
comme IP qu'il sert à protéger. Utilisé en mode
tunneling, IPSec encapsule des paquets IP
complets et les protège jusqu'à leur
destination, où les paquets IP sont "décapsulés"
et restitués.
Exemples
Aussi étrange que cela puisse
paraitre, le tunneling peut s'avérer utile à IPSec
lui-même. En effet, nombre de réseaux actuels
utilisent des adresses IP dites privées,
c'est-à-dire non-routables sur Internet, car cela
permet d'augmenter considérablement le nombre
d'adresses disponibles. La conséquence directe est
le fait que les passerelles qui connectent ces
réseaux à Internet implémentent des fonctionalités
de NAT (Network Adress Translation) et de PAT
(Port Adress Translation), voir les 2, qui
permettent aux machines du réseau privé d'accéder
au monde extérieur quand le besoin se fait sentir,
et ce en utilisant une adresse publique allouée
dynamiquement par la passerelle.
Concrètement,
ces machines ne sont donc pas visibles à partir
d'Internet, et elles n'utilisent jamais leur
adresse privée lorsqu'elles accèdent à ce dernier.
Il est donc impossible d'utiliser IPSec entre une
de ces machines du réseau privé et une autre sur
Internet, car le NAT va modifier les adresses IPs
et casser ainsi les vérifications d'intégrité
inhérentes à IPSec. Ceci est valable pour le mode
tunneling d'IPSec (voir article
sur IPSec) mais également pour son mode
transport car une des particularités de TCP, par
exemple, est d'utiliser des checksums englobant le
header IP. Le seul mode éventuellement compatible
serait le mode nesting, mais il reste plus
compliqué à mettre en oeuvre.
C'est pourquoi,
nous allons illustrer ici le concept de tunneling
en montrant une façon de traverser une passerelle
grâce à de l'encapsulation. Tout d'abord, le
problème est de faire communiquer 2 machines de
manière sécurisée : un tunnel IPSec de bout en
bout est requis. D'autre part, il se trouve
que la première machine (A) est sur un réseau
privé protégé par une passerelle ayant une
fonctionnalité de NAT. De son côté, la machine B
est reliée au réseau de son fournisseur d'accès
Internet qui n'est pas forcément plus sûr que le
réseau public, d'où la nécessité d'utiliser IPSec
de bout en bout.
Premier exemple, le plus
simple : le but est d'établir un tunnel IP entre
A et une passerelle C du fournisseur d'accès
internet de B. Cette passerelle doit pour cela
implémenter cette fonctionnalité. D'autre part,
le tunnel IP peut traverser le NAT car il
n'applique aucune protection sur les données
qu'il transporte (ici IPSec) et la translation
d'adresse peut donc être effectuée.
 La
passerelle C décapsule les paquets IP et route
les paquets IPSec vers leur destination finale.
Le problème de cette solution est le manque de
sécurité du tunnel IP, qui n'offre par
définition aucune possibilité d'authentification
des tunnels entrants; il faut donc s'appuyer sur
des méchanismes annexes (certificats, etc...).
La stack de protocoles nécessaire à A pour
communiquer avec B sera donc la suivante
:
Application / TCP / IPSec / IP /
Ethernet
Celle de B reste normale;
il doit juste implémenter IPSec.
La deuxième possibilité est
d'utiliser L2TP, mentionné précédement, pour
créer un tunnel entre A et C. Bien que L2TP et
PPP ne permettent pas d'obtenir de forts
services de sécurité, il existe néanmoins
plusieurs solutions pour authentifier les
connexions distantes (provenant ici de A).
 Ici
encore, le protocole de base est IP car il
permet la traversée du NAT; attention, IP est
toujours utilisé jusqu'à C bien qu'il ne soit
représenté que partiellement car il n'est
intéressant que lors de la traversée du NAT.
Vient ensuite UDP qui est susceptible de
transporter de nombreux protocoles tout en
permettant de traverser certains équipements
réseau (tout comme des flux DNS). Nous trouvons
ensuite PPP sur L2TP qui permettent d'établir un
tunnel (connexion point-à-point) avec C.
Celui-ci doit donc implémenter la fonctionnalité
correspondante (L2TP Network Server ou LNS).
Enfin, comme dans le cas précédent, le flux
IPSec est routé vers sa destination finale, B.
La stack de protocoles nécessaire à A pour
communiquer avec B sera donc la suivante
:
Application / TCP / IPSec / PPP / L2TP /
UDP / IP / Ethernet
Celle de B reste
normale; il doit juste implémenter IPSec.
Remarque : ces exemples n'ont
pour but que de montrer les possibilités
d'encapsulation et l'intérêt de cette technique.
La liste n'est bien sûr pas exhaustive. De plus,
rappelons tout de même que l'utilisation d'IPSec
est habituellement à l'opposé de ce qui a été
montré ici : IPSec est normalement le protocole
effectuant l'encapsulation et non l'inverse;
IPSec est le plus souvent utilisé entre
passerelles et non l'inverse. Voir la fiche sur
IPSec
pour plus de détails.
Conclusion
Bien que complexe, le concept de
tunneling et d'encapsulation peut se révéler très
utile pour traverser certains équipements réseau
de façon transparente, et permettre une
connectivité accrue. Néanmoins, il ne faut pas
oublier que le fait de sauter un firewall annule
purement et simplement la protection que celui-ci
procure et peut-même compromettre le réseau privé
tout entier, exactement comme une personne
utilisant un modem sur son ordinateur
professionnel alors que celui-ci est connecté au
réseau de l'entreprise...
Le principe
d'encapsulation a d'autre part été démocratisé et
étendu à d'autres applications; on trouve
maintenant des outils de tunneling basés sur HTTP
ou UDP (flux DNS) qui permettent aisément de
traverser des firewalls.
| |
| |
