Protocole de tunnellisation de couche 2

Dans les réseaux informatiques , le protocole L2TP ( Layer 2 Tunneling Protocol ) est un protocole de tunneling utilisé pour prendre en charge les réseaux privés virtuels (VPN) ou dans le cadre de la fourniture de services par les FAI. Il utilise le chiffrement (« masquage ») uniquement pour ses propres messages de contrôle (en utilisant un secret pré-partagé facultatif) et ne fournit aucun chiffrement ni confidentialité du contenu par lui-même. Au lieu de cela, il fournit un tunnel pour la couche 2 (qui peut être chiffré), et le tunnel lui-même peut être transmis via un protocole de chiffrement de couche 3 tel que IPsec .

Publié en août 1999 sous la forme d'une proposition de norme RFC 2661, L2TP trouve ses origines principalement dans deux anciens protocoles de tunneling pour la communication point à point : le protocole de transfert de couche 2 (L2F) de Cisco et le protocole de tunneling point à point (PPTP) de Microsoft . Une nouvelle version de ce protocole, L2TPv3 , est apparue sous la forme d'une proposition de norme RFC 3931 en 2005. L2TPv3 offre des fonctionnalités de sécurité supplémentaires, une encapsulation améliorée et la possibilité de transporter des liaisons de données autres que le simple protocole point à point (PPP) sur un réseau IP (par exemple : Frame Relay , Ethernet , ATM , etc.).

L'intégralité du paquet L2TP, y compris la charge utile et l'en-tête L2TP, est envoyée dans un datagramme UDP ( User Datagram Protocol ). L'un des avantages de la transmission via UDP (plutôt que TCP) est qu'elle évite le problème de fusion TCP . Il est courant de transporter des sessions PPP dans un tunnel L2TP. L2TP n'assure pas à lui seul la confidentialité ou l'authentification forte. IPsec est souvent utilisé pour sécuriser les paquets L2TP en fournissant la confidentialité, l'authentification et l'intégrité. La combinaison de ces deux protocoles est généralement connue sous le nom de L2TP/IPsec (discuté ci-dessous).

Les deux points d'extrémité d'un tunnel L2TP sont appelés concentrateur d'accès L2TP (LAC) et serveur réseau L2TP (LNS). Le LNS attend de nouveaux tunnels. Une fois qu'un tunnel est établi, le trafic réseau entre les homologues est bidirectionnel. Pour être utiles à la mise en réseau, les protocoles de niveau supérieur sont ensuite exécutés via le tunnel L2TP. Pour faciliter cela, une session L2TP est établie dans le tunnel pour chaque protocole de niveau supérieur tel que PPP. Le LAC ou le LNS peuvent initier des sessions. Le trafic de chaque session est isolé par L2TP, il est donc possible de configurer plusieurs réseaux virtuels sur un seul tunnel.

Les paquets échangés dans un tunnel L2TP sont classés en paquets de contrôle ou en paquets de données . L2TP offre des fonctionnalités de fiabilité pour les paquets de contrôle, mais aucune fiabilité pour les paquets de données. La fiabilité, si elle est souhaitée, doit être fournie par les protocoles imbriqués exécutés dans chaque session du tunnel L2TP.

L2TP permet la création d'un réseau privé virtuel d'accès à distance (VPDN) pour connecter un client distant à son réseau d'entreprise en utilisant une infrastructure partagée, qui peut être Internet ou le réseau d'un fournisseur de services.

Un tunnel L2TP peut s'étendre sur l'ensemble d'une session PPP ou seulement sur un segment d'une session à deux segments. Cela peut être représenté par quatre modèles de tunneling différents, à savoir :

• tunnel volontaire
• tunnel obligatoire — appel entrant
• tunnel obligatoire — numérotation à distance
• Connexion multi-sauts L2TP

Un paquet L2TP se compose de :

Signification des champs :

Drapeaux et version

indicateurs de contrôle indiquant le paquet de données/contrôle et la présence de champs de longueur, de séquence et de décalage.

Longueur (optionnel)

Longueur totale du message en octets, présente uniquement lorsque l'indicateur de longueur est défini.

ID du tunnel

Indique l'identifiant de la connexion de contrôle.

ID de session

Indique l'identifiant d'une session dans un tunnel.

Ns (facultatif)

Numéro de séquence pour ce message de données ou de contrôle, commençant à zéro et incrémenté de un (modulo 2 ¹⁶ ) pour chaque message envoyé. Présent uniquement lorsque l'indicateur de séquence est défini.

Nr (facultatif)

Numéro de séquence du message attendu à recevoir. Nr est défini sur le N du dernier message reçu dans l'ordre plus un (modulo 2 ¹⁶ ). Dans les messages de données, Nr est réservé et, s'il est présent (comme indiqué par le bit S), DOIT être ignoré à la réception.

Taille du décalage (facultatif)

Spécifie l'emplacement des données de charge utile au-delà de l'en-tête L2TP. Si le champ de décalage est présent, l'en-tête L2TP se termine après le dernier octet du remplissage de décalage. Ce champ existe si l'indicateur de décalage est défini.

Tampon décalé (en option)

Longueur variable, telle que spécifiée par la taille du décalage. Le contenu de ce champ n'est pas défini.

Données de charge utile

Longueur variable (taille maximale de la charge utile = taille maximale du paquet UDP − taille de l'en-tête L2TP)

Au moment de la configuration de la connexion L2TP, de nombreux paquets de contrôle sont échangés entre le serveur et le client pour établir un tunnel et une session pour chaque direction. Un homologue demande à l'autre homologue d'attribuer un tunnel et un identifiant de session spécifiques via ces paquets de contrôle. Ensuite, en utilisant ce tunnel et cet identifiant de session, des paquets de données sont échangés avec les trames PPP compressées comme charge utile.

La liste des messages de contrôle L2TP échangés entre LAC et LNS, pour l'établissement d'un protocole de communication avant l'établissement d'un tunnel et d'une session dans la méthode de tunneling volontaire est

En raison du manque de confidentialité inhérent au protocole L2TP, il est souvent mis en œuvre avec IPsec . Ce protocole est appelé L2TP/IPsec et est normalisé dans la RFC 3193 de l'IETF. Le processus de configuration d'un VPN L2TP/IPsec est le suivant :

1. Négociation d' association de sécurité IPsec (SA), généralement via l'échange de clés Internet (IKE). Cette opération s'effectue via le port UDP 500 et utilise généralement un mot de passe partagé (appelé « clés pré-partagées »), des clés publiques ou des certificats X.509 aux deux extrémités, bien qu'il existe d'autres méthodes de chiffrement.
2. Établissement d' une communication ESP ( Encapsulating Security Payload ) en mode transport. Le numéro de protocole IP pour ESP est 50 (comparez le 6 de TCP et le 17 d'UDP). À ce stade, un canal sécurisé a été établi, mais aucun tunnelage n'a lieu.
3. Négociation et établissement d'un tunnel L2TP entre les points de terminaison de l'association de sécurité. La négociation proprement dite des paramètres s'effectue via le canal sécurisé de l'association de sécurité, au sein du cryptage IPsec. L2TP utilise le port UDP 1701.

Une fois le processus terminé, les paquets L2TP entre les points de terminaison sont encapsulés par IPsec. Étant donné que le paquet L2TP lui-même est encapsulé et masqué dans le paquet IPsec, l'adresse IP source et de destination d'origine est chiffrée dans le paquet. De plus, il n'est pas nécessaire d'ouvrir le port UDP 1701 sur les pare-feu entre les points de terminaison, car les paquets internes ne sont pas traités tant que les données IPsec n'ont pas été déchiffrées et supprimées, ce qui n'a lieu qu'aux points de terminaison.

L'utilisation des termes tunnel et canal sécurisé peut prêter à confusion dans L2TP/IPsec . Le terme « mode tunnel » fait référence à un canal qui permet aux paquets intacts d'un réseau d'être transportés sur un autre réseau. Dans le cas de L2TP/PPP, il permet aux paquets L2TP/PPP d'être transportés sur IP. Un canal sécurisé fait référence à une connexion au sein de laquelle la confidentialité de toutes les données est garantie. Dans L2TP/IPsec, IPsec fournit d'abord un canal sécurisé, puis L2TP fournit un tunnel. IPsec spécifie également un protocole de tunnel : celui-ci n'est pas utilisé lorsqu'un tunnel L2TP est utilisé.

Windows propose un support natif (configurable dans le panneau de configuration) pour L2TP depuis Windows 2000. Windows Vista a ajouté 2 outils alternatifs, un composant logiciel enfichable MMC appelé « Pare-feu Windows avec sécurité avancée » (WFwAS) et l'outil de ligne de commande « netsh advfirewall ». Une limitation des commandes WFwAS et netsh est que les serveurs doivent être spécifiés par adresse IP. Windows 10 a ajouté les commandes PowerShell « Add-VpnConnection » et « Set-VpnConnectionIPsecConfiguration » . Une clé de registre doit être créée sur le client et le serveur si le serveur se trouve derrière un périphérique NAT-T. [1]

L2TP est souvent utilisé par les FAI lorsque des services Internet par exemple ADSL ou câble sont revendus . Depuis l'utilisateur final, les paquets circulent sur le réseau d'un fournisseur de services réseau de gros jusqu'à un serveur appelé Broadband Remote Access Server ( BRAS ), un convertisseur de protocole et un routeur combinés. Sur les réseaux traditionnels, le chemin entre l'équipement des locaux du client final et le BRAS peut passer par un réseau ATM . À partir de là, sur un réseau IP, un tunnel L2TP relie le BRAS (agissant comme LAC) à un LNS qui est un routeur périphérique à la limite du réseau IP du FAI de destination final.

• RFC 2341 Cisco Layer Two Forwarding (Protocole) « L2F » (un prédécesseur de L2TP)
• RFC 2637 Protocole de tunneling point à point (PPTP)
• RFC 2661 Protocole de tunneling de couche 2 « L2TP »
• RFC 2809 Implémentation du tunneling obligatoire L2TP via RADIUS
• RFC 2888 Accès à distance sécurisé avec L2TP
• RFC 3070 Protocole de tunneling de couche 2 (L2TP) sur Frame Relay
• Informations sur les causes de déconnexion L2TP RFC 3145
• RFC 3193 Sécurisation de L2TP à l'aide d'IPsec
• RFC 3301 Protocole de tunneling de couche 2 (L2TP) : réseau d'accès ATM
• RFC 3308 Protocole de tunneling de couche 2 (L2TP) Services différenciés
• RFC 3355 Protocole de tunneling de couche 2 (L2TP) sur couche d'adaptation ATM 5 (AAL5)
• Base d'informations de gestion du protocole de tunneling de couche 2 « L2TP » RFC 3371
• RFC 3437 Extensions du protocole de tunneling de couche 2 pour la négociation du protocole de contrôle de liaison PPP
• RFC 3438 Protocole de tunneling de couche 2 (L2TP) Numéros attribués par Internet : Mise à jour des considérations de l'IANA (Internet Assigned Numbers Authority)
• RFC 3573 Signalisation de l'état de modem en attente dans le protocole de tunneling de couche 2 (L2TP)
• RFC 3817 Protocole de tunneling de couche 2 (L2TP) Relais de découverte actif pour PPP sur Ethernet (PPPoE)
• RFC 3931 Protocole de tunneling de couche 2 - Version 3 ( L2TPv3 )
• Extensions RFC 4045 pour prendre en charge le transport efficace du trafic multidiffusion dans le protocole de tunneling de couche 2 (L2TP)
• Extensions de basculement RFC 4951 pour le « basculement » du protocole de tunneling de couche 2 (L2TP)