En la sección anterior, analizamos cómo las VPN iniciadas por el cliente pueden permitir que los empleados móviles de las empresas pasen por el "agujero de gusano", al igual que el Profesor Du, y accedan libremente a la red HQ. Sin embargo, los usuarios que se encuentran en sucursales no son tan afortunados, y generalmente usan una red de acceso telefónico para conectarse a Internet. Frente al vasto océano de Internet, y al no poder encontrar la entrada al "agujero de gusano", solo pueden mirar este océano y suspirar tristemente. Incluso si su red de acceso telefónico ha evolucionado a Ethernet, esto solo resuelve el problema de la conexión a Internet local, pero aún no pueden acceder a la red HQ. ¿Significa esto que los usuarios de sucursales están destinados a estar separados para siempre de la red HQ?
Afortunadamente, la llegada de los LAC a la escena de la red ha ayudado a las sucursales a resolver este problema. El LAC sirve como un servidor PPPoE, y un usuario de las sucursales, como el cliente PPPoE, puede establecer una conexión PPPoE con el LAC, permitiendo que PPP se use libremente en Ethernet. Además, como un "agente" para el LNS, el LAC proporciona una entrada "agujero de gusano" para las sucursales, lo que significa que los usuarios de las sucursales pueden usar el LAC como un portal para llegar a la red de HQ.
El LAC también se denomina NAS en VPDN, por lo que este tipo de VPN L2TP también se denomina “VPN iniciado por NAS”. Esto sería más fácil de entender si el nombre "VPN iniciado por NAS" se cambiara por "VPN iniciado por LAC", porque en nuestras representaciones de organización de red se muestra claramente el nombre LAC, pero todavía tenemos que usar este ahora descartado " nombre anterior ", que puede ser un poco confuso para los recién llegados.
El proceso de construcción de una VPN iniciada por NAS es un poco complicado, y para ayudar a recordar esto, dibujé una figura simple (Figura 1-1), para ayudarlo a comprender mejor lo siguiente.
Figura 1-1 Proceso para establecer una VPN iniciada por NAS.
Para revisar nuestra comprensión de PPPoE, hemos utilizado un firewall como cliente PPPoE, mientras que en la Figura 1-2 se muestra el cliente PPPoE de una PC virtual.
Figura 1-2 Esquema de la red VPN iniciada por NAS.
Un punto clave a recordar es que las conexiones entre el cliente PPPoE, el LAC, el LNS y el servidor interno son conexiones directas, lo que elimina la necesidad de configurar el enrutamiento; la autenticación del usuario también utiliza la autenticación local, que es relativamente simple. Además, el servidor interno debe configurar una puerta de enlace (gateway) para garantizar que los paquetes que proporciona al cliente PPPoE en respuesta puedan enviarse al LNS.
1 Paso: Establecer una conexión PPPoE: la interfaz de marcación marca la interfaz VT
Después de que PPP cambió a PPPoE para que pudiera establecerse en el "mundo" de Ethernet, a fin de simular el proceso de acceso telefónico a PPP en Ethernet, PPPoE inventó dos interfaces virtuales: la interfaz del marcador y la interfaz VT. Cuando PPPoE se ejecuta en un servidor de seguridad, estas dos interfaces también se utilizan: cuando un servidor de seguridad funciona como el cliente PPPoE utiliza la interfaz del marcador, y cuando un servidor de seguridad actúa como servidor PPPoE, utiliza la interfaz VT. Los parámetros PPPoE relacionados se configuran en estas dos interfaces, como se muestra en la Tabla 1-1.
Tabla 1-1 Configuración de un PPPoE de VPN iniciado por NAS.
Cliente PPPoE | Servidor PPPoE (LAC) |
interface dialer 1 dialer user user1 dialer-group 1 dialer bundle 1 ip address ppp-negotiate //Configures the negotiation mode, so that IP addresses are dynamically assigned. ppp chap user user1 //Indicates the PPPoE client's user name. ppp chap password cipher Password1 //Indicates the PPPoE client's password. dialer-rule 1 ip permit interface GigabitEthernet0/0/1 pppoe-client dial-bundle-number 1 //Enables the PPPoE client on the physical interface and binds dial-bundle. | interface Virtual-Template 1 ppp authentication-mode chap interface GigabitEthernet 0/0/1 pppoe-server bind virtual-template 1 //Enables the PPPoE server on the physical interface and binds the VT interface. aaa local-user user1 password Password1 local-user user1 service-type ppp |
La interfaz VT en el servidor PPPoE (LAC) solo completa el trabajo PPPoE, proporcionando funciones de autenticación PPP para el servidor PPPoE, pero no contiene una función para la cooperación con L2TP.
En L2TP, todas las direcciones IP de los usuarios están asignadas de manera uniforme por HQ (el servidor LNS o AAA), por lo que no es necesario configurar un conjunto de direcciones en el LAC (incluso si un conjunto de direcciones está configurado, siempre que el túnel L2TP ya este establecido, el grupo de direcciones HQ se usará preferentemente para la asignación de direcciones), pero la marcación PPPoE ordinaria necesita un grupo de direcciones para configurarse en el servidor PPPoE.
Podemos usar la siguiente captura de paquetes para analizar el proceso de establecer una conexión PPPoE.
El proceso de negociación en el paso de descubrimiento de PPPoE es bastante importante. Como se muestra en la Tabla 1-2, el cliente PPPoE y el servidor PPPoE intercambian paquetes PADI, PADO, PADR y PADS para confirmar la dirección Ethernet de cada uno y el ID de sesión PPPoE.
Tabla 1-2 Proceso de negociación en la etapa de descubrimiento PPPoE.
Step 1 PADI | PPPoE Cliente: Atencion, me quiero conectar a PPPoE, quien vendrá a ayudarme? | |
Step 2 PADO | PPPoE Server: Cliente PPPoE, búscame, yo te ayudare. | 
|
Step 3 PADR | PPPoE Client: Excelente PPPoE server, quisiera establecer una sesión PPPoE contigo. | 
|
Step 4 PADS | PPPoE Server: Perfecto, te voy a mandar la session ID a ti, y podemos simplemente usar ese ID para establecer una sesion PPPoE. |  |
Luego, después de la negociación PPP LCP y la autenticación PPP CHAP, se establece la conexión PPPoE.
2 Paso: Establecimiento del túnel L2TP: tres piezas de información para negociar la entrada al agujero de gusano
Veamos primero la configuración específica de LAC y LNS, como se muestra en la Tabla 1-3.
Tabla 1-3 Configurando el L2TP de la VPN iniciada po NAS
LAC | LNS |
l2tp enable l2tp-group 1 tunnel authentication //Avoids counterfeit LACs from connecting to the LNS. tunnel password cipher Password1 tunnel name lac start l2tp ip 1.1.1.2 fullusername user1 //Designates the address of the other tunnel terminal. | l2tp enable interface Virtual-Template 1 ppp authentication-mode chap ip address 172.16.0.1 255.255.255.0 remote address pool 1 l2tp-group 1 tunnel authentication //Avoids counterfeit LACs from connecting to the LNS. tunnel password cipher Password1 allow l2tp virtual-template 1 remote lac //Designates the VT interface and allows a remote LAC connection. aaa local-user user1 password Password1 local-user user1 service-type ppp ip pool 1 172.16.0.2 172.16.0.100 |
El LAC y el LNS intercambian tres datos en la negociación del túnel L2TP. Ya hemos cubierto este proceso en "5.4 VPN iniciadas por el cliente L2TP" y lo revisaremos nuevamente aquí. Vea la información de captura de paquetes a continuación:
El proceso de negociación de ID de túnel se muestra en la Tabla 1-4.
Tabla 1-4 Proceso de negociación de ID de túnel.
Paso 1 SCCRQ | LAC: LNS, usa "1" como el Tunnel ID para comunicarse conmigo. |
|
Paso 2 SCCRP | LNS: OK. LAC, sersiorate de que tambien estes usando el ID 1 para comunicarte conmigo. |
|
Paso 3 SCCCN | LAC: OK. | - |
3 Paso: Establecimiento de una sesión L2TP: tres elementos de información para despertar al agujero de gusano gatekeeper.
El LAC y el LNS intercambian tres datos para negociar un ID de sesión y establecer una sesión L2TP. Igualmente revisaremos este proceso nuevamente. Vea la captura de paquetes a continuación:
La tabla 1-5 proporciona el proceso de negociación de ID de sesión.
Tabla 1-5 Proceso de negociación de ID de sesión
Paso 1 ICRQ | LAC: LNS, usa 4 como el session ID para comunicarse conmigo. | |
Paso 2 ICRP | LNS: OK, LAC, solo asegúrate de que también uses el 4 como session ID para comunicarte conmigo. |
|
Paso 3 ICCN | LAC: OK. | - |
4 Paso: Autenticación de LNS y asignación de direcciones IP: el LNS acepta con severidad el LAC
1. Autenticación LNS y autenticación secundaria (opcional)
El LAC envía información de usuario al LNS para la autenticación. Sin embargo, el LNS entiende muy bien que el LAC es solo un "agente", y el LNS puede adoptar una de las tres actitudes hacia esto:
Autenticación del agente de LAC: el LNS no confía en que el LAC sea confiable y lleve a cabo directamente la autenticación de la información del usuario enviada por el LAC.
Exigir la autenticación CHAP obligatoria: el LNS no confía en el LAC y requiere que se realice una "inspección de calificación" nuevamente del usuario (imponer la nueva autenticación CHAP del usuario).
Re-negociación de LCP: el LNS no solo no confía en el LAC, sino que también expresa su insatisfacción con el "contrato de servicio" que anteriormente se firmó, y requiere que el usuario vuelva a "negociar servicios" (reinicie la negociación de LCP, y negociar parámetros MRU y métodos de autenticación).
Los dos últimos métodos se denominan conjuntamente autenticación secundaria LNS. Si el LNS está configurado para la autenticación secundaria pero el cliente PPPoE no admite la autenticación secundaria, esto significa que no se puede establecer la VPN L2TP. El punto común entre estas dos autenticaciones secundarias es que el LNS bordea el LAC y realiza la verificación directa de la información del usuario provista por el cliente PPPoE, lo que brinda mayor protección de seguridad para los servicios VPN. Los métodos de configuración para los tres tipos de métodos de autenticación se muestran en la Tabla 1-6.
Tabla 1-6 Configuración de una autenticación LNS de VPN iniciada por NAS.
Authentication Method | Configuration Method | Packet Capture Analysis |
Autenticación proxy del LAC★ | Default, no se necesita configurar. |
El LNS autentica directamente la información del usuario enviada por el LAC, y si la autenticación es exitosa, se establece una conexión PPP. |
Autenticación CHAP obligatoria. ★★ | l2tp-group 1 mandatory-chap |
El LNS vuelve a conducir la autenticación CHAP del usuario. El LNS envía un challenge, el cliente PPPoE usa el challenge para enviar el nombre de usuario y la contraseña cifrada al LNS, y una vez que el LNS autentica esto, se establece con éxito una conexión PPP. |
Renegociación LCP. ★★★ | interface virtual-template 1 ppp authentication-mode chap // Designa el modo de autenticación después de la renegociación l2tp-group 1 mandatory-lcp |
El LNS reinicia la negociación del LCP, negocia los parámetros de MRU y un método de autenticación, y luego lleva a cabo la autenticación CHAP. Después de una negociación exitosa, se establece una conexión PPP. |
★ Representa el grado de excelencia; La configuración de la renegociación de LCP es el más preferible de estos tres métodos. | ||
2. Asignación de direcciones IP
El LNS asigna una dirección IP para el cliente PPPoE a través de la negociación IPCP PPP.
Revisamos anteriormente el problema de planificación de direcciones del grupo de direcciones en la sección "VPN iniciadas por el cliente", y puede regresar y revisar esto si lo desea.
Resumamos las características de las VPN iniciadas por NAS:
Como se muestra en la Figura 1-3, en las VPN iniciadas por NAS, se pueden establecer múltiples túneles entre un par LNS-LAC (uno se construye para cada grupo L2TP), y cada túnel puede llevar varias sesiones. Esto significa que cada LAC puede llevar sesiones para todos los usuarios de acceso telefónico de la sucursal a la que pertenece. Por ejemplo, la conexión PPP 1 y la sesión L2TP 1 se establecen entre el usuario de acceso 1 y el LNS, y la conexión PPP 2 y la sesión L2TP 2 se establecen entre el usuario de acceso 2 y el LNS. Cuando un usuario marca, esto activa el establecimiento de un túnel entre el LAC y el LNS. Mientras este usuario no se desconecte, cuando otros usuarios ingresen, establecerán sesiones en el túnel existente en lugar de volver a activar el establecimiento del túnel.
Figura 1-3 Relación entre un túnel L2TP y una sesión con la conexión PPP en una VPN iniciada por NAS.
5 Paso: Transmisión de encapsulación de datos: comunicación sin obstáculos.
Después de que los paquetes del cliente PPPoE vinculados al servidor HQ alcancen el LAC, el LAC proporciona a los paquetes tres capas de "alter-egos", que son el encabezado L2TP, el encabezado UDP y el encabezado IP de la red pública, y luego los envía al LNS. Después de que el LNS recibe los paquetes, elimina estas tres capas de "alter-egos" y luego envía el paquete al servidor interno.
La Figura 1-4 muestra el proceso de encapsulación y desencapsulación de paquetes en un
escenario VPN iniciado por NAS.
Figura 1-4 Proceso de encapsulación de paquetes VPN iniciado por NAS.
Al igual que con las VPN iniciadas por el cliente, en los escenarios de VPN iniciadas por el NAS, el LNS también emitirá automáticamente una ruta de host (ruta UNR) para el cliente PPPoE que obtuvo la dirección IP de la red privada, y usará esto para guiar los paquetes de devolución desde el servidor interno enlazado para el cliente PPPoE en el túnel.
6 Enfoque a la configuración de la política de seguridad
La configuración de la política de seguridad de VPN iniciada por NAS es un poco más problemática que para las VPN iniciadas por el cliente, ya que tanto el LAC como el LNS deben configurarse. Sin embargo, el enfoque de configuración es similar.
Como se muestra en la Figura 1-5, en nuestro escenario hipotético, el GE0 / 0/2 de LAC está conectado a Internet y pertenece a la zona Untrust. En el LNS, GE0 / 0/1 está conectado a la red privada y pertenece a la zona Trust; GE0 / 0/2 está conectado a Internet y pertenece a la zona Untrust; la interfaz VT pertenece a la zona DMZ; La dirección IP asignada por el LNS para el cliente PPPoE es 172.16.0.2.
Figura 1-5 Organización de red para la configuración de la política de seguridad
de VPN en una VPN iniciada por NAS.
El proceso de configuración de la política de seguridad es el siguiente:
1. Primero configuramos la política de seguridad interzonal para que sea lo más amplia posible, para ayudar en el ajuste / prueba de VPN L2TP.
La acción de filtrado de paquetes predeterminada de la zona intermedia de LAC está configurada para "permitir":
[LAC] firewall packet-filter default permit all
La acción de filtrado de paquetes por defecto de la zona intermedia de la LNS también se establece en "permitir":
[LNS] firewall packet-filter default permit all
Después de que tanto LAC como LNS hayan configurado L2TP, hacemos ping al servidor interno con el cliente PPPoE y luego observamos las tablas de sesión de LAC y LNS.
Mesa de sesiones LAC
[LAC] display firewall session table verbose
Current Total Sessions : 1
l2tp VPN:public --> public
Zone: local--> untrust TTL: 00:02:00 Left: 00:01:52
Interface: GigabitEthernet0/0/2 NextHop: 1.1.1.2 MAC: 00-00-00-53-62-00
<--packets:26 bytes:1655 -->packets:11 bytes:900
1.1.1.1:60416-->1.1.1.2:1701
El contenido de la tabla de sesión proporciona la dirección de los paquetes en el LAC, como se muestra en la Figura 1-6.
Figura 1-6 Dirección del paquete LAC.
No hay sesión de ICMP en el LAC, solo la sesión de L2TP. Por lo tanto, es necesario configurar una política de seguridad Local -> Untrust en el LAC que permita a LAC y LNS construir un túnel L2TP. Además, los paquetes del cliente PPPoE que acceden al servidor interno primero se encapsularán en paquetes PPPoE, luego se encapsularán directamente en paquetes L2TP cuando el LAC reciba el paquete PPPoE, y finalmente ingresen al túnel L2TP, por lo que no están controlados por la política de seguridad . Por lo tanto, solo es necesario configurar una política de seguridad Local -> Untrust en el LAC.
Mesa de sesiones LNS.
[LNS] display firewall session table verbose
Current Total Sessions : 2
l2tp VPN:public --> public
Zone: untrust--> local TTL: 00:02:00 Left: 00:01:52
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:18 bytes:987 -->packets:23 bytes:2057
1.1.1.1:60416-->1.1.1.2:1701
icmp VPN:public --> public
Zone: dmz--> trust TTL: 00:00:20 Left: 00:00:00
Interface: GigabitEthernet0/0/1 NextHop: 192.168.0.2 MAC: 54-89-98-62-32-60
<--packets:4 bytes:336 -->packets:5 bytes:420
172.16.0.2:52651-->192.168.0.2:2048
Hay dos sesiones en el LNS: una sesión L2TP y una sesión ICMP. El contenido de la tabla de sesión proporciona la dirección de los paquetes en el LNS, como se muestra en la Figura 1-7.
Figura 1-7 Dirección del paquete LNS.
La figura anterior muestra que se debe configurar una política de seguridad de DMZ -> Trust en el LNS que permita que los paquetes de clientes PPPoE que buscan acceso al servidor interno pasen; un Untrust -> La política de seguridad local que permite a LAC y LNS construir un túnel L2TP también debe configurarse.
Una vez que se establece el túnel L2TP, cuando el servidor interno inicia una llamada en el cliente PPPoE, la dirección del paquete es la opuesta a cuando el cliente PPPoE accede al servidor, y no hay necesidad de más detalles sobre esto.
Para resumir, las políticas de seguridad que deben configurarse en el LAC y LNS en diversas condiciones se muestran en la Tabla 1-7, y debemos configurar las políticas de seguridad que mejor se ajusten a las condiciones existentes.
Tabla 1-7 Selección de políticas de seguridad para LAC y LNS según las condiciones.
Dirección de transacción | Equipo | Zona de Seguridad de Origen | Zona de Seguridad de destino. | Dirección origen. | Dirección destino. | Utilizado en |
PPPoE client accede al server | LAC | Local | Untrust | 1.1.1.1/32 | 1.1.1.2/32 | L2TP |
LNS | Untrust | Local | 1.1.1.1/32 | 1.1.1.2/32 | L2TP | |
DMZ | Trust | 172.16.0.2~172.16.0.100 address pool addresses | 192.168.0.0/24 | * | ||
El server accede al PPPoE client | LNS | Trust | DMZ | 192.168.0.0/24 | 172.16.0.2~172.16.0.100 address pool addresses | * |
*: El uso en esta instancia está relacionado con el tipo de transacción y se puede configurar de acuerdo con las circunstancias reales (por ejemplo: TCP, UDP, and ICMP). | ||||||
NOTA:
En este escenario, el LNS solo acepta pasivamente la solicitud del LAC para establecer el túnel, pero no iniciará activamente una solicitud al LAC para establecer el túnel, por lo que solo se debe configurar una política de seguridad local Untrust -> Local en el LNS para El túnel L2TP.
Por lo tanto, en las VPN L2TP que utilizan el método iniciado por NAS, la interfaz VT de LNS debe agregarse a una zona de seguridad, y la zona de seguridad a la que pertenece la interfaz VT determina la dirección del paquete dentro del dispositivo. Si la interfaz VT pertenece a la zona Trust, no es necesario configurar una política de seguridad entre zonas DMZ-Trust, pero esto también conllevará riesgos de seguridad adicionales. Por lo tanto, es recomendable agregar la interfaz VT a una zona de seguridad separada y luego configurar la política de seguridad más adecuada.
3. Finalmente, la acción del filtro de paquetes predeterminado se cambia a "denegar".
Establezca la acción de filtrado de paquetes predeterminada de la zona intermedia de LAC en "denegar":
[LAC] firewall packet-filter default deny all.
Establezca la acción de filtrado de paquetes predeterminada de la zona intermedia de LNS en "denegar":
[LNS] firewall packet-filter default deny all.
En las VPN iniciadas por NAS, el usuario de la organización de sucursal debe marcar antes de usar la VPN L2TP, y los paquetes también deben encapsularse en PPPoE, que es un problema demasiado grande. Además, las redes de acceso telefónico están desapareciendo gradualmente, y Ethernet se está convirtiendo en la corriente principal.
¿Esto significa que los usuarios de organizaciones de sucursales no pueden acceder a la red HQ directamente en Ethernet? Por supuesto que pueden. El deseo de la humanidad de reducir el trabajo es el verdadero impulsor de los avances en ciencia y tecnología, y en la siguiente sección presentaré las VPN iniciadas automáticamente por LAC para todos, en las que LAC marca automáticamente el LNS, eliminando el proceso de acceso telefónico para empleados de la organización de sucursales: esto se conoce como la VPN L2TP que implica el menor trabajo.
