IKE para VPN IPsec
Obtenga información sobre IKEv2 para VPN IPsec y su configuración en Junos OS.
Intercambio de claves por Internet versión 2 (IKEv2) es un protocolo de tunelización basado en IPsec. IKEv2 proporciona un canal de comunicación VPN seguro entre dispositivos VPN pares y define la negociación y autenticación para las asociaciones de seguridad (SA) IPsec de una manera protegida.
Use el Explorador de características para confirmar la compatibilidad de la plataforma y el lanzamiento de características específicas.
Revise la Comportamiento solo del respondedor IKEv2 específico de la plataforma sección para obtener notas relacionadas con su plataforma.
Procesamiento de paquetes IKE e IPsec
IKE proporciona administración de túnel para IPsec y autentica a las entidades finales. IKE realiza un intercambio de claves Diffie-Hellman (DH) para generar un túnel IPsec entre los dispositivos de red. Los túneles IPsec generados por IKE se utilizan para cifrar, descifrar y autenticar el tráfico de usuario entre los dispositivos de red en la capa IP.
Procesamiento de paquetes de IKE
Cuando un paquete de texto sin cifrar llega a un dispositivo de Juniper Networks que requiere tunelización y no existe ninguna SA de fase 2 activa para ese túnel, Junos OS comienza las negociaciones de IKE y descarta el paquete. Las direcciones de origen y de destino en el encabezado del paquete IP son las de las puertas de enlace IKE local y remota, respectivamente. En la carga del paquete IP, hay un segmento UDP que encapsula un paquete ISAKMP (IKE). El formato para los paquetes IKE es el mismo para la fase 1 y la fase 2. Consulte Figura 1.
Mientras tanto, el host de origen volvió a enviar el paquete interrumpido. Normalmente, para cuando llega el segundo paquete, las negociaciones de IKE se completan y Junos OS protege el paquete y todos los paquetes subsiguientes en la sesión, con IPsec antes de reenviarlo.
El campo Carga siguiente contiene un número que indica uno de los siguientes tipos de carga:
-
0002: Carga de negociación de SA contiene una definición para una SA de fase 1 o fase 2.
-
0004: la carga útil de la propuesta puede ser una propuesta de fase 1 o fase 2.
-
0008: la carga de transformación se encapsula en una carga de propuesta que se encapsula en una carga de SA.
-
0010: la carga de intercambio de claves (KE) contiene información necesaria para realizar un intercambio de claves, como un valor DH público.
-
0020—Carga de identificación (IDx).
-
En la fase 1, IDii indica el ID del iniciador e IDir indica el ID del respondedor.
-
En la fase 2, IDui indica el usuario iniciador e IDur indica el usuario que responde.
Los ID son tipos de ID de IKE, como FQDN, U-FQDN, dirección IP y ASN.1_DN.
-
-
0040: Carga de certificado (CERT).
-
0080—Carga de solicitud de certificado (CERT_REQ).
-
0100—La carga de hash (HASH) contiene el resultado de síntesis de una función hash determinada.
-
0200—La carga útil de firma (SIG) contiene una firma digital.
-
0400—La carga útil de Nonce (Nx) contiene información pseudoaleatoria necesaria para el intercambio).
-
0800—Carga de notificación.
-
1000: Carga de eliminación ISAKMP.
-
2000—La carga útil de ID de proveedor (VID) se puede incluir en cualquier lugar en las negociaciones de la fase 1. Junos OS lo utiliza para marcar la compatibilidad con NAT-T.
Cada carga ISAKMP comienza con el mismo encabezado genérico, tal como se muestra en la Figura 2.
Puede haber varias cargas ISAKMP enlazadas, con cada tipo de carga subsiguiente indicado por el valor en el campo Encabezado siguiente. Un valor de 0000 indica la última carga ISAKMP. Consulte Figura 3 para ver un ejemplo.
Procesamiento de paquete IPsec
Una vez que se completan las negociaciones de IKE y las dos puertas de enlace IKE han establecido SA de fase 1 y fase 2, todos los paquetes posteriores se reenvían mediante el túnel. Si la SA de fase 2 especifica el Protocolo de seguridad de encapsulación (ESP) en modo de túnel, el paquete tiene un aspecto similar al que se muestra en Figura 4. El dispositivo agrega dos encabezados adicionales al paquete original que envía el host iniciador.
Tal como se muestra en Figura 4, el paquete que crea el host iniciador incluye la carga, el encabezado TCP y el encabezado de IP interior (IP1).
El encabezado IP del enrutador (IP2), agregado por Junos OS, contiene la dirección IP de la puerta de enlace remota como dirección IP de destino y la dirección IP del enrutador local como dirección IP de origen. Junos OS también agrega un encabezado ESP entre los encabezados IP externo e interno. El encabezado ESP contiene información que permite al par remoto del mismo nivel procesar correctamente el paquete cuando lo recibe. Consulte Figura 5.
El campo Siguiente encabezado indica el tipo de datos del campo de carga. En el modo de túnel, este valor es 4, lo cual indica que un paquete IP está contenido dentro de la carga. Consulte Figura 6.
Introducción a IKE en Junos OS
IKE proporciona formas de intercambiar claves para el cifrado y la autenticación de forma segura a través de un medio no seguro, como Internet. IKE habilita un par de puertas de enlace de seguridad: Establezca dinámicamente un túnel seguro a través del cual las puertas de enlace de seguridad puedan intercambiar información clave y de túnel. Configure túneles o SA a nivel de usuario, incluidas las negociaciones de atributos de túnel y la administración de claves. Estos túneles también se pueden actualizar y terminar en la parte superior del mismo canal seguro. IKE emplea métodos Diffie-Hellman y es opcional en IPsec (las claves compartidas se pueden especificar manualmente en los extremos).
IKEv2 incluye soporte para:
VPN basadas en rutas.
VPN de sitio a sitio.
Detección de pares muertos.
Clúster de chasis.
Autenticación de clave precompartida.
Autenticación basada en certificados.
SA infantiles. Una SA secundaria IKEv2 se conoce como SA de fase 2 en IKEv1. En IKEv2, una SA secundaria no puede existir sin la SA de IKE subyacente.
AutoVPN.
VPN de punto de conexión dinámico.
EAP es compatible con el acceso remoto mediante IKEv2.
Selectores de tráfico.
IKEv2 no admite las siguientes características:
VPN basada en políticas.
Supervisión de VPN.
Protocolo de compresión de carga IP (IPComp).
- Configuración de IKEv2 en Junos OS
- Descripción de la carga de configuración de IKEv2
- Descripción del aprovisionamiento de células pico
Configuración de IKEv2 en Junos OS
Un par VPN se configura como IKEv1 o IKEv2. Cuando un par se configura como IKEv2, no puede recurrir a IKEv1 si su par remoto inicia la negociación de IKEv1. De forma predeterminada, los dispositivos de seguridad de Juniper Networks son pares IKEv1.
Utilice la instrucción de version v2-only configuración en el nivel de jerarquía [edit security ike gateway gw-name] para configurar IKEv2.
La versión de IKE se muestra en la salida de los show security ike security-associations comandos operativos y show security ipsec security-associations CLI.
Los dispositivos de Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 2, lo que le permite definir qué tan restrictivo será un rango de parámetros de túnel que aceptará. Junos OS proporciona conjuntos predefinidos de propuestas de fase 2 de tipo básicas, compatibles y estándar. También puede definir propuestas de fase 2 personalizadas.
Descripción de la carga de configuración de IKEv2
La carga de configuración es una opción de Intercambio de claves por Internet versión 2 (IKEv2) que se ofrece para propagar la información de aprovisionamiento de un respondedor a un iniciador. La carga de configuración de IKEv2 solo es compatible con VPN basadas en rutas.
RFC 5996, Protocolo de intercambio de claves por Internet versión 2 (IKEv2), define 15 atributos de configuración diferentes que el respondedor puede devolver al iniciador. Tabla 1 describe los atributos de configuración de IKEv2 admitidos en los firewalls de la serie SRX.
|
Tipo de atributo |
valor |
Description |
Largura |
|---|---|---|---|
|
INTERNAL_IP4_ADDRESS |
1 |
Especifica una dirección en la red interna. Se pueden solicitar múltiples direcciones internas. El respondedor puede enviar hasta el número de direcciones solicitadas. |
0 o 4 octetos |
|
INTERNAL_IP4_NETMASK |
2 |
Especifica el valor de máscara de red de la red interna. Solo se permite un valor de máscara de red en los mensajes de solicitud y respuesta (por ejemplo, 255.255.255.0) y solo debe usarse con un atributo INTERNAL_IP4_ADDRESS. |
0 o 4 octetos |
|
INTERNAL_IP4_DNS |
3 |
Especifica la dirección de un servidor DNS dentro de la red. Se pueden solicitar varios servidores DNS. El respondedor puede responder con cero o más atributos del servidor DNS. |
0 o 4 octetos |
|
INTERNAL_IP4_NBNS |
4 |
Especifica una dirección de un servidor de nombres NetBIOS (NBNS), por ejemplo, un servidor WINS, dentro de la red. Se pueden solicitar múltiples servidores NBNS. El respondedor puede responder con cero o más atributos de servidor NBNS. |
0 o 4 octetos |
| INTERNAL_IP6_ADDRESS |
8 |
Especifica una dirección en la red interna. Se pueden solicitar múltiples direcciones internas. El respondedor puede enviar hasta el número de direcciones solicitadas. |
0 o 17 octetos |
| INTERNAL_IP6_DNS |
10 |
Especifica la dirección de un servidor DNS dentro de la red. Se pueden solicitar varios servidores DNS. El respondedor puede responder con cero o más atributos del servidor DNS. |
0 o 16 octetos |
Para que el respondedor IKE proporcione al iniciador información de aprovisionamiento, debe adquirir la información de un origen especificado, como un servidor RADIUS. La información de aprovisionamiento también se puede devolver desde un servidor DHCP a través de un servidor RADIUS. En el servidor RADIUS, la información del usuario no debe incluir una contraseña de autenticación. El perfil de servidor RADIUS está enlazado a la puerta de enlace IKE mediante la aaa access-profile profile-name configuración en el nivel de jerarquía [edit security ike gateway gateway-name].
Junos OS mejoró la carga de configuración de IKEv2 para admitir las siguientes funciones:
-
Compatibilidad con el conjunto de direcciones locales IPv4 e IPv6. También puede asignar una dirección IP fija a un par.
Durante el establecimiento de IKE, el iniciador solicita una dirección IPv4, una dirección IPv6, una dirección DNS o una dirección WINS del respondedor. Después de que el respondedor ha autenticado correctamente al iniciador, asigna una dirección IP desde un grupo de direcciones local o a través del servidor RADIUS. Dependiendo de la configuración, esta dirección IP se asigna dinámicamente cada vez que un par se conecta o se asigna como una dirección IP fija. Si el servidor RADIUS responde con un grupo enmarcado, Junos OS asigna una dirección IP o información en función de la configuración de su grupo local correspondiente. Si configura tanto el grupo de direcciones local como el servidor RADIUS, la dirección IP asignada desde el servidor RADIUS tiene prioridad sobre el grupo local. Si configura un grupo de direcciones IP local y el servidor RADIUS no devolvió ninguna dirección IP, el grupo local asignará la dirección IP a la solicitud.
-
Opción adicional,
noneintroducida paraauthentication-order. Consulte Orden de autenticación (perfil de acceso). -
Los mensajes de inicio y detención de la contabilidad RADIUS informan del estado del túnel o del par del servidor RADIUS. Estos mensajes se pueden utilizar con fines de seguimiento o notificaciones a subsistemas como un servidor DHCP.
Asegúrese de que el servidor RADIUS admite mensajes de inicio o detención de cuentas. Asegúrese también de que tanto los firewalls de la serie SRX como el servidor RADIUS tengan la configuración adecuada para realizar un seguimiento de estos mensajes.
-
La introducción de la compatibilidad con IPv6 permite túneles de pila dual que utilizan la carga de configuración. Durante el proceso de inicio de sesión, IKE solicita direcciones IPv4 e IPv6. AAA permite el inicio de sesión solo si todas las direcciones solicitadas se han asignado correctamente. IKE finaliza la negociación si no se asigna la IP solicitada.
En una VPN basada en ruta, las interfaces de túnel seguro (st0) funcionan en modo punto a multipunto o punto a punto. La asignación de direcciones a través de la carga de configuración de IKEv2 ahora se admite para el modo punto a multipunto o punto a punto. Para las interfaces de punto a multipunto, las interfaces deben estar numeradas y las direcciones en la carga de configuración INTERNAL_IP4_ADDRESS tipo de atributo deben estar dentro del rango de subred de la interfaz punto a multipunto asociada.
Puedeconfigurar una contraseña común para las solicitudes de carga de configuración de IKEv2 para una configuración de puerta de enlace IKE. La contraseña común en el intervalo de 1 a 128 caracteres permite al administrador definir una contraseña común. Esta contraseña se utiliza entre el firewall de la serie SRX y el servidor RADIUS cuando el firewall de la serie SRX solicita una dirección IP en nombre de un par IPsec remoto mediante la carga de configuración de IKEv2. El servidor RADIUS coincide con las credenciales antes de proporcionar cualquier información IP al firewall de la serie SRX para la solicitud de carga de configuración. Puede configurar la contraseña común mediante config-payload-password configured-password la instrucción de configuración en el nivel de jerarquía [edit security ike gateway gateway-name aaa access-profile access-profile-name].
Tanto el firewall de la serie SRX como el servidor RADIUS deben tener la misma contraseña configurada y el servidor RADIUS debe configurarse para usar el Protocolo de autenticación de contraseña (PAP) como protocolo de autenticación. Sin esto, el establecimiento del túnel no tendrá éxito.
Figura 7 muestra un flujo de trabajo típico para una carga de configuración IKEv2.
La función de carga de configuración IKEv2 es compatible tanto con interfaces de túnel seguro punto a multipunto (st0) como con interfaces punto a punto. Las interfaces punto a multipunto deben estar numeradas y las direcciones proporcionadas en la carga de configuración deben estar dentro del rango de subred de la interfaz punto a multipunto asociada.
Descripción del aprovisionamiento de células pico
La carga de configuración de IKEv2 se puede usar para propagar información de aprovisionamiento desde un respondedor IKE, como un firewall de la serie SRX, a múltiples iniciadores, como las estaciones base de celdas pico LTE en una red celular. Las picoceldas se envían de fábrica con una configuración estándar que les permite conectarse al firewall de la serie SRX, pero la información de aprovisionamiento de picoceldas se almacena en uno o más servidores de aprovisionamiento dentro de una red protegida. Las picoceldas reciben información completa de aprovisionamiento después de establecer conexiones seguras con los servidores de aprovisionamiento.
El flujo de trabajo necesario para arrancar y aprovisionar una pico celda e introducirla en el servicio incluye cuatro etapas distintas:
-
Adquisición de direcciones iniciales: la pico cell se envía desde la fábrica con la siguiente información:
-
Configuración del túnel de puerta de enlace segura al firewall de la serie SRX
-
Certificado digital emitido por el fabricante
-
Nombre de dominio completo (FQDN) de los servidores de aprovisionamiento que se encuentran dentro de la red protegida
La pico celda se inicia y adquiere una dirección que se utilizará para la negociación de IKE desde un servidor DHCP. A continuación, se construye un túnel a la puerta de enlace segura en el firewall de la serie SRX utilizando esta dirección. El servidor DHCP también asigna una dirección para el tráfico de operación, administración y administración (OAM) para su uso en la red protegida.
-
Aprovisionamiento de pico celling: mediante su dirección de tráfico OAM asignada, la pico cell solicita su información de aprovisionamiento (normalmente certificado de operador, licencia, software e información de configuración) a los servidores de la red protegida.
Reiniciar: la pico celda se reinicia y utiliza la información de aprovisionamiento adquirida para hacerla específica para la red y el modelo de operación del proveedor de servicios.
-
Prestación de servicios: cuando la pico cell entra en servicio, utiliza un único certificado que contiene valores de nombre distintivo (DN) y nombre alternativo de sujeto con un FQDN para construir dos túneles a la puerta de enlace segura en el firewall de la serie SRX: uno para el tráfico OAM y el otro para el tráfico de datos del Proyecto de Asociación de Tercera Generación (3GPP).
Consulte también
Propuesta de IKE
La configuración de IKE define los algoritmos y las claves utilizados para establecer la conexión IKE segura con la puerta de enlace de seguridad del mismo nivel. Puede configurar una o varias propuestas de IKE. Cada propuesta es una lista de atributos IKE para proteger la conexión IKE entre el host IKE y su par.
Para configurar una propuesta de IKE, incluya la proposal instrucción y especifique un nombre en el nivel de jerarquía [edit security ike ]:
Política de IKE
Una política de IKE define una combinación de parámetros de seguridad (propuestas de IKE) que se utilizarán durante la negociación de IKE. Define una dirección de pares y las propuestas necesarias para esa conexión. Según el método de autenticación que se utilice, define la clave previamente compartida (PSK) para el par dado o el certificado local. Durante la negociación de IKE, IKE busca una política de IKE que sea la misma en ambos pares. El par que inicia la negociación envía todas sus directivas al par remoto y el par remoto intenta encontrar una coincidencia. Se realiza una coincidencia cuando ambas directivas de los dos pares tienen una propuesta que contiene los mismos atributos configurados. Si las duraciones no son idénticas, se utiliza la vida útil más corta entre las dos políticas (del host y del par). El PSK configurado también debe coincidir con su par.
En primer lugar, configure una o varias propuestas de IKE; a continuación, asociar estas propuestas a una política de IKE.
Para configurar una política de IKE, incluya la policy instrucción y especifique un nombre de política en el nivel de jerarquía [edit security ike]:
Reintroducción de claves y reautenticación
Descripción general
Con IKEv2, la reintroducción de claves y la reautenticación son procesos separados. La reintroducción de claves establece nuevas claves para la asociación de seguridad (SA) de IKE y restablece los contadores de ID de mensajes, pero no vuelve a autenticar a los pares. La reautenticación verifica que los pares de VPN conserven su acceso a las credenciales de autenticación. La reautenticación establece nuevas claves para la SA de IKE y las SA secundarias; ya no se necesitan las reclaves de ninguna SA IKE o SA secundaria pendiente. Después de crear el nuevo IKE y las SA secundarias, se eliminan el IKE antiguo y las SA secundarias.
La reautenticación IKEv2 está deshabilitada de forma predeterminada. Para habilitar la reautenticación, configure un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de reclaves IKE que se producen antes de que se produzca la reautenticación. Por ejemplo, si la frecuencia de reautenticación configurada es 1, se produce una nueva autenticación cada vez que hay una reclave IKE. Si la frecuencia de reautenticación configurada es 2, la reautenticación se produce en cada dos reclaves de IKE. Si la frecuencia de reautenticación configurada es 3, se produce una nueva autenticación en cada tercera reclave IKE, y así sucesivamente.
La frecuencia de reautenticación se configura con la reauth-frequency instrucción en el nivel de jerarquía [edit security ike policy policy-name]. La reautenticación se deshabilita estableciendo la frecuencia de reautenticación en 0 (valor predeterminado). La frecuencia de reautenticación no es negociada por los pares y cada par puede tener su propio valor de frecuencia de reautenticación.
Características soportadas
La reautenticación IKEv2 es compatible con las siguientes características:
Iniciadores o respondedores de IKEv2
Detección de pares muertos (DPD)
Enrutadores virtuales e interfaces de túnel seguro (st0) en enrutadores virtuales
Recorrido de traducción de direcciones de red (NAT-T)
Clústeres de chasis en modo activo-activo y activo-pasivo para dispositivos de SRX5400, SRX5600 y SRX5800
Actualización de software en servicio (ISSU) en dispositivos SRX5400, SRX5600 y SRX5800
Actualización o inserción de una nueva unidad de procesamiento de servicios (SPU) mediante el procedimiento de actualización de hardware en servicio (ISHU)
Limitaciones
Tenga en cuenta las siguientes advertencias al usar la reautenticación IKEv2:
Con NAT-T, se puede crear una nueva SA de IKE con puertos diferentes de la SA de IKE anterior. En este escenario, es posible que no se elimine la SA de IKE antigua.
En un escenario NAT-T, el iniciador detrás del dispositivo NAT puede convertirse en el respondedor después de la reautenticación. Si la sesión NAT caduca, el dispositivo NAT podría descartar nuevos paquetes IKE que podrían llegar a un puerto diferente. NAT-T keepalive o DPD deben estar habilitados para mantener viva la sesión NAT. Para AutoVPN, recomendamos que la frecuencia de reautenticación configurada en los radios sea menor que la frecuencia de reautenticación configurada en el concentrador.
En función de la frecuencia de reautenticación, el iniciador o el respondedor de la SA original pueden iniciar una nueva SA de IKE. Dado que la carga de configuración y autenticación del Protocolo de autenticación extensible (EAP) requieren que la SA de IKE la inicie la misma parte que la SA de IKE original, no se admite la reautenticación con la autenticación EAP ni con la carga de configuración.
Autenticación IKE (autenticación basada en certificados)
Jerarquía multinivel para la autenticación de certificados
La autenticación basada en certificados es un método de autenticación admitido en los firewalls de la serie SRX durante la negociación IKE. En redes grandes, varias autoridades de certificación (CA) pueden emitir certificados de entidad final (EE) a sus respectivos dispositivos finales. Es común tener CA independientes para ubicaciones, departamentos u organizaciones individuales.
Cuando se emplea una jerarquía de un solo nivel para la autenticación basada en certificados, todos los certificados EE de la red deben estar firmados por la misma CA. Todos los dispositivos de firewall deben tener el mismo certificado de CA inscrito para la validación del certificado del mismo nivel. La carga del certificado enviada durante la negociación de IKE solo contiene certificados EE.
Alternativamente, la carga de certificado enviada durante la negociación de IKE puede contener una cadena de certificados EE y CA. Una cadena de certificados es la lista de certificados necesarios para validar el certificado EE de un par. La cadena de certificados incluye el certificado EE y cualquier certificado de CA que no esté presente en el par local.
El administrador de red debe asegurarse de que todos los pares que participan en una negociación de IKE tengan al menos una CA de confianza común en sus respectivas cadenas de certificados. La CA de confianza común no tiene que ser la CA raíz. El número de certificados de la cadena, incluidos los certificados para EE y la CA más alta de la cadena, no puede superar los 10.
Lavinculación V de un par IKE configurado se puede realizar con un servidor de CA especificado o un grupo de servidores de CA. Con las cadenas de certificados, la CA raíz debe coincidir con el grupo de CA de confianza o el servidor de CA configurado en la políticade IKE.
En la jerarquía de CA de ejemplo que se muestra en Figura 8, Root-CA es la CA de confianza común para todos los dispositivos de la red. La CA raíz emite certificados de CA a las CA de ingeniería y ventas, que se identifican como Eng-CA y Sales-CA, respectivamente. Eng-CA emite certificados de CA para las CA de desarrollo y control de calidad, que se identifican como Dev-CA y Qa-CA, respectivamente. El host A recibe su certificado EE de Dev-CA, mientras que el host B recibe su certificado EE de Sales-CA.
Cada dispositivo final debe cargarse con los certificados de CA en su jerarquía. El host-A debe tener certificados Root-CA, Eng-CA y Dev-CA; Los certificados Sales-CA y Qa-CA no son necesarios. El host B debe tener certificados Root-CA y Sales-CA. Los certificados se pueden cargar manualmente en un dispositivo o inscribirse mediante el Proceso simple de inscripción de certificados (SCEP).
Cada dispositivo final debe configurarse con un perfil de CA para cada CA de la cadena de certificados. El siguiente resultado muestra los perfiles de CA configurados en el host-A:
admin@host-A# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url “www.example.net/scep/Eng/”;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url “www.example.net/scep/Dev/”;
}
}
}El siguiente resultado muestra los perfiles de CA configurados en el host B:
admin@host-B# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Sales-CA {
ca-identity Sales-CA;
enrollment {
url “www.example.net/scep/Sales/”;
}
}
}Consulte también
Configurar varios tipos de certificados para establecer SA de IKE e IPsec
Obtenga información sobre cómo configurar y administrar varios tipos de certificados.
En este ejemplo se muestra cómo configurar varios tipos de certificados para establecer IKE y SA IPsec.
A partir de Junos OS versión 22.4R1, puede establecer túneles independientemente del tipo de certificado utilizado en el iniciador y el respondedor si el método de autenticación está configurado como certificates en la propuesta de IKE mediante el set security ike proposal ike_proposal_name authentication-method certificates comando.
Puede ver el certificado inscrito mediante show security pki local-certificate certificate-id certificate-name detail el comando.
Puede comprobar el certificado inscrito mediante el request security pki local-certificate verify certificate-id certificate-name comando.
Requisitos
Antes de empezar:
-
Asegúrese de tener certificados inscritos en sus dispositivos, consulte Inscripción de certificados.
Puede verificar los certificados inscritos en sus dispositivos mediante el
request security pki local-certificate certificate-id certificate-name detailcomando. -
Asegúrese de que tiene instalado el paquete IKE, para comprobar el paquete IKE instalado, utilice el
show version | match ikecomando operativo.Si no tiene el paquete IKE instalado en el dispositivo, puede instalar el paquete IKE mediante el comando
request system software add optional://junos-ike.tgzoperativo , para obtener más información, consulte Habilitar el conjunto de características VPN IPsec.
Descripción general
En este ejemplo se configuran varios tipos de certificados para establecer SA de IKE e IPsec entre SRX_A y SRX_B.
En este ejemplo, hemos inscrito el certificado RSA en SRX_A y el certificado ECDSA en dispositivos SRX_B. Para obtener más información acerca de cómo instalar los certificados, consulte Inscripción de certificados.
| Nombre del dispositivo | Interfaz utilizada | Dirección de puerta de enlace de IKE | Dirección IP local de la puerta de enlace IKE |
|---|---|---|---|
| SRX_A | ge-0/0/0 | 192.168.1.2 | 192.168.1.1 |
| SRX_B | ge-0/0/0 | 192.168.1.1 | 192.168.1.2 |
Topología
El describe la topología para varios tipos de Figura 9 certificados que admiten la configuración.
Configuración
Configuración de SRX_A
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24 set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 set interfaces st0 unit 1 family inet set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust host-inbound-traffic protocols all set security zones security-zone trust interfaces ge-0/0/1 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone untrust interfaces ge-0/0/0 set security zones security-zone VPN interfaces st0.1 set security policies from-zone VPN to-zone trust policy 1 match source-address any set security policies from-zone VPN to-zone trust policy 1 match destination-address any set security policies from-zone VPN to-zone trust policy 1 match application any set security policies from-zone VPN to-zone trust policy 1 then permit set security policies from-zone trust to-zone VPN policy 1 match source-address any set security policies from-zone trust to-zone VPN policy 1 match destination-address any set security policies from-zone trust to-zone VPN policy 1 match application any set security policies from-zone trust to-zone VPN policy 1 then permit set security policies default-policy deny-all set security ike proposal IKE_PROP authentication-method certificates set security ike proposal IKE_PROP dh-group group5 set security ike proposal IKE_PROP authentication-algorithm sha-256 set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc set security ike policy IKE_POL proposals IKE_PROP set security ike policy IKE_POL certificate local-certificate r0_rsa_crt set security ike gateway IKE_GW ike-policy IKE_POL set security ike gateway IKE_GW address 192.168.1.2 set security ike gateway IKE_GW external-interface ge-0/0/0 set security ike gateway IKE_GW local-address 192.168.1.1 set security ike gateway IKE_GW version v2-only set security ipsec proposal IPSEC_PROP protocol esp set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc set security ipsec policy IPSEC_POL proposals IPSEC_PROP set security ipsec vpn IPSEC_VPN bind-interface st0.1 set security ipsec vpn IPSEC_VPN ike gateway IKE_GW set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL set security ipsec vpn IPSEC_VPN establish-tunnels on-traffic
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Descripción general del modo de configuración de CLI en la Guía del usuario de CLI.
Para configurar varios tipos de certificados para establecer SA de IKE e IPsec:
-
Vea los certificados inscritos en sus dispositivos con el
show security pki local-certificate certificate-id certificate-name detailcomando.Instale el certificado en su dispositivo si su dispositivo no tiene los certificados inscritos. Para obtener más información, consulte Inscripción de certificados.
-
Configurar interfaces.
user@srxa# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24 user@srxa# set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 user@srxa# set interfaces st0 unit 1 family inet
-
Configure las zonas de seguridad y la política de seguridad.
user@srxa# set security zones security-zone trust host-inbound-traffic system-services all user@srxa# set security zones security-zone trust host-inbound-traffic protocols all user@srxa# set security zones security-zone trust interfaces ge-0/0/1 user@srxa# set security zones security-zone untrust host-inbound-traffic system-services ike user@srxa# set security zones security-zone untrust interfaces ge-0/0/0 user@srxa# set security zones security-zone VPN interfaces st0.1 user@srxa# set security policies from-zone VPN to-zone trust policy 1 match source-address any user@srxa# set security policies from-zone VPN to-zone trust policy 1 match destination-address any user@srxa# set security policies from-zone VPN to-zone trust policy 1 match application any user@srxa# set security policies from-zone VPN to-zone trust policy 1 then permit user@srxa# set security policies from-zone trust to-zone VPN policy 1 match source-address any user@srxa# set security policies from-zone trust to-zone VPN policy 1 match destination-address any user@srxa# set security policies from-zone trust to-zone VPN policy 1 match application any user@srxa# set security policies from-zone trust to-zone VPN policy 1 then permit user@srxa# set security policies default-policy deny-all
-
Configure la propuesta de IKE.
[edit] user@srxa# set security ike proposal IKE_PROP authentication-method certificates user@srxa# set security ike proposal IKE_PROP dh-group group5 user@srxa# set security ike proposal IKE_PROP authentication-algorithm sha-256 user@srxa# set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc
-
Configure la política de IKE.
[edit] user@srxa# set security ike policy IKE_POL proposals IKE_PROP user@srxa# set security ike policy IKE_POL certificate local-certificate r0_rsa_crt
-
Configure la puerta de enlace de IKE.
[edit] user@srxa# set security ike gateway IKE_GW ike-policy IKE_POL user@srxa# set security ike gateway IKE_GW address 192.168.1.2 user@srxa# set security ike gateway IKE_GW external-interface ge-0/0/0 user@srxa# set security ike gateway IKE_GW local-address 192.168.1.1 user@srxa# set security ike gateway IKE_GW version v2-only
-
Configure la propuesta IPsec.
[edit] user@srxa# set security ipsec proposal IPSEC_PROP protocol esp user@srxa# set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 user@srxa# set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc
-
Configure la directiva IPsec.
[edit] user@srxa# set security ipsec policy IPSEC_POL proposals IPSEC_PROP
-
Configure la VPN IPsec.
[edit] user@srxa# set security ipsec vpn IPSEC_VPN bind-interface st0.1 user@srxa# set security ipsec vpn IPSEC_VPN ike gateway IKE_GW user@srxa# set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL user@srxa# set security ipsec vpn IPSEC_VPN establish-tunnels on-traffic
Resultados
Desde el modo de configuración, escriba los show interfacescomandos y, show security ike para confirmar la configuración. show security ipsec Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@srxa# show interfaces
ge-0/0/0 {
description untrust;
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/0/1 {
description trust;
unit 0 {
family inet {
address 172.16.1.1/24;
}
}
}
st0 {
unit 1 {
family inet;
}
}
[edit]
user@srxa# show security ike
proposal IKE_PROP {
authentication-method certificates;
dh-group group5;
authentication-algorithm sha-256;
encryption-algorithm aes-128-cbc;
}
policy IKE_POL {
proposals IKE_PROP;
certificate {
local-certificate r0_crt_rsa;
}
}
gateway IKE_GW {
ike-policy IKE_POL;
address 192.168.1.2;
external-interface ge-0/0/0;
local-address 192.168.1.1;
version v2-only;
}
[edit]
user@srxa# show security ipsec
proposal IPSEC_PROP {
protocol esp;
authentication-algorithm hmac-sha-256-128;
encryption-algorithm aes-192-cbc;
}
policy IPSEC_POL {
proposals IPSEC_PROP;
}
vpn IPSEC_VPN {
bind-interface st0.1;
ike {
gateway IKE_GW;
ipsec-policy IPSEC_POL;
}
establish-tunnels on-traffic;
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Configuración de SRX_B
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24 set interfaces ge-0/0/1 unit 0 family inet address 172.18.1.2/24 set interfaces st0 unit 1 family inet set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust host-inbound-traffic protocols all set security zones security-zone trust interfaces ge-0/0/1 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone untrust interfaces ge-0/0/0 set security zones security-zone VPN interfaces st0.1 set security policies from-zone VPN to-zone trust policy 1 match source-address any set security policies from-zone VPN to-zone trust policy 1 match destination-address any set security policies from-zone VPN to-zone trust policy 1 match application any set security policies from-zone VPN to-zone trust policy 1 then permit set security policies from-zone trust to-zone VPN policy 1 match source-address any set security policies from-zone trust to-zone VPN policy 1 match destination-address any set security policies from-zone trust to-zone VPN policy 1 match application any set security policies from-zone trust to-zone VPN policy 1 then permit set security policies default-policy deny-all set security ike proposal IKE_PROP authentication-method certificates set security ike proposal IKE_PROP dh-group group5 set security ike proposal IKE_PROP authentication-algorithm sha-256 set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc set security ike policy IKE_POL proposals IKE_PROP set security ike policy IKE_POL certificate local-certificate r1_crt_ecdsa384 set security ike gateway IKE_GW ike-policy IKE_POL set security ike gateway IKE_GW address 192.168.1.1 set security ike gateway IKE_GW external-interface ge-0/0/0 set security ike gateway IKE_GW local-address 192.168.1.2 set security ike gateway IKE_GW version v2-only set security ipsec proposal IPSEC_PROP protocol esp set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc set security ipsec policy IPSEC_POL proposals IPSEC_PROP set security ipsec vpn IPSEC_VPN bind-interface st0.1 set security ipsec vpn IPSEC_VPN ike gateway IKE_GW set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL set security ipsec vpn IPSEC_VPN establish-tunnels on-traffic
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Descripción general del modo de configuración de CLI en la Guía del usuario de CLI.
Para configurar varios tipos de certificados para establecer SA de IKE e IPsec:
-
Vea los certificados inscritos en sus dispositivos con el
request security pki local-certificate certificate-id certificate-name detailcomando.Instale el certificado en su dispositivo si su dispositivo no tiene los certificados inscritos. Para obtener más información, consulte Inscripción de certificados.
-
Configurar interfaces.
user@srxb# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24 user@srxb# set interfaces ge-0/0/1 unit 0 family inet address 172.18.1.2/24 user@srxb# set interfaces st0 unit 1 family inet
-
Configure las zonas de seguridad y la política de seguridad.
user@srxb# set security zones security-zone trust host-inbound-traffic system-services all user@srxb# set security zones security-zone trust host-inbound-traffic protocols all user@srxb# set security zones security-zone trust interfaces ge-0/0/1 user@srxb# set security zones security-zone untrust host-inbound-traffic system-services ike user@srxb# set security zones security-zone untrust interfaces ge-0/0/0 user@srxb# set security zones security-zone VPN interfaces st0.1 user@srxb# set security policies from-zone VPN to-zone trust policy 1 match source-address any user@srxb# set security policies from-zone VPN to-zone trust policy 1 match destination-address any user@srxb# set security policies from-zone VPN to-zone trust policy 1 match application any user@srxb# set security policies from-zone VPN to-zone trust policy 1 then permit user@srxb# set security policies from-zone trust to-zone VPN policy 1 match source-address any user@srxb# set security policies from-zone trust to-zone VPN policy 1 match destination-address any user@srxb# set security policies from-zone trust to-zone VPN policy 1 match application any user@srxb# set security policies from-zone trust to-zone VPN policy 1 then permit user@srxb# set security policies default-policy deny-all
-
Configure la propuesta de IKE.
[edit] user@srxb# set security ike proposal IKE_PROP authentication-method certificates user@srxb# set security ike proposal IKE_PROP dh-group group5 user@srxb# set security ike proposal IKE_PROP authentication-algorithm sha-256 user@srxb# set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc
-
Configure la política de IKE.
[edit] user@srxb# set security ike policy IKE_POL proposals IKE_PROP user@srxb# set security ike policy IKE_POL certificate local-certificate r1_crt_ecdsa384
-
Configure la puerta de enlace de IKE.
[edit] user@srxb# set security ike gateway IKE_GW ike-policy IKE_POL user@srxb# set security ike gateway IKE_GW address 192.168.1.1 user@srxb# set security ike gateway IKE_GW external-interface ge-0/0/0 user@srxb# set security ike gateway IKE_GW local-address 192.168.1.2 user@srxb# set security ike gateway IKE_GW version v2-only
-
Configure la propuesta IPsec.
[edit] user@srxb# set security ipsec proposal IPSEC_PROP protocol esp user@srxb# set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 user@srxb# set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc
-
Configure la directiva IPsec.
[edit] user@srxb# set security ipsec policy IPSEC_POL proposals IPSEC_PROP
-
Configure la VPN IPsec.
[edit] user@srxb# set security ipsec vpn IPSEC_VPN bind-interface st0.1 user@srxb# set security ipsec vpn IPSEC_VPN ike gateway IKE_GW user@srxb# set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL user@srxb# set security ipsec vpn IPSEC_VPN establish-tunnels immediately
Resultados
Desde el modo de configuración, escriba los show interfacescomandos y, show security ike para confirmar la configuración. show security ipsec Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@srxb# show interfaces
ge-0/0/0 {
description untrust;
unit 0 {
family inet {
address 192.168.1.2/24;
}
}
}
ge-0/0/1 {
description trust;
unit 0 {
family inet {
address 172.18.1.2/24;
}
}
}
st0 {
unit 1 {
family inet;
}
}
[edit]
user@srxb# show security ike
proposal IKE_PROP {
authentication-method certificates;
dh-group group5;
authentication-algorithm sha-256;
encryption-algorithm aes-128-cbc;
}
policy IKE_POL {
proposals IKE_PROP;
certificate {
local-certificate r1_crt_ecdsa384;
}
}
gateway IKE_GW {
ike-policy IKE_POL;
address 192.168.1.1;
external-interface ge-0/0/0;
local-address 192.168.1.2;
version v2-only;
}
[edit]
user@srxb# show security ipsec
proposal IPSEC_PROP {
protocol esp;
authentication-algorithm hmac-sha-256-128;
encryption-algorithm aes-192-cbc;
}
policy IPSEC_POL {
proposals IPSEC_PROP;
}
vpn IPSEC_VPN {
bind-interface st0.1;
ike {
gateway IKE_GW;
ipsec-policy IPSEC_POL;
}
establish-tunnels immediately;
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Verificación
Confirme que la configuración funcione correctamente.
Verificar SRX_A
Las salidas de muestra que se muestran están en SRX-A.
Propósito
Compruebe el estado de fase 2 de IPsec.
Acción
Desde el modo operativo, ingrese el comando show security ike security-associations.
user@srxa> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 32 UP 6723643250f0f357 f6295f11b0d7c8ab IKEv2 192.168.1.2
Desde el modo operativo, ingrese el comando show security ipsec security-associations.
user@srxa> show security ipsec security-associations Total active tunnels: 1 Total IPsec sas: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <500033 ESP:aes-cbc-192/sha256 0x5f156c1b 2750/ unlim - root 500 192.168.1.2 >500033 ESP:aes-cbc-192/sha256 0x7ea065e7 2750/ unlim - root 500 192.168.1.2
Desde el modo operativo, ingrese el comando show security ike security-associations detail.
user@srxa> show security ike security-associations detail
IKE peer 192.168.1.2, Index 32, Gateway Name: IKE_GW
Role: Responder, State: UP
Initiator cookie: 6723643250f0f357, Responder cookie: f6295f11b0d7c8ab
Exchange type: IKEv2, Authentication method: RSA-signatures
Local gateway interface: ge-0/0/0.0
Routing instance: default
Local: 192.168.1.1:500, Remote: 192.168.1.2:500
Lifetime: Expires in 28165 seconds
Reauth Lifetime: Disabled
IKE Fragmentation: Enabled, Size: 576
Remote Access Client Info: Unknown Client
Peer ike-id: 192.168.1.2
AAA assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha256-128
Encryption : aes128-cbc
Pseudo random function: hmac-sha256
Diffie-Hellman group : DH-group-5
Traffic statistics:
Input bytes : 1346
Output bytes : 1887
Input packets: 3
Output packets: 4
Input fragmented packets: 2
Output fragmented packets: 3
IPSec security associations: 2 created, 0 deleted
Phase 2 negotiations in progress: 1
IPSec Tunnel IDs: 500033
Negotiation type: Quick mode, Role: Responder, Message ID: 0
Local: 192.168.1.1:500, Remote: 192.168.1.2:500
Local identity: 192.168.1.1
Remote identity: 192.168.1.2
Flags: IKE SA is created
IPsec SA Rekey CREATE_CHILD_SA exchange stats:
Initiator stats: Responder stats:
Request Out : 0 Request In : 0
Response In : 0 Response Out : 0
No Proposal Chosen In : 0 No Proposal Chosen Out : 0
Invalid KE In : 0 Invalid KE Out : 0
TS Unacceptable In : 0 TS Unacceptable Out : 0
Res DH Compute Key Fail : 0 Res DH Compute Key Fail: 0
Res Verify SA Fail : 0
Res Verify DH Group Fail: 0
Res Verify TS Fail : 0
Desde el modo operativo, ingrese el comando show security ipsec security-associations detail.
user@srxa> show security ipsec security-associations detail
ID: 500033 Virtual-system: root, VPN Name: IPSEC_VPN
Local Gateway: 192.168.1.1, Remote Gateway: 192.168.1.2
Local Identity: ipv4(0.0.0.0-255.255.255.255)
Remote Identity: ipv4(0.0.0.0-255.255.255.255)
TS Type: proxy-id
Version: IKEv2
PFS group: N/A
DF-bit: clear, Copy-Outer-DSCP Disabled, Bind-interface: st0.1, Tunnel MTU: 0, Policy-name: IPSEC_POL
Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0
Multi-sa, Configured SAs# 0, Negotiated SAs#: 0
Tunnel events:
Thu Mar 09 2023 22:41:36: IPsec SA negotiation succeeds (1 times)
Location: FPC 0, PIC 0, KMD-Instance 0
Anchorship: Thread 1
Distribution-Profile: default-profile
Direction: inbound, SPI: 0x5f156c1b, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2895 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2286 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 32
Direction: outbound, SPI: 0x7ea065e7, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2895 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2286 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 32
Desde el modo operativo, ingrese el comando show security pki local-certificate certificate-id r0_rsa_cr detail.
user@srxa> show security pki local-certificate certificate-id r0_rsa_crt detail
LSYS: root-logical-system
Certificate identifier: r0_rsa_crt
Certificate version: 3
Serial number:
hexadecimal: 0x0186a62478ae8f0cdd766eb38dbd53
decimal: 7923302907757301847007106226306387
Issuer:
Organization: juniper, Country: India, Common name: Root-CA
Subject:
Organization: juniper, Organizational unit: marketing, State: california, Locality: sunnyvale, Common name: r0, Domain component: juniper
Subject string:
DC=juniper, CN=r0, OU=marketing, O=juniper, L=sunnyvale, ST=california, C=us
Alternate subject: "r0@juniper.net", r0.juniper.net, 192.168.1.1
Cert-Chain: Root-CA
Validity:
Not before: 03- 3-2023 05:54 UTC
Not after: 06- 6-2027 12:36 UTC
Public key algorithm: rsaEncryption(2048 bits)
30:82:01:0a:02:82:01:01:00:b0:e5:53:8d:7e:20:fa:6b:21:c2:d1
2b:48:8f:af:c3:eb:8b:23:4a:f7:c5:1f:cf:2c:6a:b3:2e:8a:ef:1b
f7:97:aa:fd:1d:ab:1c:76:9b:40:a3:ac:bb:49:f6:93:f9:e1:4e:62
df:3d:ca:e5:d2:95:9c:a0:f4:2b:d7:7e:1d:20:94:69:a8:e4:cf:dc
15:90:4c:be:1d:d8:1c:52:08:3a:d1:05:a3:bb:2f:8f:31:0c:6b:21
ef:76:c3:c7:fb:be:4a:cb:da:cc:8d:04:3a:75:0c:eb:5d:e2:f6:13
50:fe:39:67:c0:77:2f:32:b0:5e:38:6f:9c:79:b3:5d:f3:57:f4:f8
42:f5:22:5b:6c:58:67:90:4e:1e:ec:6a:03:e2:c0:87:65:02:ca:da
6f:95:0a:8c:2a:fd:45:4f:3a:b5:ef:18:05:1c:54:e6:fe:45:bb:73
53:81:b2:c6:b7:36:36:57:6d:9c:d3:d9:80:e7:d6:85:92:74:32:88
16:01:03:27:57:76:8e:5e:d6:73:ac:bf:68:fd:6d:a1:2a:8f:f5:3a
29:b0:c9:44:9b:c8:46:c1:bf:c0:52:2a:f0:51:be:b5:f6:e1:f5:3e
96:1d:3a:42:29:28:d3:cf:60:b9:eb:24:04:47:d3:f1:3f:5e:38:fc
7f:33:f6:94:9d:02:03:01:00:01
Signature algorithm: sha256WithRSAEncryption
Fingerprint:
4d:f6:89:c5:d6:3c:74:73:db:3e:f6:4b:1e:26:6c:c1:1c:1d:a7:4d (sha1)
6b:1c:a8:1f:de:5a:9b:3e:d5:c4:85:29:af:3f:82:f2 (md5)
6b:7a:b5:d1:57:cf:75:9d:1f:63:b9:f6:49:e4:4e:b3:13:2c:83:f1:f7:25:44:6f:45:2f:0d:2f:ae:a8:80:85 (sha256)
Auto-re-enrollment:
Status: Disabled
Next trigger time: Timer not startedDesde el modo operativo, ingrese el comando show security pki ca-certificate ca-profile Root-CA detail.
user@srxa> show security pki ca-certificate ca-profile Root-CA detail
LSYS: root-logical-system
CA profile: Root-CA
Certificate identifier: Root-CA
Certificate version: 3
Serial number:
hexadecimal: 0x00000440
decimal: 1088
Issuer:
Organization: juniper, Country: India, Common name: Root-CA
Subject:
Organization: juniper, Country: India, Common name: Root-CA
Subject string:
C=India, O=juniper, CN=Root-CA
Validity:
Not before: 06- 7-2022 12:36 UTC
Not after: 06- 6-2027 12:36 UTC
Public key algorithm: rsaEncryption(2048 bits)
30:82:01:0a:02:82:01:01:00:cd:9c:e6:9f:62:6c:49:15:c2:da:eb
8e:e6:e5:a1:88:40:d8:b5:2e:5b:1a:0e:de:96:d7:0b:19:f9:03:44
98:49:d5:cc:a8:90:2b:7f:1b:58:7b:1f:26:92:18:4c:2d:37:65:5c
9f:0f:6e:10:b5:34:6f:2d:b5:9c:27:3b:a6:b1:b5:a0:e2:a6:92:3d
e4:68:fe:5d:71:06:6f:ce:e6:0f:0f:e3:94:2a:23:57:98:a0:6a:9c
e0:52:a2:47:ff:ce:b0:47:bd:36:95:80:a7:af:d2:49:b1:5d:2a:3d
28:e4:95:06:b8:b3:d9:07:11:3c:13:af:c6:e2:51:08:22:82:2d:ec
4f:26:40:b0:b0:55:2d:6e:c0:c8:19:34:a7:99:5a:bc:58:98:69:ae
04:d6:6d:ec:4a:c9:55:a5:ff:00:cb:3b:02:85:fa:02:a1:5c:c1:9d
6d:44:b8:95:8f:77:c0:53:fc:7f:a4:09:a3:25:1c:4a:e2:9d:0c:81
08:b4:c8:b8:0d:bc:94:75:54:75:57:4f:d3:a4:17:0d:5d:1a:f3:c1
1d:5d:73:2f:fe:8b:cb:fc:1f:93:87:72:d6:be:df:86:d7:e6:d1:c7
0d:00:1a:6e:58:db:6a:1c:2f:1d:17:46:9a:f2:69:b4:21:db:08:5d
8d:ab:30:7d:7f:02:03:01:00:01
Signature algorithm: sha256WithRSAEncryption
Distribution CRL:
http://10.102.40.55:8080/crl-as-der/currentcrl-11.crl?id=11
Use for key: CRL signing, Certificate signing, Key encipherment, Digital signature
Fingerprint:
8b:84:60:2a:58:5b:80:f0:b9:ae:25:9f:67:3d:d6:81:ee:43:6c:d4 (sha1)
ab:ec:4d:fe:d4:04:9c:c9:79:1d:9a:33:4e:6d:78:f6 (md5)
9d:f0:c0:a0:93:74:11:53:d3:4d:2d:75:d3:60:37:5f:fb:b7:a9:67:42:cd:7c:3c:0e:0f:9b:58:36:3c:14:f5 (sha256)Verificar SRX_B
Las salidas de muestra que se muestran están en SRX-B.
Propósito
Compruebe el estado de fase 2 de IPsec.
Acción
Desde el modo operativo, ingrese el comando show security ike security-associations.
user@srxb> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 56042 UP 6723643250f0f357 f6295f11b0d7c8ab IKEv2 192.168.1.1
Desde el modo operativo, ingrese el comando show security ipsec security-associations.
user@srxb> show security ipsec security-associations Total active tunnels: 1 Total IPsec sas: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <500230 ESP:aes-cbc-192/sha256 0x7ea065e7 2638/ unlim - root 500 192.168.1.1 >500230 ESP:aes-cbc-192/sha256 0x5f156c1b 2638/ unlim - root 500 192.168.1.1
Desde el modo operativo, ingrese el comando show security ike security-associations detail.
user@srxb> show security ike security-associations detail
IKE peer 192.168.1.1, Index 56042, Gateway Name: IKE_GW
Role: Responder, State: UP
Initiator cookie: 6723643250f0f357, Responder cookie: f6295f11b0d7c8ab
Exchange type: IKEv2, Authentication method: ECDSA-384-signatures
Local gateway interface: ge-0/0/0.0
Routing instance: default
Local: 192.168.1.2:500, Remote: 192.168.1.1:500
Lifetime: Expires in 18995 seconds
Reauth Lifetime: Disabled
IKE Fragmentation: Enabled, Size: 576
Remote Access Client Info: Unknown Client
Peer ike-id: 192.168.1.1
AAA assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha256-128
Encryption : aes128-cbc
Pseudo random function: hmac-sha256
Diffie-Hellman group : DH-group-5
Traffic statistics:
Input bytes : 2934
Output bytes : 2379
Input packets: 10
Output packets: 9
Input fragmented packets: 3
Output fragmented packets: 2
IPSec security associations: 8 created, 3 deleted
Phase 2 negotiations in progress: 1
IPSec Tunnel IDs: 500230
Negotiation type: Quick mode, Role: Responder, Message ID: 0
Local: 192.168.1.2:500, Remote: 192.168.1.1:500
Local identity: 192.168.1.2
Remote identity: 192.168.1.1
Flags: IKE SA is created
IPsec SA Rekey CREATE_CHILD_SA exchange stats:
Initiator stats: Responder stats:
Request Out : 1 Request In : 2
Response In : 1 Response Out : 2
No Proposal Chosen In : 0 No Proposal Chosen Out : 0
Invalid KE In : 0 Invalid KE Out : 0
TS Unacceptable In : 0 TS Unacceptable Out : 0
Res DH Compute Key Fail : 0 Res DH Compute Key Fail: 0
Res Verify SA Fail : 0
Res Verify DH Group Fail: 0
Res Verify TS Fail : 0
Desde el modo operativo, ingrese el comando show security ipsec security-associations detail.
user@srxb> show security ipsec security-associations detail
ID: 500230 Virtual-system: root, VPN Name: IPSEC_VPN
Local Gateway: 192.168.1.2, Remote Gateway: 192.168.1.1
Local Identity: ipv4(0.0.0.0-255.255.255.255)
Remote Identity: ipv4(0.0.0.0-255.255.255.255)
TS Type: proxy-id
Version: IKEv2
PFS group: N/A
DF-bit: clear, Copy-Outer-DSCP Disabled, Bind-interface: st0.1, Tunnel MTU: 0, Policy-name: IPSEC_POL
Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0
Multi-sa, Configured SAs# 0, Negotiated SAs#: 0
Tunnel events:
Thu Mar 02 2023 22:26:16: IPsec SA negotiation succeeds (1 times)
Location: FPC 0, PIC 0, KMD-Instance 0
Anchorship: Thread 1
Distribution-Profile: default-profile
Direction: inbound, SPI: 0x7ea065e7, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2633 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2002 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 56042
Direction: outbound, SPI: 0x5f156c1b, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2633 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2002 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 56042Desde el modo operativo, ingrese el comando show security pki local-certificate certificate-id r1_crt_ecdsa384 detail.
user@srxb> show security pki local-certificate certificate-id r1_crt_ecdsa384 detail
LSYS: root-logical-system
Certificate identifier: r1_crt_ecdsa384
Certificate version: 3
Serial number:
hexadecimal: 0x0186a6254347a38063946d08595a55
decimal: 7923303152683216740296668848151125
Issuer:
Organization: juniper, Country: India, Common name: root-ecdsa-384
Subject:
Organization: juniper, Organizational unit: marketing, State: california, Locality: sunnyvale, Common name: r1_spk1, Domain component: juniper
Subject string:
DC=juniper, CN=r1_spk1, OU=marketing, O=juniper, L=sunnyvale, ST=california, C=us
Alternate subject: "r1_spk1@juniper.net", r1_spk1.juniper.net, 192.168.2
Cert-Chain: root-ecdsa-384
Validity:
Not before: 03- 3-2023 05:55 UTC
Not after: 06- 6-2027 13:21 UTC
Public key algorithm: ecdsaEncryption(384 bits)
04:c2:ba:19:dc:0d:62:a7:94:7b:9b:1d:4d:ff:a1:e1:44:b5:57:a7
cb:7d:33:6b:35:87:b8:e4:ca:44:b1:6c:6d:63:ae:6f:3c:31:7c:7e
65:99:b3:2d:a3:76:30:23:e5:0e:34:e1:28:54:d6:3e:d3:8b:de:b6
b9:45:05:82:6f:1d:20:b7:6f:3c:ce:a2:13:a2:b4:37:0b:db:35:1e
20:54:b5:06:9d:f8:7f:19:7b:c5:d7:7b:57:8b:28:31:d3
Signature algorithm: ecdsa-with-SHA384
Fingerprint:
9b:cb:5a:57:a8:60:a0:ee:5c:be:59:4c:db:35:39:d3:b7:29:ef:b1 (sha1)
ef:b5:e3:be:35:1b:6e:02:0b:61:11:a5:53:07:b4:89 (md5)
8f:86:d0:12:ea:bc:a8:81:a8:17:3a:f9:03:e4:91:57:20:9c:11:bc:a4:dd:d1:7f:d1:48:3f:5b:d9:fb:93:32 (sha256)
Auto-re-enrollment:
Status: Disabled
Next trigger time: Timer not started
s
Desde el modo operativo, ingrese el comando show security pki ca-certificate ca-profile Root-CA detail.
user@srxb> show security pki ca-certificate ca-profile Root-CA detail
LSYS: root-logical-system
CA profile: Root-CA
Certificate identifier: Root-CA
Certificate version: 3
Serial number:
hexadecimal: 0x00000440
decimal: 1088
Issuer:
Organization: juniper, Country: India, Common name: Root-CA
Subject:
Organization: juniper, Country: India, Common name: Root-CA
Subject string:
C=India, O=juniper, CN=Root-CA
Validity:
Not before: 06- 7-2022 12:36 UTC
Not after: 06- 6-2027 12:36 UTC
Public key algorithm: rsaEncryption(2048 bits)
30:82:01:0a:02:82:01:01:00:cd:9c:e6:9f:62:6c:49:15:c2:da:eb
8e:e6:e5:a1:88:40:d8:b5:2e:5b:1a:0e:de:96:d7:0b:19:f9:03:44
98:49:d5:cc:a8:90:2b:7f:1b:58:7b:1f:26:92:18:4c:2d:37:65:5c
9f:0f:6e:10:b5:34:6f:2d:b5:9c:27:3b:a6:b1:b5:a0:e2:a6:92:3d
e4:68:fe:5d:71:06:6f:ce:e6:0f:0f:e3:94:2a:23:57:98:a0:6a:9c
e0:52:a2:47:ff:ce:b0:47:bd:36:95:80:a7:af:d2:49:b1:5d:2a:3d
28:e4:95:06:b8:b3:d9:07:11:3c:13:af:c6:e2:51:08:22:82:2d:ec
4f:26:40:b0:b0:55:2d:6e:c0:c8:19:34:a7:99:5a:bc:58:98:69:ae
04:d6:6d:ec:4a:c9:55:a5:ff:00:cb:3b:02:85:fa:02:a1:5c:c1:9d
6d:44:b8:95:8f:77:c0:53:fc:7f:a4:09:a3:25:1c:4a:e2:9d:0c:81
08:b4:c8:b8:0d:bc:94:75:54:75:57:4f:d3:a4:17:0d:5d:1a:f3:c1
1d:5d:73:2f:fe:8b:cb:fc:1f:93:87:72:d6:be:df:86:d7:e6:d1:c7
0d:00:1a:6e:58:db:6a:1c:2f:1d:17:46:9a:f2:69:b4:21:db:08:5d
8d:ab:30:7d:7f:02:03:01:00:01
Signature algorithm: sha256WithRSAEncryption
Distribution CRL:
http://10.102.40.55:8080/crl-as-der/currentcrl-11.crl?id=11
Use for key: CRL signing, Certificate signing, Key encipherment, Digital signature
Fingerprint:
8b:84:60:2a:58:5b:80:f0:b9:ae:25:9f:67:3d:d6:81:ee:43:6c:d4 (sha1)
ab:ec:4d:fe:d4:04:9c:c9:79:1d:9a:33:4e:6d:78:f6 (md5)
9d:f0:c0:a0:93:74:11:53:d3:4d:2d:75:d3:60:37:5f:fb:b7:a9:67:42:cd:7c:3c:0e:0f:9b:58:36:3c:14:f5 (sha256)Autenticación de firma en IKEv2
Lea este tema para obtener información sobre el método de autenticación de firma en IKEv2 y cómo funciona en Junos OS.
El protocolo de intercambio de claves por Internet versión 2 (IKEv2) admite la autenticación basada en firmas que usa criptografía de clave pública. En IKEv2, la autenticación basada en firmas admite un método de autenticación por algoritmo de firma. Por ejemplo, los pares IKE utilizan un método de autenticación independiente para cada una de estas firmas digitales: RSA, algoritmo de firma digital (DSA) y DSA de curva elíptica (ECDSA). Cada algoritmo hash está vinculado a una firma para la autenticación. En la configuración de propuestas de IKEv2, cuando se especifica el método de autenticación, el dispositivo utiliza ese método para autenticar el origen de los mensajes de IKEv2. Es difícil para el par IKE saber qué algoritmo hash está asociado con la firma. Este proceso se vuelve aún más engorroso con la introducción de cada nuevo algoritmo. Consulte Intercambio de claves por red para obtener más información sobre IKEv2.
Puede abordar estos desafíos con el método de autenticación de firma digital basado en RFC 7427. Este método es más genérico en comparación con el método de autenticación basada en firmas, ya que los pares de IKE pueden utilizar cualquiera de los algoritmos de firma admitidos y también negociar el algoritmo hash de firma. Lea más para comprender acerca de la autenticación de firma en IKEv2.
Implementación de la autenticación de firma en IKEv2
Además de admitir la autenticación basada en firmas por algoritmo, Junos OS también admite el método de autenticación de firma digital descrito en RFC 7427. En este método, la carga de autenticación IKEv2 indica no solo el tipo de clave pública, sino también el algoritmo hash que utiliza el dispositivo para generar la firma. El dispositivo utiliza la notificación SIGNATURE_HASH_ALGORITHM para notificar a su par acerca de la compatibilidad con RFC 7427 y proporcionar la lista de algoritmos hash compatibles.
Para usar esta función, debe configurar el método de autenticación de firma digital en su dispositivo.Para obtener más información acerca del método de autenticación de firma digital, consulte proposal (Security IKE). Puede utilizar la opción signature-hash-algorithm de configuración para definir los algoritmos hash de firma específicos que deben coincidir en orden jerárquico con cada uno de los algoritmos hash de firma recibidos. Si no especifica el algoritmo hash de firma, el dispositivo coincide con el algoritmo hash de firma recibido de la lista predeterminada de todos los algoritmos hash compatibles. Consulte Signature Hash Algorithm (Security IKE).
En Junos OS, el método de autenticación implica los siguientes pasos que se definen en el flujo de mensajes IKEv2. Consulte RFC 7296, Protocolo de intercambio de claves por Internet versión 2 (IKEv2) para obtener más detalles.
-
Ambos pares de IKE se notifican inicialmente la lista de algoritmos hash compatibles. El dispositivo envía la carga SIGNATURE_HASH_ALGORITHM del mensaje IKE_SA_INIT al dispositivo par y recibe una respuesta. A continuación, los pares negocian un algoritmo hash de firma.
-
En el mensaje IKE_AUTH, los pares intercambian el método de autenticación de firma digital.
El dispositivo utiliza el método predeterminado de autenticación de certificados en cualquiera de estos escenarios:
-
El respondedor no admite RFC 7427.
-
El iniciador no admite el algoritmo hash recibido.
Ventajas
-
Flexible: incluye firmas digitales tradicionales y nuevas.
-
Facilidad de uso: se integra en la infraestructura de clave pública (PKI) existente.
-
Solución robusta: realiza una mejor verificación de identidad en comparación con el método de autenticación basada en firmas, lo que mejora la seguridad y confiabilidad generales de los pares de IKE.
Consulte también
Protección IKE contra ataques DDoS
La denegación de servicio(DoS) es uno de los ataques más comunes y graves en una red VPN IPsec insegura. Un ataque DoS proporciona una manera rápida y fácil de apoderarse de la red, ya que no requiere mucho punto de apoyo en la infraestructura de red. Losatacantes eligen este método para tomar el control de la red.
¿Qué sucede en un ataque DoS?
El atacante intenta inundar y bloquear gradualmente la red con demasiado tráfico, agotando los recursos de red y tomando aún más el control de los recursos del dispositivo, como la memoria y la CPU. Si el atacante intenta controlar mediante varios sistemas orquestados, atacando sincrónicamente a un único objetivo, se denomina ataques DoS distribuidos (DDoS).
- Vulnerabilidades de DDoS en implementaciones de IKE
- Protección Against Ataques DDoS
- Formas de monitorear ataques DDoS
Vulnerabilidades de DDoS en implementaciones de IKE
Cuando el interlocutor remoto (iniciador) envía un mensaje SA_INIT, el interlocutor local (respondedor) responde y asigna memoria para la estructura del mensaje. Llamamos a la sesión una sesión IKE semiabierta hasta que se produzca la autenticación con la ayuda del mensaje IKE_AUTH. Después de que los pares establecen una asociación de seguridad (SA) de IKE, la sesión se convierte en una sesión de IKE completamente abierta.
Para comprender las vulnerabilidades de IKEv2 DDoS, veamos algunas de las formas en que un atacante puede crear un vector de ataque fácil contra las SA de IKE:
-
Enviar un gran número de mensajes de SA_INIT (sin mensajes IKE_AUTH) para los que el atacante puede crear estructuras de asociación de seguridad IKE medio abiertas. El ataque hace que el dispositivo utilice los recursos y se quede sin memoria.
-
Envíe una gran cantidad de paquetes de IKE_AUTH no deseado con el SPI_i y el SPI_r correctos en el iniciador y el respondedor, respectivamente. El dispositivo se queda sin memoria al intentar descifrar los paquetes.
-
Envíe paquetes SA_INIT continuamente. El dispositivo se queda sin memoria al intentar generar claves para los paquetes cifrados.
-
Envíe un gran número de solicitudes de reclave por segundo durante las sesiones de IKE completamente abiertas.
-
Envíe un gran número de mensajes con identificadores de mensajes (ID) distintos. Eldispositivo pone en cola todos los mensajes IKE entrantes y se quedasin memoria.
Cómo proteger las implementaciones de IKE
Proporcionamos una infraestructura robusta para mitigar y monitorear los ataques DDoS para los protocolos IKEv1 e IKEv2. Puede protegerse contra los ataques a las implementaciones de IKE cuando el firewall ejecuta el proceso iked (en el junos-ike paquete) para el servicio VPN IPsec.
Para obtener más información sobre la protección DDoS para IKEv2, consulte RFC 8019, Protección de implementaciones del Protocolo de intercambio de claves por Internet versión 2 (IKEv2) de ataques de denegación de servicio distribuidos. Proporcionamosuna protección similar para IKEv1 cuando su firewall ejecuta el servicio VPN IPsec mediante el proceso iked. No admitimos el mecanismo de rompecabezas de cliente que presenta el RFC.
Protección Against Ataques DDoS
Puede habilitar varios mecanismos de defensa contra los ataques DDoS durante el proceso de creación de asociaciones de seguridad IKE. Estos mecanismos incluyen la configuración de la limitación de la tasa y un período de retención para las SA de IKE semiabiertas, y la gestión adicional de los tipos de cambio entrantes para las solicitudes de reclave. Proporcionamos las siguientes medidas para garantizar la protección contra ataques DDoS en SA IKE:
- Medidas de protección deSA de IKE o semiabiertas:
-
El respondedor no permite la configuración de SAde IKE semiabiertos durante un período determinado. Puede establecer este límite para que el respondedor no configure las SA hasta que alcance la duración del tiempo de espera. Para obtener más información, consulte session (Security IKE) la opción
timeout. -
Puede establecer un límite para el máximo permitido de SA de IKE medio abiertas en el respondedor. Cuando el número total de SA de IKE semiabiertas alcanza el recuento máximo, el respondedor rechaza las nuevas conexiones para las SA IKEv1 e IKEv2. Para obtener más información, consulte la
max-countopción ensession (Security IKE). -
El respondedor aplica valores de umbral en el recuento de sesiones para las SA de IKE medio abiertas. Cuando el número total de SA de IKE semiabiertas alcanzalos valores de umbral:
-
En el caso de las SA IKEv2, el respondedor invoca el mecanismo de cookies para cualquier conexión nueva.
-
En el caso de las SA IKEv1, el respondedor rechaza las nuevas conexiones.
Para obtener más información, consulte las opciones y las opciones de session (Security IKE)
thresholdssend-cookiereduce-timeout. -
-
El respondedor puede descartar sesiones duplicadas. Para obtener más información, consulte la
discard-duplicateopción en session (Security IKE). -
Puede establecer tiempos de espera de retroceso para las fases de error de autenticación e iniciación. Para obtener más información, consulte session (Security IKE) las opciones
backoff-timeouts,init-phase-failureyauth-phase-failure.
-
-
Para SA de IKE completamente abiertas:
-
Puede configurar las tasas máximas de solicitudes de reclave entrantes para limitar las solicitudes en un escenario escalado. Para obtener más información, consulte la
incoming-exchange-max-ratesopción en session (Security IKE).
-
-
El respondedor puede bloquear una sesión de IKE entrante de pares en función del ID de IKE del mismo nivel. Para obtener más información, consulte blocklists (Security IKE).
-
En el caso de las puertas de enlace dinámicas, puede establecer un límite para el número de conexiones en el nivel de configuración de la puerta de enlace de IKE mediante la opción
connections-limit. Para obtener más información, consulte Puerta de enlace (IKE de seguridad).
Para obtener más información sobre cómo configurar estas opciones, consulte Configurar la protección contra ataques DDoS de IKE.
No admitimos:
-
Protección DDoS con el servicio VPN IPsec basado en el proceso kmd.
-
Protección contra ataques de codificación de certificados hash y URL , ya que no admitimos estos tipos de codificación.
Formas de monitorear ataques DDoS
Proporcionamos los siguientes mecanismos para monitorear los ataques DDoS:
-
Utilice el
show security ike security-associationscomando para enumerar todas las asociacionesde seguridad de IKE maduras y no maduras. Para obtener más información, consulte mostrar asociaciones de seguridad ike de seguridad. -
Utilice el
show security ike statscomando para mostrar estadísticas globales de IKE del túnel VPN IPsec, como estadísticas en curso, establecidas y caducadas. Para obtener más información, consulta Mostrar estadísticas de ike de seguridad. -
Utilice el
show security ike active-peercomando para mostrar detalles de las negociaciones exitosas de IKE con los pares remotos. Para obtener más información, consulte mostrar ike de seguridad active-peer. -
Utilice el
show security ike peers in-progresscomando para mostrar los detalles de las SA de IKE en curso, incluidas las SA de IKE medio abiertas. Para obtener más información, consulte show security ike peers. También puede ver los detalles de los pares bloqueados, con errores y de retroceso mediante este comando. -
Utilice el
clear security ike peerscomando para borrar los pares de IKE que están retrocedidos, bloqueados, fallidos o en curso. Para obtener más información, consulte clear security ike peers. -
Para eliminar una asociación de seguridad IKE existente con pares que deba bloquearse para que no pueda seguir comunicándose, utilice el
clear security ike security-associationscomando. Para obtener más información, consulte clear security ike security-associations. -
Los mensajes iked system log (syslog) IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF y IKE_GATEWAY_PEER_FAILED proporcionan detalles sobre las negociaciones IKE bloqueadas, respaldadas y fallidas con los pares remotos, respectivamente.
-
Para mayor seguridad, Junos OS ofrece servicios a los usuarios para protegerse contra ataques al sistema basados en paquetes, como el filtrado, el recuento de sesiones y la limitación de velocidad. Para obtener más información, consulte el comando show firewall y la instrucción ids-option en el nivel de jerarquía [
edit security screen ids-option screen-name].
Configurar la protección contra ataques DDoS de IKE
Consulte esta sección para comprender cómo configurar la protección contra ataques DDoS en el protocolo IKE.
Prerequisitos
Antes de configurar la protección contra los ataques DDoS de IKE, asegúrese de que cumple los siguientes requisitos previos:
-
Firewall de la serie SRX que admite
junos-ikeel paquete para ejecutar el servicio VPN IPsec mediante el proceso iked. -
El firewall serie SRX que sirve como punto de conexión local (el respondedor) es accesible para el par IKE remoto (el iniciador).
-
Una política de IKE que puede asociar una lista de bloqueo de IKE.
La configuración de la protección contra los ataques DDoS de IKE consiste en las siguientes acciones :
-
Administre las SA de IKE medio abiertas entrantes.
-
Gestione las SA de IKE completamente abiertas entrantes.
-
Configure varios métodos de bloqueo para bloquear las sesiones entrantes de IKE de varios pares y asociar una de las listas de bloqueo con un par IKE.
Consulte las siguientes tareas para configurar estas acciones.
- Configurar la sesión de IKE para SA de IKE medio abiertas
- Configurar la sesión de IKE para SA de IKE completamente abiertas
- Configurar las listas de bloqueo de sesión de IKE
Configurar la sesión de IKE para SA de IKE medio abiertas
Descripción general
Asegúrese de cumplir con todos los requisitos previos descritos anteriormente.
En esta sección, verá cómo configurar los tiempos de espera, el recuento máximo y los umbrales para las SA de IKE medio abiertas. Los cambios de configuración son aplicables a las nuevas sesiones, mientras que las sesiones existentes siguen utilizando los valores predeterminados cuando no se configuran explícitamente antes. El alcance de estas configuraciones en el nivel jerárquico [edit security ike session half-open] es aplicable a nivel global y no por nivel par.
Configuración
-
Para establecer el parámetro de duración del respondedor mediante la opción
timeout seconds:[edit] user@host# set security ike session half-open timeout 150
Durante este período, el respondedor no permite la configuración de SA de IKE medio abiertas hasta que alcanza la duración del tiempo de espera. El iniciador puede seguir teniendo una duración de tiempo de espera de 60 segundos, independientemente de la configuración del respondedor.
-
Para establecer el parámetro de recuento máximo del respondedor mediante la opción
max-count value:[edit] user@host# set security ike session half-open max-count 1000
La opción establece el número máximo de sesiones de IKE semiabiertas en el respondedor. El valor predeterminado es 300, si no lo especifica. La
max-countconfiguración deshabilita todos los umbrales. En tales casos, debe configurar explícitamente los umbrales para hacerlos cumplir. -
Especifique los diferentes tipos de acciones mediante la opción
thresholdcuando el recuento de sesiones del respondedor alcance el límite.-
Para establecer el número mínimo de sesiones de IKE medio abiertas para aplicar la acción de cookie mediante la opción
send-cookie count:[edit] user@host# set security ike session half-open threshold send-cookie 500
Esto especifica el límite de umbral a partir del cual el respondedor solicita a los pares remotos que reintenten el inicio de la sesión con una cookie enviada de vuelta al par en la respuesta inicial. Aquí, cuando el límite de recuento de sesiones de IKE medio abiertas alcanza 500, el proceso iked emplea un mecanismo de cookies para las nuevas sesiones de IKE.
-
Para establecer el número mínimo de sesiones de IKE medio abiertas para aplicar una acción de tiempo de espera reducido mediante la opción
reduced-timeout count timeout seconds:[edit] user@host# set security ike session half-open threshold reduce-timeout 600 timeout 100
Esto especifica el límite a partir del cual el proceso iked reduce la duración de las nuevas SA de IKE medio abiertas. Una vez que el recuento de sesiones de IKE del respondedor medio abierto se reduce por debajo del umbral, las sesiones IKE del respondedor medio abierto vuelven a utilizar el valor de tiempo de espera predeterminado.
-
-
Para definir la opción
discard-duplicatecon el fin de descartar las sesiones IKE medio abiertas duplicadas sin enviar una respuesta al iniciador:[edit] user@host# set security ike session half-open discard-duplicate
Para una solicitud de inicio de sesión (SA_INIT) duplicada que proviene del mismo par, con una cookie de iniciador diferente para la cual no hay SA de IKE mientras la negociación está en curso, el respondedor descarta el paquete.
-
Puede establecer los tiempos de espera de retroceso mediante la opción
backoff-timeouts.Esto da algo de tiempo para que el par remoto retroceda en caso de que se produzca un error en el inicio de una sesión, lo que garantiza que el mismo par no pueda iniciar una nueva sesión durante ese período. Después del tiempo de espera de retroceso, el par puede iniciar una nueva sesión. El inicio de la sesión puede fallar en dos fases: la fase de inicialización y la fase de autenticación.
-
Para establecer el tiempo de espera de retroceso cuando se produce un error durante la fase de IKE_AUTH mediante la opción
backoff-timeouts auth-phase-failure value:[edit] user@host# set security ike session half-open backoff-timeouts auth-phase-failure 150
Al configurar
auth-phase-failure, cualquier par remoto que esté en la lista de bloqueados, retrocede incluso cuando no configure el retroceso como una acción para la regla de la lista de bloqueo de destino. El tiempo de espera para el backoff es el configurado paraauth-phase-failure. En este ejemplo, el dispositivo inicia una nueva sesión después de 150 segundos. Para sobrescribir este tiempo de espera de retroceso para una regla determinada, puede configurar explícitamente labackoffacción para la listarulede bloqueo mencionando el tiempo de espera en el [edit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level. -
Para establecer el tiempo de espera de retroceso cuando hay un error durante la fase de SA_INIT mediante la opción
backoff-timeouts init-phase-failure value:[edit] user@host# set security ike session half-open backoff-timeouts init-phase-failure 160
En este ejemplo, el dispositivo inicia una nueva sesión después de 160 segundos.
-
Configurar la sesión de IKE para SA de IKE completamente abiertas
Descripción general
Asegúrese de cumplir con todos los requisitos previos descritos anteriormente.
En esta sección, verá cómo configurar varias tasas de solicitudes entrantes para las SA de IKE abiertas completas mediante la opción incoming-exchange-max-rates en el nivel de jerarquía [edit security ike session full-open].
Configuración
Configure la incoming-exchange-max-rates opción para establecer las tasas máximas para varios intercambios iniciados por el par remoto después de establecer una SA de IKE. Puede configurar tres tipos de cambio: reclave IKE, reclave IPsec y keepalive (también conocido como detección de pares inactivos).
-
Para establecer la velocidad máxima de reclave del IKE iniciado por el par entrante mediante la opción
incoming-exchange-max-rates ike-rekey value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates ike-rekey 200/60
La opción se aplica a la reclave IKEv2 por par con un par existente en el que ya esté presente una SA de IKE.
-
Para establecer la velocidad máxima de reclave de SA IPsec iniciada por el par entrante mediante la opción
incoming-exchange-max-rates ipsec-rekey value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates ipsec-rekey 100/60
El límite se aplica por túnel.
-
Para establecer la tasa máxima de keepalive iniciado por pares entrantes usando la opción
incoming-exchange-max-rates keepalive value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates keepalive 60/60
El límite se aplica por par.
Configurar las listas de bloqueo de sesión de IKE
Descripción general
Asegúrese de cumplir con todos los requisitos previos descritos anteriormente.
Para bloquear una sesión de IKE entrante de pares según el ID de IKE del mismo nivel, debe configurar una o más listas de bloqueo. Cada lista de bloqueo contiene una o más reglas. Cada regla tiene un criterio de coincidencia y una acción.
Tenga en cuenta los siguientes criterios al configurar las listas de bloqueo:
-
Las reglas de la lista de bloqueo se aplican a las nuevas SA de IKE que se están negociando y no afectan a las SA de IKE existentes. En la etapa de autenticación del mismo nivel, el dispositivo aplica las reglas de la lista de bloqueo.
-
El orden de aplicación de las reglas depende de la secuencia en la que se enumeran estas reglas.
-
Configure los criterios de coincidencia en función del rol (iniciador o respondedor), un tipo de ID (dirección IPv4 o IPv6, nombre de host, nombre distintivo, ID de correo electrónico o ID de clave) y un patrón de ID que es una expresión regular para que coincida con el ID de IKE.
-
Puede configurar cada regla con un tipo de ID. Esto le permite configurar diferentes ID de IKE para diferentes reglas dentro de la misma lista de bloqueo.
-
Configure una acción para descartar o rechazar la conexión del mismo nivel. En función de la coincidencia, el dispositivo aplica una acción. Opcionalmente, puede establecer el temporizador de retroceso con estas acciones.
-
Consulte la lista de bloqueo en la política de IKE asociada a la puerta de enlace de IKE.
-
Cada puerta de enlace de IKE solo admite un tipo de tipo de ID de IKE remoto. Si adjunta una lista de bloqueo a una puerta de enlace y la configura con reglas que contienen diferentes ID de IKE, la puerta de enlace aplicará y coincidirá solo con las reglas cuyo tipo de ID de IKE sea el mismo que el configurado para la puerta de enlace de IKE.
-
Las métricas de velocidad de configuración de túneles con listas de bloqueo que se adjuntan a las puertas de enlace de IKE se basan en el número de reglas configuradas en las listas de bloqueo.
En esta sección, verá cómo configurar listas de bloqueo y asociar la lista de bloqueo a una política de IKE.
Configuración
-
Para crear una lista de bloqueo con varias reglas:
-
Crear una lista de bloqueo.
[edit] user@host# set security ike blocklists blocklist1 description block_from_remote
-
Cree una o varias reglas.
[edit] user@host# set security ike blocklists blocklist1 rule rule1 description rule_1 user@host# set security ike blocklists blocklist1 rule rule2 description rule_2
Puede crear varias listas de bloqueo y sus reglas.
-
-
Para configurar los criterios de coincidencia y especificar la acción:
-
Configure los criterios de coincidencia para el rule1 en la lista blocklist1de bloqueo .
[edit] user@host# set security ike blocklists blocklist1 rule rule1 match role initiator user@host# set security ike blocklists blocklist1 rule rule1 match id-type hostname user@host# set security ike blocklists blocklist1 rule rule1 match id-pattern "peer.*\.example\.net" user@host# set security ike blocklists blocklist1 rule rule2 match role initiator user@host# set security ike blocklists blocklist1 rule rule2 match id-type user-at-hostname user@host# set security ike blocklists blocklist1 rule rule2 match id-pattern "hr.example.com"
Para configurar listas de bloqueo mediante un grupo de ID de IKE o ID de IKE parciales, utilice el
id-pattern valuecon un sufijo o prefijo. Por ejemplo, puede usar el valor *.example.com cuando necesite hacer coincidir hr.example.com, finance.example.com admin.example.com. En la regla rule1, el dispositivo busca el nombre de host que coincida con el patrón peer.*\.example\.net. Aquí peer.example.net, peer.1.example.net y peer.uplink.example.net hay algunas coincidencias potenciales. En la regla rule2, el dispositivo busca la dirección de correo electrónico que coincida con el patrón hr.example.com. Del mismo modo, puede configurar otro criterio de coincidencia para las otras reglas basadas en diferentesid-typeoid-pattern. Estos patrones utilizan la expresión regular estándar. -
Especifique la acción para una coincidencia:
[edit] user@host# set security ike blocklists blocklist1 rule rule1 then reject user@host# set security ike blocklists blocklist1 rule rule1 then backoff 60 user@host# set security ike blocklists blocklist1 rule rule2 then discard user@host# set security ike blocklists blocklist1 rule rule2 then backoff 100
-
-
Para asociar una lista de bloqueo con un par IKE:
-
Configure la lista blocklist1 de bloqueo en la política ike_policy1de IKE.
[edit] user@host# set security ike policy ike_policy1 blocklist blocklist1
-
Ejemplo: Configuración de un dispositivo para la validación en cadena de certificados del mismo nivel
En este ejemplo se muestra cómo configurar un dispositivo para cadenas de certificados utilizadas para validar dispositivos del mismo nivel durante la negociación de IKE.
- Requisitos
- Descripción general
- Configuración
- Verificación
- Error de IKE y SA IPsec para un certificado revocado
Requisitos
Antes de comenzar, obtenga la dirección de la entidad de certificación (CA) y la información que necesitan (como la contraseña de desafío) cuando envíe solicitudes de certificados locales.
Descripción general
En este ejemplo se muestra cómo configurar un dispositivo local para cadenas de certificados, inscribir certificados de CA y locales, comprobar la validez de los certificados inscritos y comprobar el estado de revocación del dispositivo del mismo nivel.
Topología
En este ejemplo se muestran los comandos de configuración y operativos en el host A, tal y como se muestra en Figura 10. Se crea automáticamente un perfil de CA dinámico en el Host-A para permitir que el Host-A descargue la CRL de Sales-CA y compruebe el estado de revocación del certificado del Host-B.
La configuración de VPN IPsec para la negociación de fase 1 y fase 2 se muestra para el host-A en este ejemplo. El dispositivo del mismo nivel (host-B) debe estar configurado correctamente para que las opciones de fase 1 y fase 2 se negocien correctamente y se establezcan asociaciones de seguridad (SA). Consulte Configuración de ID de IKE remoto para VPN de sitio a sitio para ver ejemplos de configuración de dispositivos del mismo nivel para VPN.
Configuración
Para configurar un dispositivo para cadenas de certificados:
Configurar perfiles de CA
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
set security pki ca-profile Root-CA ca-identity CA-Root set security pki ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ set security pki ca-profile Root-CA revocation-check crl set security pki ca-profile Eng-CA ca-identity Eng-CA set security pki ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ set security pki ca-profile Eng-CA revocation-check crl set security pki ca-profile Dev-CA ca-identity Dev-CA set security pki ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ set security pki ca-profile Dev-CA revocation-check crl
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacer eso, consulte Uso del editor de CLI en el modo de configuración de la Guía del usuario de CLI.
Para configurar perfiles de CA:
Cree el perfil de CA para Root-CA.
[edit security pki] user@host# set ca-profile Root-CA ca-identity CA-Root user@host# set ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ user@host# set ca-profile Root-CA revocation-check crl
Cree el perfil de CA para Eng-CA.
[edit security pki] user@host# set ca-profile Eng-CA ca-identity Eng-CA user@host# set ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ user@host# set ca-profile Eng-CA revocation-check crl
Cree el perfil de CA para Dev-CA.
[edit security pki] user@host# set ca-profile Dev-CA ca-identity Dev-CA user@host# set ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ user@host# set ca-profile Dev-CA revocation-check crl
Resultados
Desde el modo de configuración, confírmela con el comando show security pki. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@host# show security pki
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Root/";
}
revocation-check {
crl ;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Eng/";
}
revocation-check {
crl ;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Dev/";
}
revocation-check {
crl ;
}
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Inscribir certificados
Procedimiento paso a paso
Para inscribir certificados:
Inscriba los certificados de CA.
user@host> request security pki ca-certificate enroll ca-profile Root-CA
user@host> request security pki ca-certificate enroll ca-profile Eng-CA
user@host> request security pki ca-certificate enroll ca-profile Dev-CA
Escriba yes en las indicaciones para cargar el certificado de CA.
Compruebe que los certificados de CA estén inscritos en el dispositivo.
user@host> show security pki ca-certificate ca-profile Root-CA Certificate identifier: Root-CA Issued to: Root-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-14-2012 22:19 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Eng-CA Certificate identifier: Eng-CA Issued to: Eng-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-15-2012 01:02 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Dev-CA Certificate identifier: Dev-CA Issued to: Dev-CA, Issued by: C = us, O = example, CN = Eng-CA Validity: Not before: 08-15-2012 17:41 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)Compruebe la validez de los certificados de CA inscritos.
user@host> request security pki ca-certificate verify ca-profile Root-CA CA certificate Root-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Eng-CA CA certificate Eng-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Dev-CA CA certificate Dev-CA verified successfully
Generar un par de claves.
user@host> request security pki generate-key-pair certificate-id Host-A type rsa size 1024
Inscribir el certificado local.
user@host> request security pki local-certificate enroll certificate-id Host-A ca-profile Dev-CA challenge-password example domain-name host-a.example.net email host-a@example.net subject DC=example,CN=Host-A, OU=DEV,O=PKI,L=Sunnyvale,ST=CA,C=US
Compruebe que el certificado local está inscrito en el dispositivo.
user@host> show security pki local-certificate Issued to: Host-A, Issued by: C = us, O = example, CN = Dev-CA Validity: Not before: 09-17-2012 22:22 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(1024 bits)Compruebe la validez del certificado local inscrito.
user@host> request security pki local-certificate verify certificate-id Host-A Local certificate Host-A verification success
Compruebe si hay perfiles de CA configurados en la descarga de CRL.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02
Configurar las opciones de VPN IPsec
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
set security ike proposal ike_cert_prop_01 authentication-method rsa-signatures set security ike proposal ike_cert_prop_01 dh-group group5 set security ike proposal ike_cert_prop_01 authentication-algorithm sha1 set security ike proposal ike_cert_prop_01 encryption-algorithm aes-256-cbc set security ike policy ike_cert_pol_01 mode main set security ike policy ike_cert_pol_01 proposals ike_cert_prop_01 set security ike policy ike_cert_pol_01 certificate local-certificate Host-A set security ike gateway ike_cert_gw_01 ike-policy ike_cert_pol_01 set security ike gateway ike_cert_gw_01 address 192.0.2.51 set security ike gateway ike_cert_gw_01 external-interface ge-0/0/1.0 set security ike gateway ike_cert_gw_01 local-identity 192.0.2.31 set security ipsec proposal ipsec_prop_01 protocol esp set security ipsec proposal ipsec_prop_01 authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec_prop_01 encryption-algorithm 3des-cbc set security ipsec proposal ipsec_prop_01 lifetime-seconds 300 set security ipsec policy ipsec_pol_01 proposals ipsec_prop_01 set security ipsec vpn ipsec_cert_vpn_01 bind-interface st0.1 set security ipsec vpn ipsec_cert_vpn_01 ike gateway ike_cert_gw_01 set security ipsec vpn ipsec_cert_vpn_01 ike ipsec-policy ipsec_pol_01
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacer eso, consulte Uso del editor de CLI en el modo de configuración de la Guía del usuario de CLI.
Para configurar las opciones de VPN IPsec:
Configure las opciones de la fase 1.
[edit security ike proposal ike_cert_prop_01] user@host# set authentication-method rsa-signatures user@host# set dh-group group5 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm aes-256-cbc [edit security ike policy ike_cert_pol_01] user@host# set mode main user@host# set proposals ike_cert_prop_01 user@host# set certificate local-certificate Host-A [edit security ike gateway ike_cert_gw_01] user@host# set ike-policy ike_cert_pol_01 user@host# set address 192.0.2.51 user@host# set external-interface ge-0/0/1.0 user@host# set local-identity 192.0.2.31
Configure las opciones de la fase 2.
[edit security ipsec proposal ipsec_prop_01] user@host# set protocol esp user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 300 [edit security ipsec policy ipsec_pol_01] user@host# set proposals ipsec_prop_01 [edit security ipsec vpn ipsec_cert_vpn_01] user@host# set bind-interface st0.1 user@host# set ike gateway ike_cert_gw_01 user@host# set ike ipsec-policy ipsec_pol_01
Resultados
Desde el modo de configuración, escriba los comandos show security ike y show security ipsec para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@host# show security ike
proposal ike_cert_prop_01 {
authentication-method rsa-signatures;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike_cert_pol_01 {
mode main;
proposals ike_cert_prop_01;
certificate {
local-certificate Host-A;
}
}
gateway ike_cert_gw_01 {
ike-policy ike_cert_pol_01;
address 192.0.2.51;
external-interface ge-0/0/1.0;
}
[edit]
user@host# show security ipsec
proposal ipsec_prop_01 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 300;
}
policy ipsec_pol_01 {
proposals ipsec_prop_01;
}
vpn ipsec_cert_vpn_01 {
bind-interface st0.1;
ike {
gateway ike_cert_gw_01;
ipsec-policy ipsec_pol_01;
}
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Verificación
Si la validación del certificado se realiza correctamente durante la negociación de IKE entre dispositivos pares, se establecen asociaciones de seguridad (SA) IKE e IPsec.
La SA de IKE está activa si el certificado es válido. La SA de IKE está inactiva y la SA de IPSEC se forma si se revoca el certificado, solo si la comprobación de revocación está configurada en el dispositivo del mismo nivel
Verificación del estado de la fase 1 de IKE
Propósito
Verifique el estado de la fase 1 de IKE.
Acción
Ingrese el comando desde el show security ike security-associations modo operativo.
user@host> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
2090205 DOWN 285feacb50824495 59fca3f72b64da10 Main 192.0.2.51
Comprobación del estado de fase 2 de IPsec
Propósito
Compruebe el estado de fase 2 de IPsec.
Acción
Ingrese el comando desde el show security ipsec security-associations modo operativo.
user@host> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/sha1 a4756de9 207/ unlim - root 500 192.0.2.51
>131073 ESP:3des/sha1 353bacd3 207/ unlim - root 500 192.0.2.51
Error de IKE y SA IPsec para un certificado revocado
Comprobación de certificados revocados
Problema
Si se produce un error en la validación del certificado durante la negociación de IKE entre dispositivos del mismo nivel, asegúrese de que el certificado del mismo nivel no se haya revocado. Un perfil de CA dinámico permite que el dispositivo local descargue la CRL de la CA del mismo nivel y compruebe el estado de revocación del certificado del par. Para habilitar los perfiles de CA dinámicos, la opción debe configurarse en un perfil de revocation-check crl CA primario.
Solución
Para comprobar el estado de revocación del certificado de un par:
Identifique el perfil de CA dinámico que mostrará la CRL para el dispositivo par ingresando el comando desde el show security pki crl modo operativo.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02 CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sales-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02El perfil
dynamic-001de CA se crea automáticamente en el host A para que el host A pueda descargar la CRL de la CA del host B (Sales-CA) y comprobar el estado de revocación del certificado del par.Para mostrar la información de CRL para el perfil de CA dinámico, ingrese el comando desde el show security pki crl ca-profile dynamic-001 detail modo operativo.
Ingrese
user@host> show security pki crl ca-profile dynamic-001 detail CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sub11 Effective date: 09-19-2012 17:29 Next update: 09-20-2012 01:49 Revocation List: Serial number Revocation date 10647C84 09-19-2012 17:29 UTCEl certificado del host B (número de serie 10647084) ha sido revocado.
Fragmentación IKEv2
Fragmentación de mensajes
La fragmentación de mensajes IKEv2, como se describe en RFC 7383, Fragmentación de mensajes del Protocolo de intercambio de claves por Internet versión 2 (IKEv2), permite que IKEv2 funcione en entornos donde los fragmentos de IP podrían estar bloqueados y los pares no podrían establecer una asociación de seguridad (SA) IPsec. La fragmentación de IKEv2 divide un mensaje IKEv2 grande en un conjunto de mensajes más pequeños para que no haya fragmentación en el nivel de IP. La fragmentación tiene lugar antes de cifrar y autenticar el mensaje original, de modo que cada fragmento se cifra y autentica por separado. En el receptor, los fragmentos se recopilan, verifican, descifran y fusionan en el mensaje original.
Para que se produzca la fragmentación de IKEv2, ambas VPN del mismo nivel deben indicar la compatibilidad con la fragmentación mediante la inclusión de la carga de notificación IKEV2_FRAGMENTATION_SUPPORTED en el intercambio IKE_SA_INIT. Si ambos pares indican compatibilidad con la fragmentación, corresponde al iniciador del intercambio de mensajes determinar si se utiliza o no la fragmentación de IKEv2.
En los firewalls de la serie SRX, se permite un máximo de 32 fragmentos por mensaje IKEv2. Si el número de fragmentos de mensaje IKEv2 que se enviarán o recibirán supera los 32, los fragmentos se eliminarán y el túnel no se establecerá. No se admite la retransmisión de fragmentos de mensajes individuales
Configuración
En los firewalls de la serie SRX, la fragmentación IKEv2 está habilitada de forma predeterminada para los mensajes IPv4 e IPv6. Para deshabilitar la fragmentación de IKEv2, utilice la disable instrucción en el nivel de jerarquía [edit security ike gateway gateway-name fragmentation]. También puede utilizar la size instrucción para configurar el tamaño del paquete en el que se fragmentan los mensajes; el tamaño del paquete oscila entre 500 y 1300 bytes. Si size no está configurado, el tamaño predeterminado del paquete es 576 bytes para el tráfico IPv4 y 1280 bytes para el tráfico IPv6. Un paquete IKEv2 mayor que el tamaño de paquete configurado está fragmentado.
Después de deshabilitar o habilitar la fragmentación de IKEv2 o cambiar el tamaño del fragmento de paquete, los túneles VPN alojados en la puerta de enlace de IKE se desactivan y las SA de IKE e IPsec se renegocian.
Advertencias
Las siguientes características no son compatibles con la fragmentación de IKEv2:
Descubrimiento de MTU de ruta.
SNMP.
Consulte también
Política de IKE con una CA de confianza
En este ejemplo se muestra cómo enlazar un servidor de CA de confianza a una política IKE del mismo nivel.
Antes de comenzar, debe tener una lista de todas las CA de confianza que desea asociar a la directiva IKE del par.
Puede asociar una política de IKE a un único perfil de CA de confianza o a un grupo de CA de confianza. Para establecer una conexión segura, la puerta de enlace de IKE utiliza la política de IKE para limitarse al grupo configurado de CA (perfiles de ca) mientras valida el certificado. No se valida un certificado emitido por cualquier origen que no sea la CA o el grupo de CA de confianza. Si hay una solicitud de validación de certificado procedente de una política de IKE, el perfil de CA asociado de la política de IKE validará el certificado. Si una política de IKE no está asociada a ninguna CA, cualquiera de los perfiles de CA configurados valida el certificado de forma predeterminada.
En este ejemplo, se crea un perfil de CA denominado root-ca y se asocia a un root-ca-identity perfil.
Puede configurar un máximo de 20 perfiles de CA que desee agregar a un grupo de CA de confianza. No puede confirmar su configuración si configura más de 20 perfiles de CA en un grupo de CA de confianza.
Para ver los perfiles de CA y los grupos de CA de confianza configurados en su dispositivo, ejecute show security pki comando.
user@host# show security ike
proposal ike_prop {
authentication-method rsa-signatures;
dh-group group2;
authentication-algorithm sha-256;
encryption-algorithm aes-256-cbc;
}
policy ike_policy {
proposals ike_prop;
certificate {
local-certificate SPOKE;
trusted-ca ca-profile root-ca;
}
}
El show security ike comando muestra el grupo de perfiles de CA bajo la política de IKE denominada ike_policy y el certificado asociado a la política de IKE.
Consulte también
Configuración de Establish-Tunnel Responder-only en IKE
En este tema se muestra cómo configurar túneles establecidos de solo respuesta en Intercambio de claves por Internet (IKE). Inicie los túneles desde el par remoto y envíe el tráfico a través de todos los túneles. Especifica cuándo se activa IKE.
En los firewalls de la serie SRX, la establish-tunnels opción admite los responder-only valores y responder-only-no-rekey en el [edit security ipsec vpn vpn-name] nivel de jerarquía.
Estas opciones solo se admiten en una VPN de sitio a sitio. Estas opciones no son compatibles con Auto VPN.
Las responder-only opciones y responder-only-no-rekey no establecen ningún túnel VPN desde el dispositivo, por lo que el túnel VPN se inicia desde el par remoto. Cuando se configura responder-only, un túnel establecido vuelve a definir la clave de IKE e IPsec en función de los valores de duración de IKE e IPsec configurados. Cuando se configura responder-only-no-rekey, un túnel establecido no vuelve a crear la clave desde el dispositivo y depende del par remoto para iniciar la nueva clave. Si el par remoto no inicia la reclave, el desmontaje del túnel se produce después de que expire la vida útil.
Antes de empezar:
Comprender cómo establecer un túnel IPsec de IKE de clave automática. Leer Información general sobre IPsec.
Para configurar el respondedor de túnel establecido solo en IKE:
Comportamiento solo del respondedor IKEv2 específico de la plataforma
Use el Explorador de características para confirmar la compatibilidad de la plataforma y el lanzamiento de características específicas.
Use la tabla siguiente para revisar los comportamientos específicos de la plataforma para sus plataformas.
| Plataforma | Diferencia |
|---|---|
| Serie SRX |
|
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.
responder-only-no-rekeyresponder-only los valores de la establish-tunnels opción en el [edit security ipsec vpn vpn-name] nivel de jerarquía se introducen en SRX5000 línea en Junos OS versión 19.1R1.