Présentation du L2TP pour l’accès abonné

Le protocole de tunnelisation de couche 2 (L2TP) est un protocole client-serveur qui permet au protocole PPP (Point-to-Point Protocol) d’être tunnelisé sur un réseau. La couche L2TP encapsule des paquets de couche 2, par exemple PPP, pour les transmettre sur un réseau. Un concentrateur d’accès L2TP (LAC), configuré sur un dispositif 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. Le LNS fonctionne comme le point d’arrêt logique de la session PPP tunnelisée par le LAC à partir du client distant. La figure 1 illustre une topologie L2TP simple.

La couche L2TP sépare la terminaison des technologies d’accès, telles que le câble ou xDSL, de la terminaison du PPP et de l’accès ultérieur à un réseau. Cette séparation permet aux FSI publics d’externaliser leurs technologies d’accès à des entreprises de services locaux (ESLC) concurrentes. L2TP fournit aux FAI la capacité de fournir un service VPN ; Les entreprises privées peuvent réduire ou éviter d’investir dans des technologies d’accès pour les travailleurs à distance.

Vous pouvez configurer votre routeur pour qu’il agisse en tant que LAC en mode PPP pass-through dans lequel le LAC reçoit les paquets d’un client distant, puis les transmet au niveau de la couche 2 directement au LNS. La session PPP est terminée sur le LNS. Cette implémentation LAC prend uniquement en charge les abonnés PPPoE (Point-to-Point Protocol over Ethernet) sur des interfaces logiques dynamiques ou statiques. La figure 2 montre l’empilement de la couche de protocole pour une connexion pass-through L2TP.

Remarque :

Sur les routeurs MX Series, les fonctions LAC et LNS sont prises en charge uniquement sur les MPC ; ils ne sont pris en charge sur aucun PIC de services ou MS-DPC. Pour plus de détails sur la prise en charge MPC de L2TP, voir la référence des modules d’interface MX Series

Certains routeurs M Series prennent en charge les fonctions LNS sur les PIC de services. Pour plus d’informations sur l’implémentation L2TP sur les routeurs M Series, consultez Présentation de la configuration des services L2TP.

Le LAC crée dynamiquement des tunnels sur la base de paramètres d’authentification AAA et transmet les paquets L2TP au LNS au moyen du protocole IP/User Datagram Protocol (UDP). Le trafic circule dans un L2TP session; un tunnel est une agrégation d’une ou plusieurs sessions. Vous pouvez également provisionner un mappage de domaine utilisé par AAA pour déterminer s’il faut tunnel ou résilier le abonné PPPoE sur le LAC. Un mappage un-à-un existe entre chaque abonné PPP tunnelisé vers le LNS et une session L2TP.

Lorsque le LNS est un routeur MX Series, une interface homologue LAC sur un MPC fournit une adresse IP pour l’échange de paquets IP entre les points de terminaison du tunnel ; le moteur de routage assure la maintenance des tunnels L2TP. Le moteur de transfert de paquets héberge une ou plusieurs interfaces de services en ligne (si). Ces interfaces fonctionnent comme une interface physique virtuelle et ancrent les sessions L2TP sur le LNS. L’interface si permet d’activer des services L2TP sans nécessiter de PIC de services spécial. Enfin, une autre interface est utilisée pour transmettre les données des abonnés vers et depuis Internet.

Les caractéristiques du tunnel peuvent provenir soit d’un profil de tunnel que vous configurez, soit d’attributs de tunnel RADIUS et d’attributs spécifiques au fournisseur (VSA) du serveur AAA accessible au niveau du lac des accès. Vous pouvez inclure un profil de tunnel dans une carte de domaine, qui applique le profil de tunnel avant que l’authentification RADIUS n’ait lieu. Vous pouvez utiliser les attributs standard RADIUS et les VSA pour remplacer tout ou partie des caractéristiques configurées par le profil de tunnel dans une carte de domaine. RADIUS peut également appliquer lui-même un profil de tunnel lorsque le VSA du groupe de tunnels RADIUS [26-64] est spécifié dans la connexion RADIUS.

Remarque :

L2TP n’est pas pris en charge sur les tunnels GRE.

Le VSA de routeur virtuel [26-1] dans le profil de l’abonné sur le serveur AAA du fournisseur de services (accessible depuis le LNS) détermine l’instance de routage dans laquelle la session L2TP est activée sur le LNS. Lorsque ce VSA n’est pas présent, la session d’abonné est établie dans la même instance de routage que le tunnel, car le serveur AAA n’est accessible qu’à partir de l’instance de routage dans laquelle le tunnel se termine sur le LNS.

Ce comportement est différent de celui des abonnés DHCP et PPPoE non tunnelisés, qui apparaissent dans l’instance de routage par défaut en l’absence du VSA de routeur virtuel. Pour les abonnés L2TP, vous devez inclure ce VSA dans le profil de l’abonné lorsque vous souhaitez que la session de l’abonné apparaisse dans une instance de routage différente de l’instance de routage de tunnel.

À partir de la version 17.4R1 de Junos OS, le LNS inclut les attributs RADIUS suivants lorsqu’il envoie un message de demande d’accès au serveur RADIUS :

• Type de tunnel (64)

• Tunnel de type moyen (65)

• point de terminaison tunnel-client (66)

• point de terminaison tunnel-serveur (67)

• Connexion-tunnel-débit (68)

• ID d’affectation de tunnel (82)

• Tunnel-client-auth-id (90)

• Identifiant d’authentification du serveur de tunnel (91)

Dans les versions antérieures, le LNS inclut ces attributs uniquement dans les enregistrements comptables qu’il envoie au serveur RADIUS. Dans les messages Access-Request, ils peuvent être utilisés pour corréler sur le serveur RADIUS la session du LAC au LNS.

Le LAC prend en charge la mise en miroir initiée par RADIUS, qui crée des stratégies sécurisées basées sur certaines VSA RADIUS, et utilise les attributs RADIUS pour identifier un abonné dont le trafic doit être mis en miroir. (Cette fonctionnalité n’est pas prise en charge pour un LNS configuré sur un routeur MX Series.)

Le LAC et le LNS prennent en charge l’ISSU unifiée. Lorsqu’une mise à niveau est lancée, le LAC termine toutes les négociations L2TP en cours, mais rejette toute nouvelle négociation jusqu’à ce que la mise à niveau soit terminée. Aucun nouveau tunnel ou session n’est établi pendant la mise à niveau. Les déconnexions des abonnés sont enregistrées pendant la mise à niveau et sont terminées une fois la mise à niveau terminée.

Le Tableau 1 décrit les termes de base du L2TP.

Tableau 1 : Conditions L2TP

Durée	Descriptif
AVP	Paire de valeurs d’attribut (AVP) : combinaison d’un attribut unique, représenté par un entier, et d’une valeur contenant la valeur réelle identifiée par l’attribut.
Appel	Connexion (ou tentative de connexion) entre un système distant et le LAC.
BAC	Concentrateur d’accès L2TP (LAC) : nœud qui agit comme un côté d’un point de terminaison de tunnel L2TP et qui est un homologue du LNS. Le LAC se trouve entre un LNS et un système distant et transmet les paquets vers et depuis chacun.
LNS	Serveur réseau L2TP (LNS) : nœud qui agit comme un côté d’un point de terminaison de tunnel L2TP et qui est un homologue du LAC. Le LNS est le point de terminaison logique d’une connexion PPP qui est tunnelisée à partir du système distant par le LAC.
Pair	Dans le contexte L2TP, le LAC ou le LNS. L’homologue de la LAC est un LNS, et vice versa.
Authentification par proxy	Pré-authentification PPP effectuée par le LAC pour le compte du LNS. Les données de proxy sont envoyées par le LAC au LNS et contiennent des attributs tels que le type d’authentification, le nom de l’authentification et la demande d’authentification. Le LNS répond avec les résultats de l’authentification.
Proxy LCP	Négociation du protocole LCP (Link Control Protocol) effectuée par le LAC pour le compte du LNS. Le proxy est envoyé par le LAC au LNS contenant des attributs tels que les derniers attributs de configuration envoyés et reçus du client.
Système à distance	Système d’extrémité ou routeur connecté à un réseau d’accès distant, qui est soit l’initiateur, soit le destinataire d’un appel.
Séance	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. Remarque : Il existe une relation un-à-un entre les sessions L2TP établies et leurs connexions PPP associées.
Tunnel	Connexion entre la paire LAC-LNS composée d’une connexion de contrôle et d’au moins 0 session L2TP.

Le L2TP est mis en œuvre à quatre niveaux :

• Source : le routeur local faisant office de LAC.

• Destination : le routeur distant faisant office de LNS.

• Tunnel : chemin direct entre le LAC et le LNS.

• Session : connexion PPP dans un tunnel.

Lorsque le routeur a établi des destinations, des tunnels et des sessions, vous pouvez contrôler le trafic L2TP. La modification d’une destination affecte tous les tunnels et sessions vers cette destination ; La modification d’un tunnel affecte toutes les sessions dans ce tunnel. Par exemple, la fermeture d’une destination entraîne la fermeture de tous les tunnels et sessions vers cette destination.

• Séquence des événements sur le LAC
• Séquence des événements sur le LNS

Les homologues L2TP maintiennent une file d’attente de messages de contrôle qui doivent être envoyés à l’appareil homologue. Une fois que l’homologue local (LAC ou LNS) a envoyé un message, il attend une réponse de l’homologue distant. Si aucune réponse n’est reçue, l’homologue local retransmet le message. Ce comportement donne à l’homologue distant plus de temps pour répondre au message.

Vous pouvez contrôler le comportement de retransmission des deux manières suivantes :

• Nombre de retransmissions : vous pouvez configurer le nombre de fois qu’un message sans accusé de réception est retransmis par l’homologue local. Plus le nombre augmente, plus l’homologue distant a d’occasions de répondre, mais plus le trafic de contrôle augmente. Pour les tunnels qui ont été établis, incluez l’instruction retransmission-count-established au niveau de la [edit services l2tp tunnel] hiérarchie. Pour les tunnels qui ne sont pas encore établis, incluez l’instruction retransmission-count-not-established .

• Intervalle de retransmission : vous pouvez configurer la durée pendant laquelle l’homologue local attend la première réponse à un message de contrôle. Si une réponse n’est pas reçue dans le premier intervalle de délai, le minuteur de retransmission double l’intervalle entre chaque retransmission successive jusqu’à un maximum de 16 secondes. L’augmentation de l’intervalle donne à l’homologue distant plus de temps pour répondre, mais dépense également plus de ressources sur un homologue potentiellement indisponible. Incluez l’instruction minimum-retransmission-interval au niveau de la [edit services l2tp tunnel] hiérarchie.

L’homologue local continue de retransmettre le message de contrôle jusqu’à ce que l’une des situations suivantes se produise :

• Une réponse est reçue dans le délai d’attente actuel.

• Le nombre maximal de retransmissions est atteint.

Si le nombre maximal est atteint et qu’aucune réponse n’a été reçue, le tunnel et toutes ses sessions sont effacés.

Remarque :

Atteindre l’intervalle maximal de 16 secondes n’arrête pas les retransmissions. L’homologue local continue d’attendre 16 secondes après chaque retransmission suivante.

Les exemples suivants décrivent le comportement de retransmission dans différentes circonstances :

• Exemple 1 : le nombre de retransmissions est de trois et l’intervalle de retransmission minimal est de 1 seconde.

  1. L’homologue local envoie un message de contrôle.

  2. L’homologue local attend 1 seconde, mais ne reçoit aucune réponse.

  3. L’homologue local retransmet le message de contrôle. Il s’agit de la première retransmission.

  4. L’homologue local attend 2 secondes, mais reçoit une réponse avant l’expiration de l’intervalle.

  5. La retransmission s’arrête parce qu’une réponse est reçue dans l’intervalle.

• Exemple 2 : le nombre de retransmissions est de deux et l’intervalle de retransmission minimal est de 8 secondes.

  1. L’homologue local envoie un message de contrôle.

  2. L’homologue local attend 8 secondes, mais ne reçoit aucune réponse.

  3. L’homologue local retransmet le message de contrôle. Il s’agit de la première retransmission.

  4. L’homologue local attend 16 secondes, mais ne reçoit aucune réponse.

  5. L’homologue local retransmet le message de contrôle. Il s’agit de la deuxième retransmission.

  6. L’homologue local attend à nouveau 16 secondes, car l’intervalle ne peut pas augmenter au-delà de 16, mais ne reçoit aucune réponse.

  7. La retransmission s’arrête parce que le nombre maximum de retransmissions était de deux a été atteint.

  8. Le tunnel et toutes ses sessions sont nettoyés.

• Objet
• Mesures à prendre