Descripción general de la tunelización L2TP basada en filtros de firewall en redes IPv4
El protocolo de tunelización de capa 2 (L2TP) es un protocolo cliente-servidor que permite que el protocolo punto a punto (PPP) se tuneliza a través de una red. L2TP encapsula paquetes de capa 2, como PPP, para la 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 tunelización de varias conexiones de capa 2 entre dos nodos IPv6. Las diferencias significativas entre L2TPv2 y L2TPv3 incluyen las siguientes:
Separación de todos los AVP y referencias relacionados con PPP, lo que permite la inclusión de una parte del encabezado de datos L2TP que era específica para las necesidades de PPP.
Haga la 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 se admite para IPv6.
En el caso de los filtros de firewall, solo se admite la encapsulación/descapsulación del plano de datos L2TPv3.
L2TP se compone de dos tipos de mensajes, mensajes de control y mensajes de datos (a veces conocidos como paquetes de control y paquetes de datos respectivamente). Los mensajes de control se utilizan en el establecimiento, el mantenimiento y la eliminación 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 el uso de mecanismos de protocolo de tunelización GRE iniciados por dos acciones estándar de filtro de firewall. Esta característica también se admite en sistemas lógicos. Cuando configure la tunelización L2TP con filtros de firewall, no es necesario crear interfaces de túnel en tarjetas de interfaz físicas (PIC) de servicios de túnel ni en concentradores de puerto modular (MPC3E). En su lugar, los motores de reenvío de paquetes proporcionan servicios de túnel a interfaces lógicas de Ethernet o interfaces de Ethernet agregadas alojadas en tarjetas de interfaz modulares (MIC) o MPC en plataformas de enrutamiento universal de 5G serie MX.
Dos enrutadores de la serie MX instalados como enrutadores de borde de proveedor (PE) proporcionan conectividad a los enrutadores de borde del cliente (CE) en dos redes desarticuladas. Las interfaces MIC o MPC en los enrutadores de PE realizan la encapsulación L2TP IPv4 y la desencapsulación de cargas. Después de la descapsulació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 decapsulate l2tp output-interface interface-name cookie l2tpv3-cookie instrucción en el [edit firewall family family-name filter filter-name term term-name then] nivel de jerarquía.
Durante la descapsulación, el encabezado interno debe ser Ethernet para túneles L2TP. La clase de reenvío de forma predeterminada se aplica antes del firewall y no se conserva para el paquete desencapsulado (mediante el uso de la forwarding-class class-name instrucción en el [edit firewall family family-name] nivel de jerarquía, que es una acción de filtro nominante). Sin embargo, puede especificar la clase de reenvío en la que se debe clasificar el paquete incluyendo la acción de filtro para un paquete desencapsulado mediante la decapsulate l2tp forwarding-class class-name instrucción en el [edit firewall family family-name filter filter-name term term-name then] nivel de jerarquía.
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 que no es cero para una sesión. Las sesiones L2TP se denominan mediante identificadores que solo tienen significación local. La misma sesión lógica recibirá diferentes identificaciones de sesión por cada extremo de la conexión de control durante la vida útil 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 AAV del 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, incluyendo 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 está tunelizando.
El campo Cookie opcional contiene un valor de longitud variable (máximo 64 bits) utilizado 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ñaldo para esta sesión. La cookie ofrece un nivel adicional de garantía de que el ID de sesión ha dirigido un mensaje de datos a la sesión adecuada. Una cookie bien elegida podría evitar la desviación involuntaria de paquetes aleatorios con los identificaciones de sesión reutilizadas recientemente o para los de sesión sujetos a daños en los 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, los valores aleatorios de la cookie se seleccionan e intercambian como AVPs de cookie asignados durante la creación de la sesión.
Una sesión es una conexión lógica creada entre la LAC y las LNS cuando se establece una conexión PPP de extremo a extremo entre un sistema remoto y las LNS. Hay una relación uno a uno entre las sesiones de 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 y acciones especificadas de coincidencia de filtro de firewall estándar se realiza mediante una búsqueda de capa 3. En la versión 14.2 y anteriores de Junos OS, la descapsulació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 filtros 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 de protocolo de enrutamiento no se pueden configurar sobre los túneles basados en firewall.
Seguridad de túnel
La tunelización basada en filtros en redes IPv4 no está cifrada. Si requiere una tunelización segura, debe usar cifrado de seguridad IP (IPsec), que no se admite en interfaces MIC o MPC. Sin embargo, las interfaces DPC de varios servicios (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 el tráfico destinado a u originado en el motor de enrutamiento.
Rendimiento del reenvío
La tunelización basada en filtros en 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 paquetes de carga).
Escalabilidad de 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 hospede las interfaces de túnel. Cuando utiliza 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 del túnel GRE. Como ejemplo, supongamos que desea enviar 100 Gbps de tráfico L2TP desde el enrutador A al enrutador B y solo tiene interfaces de 10 Gbps. Para asegurarse de que su configuración no encapsula todo el tráfico de la misma tarjeta que va a la misma interfaz de 10 Gbps, debe distribuir el tráfico en varios puntos de encapsulación.