Descripción general de la traducción de direcciones de red
Descripción general del direccionamiento de red con reconocimiento de direcciones de Junos
El direccionamiento de red con reconocimiento de direcciones de Junos proporciona la funcionalidad de traducción de direcciones de red (NAT) para traducir direcciones IP. Esto es particularmente importante porque la Autoridad de Asignación de Números de Internet (IANA) asignó el último gran bloque de direcciones IPv4 a principios de 2011.
En este tema se incluyen las siguientes secciones:
- Beneficios de NAT
- Descripción general del concepto y las instalaciones de NAT
- NAT básica de IPv4 a IPv4
- NAPT determinista
- NAT de destino estático
- Dos veces NAT
- TDR IPv6
- Compatibilidad con puerta de enlace a nivel de aplicación (ALG)
- NAT-PT con DNS ALG
- TDR dinámica
- NAT64 con estado
- 464XLAT
- Lite de doble pila
- Soporte de tarjeta de línea de direccionamiento de red consciente de direcciones de Junos
Beneficios de NAT
NAT admite una amplia gama de objetivos de red, entre los que se incluyen:
Ocultar un conjunto de direcciones de host en una red privada detrás de un grupo de direcciones públicas para proteger las direcciones de host de ataques directos a la red y evitar el agotamiento de las direcciones IPv4
Proporcionar las herramientas para la transición a IPv6 según los requisitos del negocio y para garantizar el crecimiento ininterrumpido de suscriptores y servicios
Proporcionar coexistencia IPv4–IPv6
Descripción general del concepto y las instalaciones de NAT
El direccionamiento de red con reconocimiento de direcciones de Junos proporciona NAT de grado de operador (CGN) para redes IPv4 e IPv6, y facilita el tránsito de tráfico entre diferentes tipos de redes.
Junos Address Aware Network Addressing admite un conjunto diverso de opciones de traducción de NAT:
Traducción de origen estático: permite ocultar una red privada. Cuenta con un mapeo 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 NAT básica .
NAPT determinista: elimina la necesidad de registrar la traducción de direcciones al garantizar que la dirección y el puerto IPv4 o IPv6 de origen originales siempre se asignen a la misma dirección IPv4 y al mismo intervalo de puertos posteriores a NAT.
Traducción de origen dinámico: incluye dos opciones: traducción dinámica de origen de solo dirección y traducción de puertos de direcciones de red (NAPT):
Traducción de origen de sólo dirección dinámica: mdash; Una dirección NAT se recoge dinámicamente de un grupo NAT 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 NAT 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 NAT correspondiente. Para obtener más información, consulte NAPT .
Traducción estática de destino: permite hacer accesibles los servidores privados seleccionados. Cuenta con un mapeo 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 NAT de destino estático.
Traducción de protocolos: permite asignar direcciones de un grupo de forma estática o dinámica a medida que las sesiones se inician a través de límites IPv4 o IPv6. Para obtener más información, consulte Configuración de NAT-PT , NAT-PT con DNS ALG y NAT64 con estado.
Encapsulación de paquetes IPv4 en paquetes IPv6 mediante cables: permite que los paquetes viajen por cables blandos hasta un punto de conexión NAT de grado portador donde se someten a procesamiento NAT de origen para ocultar la dirección de origen original. Para obtener más información, consulte Información general sobre Servicios de tunelización para la transición de IPv4 a IPv6.
Junos Address Aware Network Addressing admite la funcionalidad NAT descrita en las RFC del IETF y los borradores de Internet, tal y como se muestra en " Estándares NAT y SIP compatibles" en la Referencia de estándares.
No todos los tipos de NAT son compatibles con todos los tipos de interfaz. Consulte Comparación de características NAT de grado de operador para Junos Address Aware por tipo de tarjeta de interfaz, que enumera las funciones disponibles en las interfaces compatibles.
NAT básica de IPv4 a IPv4
La traducción básica de direcciones de red o NAT 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 única dirección de red y sus puertos TCP/UDP. Juntas, estas dos operaciones, denominadas NAT tradicional, proporcionan un mecanismo para conectar un dominio con direcciones privadas a un dominio externo con direcciones registradas únicas globalmente.
El NAT tradicional, especificado en RFC 3022, Traductor de direcciones de red IP tradicionales, es totalmente compatible con el direccionamiento de red consciente de direcciones de Junos. Además, NAPT es compatible con las direcciones de origen.
NAT básica
Con NAT básica, se reserva un bloque de direcciones externas para traducir direcciones de hosts en un dominio privado a medida que originan sesiones al dominio externo. Para los paquetes que salen de la red privada, Basic NAT traduce las direcciones IP de origen y campos relacionados, como las sumas de comprobación de encabezado IP, TCP, UDP e ICMP. Para los paquetes entrantes, NAT básica traduce la dirección IP de destino y las sumas de comprobación enumeradas anteriormente.
La horquilla es compatible con NAT básico.
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 NAT básica para usar un grupo 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 campos relacionados, como las sumas de comprobación de encabezado IP, TCP, UDP e ICMP. Para los paquetes entrantes, NAPT traduce la dirección IP de destino, el identificador de transporte de destino y las sumas de comprobación de IP y encabezado de transporte.
En los enrutadores serie MX con MS-MIC y MS-MPC, si configura una regla NAT NAPT44 y la dirección IP de origen de un paquete falsificado es igual al grupo NAT y se produce un error en la condición de coincidencia de regla NAT, el paquete se recorre 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 NAT en tales condiciones.
La horquilla es compatible con NAPT.
NAPT determinista
Utilice NAPT44 determinista para asegurarse de que la dirección IPv4 y el puerto de origen originales siempre se asignen a la misma dirección IPv4 y rango de puertos posteriores a NAT, y que la asignación inversa de una dirección IPv4 externa traducida y un puerto traducidos siempre se asignen a la misma dirección IP interna. Esto elimina la necesidad de registrar la traducción de direcciones. A partir de Junos OS versión 17.4R1, NAPT64 determinista es compatible con MS-MPC y MS-MIC. El NAPT64 determinista garantiza que la dirección IPv6 y el puerto de origen originales siempre se asignen a la misma dirección IPv4 y al mismo rango de puertos posteriores a la NAT, y que la asignación inversa de una dirección IPv4 externa traducida y un puerto traducidos siempre se asignen a la misma dirección IPv6 interna.
NAT de destino estático
Utilice NAT de destino estática para traducir la dirección de destino del tráfico externo a una dirección especificada en un grupo de destinos. El grupo de destino contiene una dirección y ninguna configuración de puerto.
Para obtener más información acerca de NAT de destino estático, consulte RFC 2663, Terminología y consideraciones del Traductor de direcciones de red IP (NAT).
Dos veces NAT
En Twice NAT, tanto las direcciones de origen como las de destino están sujetas a traducción a medida que los paquetes atraviesan el enrutador NAT. La información de origen a traducir puede ser sólo dirección o dirección y puerto. Por ejemplo, utilizaría Twice NAT cuando conecte dos redes en las que todas o algunas direcciones de una red se superponen con direcciones de otra red (independientemente de que la red sea privada o pública). En NAT tradicional, solo se traduce una de las direcciones.
Para configurar Twice NAT, debe especificar una dirección de destino y una dirección de origen para la dirección de coincidencia, el grupo o prefijo y el tipo de traducción.
Puede configurar puertas de enlace de nivel de aplicación (ALG) para ICMP y traceroute con firewall con estado, NAT o reglas de clase de servicio (CoS) cuando Twice NAT está configurado en el mismo conjunto de servicios. Estas ALG no se pueden aplicar a flujos creados por el Protocolo de control de puerta de enlace de paquetes (PGCP). Dos veces NAT no admite otras ALG. De forma predeterminada, la característica Twice NAT puede afectar a los encabezados IP, TCP y UDP incrustados en la carga de mensajes de error ICMP.
Twice NAT, especificado en RFC 2663, Terminología y consideraciones del traductor de direcciones de red IP (NAT), es totalmente compatible con el direccionamiento de red consciente de direcciones de Junos.
TDR IPv6
La NAT de IPv6 a IPv6 (NAT66), definida en el borrador de Internet draft-mrw-behave-nat66-01, Traducción de direcciones de red de IPv6 a IPv6 (NAT66), es totalmente compatible con el direccionamiento de red con reconocimiento de direcciones de Junos.
Compatibilidad con puerta de enlace a nivel de aplicación (ALG)
El direccionamiento de red con reconocimiento de direcciones de Junos admite varias ALG. Puede utilizar reglas NAT para filtrar el tráfico entrante en función de ALGS. Para obtener más información, vea Descripción general de las reglas de traducción de direcciones de red.
NAT-PT con DNS ALG
NAT-PT y ALG del Sistema de nombres de dominio (DNS) se utilizan para facilitar la comunicación entre hosts IPv6 y hosts IPv4. Mediante un conjunto de direcciones IPv4, NAT-PT asigna direcciones de ese grupo a nodos IPv6 de forma dinámica a medida que las sesiones se inician a través de los límites IPv4 o IPv6. Las sesiones entrantes y salientes deben atravesar el mismo enrutador NAT-PT para que pueda realizar un seguimiento de esas sesiones. RFC 2766, Traducción de direcciones de red: traducción de protocolos (NAT-PT), recomienda el uso de NAT-PT para la traducción entre nodos de solo IPv6 y nodos de 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árquica distribuido para computadoras, servicios o cualquier recurso conectado a Internet o a 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 DNS ALG se emplea con NAT-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ámica
El flujo NAT dinámico se muestra en la Figura 1.
NAT dinámico
Con NAT dinámica, puede asignar una dirección IP privada (origen) a una dirección IP pública extraída de un grupo de direcciones IP registradas (públicas). Las direcciones NAT del grupo se asignan dinámicamente. La asignación dinámica de direcciones también permite que varios hosts privados utilicen algunas direcciones IP públicas, en contraste con un conjunto de igual tamaño requerido por NAT estática de origen.
Para obtener más información acerca de la traducción de direcciones dinámicas, consulte RFC 2663, Terminología y consideraciones del Traductor de direcciones de red IP (NAT).
NAT64 con estado
El flujo de estado de NAT64 se muestra en la Figura 2.
NAT64 con estado
Stateful NAT64 es un mecanismo para moverse a una red IPv6 y al mismo tiempo lidiar con el agotamiento de direcciones IPv4. Al permitir que los clientes solo IPv6 se pongan en contacto con servidores IPv4 mediante UDP, TCP o ICMP de unidifusión, 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 o en el servidor IPv4. DNS64 está fuera del alcance de este documento porque normalmente se implementa como una mejora de los servidores DNS implementados actualmente.
El NAT64 con estado, especificado en RFC 6146, Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, es totalmente compatible con Junos Address Aware Network Addressing.
464XLAT
A partir de Junos OS versión 17.1R1, puede configurar un 464XLAT Provider-Side Translater (PLAT). Esto solo se admite en MS-MICs y MS-MPCs. 464XLAT proporciona una técnica simple 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 punto a punto IPv4 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).
alámbrico 464XLAT
XLAT464 proporciona las ventajas de no tener que mantener una red IPv4 y no tener que asignar direcciones IPv4 públicas adicionales.
La 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 redes móviles implementar IPv6 para que sus usuarios and admitan aplicaciones solo IPv4 en dispositivos móviles (consulte la Figura 4).
inalámbrico 464XLAT
Lite de doble pila
El flujo de doble pila lite (DS-Lite) se muestra en la Figura 5.
DS-Lite
DS-Lite emplea túneles IPv4 sobre IPv6 para cruzar una red de acceso IPv6 y alcanzar una NAT IPv4-IPv4 de grado carrier. Esto facilita la introducción gradual de IPv6 en Internet al proporcionar compatibilidad con versiones anteriores de IPv4.
DS-Lite es compatible con enrutadores de la serie MX con MS-DPC y en enrutadores de la serie M con PIC multiservicios MS-100, MS-400 y MS-500. A partir de Junos OS versión 17.4R1, DS-Lite es compatible con enrutadores serie MX con MS-MPC y MS-MIC.A partir de Junos OS versión 19.2R1, DS-Lite es compatible con MX Virtual Chassis y enrutadores MX Broadband Network Gateway (BNG).
Soporte de tarjeta de línea de direccionamiento de red consciente de direcciones de Junos
Las tecnologías de direccionamiento de red con reconocimiento de direcciones de Junos están disponibles en las siguientes tarjetas de línea:
Concentrador de puerto denso multiservicios (MS-DPC)
PICS 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 (NAT en línea).
Para obtener una lista de los tipos de NAT específicos admitidos en cada tipo de tarjeta, consulte Comparación de características NAT de grado de operador para el reconocimiento de direcciones de Junos por tipo de tarjeta de interfaz.
Ver también
Escenarios de transición IPv6 de ejemplo
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 Internet (ISP) no ha cambiado significativamente su red IPv4. Este enfoque permite que los hosts IPv4 accedan a Internet IPv4 y a los hosts IPv6 accedan a Internet IPv6. Un host de doble pila se puede tratar 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
Se deben implementar dos nuevos tipos de dispositivos en este enfoque: una puerta de enlace doméstica de doble pila y una traducción de direcciones de red (NAT) de grado portador de doble pila. La puerta de enlace doméstica de doble pila integra funciones de reenvío IPv4 y tunelización v6 sobre v4. También puede integrar una función NAT v4-v4. El NAT de grado portador (CGN) de doble pila integra las funciones de tunelización v6-over-v4 y NAT 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) admite ISP solo IPv6. El mejor modelo de negocio para este enfoque es que el equipo en las instalaciones del cliente (CPE) ha integrado las funciones para tunelizar IPv6 a una red troncal IPv4, tunelizar IPv4 a una red troncal IPv6 y puede detectar automáticamente qué solución se requiere.
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 grupos de clientes (por ejemplo, todos los conectados a un único punto de presencia) de forma incremental. Tal 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 utilizar para permitir que los dispositivos IPv6 se comuniquen con hosts IPv4 sin modificar los clientes.
Descripción general de la implementación de NAT 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 denso multiservicios (MS-DPC): el paquete de servicios de capa 3 se usa para configurar NAT para PIC de servicios adaptativos de MS-DPC. Esta solución proporciona la funcionalidad NAT descrita en Descripción general del direccionamiento de red con reconocimiento de direcciones de Junos .
PIC multiservicios MS-100, MS-400 y MS-500: el paquete de servicios de capa 3 se utiliza para configurar NAT para PIC de multiservicios. Esta solución proporciona la funcionalidad NAT descrita en Descripción general del direccionamiento de red con reconocimiento de direcciones de Junos .
Concentrador de puerto modular multiservicios (MS-MPC) y tarjeta de interfaz modular multiservicios (MS-MIC): MS-MPC y MS-MIC están preconfigurados para permitir la configuración de NAT carrier-grade. Esta solución proporciona la funcionalidad NAT descrita en Descripción general del direccionamiento de red con reconocimiento de direcciones de Junos .
NAT en línea para tarjetas de línea de concentrador de puerto modular (MPC): NAT 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 NAT 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 características NAT 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 NAT de nivel de operador de Junos OS.
A partir de la versión 17.2R1 de Junos OS, se admite NAT en línea en MPC5E y MPC6E.
A partir de la versión 17.4R1 de Junos OS, se admite NAT en línea en MPC7E, MPC8E y MPC9E.
Característica |
MS-DPC MS-100 MS-400 MS-500 |
MS-MPC MS-MIC |
MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E y MPC9E TDR en línea |
|---|---|---|---|
NAT de origen estático |
Sí |
Sí |
Sí |
NAT de origen dinámico: solo dirección |
Sí |
Sí |
No |
NAT de origen dinámico: traducción de puertos NAPT con asignación segura de bloques de puertos |
Sí |
sí (NAT de origen dinámico: traducción de puertos NAPT con asignación segura de bloques de puertos compatible con MS-MPC y MS-MIC a partir de Junos OS versión 14.2R2) |
No |
NAT de origen dinámico: traducción de puertos NAPT44 con asignación determinista de bloques de puertos |
Sí |
sí (NAT de origen dinámico: traducción de puertos NAPT44 con asignación determinista de bloques de puertos compatible con MS-MPC y MS-MIC a partir de Junos OS versión 17.3R1, en Junos OS versión 14.2R7 y versiones posteriores 14.2, en 15.1R3 y versiones posteriores 15.1, y en 16.1R5 y versiones posteriores 16.1) |
No |
NAT de origen dinámico: traducción de puertos NAPT64 con asignación determinista de bloques de puertos |
No |
sí (NAT de origen dinámico: traducción de puertos NAPT64 con asignación determinista de bloques de puertos compatible con MS-MPC y MS-MIC a partir de Junos OS versión 17.4R1) |
No |
NAT de destino estático |
Sí |
Sí |
Sí
Nota:
La TDR de destino se puede implementar indirectamente. Consulte Descripción general de la traducción de direcciones de red en línea |
Dos veces NAT |
Sí |
sí (dos veces NAT compatible con MS-MPC y MS-MIC a partir de Junos OS versión 15.1R1) |
Sí
Nota:
Dos veces NAT 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 intervalo admitidos para MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS) |
No |
NAPT - APP/FEI/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 |
NAT64 con estado |
Sí |
Sí |
No |
NAT64 con estado con APP/EIM/EIF |
No |
Sí |
No |
NAT64 con estado de ALG
|
No |
Sí |
No |
DS-Lite |
Sí |
sí (DS-Lite es compatible con MS-MPC y MS-MIC a partir de Junos OS versión 17.4R1) |
No |
6º |
Sí |
No |
No |
6to4 |
Sí |
No |
No |
464XLAT |
No |
sí (a partir de Junos OS versión 17.1R1) |
No |
Dirección superpuesta en todo el grupo NAT |
Sí |
Sí |
No |
| Pool 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 Junos OS versión 18.2R1, el protocolo de control de puertos en MS-MPC y MS-MIC admite DS-Lite. PCP proporciona un mecanismo para controlar el reenvío de paquetes entrantes mediante dispositivos ascendentes como NAT44 y dispositivos de firewall, y un mecanismo para reducir el tráfico 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 es compatible con 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í |
La Tabla 2 resume la disponibilidad de tipos de traducción por tipo de tarjeta de línea.
Tipo de traducción |
MS-DPC 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 NAT en las plataformas enumeradas.
Para ver los detalles de implementación (puerto, protocolo, etc.) de estas aplicaciones predeterminadas de Junos OS, busque el nombre ALG predeterminado de Junos OS en la tabla y, a continuación, busque el nombre listado en el groupsarchivo . Por ejemplo, para obtener detalles sobre TFTP, busque como junos-tftp se muestra.
Junos OS proporciona el junos-alg, que permite que otras ALG funcionen controlando registros de ALG, lo que hace que los paquetes de ruta lenta fluyan a través de las ALG registradas y transfiera eventos 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) y de inicio de sesión remoto (rlogin) no son compatibles con la traducción de puertos de direcciones de red (NAPT) en enrutadores 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 las ALG disponibles para Junos OS Address Aware NAT para tarjetas de interfaces de servicios.
ALG |
MS-DPC |
MS-MPC, MS-MIC |
Nombre ALG predeterminado de Junos OS |
|---|---|---|---|
ALG TCP básico |
Sí |
Sí |
Nota:
No se admiten ALG específicas de Junos OS. Sin embargo, una característica llamada rastreador TCP, disponible de forma predeterminada, realiza el orden de segmentos y el seguimiento de retransmisiones y conexiones, validaciones para conexiones TCP. |
ALG UDP básico |
Sí |
Sí |
Nota:
El rastreador TCP realiza comprobaciones limitadas de integridad y validación para UDP. |
BOOTP |
Sí |
No |
|
Servicios RPC de DCE |
Sí |
Sí |
|
DNS |
Sí |
Sí |
|
DNS |
No |
No |
|
FTP |
Sí |
Sí |
|
RAS de Gatekeeper (a partir de Junos OS versión 17.1R1) |
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 manejan 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, la alg de ALG de IKE se admite en 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 |
|
Servicios de mapas de puertos RPC y RPC de Sun |
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 NAT en las tarjetas de interfaz MS-MIC y MS-MPC. Las sesiones SIP en MS-DPC 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 direcciones de red (NAPT). |
|
WINFrame |
Sí |
No |
|
TALK-UDP |
No |
Sí |
|
MS RPC |
No |
Sí |
|
Ver también
ALG disponibles de forma predeterminada para la TDR con reconocimiento de direcciones de Junos OS 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 NAT en enrutadores ACX500.
Para ver los detalles de implementación (puerto, protocolo, etc.) de estas aplicaciones predeterminadas de Junos OS, busque el nombre ALG predeterminado de Junos OS en la tabla y, a continuación, busque el nombre listado en el groupsarchivo . Por ejemplo, para obtener detalles sobre TFTP, busque como junos-tftp se muestra.
El ALG para NAT solo se admite en los enrutadores interiores ACX500.
Junos OS proporciona el junos-alg, que permite que otras ALG funcionen controlando registros de ALG, lo que hace que los paquetes de ruta lenta fluyan a través de las ALG registradas y transfiera eventos 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 (inicio de sesión) no son compatibles con la traducción de puertos de direcciones de red (NAPT) en el enrutador ACX500.
| ALG |
Enrutador ACX500 |
Nombre ALG predeterminado de Junos OS |
|---|---|---|
| ALG TCP básico |
Sí |
Nota:
No se admiten ALG específicas de Junos OS. Sin embargo, una característica llamada rastreador TCP, disponible de forma predeterminada, realiza el orden de segmentos y el seguimiento de retransmisiones y conexiones, validaciones para conexiones TCP. |
| ALG UDP 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 compatibilidad con 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 direcciones 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 de cordura básica en paquetes TCP. Si encuentra errores, genera los siguientes eventos de anomalía y mensajes de registro del sistema:
-
Puerto cero de origen o destino TCP
-
Error en la comprobación de longitud del encabezado TCP
-
Se establece el número de secuencia TCP cero y no se establecen indicadores
-
Se establecen los indicadores TCP número cero y FIN/PSH/RST
-
TCP FIN/RST o SYN(URG|FIN|RST) se establecen los indicadores
El ALG TCP realiza los pasos siguientes:
-
Cuando el enrutador recibe un paquete SYN, el ALG crea flujos TCP hacia adelante y hacia atrás y los agrupa en una conversación. Rastrea el protocolo de enlace 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 dentro de un pequeño intervalo de tiempo (actualmente 4 segundos). Si el protocolo de enlace de tres vías TCP no se establece en ese período, la sesión termina.
-
Un mecanismo keepalive detecta sesiones TCP con puntos finales que no responden.
-
Los errores ICMP solo se permiten cuando un flujo coincide con la información del selector especificada en los datos ICMP.
UDP básico
Este ALG realiza una comprobación de cordura básica 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 longitud del encabezado UDP
El ALG UDP realiza los pasos siguientes:
-
Cuando recibe el primer paquete, el ALG crea flujos bidireccionales para aceptar tráfico de sesión UDP directo e inverso.
-
Si la sesión está inactiva durante más del tiempo de inactividad máximo permitido (el valor predeterminado es 30 segundos), se eliminan los flujos.
-
Los errores ICMP solo se permiten cuando un flujo coincide con la información del selector especificada en los datos ICMP.
DNS
El ALG del Sistema de nombres de dominio (DNS) maneja los 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 supervisa los paquetes de consulta y respuesta DNS y solo admite tráfico UDP. El ALG no admite traducciones de carga. El ALG de DNS cierra la sesión solo cuando se recibe una respuesta o se alcanza un tiempo de espera inactivo.
El siguiente es un ejemplo para configurar DNS ALG:
-
Creación de interfaz NAT.
[edit] services { service-set set-dns { nat-rules nat-dns; interface-service { service-interface ms-0/2/0; } } -
Configuración del grupo NAT.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definición de reglas NAT 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; } } } } } } -
Enlazar conjuntos de servicios 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 en busca del comando PORT, que proporciona la dirección IP y el número de puerto a los que se conecta el servidor. Para el FTP en modo pasivo, el servicio de firewall con estado de Junos OS analiza los datos de la aplicación de cliente a servidor en busca del comando PASV y, a continuación, 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 al 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, es posible que se cambie el número de secuencia TCP y, a partir de entonces, el servicio NAT necesita mantener este delta en los números SEQ y ACK realizando NAT de secuencia en todos los paquetes posteriores.
La compatibilidad con firewall con estado y servicios NAT requiere que configure el ALG FTP 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 la conexión dinámica de datos
-
Crea flujos para la conexión de datos negociada dinámicamente
-
Supervisa la conexión de control en los modos activo y pasivo
-
Reescribe los paquetes de control con la dirección NAT y la información de puerto adecuadas
En ACX500, para que el FTP pasivo funcione correctamente sin la puerta de enlace de capa de aplicación (ALG) FTP habilitada (al no especificar la instrucción en el nivel de jerarquía), debe habilitar la funcionalidad de agrupación de direcciones emparejadas (APP) habilitada (incluyendo la application junos-ftp address-pooling instrucción en el nivel de [edit services nat rule rule-name term term-name from] [edit services nat rule rule-name term term-name then translated] jerarquía). Dicha configuración hace que los datos y las sesiones FTP de control reciban la misma dirección NAT.
A continuación se muestra un ejemplo para configurar ALG FTP:
-
Creación de interfaz NAT.
[edit] services { service-set set-ftp { nat-rules nat-ftp; interface-service { service-interface ms-0/2/0; } } -
Configuración del grupo NAT.
[edit] services { nat { pool p-napt { address 10.30.30.0/24; port { range low 9000 high 9010; } } } -
Definición de reglas NAT para ALG FTP.
[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; } } } } } } -
Enlazar conjuntos de servicios 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 NAT.
El ALG de ICMP siempre rastrea el tráfico de ping de forma estatal 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 NAT dinámico, el identificador de paquete PING se traduce para permitir que otros hosts del grupo NAT utilicen el mismo identificador.
La compatibilidad con servicios NAT requiere que configure el ALG ICMP si el protocolo es necesario. Puede configurar el tipo y el código ICMP para un filtrado adicional.
TFTP
El Protocolo trivial de transferencia de archivos (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 los servicios NAT requiere que configure el ALG TFTP para el puerto de destino UDP 69.
El siguiente es un ejemplo para configurar TFTP ALG:
-
Creación de interfaz NAT.
[edit] services { service-set set-tftp { nat-rules nat-tftp; interface-service { service-interface ms-0/2/0; } } -
Configuración del grupo NAT.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definición de reglas NAT 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; } } } } } } -
Enlazar conjuntos de servicios 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 shell remoto de UNIX
Tres protocolos forman la base para los servicios de shell remoto 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 () al servidor (
rcmdrshd) utiliza el conocido puerto TCP 512. Se puede abrir una segunda conexión TCP a petición dercmd. El número de puerto del cliente para la segunda conexión se envía al servidor como una cadena ASCII. -
Inicio de 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 de firewall especial. -
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 () al servidor (
rcmdrshd) utiliza el conocido puerto TCP 514. Se puede abrir una segunda conexión TCP a petición dercmd. El número de puerto del cliente para la segunda conexión se envía al servidor como una cadena ASCII.
Los servicios de shell remoto NAT requieren que cualquier puerto de origen dinámico asignado esté dentro del intervalo de puertos 512 a 1023. Si configura un grupo NAT, este intervalo de puertos está reservado exclusivamente para aplicaciones de shell remotas.
A continuación se muestra un ejemplo para configurar RSH ALG:
-
Creación de interfaz NAT.
[edit] services { service-set set-rsh { nat-rules nat-rsh; interface-service { service-interface ms-0/2/0; } } -
Configuración del grupo NAT.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definición de reglas NAT 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; } } } } } } -
Enlazar conjuntos de servicios 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 con las funciones viene determinada por la plataforma y la versión que esté utilizando. 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 NAT 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