Présentation de la tunnelisation L2TP basée sur des filtres de pare-feu dans les réseaux IPv4

Le protocole L2TP (Layer 2 Tunneling Protocol) est un protocole client-serveur qui permet au protocole PPP (Point-to-Point Protocol) d’être tunnelisé à travers un réseau. L2TP encapsule des paquets de couche 2, tels que PPP, pour les transmettre sur un réseau. Un concentrateur d’accès L2TP (LAC), configuré sur un périphérique d’accès, reçoit les paquets d’un client distant et les transmet à un serveur réseau L2TP (LNS) sur un réseau distant. L2TPv3 définit le protocole de contrôle de base et l’encapsulation pour la tunnelisation de plusieurs connexions de couche 2 entre deux nuds IPv6. Les différences significatives entre L2TPv2 et L2TPv3 sont les suivantes :

• Séparation de tous les AVP et références liés à PPP, ce qui permet d’inclure une partie de l’en-tête de données L2TP qui était spécifique aux besoins de PPP.

• Passez d’un ID de session et d’un ID de tunnel 16 bits à un ID de session et un ID de connexion de contrôle 32 bits respectivement.

• Extension du mécanisme d’authentification du tunnel pour couvrir l’intégralité du message de contrôle plutôt qu’une partie de certains messages.

• L2TPv3 est pris en charge pour IPv6 uniquement.

• Pour les filtres de pare-feu, seule l’encapsulation/décapsulation L2TPv3 du plan de données est prise en charge.

L2TP est composé de deux types de messages, les messages de contrôle et les messages de données (parfois appelés paquets de contrôle et paquets de données). Les messages de contrôle sont utilisés pour établir, maintenir et effacer les connexions et les sessions de contrôle. Ces messages utilisent un canal de contrôle fiable au sein de L2TP pour garantir la livraison. Les messages de données sont utilisés pour encapsuler le trafic L2 transporté sur la session L2TP.

Vous pouvez configurer un réseau IPv4 pour transporter le trafic de transit IPv4, IPv6 ou MPLS à l’aide des mécanismes de protocole de tunnelisation GRE initiés par deux actions de filtre de pare-feu standard. Cette fonctionnalité est également prise en charge dans les systèmes logiques. Lorsque vous configurez la tunnelisation L2TP avec des filtres de pare-feu, vous n’avez pas besoin de créer d’interfaces de tunnel sur les cartes d’interface physique (PIC) des services de tunnel ou sur les concentrateurs de ports modulaires (MPC) MPC3E. Au lieu de cela, les moteurs de transfert de paquets fournissent des services de tunnel vers des interfaces logiques Ethernet ou des interfaces Ethernet agrégées hébergées sur des cartes d’interface modulaires (MIC) ou MPC dans les plates-formes de routage universelles 5G MX Series.

Deux routeurs MX Series installés en tant que routeurs PE fournissent une connectivité aux routeurs CE (Provider Edge) sur deux réseaux disjoints. Les interfaces MIC ou MPC sur les routeurs PE assurent l’encapsulation IPv4 L2TP et la désencapsulation des charges utiles. Après décapsulation, les paquets sont envoyés à l’interface locale d’une table de routage spécifiée dans l’action, ou à la table de routage par défaut, en fonction du champ de protocole de l’en-tête L2TP. Toutefois, un paquet L2TP peut éventuellement être envoyé à travers la structure avec un jeton égal à un index d’interface de sortie pour effectuer une connexion croisée de couche 2. Vous pouvez spécifier le spécificateur d’interface de sortie à utiliser pour le paquet L2TP à envoyer en incluant l’instruction decapsulate l2tp output-interface interface-name cookie l2tpv3-cookie au niveau de la [edit firewall family family-name filter filter-name term term-name then] hiérarchie.

Lors de la décapsulation, l’en-tête interne doit être Ethernet pour les tunnels L2TP. Par défaut, la classe de transfert est appliquée avant le pare-feu et n’est pas conservée pour le paquet décapsulé (à l’aide de l’instruction forwarding-class class-name au niveau de la [edit firewall family family-name] hiérarchie, qui est une action de filtrage non terminante). Toutefois, vous pouvez spécifier la classe de transfert pour laquelle le paquet doit être classé en incluant l’action de filtre pour un paquet décapsulé à l’aide de l’instruction decapsulate l2tp forwarding-class class-name au niveau de la [edit firewall family family-name filter filter-name term term-name then] hiérarchie.

Les définitions de champ suivantes sont définies pour être utilisées dans toutes les encapsulations d’en-tête de session L2TP.

• Le champ ID de session est un champ de 32 bits contenant un identificateur différent de zéro pour une session. Les sessions L2TP sont nommées à l’aide d’identificateurs qui n’ont qu’une signification locale. La même session logique se verra attribuer des ID de session différents à chaque extrémité de la connexion de contrôle pendant toute la durée de vie de la session. Lorsque la connexion de contrôle L2TP est utilisée pour l’établissement d’une session, les ID de session sont sélectionnés et échangés en tant qu’ID de session local AVP lors de la création d’une session. Seul l’ID de session fournit le contexte nécessaire à tout traitement ultérieur des paquets, y compris la présence, la taille et la valeur du cookie, le type de sous-couche spécifique L2 et le type de charge utile tunnelisée.

• Le champ facultatif Cookie contient une valeur de longueur variable (maximum 64 bits) utilisée pour vérifier l’association d’un message de données reçu avec la session identifiée par l’ID de session. Le champ Cookie doit être défini sur la valeur aléatoire configurée ou signalée pour cette session. Le cookie fournit un niveau supplémentaire de garantie qu’un message de données a été dirigé vers la bonne session par l’ID de session. Un cookie bien choisi peut empêcher l’acheminement par inadvertance de paquets aléatoires avec des ID de session récemment réutilisés ou pour des ID de session sujets à la corruption de paquets. Le cookie peut également fournir une protection contre certaines attaques d’insertion de paquets malveillantes spécifiques. Lorsque la connexion de contrôle L2TP est utilisée pour l’établissement d’une session, des valeurs de cookie aléatoires sont sélectionnées et échangées en tant qu’AVP de cookie affecté lors de la création de la session.

Une session est une connexion logique créée entre le LAC et le LNS lorsqu’une connexion PPP de bout en bout est établie entre un système distant et le LNS. Il existe une relation biunivoque entre les sessions L2TP établies et les connexions PPP qui leur sont associées. Un tunnel est une agrégation d’une ou plusieurs sessions L2TP.

À partir de Junos OS version 15.1, la décapsulation des paquets IP envoyés via un tunnel L2TP avec des conditions de correspondance de filtre de pare-feu standard et des actions spécifiées est effectuée à l’aide d’une recherche de couche 3. Dans Junos OS version 14.2 et antérieure, la décapsulation du trafic sur un tunnel L2TP avec des actions de filtre de pare-feu configurées est effectuée à l’aide des propriétés d’interface de couche 2.