Descripción general de la tunelización L2TP basada en filtros de firewall en redes IPv4
El protocolo de túnel de capa 2 (L2TP) es un protocolo cliente-servidor que permite que el protocolo punto a punto (PPP) se tunelice a través de una red. L2TP encapsula paquetes de capa 2, como PPP, para su transmisión a través de una red. Un concentrador de acceso L2TP (LAC), configurado en un dispositivo de acceso, recibe paquetes de un cliente remoto y los reenvía a un servidor de red L2TP (LNS) en una red remota. L2TPv3 define el protocolo de control base y la encapsulación para tunelizar múltiples conexiones de capa 2 entre dos nodos IPv6. Las diferencias significativas entre L2TPv2 y L2TPv3 incluyen las siguientes:
Separación de todas las AVP y referencias relacionadas con la PPP, lo que permite la inclusión de una parte del encabezado de datos L2TP que era específica para las necesidades de la PPP.
Transición de un ID de sesión de 16 bits y un ID de túnel a un ID de sesión de 32 bits y un ID de conexión de control, respectivamente.
Extensión del mecanismo de autenticación de túnel para cubrir todo el mensaje de control en lugar de solo una parte de ciertos mensajes.
L2TPv3 solo es compatible con IPv6.
Para los filtros de firewall, solo se admite la encapsulación/desencapsulación del plano de datos L2TPv3.
L2TP se compone de dos tipos de mensajes, mensajes de control y mensajes de datos (a veces denominados paquetes de control y paquetes de datos, respectivamente). Los mensajes de control se utilizan en el establecimiento, mantenimiento y limpieza de conexiones y sesiones de control. Estos mensajes utilizan un canal de control confiable dentro de L2TP para garantizar la entrega. Los mensajes de datos se utilizan para encapsular el tráfico L2 que se transporta a través de la sesión L2TP.
Puede configurar una red IPv4 para transportar tráfico de tránsito IPv4, IPv6 o MPLS mediante mecanismos de protocolo de tunelización GRE iniciados por dos acciones de filtro de firewall estándar. Esta característica también es compatible con sistemas lógicos. Al configurar la tunelización L2TP con filtros de firewall, no es necesario crear interfaces de túnel en tarjetas de interfaz física (PIC) de servicios de túnel ni en concentradores de puertos modulares (MPC) MPC3E. En su lugar, los motores de reenvío de paquetes proporcionan servicios de túnel a interfaces lógicas Ethernet o interfaces Ethernet agregadas alojadas en tarjetas de interfaz modular (MIC) o MPC en plataformas de enrutamiento universal 5G de la serie MX.
Dos enrutadores de la serie MX instalados como enrutadores perimetrales de proveedor (PE) proporcionan conectividad a los enrutadores perimetrales del cliente (CE) en dos redes separadas. Las interfaces MIC o MPC en los enrutadores PE realizan la encapsulación y desencapsulación L2TP IPv4 de las cargas útiles. Después de la desencapsulación, los paquetes se envían a la interfaz local de una tabla de enrutamiento especificada en la acción, o a la tabla de enrutamiento predeterminada, según el campo de protocolo del encabezado L2TP. Sin embargo, opcionalmente se puede enviar un paquete L2TP a través de la estructura con un token igual a un índice de interfaz de salida para realizar una conexión cruzada de capa 2. Puede especificar el especificador de interfaz de salida que se utilizará para el paquete L2TP que se va a enviar incluyendo la instrucción en el nivel de jerarquía.decapsulate l2tp output-interface interface-name cookie l2tpv3-cookie[edit firewall family family-name filter filter-name term term-name then]
Durante la desencapsulación, el cabezal interno debe ser Ethernet para túneles L2TP. La clase de reenvío se aplica de forma predeterminada antes que el firewall y no se conserva para el paquete desencapsulado (mediante la instrucción en el nivel de jerarquía, que es una acción de filtro que no termina).forwarding-class class-name[edit firewall family family-name] Sin embargo, puede especificar la clase de reenvío con la que debe clasificarse el paquete incluyendo la acción de filtro para un paquete desencapsulado mediante la instrucción en el nivel de jerarquía.decapsulate l2tp forwarding-class class-name[edit firewall family family-name filter filter-name term term-name then]
Las siguientes definiciones de campo se definen para su uso en todas las encapsulaciones de encabezado de sesión L2TP.
El campo ID de sesión es un campo de 32 bits que contiene un identificador distinto de cero para una sesión. Las sesiones L2TP se denominan mediante identificadores que solo tienen significado local. La misma sesión lógica recibirá diferentes ID de sesión por cada extremo de la conexión de control durante la duración de la sesión. Cuando se utiliza la conexión de control L2TP para el establecimiento de la sesión, los ID de sesión se seleccionan e intercambian como AVP de ID de sesión local durante la creación de una sesión. El ID de sesión por sí solo proporciona el contexto necesario para todo el procesamiento posterior de paquetes, incluida la presencia, el tamaño y el valor de la cookie, el tipo de subcapa específica de L2 y el tipo de carga que se tuneliza.
El campo opcional Cookie contiene un valor de longitud variable (máximo 64 bits) que se utiliza para comprobar la asociación de un mensaje de datos recibido con la sesión identificada por el ID de sesión. El campo Cookie debe establecerse en el valor aleatorio configurado o señalado para esta sesión. La cookie proporciona un nivel adicional de garantía de que un mensaje de datos ha sido dirigido a la sesión adecuada por el ID de sesión. Una cookie bien elegida puede evitar la desviación inadvertida de paquetes aleatorios con ID de sesión recientemente reutilizados o para ID de sesión sujetos a corrupción de paquetes. La cookie también puede proporcionar protección contra algunos ataques específicos de inserción de paquetes maliciosos. Cuando se utiliza la conexión de control L2TP para el establecimiento de la sesión, se seleccionan valores de cookie aleatorios y se intercambian como AVP de cookies asignadas durante la creación de la sesión.
Una sesión es una conexión lógica creada entre el LAC y el LNS cuando se establece una conexión PPP de extremo a extremo entre un sistema remoto y el LNS. Existe una relación uno a uno entre las sesiones L2TP establecidas y sus conexiones PPP asociadas. Un túnel es una agregación de una o más sesiones L2TP.
A partir de Junos OS versión 15.1, la desencapsulación de paquetes IP que se envían a través de un túnel L2TP con condiciones de coincidencia de filtro de firewall estándar y acciones especificadas se realiza mediante una búsqueda de capa 3. En Junos OS versión 14.2 y anteriores, la desencapsulación del tráfico a través de un túnel L2TP con acciones de filtro de firewall configuradas se realiza mediante las propiedades de interfaz de capa 2.
Tunelización unidireccional
Los túneles L2TP basados en filtros en las redes IPv4 son unidireccionales. Solo transportan paquetes de tránsito y no requieren interfaces de túnel. Aunque puede aplicar filtros de firewall a direcciones de circuito cerrado, las acciones de filtro de firewall de encapsulación y desencapsulación de GRE no se admiten en las interfaces de circuito cerrado del enrutador. Las operaciones de encapsulación y desencapsulación iniciadas por filtro de paquetes L2TP se ejecutan en motores de reenvío de paquetes para interfaces lógicas Ethernet e interfaces Ethernet agregadas. Este diseño permite un uso más eficiente del ancho de banda del motor de reenvío de paquetes en comparación con la tunelización GRE mediante interfaces de túnel. Las sesiones del protocolo de enrutamiento no se pueden configurar sobre los túneles basados en firewall.
Seguridad de túnel
La tunelización basada en filtros a través de redes IPv4 no está cifrada. Si necesita tunelización segura, debe usar el cifrado de seguridad IP (IPsec), que no se admite en interfaces MIC o MPC. Sin embargo, las interfaces multiservicios DPC (MS-DPC) en enrutadores MX240, MX480 y MX960 admiten herramientas IPsec para configurar asociaciones de seguridad (SA) manuales o dinámicas para el cifrado del tráfico de datos, así como del tráfico destinado u originado en el motor de enrutamiento.
Rendimiento de reenvío
La tunelización basada en filtros a través de redes IPv4 permite un uso más eficiente del ancho de banda del motor de reenvío de paquetes en comparación con la tunelización L2TP mediante interfaces de túnel. La encapsulación, la desencapsulación y la búsqueda de rutas son actividades de procesamiento de encabezados de paquetes que, para la tunelización basada en filtros de firewall, se realizan en el motor de reenvío de paquetes basado en el chipset Junos Trio. En consecuencia, el encapsulador nunca necesita enviar paquetes de carga a una interfaz de túnel independiente (que podría residir en una PIC en una ranura diferente a la interfaz que recibe los paquetes de carga).
Escalabilidad del reenvío
El reenvío de tráfico L2TP con interfaces de túnel requiere que el tráfico se envíe a una ranura que aloje las interfaces de túnel. Cuando se utilizan interfaces de túnel para reenviar tráfico GRE, este requisito limita la cantidad de tráfico que se puede reenviar por dirección de destino de túnel GRE. Por ejemplo, supongamos que desea enviar 100 Gbps de tráfico L2TP del enrutador A al enrutador B y solo tiene interfaces de 10 Gbps. Para asegurarse de que la configuración no encapsula todo el tráfico de la misma placa que va a la misma interfaz de 10 Gbps, debe distribuir el tráfico entre varios puntos de encapsulación.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.