Configuration et désinstallation du tunnel L2TP

Options de téléchargement

PDF (213.1 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (134.7 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (177.9 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:29 janvier 2008

ID du document:23980

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

PPP

L2TP

Résumé du flux PPP et L2TP

Séquence de connexion PPP/L2TP

Débogage provenant de LAC montrant l'établissement des appels PPP et L2TP

Débogage provenant de LNS montrant l'établissement des appels PPP et L2TP

Séquence de déconnexion PPP/L2TP

Débogage provenant de LAC qui montre PPP et L2TP Disconnect

Débogage provenant de LNS qui montre PPP et L2TP Disconnect

Informations connexes

Introduction

Ce document traite de la configuration et de la désactivation du tunnel L2TP (Layer Two Tunneling Protocol). Le document fournit également un résumé de PPP et de L2TP.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Les informations de ce document sont basées sur le logiciel Cisco IOS® versions 12.0(1)T et ultérieures.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

PPP

PPP est un protocole symétrique peer-to-peer qui transporte le trafic de couche 2 et de couche 3 (L3) sur des liaisons point à point. Il existe trois composants principaux :

Encapsulation
Protocole LCP (Link Control Protocol)
NCP (Network Control Protocol)

Les datagrammes sont encapsulés dans PPP. Le protocole LCP permet la négociation des options de configuration pour permettre l’établissement de la liaison. Les protocoles NCP sont négociés pour chacun des protocoles de couche 3 qui s’exécutent sur la liaison.

Au cours de la durée de vie d’une session PPP, la liaison passe par quatre phases distinctes :

Établissement de la liaison - Dans le cadre de la phase d’établissement de la liaison, le protocole PPP utilise une fonction LCP qui doit être terminée et déclarée ouverte avant que la liaison entre dans la phase d’authentification, le cas échéant, et négocie l’ouverture de la couche réseau. Le protocole LCP est également utilisé pour mettre fin à la liaison PPP.
Authentification : la phase d'authentification est spécifique à la mise en oeuvre et n'est pas obligatoire pour passer du protocole LCP au protocole NCP. Si négocié et convenu au cours de la phase LCP, l’homologue distant doit s’identifier et passer la méthode d’authentification convenue avant que le protocole PPP ne passe à la couche réseau.
Couche réseau : la négociation NCP garantit que les deux homologues s’accordent sur les caractéristiques du protocole L3. Dans le cas d'IP, le protocole de contrôle est appelé IP Control Protocol (IPCP). Outre la négociation entre homologues, il y a également un élément d'affectation. Cela est courant avec les clients d'accès à distance de type Microsoft Windows qui n'ont pas d'adresse IP allouée et qui comptent sur le fournisseur de services pour allouer l'adresse IP lors de la connexion.
Terminaison de liaison : la phase de terminaison de liaison peut être entrée à tout moment pendant le cycle de vie de l'appel. LCP est utilisé pour envoyer la demande de terminaison.

L2TP

L2TP étend la nature point à point du protocole PPP. L2TP fournit une méthode d’encapsulation pour la transmission de trames PPP à canaux, qui permet aux points d’extrémité PPP d’être tunnellisés sur un réseau à commutation de paquets. Le protocole L2TP est le plus souvent déployé dans des scénarios de type accès distant qui utilisent Internet pour offrir des services de type intranet. Le concept est celui d'un réseau privé virtuel (VPN).

Les deux principaux éléments physiques de L2TP sont le concentrateur d’accès L2TP (LAC) et le serveur de réseau L2TP (LNS) :

LAC : le LAC est un homologue du LNS qui agit comme un côté du point d'extrémité du tunnel. Le LAC met fin à la connexion PPP distante et se trouve entre le distant et le LNS. Les paquets sont transférés vers et depuis la connexion distante via la connexion PPP. Les paquets en provenance et à destination du LNS sont transférés via le tunnel L2TP.
LNS : le LNS est un homologue du LAC qui agit comme un côté du point d'extrémité du tunnel. Le LNS est le point de terminaison des sessions en tunnel PPP de LAC. Il est utilisé pour agréger les sessions PPP multicanaux de LAC et pour entrer dans le réseau privé.

Il existe deux types de message différents que L2TP utilise :

Messages de contrôle : L2TP transmet les messages de contrôle et de données sur des canaux de contrôle et de données distincts. Le canal de contrôle intrabande transmet les messages de gestion de connexion de contrôle séquencé, de gestion des appels, de rapport d'erreurs et de contrôle de session. L'initialisation de la connexion de contrôle n'est pas spécifique au LAC ou au LNS, mais plutôt à l'émetteur et au récepteur du tunnel qui a de la pertinence dans l'établissement de la connexion de contrôle. Une méthode d'authentification par défi à secret partagé est utilisée entre les points d'extrémité du tunnel.
Messages de données : les messages de données sont utilisés pour encapsuler les trames PPP envoyées dans le tunnel L2TP.

Le protocole L2TP utilise le port UDP (User Datagram Protocol) enregistré 1701 et l’ensemble du paquet L2TP est encapsulé dans le datagramme UDP. Selon le fonctionnement normal du protocole UDP, l'initiateur du tunnel sélectionne un port UDP disponible et envoie le numéro de port 1701 à la destination UDP. Dans la réponse, le numéro du port de destination est identique au numéro du port source utilisé dans l’en-tête UDP entrant. Le port source est défini sur la base de tout port libre trouvé. Une fois les ports source et de destination établis, les ports doivent rester identiques pendant la durée du tunnel. Dans le logiciel Cisco IOS, les numéros de port source et de destination sont toujours définis sur le numéro de port UDP 1701.

Remarque : Les protocoles L2F (Layer 2 Forwarding) et L2TP partagent le même numéro de port UDP. Le champ Version de l'en-tête vous permet de distinguer les deux protocoles. Une valeur de 1 indique L2F et une valeur de 2 indique L2TP.

Résumé du flux PPP et L2TP

L'établissement de la connexion et de la session de contrôle doit avoir lieu avant que les trames PPP puissent être transmises via le tunnel.

Une fois le canal de contrôle établi, des sessions sont créées pour chaque connexion PPP. L'établissement de la session est directionnel, par rapport au BAC et au SNL. Pour les appels entrants, le LAC demande au LNS d'accepter la session. Pour les appels sortants, le LNS demande au LAC d'accepter la session.

La section Séquence de connexion PPP/L2TP de ce document détaille la configuration des appels PPP et L2TP lorsqu'un utilisateur à accès distant passe un appel dans le LAC. Cet exemple utilise le service d'identification de numéro composé (DNIS) afin d'initier le tunnel L2TP, bien que vous puissiez également utiliser le nom de domaine à cette fin. La séquence montre le début de la session PPP à partir d'un routeur SOHO 2500, la négociation LCP entre l'utilisateur d'accès distant et LAC et l'authentification partielle. Le LAC procède ensuite à l'établissement du tunnel L2TP et de la session dans le tunnel. Une session est établie pour chaque connexion PPP entre le LAC et le LNS. L2TP utilise les identificateurs de tunnel et de session homologues dans tous les messages sortants afin de multiplier et démultiplexer les connexions PPP. Ces identificateurs sont attribués et échangés au cours des phases d'établissement de session et de connexion de contrôle respectives. Les ID de tunnel et de session ont une signification locale uniquement. Les points d'extrémité du tunnel ont des identificateurs différents pour le même tunnel et la même session.

Remarque : La valeur 0 a une signification unique et n'est utilisée que lorsque le tunnel et l'identificateur de session doivent encore être attribués.

Après l'établissement du tunnel, le processus d'authentification PPP se termine entre l'utilisateur d'accès distant et le LNS. Le LAC continue de recevoir des trames PPP. Le verrouillage de trame de liaison et le contrôle de redondance cyclique (CRC) sont supprimés, encapsulés dans LT2P et transférés dans le tunnel vers le LNS. Là, le paquet L2TP est reçu et traité comme s’il était terminé sur une interface PPP locale. La négociation du protocole PPP NCP se produit, puis le protocole IPCP est déclaré ouvert. La connexion est terminée.

Séquence de connexion PPP/L2TP

Voici la séquence d'événements de connexion :

L'utilisateur distant initie une connexion PPP. Le LAC accepte la connexion. Une liaison PPP est établie.
LCP est négocié entre l'utilisateur distant et LAC. Le LAC émet un défi CHAP (Challenge Handshake Authentication Protocol) afin d'effectuer une authentification partielle de l'utilisateur distant. La réponse est envoyée au LNS lors de l'établissement de la session. La réponse est envoyée en tant que réponse d'authentification proxy AVP 33 dans l'ICCN (Incoming-Call-Connected).
Le DNIS est utilisé pour déterminer si l'utilisateur est un client VPDN (Virtual Private Dial Network).
Comme il n'existe aucun tunnel pour le numéro composé (614629), la création d'un nouveau tunnel est nécessaire. RADIUS est interrogé et les informations du tunnel sont téléchargées vers le LAC.
La connexion de contrôle est démarrée. Le tunnel est à l'état IDLE :
- L'initiateur du tunnel (dans ce cas, le LAC) envoie un SCCRQ (Start-Control-Connection-Request) au LNS. Le SCCRQ contient un défi AVP 11, qui indique que le LAC veut authentifier le tunnel avec l'utilisation d'une authentification de type CHAP. Le même secret est connu des deux points d'extrémité du tunnel. Le tunnel est maintenant dans l'état WAIT-CTL-REPLY.
- Le LNS peut activer le tunnel, de sorte que le LNS répond par un SCCRP (Start-Control-Connection-Reply). Le SCCRP contient un défi AVP 11 et une réponse de défi AVP 13 en réponse au SCCRQ. Le tunnel est maintenant dans l'état WAIT-CTL-REPLY.
- Le LAC répond par un message SCCCN (Start-Control-Connection-Connected). Le SCCCN contient un AVP 13 en réponse au SCCRP. Le tunnel est maintenant à l'état Établi.
- Le LNS envoie un message ZLB (Zero-Length Body) au LAC. Le message ZLB est un accusé de réception séquencé. Le tunnel est maintenant à l'état Établi.
L'authentification du tunnel est maintenant terminée et le tunnel est établi. La session est maintenant dans un état IDLE.
Maintenant que le tunnel existe, un échange en trois étapes pour l'établissement de la session dans le tunnel est effectué :
- Le LAC envoie une requête d'appel entrant (ICRQ) avec les informations de paramètre pour la session. La session est maintenant en état de réponse en attente.
- Le LNS envoie une réponse d'appel entrant (ICRP) qui contient l'ID de session. La session est maintenant dans un état Attendre la connexion.
- Le LAC envoie un ICCN et fournit au LNS des informations supplémentaires pour l'appel répondu. Ces informations incluent les informations LCP de la négociation effectuée par le LAC et l'utilisateur distant. La session est maintenant à l'état Établi.
- Le LNS envoie un message ZLB, qui est un accusé de réception séquencé, au LAC. La session est maintenant à l'état Établi.
Après l'établissement de la session, une interface d'accès virtuel est créée sur le LNS. Les informations de configuration LCP qui ont été fournies dans l'ICCN sont forcées sur la pile PPP de l'interface d'accès virtuel. Ces informations incluent les informations d'authentification partielle.
Le LNS génère un défi d'authentification. La réponse d'authentification du proxy AVP 33, qui a été fournie dans l'ICCN, est relayée.
L'authentification, l'autorisation et la comptabilité normales (AAA) ou l'authentification et l'autorisation PPP ont lieu.
Une demande d'accès RADIUS est envoyée pour l'authentification et l'autorisation par utilisateur.
Un ACCEPT RADIUS est reçu.

Remarque : RADIUS a été configuré pour autoriser l'adresse IP que l'utilisateur distant a offerte dans la demande de configuration IPCP entrante.
Un message de réussite CHAP est envoyé à l'utilisateur distant.
La négociation PPP IPCP se termine et est déclarée OUVERTE. Une route d’hôte est installée sur l’interface distante. L'utilisateur distant est maintenant connecté et le flux de trafic peut commencer.

Flux d'appels de connexion PPP et L2TP