Au début de cette partie sur la couche 2, nous avons évoqué le fait qu’un protocole de liaison de données peut servir même lorsqu’il n’y a qu’une source et une destination possibles. Nous allons en premier lieu étudier l’un de ces protocoles dans un cas simple, que nous complexifierons de plus en plus. 
Tout vient à point...
Vous avez déjà entendu parler de l’ADSL ? C’est une technologie très utilisée notamment pour l’accès à Internet chez les particuliers. Physiquement, une paire de fils de cuivre va de chez l’abonné aux équipements de l’opérateur. Pas de switch, pas de routeur entre l’abonné et l’opérateur : c’est une liaison directe.
On peut envoyer directement des paquets IP, alors ?
Eh bien… non. Un des problèmes qui va se poser, c’est l’authentification de l’utilisateur. L’opérateur pourrait techniquement l’identifier par la ligne, mais comment être sûr que c’est bien lui et non une personne malveillante qui tente d’utiliser cette ligne incognito ?
Pour cela, on peut avoir recours à PPP : Point-to-Point Protocol (protocole point-à-point). Ce protocole de liaison de données sert à établir un lien de niveau 2 entre deux entités, et surtout, permet l’authentification. Ainsi, dans le cas de notre ligne ADSL, on va pouvoir s’assurer qu’un méchant pirate n’essaie pas de détourner une ligne de cuivre pour commettre des malversations. 
Ces termes vous semblent compliqués ? Par ici pour une petite explication !
Théoriquement, PPP peut être utilisé sans authentification. En pratique, ce cas est rare et peu utile.
Deux méthodes d’authentification sont supportées par PPP : elles s’appellent PAP et CHAP. Ce protocole fonctionne selon une architecture client-serveur. C’est toujours le client qui initie la connexion et qui choisit son mode d’authentification. Si c’est PAP, c’est très facile : les identifiants sont directement envoyés en clair au serveur dès le départ ! Ce dernier répond qu’ils sont valides ou non, et la session est établie ou non. Simple et efficace, et absolument pas sécurisé ! 
Une personne qui peut voir ce qui se passe sur la ligne récupérerait sans difficulté les mots de passe. Pour éviter cela, mieux vaut utiliser CHAP.
Dans ce dernier cas, cela fonctionne différemment. Le client fait une demande de connexion. Le serveur lui renvoie un challenge. Il contient un numéro d’identification, un nombre aléatoire ainsi que le nom du serveur. Pour relever ce défi, le client doit renvoyer le même numéro d’identification, son nom d’utilisateur ainsi qu’un hash1. Ce hash, ce n’est pas une substance qui se fume et qui est très mauvaise pour la santé ! C’est une valeur basée sur le numéro d’identification, le nombre aléatoire et le mot de passe de l’utilisateur. Pour plus de détails sur ce procédé, nous vous invitons à consulter ce document du constructeur Cisco. C’est en anglais et ça parle surtout de configuration de routeurs, mais les schémas sont plutôt clairs.
Tout cela est transmis au serveur. Le hash assure la confidentialité du mot de passe sur le réseau. Le serveur peut faire le même calcul de son côté, puisqu’il connait d’une manière ou d’une autre le mot de passe associé au nom d’utilisateur. Ainsi, il vérifie si le challenge est réussi : si tel est le cas, bravo ! Le client est récompensé par une connexion PPP établie ! 
PPP est donc bien utile pour fournir de l’authentification sur un lien direct. Mais bien souvent, le support physique ne permet pas de transmettre directement des trames PPP. C’est là que ça se complexifie. 
- Le hashage est une sorte de chiffrement à sens unique. On ne peut pas retrouver une valeur d’origine qui a été hashée, mais la même fonction de hashage donne toujours le même résultat pour une même valeur.↩
... à qui sait encapsuler
Sur les lignes ADSL, un protocole qu’il est fréquent de rencontrer est ATM. Avec lui, chaque envoi de données se fait dans des cellules, qui sont des "mini-trames" de taille fixe (53 octets). Chaque cellule comporte un en-tête qui permet de définir des chemins virtuels et des circuits virtuels. Nous ne nous étendrons pas sur ces notions ici, sachez simplement que c’est ce qui permet de différencier ce qui relève du téléphone, de la télévision et d’Internet dans les offres dites "triple play".
Pour des raisons d’ordre électronique que nous ne développerons pas pour le moment, il n’est pas possible de faire transiter directement du PPP sur de l’ADSL. On peut en revanche utiliser le protocole ATM. Comment faire alors pour bénéficier des services de PPP sur une ligne ADSL ? Eh bien… en encapsulant PPP dans ATM.
Tout comme TCP peut s’encapsuler dans IP, comme IP peut s’encapsuler dans Ethernet, certains protocoles de niveau 2 peuvent s’encapsuler entre eux. Dans le cas que nous avons évoqué, on parle de PPP over ATM (PPPoA). De la même manière, on peut encapsuler PPP dans Ethernet, ce qu’on appelle PPPoE. Ethernet pouvant à son tour être encapsulé dans ATM, on peut même faire du PPPoEoA !
Ce genre d’encapsulation crée plusieurs interfaces sur votre système. Si vous établissez une liaison PPP entre deux hôtes reliés en Ethernet, vous aurez une interface Ethernet et une interface PPP ! Chacune peut être paramétrée indépendamment, notamment en matière d’adressage.
Prenons un exemple : nos 2 hôtes Clémentine et Mandarine sont reliés en Ethernet et ont ouvert une connexion PPP. Elles disposent d’adresses IP configurées ainsi :
| - | Clémentine | Mandarine |
|---|---|---|
| PPP | 10.0.0.1/24 | 10.0.0.2/24 |
| Ethernet | 192.168.1.1/24 | 192.168.1.2/24 |
Pour communiquer, nos agrumes peuvent passer par 2 réseaux IP. Si Clémentine lance un ping 192.168.1.2,
que se passe-t-il ? Facile : ce réseau est directement connecté sur l’interface Ethernet. On aura le comportement suivant :
Et si Clémentine fait un ping 10.0.0.2 ? Ce réseau est directement connecté sur l’interface PPP… Mais celle-ci doit s’appuyer sur Ethernet ! Le programme ping n’en a pas conscience, il ne peut voir que l’interface PPP pour ce réseau. Le système d’exploitation se débrouille pour gérer cela. Sur le câble, voici ce qu’on va voir passer.
En pratique, quelle différence ? Dans le cas présent, ça ne change pas grand-chose. C’est surtout pour illustrer le rapport entre les interfaces. Là où ça se corse, c’est quand on veut faire de l’encapsulation au-delà du réseau strictement local.
Le bout du tunnel
Dans le cas précédent, nous avons vu qu’un programme ne peut avoir conscience, au mieux, que de l’interface réseau qu’il utilise. Il ne sait pas ce qu’il y a "en dessous". Alors, si l’interface utilisée fait un traitement particulier des données qui transitent par elles, personne ne se rendra compte de rien tant qu’elles sont restituées correctement à l’autre bout. Là où c’est particulièrement intéressant, c’est si on crée une connexion point-à-point dont l’interface chiffre toute communication qui passe dessus. C’est possible avec le protocole IPsec.
IPsec est en réalité un agglomérat de protocoles qui permet de chiffrer l’intégralité d’un paquet IP et de ses données utiles. C’est un système assez complexe qui mériterait à lui seul plusieurs chapitres. Si vous vous sentez d’attaque, vous pouvez consulter ce papier de FrameIP.
Au sec dans le tunnel
Reprenons notre exemple précédent et considérons maintenant qu’IPsec est appliqué à tout paquet qui passe par l’interface PPP. Voici ce qui se passe.
On a formé ce qu’on appelle un tunnel. C’est une sorte de tuyau opaque où on peut voir ce qu’il y rentre et ce qui en sort, mais pas ce qui passe dedans. L’interface PPP de Clémentine représente un bout du tunnel, l’interface PPP de Mandarine représente l’autre extrémité. Entre les deux, tout est chiffré, pas moyen de savoir ce qui se trame dedans !
Il y a deux possibilités au niveau des adresses IP qui seront visibles. Soit on conserve les source et destination d’origine, c’est moins confidentiel car elles ne sont alors pas chiffrées. Soit on les remplace par la source et la destination des entités qui traitent le chiffrement et le déchiffrement. Dans ce dernier cas, c’est l’intégralité du paquet d’origine, en-tête inclus, qui est encapsulé dans un nouveau paquet IPsec. Dans notre exemple, ça revient au même.
C’est pas mal, car un tel modèle empêche une éventuelle interception sur un réseau Ethernet. Les switchs indiscrets peuvent aller se rhabiller ! 
Mais que diriez-vous de pousser le concept encore plus loin et l’étendre entre hôtes distants, par exemple sur Internet ?
Pas possible avec PPP, c’est un protocole de niveau 2, ça reste restreint au réseau local !
On a bien encapsulé PPP dans Ethernet, alors pourquoi pas dans un protocole d’un autre niveau ? 
L’idée peut paraitre bizarre, mais il existe une solution : L2TP.
Vers Internet et au-delà
L2TP, pour Layer 2 Tunneling Protocol, ou protocole de tunnel de couche 2. Tout est dit, ou presque. Ce protocole permet d’encapsuler PPP dans UDP. On peut faire transiter sans souci des paquets UDP sur Internet, alors puisqu’on peut encapsuler PPP dans UDP grâce à L2TP, eh bien mélangeons tout cela ! Pour couronner le tout, on va maintenant séparer physiquement Clémentine et Mandarine à deux endroits d’Internet. La première aura l’adresse 1.1.1.1, la seconde, 2.2.2.2.
Ça commence à faire un beau mille-feuilles. Notez qu’au niveau IP inférieur, on reprend des adresses qui correspondent à des interfaces physiques. Cela devient nécessaire lorsqu’on veut fonctionner en dehors d’un réseau purement local : il faut que les routeurs sachent où orienter les paquets, et ils ne connaissent pas les adresses des interfaces PPP qu’on peut qualifier de virtuelles.
Ce qui est vu dans le câble à partir du niveau IP est ce qui sera vu par tous les intermédiaires. Ainsi, si pour une raison quelconque, les paquets ICMP sont bloqués sur le réseau, ils passeront quand même entre Clémentine et Mandarine s’ils passent par le tunnel ! Eh oui, tout ce qu’on voit sur le réseau, ce sont des datagrammes UDP ! 
Vous aurez peut-être remarqué que, depuis le début, on cherche à faire un ping entre 10.0.0.1 et 10.0.0.2. Ces hôtes sont théoriquement dans le même réseau IP. Et si vous vous souvenez bien, qui dit même plan d’adressage dit même réseau physique… Eh bien, avec L2TP, on a créé un réseau privé virtuel, un VPN. Les deux hôtes se voient comme voisins et comme faisant partie d’un même LAN, bien que ce ne soit physiquement pas le cas. Il existe d’autres moyens et d’autres protocoles pour établir des VPN : on peut citer la solution OpenVPN qui fonctionne différemment.
Nous avons abordé beaucoup de notions complexes tout en restant en surface. Cela peut être frustrant et nous en avons bien conscience. Notre objectif est de vous donner de bonnes bases, pas de faire de vous des experts. Chacun des termes évoqués dans ce chapitre mériterait qu’on y passe des heures, qu’on y consacre un livre entier. C’est pourquoi nous préférons vous renvoyer vers d’autres ressources si vous souhaitez en savoir davantage et aller plus en profondeur.
Nous allons commencer à lever le pied avec la couche 2 et toucher le fond de la pile de protocoles que nous offre le modèle OSI. Préparez-vous à découvrir un aspect des réseaux que vous n’avez probablement jamais vu !