Le tunneling

L'art de créer des tunnels dans les réseaux informatiques

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éfèrera 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 paraître, 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 fonctionnalité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écanismes 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.

Quelques outils pour aller plus loin

Stunnel est un outil de tunneling par proxy. Toujours développé en 2017, il vous permettra d'expérimenter la création de tunnels cryptés par TLS.
Un autre outil très similaire à Stunnel se nomme "Tunna".

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.

SoGoodToBe
02 Septembre 2002