De manera similar a la política IPSec de IKE, la política IPSec de plantilla también debe confiar en un túnel IPSec negociado IKE. La mejora más importante que viene con la política de IPSec de la plantilla es que no requiere direcciones IP pares fijas: una dirección IP igual puede ser estrictamente designada (IP única), designada en forma amplia (segmento de dirección IP) o simplemente no designada (es decir, la IP igual) puede ser cualquier IP).
La plantilla de política IPSec es como un general valiente, que no deja una IP igual detrás de las líneas enemigas; Fijo, dinámico, privado ... todos son bienvenidos a unirse a las filas. Es precisamente debido a este comportamiento que la plantilla de politica IPSec es adecuada para los hosts de Tiandihui porque les permite responder a una multitud de solicitudes de negociación de sub hostes. Los beneficios se vuelven cada vez más obvios a medida que las filas de los sub host comienzan a aumentar:
Se utiliza la política IPSec IKE. Los hosts deben configurar un número n de políticas IPSec y pares IKE, donde n es igual al número de sub-hosts.
l Se utiliza la política IPSec IKE. Los hosts deben configurar un número n de políticas IPSec y pares IKE, donde n es igual al número de sub-hosts.
l Plantilla IPSec se utiliza la política. Los hosts solo necesitan configurar una política IPSec y un igual IKE, independientemente de n.
En conclusión, las dos ventajas principales de la política IPSec de la plantilla aseguran su boleto para el "Hall of Fame" de IPSec:
l Para raras veces las solicitudes de inicio, las IP públicas no fijas están bien
l Configuración simple; solo se necesita un par IKE
Sin embargo, incluso las estrellas tienen sus propias dificultades tácitas; Las políticas de IPSec de plantilla solo pueden responder a solicitudes de negociación iniciadas por pares y no pueden iniciar negociaciones de forma activa.
1 Aplicaciones de red punto a multipunto
Como se muestra en la Figura 1-1, las interfaces del sub-host 1 y del sub-host 2 utilizan el método dinámico de recuperación de direcciones IP públicas. Se deben establecer túneles IPSec respectivos entre el host secundario 1 y el host y el host secundario 2 y el host. Además, el host secundario 1 y el host secundario 2 también pueden comunicarse a través de la VPN IPSec.
Figura 1-1 Red punto a multipunto IPSec VPN
La lógica detrás de la configuración de la plantilla de política IPSec es la que se muestra en la Figura 1-2.
Figura 1-2 Esquema de la configuración de la plantilla de política IPSec
La configuración de la política IPSec de la plantilla se muestra en la Tabla 1-1. No volveremos a revisar las configuraciones predeterminadas de las propuestas IKE e IPSec. La configuración del host secundario 2 es similar a la del host secundario 1. Simplemente consulte la configuración del host secundario 1.
Tabla 1-1 configuración de la plantilla VPN IPSec
Configuracion | Host FW_A (con política IPSec de plantilla) | Sub-Host 1 FW_B (con política IPSec de plantilla) |
IKE propuesta de configuración | ike proposal 10 | ike proposal 10 |
IKE Configuración Peer | ike peer a ike-proposal 10 pre-shared-key tiandihui1 //can forego remote-address configuration; the remote-address can also be used to designate the IP address segment. | ike peer a ike-proposal 10 remote-address 1.1.1.1 pre-shared-key tiandihui1 |
ACL | acl number 3000 rule 5 permit ip destination 172.16.1.0 0.0.0.255 rule 10 permit ip destination 172.16.2.0 0.0.0.255 | acl number 3000 rule 5 permit ip source 172.16.1.0 0.0.0.255 |
IPSec Proposal | IPSec proposal a | IPSec proposal a |
Politica IPSec | IPSec policy-template tem1 1 //configuration IPSec policy template security acl 3000 proposal a ike-peer a IPSec policy policy1 12 isakmp template tem1//configuration template IPSec policy | IPSec policy policy1 1 isakmp security acl 3000 proposal a ike-peer a |
Aplicación de politica IPSec | interface GigabitEthernet0/0/2 ip address 1.1.1.1 255.255.255.0 IPSec policy policy1 | interface GigabitEthernet0/0/2 ip address 2.2.2.2 255.255.255.0 IPSec policy policy1 auto-neg //once auto-neg is configured, traffic trigger is not needed; IPSec tunnel is established directly. |
Ruta | Configuración de ruta requerida para cada red privada de intercambio de visitas. | Configuración de ruta requerida para cada red privada de intercambio de visitas. |
La configuración anterior tiene dos diferencias con el método IKE estándar; nota lo siguiente:
· Host FW utiliza la política IPSec plantilla.
La política de IPSec de la plantilla no requiere que los compañeros de IKE configuren direcciones remotas; o las direcciones remotas se pueden usar para designar segmentos de direcciones IP.
En 32.IKEv1 "Fase 1: Establecimiento de IKE SA (Modo principal)", discutimos los tres usos de direcciones remotas, comandos y direcciones IP designadas. Ahora, consideremos por un momento: si la política IPSec de la plantilla no configura el comando de dirección remota, ¿causará confusión? Incluso si el anfitrión cede sus derechos, no habrá ningún problema:
· Si el host no configura un comando de dirección remota, no habrá una dirección IP de par de túnel designada. En este momento, el host solo puede aceptar el acceso de sub-host activo y no puede realizar la autenticación de sub-host ni puede acceder activamente al sub-host.
· Si el host utiliza una dirección remota para designar el segmento de la dirección IP del interlocutor del túnel, el host puede verificar si el ID del dispositivo sub-host (dirección IP) está contenido en el segmento de la dirección IP; solo se aceptarán solicitudes cuando el ID esté de hecho dentro del segmento. Incluso en este momento, el host aún no puede acceder activamente al sub-host.
De los dos puntos anteriores se puede ver que la política de IPSec de la plantilla parece permitir que los hosts superen el problema de los pares "sin IP fija" y "sin IP pública". Pero, de hecho, esto solo se logra cuando el anfitrión cede activamente dos derechos.
· Configuración de ACL es específica; Con más sub-hosts, la configuración de ACL del host se vuelve más complicada. Los requisitos de ACL de FW_A del host incluyen dos reglas:
o Para permitir que el sub-host 2 y el host FW accedan al sub-host 1 FW, la fuente debe incluir el sub-host 2 y el segmento de red del host, y el destino debe ser el segmento de red del sub-host 1. En este caso, la fuente no está designada, lo que significa que la fuente puede ser el host secundario 2 o el host u otro segmento de dirección IP.
o Para permitir que el sub-host 1 y el host FW accedan al sub-host 2, la fuente debe incluir el sub-host 1 y el segmento de red del host, y el destino debe ser el segmento de red del sub-host 2. En este caso, no hay una fuente designada, lo que significa que la fuente puede ser un host secundario 1 o el host u otro segmento de dirección IP.
· Sub-host FW requisito de ACL:
Para permitir que el FW del host secundario 1 tenga acceso al host secundario 2 y los FW del host, la fuente debe ser el segmento de red del host secundario 1, y el destino debe ser el segmento secundario 2 y los segmentos de red del host. En este caso, no hay un destino designado, lo que significa que la fuente puede ser el host secundario 2 o el host u otro segmento de dirección IP.
La autenticación se realiza cuando la configuración está completa:
1. En el host FW_A, las SA de primera y segunda fase se establecen normalmente entre el host y el sub-host 1 y los sub-host 2 FW.
2. El subhost 1, el subhost 2 y el host pueden comunicarse de un lado a otro.
Pregunta: Si los parámetros de negación automática no están configurados en la política IPSec de la interfaz FW_B, ¿pueden comunicarse directamente el host secundario 1 y el host secundario 2?
3. Una vez que las políticas de IPSec se cancelan en los FW del host secundario 1 y del host secundario 2, cuando se vuelven a aplicar, los parámetros de negación automática no están configurados. Si la PC_B del host secundario 1 hace ping a la PC_C del host secundario 2, el ping no se realizará.
4. Verifique el estado del sub-host 1 FW_B's SA.
<FW_B> display ike sa
current ike sa number: 2
-------------------------------------------------------------------------
conn-id peer flag phase vpn
-------------------------------------------------------------------------
40022 1.1.1.1 RD|ST v2: 2 public
7 1.1.1.1 RD|ST v2: 1 public
La SA establecida entre el host secundario 1 y el host es normal.
5. Verifique el estado del sub-host 2 FW_ C's SA.
<FW_C> display ike sa
current sa Num: 0
No hay SA establecida entre el host secundario 2 y el host FW. Esto se debe a que el host FW configuró la política IPSec de la plantilla y solo puede responder a las negociaciones. Como tal, el sub-host 1 creó una SA normal con el FW del host, pero el host no puede establecer una SA con el FW del sub-host 2. Una vez que los parámetros de negación automática se configuran en la política de IPSec aplicada por los FW de host secundario 1 y host secundario 2, se creará automáticamente el SA de IPSec. Debido a que los SA ya están implementados desde el host secundario 1 al host FW y el host al host host 2 FW, el host secundario 1 puede comunicarse con el host secundario 2. Del mismo modo, el anfitrión puede enviar pings al servidor secundario. Hospedadores.
En este punto, ya hemos introducido tres políticas IPSec diferentes: la política IPSec manual, la política IPSec IKE y la política IPSec de plantilla. Las tres políticas IPSec se pueden configurar en un solo grupo de políticas IPSec. Este llamado grupo de políticas IPSec es un grupo de políticas IPSec con el mismo nombre. A lo sumo, solo puede haber una plantilla IPSec en un solo grupo de políticas IPSec, cuyo número de serie también debe ser el más grande, establecido en prioridad mínima. De lo contrario, la política de IPSec de la plantilla recibirá primero la solicitud de acceso; las políticas de IKE IPSec de baja prioridad no tendrán ninguna manera de mostrar su talento.
Tanto la plantilla como las políticas de IKE IPSec deben negociar los túneles IPSec con IKE. El proceso de negociación es el mismo, y no es necesario que el Dr. WoW lo repita de nuevo. A continuación, centraremos nuestra discusión en las "características" de la política IPSec de la plantilla.
2 Claves pre compartidas personalizadas (solo firewall USG9500-Series)
Solo se puede citar un par de IKE en la plantilla IPSec. Además, un único IKE Peer solo puede tener una clave precompartida configurada. Como tal, todos los pares interconectados deben configurarse con la misma clave precompartida. Debido a esto, si incluso un solo firewall pierde la clave compartida previamente, la seguridad de todos los demás firewalls se ve comprometida.
Entonces, si un host desea establecer una red interconectada de punto a multipunto con múltiples sub-hosts, ¿pueden los firewalls de sub-host configurar diferentes claves pre-compartidas? Dado que la clave precompartida está asociada con la generación de claves y la autenticación de identidad, la clave precompartida solo debe estar vinculada a la identidad del dispositivo, y la autenticación de identidad se puede realizar con el método de autenticación de clave precompartida para la dirección IP local o nombre del dispositivo. Cuando se utiliza una dirección IP o un nombre de dispositivo para designar una clave precompartida, se puede configurar una "clave precompartida personalizada" para cada servidor de seguridad de host secundario.
· Designación de clave precompartida personalizada a través de la dirección IP del par para cada servidor de seguridad de host secundario
Este método es adecuado para servidores de seguridad de host secundario con direcciones IP fijas. El firewall del host, como la dirección remota y la clave compartida previamente configuradas, se eliminan y cambian globalmente para que cada cortafuegos secundario tenga su propia dirección remota y clave compartida. De esta manera, el método de plantilla puede adelantarse al juego y sortear inteligentemente sus limitaciones.
Tabla 1-2 Designación de clave precompartida personalizada a través de la dirección IP del par
Configuración | Host FW_A | Sub-Host 1 FW_B |
Configuración IKE Peer | ike peer a local-id-type ip ike-proposal 10 | ike peer a local-id-type ip ike-proposal 10 remote-address 1.1.1.1 pre-shared-key tiandihui1 |
Configuración de clave pre compartida personalizada | ike remote-address 2.2.2.2 pre-shared-key tiandihui1 ike remote-address 2.2.3.2 pre-shared-key tiandihui2 | - |
Designación de nombre de clave precompartida a través del dispositivo peer
Cuando el servidor de seguridad de host secundario no tiene una dirección IP fija, el nombre del dispositivo se puede usar para verificar la identidad (como nombre local). En este momento, el servidor de seguridad del host puede configurar globalmente una identificación remota única y una clave precompartida para cada servidor de seguridad de host secundario.
Tabla 1-3 Designación de nombre de clave precompartida personalizada a través del dispositivo peer
Configuración | Host FW_A | sub-host 1 FW_B |
Configuracion IKE Peer | ike peer a local-id-type ip ike-proposal 10 | ike peer a local-id-type fqdn // cuando la autenticación de identidad se realiza a través del nombre del dispositivo, la autenticación local debe configurarse como FQDN o USER-FQDN. ike-proposal 10 remote-address 1.1.1.1 pre-shared-key tiandihui1 |
Configuración nombre Local | - | ike local-name tdhfd1 |
Configuración de clave precompartida personalizada | ike remote-id tdhfd1 pre-shared-key tiandihui1 ike remote-id tdhfd2 pre-shared-key tiandihui2 | - |
NOTA: El host FW_A configurado "ike remote-id" debe ser el mismo que el host secundario 1 FW_B configurado "ike local-name".
3 Uso de Nombre de Dominio Peer Designado
Cuando se accede a un servidor de seguridad de host secundario con una dirección IP dinámica, ¿están atadas las manos de la política IPSec de IKE?
De hecho, también hay un método que puede ayudar a la política IPSec de IKE: cuando la dirección IP del par no es fija, naturalmente, no se puede configurar una dirección remota, pero el host aún puede aprender la dirección IP a través de otros métodos indirectos tal como a través del nombre de dominio. En otras palabras, el host puede usar un dominio remoto designado para reemplazar la dirección remota; El DNS configurado del servidor de seguridad del host secundario obtendrá una relación de asignación entre el nombre de dominio y la dirección IP, y utilizará el DDNS para garantizar que la relación de asignación se actualice constantemente. Por supuesto, los nombres de dominio configurados dinámicamente también se pueden usar con la política IPSec de la plantilla.
Tabla 1-4 Designación de nombre de dominio de igual en igual IKE
Ajustes de Configuración | Host FW_A | Sub-Host 1 FW_B |
Configuración IPSec | Solo cambios en la configuración IKE Peer ike peer a ike-propuesta 10 clave pre- shared-key tiandihui1 dominio remoto www.adcd.3322.org | Sin Cambios |
Configuracion Adicional | - | 1. Iniciar resolución de nombre de dominio dns resolver servidor dns 200.1.1.1 2. Configure DDNS policy // La siguiente configuración requiere contacto con el proveedor de servicios DDNS y debe realizarse de acuerdo con las instrucciones del proveedor de servicios DDNS. ddns policy abc ddns cliente www.adcd.3322.org servidor ddns www.3322.org ddns nombre de usuario abc123 contraseña abc123 3. Apply DDNS policy // dialer port es la interfaz lógica que corresponde a la interfaz ADSL. Esta solución tiene relativamente más aplicaciones para los puertos de acceso telefónico ADSL sub-host; en este caso, la política DDNS del host secundario se aplicará al puerto del marcador. ddns cliente habilitado marcador de interfaz 1 ddns aplicar la política abc |
La limitación de esta solución es que las partes de acceso dinámico deben tener un nombre de dominio fijo y también deben agregar configuraciones de DNS y DDNS, lo cual es un poco complicado. Como tal, no es tan útil como la política IPSec de la plantilla. Utilice este método solo cuando no tenga otra opción.
4 Resumen
Entonces, ¿cuán grande es la política IPSec de la plantilla? En situaciones prácticas, no es solo pelear la batalla, y la guerra solo se puede ganar si la plantilla y las políticas IPSec de IKE trabajan juntas. Su compatibilidad es la que se muestra en la Tabla 1-5.
Tabla 1-5 Política de plantillas IPSec y compatibilidad de políticas IKE IPSec
Escenario | Host FW_A | Sub-Host FW_B |
Dirección IP del host fija + dirección IP del sub-host fija | Política de IKE IPSec o plantilla Política de IPSec | Política IPSec IKE |
Dirección IP del host fija + dirección IP del host secundario asignada dinámicamente | Política de plantilla IPSec o política de IKE IPSec (nombre de dominio de igual designado) | Política IPSec IKE |
Dirección IP del host asignada dinámicamente + dirección IP del host secundario asignada dinámicamente | Política de plantilla IPSec o política de IKE IPSec (nombre de dominio de igual designado) | Política IKE IPSec (nombre de dominio de igual designado) |
|
|
|
La política de IPSec de la plantilla es verdaderamente poderosa, y solo con este escudo en la mano, el FW del host se puede conectar a los FW del sub-host, sin preocuparse, ya sea que estén utilizando direcciones IP públicas, configuración fija o incluso direcciones dinámicas. Sin embargo, después de analizarlo más detenidamente, podemos ver que la política IPSec de la plantilla tiene diferentes enfoques para las direcciones IP públicas y privadas. Cuando el par es una dirección IP privada, la política de IPSec de la plantilla todavía tiene que tomar algunos otros pasos para poner todo en orden.
