Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Descripción general de la configuración de TDR

Descripción general de la configuración de traducción de direcciones de red

Para configurar la traducción de direcciones de red (TDR), siga los pasos generales siguientes:

  1. Configure las direcciones de origen y destino. Para obtener más información, consulte Configuración de direcciones de origen y destino Descripción general de la traducción de direcciones de red.
  2. Defina las direcciones o prefijos, los rangos de direcciones y los puertos utilizados para TDR. Para obtener más información, consulte Descripción general de Configuración de conjuntos de direcciones y puertos para la traducción de direcciones de red
  3. Si procede, configure los grupos de direcciones para la traducción del puerto de direcciones de red (NAPT). Para obtener más información, consulte Descripción general de Configuración de conjuntos de direcciones para la traducción de puertos de direcciones de red (NAPT).
  4. Configure las reglas de TDR. Dentro de las reglas, incluya direcciones de coincidencia, condiciones de coincidencia, acciones y tipos de traducción. Para obtener más información, consulte Descripción general de reglas de traducción de direcciones de red.
  5. Configure conjuntos de servicios para el procesamiento de TDR. Dentro de cada conjunto de servicios, defina las interfaces para gestionar el tráfico entrante y saliente, así como una regla o conjunto de reglas de TDR. Para obtener más información, consulte Configuración de conjuntos de servicios para la traducción de direcciones de red.

Ver también

Configuración de direcciones de origen y destino Descripción general de la traducción de direcciones de red

Debe configurar una dirección específica, un prefijo o los límites del rango de direcciones:

  • Las siguientes direcciones, aunque válidas en inet.0, no se pueden utilizar para la traducción de TDR:

    • 0.0.0.0/32

    • 127.0.0.0/8 (circuito cerrado)

    • 128.0.0.0/16 (marciano)

    • 191.255.0.0/16 (marciano)

    • 192.0.0.0/24 (marciano)

    • 223.255.255.0/24 (marciano)

    • 224.0.0.0/4 (multidifusión)

    • 240.0.0.0/4 (reservado)

    • 255.255.255.255 (difusión)

    Las direcciones especificadas como válidas en la tabla de enrutamiento y no compatibles con la inet.0 traducción de TDR son orlonger tipos de filtro de coincidencia. No puede especificar ninguna región dentro de dichos prefijos de dirección en un conjunto TDR.

  • En enrutadores de la serie MX con MS-MPC y MS-MIC, si configura un conjunto de direcciones TDR con una longitud de prefijo igual o superior a /16, la PIC no contiene suficiente memoria para aprovisionar el conjunto configurado. Además, pueden producirse problemas de utilización de memoria si intenta configurar varios grupos cuyas direcciones IP totales combinadas superen /16. En tales circunstancias, se genera un mensaje de registro del sistema que indica que no se pudo crear el nombre del grupo TDR y que el conjunto de servicios no está activado. En MS-MPC y MS-MIC, no debe configurar agrupaciones TDR con longitudes de prefijo mayores o iguales a /16.

  • Puede especificar uno o varios prefijos de dirección IPv4 en la pool instrucción y en la from cláusula del término de regla TDR. Esto permite configurar la traducción de origen de una subred privada a una subred pública sin definir un término de regla para cada dirección de la subred. La traducción de destino no se puede configurar con este método. Para obtener más información, consulte Ejemplos: configurar reglas TDR.

  • Cuando configure TDR de origen estático, el tamaño de prefijo address que configure en el [edit services nat pool pool-name] nivel de jerarquía debe ser mayor que el source-address intervalo de prefijos configurado en el [edit services nat rule rule-name term term-name from] nivel de jerarquía. El source-address rango de prefijos también debe asignarse a una sola subred o rango de direcciones IPv4 o IPv6 en la pool instrucción. Cualquier dirección de agrupación que no sea utilizada por el rango de source-address prefijos no se utilizará. Los grupos no se pueden compartir.

  • Cuando se configura un tamaño de prefijo de agrupación de direcciones TDR con la address instrucción en el nivel de jerarquía [edit services nat pool nat-pool-name], las direcciones de subred y difusión no se incluyen en la lista de direcciones IP utilizables. Por ejemplo, si lo utiliza address 10.11.12.0/28 en un grupo TDR, las direcciones 10.11.12.0 (dirección de subred) y 10.11.12.15 (dirección de difusión) no están disponibles.

Nota:

Cuando se incluye una configuración TDR que cambia las direcciones IP, puede afectar a las funciones de ruta de reenvío en otras partes de la configuración del enrutador, como el uso de clase de origen (SCU), el uso de clase de destino (DCU), el reenvío basado en filtros u otras funciones destinadas a direcciones IP o prefijos específicos.

La configuración de TDR también puede afectar al funcionamiento del protocolo de enrutamiento, ya que las direcciones de interconexión, vecino e interfaz de protocolo se pueden modificar cuando los paquetes de protocolos de enrutamiento transitan por la PIC de servicios adaptables (AS) o multiservicios.

Ver también

Descripción general de la configuración de conjuntos de direcciones y puertos para la traducción de direcciones de red

Configuración de grupos TDR

Puede utilizar la pool instrucción para definir las direcciones (o prefijos), los rangos de direcciones y los puertos utilizados para la traducción de direcciones de red (TDR). Para configurar la información, incluya la pool instrucción en el [edit services nat] nivel de jerarquía.

A partir de Junos OS versión 14.2, configure el grupo de TDR de la siguiente manera. A partir de Junos OS versión 16.1, se admite la limit-ports-per-address instrucción.

En la versión 14.1 y anteriores de Junos OS, configure el grupo de TDR de la siguiente manera:

Para configurar grupos para TDR tradicional, especifique un grupo de destino o un grupo de origen.

Con el TDR de origen estático y el TDR de origen dinámico, puede especificar varias direcciones IPv4 (o prefijos) y rangos de direcciones IPv4. Se pueden admitir hasta 32 prefijos o rangos de direcciones (o una combinación) dentro de un solo grupo.

Con la TDR de destino estático, también puede especificar varios prefijos de dirección y rangos de direcciones en un solo término. Varios términos TDR de destino pueden compartir un grupo TDR de destino. Sin embargo, la máscara de red o el rango de la from dirección deben ser menores o iguales que la máscara de red o el rango de la dirección del grupo de destino. Si define el grupo para que sea mayor de lo necesario, no se utilizarán algunas direcciones. Por ejemplo, si define el tamaño del grupo como 100 direcciones y la regla especifica solo 80 direcciones, no se utilizarán las últimas 20 direcciones del grupo.

Para conocer las restricciones de tipos de traducción específicos, consulte Descripción general de las reglas de traducción de direcciones de red.

Con la TDR estática de origen, los prefijos y rangos de direcciones no pueden superponerse entre grupos separados.

En un rango de direcciones, el low valor debe ser un número menor que el high valor. Cuando se configuran varios rangos de direcciones y prefijos, los prefijos se agotan primero, seguidos de los rangos de direcciones.

Cuando se especifica un puerto para TDR de origen dinámico, los intervalos de direcciones se limitan a un máximo de 65 000 direcciones, para un total de (65 000 x 65 535) o 4 259 775 000 flujos. Un conjunto de TDR dinámico sin traducción de puertos de direcciones admite hasta 65 535 direcciones. No hay límite en el tamaño del conjunto para TDR de origen estático.

Preservar el rango y preservar la paridad

Puede configurar su TDR de carrier-grade (CGN) para conservar el rango o la paridad del puerto de origen del paquete cuando asigna un puerto de origen para una conexión de salida. Puede configurar las opciones conservar paridad y conservar intervalo en la definición de agrupación TDR incluyendo las preserve-range instrucciones and preserve-parity configuration en el [edit services nat pool poolname port] nivel de jerarquía.

La conservación del rango y la paridad se admiten en enrutadores serie MX con MS-DPC y en enrutadores serie M con PIC multiservicios MS-100, MS-400 y MS-500. La conservación del rango y la paridad son compatibles con enrutadores serie MX con MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS.

  • Conservar rango: RFC 4787, Requisitos de comportamiento de traducción de direcciones de red (TDR) para UDP de unidifusión, define dos rangos: de 0 a 1023 y de 1024 a 65.535. Cuando se configura la perilla preserve-range y el puerto entrante cae en uno de estos rangos, CGN asigna un puerto de ese rango solamente. Sin embargo, si no hay ningún puerto disponible en el rango, se produce un error en la solicitud de asignación de puertos y no se crea esa sesión. El error se refleja en los contadores y el registro del sistema, pero no se genera ningún mensaje de Protocolo de mensajes de control de Internet (ICMP). Si este potenciómetro no está configurado, la asignación se basa en el intervalo de puertos configurado sin tener en cuenta el intervalo de puertos que contiene el puerto de entrada. La excepción son algunas puertas de enlace a nivel de aplicación (ALG), como hello, que tienen zonas especiales.

  • Conservar paridad: cuando se configura el preserve-parity potenciómetro, CGN asigna un puerto con la misma paridad par o impar que el puerto de entrada. Si el número de puerto de entrada es par o impar, el número de puerto de salida debe ser par o impar. Si no hay disponible un número de puerto de la paridad deseada, se produce un error en la solicitud de asignación de puertos, no se crea la sesión y se descarta el paquete.

Especificar prefijos de origen y destino sin configurar un grupo

Puede especificar directamente el prefijo de origen o de destino utilizado en TDR sin configurar un grupo.

Para configurar la información, incluya la rule instrucción en el nivel de [edit services nat] jerarquía:

Descripción general de las reglas de traducción de direcciones de red

Para configurar una regla TDR, incluya la rule rule-name instrucción en el nivel de [edit services nat] jerarquía:

Cada regla debe incluir una match-direction instrucción que especifique la dirección en la que se aplica la coincidencia.

Nota:

Los enrutadores de la serie ACX solo input se admiten como la dirección de coincidencia.

Además, cada regla de TDR consta de un conjunto de términos, similar a un filtro de firewall. Un término consiste en lo siguiente:

  • from instrucción: especifica las condiciones de coincidencia y las aplicaciones que se incluyen y excluyen.

  • then instrucción: especifica las acciones y los modificadores de acción que debe realizar el software del enrutador.

En las siguientes secciones se explica cómo funcionan los componentes de las reglas de TDR:

Configuración de la dirección de coincidencia para reglas TDR

Cada regla debe incluir una match-direction instrucción que especifique la dirección en la que se aplica la coincidencia. Para configurar dónde se aplica la coincidencia, incluya la match-direction instrucción en el nivel de [edit services nat rule rule-name] jerarquía:

La dirección de coincidencia se utiliza con respecto al flujo de tráfico a través de la PIC Multiservices CPC y Multiservices. Cuando se envía un paquete a la PIC, la información de dirección se transporta junto con él. La dirección del paquete se determina en función de los siguientes criterios:

  • Con un conjunto de servicios de interfaz, la dirección del paquete viene determinada por si un paquete entra o sale de la interfaz en la que se aplica el conjunto de servicios.

  • Con un conjunto de servicio de salto siguiente, la dirección del paquete está determinada por la interfaz usada para enrutar el paquete a la CPC multiservicios o a la PIC multiservicios. Si se usa la interfaz interna para enrutar el paquete, se ingresa la dirección del paquete. Si se utiliza la interfaz externa para dirigir el paquete a la PIC o CPC, se emite la dirección del paquete. Para obtener más información acerca de las interfaces internas y externas, consulte Configurar conjuntos de servicios para aplicarlos a las interfaces de servicios.

  • En la CPC multiservicios y la PIC multiservicios, se realiza una búsqueda de flujo. Si no se encuentra ningún flujo, se procesa la regla. Se tienen en cuenta todas las reglas del conjunto de servicios. Durante el procesamiento de reglas, la dirección del paquete se compara con las direcciones de las reglas. Solo se tienen en cuenta las reglas con información de dirección que coincida con la dirección del paquete.

Configuración de condiciones de coincidencia en reglas TDR

Para configurar condiciones de coincidencia de TDR, incluya la from instrucción en el nivel de [edit services nat rule rule-name term term-name] jerarquía:

Para configurar la TDR tradicional, puede utilizar la dirección de destino, un rango de direcciones de destino, la dirección de origen o un rango de direcciones de origen como condición de coincidencia, de la misma manera que configuraría un filtro de firewall; Para obtener más información, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y agentes de policía de tráfico.

Como alternativa, puede especificar una lista de prefijos de origen o destino incluyendo la prefix-list instrucción en el [edit policy-options] nivel de jerarquía y, a continuación, incluyendo la destination-prefix-list instrucción or source-prefix-list en la regla de TDR. Para obtener un ejemplo, consulte Ejemplos: configuración de reglas de firewall de inspección de estado.

Si la translation-type instrucción de la then instrucción de la regla TDR se establece en stateful-nat-64, el intervalo especificado por la destination-address-range instrucción or the destination-prefix-list from debe estar dentro del intervalo especificado por la destination-prefix instrucción de la then instrucción.

Si al menos un término TDR dentro de una regla TDR tiene habilitada la funcionalidad de emparejamiento de agrupación de direcciones (APP) (al incluir la address-pooling instrucción en el [edit services nat rule rule-name term term-name then translated] nivel de jerarquía), todos los demás términos de la regla TDR que utilicen el mismo grupo de direcciones TDR que el grupo de direcciones para el término con APP habilitado deben tener APP habilitado. De lo contrario, si agrega un término de regla TDR sin habilitar APP a una regla que contiene otros términos con APP habilitado, todos los términos con APP habilitado en una regla TDR descartan flujos de tráfico que coincidan con los criterios especificados en la regla TDR.

En el caso de enrutadores serie MX con MS-MIC y MS-MPC, aunque la funcionalidad de emparejamiento de agrupación de direcciones (APP) está habilitada dentro de una regla de TDR (incluyendo la address-pooling instrucción en el [edit services nat rule rule-name term term-name then translated] nivel de jerarquía), es una característica de un conjunto de TDR. Este grupo de TDR para el que está habilitada la aplicación no se puede compartir con reglas de TDR que no tengan la aplicación configurada.

Cuando se configura TDR, si algún tráfico está destinado a las siguientes direcciones y no coincide con un flujo TDR o una regla TDR, el tráfico se interrumpe:

  • Direcciones especificadas en la instrucción cuando se utiliza la from destination-address traducción de destino

  • Direcciones especificadas en el conjunto TDR de origen cuando se utiliza la traducción de origen

Configuración de acciones en reglas TDR

Para configurar acciones TDR, incluya la then instrucción en el nivel de [edit services nat rule rule-name term term-name] jerarquía:

  • La no-translation instrucción le permite especificar las direcciones que desea excluir de la TDR.

    La no-translation instrucción se admite en enrutadores serie MX con MS-DPC y en enrutadores serie M con PIC multiservicios MS-100, MS-400 y MS-500. La no-translation instrucción se admite en enrutadores serie MX con MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS.

  • La system log instrucción le permite registrar una alerta en el recurso de registro del sistema.

  • Las destination-poolinstrucciones , destination-prefix, source-pooly source-prefix especifican la información de direccionamiento que se define incluyendo la pool instrucción en el nivel de jerarquía; para obtener más información, consulte Configuración de conjuntos de direcciones y puertos para Descripción [edit services nat] general de la traducción de direcciones de red.

  • La translation-type instrucción especifica el tipo de TDR utilizado para el tráfico de origen o destino. Las opciones son basic-nat-pt, basic-nat44, basic-nat66, dnat-44, dynamic-nat44napt-ptstateful-nat464napt-44napt-66, twice-basic-nat-44stateful-nat64 twice-dynamic-nat-44y .twice-napt-44

Nota:

En la versión 13.2 y anteriores de Junos OS, la CLI no aplicaba la siguiente restricción: si la translation-type instrucción en la then instrucción de una regla TDR se estableció en stateful-nat-64, el rango especificado por la destination-address-range o destination-prefix-list en la from instrucción debía estar dentro del rango especificado por la destination-prefix instrucción en la then instrucción. A partir de la versión 13.3R1 de Junos OS, se aplica esta restricción.

Configuración de tipos de traducción

Los detalles de implementación de las nueve opciones de la translation-type declaración son los siguientes:

  • basic-nat44: esta opción implementa la traducción estática de las direcciones IP de origen sin asignación de puertos. Debe configurar la from source-address instrucción en la condición de coincidencia de la regla. El tamaño del intervalo de direcciones especificado en la instrucción debe ser igual o menor que el conjunto de origen. Debe especificar un grupo de origen o un prefijo de destino. El grupo al que se hace referencia puede contener varias direcciones, pero no puede especificar puertos para la traducción.

    Nota:

    En un conjunto de servicios de interfaz, todos los paquetes destinados a la dirección de origen especificada en la condición de coincidencia se enrutan automáticamente a la PIC de servicios, incluso si no hay ningún conjunto de servicios asociado con la interfaz.
    Nota:

    Antes de Junos OS versión 11.4R3, solo podía usar un grupo TDR de origen en un único conjunto de servicios. A partir de la versión 11.4R3 de Junos OS y versiones posteriores, puede reutilizar un grupo TDR de origen en varios conjuntos de servicios.

  • basic-nat66: esta opción implementa la traducción estática de las direcciones IP de origen sin asignación de puertos en redes IPv6. La configuración es similar a la basic-nat44 implementación, pero con direcciones IPv6.

    Esta basic-nat66 opción no está disponible si usa MS-MPC o MS-MIC.

  • basic-nat-pt: esta opción implementa la traducción de las direcciones de los hosts IPv6, ya que originan sesiones en los hosts IPv4 de un dominio externo y viceversa. Esta opción siempre se implementa con DNS ALG. Debe definir los conjuntos de origen y destino de direcciones IPv4. Debe configurar una regla y definir dos términos. Configure las direcciones IPv6 en la from instrucción de ambas term instrucciones. En la then instrucción del primer término de la regla, haga referencia a los grupos de origen y destino y configure dns-alg-prefix. Configure el prefijo de origen en la then instrucción del segundo término dentro de la misma regla.

    Esta basic-nat-pt opción no está disponible si usa MS-MPC o MS-MIC.

  • deterministic-napt44: esta opción implementa la asignación basada en algoritmos de bloques de puertos de destino y dirección IP. Esto garantiza que una dirección IP y un puerto entrantes (de origen) siempre se asignen a la misma dirección IP y puerto de destino, lo que elimina la necesidad de registrar la traducción de direcciones. Cuando use deterministic-napt44, también debe usarlo deterministic-port-block-allocation en el nivel de [edit services nat pool poolname port] jerarquía.

    Esta deterministic-napt44 opción se admite en enrutadores serie MX con MS-DPC y en enrutadores serie M con PIC multiservicios MS-100, MS-400 y MS-500. La deterministic-napt44 opción si utiliza enrutadores de la serie MX con MS-MPC o MS-MIC solo se admite en Junos OS versión 14.2R7 y versiones posteriores 14.2 y en las versiones 15.1R3 y posteriores 15.1.

  • dnat-44: esta opción implementa la traducción estática de las direcciones IP de destino sin asignación de puertos. El tamaño del espacio de direcciones del grupo debe ser mayor o igual que el espacio de direcciones de destino. Debe especificar un nombre para la destination pool instrucción. El conjunto al que se hace referencia puede contener varias direcciones, rangos o prefijos, siempre y cuando el número de direcciones TDR del conjunto sea mayor que el número de direcciones de destino de la from instrucción. Debe incluir exactamente un destination-address valor en el nivel de [edit services nat rule rule-name term term-name from] jerarquía; si es un prefijo, el tamaño debe ser menor o igual que el tamaño del prefijo de agrupación. Las direcciones del grupo que no coincidan en el valor permanecen sin usar, ya que un grupo no se puede compartir entre varios términos o reglas.

  • dynamic-nat44: esta opción implementa la traducción dinámica de las direcciones IP de origen sin asignación de puertos. Debe especificar un source-poolnombre . El grupo al que se hace referencia debe incluir una address configuración (para la traducción solo de direcciones).

    La dynamic-nat44 opción de solo dirección admite la traducción de hasta 16.777.216 direcciones a un conjunto de tamaño más pequeño. Las solicitudes del rango de direcciones de origen se asignan a las direcciones del grupo hasta que se agota el grupo y se rechazan las solicitudes adicionales. Una dirección TDR asignada a un host se utiliza para todas las sesiones simultáneas desde ese host. La dirección se libera en el grupo solo después de que caduquen todas las sesiones de ese host. Esta característica permite que el enrutador comparta algunas direcciones IP públicas entre varios hosts privados. Dado que es posible que no todos los hosts privados creen sesiones simultáneamente, pueden compartir algunas direcciones IP públicas.

  • napt-44: esta opción implementa la traducción dinámica de las direcciones IP de origen con asignación de puertos. Debe especificar un nombre para la source-pool instrucción. El grupo al que se hace referencia debe incluir una port configuración. Si el puerto está configurado como automático o se especifica un rango de puertos, implica que se utiliza la traducción de puerto de dirección de red (NAPT).

  • napt-66: esta opción implementa la traducción dinámica de direcciones IP de origen con asignación de puertos para direcciones IPv6. La configuración es similar a la napt-44 implementación, pero con direcciones IPv6.

    Esta napt-66 opción no está disponible si usa MS-MPC o MS-MIC.

  • napt-pt: esta opción implementa la traducción dinámica de direcciones y puertos para la traducción de origen y estática de la dirección IP de destino. Debe especificar un nombre para la source-pool instrucción. El grupo al que se hace referencia debe incluir una configuración de puerto (para NAPT). Además, debe configurar dos reglas, una para el tráfico DNS y la otra para el resto del tráfico. La regla destinada al tráfico DNS debe estar habilitada para DNS ALG y la dns-alg-prefix instrucción debe estar configurada. Además, el prefijo configurado en la dns-alg-prefix instrucción se debe utilizar en la segunda regla para traducir las direcciones IPv6 de destino a direcciones IPv4.

    Esta napt-pt opción no está disponible si usa MS-MPC o MS-MIC.

  • stateful-nat464: esta opción implementa la traducción de direcciones del transatlántico del lado del proveedor (PLAT) 464XLAT para las direcciones IP de origen y la traducción de eliminación de prefijos IPv6 para las direcciones IPv4 de destino. Debe especificar las direcciones IPv4 utilizadas para la traducción en el nivel de jerarquía [edit services nat pool]. Se debe hacer referencia a este grupo en la regla que traduce las direcciones IPv6 a IPv4.

    La stateful-nat464 opción solo está disponible si utiliza MS-MPC o MS-MIC, y se admite a partir de la versión 17.1R1 de Junos OS.

  • stateful-nat64: esta opción implementa la traducción dinámica de direcciones y puertos para las direcciones IP de origen y la traducción de eliminación de prefijos para las direcciones IP de destino. Debe especificar las direcciones IPv4 utilizadas para la traducción en el [edit services nat pool] nivel jerárquico. Se debe hacer referencia a este grupo en la regla que traduce las direcciones IPv6 a IPv4.

  • twice-basic-nat-44: esta opción implementa la traducción de origen estático y destino estático para direcciones IPv4, combinando basic-nat44 así para direcciones de origen y dnat-44 destino.

    Esta twice-basic-nat-44 opción se admite en MS-DPC y en PIC multiservicios MS-100, MS-400 y MS-500. Esta twice-basic-nat-44 opción se admite en MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS.

  • twice-dynamic-nat-44: esta opción implementa la traducción dinámica de origen y estática de destino para direcciones IPv4, combinándola dynamic-nat44 para direcciones de origen y dnat-44 destino.

    Esta twice-dynamic-nat-44 opción se admite en MS-DPC y en PIC multiservicios MS-100, MS-400 y MS-500. Esta twice-dynamic-nat-44 opción se admite en MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS.

  • twice-napt-44: esta opción implementa la traducción estática de origen y destino para direcciones IPv4, combinándola napt-44 para direcciones de origen y dnat-44 destino.

    Esta twice-napt-44 opción se admite en MS-DPC y en PIC multiservicios MS-100, MS-400 y MS-500. Esta twice-napt-44 opción se admite en MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS.

Para obtener más información acerca de los métodos TDR, consulte RFC 2663, Terminología y consideraciones del traductor de direcciones de red IP (TDR).

Configuración de reglas TDR para el paso directo de IPsec para pares que no son de TDR-T

Antes de la versión 17.4R1 de Junos OS, la traducción de direcciones de red-recorrido (TDR-T) no es compatible con el conjunto de funciones IPsec de Junos VPN Site Secure en los enrutadores de la serie MX. A partir de Junos OS versión 14.2R7, 15.1R5, 16.1R2 y 17.1R1, puede pasar paquetes IKEv1 e IPsec a través de reglas NAPT-44 y NAT64 entre pares IPsec que no sean compatibles con TDR-T. Solo se admite el modo de túnel ESP. Esta característica solo se admite en MS-MPC y MS-MIC.

Para configurar reglas TDR para el paso directo de IPsec para NAPT-44 o NAT64:

  1. Configure una aplicación ALG de IKE. Consulte Configuración de las propiedades de la aplicación.

  2. Agregue la aplicación a un conjunto de aplicaciones. Consulte Configuración de conjuntos de aplicaciones.

  3. Configure un grupo de TDR. Consulte Configuración de conjuntos de direcciones y puertos para obtener información general sobre la traducción de direcciones de red.

  4. Configure la regla TDR:

    1. Configure una dirección de coincidencia para la regla. Consulte Configurar dirección de coincidencia para reglas TDR.

    2. Configure una de las condiciones coincidentes para que sea el conjunto de aplicaciones para el paso directo de IKE e IPsec que configuró en el paso 2.

    3. Configure otras condiciones de coincidencia. Consulte Configuración de condiciones de coincidencia en Reglas TDR.

    4. Configure el tipo de traducción como NAPT-44 o NAT64.

    5. Configure otras acciones de TDR. Consulte Configuración de acciones en Reglas TDR.

  5. Asigne la regla TDR a un conjunto de servicios.

Ver también

Protección de dispositivos CGN contra ataques de denegación de servicio (DOS)

Ahora puede elegir opciones de configuración que ayuden a prevenir o minimizar el efecto de los intentos de ataque de denegación de servicio (DOS).

Comportamiento de actualización de asignación

Antes de la implementación de las nuevas opciones para configurar el comportamiento de actualización de mapeo de TDR, descritas en este tema, una conversación se mantenía viva cuando los flujos de entrada o salida estaban activos. Este sigue siendo el comportamiento predeterminado. Ahora también puede especificar la actualización de la asignación solo para los flujos de entrada o solo para los flujos de salida. Para configurar el comportamiento de actualización de la asignación, incluya la mapping-refresh (inbound | outbound | inbound-outbound) instrucción en el nivel de [edit services nat rule rule-name term term-name then translated secure-nat-mapping] jerarquía.

Límite de flujo entrante EIF

Anteriormente. el número de conexiones entrantes en una asignación EIF estaba limitado solo por los flujos máximos permitidos en el sistema. Ahora puede configurar el número de flujos entrantes permitidos para un EIF. Para limitar el número de conexiones entrantes en una asignación EIF, incluya la eif-flow-limit number-of-flows instrucción en el nivel de [edit services nat rule rule-name term term-name then translated secure-nat-mapping] jerarquía.

Implementación de TDR carrier-grade: mejores prácticas

Los siguientes temas presentan las mejores prácticas para la implementación de TDR grado carrier:

Usar la asignación de direcciones round-rob cuando se usa la aplicación con MS-CPC

Práctica recomendada:

Si está utilizando un MS-CPC y configura el emparejamiento de agrupación de direcciones (APP) en una regla TDR, debe usar la asignación de direcciones de operación rotativa para el conjunto de TDR.

La función de aplicación asigna una dirección IP privada a la misma dirección IP pública en un grupo TDR para todas las sesiones de TDR para esa dirección IP privada.

La asignación de direcciones secuenciales para grupos TDR es la predeterminada en MS-CPC y asigna todos los puertos para una dirección IP pública antes de asignar la siguiente dirección IP. La asignación secuencial, junto con la aplicación, puede dar lugar a la asignación de varios hosts privados a la misma dirección IP pública, lo que resulta en un agotamiento rápido de puertos para una dirección IP pública, mientras que otros puertos aún están disponibles desde las direcciones IP restantes en el conjunto de TDR.

La asignación round-robin, por otro lado, asigna la siguiente dirección IP en el conjunto de TDR a la siguiente dirección IP privada que necesita traducción, lo que reduce la posibilidad de que se agoten todos los puertos de una dirección IP pública.

Para obtener más información acerca de la aplicación y la asignación de direcciones a operación rotativa, consulte Descripción general de Configuración de grupos de direcciones para la traducción de puertos de direcciones de red (NAPT).

Nota:

MS-MPC y MS-MIC solo utilizan la asignación round-robin.

En el ejemplo siguiente se muestra la asignación de direcciones a operación rotativa.

Utilice la función EIM solo cuando sea necesario

Práctica recomendada:

No utilice la asignación independiente del punto de conexión (EIM) en términos de reglas de TDR que incluyan ALG de Junos. EIM asigna la misma dirección y puerto TDR externo para una sesión específica desde un host privado, pero agrega una sobrecarga de procesamiento. EIM no proporciona ningún beneficio para ninguno de los ALG de Junos, que ya emplean la funcionalidad utilizada por EIM.
Práctica recomendada:

Active EIM para aplicaciones que reutilizan los puertos de origen y dependen de un dispositivo CGNAT para mantener la misma dirección y asignación de puertos para todo el tráfico enviado a distintos destinos. Por ejemplo, use EIM para aplicaciones de juegos de consola como Xbox y PS4 o aplicaciones que usan métodos de reparación de autodirección unilateral (UNSAF). Consulte (RFC 3424 de GTI-I, Consideraciones de IAB para la corrección unilateral de autodirecciones (UNSAF) a través de la traducción de direcciones de red).

Para obtener más información acerca de EIM, consulte Descripción general de Configuración de grupos de direcciones para la traducción de puertos de direcciones de red (NAPT).

En el siguiente ejemplo, se utiliza el ALG SIP de Junos en la regla TDR, por lo que no se utiliza EIM.

Defina la asignación de bloques de puertos tamaños de bloque en función del número esperado de sesiones de usuario

Práctica recomendada:

Para la asignación segura de bloques de puerto y la asignación de bloques de puerto determinista, defina un tamaño de bloque de asignación de bloques de puerto que sea de 2 a 4 veces mayor que el número promedio esperado de sesiones activas para un usuario. Por ejemplo, si se espera que el usuario tenga un promedio de aproximadamente 200 a 250 sesiones TDR activas, configurar el tamaño de bloque en 512 o 1024 proporciona una asignación liberal.
Práctica recomendada:

Si está implementando la asignación segura de bloques de puertos con la serie MX como dispositivo TDR y no está seguro de su perfil de usuario y perfil de tráfico del suscriptor, establezca el tamaño del bloque de puerto en 1024 si tiene suficientes direcciones IP TDR para manejar el número máximo estimado de suscriptores privados. La cantidad de direcciones IP TDR multiplicadas por 62 le da la cantidad de suscriptores privados que se pueden manejar con un tamaño de bloque de puerto de 1024 (hay 62 bloques por dirección IP). Luego, supervise de cerca el enrutador de la serie MX mediante el show services nat pool detail comando para determinar si es necesario cambiar el tamaño del bloque.
Práctica recomendada:

Tenga cuidado de no hacer que el tamaño de bloque sea demasiado grande si la cantidad de direcciones IP que puede asignar al grupo TDR es limitada. Hacer un tamaño de bloque de puerto que sea lo suficientemente grande como para asignar los bloques de manera eficiente a sus suscriptores puede causar que todos los bloques de puerto se vinculen.

La asignación segura de bloques de puertos asigna bloques de puertos a un usuario determinado para NAT44 o NAT64. La asignación segura de bloques de puerto limita la cantidad de mensajes syslog al generar solo un syslog por bloque de puertos.

Sin embargo, configurar el tamaño de bloque incorrectamente puede dar lugar a un uso ineficiente de los recursos de TDR o a problemas de rendimiento. Por ejemplo, cuando un usuario se conecta a un sitio web que requiere el establecimiento de un número significativo de sockets para una sola página HTML, se debe asignar un número correspondiente de puertos nuevos. El tamaño del bloque de puerto debe ser lo suficientemente grande como para evitar la asignación continua de nuevos bloques. Si el número de sesiones simultáneas para un suscriptor privado supera el número de puertos disponibles en el bloque de puerto activo, los otros bloques de puerto asignados al suscriptor se analizan en busca de puertos disponibles para usar o se asigna un nuevo bloque desde el grupo de bloques libres para el suscriptor. El análisis de los bloques de puertos asignados y la asignación de bloques adicionales pueden provocar retrasos en la configuración de nuevas sesiones y en la carga de páginas web.

Para obtener más información acerca de la asignación de bloques de puerto, consulte Configurar la asignación de bloques de puerto segura y Configurar NAPT determinista.

En el siguiente ejemplo, se establece el tamaño de bloque de puerto en 1024.

Consideraciones al cambiar la configuración de asignación de bloques de puerto en sistemas en ejecución

Práctica recomendada:

Antes de cambiar la asignación segura de bloques de puerto o la configuración de bloque de puerto determinista en un sistema en ejecución cuando se utiliza una MS-MPC o MS-MIC, planifique una interrupción rápida en las sesiones de TDR. El cambio en la configuración da como resultado la recreación de todas las sesiones TDR actuales.
Práctica recomendada:

Antes de cambiar la configuración de asignación de bloques de puerto en un sistema en ejecución cuando utilice un MS-CPC, planifique una interrupción de los servicios. Después de cambiar la configuración, debe reiniciar MS-CPC o, si esto no es posible, debe desactivar y reactivar el conjunto de servicios.

Los cambios en la configuración de asignación de bloques de puerto incluyen:

  • Cambiar cualquier configuración de PBA del grupo TDR.

  • Cambiar un grupo TDR de PBA a un grupo TDR que no sea de PBA.

  • Cambiar un grupo TDR que no es de PBA a un grupo TDR de PBA.

Para obtener más información acerca de cómo configurar la asignación de bloques de puerto, consulte Configurar la asignación de bloques de puerto segura y Configurar NAPT determinista.

No asigne grupos de TDR que sean más grandes de lo necesario

MS-MPC y MS-MIC

Práctica recomendada:

Cuando utilice NAPT44 como su tipo de traducción con MS-MIC o MS-MPC, no configure grupos de TDR que sean más grandes de lo necesario para la velocidad máxima de sesión, lo que inmovilizaría valiosos recursos de IPv4. Cada conversación, también conocida como sesión, incluye dos flujos: un flujo de entrada y un flujo de salida. Cada conversación requiere un puerto y cada dirección IP del grupo tiene un intervalo de puertos 1024-65535 (64K), por lo que no es necesario que el tamaño del conjunto de TDR sea mayor que:

Número máximo de conversaciones/64 K
Práctica recomendada:

Cuando utilice NAPT44 como su tipo de traducción con el MS-MIC, recomendamos un tamaño máximo del grupo TDR de 128 direcciones (una red /25).
Práctica recomendada:

Cuando utilice NAPT44 como su tipo de traducción con la MS-MPC, recomendamos un tamaño máximo del conjunto de TDR de 256 direcciones (una red /24).

El tamaño máximo recomendado del conjunto de TDR cuando se usa NAPT-44 para una MS-MIC es de 128 direcciones IP, ya que MS-MIC admite un máximo de 14 millones de flujos, o 7 millones de conversaciones, que requieren 7 millones de puertos. Hay un total de 7 millones de puertos disponibles con 128 direcciones IP, y cada dirección IP tiene un rango de puertos de 1024-65535.

El tamaño máximo recomendado de agrupación de TDR para cada ranura de una MS-MPC cuando se utiliza NAPT-44 es de 256 direcciones IP, ya que cada ranura admite un máximo de 30 millones de flujos, o 15 millones de conversaciones, que requieren 15 millones de puertos. Hay un total de 15 millones de puertos disponibles con 256 direcciones IP, y cada dirección IP tiene un rango de puertos de 1024-65535.

Puede usar agrupaciones más grandes que los valores recomendados y puede esperar que las configuraciones que usan la función de asignación de bloques de puerto (PBA) requieran agrupaciones más grandes. Esto se debe a que PBA asigna bloques de puertos a direcciones IP privadas, lo que cambia el modelo de eficiencia del grupo.

Para obtener más información acerca de cómo configurar grupos de TDR, consulte Configuración de conjuntos de direcciones y puertos para la descripción general de la traducción de direcciones de red.

MS-CPC

Práctica recomendada:

Cuando utilice NAPT44 como su tipo de traducción con el MS-CPC, no configure grupos TDR que sean más grandes de lo necesario para la velocidad de flujo máxima, lo que inmovilizaría valiosos recursos IPv4. Cada conversación incluye dos flujos (1 flujo inverso para cada flujo directo). Cada conversación requiere un puerto y cada dirección IP del grupo tiene un intervalo de puertos 1024-65535 (64K), por lo que no es necesario que el tamaño del conjunto de TDR sea mayor que:

Número máximo de conversaciones/64 K
Práctica recomendada:

Cuando utilice NAPT44 como su tipo de traducción con MS-CPC, no configure grupos TDR con más de 64 direcciones (una red /26).

El tamaño máximo del conjunto de TDR para un MS-CPC es de 64 direcciones IP, ya que MS-CPC admite un máximo de 8 millones de flujos, o 4 millones de conversaciones, lo que requiere un máximo de 4 millones de puertos. Hay un total de 4 millones de puertos disponibles con 64 direcciones IP, cada una de las cuales tiene un rango de puertos de 1024 a 65535. Si APP, EIM y EIF están habilitados, MS-CPC admite un máximo de 5,8 millones de flujos o 2,9 millones de conversaciones, por lo que el tamaño máximo del grupo de TDR sería menor.

Para obtener más información acerca de cómo configurar grupos de TDR, consulte Configuración de conjuntos de direcciones y puertos para la descripción general de la traducción de direcciones de red.

Configure el registro del sistema para TDR solo cuando sea necesario

Práctica recomendada:

No habilite el registro del sistema por sesión para configuraciones de asignación segura de bloques de puertos.
Práctica recomendada:

No habilite el registro del sistema para configuraciones TDR deterministas.
Práctica recomendada:

Habilite el registro del sistema en el nivel del conjunto de servicios en lugar de en el nivel de la interfaz de servicios cuando sea posible.
Práctica recomendada:

En redes de producción, envíe siempre los mensajes de registro a un servidor de registro del sistema externo. Esto evita agregar carga de CPU al motor de enrutamiento, lo que ocurre cuando los mensajes se registran localmente.
Práctica recomendada:

Especifique la clase de registro del sistema para restringir el registro a la clase de aplicaciones en la que está interesado.
Práctica recomendada:

Si configura el registro del sistema dentro de un término de regla TDR, use una regla de firewall con estado para restringir el tráfico que llega al término de regla TDR.

Los mensajes de registro del sistema pueden afectar negativamente al rendimiento de la tarjeta de servicios, dependiendo de la frecuencia con la que se crean y eliminan sesiones. Todos los mensajes de registro del sistema creados por la tarjeta de servicios requieren procesamiento de CPU en la tarjeta de servicios, y los mensajes de registro del sistema constituyen tráfico que se envía a través del enrutador de la serie MX y compite con el tráfico de usuario para llegar al servidor de registro externo.

La asignación segura de bloques de puertos elimina la necesidad de configurar registros por sesión, ya que conoce el bloque y el tamaño del bloque y puede derivar los puertos asignados a cada usuario.

El TDR determinista elimina la necesidad de iniciar sesión, ya que toda la información sobre la asignación de puertos se puede deducir matemáticamente.

En el ejemplo siguiente se restringe el registro a eventos TDR y se envían mensajes de registro al servidor de registro externo 203.0.113.4

Cuando configura el registro del sistema dentro de un término de regla TDR, todo el tráfico que entra en el término de regla TDR genera un registro, lo que puede causar un registro excesivo. Esto podría resultar en que se alcance el límite de velocidad de registro y perdería los registros que necesita.

Para obtener más información acerca de cómo configurar el registro del sistema para TDR, consulte Configurar registros de sesión de TDR.

Limite el impacto de la falta de fragmentos de IP

Práctica recomendada:

Para la interfaz de servicios configurada para TDR, limite el impacto de los fragmentos que faltan o se retrasan mediante la configuración de lo siguiente:

  • Número máximo de fragmentos para un paquete

  • Tiempo máximo de espera para un fragmento faltante

Los fragmentos IP recibidos por la tarjeta de servicios configurada para TDR se almacenan en búfer a medida que llegan. Esto permite una comprobación de la integridad del paquete completamente reensamblado antes de que el paquete sea procesado por TDR. Los fragmentos faltantes o retrasados pueden hacer que los fragmentos ya recibidos se retengan hasta que el búfer interno esté lleno y se eliminen, lo que da como resultado una sobrecarga de uso de la CPU y un reenvío de tráfico reducido.

Configurar la cantidad máxima de fragmentos que puede tener un paquete y limitar el tiempo de espera para un fragmento faltante reduce la posibilidad de que el búfer interno se llene.

En el ejemplo siguiente, se establece el número máximo de fragmentos en 10 y el tiempo de espera máximo en 3 segundos.

No utilice configuraciones propensas a bucles de enrutamiento de paquetes

Práctica recomendada:

Evite los bucles de enrutamiento de paquetes asegurándose de que solo el tráfico deseado pueda llegar a la tarjeta de servicios y ser procesado por la regla TDR de conjunto de servicios. Puede hacer esto de la siguiente manera:

  • Configurar un intervalo de direcciones de origen en la regla TDR cuando sea posible.

  • Configurar un filtro de firewall que acepte solo el tráfico destinado a ser atendido por la regla TDR en un conjunto de servicios de estilo de próximo salto.

El bucle de paquetes entre el motor de reenvío de paquetes y la tarjeta de servicios da como resultado un uso alto y persistente de CPU en la tarjeta de servicios. El bucle de paquetes puede deberse a que la tarjeta de servicios recibe tráfico de una red de origen privada inesperada. Cuando TDR procesa tráfico inesperado, se crea un orificio y, en el caso de EIF, se pueden crear muchos orificios de alfiler. Estos agujeros provocan bucles de enrutamiento si el tráfico de retorno se enruta de vuelta a través de la tarjeta de servicios.

En el siguiente ejemplo, se muestra un filtro de firewall que solo permite que el tráfico desde 198.51.100.0/24 llegue a la interfaz de servicios ms-1/0/0, que es la interfaz interna para un conjunto de servicios de salto siguiente.

Para obtener más información acerca de cómo configurar filtros de firewall, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y reguladores de tráfico.

En el siguiente ejemplo, se muestra una regla de TDR que solo procesa el tráfico de 198.51.100.0/24 (el resto del tráfico llega a la interfaz de servicios, pero no se procesa).

Para obtener más información acerca de cómo configurar reglas TDR, consulte Descripción general de reglas de traducción de direcciones de red.

Tiempos de espera de inactividad

Práctica recomendada:

Establezca el tiempo de espera de inactividad solo para las aplicaciones definidas por el usuario que podrían requerir que la asignación de sesión de TDR permanezca en la memoria durante más tiempo que el tiempo de espera de inactividad de TDR predeterminado de 30 segundos. Por ejemplo, una aplicación bancaria HTTP o HTTPS puede requerir más de 30 segundos de inactividad porque el usuario debe ingresar datos.
Práctica recomendada:

Antes de realizar cambios en los tiempos de espera de inactividad existentes, ejecute los siguientes comandos varias veces durante las horas pico. A continuación, ejecute los comandos después de realizar los cambios y compruebe que estos no privan al enrutador de la serie MX de recursos TDR ni a la tarjeta de servicios de memoria.

En el ejemplo siguiente se muestra el tiempo de espera de inactividad establecido en 1800 segundos para aplicaciones HTTPS y HTTP.

Para obtener más información acerca de cómo configurar aplicaciones definidas por el usuario, consulte Configurar propiedades de la aplicación.

Debe sopesar los riesgos de establecer tiempos de espera de inactividad altos para todo el tráfico. Aunque el tiempo de espera de inactividad de TDR predeterminado de 30 segundos puede ser demasiado bajo para algunas aplicaciones definidas por el usuario, establecer un valor de tiempo de espera demasiado alto puede inmovilizar recursos de TDR. Por ejemplo, establecer valores altos de tiempo de espera de inactividad puede bloquear cualquier sesión TCP que esté inactiva solo unos minutos después de su creación. Si la sesión TCP no es cerrada limpiamente por un FIN o RST por el cliente o servidor, la sesión permanecerá en la memoria y bloqueará los recursos TDR asignados a ella hasta que expire el valor de tiempo de espera.

Establecer tiempos de espera de inactividad más altos que afecten a todos los puertos UDP y TCP puede ser peligroso, especialmente con tráfico UDP como DNS. A diferencia de TCP, UDP no tiene otra forma de finalizar una sesión que no sea el tiempo de espera, por lo que todas las sesiones UDP permanecerían activas durante el valor completo del tiempo de espera de inactividad.

El siguiente ejemplo no es una configuración recomendada, ya que establece valores altos de tiempo de espera de inactividad para todo el tráfico TCP y UDP.

No tenemos valores de tiempo de espera de inactividad recomendados específicos. Los valores de tiempo de espera de inactividad adecuados dependen de varios factores, entre los que se incluyen:

  • Qué aplicaciones se utilizan en la red de un usuario final

    Por ejemplo, Apple ha declarado que se requiere un tiempo de espera de inactividad de 60 minutos para los siguientes servicios de Apple, que requieren una larga duración de la conexión:

    • Apple Push Services: puerto TCP entrante 5223

    • Exchange Active Sync: puerto TCP entrante 443

    • MobileMe: puertos TCP entrantes 5222 y 5223

  • Cómo se utiliza la solución TDR, por ejemplo, como dispositivo Gi TDR o como enrutador de borde empresarial

  • Qué tan grandes son sus grupos de TDR

  • Cuánto tráfico recibe cada tarjeta de servicios durante los picos de carga

  • Cuánta memoria tiene disponible

Habilitar volcado en control de flujo

Práctica recomendada:

Habilite la opción de volcado en control de flujo para cualquier tarjeta de servicios que procese tráfico TDR en una red de producción. Esta opción detecta cuando una tarjeta de servicios está bloqueada, escribe un volcado de memoria que Juniper Networks puede analizar para determinar por qué la tarjeta se bloqueó y recupera la tarjeta de servicios reiniciándola.

Para MS-MIC y MS-MPC, establezca la opción dump-on-flow-control en la interfaz pc-, la cual se utiliza para enviar tráfico de control desde el motor de enrutamiento a la tarjeta de servicios. En el siguiente ejemplo, se muestra la configuración si la interfaz de servicios es ms-2/1/0.

Para MS-CPC, establezca la opción de control de volcado en flujo en la interfaz sp-. En el siguiente ejemplo, se muestra la configuración si la interfaz de servicios es sp-2/1/0.

Ver también

Tabla de historial de cambios

La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.

Lanzamiento
Descripción
17.1R1
A partir de Junos OS versión 14.2R7, 15.1R5, 16.1R2 y 17.1R1, puede pasar paquetes IKEv1 e IPsec a través de reglas NAPT-44 y NAT64 entre pares IPsec que no sean compatibles con TDR-T.
16.1
A partir de Junos OS versión 16.1, se admite la limit-ports-per-address instrucción.
14.2
A partir de Junos OS versión 14.2, configure el grupo de TDR de la siguiente manera.