Configuración y anulación del túnel L2TP

Opciones de descarga

PDF (180.0 KB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (133.7 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (176.6 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:29 de enero de 2008

ID del documento:23980

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

PPP

L2TP

Resumen de Flujo PPP y L2TP

La secuencia de conexión de PPP/L2TP

Depuración tomada de LAC que muestra el establecimiento de llamadas PPP y L2TP

Depuración tomada de LNS que muestra el establecimiento de llamadas PPP y L2TP

La secuencia de desconexión de PPP/L2TP

Depuración tomada de LAC que muestra la desconexión PPP y L2TP

Depuración tomada de LNS que muestra la desconexión PPP y L2TP

Información Relacionada

Introducción

Este documento trata sobre la configuración y desactivación del túnel L2TP (Layer Two Tunneling Protocol). El documento también ofrece un resumen de PPP y L2TP.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información en este documento se basa en Cisco IOS® Software Releases 12.0(1)T y posteriores.

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.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

PPP

PPP es un protocolo simétrico de igual a igual que transporta el tráfico de capa 2 y capa 3 (L3) a través de enlaces punto a punto. Hay tres componentes principales:

‘Encapsulación
Protocolo de control de enlaces (LCP)
Protocolo de control de red (NCP)

Los datagramas se encapsulan en PPP. El LCP permite la negociación de opciones de configuración para permitir el establecimiento de link. Los NCP se negocian para cada uno de los protocolos L3 que se ejecutan en el link.

Durante la vida de una sesión PPP, el link pasa por cuatro fases distintas:

Establecimiento de link: como parte de la fase de establecimiento de link, PPP utiliza una función LCP que debe completarse y declararse abierta antes de que el link entre en la fase de autenticación, si procede, y negocia la apertura de la capa de red. LCP también se utiliza para terminar el link PPP.
Autenticación: la fase de autenticación es específica de la implementación y no es un requisito obligatorio para el traslado de LCP a NCP. Si se negocia y se acuerda durante la fase LCP, el peer remoto debe identificarse y pasar el método de autenticación acordado antes de que PPP se mueva a la capa de red.
Capa de red: la negociación NCP garantiza que ambos peers coincidan en las características del protocolo L3. En el caso de IP, el protocolo de control se denomina protocolo de control IP (IPCP). Además de la negociación entre pares, también existe un elemento de asignación. Esto es común con los clientes de acceso remoto de tipo Microsoft Windows que no tienen ninguna dirección IP asignada y confían en el proveedor de servicios para asignar la dirección IP al conectarse.
Terminación del link: la fase de terminación del link se puede ingresar en cualquier momento durante el ciclo de vida de la llamada. LCP se utiliza para enviar la petición de terminación.

L2TP

L2TP amplía la naturaleza punto a punto de PPP. L2TP proporciona un método de encapsulación para la transmisión de tramas PPP tunelizadas, que permite que los extremos PPP sean tunelizados a través de una red conmutada por paquetes. L2TP se suele implementar en escenarios de tipo acceso remoto que utilizan Internet para ofrecer servicios de tipo intranet. El concepto es el de una red privada virtual (VPN).

Los dos elementos físicos principales de L2TP son el L2TP Access Concentrator (LAC) y el L2TP Network Server (LNS):

LAC: el LAC es un peer del LNS que actúa como un lado del extremo del túnel. LAC finaliza la conexión remota PPP y se ubica entre el remoto y el LNS. Los paquetes se reenvían a y desde la conexión remota a través de la conexión PPP. Los paquetes hacia y desde el LNS se reenvían a través del túnel L2TP.
LNS: el LNS es un peer del LAC que actúa como un lado del extremo del túnel. El LNS es el punto de terminación para las sesiones tunelizadas PPP de LAC. Esto se utiliza para agregar las sesiones PPP tunelizadas LAC múltiples y el ingreso a la red privada.

Hay dos tipos de mensajes diferentes que L2TP utiliza:

Mensajes de control: L2TP pasa los mensajes de datos y de control por canales de datos y de control independientes. El canal de control en banda pasa los mensajes de control de conexión secuenciada, administración de llamadas, informes de errores y control de sesión. La iniciación de la conexión de control no es específica para el LAC o el LNS sino más bien para el originador y receptor del túnel que tiene relevancia en el establecimiento de conexión de control. Se utiliza un método de autenticación de desafío secreto compartido entre los puntos finales del túnel.
Mensajes de datos: los mensajes de datos se utilizan para encapsular las tramas PPP que se envían al túnel L2TP.

L2TP utiliza el puerto registrado 1701 del protocolo de datagrama de usuario (UDP), y el paquete L2TP es encapsulado dentro del datagrama UDP. Como por operación UDP normal, el iniciador del túnel selecciona un puerto UDP disponible y envía el puerto número 1701 al destino UDP. En la respuesta, el número de puerto de destino es el mismo que el número de puerto de origen que se utiliza en el encabezado UDP entrante. El puerto de origen se establece en función de cualquier puerto libre que se encuentre. Después de establecer los puertos de origen y de destino, los puertos deben permanecer iguales durante la duración del túnel. En Cisco IOS Software, los números de puerto de origen y de destino siempre se establecen en el número de puerto UDP 1701.

Nota: El protocolo de reenvío de capa 2 (L2F) y L2TP comparten el mismo número de puerto UDP. El campo Versión del encabezado permite discriminar entre los dos protocolos. Un valor de 1 indica L2F, mientras que un valor de 2 indica L2TP.

Resumen de Flujo PPP y L2TP

El establecimiento de la conexión de control y la sesión debe ocurrir antes de que las tramas PPP se puedan reenviar a través del túnel.

Después del establecimiento exitoso del canal de control, se crean sesiones para cada conexión PPP. El establecimiento de sesión es direccional, en relación con el LAC y el LNS. Para las llamadas entrantes, el LAC solicita al LNS que acepte la sesión. Para las llamadas salientes, el LNS le pide al LAC que acepte la sesión.

La sección Secuencia de Conexión PPP/L2TP de este documento detalla la configuración de la llamada PPP y L2TP cuando un usuario de acceso remoto realiza una llamada al LAC. Este ejemplo utiliza el servicio de identificación de número marcado (DNIS) para iniciar el túnel L2TP, aunque también puede utilizar el nombre de dominio para este fin. La secuencia muestra el inicio de la sesión PPP desde un router SOHO 2500, la negociación LCP entre el usuario de acceso remoto y LAC, y la autenticación parcial. Luego, el LAC procede a establecer el túnel L2TP y la sesión dentro del túnel. Se establece una sesión para cada conexión PPP entre el LAC y el LNS. L2TP utiliza los identificadores de túnel de peer y sesión en todos los mensajes salientes para multiplexar y desmultiplexar las conexiones PPP. Estos identificadores se asignan e intercambian durante las respectivas fases de conexión de control y establecimiento de sesión. Los ID de túnel y de sesión sólo tienen importancia local. Los extremos del túnel tienen identificadores diferentes para el mismo túnel y sesión.

Nota: El valor 0 tiene una significación única y sólo se utiliza cuando el túnel y el identificador de sesión aún no se han asignado.

Después del establecimiento del túnel, el proceso de autenticación PPP se completa entre el usuario de acceso remoto y el LNS. El LAC continúa recibiendo las tramas PPP. El entramado de enlaces y la verificación de redundancia cíclica (CRC) se quitan, encapsulan en LT2P y se reenvían al túnel al LNS. Allí, el paquete L2TP se recibe y se trata como si se terminara en una interfaz PPP local. Se produce la negociación de PPP NCP y luego se declara IPCP abierto. La conexión ha finalizado.

La secuencia de conexión de PPP/L2TP

Ésta es la secuencia de conexión de eventos:

El usuario remoto inicia una conexión PPP. El LAC acepta la conexión. Se estableces un link PPP.
El LCP se negocia entre el usuario remoto y el LAC. El LAC emite un desafío del Protocolo de autenticación por desafío mutuo (CHAP) para realizar una autenticación parcial del usuario remoto. La respuesta se envía al LNS durante el establecimiento de la sesión. La respuesta se envía como respuesta de autenticación de proxy del par valor de atributo (AVP) 33 en el ICCN (Incoming-Call-Connected).
El DNIS se utiliza para determinar si el usuario es un cliente de red de acceso telefónico privada virtual (VPDN).
Dado que no existe ningún túnel para el número marcado (614629), es necesario crear un túnel nuevo. RADIUS se consulta y la información del túnel se descarga en el LAC.
Se ha iniciado la conexión de control. El túnel se encuentra en estado IDLE:
- El iniciador del túnel (en este caso, el LAC) envía una solicitud de conexión de control de inicio (SCCRQ) al LNS. El SCCRQ contiene un desafío AVP 11, que indica que el LAC desea autenticar el túnel con el uso de una autenticación estilo CHAP. El mismo secreto es conocido para ambos puntos finales del túnel. El túnel se encuentra en estado WAIT-CTL-REPLY.
- El LNS puede activar el túnel, por lo que el LNS responde con un Start-Control-Connection-Reply (SCCRP). El SCCRP contiene un desafío AVP 11 y una respuesta de desafío AVP 13 en respuesta al SCCRQ. El túnel se encuentra en estado WAIT-CTL-REPLY.
- LAC responde con un mensaje de Start-Control-Connection-Connected (SCCCN). El SCCCN contiene un AVP 13 en respuesta al SCCRP. El túnel se encuentra en un estado establecido.
- El LNS envía un mensaje de cuerpo de longitud cero (ZLB) al LAC. El mensaje ZLB es un reconocimiento secuenciado. El túnel se encuentra en un estado establecido.
La autenticación del túnel está completa y el túnel está establecido. La sesión se encuentra en un estado ocioso.
Ahora que el túnel existe, se realiza un intercambio de tres vías para el establecimiento de sesión dentro del túnel:
- La LAC envía una Petición de llamada entrante (ICRQ) con la información del parámetro para la sesión. La sesión se encuentra ahora en el estado de respuesta de espera.
- El LNS envía una respuesta de llamada entrante (ICRP) que contiene la ID de sesión. La sesión se encuentra ahora en estado Espera de conexión.
- El LAC envía un ICCN y proporciona al LNS información adicional para la llamada respondida. Esta información incluye la información de LCP de la negociación que el LAC y el usuario remoto realizaron. La sesión se encuentra en el estado Establecido.
- El LNS envía un mensaje ZLB, que es un reconocimiento secuenciado, al LAC. La sesión se encuentra en el estado Establecido.
Después del establecimiento de la sesión, se crea una interfaz de acceso virtual en el LNS. La información de configuración de LCP que se entregó en el ICCN se fuerza en la pila PPP de la interfaz de acceso virtual. Esta información incluye la información de autenticación parcial.
El LNS genera un desafío de autenticación. Se reproduce la respuesta de autenticación de proxy AVP 33, que se entregó en la ICCN.
La autenticación, autorización y contabilidad (AAA) o la autenticación y autorización PPP se realizan de forma normal.
Se envía una solicitud de acceso RADIUS para la autenticación y autorización por usuario.
Se recibe un RADIUS Access-Accept .

Nota: RADIUS se ha configurado para permitir la dirección IP que el usuario remoto ha ofrecido en la IPCP Configure-Request entrante.
Un mensaje CHAP satisfactorio se envía al usuario remoto.
La negociación PPP IPCP se completa y se declara ABIERTA. Se instala una ruta de host para la interfaz remota. El usuario remoto ya está conectado y el flujo de tráfico puede comenzar.

Flujo de llamadas de conexión de PPP y L2TP