EN ESTA PÁGINA
Descripción general del direccionamiento de red de Junos Address Aware
Descripción general de la implementación de TDR de grado de operador de Junos OS
Comparación de funciones TDR carrier-grade para Junos Address Aware por tipo de tarjeta de interfaz
ALG disponibles para TDR con reconocimiento de direcciones de Junos OS
ALG disponibles de forma predeterminada para Junos OS Address Aware TDR en el enrutador ACX500
Descripción general de la traducción de direcciones de red
Descripción general del direccionamiento de red de Junos Address Aware
El direccionamiento de red de Junos Address Aware proporciona la funcionalidad de traducción de direcciones de red (TDR) para traducir direcciones IP. Esto es particularmente importante porque la Autoridad de números asignados de Internet (AANI) asignó el último gran bloque de direcciones IPv4 a principios de 2011.
En este tema, se incluyen las siguientes secciones:
- Beneficios de TDR
- Descripción general del concepto y las instalaciones de TDR
- IPv4 a IPv4 TDR básico
- NAPT determinista
- TDR de destino estático
- Dos veces TDR
- IPv6 TDR
- Soporte de puerta de enlace a nivel de aplicación (ALG)
- TDR-PT con DNS ALG
- TDR dinámico
- Estado NAT64
- 464XLAT
- Doble pila Lite
- Soporte de tarjeta de línea de direccionamiento de red Junos Address Aware
Beneficios de TDR
TDR admite una amplia gama de objetivos de redes, entre ellos:
-
Ocultar un conjunto de direcciones de host en una red privada detrás de un conjunto de direcciones públicas para proteger las direcciones de host de ataques directos en la red y evitar el agotamiento de las direcciones IPv4
-
Proporcionar las herramientas para la transición a IPv6 en función de los requisitos empresariales y para garantizar un crecimiento ininterrumpido de suscriptores y servicios
-
Proporcionar coexistencia IPv4–IPv6
Descripción general del concepto y las instalaciones de TDR
El direccionamiento de red de Junos Address Aware proporciona TDR de grado de operador (CGN) para redes IPv4 e IPv6, y facilita el tránsito de tráfico entre diferentes tipos de redes.
El direccionamiento de red de Junos Address Aware admite un conjunto diverso de opciones de traducción de TDR:
-
Traducción de origen estático: le permite ocultar una red privada. Cuenta con una asignación uno a uno entre la dirección original y la dirección traducida; La asignación se configura estáticamente. Para obtener más información, consulte TDR básica .
-
NAPT determinista: elimina la necesidad de registrar la traducción de direcciones al garantizar que la dirección IPv4 o IPv6 de origen original y el puerto siempre se asignen al mismo rango de puertos y direcciones IPv4 posteriores a la TDR.
-
Traducción de fuente dinámica: incluye dos opciones: traducción de fuente dinámica de solo dirección y traducción de puerto de dirección de red (NAPT):
-
Traducción de origen dinámica de solo dirección: mdash; Una dirección TDR se recoge dinámicamente de un grupo TDR de origen y la asignación de la dirección de origen original a la dirección traducida se mantiene siempre que haya al menos un flujo activo que utilice esta asignación. Para obtener más información, consulte TDR dinámica.
-
NAPT: se traducen tanto la dirección de origen original como el puerto de origen. La dirección y el puerto traducidos se recogen del grupo de TDR correspondiente. Para obtener más información, consulte NAPT .
-
-
Traducción de destino estático: le permite hacer que los servidores privados seleccionados sean accesibles. Cuenta con una asignación uno a uno entre la dirección traducida y la dirección de destino; La asignación se configura estáticamente. Para obtener más información, consulte TDR de destino estático.
-
Traducción de protocolos: permite asignar direcciones de un grupo de forma estática o dinámica a medida que se inician sesiones a través de los límites de IPv4 o IPv6. Para obtener más información, consulte Configurar TDR-PT, TDR-PT con DNS ALG y NAT64 con estado.
-
Encapsulación de paquetes IPv4 en paquetes IPv6 mediante cables de software: permite que los paquetes viajen a través de cables de software a un punto de conexión TDR de grado carrier donde se someten a un procesamiento de TDR de origen para ocultar la dirección de origen original. Para obtener más información, consulte Servicios de tunelización para Descripción general de la transición de IPv4 a IPv6.
El direccionamiento de red de Junos Address Aware admite la funcionalidad TDR descrita en los RFC y borradores de Internet de GTI-I, como se muestra en " Estándares TDR y SIP compatibles" en Referencia de estándares.
No todos los tipos de TDR son compatibles con todos los tipos de interfaz. Consulte Comparación de funciones TDR carrier-grade para Junos Address Aware por tipo de tarjeta de interfaz, en la cual se enumeran las funciones disponibles en las interfaces compatibles.
IPv4 a IPv4 TDR básico
La Traducción de direcciones de red básica o TDR básica es un método mediante el cual las direcciones IP se asignan de un grupo a otro, de manera transparente para los usuarios finales. La traducción de puertos de direcciones de red o NAPT es un método mediante el cual muchas direcciones de red y sus puertos TCP/UDP se traducen en una sola dirección de red y sus puertos TCP/UDP. Juntas, estas dos operaciones, conocidas como TDR tradicional, proporcionan un mecanismo para conectar un dominio con direcciones privadas a un dominio externo con direcciones registradas únicas globalmente.
El TDR tradicional, especificado en RFC 3022, Traductor de direcciones de red IP tradicional, es totalmente compatible con el direccionamiento de red de Junos Address Aware. Además, NAPT es compatible con direcciones de origen.
TDR básico
Con la TDR básica, se reserva un bloque de direcciones externas para traducir las direcciones de los hosts en un dominio privado a medida que originan sesiones al dominio externo. Para los paquetes que salen de la red privada, la TDR básica traduce las direcciones IP de origen y los campos relacionados, como las sumas de comprobación de encabezado IP, TCP, UDP e ICMP. En el caso de los paquetes entrantes, la TDR básica traduce la dirección IP de destino y las sumas de comprobación mencionadas anteriormente.
La horquilla es compatible con TDR básicos.
NAPT
Utilice NAPT para permitir que los componentes de la red privada compartan una única dirección externa. NAPT traduce el identificador de transporte (por ejemplo, número de puerto TCP, número de puerto UDP o ID de consulta ICMP) de la red privada en una única dirección externa. NAPT se puede combinar con Basic TDR para usar un conjunto de direcciones externas junto con la traducción de puertos.
Para los paquetes que salen de la red privada, NAPT traduce la dirección IP de origen, el identificador de transporte de origen (puerto TCP/UDP o ID de consulta ICMP) y los campos relacionados, como las sumas de comprobación de encabezado IP, TCP, UDP e ICMP. En el caso de los paquetes entrantes, NAPT traduce la dirección IP de destino, el identificador de transporte de destino y las sumas de comprobación del encabezado de transporte e IP.
En enrutadores de la serie MX con MS-MIC y MS-MPC, si configura una regla NAPT44 TDR y la dirección IP de origen de un paquete suplantado es igual al conjunto TDR y se produce un error en la condición de coincidencia de regla TDR, el paquete se mueve continuamente entre la PIC de servicios y el motor de reenvío de paquetes. Le recomendamos que borre manualmente la sesión y cree un filtro para bloquear la suplantación de IP del grupo TDR en tales condiciones.
La horquilla es compatible con NAPT.
NAPT determinista
Utilice NAPT44 determinista para garantizar que la dirección IPv4 y el puerto de origen original siempre se asignen a la misma dirección IPv4 posterior a la TDR y el mismo rango de puertos, y que la asignación inversa de una dirección IPv4 y un puerto externos traducidos dados siempre se asignen a la misma dirección IP interna. Esto elimina la necesidad de registrar la traducción de direcciones. A partir de la versión 17.4R1 de Junos OS, se admite NAPT64 determinista en MS-MPC y MS-MIC. El NAPT64 determinista garantiza que la dirección IPv6 y el puerto de origen original siempre se asignen a la misma dirección IPv4 posterior a la TDR y el mismo rango de puertos, y que la asignación inversa de una dirección IPv4 externa traducida determinada y un puerto siempre se asignen a la misma dirección IPv6 interna.
TDR de destino estático
Utilice TDR de destino estático para traducir la dirección de destino del tráfico externo a una dirección especificada en un grupo de destino. El grupo de destino contiene una dirección y ninguna configuración de puerto.
Para obtener más información acerca de la TDR de destino estático, consulte RFC 2663, Terminología y consideraciones del traductor de direcciones de red IP (TDR).
Dos veces TDR
En Twice TDR, tanto la dirección de origen como la de destino están sujetas a traducción a medida que los paquetes atraviesan el enrutador TDR. La información de origen a traducir puede ser solo dirección o dirección y puerto. Por ejemplo, usaría Twice TDR cuando esté conectando dos redes en las que todas o algunas direcciones de una red se superponen con direcciones de otra red (ya sea que la red sea privada o pública). En la TDR tradicional, solo se traduce una de las direcciones.
Para configurar Twice TDR, debe especificar una dirección de destino y una dirección de origen para la dirección de coincidencia, el conjunto o el prefijo y el tipo de traducción.
Puede configurar puertas de enlace a nivel de aplicación (ALG) para ICMP y traceroute con reglas de firewall con estado, TDR o de clase de servicio (CoS) cuando Twice TDR está configurado en el mismo conjunto de servicios. Estos ALG no se pueden aplicar a flujos creados por el Protocolo de control de puerta de enlace de paquetes (PGCP). Twice TDR no admite otros ALG. De forma predeterminada, la función Twice TDR puede afectar a los encabezados IP, TCP y UDP incrustados en la carga útil de los mensajes de error ICMP.
Twice TDR, especificado en RFC 2663, Terminología y consideraciones del traductor de direcciones de red IP (TDR), es totalmente compatible con el direccionamiento de red de Junos Address Aware.
IPv6 TDR
La TDR IPv6 a IPv6 (NAT66), definida en el borrador de Internet draft-mrw-behave-nat66-01, Traducción de direcciones de red IPv6 a IPv6 (NAT66), es totalmente compatible con el direccionamiento de red de Junos Address Aware.
Soporte de puerta de enlace a nivel de aplicación (ALG)
El direccionamiento de red de Junos Address Aware admite varios ALG. Puede utilizar reglas de TDR para filtrar el tráfico entrante basado en ALGS. Para obtener más información, consulte Descripción general de reglas de traducción de direcciones de red.
TDR-PT con DNS ALG
TDR-PT y el ALG del sistema de nombres de dominio (DNS) se utilizan para facilitar la comunicación entre hosts IPv6 y hosts IPv4. Mediante el uso de un conjunto de direcciones IPv4, el TDR-PT asigna direcciones de ese conjunto a nodos IPv6 de forma dinámica a medida que se inician sesiones a través de los límites de IPv4 o IPv6. Las sesiones entrantes y salientes deben atravesar el mismo enrutador TDR-PT para que pueda rastrear esas sesiones. RFC 2766, Traducción de direcciones de red: traducción de protocolos (TDR-PT), recomienda el uso de TDR-PT para la traducción entre nodos solo IPv6 y nodos solo IPv4, y no para la traducción de IPv6 a IPv6 entre nodos IPv6 o la traducción de IPv4 a IPv4 entre nodos IPv4.
DNS es un sistema de nomenclatura jerárquico distribuido para computadoras, servicios o cualquier recurso conectado a Internet o una red privada. El ALG de DNS es un agente específico de la aplicación que permite que un nodo IPv6 se comunique con un nodo IPv4 y viceversa.
Cuando se emplea DNS ALG con TDR-PT, el DNS ALG traduce las direcciones IPv6 en consultas y respuestas DNS a las direcciones IPv4 correspondientes y viceversa. Las asignaciones de nombre a dirección IPv4 se mantienen en el DNS con consultas "A". Las asignaciones de nombre a dirección IPv6 se mantienen en el DNS con consultas "AAAA".
Para consultas DNS IPv6, utilice la do-not-translate-AAAA-query-to-A-query instrucción en el nivel de [edit applications application application-name] jerarquía.
TDR dinámico
El flujo dinámico de TDR se muestra en la Figura 1.
dinámico de TDR
Con la TDR dinámica, puede asignar una dirección IP privada (origen) a una dirección IP pública extraída de un conjunto de direcciones IP registradas (públicas). Las direcciones TDR del grupo se asignan dinámicamente. La asignación dinámica de direcciones también permite que varios hosts privados usen algunas direcciones IP públicas, en contraste con un conjunto de igual tamaño requerido por la TDR estática de origen.
Para obtener más información acerca de la traducción dinámica de direcciones, consulte RFC 2663, Terminología y consideraciones del traductor de direcciones de red IP (TDR).
Estado NAT64
El flujo de NAT64 con estado se muestra en la Figura 2.
de NAT64 con estado
El estado NAT64 es un mecanismo para pasar a una red IPv6 y al mismo tiempo lidiar con el agotamiento de direcciones IPv4. Al permitir que los clientes solo IPv6 contacten con servidores IPv4 mediante UDP de unidifusión, TCP o ICMP, varios clientes solo IPv6 pueden compartir la misma dirección de servidor IPv4 pública. Para permitir el uso compartido de la dirección del servidor IPv4, NAT64 traduce los paquetes IPv6 entrantes a IPv4 (y viceversa).
Cuando se utiliza NAT64 con estado junto con DNS64, normalmente no se requieren cambios en el cliente IPv6 ni en el servidor IPv4. DNS64 está fuera del alcance de este documento porque normalmente se implementa como una mejora para los servidores DNS implementados actualmente.
NAT64 con estado, especificado en RFC 6146, NAT64 con estado: Traducción de direcciones de red y protocolos de clientes IPv6 a servidores IPv4 es totalmente compatible con el direccionamiento de red de Junos Address Aware.
464XLAT
A partir de la versión 17.1R1 de Junos OS, puede configurar un traductor del lado del proveedor (PLAT) 464XLAT. Esto solo se admite en MS-MIC y MS-MPC. 464XLAT proporciona una técnica sencilla y escalable para que un cliente IPv4 con una dirección privada se conecte a un host IPv4 a través de una red IPv6. 464XLAT solo admite IPv4 en el modelo cliente-servidor, por lo que no admite la comunicación IPv4 punto a punto ni las conexiones IPv4 entrantes.
Un traductor del lado del cliente (CLAT), que no es un producto de Juniper Networks, traduce el paquete IPv4 a IPv6 incrustando las direcciones de origen y destino IPv4 en prefijos IPv6 /96, y envía el paquete a través de una red IPv6 al PLAT. El PLAT traduce el paquete a IPv4 y lo envía al host IPv4 a través de una red IPv4 (consulte la Figura 3).
de cableado 464XLAT
XLAT464 ofrece las ventajas de no tener que mantener una red IPv4 y no tener que asignar direcciones IPv4 públicas adicionales.
El CLAT puede residir en el dispositivo móvil del usuario final en una red móvil solo IPv6, lo que permite a los proveedores de red móvil implementar IPv6 para que sus usuarios and admitan aplicaciones solo IPv4 en dispositivos móviles (vea la Figura 4).
inalámbrico 464XLAT
Doble pila Lite
El flujo de doble pila lite (DS-Lite) se muestra en la Figura 5.
DS-Lite emplea túneles IPv4 sobre IPv6 para cruzar una red de acceso IPv6 y llegar a un TDR IPv4-IPv4 de grado carrier. Esto facilita la introducción gradual de IPv6 en Internet al proporcionar compatibilidad con versiones anteriores con IPv4.
DS-Lite se admite en enrutadores serie MX con MS-DPC y en enrutadores serie M con PIC multiservicios MS-100, MS-400 y MS-500. A partir de la versión 17.4R1 de Junos OS, DS-Lite es compatible con enrutadores de la serie MX con MS-MPC y MS-MIC. A partir de la versión 19.2R1 de Junos OS, DS-Lite es compatible con el chasis virtual MX y los enrutadores de puerta de enlace de red de banda ancha (BNG) MX.
Soporte de tarjeta de línea de direccionamiento de red Junos Address Aware
Las tecnologías de direccionamiento de red Junos Address Aware están disponibles en las siguientes tarjetas de línea:
-
MultiServices Concentrador de puerto denso (MS-CPC)
-
PIC de multiservicios MS-100, MS-400 y MS-500
-
Concentrador de puerto modular multiservicios (MS-MPC) y tarjeta de interfaz modular multiservicios (MS-MIC)
-
Concentradores de puertos modulares (TDR) en línea.
Para obtener una lista de los tipos de TDR específicos admitidos en cada tipo de tarjeta, consulte Comparación de funciones TDR carrier-grade para Junos Address Aware por tipo de tarjeta de interfaz.
Ver también
Ejemplos de escenarios de transición a IPv6
Junos OS admite muchos escenarios de transición IPv6 requeridos por los clientes de Junos OS. A continuación, se muestran algunos ejemplos:
- Ejemplo 1: Agotamiento de IPv4 con una red de acceso no IPv6
- Ejemplo 2: Agotamiento de IPv4 con una red de acceso IPv6
- Ejemplo 3: Agotamiento de IPv4 para redes móviles
Ejemplo 1: Agotamiento de IPv4 con una red de acceso no IPv6
La Figura 6 muestra un escenario en el que el proveedor de servicios de Internet (ISP) no ha cambiado significativamente su red IPv4. Este enfoque permite que los hosts IPv4 accedan a Internet IPv4 y que los hosts IPv6 accedan a Internet IPv6. Un host de doble pila puede tratarse como un host IPv4 cuando utiliza el servicio de acceso IPv4 y como un host IPv6 cuando utiliza el servicio de acceso IPv6.
de acceso IPv4
En este enfoque, se deben implementar dos nuevos tipos de dispositivos: una puerta de enlace doméstica de doble pila y una traducción de direcciones de red carrier-grade (TDR) de doble pila. La puerta de enlace doméstica de doble pila integra funciones de reenvío IPv4 y tunelización de v6 sobre v4. También puede integrar una función TDR v4-v4. El TDR carrier-grade (CGN) de doble pila integra la tunelización v6-over-v4 y las funciones TDR carrier-grade v4-v4.
Ejemplo 2: Agotamiento de IPv4 con una red de acceso IPv6
En el escenario que se muestra en la Figura 7, la red del ISP es solo IPv6.
de acceso IPv6
La solución de doble pila lite (DS-Lite) es compatible con ISP solo IPv6. El mejor modelo de negocio para este enfoque es que el equipo local del cliente (CPE) haya integrado las funciones para tunelizar IPv6 a una red troncal IPv4, tunelizar IPv4 a una red troncal IPv6, y pueda detectar automáticamente qué solución se necesita.
No todos los clientes de un ISP determinado deben cambiar del acceso IPv4 al acceso IPv6 simultáneamente; De hecho, la transición se puede gestionar mejor cambiando de grupo de clientes (por ejemplo, todos los que están conectados a un único punto de presencia) de forma incremental. Este enfoque incremental debería resultar más fácil de planificar, programar y ejecutar que una conversión general.
Ejemplo 3: Agotamiento de IPv4 para redes móviles
La complejidad de las redes móviles requiere un enfoque de migración flexible para garantizar una interrupción mínima y la máxima compatibilidad con versiones anteriores durante la transición. NAT64 se puede usar para permitir que los dispositivos IPv6 se comuniquen con hosts IPv4 sin modificar los clientes.
Descripción general de la implementación de TDR de grado de operador de Junos OS
Junos OS le permite implementar y escalar una solución de traducción de direcciones de red de nivel de operador (CGNAT) según el tipo de interfaces de servicios utilizadas para su implementación:
Concentrador de puerto más denso de multiservicios (MS-CPC): el paquete de servicios de capa 3 se utiliza para configurar TDR para PIC de servicios adaptables MS-CPC. Esta solución proporciona la funcionalidad TDR descrita en Descripción general del direccionamiento de red de Junos Address Aware.
PIC multiservicios MS-100, MS-400 y MS-500: el paquete de servicios de capa 3 se utiliza para configurar TDR para PIC multiservicios. Esta solución proporciona la funcionalidad TDR descrita en Descripción general del direccionamiento de red de Junos Address Aware.
Concentrador de puerto modular multiservicios (MS-MPC) y tarjeta de interfaz modular multiservicios (MS-MIC): MS-MPC y MS-MIC están preconfiguradas para permitir la configuración de TDR carrier-grade. Esta solución proporciona la funcionalidad TDR descrita en Descripción general del direccionamiento de red de Junos Address Aware.
TDR en línea para tarjetas de línea de concentrador de puerto modular (MPC)): la TDR en línea aprovecha las capacidades de servicios de las tarjetas de línea MPC, lo que permite una implementación rentable de la funcionalidad de TDR en el plano de datos, como se describe en Descripción general de la traducción de direcciones de red en línea.
Ver también
Comparación de funciones TDR carrier-grade para Junos Address Aware por tipo de tarjeta de interfaz
En la Tabla 1 se resumen las diferencias de características entre las implementaciones de TDR carrier-grade de Junos OS.
A partir de la versión 17.2R1 de Junos OS, se admite el TDR en línea en MPC5E y MPC6E.
A partir de la versión 17.4R1 de Junos OS, se admite TDR en línea en MPC7E, MPC8E y MPC9E.
Reportaje |
MS-CPC MS-100 MS-400 MS-500 |
MS-MPC MS-MIC |
MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E y MPC9E TDR en línea |
|---|---|---|---|
TDR de fuente estática |
Sí |
Sí |
Sí |
TDR de fuente dinámica: solo dirección |
Sí |
Sí |
No |
TDR de origen dinámico: traducción de puertos NAPT con asignación de bloques de puerto segura |
Sí |
Sí (TDR de origen dinámico: traducción de puerto NAPT con asignación de bloque de puerto segura compatible con MS-MPC y MS-MIC a partir de la versión 14.2R2 de Junos OS) |
No |
TDR de fuente dinámica: traducción de puertos NAPT44 con asignación de bloques de puerto determinista |
Sí |
sí (TDR de origen dinámico: traducción de puertos NAPT44 con asignación de bloque de puerto determinista compatible con MS-MPC y MS-MIC a partir de la versión 17.3R1 de Junos OS, en la versión 14.2R7 de Junos OS y versiones posteriores 14.2, en las versiones 15.1R3 y posteriores 15.1, y en las versiones 16.1R5 y posteriores 16.1) |
No |
TDR de origen dinámico: traducción de puertos NAPT64 con asignación de bloques de puerto determinista |
No |
Sí (TDR de origen dinámico: traducción de puertos NAPT64 con asignación de bloques de puerto determinista compatible con MS-MPC y MS-MIC a partir de la versión 17.4R1 de Junos OS) |
No |
TDR de destino estático |
Sí |
Sí |
Sí
Nota:
El TDR de destino se puede implementar indirectamente. Consulte Descripción general de la traducción de direcciones de red en línea |
Dos veces TDR |
Sí |
Sí (dos veces compatible con TDR para MS-MPC y MS-MIC a partir de Junos OS versión 15.1R1) |
Sí
Nota:
Twice TDR se puede implementar indirectamente. Consulte Descripción general de la traducción de direcciones de red en línea |
NAPT - Preservar la paridad y el rango |
Sí |
sí (NAPT: conservar la paridad y el rango compatibles con MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS) |
No |
NAPT - APP/EIF/EIM |
Sí |
Sí |
No |
IKE ALG |
No |
Sí (a partir de Junos OS versión 14.2R7, 15.1R5, 16.1R2 y 17.1R1) |
No |
Estado NAT64 |
Sí |
Sí |
No |
Estado NAT64 con APP/EIM/EIF |
No |
Sí |
No |
Estado NAT64 con ALG
|
No |
Sí |
No |
DS-Lite |
Sí |
Sí (DS-Lite compatible con MS-MPC y MS-MIC a partir de la versión 17.4R1 de Junos OS) |
No |
6º |
Sí |
No |
No |
6 a 4 |
Sí |
No |
No |
464XLAT |
No |
Sí (a partir de Junos OS versión 17.1R1) |
No |
Superposición de direcciones en el conjunto de TDR |
Sí |
Sí |
No |
| Conjunto de sobrecarga |
Sí |
No |
No |
Protocolo de control de puertos |
Sí |
Sí (El protocolo de control de puertos con NAPT44 es compatible con MS-MPC y MS-MIC a partir de Junos OS versión 17.4R1. A partir de la versión 18.2R1 de Junos OS, el protocolo de control de puertos en MS-MPC y MS-MIC admite DS-Lite. El PCP proporciona un mecanismo para controlar el reenvío de paquetes entrantes por parte de dispositivos ascendentes, como NAT44 y dispositivos de firewall, y un mecanismo para reducir el tráfico de keepalive de aplicaciones). |
No |
CGN-PIC |
Sí |
No |
No |
Soporte de AMS |
No |
Sí |
No |
Reenvío de puertos |
Sí |
Sí (el reenvío de puertos se admite para MS-MPC y MS-MIC a partir de Junos OS versión 17.4R1). |
No |
Sin traducción |
Sí |
sí (no se admite traducción para MS-MPC y MS-MIC a partir de Junos OS versión 15.1R1) |
Sí |
En el cuadro 2 se resume la disponibilidad de tipos de traducción por tipo de tarjeta de línea.
Tipo de traducción |
MS-CPC MS-100 MS-400 MS-500 |
MS-MPC MS-MIC |
MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E y MPC9E TDR en línea |
|---|---|---|---|
|
Sí |
Sí |
Sí |
|
Sí |
No |
No |
|
Sí |
No |
No |
|
Sí |
sí ( |
No |
|
No |
sí ( |
No |
|
Sí |
Sí |
No |
|
Sí |
Sí |
No |
|
Sí |
Sí |
No |
|
Sí |
No |
No |
|
Sí |
No |
No |
|
No |
Sí (a partir de Junos OS versión 17.1R1) |
No |
|
Sí |
Sí |
No |
|
Sí |
sí ( |
Sí ( |
|
Sí |
sí ( |
No |
|
Sí |
sí ( |
No |
ALG disponibles para TDR con reconocimiento de direcciones de Junos OS
Las siguientes puertas de enlace de nivel de aplicación (ALG) enumeradas en la tabla 3 son compatibles con el procesamiento de TDR en las plataformas enumeradas.
Para ver los detalles de implementación (puerto, protocolo, etc.) de estas aplicaciones predeterminadas de Junos OS, busque el nombre de ALG predeterminado de Junos OS en la tabla y, a continuación, busque el nombre de la lista en el groupsarchivo . Por ejemplo, para obtener más información sobre TFTP, busque como junos-tftp se muestra.
Junos OS proporciona el , que permite que otros ALG funcionen mediante el junos-algmanejo de registros ALG, lo que hace que los paquetes de ruta lentos fluyan a través de ALG registrados y la transferencia de eventos de ALG a los complementos de ALG. El junos-alg ALG está disponible automáticamente en las plataformas MS-MPC y MS-MIC y no requiere configuración adicional.
Las puertas de enlace de capa de aplicación (ALG) de shell remoto (RSH) e inicio de sesión remoto (rlogin) no son compatibles con la traducción de puerto de dirección de red (NAPT) en enrutadores de la serie MX con MS-MIC y MS-MPC.
user@host# show groups junos-defaults applications application junos-tftp application-protocol tftp; protocol udp; destination-port 69;
En la Tabla 3 se resumen los ALG disponibles para la tarjeta TDR con reconocimiento de direcciones de Junos OS para interfaces de servicios.
ALG |
MS-CPC |
MS-MPC, MS-MIC |
Nombre ALG predeterminado de Junos OS |
|---|---|---|---|
TCP ALG básico |
Sí |
Sí |
Nota:
No se admiten ALG específicos de Junos OS. Sin embargo, una función llamada rastreador TCP, disponible de forma predeterminada, realiza el orden de los segmentos y la retransmisión y el seguimiento de la conexión, validaciones para las conexiones TCP. |
UDP ALG básico |
Sí |
Sí |
Nota:
El rastreador TCP realiza comprobaciones limitadas de integridad y validación para UDP. |
ARRANQUE |
Sí |
No |
|
Servicios RPC de DCE |
Sí |
Sí |
|
DNS |
Sí |
Sí |
|
DNS |
No |
No |
|
FTP |
Sí |
Sí |
|
RAS de gatekeeper (a partir de la versión 17.1R1 de Junos OS) |
No |
Sí |
|
H323 |
No |
Sí |
|
ICMP |
Sí |
Sí
Nota:
En Junos OS versión 14.1 y anteriores, los mensajes ICMP se manejan de forma predeterminada, pero no se proporciona compatibilidad con PING ALG. A partir de Junos OS 14.2, los mensajes ICMP se gestionan de forma predeterminada y se proporciona compatibilidad con PING ALG. |
|
IIOP |
Sí |
No |
|
IKE ALG |
No |
Sí
Nota:
A partir de Junos OS versión 14.2R7, 15.1R5, 16.1R2 y 17.1R1, el ALG de IKE es compatible con MS-MPC y MS-MIC. |
|
IP |
Sí |
El rastreador TCP, disponible de forma predeterminada en estas plataformas, realiza comprobaciones limitadas de integridad y validación. |
|
NETBIOS |
Sí |
No |
|
NETSHOW |
Sí |
No |
|
PPTP |
Sí |
Sí |
|
REALAUDIO |
Sí |
No |
|
Sun RPC y RPC Servicios de mapas de puertos |
Sí |
Sí |
|
RTSP |
Sí |
Sí |
|
SIP |
Sí |
Sí |
El SIP
Nota:
Las sesiones SIP están limitadas a 12 horas (720 minutos) para el procesamiento de TDR en las tarjetas de interfaz MS-MIC y MS-MPC. Las sesiones SIP en el MS-CPC no tienen límites de tiempo. |
SNMP |
Sí |
No |
|
SQLNET |
Sí |
Sí |
|
TFTP |
Sí |
Sí |
|
Traceroute |
Sí |
Sí |
|
Servicio de shell remoto de Unix |
Sí |
Sí
Nota:
El ALG de shell remoto (RSH) no es compatible con la traducción de puertos de dirección de red (NAPT). |
|
WINFrame |
Sí |
No |
|
DISCUSIÓN-UDP |
No |
Sí |
|
MS RPC |
No |
Sí |
|
Ver también
ALG disponibles de forma predeterminada para Junos OS Address Aware TDR en el enrutador ACX500
Las siguientes puertas de enlace de nivel de aplicación (ALG) enumeradas en la tabla 4 son compatibles con el procesamiento de TDR en enrutadores ACX500.
Para ver los detalles de implementación (puerto, protocolo, etc.) de estas aplicaciones predeterminadas de Junos OS, busque el nombre de ALG predeterminado de Junos OS en la tabla y, a continuación, busque el nombre de la lista en el groupsarchivo . Por ejemplo, para obtener más información sobre TFTP, busque como junos-tftp se muestra.
El ALG para TDR solo se admite en los enrutadores interiores ACX500.
Junos OS proporciona el , que permite que otros ALG funcionen mediante el junos-algmanejo de registros ALG, lo que hace que los paquetes de ruta lentos fluyan a través de ALG registrados y la transferencia de eventos de ALG a los complementos de ALG. El junos-alg ALG está disponible automáticamente en el enrutador ACX500 y no requiere configuración adicional.
Las puertas de enlace de capa de aplicación (ALG) de inicio de sesión remoto (rlogin) no son compatibles con la traducción de puerto de dirección de red (NAPT) en el enrutador ACX500.
| ALG |
Enrutador ACX500 |
Nombre ALG predeterminado de Junos OS |
|---|---|---|
| TCP ALG básico |
Sí |
Nota:
No se admiten ALG específicos de Junos OS. Sin embargo, una función llamada rastreador TCP, disponible de forma predeterminada, realiza el orden de los segmentos y la retransmisión y el seguimiento de la conexión, validaciones para las conexiones TCP. |
| UDP ALG básico |
Sí |
Nota:
El rastreador TCP realiza comprobaciones limitadas de integridad y validación para UDP. |
| DNS |
Sí |
|
| FTP |
Sí |
|
| ICMP |
Sí
Nota:
Los mensajes ICMP se manejan de forma predeterminada, pero no se proporciona soporte PING ALG. |
|
| TFTP |
Sí |
|
| Servicio de shell remoto de Unix |
Sí
Nota:
El ALG de shell remoto (RSH) no es compatible con la traducción de puertos de dirección de red (NAPT). |
|
Detalles de soporte de ALG
Esta sección incluye detalles sobre los ALG. Incluye lo siguiente:
TCP básico
Este ALG realiza una comprobación básica de la cordura en los paquetes TCP. Si encuentra errores, genera los siguientes eventos de anomalía y mensajes de registro del sistema:
-
Puerto de origen o destino TCP cero
-
Error en la comprobación de la longitud del encabezado TCP
-
Número de secuencia TCP cero y no se han establecido indicadores
-
Se establecen el número de secuencia TCP cero y los indicadores FIN/PSH/RST
-
TCP FIN/RST o SYN(URG|FIN|RST)
TCP ALG realiza los pasos siguientes:
-
Cuando el enrutador recibe un paquete SYN, el ALG crea flujos TCP hacia adelante e inverso y los agrupa en una conversación. Realiza un seguimiento del apretón de manos de tres vías TCP.
-
El mecanismo de defensa SYN rastrea el estado de establecimiento de la conexión TCP. Espera que la sesión TCP se establezca en un intervalo de tiempo pequeño (actualmente 4 segundos). Si el apretón de manos de tres vías TCP no se establece en ese período, la sesión finaliza.
-
Un mecanismo de keepalive detecta sesiones TCP con puntos de conexión que no responden.
-
Los errores de ICMP solo se permiten cuando un flujo coincide con la información del selector especificada en los datos del ICMP.
UDP básico
Este ALG realiza una comprobación básica de la cordura en los encabezados UDP. Si encuentra errores, genera los siguientes eventos de anomalía y mensajes de registro del sistema:
-
Puerto de origen o destino UDP 0
-
Error en la comprobación de la longitud del encabezado UDP
El ALG UDP realiza los pasos siguientes:
-
Cuando recibe el primer paquete, el ALG crea flujos bidireccionales para aceptar el tráfico de la sesión UDP directa e inversa.
-
Si la sesión está inactiva durante más tiempo que el máximo permitido (el valor predeterminado es de 30 segundos), se eliminarán los flujos.
-
Los errores de ICMP solo se permiten cuando un flujo coincide con la información del selector especificada en los datos del ICMP.
DNS
El ALG del sistema de nombres de dominio (DNS) maneja datos asociados con la localización y traducción de nombres de dominio en direcciones IP. El ALG normalmente se ejecuta en el puerto 53. El ALG monitorea los paquetes de consulta y respuesta de DNS y solo admite tráfico UDP. El ALG no admite traducciones de carga útil. El ALG DNS cierra la sesión solo cuando se recibe una respuesta o se alcanza un tiempo de espera de inactividad.
A continuación, se muestra un ejemplo para configurar DNS ALG:
-
Crear interfaz TDR.
[edit] services { service-set set-dns { nat-rules nat-dns; interface-service { service-interface ms-0/2/0; } } -
Configuración del conjunto TDR.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definición de reglas de TDR para DNS ALG.
[edit] services { nat { rule nat-dns { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-dns-udp;; } then { translated { source-pool p-napt; translation-type { basic-nat44; } } } } } } -
Conjuntos de servicio de enlace a la interfaz.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-dns; } output { service-set set-dns; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
FTP
FTP es el protocolo de transferencia de archivos especificado en RFC 959. Además de la conexión de control principal, también se realizan conexiones de datos para cualquier transferencia de datos entre el cliente y el servidor; y el host, el puerto y la dirección se negocian a través del canal de control.
Para FTP en modo no pasivo, el servicio de firewall con estado de Junos OS analiza los datos de la aplicación de cliente a servidor para el comando PORT, el cual proporciona la dirección IP y el número de puerto al que se conecta el servidor. Para FTP en modo pasivo, el servicio de firewall con estado de Junos OS analiza los datos de la aplicación de cliente a servidor para el comando PASV y, luego, analiza las respuestas de servidor a cliente en busca de la respuesta 227, que contiene la dirección IP y el número de puerto a los que se conecta el cliente.
Hay una complicación adicional: FTP representa estas direcciones y números de puerto en ASCII. Como resultado, cuando se reescriben direcciones y puertos, el número de secuencia TCP puede cambiar y, a partir de entonces, el servicio TDR debe mantener esta diferencia en los números SEQ y ACK mediante la realización de la secuencia TDR en todos los paquetes posteriores.
La compatibilidad con firewalls con estado y servicios TDR requiere que configure FTP ALG en el puerto TCP 21 para habilitar el protocolo de control FTP. El ALG realiza las siguientes tareas:
-
Asigna automáticamente puertos de datos y permisos de firewall para una conexión de datos dinámica
-
Crea flujos para la conexión de datos negociada dinámicamente
-
Supervisa la conexión de control en modo activo y pasivo
-
Reescribe los paquetes de control con la dirección TDR adecuada y la información del puerto
En el ACX500, para que el FTP pasivo funcione correctamente sin la puerta de enlace de capa de aplicación (ALG) FTP habilitada (si no especifica la application junos-ftp instrucción en el [edit services nat rule rule-name term term-name from] nivel jerárquico), debe habilitar la funcionalidad de emparejamiento de agrupación de direcciones (APP) habilitada (si incluye la address-pooling instrucción en el nivel jerárquico [edit services nat rule rule-name term term-name then translated] ). Esta configuración hace que las sesiones FTP de datos y de control reciban la misma dirección TDR.
A continuación se muestra un ejemplo para configurar FTP ALG:
-
Crear interfaz TDR.
[edit] services { service-set set-ftp { nat-rules nat-ftp; interface-service { service-interface ms-0/2/0; } } -
Configuración del conjunto TDR.
[edit] services { nat { pool p-napt { address 10.30.30.0/24; port { range low 9000 high 9010; } } } -
Definición de reglas TDR para FTP ALG.
[edit] services { nat { rule nat-ftp { match-direction input; term term1 { from { source-address { 10.10.10.0/24; } applications junos-ftp; } then { translated { source-pool p-napt; translation-type { napt-44; } } } } } } -
Conjuntos de servicio de enlace a la interfaz.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-ftp; } output { service-set set-ftp; } } address 10.10.10.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.10.10.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
ICMP
El protocolo de mensajes de control de Internet (ICMP) se define en RFC 792. Junos OS permite que los mensajes ICMP se filtren por tipo específico o por valor de código de tipo específico. Los paquetes de error ICMP que carecen de un tipo y código configurados específicamente se comparan con cualquier flujo existente en la dirección opuesta para comprobar la legitimidad del paquete de error. Los paquetes de error ICMP que pasan la coincidencia de filtros están sujetos a traducción TDR.
El ALG ICMP siempre rastrea el tráfico ping con estado utilizando el número de secuencia ICMP. Cada respuesta de eco se reenvía solo si hay una solicitud de eco con el número de secuencia correspondiente. Para cualquier flujo de ping, solo se pueden reenviar 20 solicitudes de eco sin recibir una respuesta de eco. Cuando se configura TDR dinámico, el identificador de paquete PING se traduce para permitir que hosts adicionales en el conjunto de TDR utilicen el mismo identificador.
La compatibilidad con servicios TDR requiere que configure el ALG ICMP si se necesita el protocolo. Puede configurar el tipo y el código de ICMP para un filtrado adicional.
TFTP
El protocolo de transferencia de archivos trivial (TFTP) se especifica en RFC 1350. Las solicitudes TFTP iniciales se envían al puerto de destino UDP 69. Se pueden crear flujos adicionales para obtener o colocar archivos individuales. La compatibilidad con servicios TDR requiere que configure el ALG TFTP para el puerto de destino UDP 69.
A continuación se muestra un ejemplo para configurar TFTP ALG:
-
Crear interfaz TDR.
[edit] services { service-set set-tftp { nat-rules nat-tftp; interface-service { service-interface ms-0/2/0; } } -
Configuración del conjunto TDR.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definición de reglas de TDR para ALG TFTP.
[edit] services { nat { rule nat-tftp { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-tftp; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Conjuntos de servicio de enlace a la interfaz.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-tftp; } output { service-set set-tftp; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
Servicios de shells remotos de UNIX
Tres protocolos forman la base de los servicios de shells remotos de UNIX:
-
Ejecutivo: ejecución remota de comandos; Permite a un usuario del sistema cliente ejecutar un comando en el sistema remoto. El primer comando del cliente (
rcmd) al servidor (rshd) utiliza el conocido puerto TCP 512. Se puede abrir una segunda conexión TCP a petición dercmd. El número de puerto de cliente para la segunda conexión se envía al servidor como una cadena ASCII. -
Iniciar sesión: más conocido como
rlogin; utiliza el conocido puerto TCP 513. Para obtener más información, consulte RFC 1282. No se requiere ningún procesamiento especial de firewall. -
Shell: ejecución remota de comandos; Permite a un usuario del sistema cliente ejecutar un comando en el sistema remoto. El primer comando del cliente (
rcmd) al servidor (rshd) utiliza el conocido puerto TCP 514. Se puede abrir una segunda conexión TCP a petición dercmd. El número de puerto de cliente para la segunda conexión se envía al servidor como una cadena ASCII.
Los servicios de shell remoto de TDR requieren que cualquier puerto de origen dinámico asignado esté dentro del intervalo de puertos 512 a 1023. Si configura un grupo TDR, este intervalo de puertos está reservado exclusivamente para aplicaciones de shell remotas.
A continuación se muestra un ejemplo para configurar RSH ALG:
-
Crear interfaz TDR.
[edit] services { service-set set-rsh { nat-rules nat-rsh; interface-service { service-interface ms-0/2/0; } } -
Configuración del conjunto TDR.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definición de reglas TDR para RSH ALG.
[edit] services { nat { rule nat-rsh { match-direction input; term term1 { from { source-address { 510.0.50.2/32; } applications junos-rsh; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Conjuntos de servicio de enlace a la interfaz.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-rsh; } output { service-set set-rsh; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
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.
deterministic-napt64 compatible con MS-MPC y MS-MIC
stateful-nat464
twice-dynamic-nat-44 compatible con MS-MPC y MS-MIC
twice-basic-nat-44 compatible con TDR en línea
twice-dynamic-nat-44 compatible con MS-MPC y MS-MIC
twice-dynamic-napt-44 compatible con MS-MPC y MS-MIC
deterministic-napt44 compatible con MS-MPC y MS-MIC