Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuración de interfaces de servicios

Descripción general de nomenclatura de interfaz de servicios

Cada interfaz tiene un nombre de interfaz, el cual especifica el tipo de medio, la ranura en la que se encuentra la FPC, la ubicación en la FPC en la que está instalada la PIC y el puerto PIC. El nombre de interfaz identifica de forma exclusiva a un conector de red individual en el sistema. Utilice el nombre de interfaz al configurar interfaces y cuando habilite varias funciones y propiedades, como protocolos de enrutamiento, en interfaces individuales. El sistema utiliza el nombre de interfaz cuando se muestra información de la interfaz, por ejemplo, en el show interfaces comando.

El nombre de interfaz se representa mediante una parte física, una parte lógica y una parte de canal con el siguiente formato:

La parte de canal del nombre es opcional para todas las interfaces, excepto las interfaces canalizadas DS3, E1, OC12 y STM1.

La parte física de un nombre de interfaz identifica el dispositivo físico, el cual corresponde a un único conector de red físico. Esta parte del nombre de interfaz tiene el siguiente formato:

type es el tipo de medio, el cual identifica el dispositivo de red. En el caso de las interfaces de servicio, puede ser uno de los siguientes:

  • ams: interfaz de multiservicios agregados (AMS). Una interfaz AMS es un conjunto de interfaces de servicios que puede funcionar como una sola interfaz. Una interfaz AMS se indica amsN como en la configuración, N donde es un número único que identifica una interfaz AMS (por ejemplo, ams0). Las interfaces miembro de una interfaz AMS se identifican en la configuración con un mams- prefijo (por ejemplo, mams-1/2/0).

  • cp: interfaz de recopilador de flujo.

  • es: interfaz de cifrado.

  • gr— Interfaz de túnel de encapsulación de enrutamiento genérico.

  • gre: esta interfaz se genera internamente y no se puede configurar.

  • ip— interfaz de túnel de encapsulación IP sobre IP.

  • ipip: esta interfaz se genera internamente y no se puede configurar.

  • ls: interfaz de servicios de vínculo.

  • lsq: interfaz de cola inteligente (IQ) de servicios de vínculo; también se usa para servicios de voz.

  • mams: interfaz de miembro en una interfaz AMS.

  • ml— Interfaz multilink.

  • mo: interfaz de servicios de supervisión. La interfaz lógica mo-fpc/pic/port.16383 es una interfaz noconfigurable generada internamente para el tráfico de control del enrutador.

  • ms: interfaces multiservicios en tarjetas de interfaces modulares (MS-MIC) y concentradores de puertos modulares multiservicios (MS-MPC).

  • mt— Interfaz de túnel de multidifusión. Esta interfaz se genera de forma automática, pero puede configurar propiedades en ella si es necesario.

  • mtun: esta interfaz se genera internamente y no se puede configurar.

  • rlsq— Interfaz LSQ de redundancia.

  • rsp: interfaz de servicios adaptables con redundancia.

  • si: interfaz en línea de servicios, configurada únicamente en enrutadores serie MX3D.

  • sp— Interfaz de servicios adaptable. La interfaz lógica sp-fpc/pic/port.16383 es una interfaz noconfigurable generada internamente para el tráfico de control del enrutador.

  • tap: esta interfaz se genera internamente y no se puede configurar.

  • vt— Interfaz de túnel de circuito cerrado virtual.

Habilitar paquetes de servicio

Para las AS, las CPC multiservicios, las DPC multiservicios y el módulo interno de servicios adaptables (ASM) en el enrutador de M7i, hay dos paquetes de servicio: capa 2 y capa 3. Ambos paquetes de servicio se admiten en todas las interfaces de servicios adaptables, pero solo puede habilitar un paquete de servicio por PIC, con la excepción de un paquete combinado compatible con el ASM. En un solo enrutador, puede habilitar ambos paquetes de servicio instalando dos o más CPC en la plataforma.

Nota:

El motor de enrutamiento cambio automático (GRES) se habilita automáticamente en todas las PIC y DPC de servicios, excepto en la PIC ES. Se admite en todos los M Series, serie MX y serie T, excepto en los enrutadores tx Matrix. Los servicios de capa 3 deben conservar el estado después de la conmutación, pero los servicios de capa 2 se reiniciarán. En el caso de los servicios IPsec, Intercambio de claves por red (ICR) no se almacenan y se deben reiniciar después de la conmutación. Para obtener más información acerca de GRES, consulte Junos OS del usuario de alta disponibilidad.

Habilitar paquetes de servicio por PIC, no por puerto. Por ejemplo, si configura el paquete de servicio de capa 2, toda la PIC utilizará el paquete configurado. Para habilitar un paquete de servicio, incluya la instrucción service-package en el nivel [edit chassis fpc slot-number pic pic-number adaptive-services] de jerarquía y especifique layer-2 o layer-3:

Para determinar qué paquete admite una PIC de AS, show chassis hardware emita el comando: si la PIC admite el paquete de capa 2, Link Services IIse muestra como y, si admite el paquete de capa 3, Adaptive Services IIse muestra como . Para determinar qué paquete admite una PIC de varios servicios, emita el show chassis pic fpc-slot slot-number pic-slot slot-number comando. El Package campo muestra el valor Layer-2 o Layer-3.

Nota:

El ASM tiene una opción predeterminada (layer-2-3) que combina las funciones disponibles en los paquetes de servicios de capa 2 y capa 3.

Después de confirmar un cambio en el paquete de servicio, la PIC se desconecta y, luego, vuelve a estar en línea de inmediato. No es necesario que tome la PIC de forma manual fuera de línea y en línea.

Nota:

Cambiar el paquete de servicio hace que se pierda toda la información de estado asociada con el paquete de servicio anterior. Solo debe cambiar el paquete de servicio cuando no haya tráfico activo en la PIC.

Los servicios admitidos en cada paquete difieren según la PIC y el tipo de plataforma. En la tabla 1 se enumeran los servicios admitidos en cada paquete de servicio para cada PIC y plataforma.

En las CPC de AS y multiservicios, la compatibilidad de servicios de vínculo incluye componentes de CoS de Junos OS, LFI (FRF.12), MLFR de extremo a extremo (FRF.15), MLFR UNI NNI (FRF.16), MLPPP (RFC 1990) y MLPPP multiclase. Para obtener más información, consulte Capacidades e interfaces del paquete de servicio de capa 2 y capacidades e interfaces del paquete de servicio de capa 2.

Nota:

El AS PIC II para el servicio de capa 2 se dedica a admitir solo el paquete de servicio de capa 2.

Tabla 1: servicios de PIC AS y multiservicios por paquete de servicio, PIC y plataforma

Servicios

ASM

AS/AS2 y LAS PICs multiservicios

AS/AS2 y LAS CPC multiservicios

PICs AS2 y Multiservicios

PICs AS2 y Multiservicios

Paquete de servicio de capa 2 (solo) M7i M7i, M10i y M20 M40e y M120 M320, T320 y T640 Matriz de transmisión

Servicios de vínculo:

         
  • Servicios de vínculo

No

  • MLPPP multiclase

No

Servicios de voz:

         
  • CRTP e LFI

No

  • CRTP y MLPPP

No

  • BPC A través de PPP (sin MLPPP)

No

Paquete de servicio de capa 3 (solo) M7i M7i, M10i y M20 M40e y M120 M320, T320 y T640 Matriz de transmisión

Servicios de seguridad:

         
  • Porque

No

  • Sistema de detección de intrusiones (IDS)

No

  • Ipsec

No

  • TDR

No

  • Firewall stateful

No

Servicios de cuentas:

         
  • Monitoreo activo

  • Captura dinámica de flujo (solo multiservicios 400 PIC)

No

No

No

No

  • Flujo de toque

Sí (solo M40e)

No

  • Supervisión pasiva (solo multiservicios 400 PIC)

No

Sí (solo M40e)

No

  • Duplicación de puertos

Servicios de LNS:

         
  • L2TP LNS

Sí (M7i y M10i único)

Sí (solo M120)

No

No

Servicios de voz:

         
  • BGF

No

Paquete de servicio de capa 2 y capa 3 (características comunes) M7i M7i, M10i y M20 M40e y M120 M320, T320 y T640 Matriz de transmisión

Servicios RPM:

         
  • Marca de hora del sondeo RPM

No

Servicios de túnel:

         
  • GRE (gr-fpc/pic/port)

  • Fragmentación GRE (clear-dont-fragment-bit)

No

No

  • clave GRE

No

  • Túneles IP-IP (ip-fpc/pic/port)

  • Túneles lógicos (lt-fpc/pic/port)

No

No

No

No

No

  • Túneles de multidifusión (mt-fpc/pic/port)

  • Desencaps encapsulación PIM (pd-fpc/pic/port)

  • Encapsulación PIM (pe-fpc/pic/port)

  • Túneles virtuales (vt-fpc/pic/port)

Capacidades e interfaces del paquete de servicio de capa 2

Cuando habilite el paquete de servicio de capa 2, puede configurar los servicios de vínculo. En las AS y multiservicios, y en el ASM, los servicios de vínculo incluyen compatibilidad con lo siguiente:

  • Componentes de Junos CoS: las interfaces y las capacidades del paquete de servicio de capa 2 describen cómo los componentes de Junos CoS funcionan en interfaces IQ (lsq) de servicios de vínculo. Para obtener información más detallada acerca de los componentes de Junos CoS, consulte la Guía del usuario Junos OS clase de servicio para dispositivos de enrutamiento.

  • LFI en vínculos de Frame Relay que utilizan fragmentación de extremo a extremo FRF.12: el estándar de FRF.12 está definido en la especificación FRF.12, Acuerdo de implementación de fragmentación de Frame Relay.

  • LFI en vínculos MLPPP.

  • MLFR UNI NNI (FRF.16):El estándar de FRF.16 se define en la especificación FRF.16.1, Acuerdo de implementación UNI/NNI multilink Frame Relay.

  • MLPPP (RFC 1990)

  • MLFR de extremo a extremo (FRF.15)

Para la interfaz LSQ en las AS y LASIC multiservicios, la sintaxis de configuración es casi la misma que para las PIC de multilink y de servicios de vínculo. La diferencia principal es el uso del descriptor de tipo de interfaz lsq en lugar de ml o ls. Cuando habilite el paquete de servicio de capa 2, se crean automáticamente las siguientes interfaces:

Los tipos grde interfaz , ip, mt, pdpey vt son interfaces de túnel estándar que están disponibles en las CPC de AS y Multiservicios, ya sea que habilite el paquete de servicio de capa 2 o de capa 3. Estas interfaces de túnel funcionan de la misma manera para ambos paquetes de servicio, excepto que el paquete de servicio de capa 2 no admite algunas funciones de túnel, como se muestra en la Tabla 1.

El tipo de lsq-fpc/pic/port interfaz es la interfaz IQ (lsq) de servicios de vínculo físico. Los tipos de lsq-fpc/pic/port:0 interfaz a través lsq-fpc/pic/port:N de representan paquetes FRF.16. Estos tipos de interfaz se crean cuando se incluye la mlfr-uni-nni-bundles instrucción en la [edit chassis fpc slot-number pic pic-number] opción. Para obtener más información, consulte Funcionalidades e interfaces del paquete de servicio de capa 2, y guía del usuario de interfaces de servicios de vínculo y multilink para dispositivos de enrutamiento.

Nota:

El tipo sp de interfaz se crea porque es necesario para el Junos OS. Para el paquete de servicio de capa 2, la sp interfaz no es configurable, pero no debe deshabilitarla.

Procedimiento de configuración de servicios

Siga estos pasos generales para configurar los servicios:

  1. Defina objetos de aplicación mediante la configuración de instrucciones en el nivel [edit applications] jerárquico.
  2. Defina reglas de servicio mediante la configuración de instrucciones en el nivel [edit services (ids | ipsec-vpn | nat | stateful-firewall) rule] jerárquico.
  3. A agrupa las reglas de servicio configurando la rule-set instrucción en el nivel [edit services (ids | ipsec-vpn | nat | stateful-firewall)] jerárquico.
  4. Grupo de conjuntos de reglas de servicio en una definición de conjunto de servicios mediante la configuración de la service-set instrucción en el nivel [edit services] jerárquico.
  5. Aplique el conjunto de servicios en una interfaz incluyendo la instrucción service-set en el nivel [edit interfaces interface-name unit logical-unit-number family inet service (input | output)] de jerarquía. Como alternativa, puede configurar interfaces lógicas como destino de salto siguiente incluyendo la next-hop-service instrucción en el nivel [edit services service-set service-set-name] de jerarquía.
    Nota:

    Puede configurar reglas de IDS, TDR y de estado dentro del mismo conjunto de servicios. Debe configurar los servicios IPsec en un conjunto de servicios independiente, aunque puede aplicar ambos conjuntos de servicios a la misma PIC.

Ejemplo: configuración de interfaces de servicio

La siguiente configuración incluye todos los elementos necesarios para configurar los servicios en una interfaz:

Configuración de la configuración predeterminada de tiempo de espera para interfaces de servicios

Puede especificar la configuración predeterminada global para ciertos temporizadores que se apliquen a toda la interfaz. Hay tres instrucciones de este tipo:

  • inactivity-timeout: establece el período de tiempo de espera de inactividad para los flujos establecidos, después de lo cual ya no son válidos.

  • open-timeout: establece el período de tiempo de espera para el establecimiento de sesión del Protocolo de control de transmisión (TCP), para su uso con defensas de syn-cookie contra intrusiones en la red.

  • close-timout: establece el período de tiempo de espera para el desgarro de la sesión del Protocolo de control de transmisión (TCP).

Para configurar una configuración para el período de tiempo de espera de inactividad, incluya la inactivity-timeout instrucción en el nivel [edit interfaces interface-name services-options] jerárquico:

El valor predeterminado es de 30 segundos. El intervalo de valores posibles va de 4 a 86.400 segundos. Cualquier valor que configure en la definición de protocolo de aplicación anula el valor especificado aquí; para obtener más información, consulte Configuración de propiedades de aplicación.

Para configurar una configuración para el período de tiempo de espera del establecimiento de sesión TCP, incluya la open-timeout instrucción en el nivel [edit interfaces interface-name services-options] de jerarquía:

El valor predeterminado es de 5 segundos. El intervalo de valores posibles va de 4 a 224 segundos. Cualquier valor que configure en la definición servicio de detección de intrusiones (IDS) reemplaza el valor especificado aquí; para obtener más información, consulte Configurar IDS reglas de desarrollo en una MS-CPC.

Para configurar una configuración para el período de tiempo de espera de desmontaje de la sesión TCP, incluya la close-timeout instrucción en el nivel [edit interfaces interface-name services-options] de jerarquía:

El valor predeterminado es 1 segundo. El intervalo de valores posibles va de 2 a 300 segundos.

Uso de mensajes keep-Alive para un mayor control de los tiempos de espera de inactividad de TCP

Los mensajes keep-alive se generan de forma automática para evitar tiempos de espera de inactividad de TCP. El número predeterminado de mensajes keep-alive es 4. Sin embargo, puede configurar el número de mensajes keep-actuales ingresando la tcp-tickles instrucción en el nivel [edit interaces interface-name service-options] jerárquico.

Cuando se genera el tiempo de espera para un flujo TCP bidireccional, se envían paquetes keep-alive para restablecer el temporizador. Si el número de paquetes consecutivos keep-alive enviados en un flujo alcanza el límite predeterminado o configurado, la conversación se elimina. Hay varias situaciones posibles, dependiendo inactivity-timer de la configuración de la cantidad máxima predeterminada o configurada de mensajes de mantener vivo.

  • Si el valor configurado de los mensajes keep-actuales inactivity-timeout es cero y NO está configurado (en cuyo caso se usa el valor predeterminado de tiempo de espera de 30), no se envían paquetes keep-alive. La conversación se elimina cuando cualquier flujo de la conversación está inactivo durante más de 30 segundos.

  • Si el valor configurado de los mensajes keep-actuales inactivity-timeout es cero y está configurado, no se envían paquetes keep-alive y la conversación se elimina cuando cualquier flujo de la conversación está inactivo para más que el valor de tiempo de espera configurado.

  • Si el número máximo predeterminado o configurado de mensajes keep-alive es algún entero positivo, inactivity-timeout y cualquiera de los flujos de una conversación está inactivo para más que el valor predeterminado o configurado para los paquetes keep-alive se envían. Si los hosts no responden al número configurado de paquetes consecutivos keep-alive, la conversación se elimina. El intervalo entre paquetes keep-alive será de 1 segundo. Sin embargo, si el host devuelve un paquete ACK, el flujo correspondiente se activa y los paquetes de mantener vivo no se envían hasta que el flujo vuelve a estar inactivo.

Configuración del registro del sistema para interfaces de servicios

Se especifican propiedades que controlan cómo se generan los mensajes de registro del sistema para la interfaz como un todo. Si configura valores diferentes para las mismas [edit services service-set service-set-name] propiedades en el nivel de jerarquía, los valores de conjunto de servicios reemplazan los valores configurados para la interfaz. Para obtener más información sobre cómo configurar propiedades de conjunto de servicios, consulte Configurar el registro del sistema para conjuntos de servicios.

Nota:

A partir de Junos OS release 14.2R5, 15.1R3 y 16.1R1, para interfaces de multiservicios (ms-), no puede configurar el registro del sistema para PPG y ALG incluyendo las instrucciones syslog-logs y alg-logs en el nivel de jerarquía [edit services-set service-set service-set-name syslog host class]. Se muestra un mensaje de error si intenta confirmar una configuración que contiene las opciones de los registros de los p.s. y los registros alg para definir el registro del sistema para ELS y las ALG para interfaces ms-.

Para configurar los valores de registro predeterminados del sistema para toda la interfaz, incluya la syslog instrucción en el nivel [edit interfaces interface-name services-options] de jerarquía:

Configure la host instrucción con un nombre de host o una dirección IP que especifique el servidor de destino del registro del sistema. El nombre de local host dirige los mensajes de registro del sistema al motor de enrutamiento. Para los servidores de registro del sistema externos, se debe tener acceso al nombre de host desde la misma instancia de enrutamiento a la que se entrega el paquete de datos inicial (que desencadenó el establecimiento de sesión). Solo puede especificar un nombre de host de registro del sistema.

A partir de Junos OS versión 17.4R1, puede configurar hasta un máximo de cuatro servidores de registro del sistema (combinación de hosts de registro del sistema local y recopiladores de registros del sistema remoto) para cada conjunto de servicios para la interfaz ms [edit interfaces interface-name services-options] bajo jerarquía.

La tabla 2 enumera los niveles de gravedad que puede especificar en instrucciones de configuración en el nivel [edit interfaces interface-name services-options syslog host hostname] jerárquido. Los niveles desde emergency hasta están info en orden desde la mayor gravedad (mayor efecto sobre el funcionamiento) hasta la más baja.

Tabla 2: Niveles de gravedad del mensaje de registro del sistema

Nivel de gravedad

Descripción

any

Incluye todos los niveles de gravedad

emergency

Pánico del sistema u otra condición que hace que el enrutador deje de funcionar

alert

Condiciones que requieren corrección inmediata, como una base de datos del sistema dañada

critical

Condiciones críticas, como errores de disco duro

error

Condiciones de error que generalmente tienen consecuencias menos graves que los errores en los niveles de emergencia, alerta y críticos

warning

Condiciones que garantizan el monitoreo

notice

Condiciones que no son errores, pero que pueden justificar un manejo especial

info

Eventos o condiciones de interés no ambientales

Recomendamos establecer el nivel de gravedad del registro del sistema en durante error el funcionamiento normal. Para supervisar el uso de recursos de PIC, establezca el nivel en warning. Para recopilar información acerca de un ataque de intrusiones cuando se detecte un error en el sistema de detección de intrusiones, establezca el nivel en notice para una interfaz específica. Para depurar una funcionalidad de configuración Traducción de direcciones de red registro (TDR), establezca el nivel en info.

Para obtener más información acerca de los mensajes de registro del sistema, consulte el Explorador de registros del sistema.

Para usar un código de instalación determinado para todo el registro en el host de registro del sistema especificado, incluya la facility-override instrucción en el nivel [edit interfaces interface-name services-options syslog host hostname] de jerarquía:

Las instalaciones compatibles incluyen authorization, daemonftp, kernel, user, y local0 through local7.

Para especificar un prefijo de texto para todo el registro en este host de registro del sistema, incluya la log-prefix instrucción en el nivel [edit interfaces interface-name services-options syslog host hostname] de jerarquía:

Configuración del protocolo Syslog TLS en MS-MPC y MS-MIC

capa de transporte de seguridad de red (TLS)

A partir de Junos OS versión 19.1R1, puede configurar capa de transporte Security (TLS) para los mensajes syslog generados por los servicios que se ejecutan en las tarjetas de servicio MS-MPC o MS-MIC en un enrutador MX. Los servicios pueden ser uno de los siguientes:

  • Junos Address Aware (antes conocido como TDR feaures)

  • Junos VPN Site Secure (antes denominadas características de IPsec)

  • Junos Network Secure (conocidas anteriormente como funciones de firewall stateful)

capa de transporte Security (TLS) es un protocolo a nivel de aplicación que proporciona tecnología de cifrado para Internet. TLS depende de certificados y pares de intercambio de claves pública y privada para este nivel de seguridad. Es el protocolo de seguridad más utilizado para las aplicaciones que requieren el intercambio seguro de datos a través de una red, como transferencias de archivos, conexiones VPN, mensajes instantáneas y voz sobre IP (VoIP).

El protocolo TLS se utiliza para el intercambio de certificados, la autenticación mutua y los cifrados de negociación para proteger la transmisión de posibles manipulaciones y escuchas. Tls a veces se denomina capa de conexión segura (SSL). TLS y SSL no son interoperables, aunque TLS actualmente proporciona cierta compatibilidad con versiones anteriores.

Beneficios de TLS

TLS garantiza la transmisión segura de datos entre un cliente y un servidor mediante una combinación de privacidad, autenticación, confidencialidad e integridad de datos.

Tres servicios esenciales de TLS

El protocolo TLS está diseñado para proporcionar tres servicios esenciales a las aplicaciones que se ejecutan por encima de él: cifrado, autenticación e integridad de datos.

  • Cifrado: para establecer un canal de datos criptográficomente seguro, el servidor y el cliente deben coincidir en qué conjuntos de cifrado se utilizan y las claves que se utilizan para cifrar los datos. El protocolo TLS especifica una secuencia de apretón de manos bien definida para llevar a cabo este intercambio. TLS utiliza criptografía de clave pública, lo que permite al cliente y al servidor negociar una clave confidencial compartida sin tener que establecer ningún conocimiento previo entre sí, y hacerlo a través de un canal no cifrado.

  • Autenticación: como parte del protocolo TLS, el protocolo permite que tanto el servidor como el cliente autentificar su identidad. La confianza implícita entre el cliente y el servidor (porque el cliente acepta el certificado generado por el servidor) es un aspecto importante de TLS. Es sumamente importante que la autenticación del servidor no se vea comprometida; sin embargo, en realidad, los certificados y certificados auto firmados con anomalías son abundantes. Las anomalías pueden incluir certificados caducados, instancias de nombre común que no coincidan con un nombre de dominio, etc.

  • Integridad: con el cifrado y la autenticación en su sitio, el protocolo TLS hace un mecanismo de trama de mensajes y firma cada mensaje con un código de autenticación de mensajes (MAC). El algoritmo mac hace la suma de comprobación eficaz y las claves se negocian entre el cliente y el servidor.

Protocolo TLS

Cada sesión de TLS comienza con un apretón de manos durante el cual el cliente y el servidor coinciden en la clave de seguridad específica y los algoritmos de cifrado que se deben usar para esa sesión. En este momento, el cliente también autentica el servidor. Opcionalmente, el servidor puede autenticar al cliente. Una vez completado el contacto, puede comenzar la transferencia de datos cifrados.

Cifrar el tráfico de Syslog con TLS

El protocolo TLS garantiza que los mensajes syslog se envíen y reciban de forma segura a través de la red. TLS usa certificados para autenticar y cifrar la comunicación. El cliente autentica el servidor mediante la solicitud de su certificado y clave pública. Opcionalmente, el servidor también puede solicitar un certificado al cliente, por lo que también es posible la autenticación mutua.

Un certificado en el servidor que identifique al servidor y el certificado de autoridad de certificación (AC) emitido por el servidor debe estar disponible con el cliente para TLS para cifrar el tráfico syslog.

Para la autenticación mutua del cliente y el servidor, debe estar disponible en el servidor un certificado con el cliente que identifique al cliente y el certificado de AC emitido por el cliente. La autenticación mutua garantiza que el servidor syslog acepte solo mensajes de registro de clientes autorizados.

TLS se usa como un transporte seguro para contrarrestar todas las amenazas principales a syslog enumeradas a continuación:

  • Confidencialidad para contrarrestar la divulgación del contenido del mensaje.

  • Comprobación de integridad para contrarrestar modificaciones de un mensaje salto a salto.

  • Autenticación de servidor o mutua para contrarrestar el enmascaramiento.

Versiones de TLS

A continuación, se encuentran las versiones de TLS:

  • TLS versión 1.0: proporciona comunicación segura a través de las redes proporcionando privacidad e integridad de datos entre las aplicaciones que se comunican

  • TLS versión 1.1: esta versión mejorada de TLS proporciona protección contra ataques de encadenamiento de bloques de cifrado (CBC).

  • TLS versión 1.2: esta versión mejorada de TLS proporciona una flexibilidad mejorada para la negociación de algoritmos criptográficos.

Descripción general de la configuración del protocolo de transporte TLS para mensajes syslog

A partir de Junos OS versión 19.1R1, puede configurar un enrutador serie MX para usar capa de transporte Security (TLS) para los mensajes syslog generados por los servicios que se ejecutan en las tarjetas de servicio MS-MPC o MS-MIC en un enrutador serie MX.

Los siguientes paquetes de servicios están preinstalados y preconfigurados en MS-MIC y MS-MS-MCS:

  • Junos Traffic Vision (antes llamado Jflow)

  • Junos Address Aware (conocidas anteriormente como funciones TDR funciones)

  • Junos VPN Site Secure (antes denominadas características de IPsec)

  • Junos Network Secure (conocida anteriormente como función de firewall stateful)

  • Paquete de PIC de base de criptodivisas de Junos Services

  • Puertas de enlace de nivel de aplicación de servicios Junos

Puede configurar un máximo de cuatro servidores syslog para cada conjunto de servicios y enviar datos cifrados a los servidores.

Los mensajes syslog se envían a través de una conexión dedicada creada para un conjunto determinado de parámetros de configuración únicos:

  • Dirección IP de origen

  • Dirección IP de destino (servidor TCP/TLS)

  • Puerto

  • Nombre de perfil SSL (para la conexión TLS)

    Nota:

    Si el perfil ssl no está configurado en la jerarquía tcp-log, entonces es un transporte TCP que no es TLS.

Nota:

Si hay varios conjuntos de servicios que tengan la configuración de registro TCP/TLS con los mismos parámetros mencionados anteriormente, los registros generados a partir de las sesiones de todos esos conjuntos de servicios comparten la misma conexión.

Esta función es compatible tanto con IPv4 como con IPv6.

Nota:

La conexión TCP/TLS configurada permanece activa hasta que la configuración esté presente, incluso si no hay eventos de registro.

La compatibilidad con la configuración de sicólogo TCP/TLS se proporciona para el registro seguro y confiable solo en el plano de datos.

Para servicios múltiples agregados (AMS) con varios miembros activos, cada miembro crea una conexión TCP/TLS independiente y los syslog generados por cada PIC miembro se envían a través de sus conexiones únicas.

Configuración de TCP/TLS para mensajes syslog

Puede usar los protocolos de transporte TCP/TLS para enviar mensajes syslog de manera confiable y segura a servidores syslog externos.

Para configurar los protocolos TCP/TLS para mensajes syslog:

  1. Configure el perfil de iniciación de SSL.
    Nota:

    La configuración del perfil de iniciación de SSL es opcional si no utiliza la opción TLS/TCP para los mensajes syslog.

    protocol-version: el valor predeterminado se establece en all. Cuando se establece en all SSL versión 3 y TLSL versión 1 se maneja. Se recomienda usar de forma predeterminada.

    cifrados preferidos:strong cifrados con fuerza de >= 168 bits. Se recomienda usar cifrados sólidos.

    Consulte inicio (Servicios) para configurar todos los parámetros de la instrucción de iniciación.

  2. Configure los parámetros de registro TCP.

    dirección de origen: dirección de origen para el registro tcp.

  3. Configure el perfil SSL para el registro TCP.

    [edit services service-set]
    user@router# set ss1 syslog host server -ip tcp-log ssl-profile ssl-profile-name
    

    perfil ssl: nombre de perfil SSL para el registro tcp

    Consulte perfil (iniciación de SSL) para configurar todas las opciones para el perfil ssl.

  4. [Opcional] Configure el nombre de instancia de enrutamiento para el registro tcp.

    vrf-name: nombre de instancia de enrutamiento para el registro tcp.

  5. Confirmar la configuración.

    Después de la confirmación, la configuración crea una nueva conexión TCP con conexión TLS si el perfil SSL está configurado.

  6. Compruebe la configuración con el show services tcp-log connections comando:

    La conexión syslog TCP/TLS se establece con la infraestructura de sesiones de datos L4 de servicios de MS-MPC y se puede rastrear el estado de la sesión con el siguiente comando:

    Nota:

    El id de sesión en ambos comandos debe coincidir con lo que se destacó anteriormente bold .

Tabla del historial de versiones
Lanzamiento
Descripción
14.2R5
A partir de Junos OS release 14.2R5, 15.1R3 y 16.1R1, para interfaces de multiservicios (ms-), no puede configurar el registro del sistema para PPG y ALG incluyendo las instrucciones syslog-logs y alg-logs en el nivel de jerarquía [edit services-set service-set service-set-name syslog host class].