Présentation de L2TP pour l’accès des abonnés
Présentation de L2TP pour l’accès des abonnés
Le protocole L2TP (Layer 2 Tunneling Protocol) est un protocole client-serveur qui permet de tunneliser le protocole PPP (Point-to-Point Protocol) sur 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. Le LNS fonctionne comme le point de terminaison logique de la session PPP tunnelisée par le LAC à partir du client distant. La figure 1 montre une topologie L2TP simple.
L2TP typique
Le L2TP sépare la terminaison des technologies d’accès, telles que le câble ou le xDSL, de la terminaison du PPP et de l’accès ultérieur à un réseau. Cette séparation permet aux FSI publics d’impartir leurs technologies d’accès à des entreprises de services locaux concurrentes (ESLC). L2TP offre aux FAI la possibilité de fournir un service VPN ; Les entreprises privées peuvent réduire ou éviter les investissements dans les 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 et les transmet ensuite 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 illustre l’empilement de la couche de protocole pour une connexion pass-through L2TP.
pass-through
Sur les routeurs MX Series, les fonctions LAC et LNS ne sont prises en charge que sur les MPC ; ils ne sont pris en charge sur aucun service PIC ou MS-DPC. Pour plus d’informations sur la prise en charge MPC pour L2TP, reportez-vous au Guide de référence des modules d’interface MX Series
Certains routeurs M Series prennent en charge les fonctions LNS sur les PIC de service. Pour plus d’informations sur l’implémentation L2TP sur les routeurs M Series, consultez Vue d’ensemble de la configuration des services L2TP.
Le LAC crée dynamiquement des tunnels basés sur des paramètres d’authentification AAA et transmet des 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 configurer une carte de domaine utilisée par AAA pour déterminer s’il faut tunneliser ou terminer l’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 gère les 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’utiliser des services L2TP sans nécessiter de PIC de services spéciaux. 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 LAC. Vous pouvez inclure un profil de tunnel dans une carte de domaine, qui applique le profil de tunnel avant l’authentification RADIUS. Vous pouvez utiliser des attributs standard RADIUS et des 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 groupe de tunnels RADIUS VSA [26-64] est spécifié dans la connexion RADIUS.
L2TP n’est pas pris en charge sur les tunnels GRE.
Le routeur virtuel VSA [26-1] dans le profil d’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 affichée sur le LNS. Lorsque ce VSA n’est pas présent, la session d’abonné apparaît 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 Virtual-Router. Pour les abonnés L2TP, vous devez inclure ce VSA dans le profil d’abonné lorsque vous souhaitez que la session d’abonné apparaisse dans une instance de routage différente de l’instance de routage de tunnel.
À partir de Junos OS version 17.4R1, 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-Medium-Type (65)
Tunnel-Client-Point de terminaison (66)
Tunnel-serveur-point de terminaison (67)
Connexion-tunnel-acct (68)
id_affectation_tunnel (82)
Tunnel-Client-Auth-ID (90)
Tunnel-serveur-auth-id (91)
Dans les versions antérieures, le LNS inclut ces attributs uniquement dans les enregistrements de comptabilité qu’il envoie au serveur RADIUS. Dans les messages de demande d’accès, 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 politiques de sécurité basées sur certains VSA RADIUS, et utilise des 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.)
La LAC et le LNS soutiennent l’ISSU unifiée. Lorsqu’une mise à niveau est lancée, le BAC termine toutes les négociations L2TP en cours, mais rejette toute nouvelle négociation tant que la mise à niveau n’est pas 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.
Terminologie L2TP
Le tableau 1 décrit les termes de base de la L2TP.
Terme |
Description |
|---|---|
AVP |
Paire attribut-valeur (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. |
Appeler |
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 transfère les paquets vers et depuis chacun. |
LNS |
Serveur réseau L2TP (LNS) : nœud agissant comme un côté d’un point de terminaison de tunnel L2TP et homologue du LAC. Le LNS est le point de terminaison logique d’une connexion PPP tunnelisée à partir du système distant par le LAC. |
Peer |
Dans le contexte de la L2TP, soit le LAC ou le LNS. Le pair de BAC 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 proxy sont envoyées par le LAC au LNS contenant des attributs tels que le type d’authentification, le nom de l’authentification et la contestation d’authentification. Le LNS répond avec les résultats de l’authentification. |
Proxy LCP |
Négociation du protocole de contrôle de liaison (LCP) 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 terminal ou routeur relié à un réseau d’accès à distance, qui est l’initiateur ou le destinataire d’un appel. |
Session |
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.
Note:
Il existe une relation univoque 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 de 0 ou plusieurs sessions L2TP. |
Mise en œuvre de L2TP
Le L2TP est mis en œuvre à quatre niveaux :
Source : routeur local faisant office de LAC.
Destination : routeur distant faisant office de LNS.
Tunnel : chemin direct entre l’ALC 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 de ce tunnel. Par exemple, la fermeture d’une destination ferme tous les tunnels et sessions vers cette destination.
Séquence des événements sur le LAC
Le routeur faisant office de LAC crée dynamiquement des destinations, des tunnels et des sessions, comme suit :
Le client établit une connexion PPP avec le routeur.
Le routeur et le client échangent des paquets LCP (Link Control Protocol). L’ALC négocie au nom de la LNS ; c’est ce qu’on appelle le LCP proxy.
Le LAC authentifie le client au nom du LNS ; C’est ce qu’on appelle l’authentification par proxy. En utilisant une base de données locale liée au nom de domaine ou l’authentification RADIUS, le routeur décide de mettre fin à la connexion PPP ou de la tunneliser.
Si le routeur découvre qu’il doit tunneliser la session, il effectue les opérations suivantes :
Configure une nouvelle destination ou sélectionne une destination existante.
Configure un nouveau tunnel ou sélectionne un tunnel existant.
Lorsqu’un secret partagé est configuré dans le profil de tunnel ou dans l’attribut RADIUS Tunnel-Password [69], selon la méthode utilisée pour configurer le tunnel, le secret est utilisé pour authentifier le tunnel pendant la phase d’établissement. Le LAC inclut le Challenge AVP dans le message SCCRQ envoyé au LNS. Le LNS renvoie l’AVP Challenge Response dans le message SCCRP. Si la réponse du LNS ne correspond pas à la valeur attendue par le LAC, l’authentification du tunnel échoue et le tunnel n’est pas établi.
Ouvre une nouvelle session.
Le routeur transmet les résultats des négociations LCP et de l’authentification au LNS.
Une connexion PPP existe désormais entre le client et le LNS.
Le routeur ignore les paquets reçus si la taille du champ de pavé de décalage facultatif de longueur variable dans l’en-tête L2TP est trop grande. Le routeur prend toujours en charge les paquets dont le champ de pad de décalage ne dépasse pas 16 octets et peut prendre en charge des champs de pad de décalage plus importants, en fonction d’autres informations contenues dans l’en-tête. Cette restriction est une cause possible, bien que peu probable, de rejet excessif des paquets L2TP.
Lorsque le LAC met fin à une session PPP, il génère une cause de déconnexion PPP et inclut cette information dans le code de cause de déconnexion PPP (AVP 46) lorsqu’il envoie un message CDN (Call-Disconnect-Notifi) au LNS. La valeur du code est 0, ce qui indique une erreur globale sans aucune information disponible.
Séquence des événements sur le LNS
Un routeur faisant office de LNS peut être configuré comme suit :
Le LAC initie un tunnel avec le routeur agissant comme le LNS.
Le LNS vérifie qu’un tunnel avec ce LAC est valide : la destination est configurée, le nom d’hôte et le mot de passe du tunnel sont corrects.
Le LNS complète la configuration du tunnel avec le LAC.
Le LAC configure une session et lance une demande de session au LNS.
Le LNS utilise une interface statique ou crée une interface dynamique pour ancrer la session PPP.
S’ils sont activés et présents, le LNS accepte le LCP proxy et les données d’authentification proxy et les transmet à PPP.
PPP traite le LCP proxy, s’il est présent, et, si le LCP proxy est acceptable, place LCP sur le LNS à l’état ouvert sans renégociation du LCP.
PPP traite les données d’authentification du proxy, si elles sont présentes, et transmet les données à AAA pour vérification. (Si les données ne sont pas présentes, PPP demande les données à l’homologue.)
Note:Lorsque le LCP proxy n’est pas présent ou n’est pas acceptable, le LNS négocie le LCP avec l’homologue. Lorsque la renégociation LCP est activée sur le LNS, celui-ci ignore tous les paramètres LCP pré-négociés et renégocie à la fois les paramètres LCP et l’authentification PPP avec le client PPP.
Le LNS transmet les résultats de l’authentification à l’homologue.
Retransmission des messages de contrôle L2TP
Les homologues L2TP gèrent une file d’attente de messages de contrôle qui doivent être envoyés au périphérique 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 laisse à 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 non accusé de réception est retransmis par l’homologue local. L’augmentation du nombre offre davantage de possibilités de réponse à l’homologue distant, mais augmente également la quantité de trafic de contrôle. Pour les tunnels qui ont été établis, incluez l’instruction
retransmission-count-establishedau niveau de la[edit services l2tp tunnel]hiérarchie. Pour les tunnels qui ne sont pas encore établis, incluez laretransmission-count-not-establisheddéclaration.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 délai d’attente, la minuterie 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 consacre également plus de ressources à un homologue potentiellement indisponible. Incluez l’instruction
minimum-retransmission-intervalau niveau de la[edit services l2tp tunnel]hiérarchie.
L’homologue local continue à 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.
Atteindre l’intervalle maximum de 16 secondes n’arrête pas les retransmissions. L’homologue local continue d’attendre 16 secondes après chaque retransmission ultérieure.
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.
L’homologue local envoie un message de contrôle.
L’homologue local attend 1 seconde, mais ne reçoit aucune réponse.
L’homologue local retransmet le message de contrôle. Il s’agit de la première retransmission.
L’homologue local attend 2 secondes, mais reçoit une réponse avant l’expiration de l’intervalle.
La retransmission s’arrête car 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.
L’homologue local envoie un message de contrôle.
L’homologue local attend 8 secondes, mais ne reçoit aucune réponse.
L’homologue local retransmet le message de contrôle. Il s’agit de la première retransmission.
L’homologue local attend 16 secondes, mais ne reçoit aucune réponse.
L’homologue local retransmet le message de contrôle. Il s’agit de la deuxième retransmission.
L’homologue local attend à nouveau 16 secondes, car l’intervalle ne peut pas dépasser 16, mais ne reçoit aucune réponse.
La retransmission s’arrête car le nombre maximal de retransmissions de deux a été atteint.
Le tunnel et toutes ses sessions sont dégagés.
Configuration des attributs de retransmission pour les messages de contrôle L2TP
Vous pouvez contrôler la retransmission des messages de contrôle L2TP non reconnus en configurant le nombre de fois que l’homologue local retransmet le message et la durée d’attente d’une réponse avant la retransmission.
Les homologues L2TP gèrent une file d’attente de messages de contrôle qui doivent être envoyés au périphérique homologue. Une fois que l’homologue local (LAC ou LNS) a envoyé un message, il attend une réponse de l’homologue distant. Si une réponse n’est pas reçue dans l’intervalle de retransmission minimal, l’homologue local retransmet le message et attend le double de l’intervalle de retransmission. Chaque fois qu’il retransmet le message, l’homologue double la durée d’attente, jusqu’à un maximum de 16 secondes.
Si aucune réponse n’est reçue, l’homologue local continue d’envoyer le message jusqu’à ce que le nombre de retransmissions corresponde au nombre de retransmissions. Dans ce cas, les retransmissions s’arrêtent et le tunnel et toutes ses sessions sont effacés.
Avant de rétrograder vers une version Junos OS qui ne prend pas en charge ces instructions, nous vous recommandons d’annuler explicitement la configuration de la fonctionnalité en incluant l’instruction et l’instruction no retransmission-count-established no retransmission-count-non-established au niveau de la [edit services l2tp tunnel] hiérarchie.
Lors d’une mise à niveau logicielle unifiée en service (ISSU unifiée) sur un routeur MX Series configuré en tant que LAC, le LAC ne répond pas aux messages de contrôle du LNS. Cela peut entraîner l’abandon des sessions L2TP LAC. Vous pouvez éviter cette situation en vous assurant que le nombre maximal de retransmissions sur le LNS est défini sur 16 ou plus.
Pour définir le nombre maximal de retransmissions pour les tunnels établis :
Configurez le nombre.
[edit services l2tp tunnel] user@host# set retransmission-count-established count
Pour définir le nombre maximal de retransmissions pour les tunnels non établis :
Configurez le nombre.
[edit services l2tp tunnel] user@host# set retransmission-count-not-established count
Pour définir l’intervalle minimal entre les retransmissions :
Configurez l’intervalle.
[edit services l2tp tunnel] user@host# set minimum-retransmission-timeout seconds
Par exemple, la configuration suivante spécifie que les tunnels établis ont un nombre maximal de retransmissions de trois et un intervalle de retransmission minimal de deux secondes :
[edit services l2tp tunnel] user@host# set retransmission-count-established 3 user@host# set minimum-retransmission-timeout 2
Avec cet exemple de configuration, la séquence suivante s’applique à chaque message de contrôle envoyé par le LAC ou le LNS :
- L’homologue local envoie le message de contrôle et attend une réponse de l’homologue distant.
- Si la réponse n’est pas reçue dans l’intervalle minimum de 2 secondes, l’homologue local retransmet le message. Il s’agit de la première retransmission.
- Si la réponse n’est pas reçue dans les 4 secondes, l’homologue local retransmet le message. Il s’agit de la deuxième retransmission.
- Si la réponse n’est pas reçue dans les 8 secondes, l’homologue local retransmet le message. Il s’agit de la troisième et dernière retransmission, car le nombre maximum a été atteint.
- Si la réponse n’est pas reçue dans les 16 secondes, le tunnel et toutes ses sessions sont effacés.
Activation des compteurs de tunnel et globaux pour la collecte de statistiques SNMP
Par défaut, l’interrogation SNMP est désactivée pour les statistiques L2TP. Par conséquent, le tunnel L2TP et les compteurs globaux répertoriés dans le tableau 2 ont une valeur par défaut de zéro.
Nom du compteur |
Type |
|---|---|
jnxL2tpTunnelStatsDataTxPkts |
Tunnel |
jnxL2tpTunnelStatsDataRxPkts |
Tunnel |
jnxL2tpTunnelStatsDataTxBytes |
Tunnel |
jnxL2tpTunnelStatsDataRxBytes |
Tunnel |
jnxL2tpStatsPayloadRxOctets |
Mondiale |
jnxL2tpStatsPayloadRxPkts |
Mondiale |
jnxL2tpStatsPayloadTxOctets |
Mondiale |
jnxL2tpStatsPayloadTxPkts |
Mondiale |
Vous pouvez activer la collecte de ces statistiques en incluant l’instruction enable-snmp-tunnel-statistics au niveau de la [edit services l2tp] hiérarchie. Lorsqu’il est activé, le processus L2TP interroge ces statistiques toutes les 30 secondes pendant 1000 sessions. L’âge potentiel des statistiques augmente avec le nombre de sessions d’abonnés ; Les données sont actualisées plus rapidement à mesure que le nombre de sessions diminue. Par exemple, avec 60 000 sessions, aucune de ces statistiques ne peut dater de plus de 30 minutes.
La charge du système peut augmenter lorsque vous activez ces compteurs et utilisez également les mises à jour comptables intermédiaires RADIUS. Nous vous recommandons d’activer ces compteurs lorsque vous utilisez uniquement des statistiques SNMP.
Pour activer la collecte de statistiques L2TP pour SNMP :
Activez la collecte de statistiques.
[edit services l2tp] user@host1# set enable-snmp-tunnel-statistics
Vérification et gestion de L2TP pour l’accès des abonnés
But
Afficher ou effacer des informations sur les tunnels et les sessions L2TP.
L’option all n’est pas destinée à être utilisée comme moyen d’effectuer une déconnexion en bloc des abonnés L2TP. Nous vous recommandons de ne pas utiliser cette all option avec les clear services l2tp destinationinstructions , clear services l2tp sessionou clear services l2tp tunnel dans un environnement de production. Au lieu d’effacer tous les abonnés en même temps, envisagez d’effacer les abonnés dans un groupe plus petit, en fonction de l’interface, du tunnel ou du point de terminaison de destination.
Action
Pour afficher un résumé des tunnels, des sessions, des erreurs et des paquets de données et de contrôle L2TP :
user@host> show services l2tp summary
Pour afficher les destinations L2TP :
user@host> show services l2tp destination
Pour effacer toutes les destinations L2TP :
user@host> clear services l2tp destination all
Pour effacer les statistiques de tous les tunnels L2TP appartenant à une destination, des tunnels appartenant à une adresse de passerelle locale spécifiée et des tunnels appartenant à une adresse de passerelle d’homologue spécifiée :
user@host>clear services l2tp destination statistics all user@host>clear services l2tp destination local-gateway 203.0.113.2
Pour afficher les sessions L2TP :
user@host> show services l2tp session
Pour effacer toutes les sessions L2TP, la session avec un ID de session local spécifié ou les sessions associées à la passerelle locale spécifiées par une adresse IP ou un nom :
user@host>clear services l2tp session all user@host>clear services l2tp session local-session-id 40553 user@host>clear services l2tp session local-gateway 203.0.113.2 user@host>clear services l2tp session local-gateway-name lns-mx960
Pour effacer les statistiques de toutes les sessions L2TP, de la session avec un ID de session local spécifié ou des sessions associées à la passerelle locale spécifiées par une adresse IP ou un nom :
user@host>clear services l2tp session statistics all user@host>clear services l2tp session statistics local-session-id 17967 user@host>clear services l2tp session statistics local-gateway 203.0.113.2 user@host>clear services l2tp session statistics local-gateway-name lns-mx960
Pour afficher les tunnels L2TP :
user@host> show services l2tp tunnel
Pour effacer tous les tunnels L2TP, le tunnel avec un ID de tunnel local spécifié ou les tunnels associés à la passerelle locale spécifiés par une adresse IP ou un nom :
user@host> clear services l2tp tunnel all user@host>clear services l2tp tunnel local-tunnel-id 40553 user@host>clear services l2tp tunnel local-gateway 203.0.113.2 user@host>clear services l2tp tunnel local-gateway-name lns-mx960
Pour effacer les statistiques de tous les tunnels L2TP, du tunnel avec un ID de tunnel local spécifié ou des tunnels associés à la passerelle locale spécifiés par une adresse IP ou un nom :
user@host> clear services l2tp tunnel statistics all user@host>clear services l2tp tunnel statistics local-tunnel-id 40553 user@host>clear services l2tp tunnel statistics local-gateway 203.0.113.2 user@host>clear services l2tp tunnel statistics local-gateway-name lns-mx960