Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Intercambio de claves por red (ICR) para VPN IPsec

Intercambio de claves por red versión 2 (IKEv2) es un protocolo de túnel basado en IPsec que proporciona un canal de comunicación VPN seguro entre dispositivos VPN del mismo nivel y define la negociación y autenticación para las asociaciones de seguridad IPsec (SA) de manera protegida.

ICR y procesamiento de paquetes IPsec

ICR proporciona administración de túnel para IPsec y autentica a las entidades finales. ICR 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 ICR 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 ICR

Cuando un paquete de texto sin formato llega Juniper Networks 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 ICR negociaciones y descarta el paquete. Las direcciones de origen y de destino del encabezado del paquete IP son las de las puertas de enlace ICR local y remota, respectivamente. En la carga del paquete IP, hay un segmento UDP encapsulando un paquete ISAKMP (ICR). El formato para ICR paquetes es el mismo para la fase 1 y la fase 2. Consulte Figura 1 .

Mientras tanto, el host de origen ha enviado de nuevo el paquete interrumpido. Normalmente, cuando llega el segundo paquete, se completan las negociaciones de ICR y Junos OS protege el paquete y todos los paquetes subsiguientes en la sesión, con IPSec antes de reenviarlo.

Figura 1: Paquete ICR para las fases 1 y 2Paquete ICR para las fases 1 y 2

El campo siguiente carga contiene un número que indica uno de los siguientes tipos de carga:

  • 0002: La carga de negociación de SA contiene una definición para una SA de fase 1 o fase 2.

  • 0004: La carga de 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 llevar a cabo 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 de la respondedor.

    • En la fase 2, IDui indica el iniciador de usuario e IDur indica el respondedor de usuario.

    Los identificadores son ICR tipos de ID, 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 hash (HASH) contiene el resultado de síntesis de una función hash determinada.

  • 0200: la carga de firma (SIG) contiene una firma digital.

  • 0400: La carga Nonce (Nx) contiene información pseudoalearia necesaria para el intercambio.

  • 0800: notificar carga.

  • 1000: Carga de eliminación ISAKMP.

  • 2000: La carga de ID de proveedor (VID) se puede incluir en cualquier lugar en las negociaciones de fase 1. Junos OS lo utiliza para marcar la compatibilidad con TDR-T.

Cada carga ISAKMP comienza con el mismo encabezado genérico, tal y como Figura 2se muestra en la.

Figura 2: Encabezado de carga ISAKMP genéricoEncabezado de carga ISAKMP genérico

Puede haber varias cargas ISAKMP encadenadas, con cada tipo de carga subsiguiente indicado por el valor en el campo Next header (encabezado siguiente). Un valor de 0000 indica la última carga ISAKMP. Consulte Figura 3 , para obtener un ejemplo.

Figura 3: Encabezado ISAKMP con cargas ISAKMP genéricasEncabezado ISAKMP con cargas ISAKMP genéricas

Procesamiento de paquetes IPsec

Una vez ICR se completan las negociaciones y las dos puertas de enlace de ICR establecen asociaciones de seguridad (AS) de fase 1 y fase 2, todos los paquetes subsiguientes se reenvía 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 se parece al que se muestra en Figura 4 . El dispositivo agrega dos encabezados adicionales al paquete original que envía el host que inicia el inicio.

Tal y como Figura 4se muestra en, el paquete que crea el host de inicio incluye la carga, el encabezado TCP y el encabezado de IP interior (IP1).

Figura 4: Paquete IPsec: ESP en modo de túnelPaquete IPsec: ESP en modo de túnel

El encabezado IP del enrutador (IP2), que Junos OS agrega, 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. En Junos OS también se agrega un encabezado ESP entre los encabezados IP externos e internos. El encabezado ESP contiene información que permite al elemento remoto del mismo nivel procesar correctamente el paquete cuando lo recibe. Esto se muestra en Figura 5.

Figura 5: Encabezado de IP exterior (IP2) y encabezado ESPEncabezado de IP exterior (IP2) y encabezado ESP

El campo siguiente encabezado indica el tipo de datos del campo carga. En el modo de túnel, este valor es 4, lo que indica que un paquete IP está contenido dentro de la carga. Consulte Figura 6la.

Figura 6: Encabezado de dirección IP interior (IP1) y encabezado de TCPEncabezado de dirección IP interior (IP1) y encabezado de TCP

Introducción a ICR en Junos OS

ICR maneras de intercambiar claves para el cifrado y la autenticación de forma segura a través de un medio no seguro, como Internet. ICR habilita un par de puertas de enlace de seguridad para: Establezca dinámicamente un túnel seguro en el que las puertas de enlace de seguridad puedan intercambiar información de túnel y clave. Configure túneles o SA de nivel de usuario, incluidas las negociaciones de atributos de túnel y la administración de claves. Estos túneles también pueden actualizarse y terminarse encima del mismo canal seguro. ICR emplea métodos Diffie-Hellman y es opcional en IPsec (las claves compartidas se pueden escribir manualmente en los puntos de conexión).

IKEv2 incluye soporte para:

  • VPN basadas en la ruta.

  • VPN de sitio a sitio.

  • Detección de pares de tráfico muerto.

  • Clúster de chasis.

  • Autenticación de clave previamente compartida.

  • Autenticación basada en certificados.

  • SA secundarias. Una SA secundaria de IKEv2 se conoce como SA de fase 2 en IKEv1. En IKEv2, no puede existir una SA secundaria sin el ICR SA subyacente.

  • AutoVPN.

  • VPN de extremo dinámico.

  • EAP se admite para el acceso remoto mediante IKEv2.

  • Selectores de tráfico.

IKEv2 no admite las características siguientes:

  • VPN basado en políticas.

  • Supervisión de VPN.

  • Protocolo de compresión de carga IP (IPComp).

Configuración de IKEv2 en Junos OS

Una VPN peer está configurada como IKEv1 o IKEv2. Cuando un elemento del mismo nivel se configura como IKEv2, no puede recurrir a IKEv1 si su punto de conexión remoto inicia la negociación de IKEv1. De forma predeterminada, los dispositivos de seguridad Juniper Networks son los homólogos de IKEv1.

Utilice la version v2-only instrucción de configuración en eledit security ike gateway gw-namenivel de jerarquía [] para configurar IKEv2.

La versión ICR se muestra en el resultado de los show security ike security-associations comandos show security ipsec security-associations de funcionamiento de la CLI y.

Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 2, lo que le permite definir cómo restrictivo es un rango de parámetros de túnel que va a aceptar. Junos OS proporciona conjuntos predefinidos de propuestas de la fase 2 estándar, compatibles y básicos. También puede definir propuestas personalizadas de fase 2.

Descripción de la carga de configuración IKEv2

La carga de configuración es Intercambio de claves por red opción 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 se admite con VPN basadas en rutas.

RFC 5996, protocolo Intercambio de claves por red 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 IKEv2 compatibles con dispositivos de la serie SRX.

Tabla 1: Atributos de configuración de IKEv2

Tipo de atributo

Valor

Descriptiva

Alarga

INTERNAL_IP4_ADDRESS

1

Especifica una dirección en la red interna. Se pueden solicitar varias direcciones internas. El contestador puede enviar hasta el número de direcciones solicitado.

0 ó 4 octetos

INTERNAL_IP4_NETMASK

2

Especifica el valor de máscara de red interna. Solo se permite un valor de máscara de la sesión en los mensajes de solicitud y respuesta (por ejemplo, 255.255.255.0), y solo se debe usar con un atributo INTERNAL_IP4_ADDRESS.

0 ó 4 octetos

INTERNAL_IP4_DNS

3

Especifica la dirección de un servidor DNS en la red. Se pueden solicitar varios servidores DNS. El contestador puede responder con cero o más atributos del servidor DNS.

0 ó 4 octetos

INTERNAL_IP4_NBNS

4

Especifica la dirección de un servidor de nombres NetBIOS (NBNS), por ejemplo, un servidor WINS, dentro de la red. Se pueden solicitar varios servidores NBNS. El interlocutor que responde puede responder con cero o más atributos de servidor NBNS.

0 ó 4 octetos

INTERNAL_IP6_ADDRESS

8

Especifica una dirección en la red interna. Se pueden solicitar varias direcciones internas. El contestador puede enviar hasta el número de direcciones solicitado.

0 o 17 octetos

INTERNAL_IP6_DNS

10

Especifica la dirección de un servidor DNS en la red. Se pueden solicitar varios servidores DNS. El contestador puede responder con cero o más atributos del servidor DNS.

0 o 16 octetos

Para que el ICR contestadora proporcione al iniciador la información de aprovisionamiento, debe adquirir la información de un origen especificado, como un servidor RADIUS. La información de aprovisionamiento también puede devolverse 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 del servidor RADIUS está enlazado a la puerta de aaa access-profile profile-name enlace de ICR utilizandoedit security ike gateway gateway-namela configuración en el nivel de jerarquía [].

A partir de Junos OS versión 20.3R1 en la línea de dispositivos SRX5000 con SPC3 y vSRX con la nueva IKED, hemos mejorado la carga de configuración de IKEv2 para:

  • Compatibilidad con grupos de direcciones locales IPv4 e IPv6. También puede asignar una dirección IP fija a un par.

    Durante ICR establecimiento, 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 haya autenticado al iniciador de forma correcta, asigna una dirección IP desde un grupo de direcciones local o mediante RADIUS servidor. Según 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 RADIUS responde con un grupo enmarcado, Junos OS asigna una dirección IP o información basada en la configuración de su grupo local correspondiente. Si configura tanto el grupo de direcciones local como RADIUS servidor, la dirección IP asignada desde un servidor RADIUS tiene prioridad sobre el grupo local. Si configura el grupo de direcciones IP locales y el servidor RADIUS no devuelve ninguna dirección IP, el grupo local asigna la dirección IP a la solicitud.

  • Opción adicional, none presentada para authentication-order . Consulte orden de autenticación (perfil de acceso).

  • RADIUS los mensajes de inicio y de detenerse de la cuenta informan del estado del túnel o del par del RADIUS servidor. Estos mensajes se pueden utilizar con fines de seguimiento o notificaciones a subsistemas, como un servidor DHCP.

    Asegúrese de que el RADIUS servidor admite los mensajes de inicio o detención de la cuenta. También asegúrese de que tanto los dispositivos de la serie SRX como el RADIUS servidor tengan la configuración adecuada para rastrear estos mensajes.

  • La introducción de la compatibilidad con IPv6 permite túneles de pila dual mediante carga de configuración. Durante el proceso de inicio de sesión, ICR solicitudes para direcciones IPv4 e IPv6. AAA permitir el inicio de sesión solo si todas las direcciones solicitadas se asignaron correctamente. ICR termina la negociación si no se asigna la IP solicitada.

En una VPN basada en la ruta, las interfaces de túnel seguro (st0) funcionan en el modo punto a multipunto o punto a punto. Ahora se admite la asignación de direcciones mediante la carga de configuración IKEv2 para el modo punto a multipunto o punto a punto. Para interfaces de punto a multipunto, las interfaces deben estar numeradas y las direcciones de la carga de configuración INTERNAL_IP4_ADDRESS tipo de atributo deben estar dentro del rango de subred de la interfaz de punto a multipunto asociada.

A partir de Junos OS versión 20.1R1, puede configurar una contraseña común para las solicitudes de carga de configuración IKEv2 para una configuración ICR puerta de enlace. La contraseña común en un intervalo de 1 a 128 caracteres permite al administrador definir una contraseña común. Esta contraseña se usa entre el dispositivo serie SRX y el servidor RADIUS cuando el dispositivo serie SRX solicita una dirección IP en nombre de un par IPsec remoto mediante carga de configuración IKEv2. RADIUS servidor coincide con los credenciales antes de que proporciona cualquier información IP al dispositivo de la serie SRX para la solicitud de carga de configuración. Puede configurar la contraseña común mediante una instrucción config-payload-password configured-password de configuración en el nivel de jerarquía [ edit security ike gateway gateway-name aaa access-profile access-profile-name ].

Tanto el dispositivo de la serie SRX como el servidor de RADIUS deben tener la misma contraseña configurada y el servidor radius debe estar configurado para usar el protocolo de autenticación de contraseña (PAP) como protocolo de autenticación. Sin esto, el establecimiento de túneles no tendrá éxito.

Figura 7 muestra un flujo de trabajo típico para una carga de configuración IKEv2.

Figura 7: Flujo de trabajo típico de carga de configuración IKEv2Flujo de trabajo típico de carga de configuración IKEv2

La característica de carga de configuración de IKEv2 solo se admite para interfaces de túnel seguro punto a multipunto (st0). Las interfaces punto a multipunto deben estar numeradas y las direcciones que se proporcionan en la carga de configuración deben estar dentro del rango de subred de la interfaz de punto a multipunto asociada.

Descripción de aprovisionamiento de celda pico

La carga de configuración de IKEv2 se puede usar para propagar la información de aprovisionamiento de un ICR respondedor, como un dispositivo serie SRX, a varios iniciadores, como las estaciones de la celda de la celular de LTE pico en una red móvil. Las celdas de pico de envío de la fábrica tienen una configuración estándar que les permite conectarse al dispositivo de serie SRX, pero la información de aprovisionamiento de celdas de pico se almacena en uno o más servidores de aprovisionamiento en una red protegida. Las celdas pico reciben información de aprovisionamiento completa después de establecer conexiones seguras con los servidores de aprovisionamiento.

Se requiere que el flujo de trabajo arranque y aprovisione una celda pico y se introduce en el servicio incluye cuatro fases distintas:

  1. Adquisición de direcciones iniciales: la célula pico se envía desde la fábrica con la siguiente información:

    • Configuración del túnel de puerta de enlace segura hacia el dispositivo serie SRX

    • Certificado digital expedido por el fabricante

    • El nombre de dominio completo (FQDN) de los servidores de aprovisionamiento que se encuentran en la red protegida

    La celda pico inicia y adquiere la dirección que se utilizará para ICR negociación desde un servidor DHCP. A continuación, se crea un túnel para la puerta de enlace segura en el dispositivo de serie SRX que utiliza esta dirección. El servidor DHCP asigna también al tráfico de funcionamiento, administración y administración (mantenimiento seguros) un uso en la red protegida.

  2. Aprovisionamiento de celda Pico: mediante su dirección de tráfico OAM asignada, la celda pico solicita su información de aprovisionamiento (normalmente certificado de operador, licencia, software e información de configuración) de los servidores dentro de la red protegida.

  3. Reinicio: la pico cell se reinicia y utiliza la información de aprovisionamiento adquirida para hacerla específica del modelo de red y operación del proveedor de servicios.

  4. Provisión de servicio: cuando la celda pico entra en servicio, utiliza un único certificado que contiene nombre distinguido (DN) y valores de nombre alternativo de sujeto con un FQDN para crear dos túneles a la puerta de enlace segura en el dispositivo de la serie SRX: uno para el tráfico mantenimiento seguros y otro para el tráfico de datos de un proyecto de colaboración de tercera generación (3GPP).

ICR propuesta

La ICR define los algoritmos y claves que se utilizan para establecer la conexión ICR segura con la puerta de enlace de seguridad par. Puede configurar una o más ICR propuestas. Cada propuesta es una lista de atributos ICR para proteger la ICR conexión entre el host ICR y su par.

Para configurar una ICR propuesta, incluya la instrucción y proposal especifique un nombre en el nivel de jerarquía [ edit security ike ]:

ICR de desarrollo

Una política ICR define una combinación de parámetros de seguridad (ICR propuestas) que se usarán durante ICR negociación. Define una dirección par y las propuestas necesarias para esa conexión. Según el método de autenticación que se utilice, define la clave previamente compartida para el par determinado o el certificado local. Durante la ICR, ICR busca una política de ICR que sea la misma en ambos pares. El par que inicia la negociación envía todas sus políticas al par remoto y el par remoto intenta encontrar una coincidencia. Se hace una coincidencia cuando ambas políticas de los dos pares tienen una propuesta que contiene los mismos atributos configurados. Si las duraciones no son idénticas, se utilizará la duración más corta entre las dos políticas (del host y el par). La clave configurada previamente compartida también debe coincidir con su par.

En primer lugar, puede configurar una o más ICR propuestas; a continuación, asocie estas propuestas con ICR política.

Para configurar una política ICR, incluya la instrucción y especifique un nombre de política policy en el nivel de jerarquía [ edit security ike ]:

Reesclave y reauteticación

Descripción general

Con IKEv2, la regeneración de claves y la nueva autenticación son procesos independientes. El cambio de claves establece nuevas claves para el SA (ICR Security Association) y restablece los contadores de ID de mensajes, pero no reautentica los homólogos. La nueva autenticación comprueba que los homólogos VPN conservan su acceso a las credenciales de autenticación. La reautenticación establece claves nuevas para el ICR SA y las SA secundarias; ya no son necesarias las claves de cualquier SA pendiente ICR o SA secundaria. Después de que se crean las nuevas SA de ICR y secundarias, se eliminan el ICR antiguo y las SA secundarias.

La reautenticación de IKEv2 está deshabilitada de forma predeterminada. La reautenticación se habilita configurando un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de reICR claves que tienen lugar antes de que se produzca una nueva autenticación. Por ejemplo, si la frecuencia configurada para la reautenticación es 1, la nueva autenticación se realiza cada vez que se produce un ICR regeneración de claves. Si la frecuencia configurada para la reautenticación es 2, la reautenticación se produce en todos los demás ICR las claves de regeneración. Si la frecuencia configurada para la reautenticación es 3, la reautenticación se produce cada tres ICR regeneración de claves, y así sucesivamente.

La frecuencia de reautenticación se configura con la reauth-frequency instrucción en el niveledit security ike policy policy-namede jerarquía []. La reautenticación se deshabilita estableciendo la frecuencia de reautenticación en 0 (valor predeterminado). Los interlocutores no negocian la frecuencia de reautenticación, y cada interlocutor puede tener su propio valor de frecuencia de reautenticación.

Características compatibles

La reautenticación de IKEv2 se admite con las siguientes características:

  • Iniciadores o respondedores IKEv2

  • Detección de punto muerto (DPD)

  • Enrutadores virtuales y interfaces de túnel seguro (st0) en enrutadores virtuales

  • Traducción de direcciones de red transversal (TDR-T)

  • Clústeres de chasis en modo activo-activo y activo-pasivo para SRX5400, SRX5600 y dispositivos de SRX5800

  • Actualización del software en servicio (emisión) en dispositivos SRX5400, SRX5600 y SRX5800

  • Actualización o inserción de una nueva unidad de procesamiento de servicios (SPU) con el procedimiento de actualización de hardware en servicio (ISHU)

Límites

Tenga en cuenta las siguientes consideraciones cuando utilice la reautenticación de IKEv2:

  • Con TDR-T, puede crearse una nueva SA de ICR con puertos diferentes de la ICR SA anterior. En esta situación, es posible que no se elimine el SA ICR antiguo.

  • En un escenario TDR-T, el iniciador detrás del dispositivo TDR puede convertirse en el contestador después de una nueva autenticación. Si la sesión de TDR expira, el dispositivo TDR podría descartar los nuevos ICR paquetes que puedan llegar a un puerto diferente. TDR-T keepalive o DPD deben estar habilitadas para mantener activas las TDR sesión. Para AutoVPN, recomendamos que la frecuencia de reautenticación configurada en los radios sea más pequeña que la frecuencia de reautenticación configurada en el concentrador.

  • En función de la frecuencia de reautenticación, el iniciador o el contestador de la SA de ICR original puede iniciar una nueva ICR SA. Debido a que la carga de la configuración y la autenticación del Protocolo de autenticación extensible (EAP) requieren que la misma entidad inicie la SA de ICR, ésta no es compatible con la autenticación EAP ni con ICR la carga de configuración.

ICR de acceso (autenticación basada en certificados)

Jerarquía multinivel para autenticación de certificados

La autenticación basada en certificados es un método de autenticación compatible con serie SRX dispositivos durante la negociación de ICR. En redes de gran tamaño, varias entidades emisoras de certificados (CA) pueden emitir certificados end Entity (EE) para sus dispositivos finales respectivos. Es habitual disponer de entidades emisoras 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 en la red deben estar firmados por la misma CA. Todos los dispositivos Firewall deben tener el mismo certificado de CA inscrito para validar el certificado del mismo nivel. La carga de certificado enviada durante el ICR negociación solo contiene certificados EE.

De manera alternativa, la carga de certificado enviada durante la negociación de ICR puede contener una cadena de EE y certificados de 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 elemento del mismo nivel local.

El administrador de red debe asegurarse de que todos los interlocutores que participan en una negociación de ICR tengan al menos una entidad emisora de certificados de confianza común en sus respectivas cadenas de certificado. La entidad emisora de certificados de confianza común no tiene que ser necesariamente la entidad emisora raíz. El número de certificados de la cadena, incluidos los certificados de EEs y la de la mayor parte de la entidad emisora en la cadena, no puede ser superior a 10.

A partir de Junos OS versión 18.1 R1, se puede llevar a cabo la validación de una ICR del mismo nivel configurada con un servidor de CA especificado o con un grupo de servidores de entidad emisora. Con las cadenas de certificados, la entidad emisora raíz debe coincidir con el grupo de CA de confianza o el servidor de CA configurado en la Directiva de ICR

En el ejemplo de jerarquía de CA Figura 8que se muestra en la, CA raíz es la entidad emisora de certificados de confianza común para todos los dispositivos de la red. Raíz-CA emite certificados de CA para las CA de ingeniería y ventas, que se identifican como ENG-California y sales-CA, respectivamente. La CA ENG emite certificados de entidad emisora para las CA de desarrollo y garantía de calidad, que se identifican como dev-CA y QA-CA respectivamente. Host-A recibe su certificado EE de dev-CA, mientras que host-B recibe su certificado EE de sales-CA.

Figura 8: Jerarquía multinivel para la autenticación basada en certificadosJerarquía multinivel para la autenticación basada en certificados

Cada dispositivo final debe estar cargado con los certificados de la entidad emisora en su jerarquía. Los hosts a deben tener certificados raíz-CA, ENG-CA y dev-CA; Los certificados de CA y AC-CA no son necesarios. Host-B debe tener certificados raíz de CA y de ventas-CA. Los certificados se pueden cargar manualmente en un dispositivo o inscribirse con el proceso de inscripción de certificados simple (SCEP).

Cada dispositivo de extremo debe estar configurado con un perfil de CA para cada CA de la cadena de certificados. El resultado siguiente muestra los perfiles de CA configurados en host-A:

El resultado siguiente muestra los perfiles de CA configurados en host-B:

Ejemplo Configurando un dispositivo para validación de cadena de certificado de mismo nivel

Este ejemplo muestra cómo configurar un dispositivo para las cadenas de certificados que se utilizan para validar los dispositivos del mismo nivel durante ICR negociación.

Aplicables

Antes de comenzar, obtenga la dirección de la entidad EMISORa de certificados y la información que requieren (como la contraseña de desafío) cuando envíe solicitudes para certificados locales.

Descripción general

Este ejemplo muestra cómo configurar un dispositivo local para las cadenas de certificados, inscribir CA y certificados 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 del host-A Figura 9, como se muestra en la. Un perfil de AC dinámico se crea automáticamente en host-A para permitir que host-A descargue la CRL de Sales-AC y compruebe el estado de revocación del certificado de Host-B.

Figura 9: Ejemplo de cadena de certificadosEjemplo de cadena de certificados

En este ejemplo, se muestra la configuración VPN de IPsec para la negociación de la fase 1 y la fase 2 para el host-A. El dispositivo del mismo nivel (host-B) debe configurarse correctamente para que las opciones Phase 1 y Phase 2 se negocien satisfactoriamente y se establezcan asociaciones de seguridad (SA). Consulte configuración de identificadores de ICR remotos para VPN de sitio a sitio para obtener ejemplos acerca de la configuración de dispositivos del mismo nivel para VPN.

Automática

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, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los [edit] comandos en la CLI en el nivel de jerarquía y, a continuación, entrar commit desde el modo de configuración.

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte uso del editor de CLI en el modo de configuración en la guía del usuario de CLI.

Para configurar perfiles de CA:

  1. Cree el perfil de CA para root-CA.

  2. Cree el perfil de CA para ENG-CA.

  3. Cree el perfil de CA para dev-CA.

Resultados

Desde el modo de configuración, escriba el show security pki comando para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración de este ejemplo para corregirlo.

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Inscribir certificados

Procedimiento paso a paso

Para inscribir certificados:

  1. Inscriba los certificados de la entidad emisora.

    Escriba yes en los indicadores para cargar el AC certificado.

  2. Compruebe que los certificados de la CA están inscritos en el dispositivo.

  3. Compruebe la validez de los certificados de CA inscritos.

  4. Generar un par de claves.

  5. Inscriba el certificado local.

  6. Compruebe que el certificado local está inscrito en el dispositivo.

  7. Compruebe la validez del certificado local inscrito.

  8. Compruebe la descarga de CRL para los perfiles de CA configurados.

Configurar las opciones de IPsec VPN

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los [edit] comandos en la CLI en el nivel de jerarquía y, a continuación, entrar commit desde el modo de configuración.

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte uso del editor de CLI en el modo de configuración en la guía del usuario de CLI.

Para configurar las opciones de IPsec VPN:

  1. Configure las opciones de fase 1.

  2. Configure las opciones de fase 2.

Resultados

Desde el modo de configuración, escriba los show security ike comandos y show security ipsec para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración de este ejemplo para corregirlo.

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Comproba

Si la validación de certificados es correcta durante la negociación de ICR entre dispositivos del mismo nivel, se establecen tanto asociaciones de seguridad (SA) ICR como IPsec.

Si el certificado es válido, el ICR SA estará activo. La SA de ICR está inactiva y se forma una asociación de IPSEC si el certificado se revoca, solo si la comprobación de revocación se configuró en el dispositivo del mismo nivel

Comprobación del estado de la fase 1 ICR

Purpose

Compruebe el estado de la fase 1 ICR.

Intervención

Ingrese el show security ike security-associations comando desde el modo operativo.

Comprobando el estado de la fase 2 de IPsec

Purpose

Compruebe el estado de la fase 2 de IPsec.

Intervención

Ingrese el show security ipsec security-associations comando desde el modo operativo.

Error de SA de ICR e IPsec para un certificado revocado

Buscando certificados revocados

Relacionado

Si se produce un error en la validación del certificado ICR durante la negociación entre dispositivos par, compruebe que no se revocó el certificado del par. Un perfil AC dinámico permite que el dispositivo local descargue la CRL del AC par y compruebe el estado de revocación del certificado del par. Para habilitar perfiles de CA dinámicos revocation-check crl , la opción debe estar configurada en un perfil de CA principal.

Solución

Para comprobar el estado de revocación del certificado de un par:

  1. Identifique el perfil AC dinámico que mostrará la CRL para el dispositivo par ingresando el show security pki crl comando desde el modo operativo.

    El perfil de AC se crea automáticamente en host-A para que host-A pueda descargar la CRL del AC (ventas AC) del host-B y comprobar el estado de revocación del certificado del dynamic-001 par.

  2. Mostrar información de CRL para el perfil AC dinámico ingresando el show security pki crl ca-profile dynamic-001 detail comando desde el modo operativo.

    Escríba

    Se revocó el certificado de host B (número de serie 10647084).

Fragmentación ikEv2

Fragmentación de mensajes

La fragmentación de mensajes IKEv2, tal como se describe en RFC 7383, fragmentación de mensajes del protocolo Intercambio de claves por red versión 2 (IKEv2),permite que IKEv2 funcione en entornos en los que es posible que se bloqueen fragmentos de IP y los pares no puedan establecer una asociación de seguridad IPsec (SA). La fragmentación de IKEv2 divide un mensaje IKEv2 grande en un conjunto de otros más pequeños, de modo que no hay fragmentación en el nivel de IP. La fragmentación tiene lugar antes de que el mensaje original se cifre y se autentique, de forma que cada fragmento se cifre y se autentique por separado. En el receptor, los fragmentos se recolectan, comprueban, descifran y se combinan en el mensaje original.

Para que se produzca la fragmentación de IKEv2, ambos interlocutores VPN deben indicar la compatibilidad con la fragmentación mediante la inclusión de la carga de notificación IKEV2_FRAGMENTATION_SUPPORTED en IKE_SA_INIT Exchange. Si ambos interlocutores indican compatibilidad de fragmentación, depende del iniciador del intercambio de mensajes determinar si se utiliza la fragmentación IKEv2 o no.

En serie SRX dispositivos, se permite un máximo de 32 fragmentos por mensaje IKEv2. Si el número de fragmentos del mensaje IKEv2 que se va a enviar o recibir es superior a 32, los fragmentos se eliminarán y no se establecerá el túnel. No se admite la retransmisión de fragmentos de mensajes individuales

Automática

En los dispositivos serie SRX, la fragmentación de IKEv2 está habilitada de forma predeterminada para los mensajes IPv4 e IPv6. Para deshabilitar la fragmentación de IKEv2 disable , use la instrucciónedit security ike gateway gateway-name fragmentationen el nivel de jerarquía []. 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 el 500 y el 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 del paquete configurado está fragmentado.

Una vez habilitada o habilitada la fragmentación de IKEv2 o se cambie el tamaño del fragmento de paquete, se desconectarán los túneles VPN alojados en la puerta de enlace de ICR e ICR, y se renegociarán las SA IPsec.

ADVERTENCIAS

Las siguientes características no se admiten con la fragmentación IKEv2:

  • Detección de MTU de ruta de acceso.

  • SNMP.

ICR política de desarrollo con un sistema de AC

En este ejemplo se muestra cómo enlazar un servidor de CA de confianza a una directiva de ICR del elemento del mismo nivel.

Antes de comenzar, debe disponer de una lista de todas las entidades de certificación de confianza que desea asociar con la Directiva de ICR del interlocutor.

Puede asociar una directiva de ICR a un perfil único de CA de confianza o a un grupo de CA de confianza. Para establecer una conexión segura, la puerta de enlace de ICR usa la Directiva de ICR para limitarse al grupo configurado de entidades emisoras (perfiles de CA) mientras se valida el certificado. No se valida un certificado emitido por cualquier fuente distinta de la CA de confianza o el grupo de CA de confianza. Si hay una solicitud de validación de certificado procedente de una directiva de ICR, el perfil de CA asociado de la Directiva de ICR validará el certificado. Si una directiva de ICR no está asociada con ninguna entidad emisora de certificados, entonces, de forma predeterminada, el certificado será validado por cualquiera de los perfiles de CA configurados.

En este ejemplo, se crea un perfil root-ca de CA con el root-ca-identity nombre y se asocia a al 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.

  1. Crear un perfil de CA y asociar un identificador de CA al perfil.
  2. Definir una propuesta de ICR y el método de autenticación de propuesta de ICR.
  3. Definir el grupo Diffie-Hellman, el algoritmo de autenticación, un algoritmo de cifrado para la propuesta de ICR.
  4. Configure una directiva de ICR y asocie la Directiva con la propuesta de ICR.
  5. Configure un identificador de certificado local para la Directiva ICR.
  6. Defina la entidad emisora de certificados que se utilizará para la Directiva de ICR.

Para ver los perfiles de CA y los grupos de CA de confianza configurados show security pki en su dispositivo, ejecute el comando.

El show security ike comando muestra el grupo de perfiles de CA bajo la directiva ike_policy ICR denominada y el certificado asociado a la Directiva de ICR.

Configurar-túnel de establecimiento de sólo respuesta en ICR

Este tema muestra cómo configurar los túneles: solo responden en Intercambio de claves por red (ICR). Iniciar los túneles desde el interlocutor remoto y enviar el tráfico a través de todos los túneles. Especifica cuándo se activa ICR.

A partir de Junos OS versión 19.1R1, en la línea de dispositivos SRX5000, la opción establecer túneles admite los valores y en el nivel responder-onlyresponder-only-no-rekey de [edit security ipsec vpn vpn-name] jerarquía.

Las opciones y se admiten en la línea de dispositivos responder-only SRX5000 con una tarjeta responder-only-no-rekey SPC3 solo si la está junos-ike-package instalada. Estas opciones solo se admiten en una VPN de sitio a sitio. Estas opciones no se admiten en vpn automática.

Las opciones y no establecen ningún túnel VPN desde el dispositivo, por lo que el túnel VPN se responder-only inicia desde el par responder-only-no-rekey remoto. Cuando configure, un túnel establecido vuelve a clave ICR y IPsec según los valores de vida responder-only ICR e IPsec configurados. Cuando configure, un túnel establecido no reclame desde el dispositivo y depende del par remoto responder-only-no-rekey para iniciar la reclame. Si el interlocutor remoto no inicia la regeneración de claves, la destrucción del túnel se produce cuando caduca la duración dura.

Antes de empezar:

Para configurar el aprobador por el túnel en ICR:

  1. Configurar-solo respondedor de túnel
  2. Confirme su configuración introduciendo el show security ipsec vpn IPSEC_VPN comando.
  3. Configurar-túnel solo respondedor-sin regeneración de claves
  4. Confirme su configuración introduciendo el show security ipsec vpn IPSEC_VPN comando.

    En el caso de varios objetos de VPN, tendrá prioridad el modo de solo respondedor. Si alguna de las VPN de una puerta de enlace está configurada con modo de solo respondedor, todas las VPN en la puerta de enlace se deben configurar con el modo de solo respondedor.

Tabla de historial de versiones
Liberación
Descripción
18.1R1
A partir de Junos OS versión 18.1 R1, se puede llevar a cabo la validación de una ICR del mismo nivel configurada con un servidor de CA especificado o con un grupo de servidores de entidad emisora.