NAT ALG

Publicado 2019-1-21 17:30:40 85 0 0 0

En las secciones anteriores, he introducido Source NAT y NAT Server y NAT bidireccional soportado por firewalls.

Estas funciones NAT se pueden utilizar de forma flexible en diferentes escenarios.

Como sabemos, NAT sólo traduce las direcciones en los encabezados. Para algunos protocolos, como FTP, las cargas útiles de paquetes también llevan información de direcciones. Si los firewalls no pueden procesar correctamente dicha información, FTP puede no funcionar correctamente. Bueno, ¿cómo deberían los cortafuegos procesar paquetes de protocolo?


1.  FTP Packets Traversing NAT Devices.

Usemos FTP como ejemplo para ver qué problemas ocurren cuando los paquetes FTP intentan pasar a través de dispositivos NAT.

En este ejemplo, un cliente FTP reside en una intranet, y un servidor FTP reside en Internet. FTP funciona en modo activo.

La Figura 1-1 muestra el proceso de interacción FTP en el dispositivo NAT. Figura 1-1 Proceso de interacción FTP 1 cuando la fuente NAT es configured


5578e8c4a9659.png



Podemos ver que después de establecer una conexión de control entre el cliente FTP y el servidor, el cliente envía un paquete de comandos PORT al servidor, y el paquete contiene la dirección privada y el puerto del cliente. 

El firewall envía directamente el paquete al servidor. Después de recibir el paquete, el servidor FTP inicia una conexión de datos a 192.168.1.2 según las instrucciones del comando PORT. 

El problema es incurrido. 192.168.1.2 es una dirección privada. Los paquetes destinados a esta dirección no pueden transmitirse en Internet. Como resultado, el servicio FTP es anormal.


¿Qué debería hacer el firewall para resolver el problema? 

Si el firewall traduce tanto la dirección de origen en la cabecera como la dirección IP en la información de la capa de aplicación en la carga útil, se puede establecer la conexión de datos.



El Gateway de Nivel de Aplicaciones NAT (la función ALG) resuelve el problema. 

Como técnica para ayudar a los paquetes que atraviesan cortafuegos, el NAT ALG permite que un firewall traduzca las direcciones IP tanto en encabezados como en cargas útiles.


La Figura 1-2 muestra el proceso de interacción FTP después de habilitar el ALG NAT en el firewall.

Figura 1-2 Proceso de interacción FTP 2 cuando se configura Source NAT


5578e8d2cc21e.png



Una vez habilitado el NAT ALG, el firewall traduce la dirección IP transportada en la carga útil del paquete de comandos PORT a la dirección pública 1.1.1.1 

Después de recibir el paquete, el servidor FTP inicia una conexión de datos a 1.1.1.1


Puede que tengas otra pregunta. ¿Puede el firewall permitir la solicitud de conexión incluso si el servidor FTP puede iniciar la solicitud de conexión?

Esta pregunta es tan familiar. ¿Cierto?Para encontrar la respuesta, volvamos a la función ASPF en el capítulo 2 "Política de seguridad". 

Después de habilitar ASPF, el firewall abre un canal invisible para que los datos de FTP eviten las verificaciones de la política de seguridad, atravesando el cortafuegos. El servicio FTP requiere ASPF en escenarios NAT. En realidad, NAT ALG y ASPF se implementan utilizando un comando. Enabling NAT ALG también cuenta con ASPF habilitado. Por lo tanto, después de habilitar NAT ALG, se genera la siguiente entrada del mapa del servidor:




Type: ASPF,  3.3.3.3 -> 1.1.1.1:24576[192.168.1.2:55177],  Zone:---  
 Protocol: tcp(Appro: ftp-data),  Left-Time:00:00:03,  Pool: ---                
 Vpn: public -> public



Esta entrada del mapa del servidor tiene información de traducción de direcciones. Antes de que expire el tiempo de envejecimiento, esta entrada ayuda a que el paquete de solicitud de conexión de datos del servidor FTP atraviese el cortafuegos y llegue con precisión al cliente FTP de la intranet. La Figura 1-3 muestra el proceso completo de interacción FTP.

Figura 1-3 Proceso de interacción FTP 3 cuando se configura Source NAT




5578e8e39f4ff.png



Además del escenario NAT de origen, el escenario NAT Server requiere ALG y ASPF de NAT. En este ejemplo, un cliente FTP reside en Internet, y un servidor FTP reside en una intranet. FTP funciona en modo pasivo. La Figura 1-4 muestra el proceso completo de interacción FTP.

Figura 1-4 Proceso de interacción FTP cuando se configura NAT Server



5578e8f2ed41a.png


Las siguientes entradas del server-map se generan en el firewall:


[FW] display firewall server-map

server-map item(s)

 ------------------------------------------------------------------------------

 Nat Server, any -> 1.1.1.1:21[192.168.1.2:21], Zone: ---

   Protocol: tcp(Appro: ftp), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

 

 Nat Server Reverse, 192.168.1.2[1.1.1.1] -> any, Zone: ---

   Protocol: any(Appro: ---), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

 

 ASPF, 3.3.3.3 -> 1.1.1.1:4097[192.168.1.2:2049], Zone: ---

   Protocol: tcp(Appro: ftp-data), Left-Time: 00:00:53, Addr-Pool: ---

   VPN: public -> public



El paquete de conexión de control iniciado por el cliente FTP coincide con la entrada del mapa del servidor hacia adelante para NAT Server y se traduce la dirección. El paquete de conexión de datos iniciado por el cliente FTP coincide con la entrada del mapa del servidor para ASPF y se traduce la dirección.


En conclusión, si se utilizan protocolos multicanal tales como FTP, SIP y H.323 y NAT se aplica en una red, se recomienda tanto NAT ALG como ASPF en el firewall, para que los protocolos puedan funcionar correctamente.



2 paquetes de protocolo definidos por el usuario QQ/MSN/que atraviesan dispositivos NAT

También mencionamos QQ y MSN, y protocolos definidos por el usuario en "Security Policy". Firewalls clasifica estos protocolos en un tipo: "STUN". STUN es corto para Simple Traversal of UDP Through Network Address Translators que es un modo de transversal NAT. A diferencia de ALG NAT, el STUN no necesita ningún procesamiento en dispositivos NAT. En cambio, el cliente STUN en una intranet obtiene su dirección pública a través de intercambios de información entre el cliente STUN y el servidor. Luego, el cliente agrega la dirección pública en la carga útil y envía el paquete. De esta manera, el servidor en Internet obtiene la dirección pública del cliente desde la carga útil e inicia una solicitud de conexión al cliente.


Los protocolos STUN son responsables de su funcionamiento durante la traducción de direcciones. Por lo tanto, no se requiere NAT ALG para estos protocolos. Sin embargo, todavía tenemos que considerar cómo hacer que sus paquetes de servicios pasen a través del firewall. La solución también es ASPF Después de un paquete m


El TFTP se utiliza como ejemplo. La siguiente parte proporciona una entrada de mapa de servidor ASPF para el protocolo definido por el usuario en un escenario NAT (las entradas del servidor-mapa generadas para QQ y MSN son similares a esta entrada server-map):


Type: STUN,  ANY -> 1.1.1.1:4096[192.168.1.2:63212],  Zone:---          

 Protocol: udp(Appro: stun-derived),  Left-Time:00:04:58,  Pool: 1, Section: 0 

 Vpn: public -> public

 Type: STUN Reverse,  192.168.1.2:63212[1.1.1.1:4096] -> ANY,  Zone:---  

 Protocol: udp(Appro: stun-derived),  Left-Time:00:04:58,  Pool: 1, Section: 0 

 Vpn: public -> public



A diferencia de las entradas generadas en escenarios no NAT, estas entradas contienen información de traducción de direcciones. Además, se generan dos entradas del mapa del servidor. La entrada con el Tipo ser STUN es la entrada avanzada, mientras que la entrada con el Tipo ser STUN Reverse es la entrada inversa.


Antes de que expire el tiempo de envejecimiento, la entrada avanzada ayuda a la solicitud de conexión iniciada por el servidor TFTP atravesar el firewall y llegar con precisión al cliente TFTP en la intranet; la entrada inversa ayuda al firewall a traducir la dirección y el puerto (63212). Esta implementación garantiza que una aplicación específica (identificada por el número de puerto) para un usuario de intranet se presente utilizando la dirección pública fija y el puerto, asegurando el funcionamiento normal de los servicios TFTP.



3 un comando que controla dos funciones

En los firewalls de Huawei, se controlan ASPF y NAT ALG utilizando comandos separados. En la actualidad, la mayoría de los firewalls utilizan un comando para controlar estas dos funciones. Para ser específico, el comando detect se puede utilizar en la vista Intrazone o interzona para habilitar ASPF Luego, el ALG de NAT se activa automáticamente.


El firewall determina el uso del ALG de NAT, el ASPF o ambos según sea necesario. Lo que debemos hacer es sólo ejecutar el comando, reduciendo la carga de trabajo de configuración.


Especifica los protocolos típicos, la Tabla 1-1 enumera los modos de procesamiento del firewall después de utilizar el comando detect.


Tabla 1-1 Modos de procesamiento para protocolos típicos



Typical Protocol

NAT Scenario or Not

Effective Function

Effect

FTP

SIP

H323

Non-NAT scenario

ASPF

Server-map entries are generated to help the packets from other hosts to FTP, SIP, and H.323 hosts traverse the firewall.

NAT scenario

NAT ALG

The IP addresses in payloads are translated.

ASPF

Server-map entries (with address translation information) are generated to help the packets from other hosts on the Internet to FTP, SIP, and H.323 hosts on an intranet traverse the firewall.

QQ

MSN

User-defined

Non-NAT scenario

ASPF

Triplet server-map entries are generated to help the packets from other hosts to QQ, MSN, and user-defined hosts traverse the firewall.

NAT scenario

ASPF

Triplet server-map entries (with address translation information) are generated to help the packets from other hosts on the Internet to QQ, MSN, and user-defined hosts on an intranet traverse the firewall.



Como se indica en la tabla anterior, el ASPF genera una entrada triplet server-map para un protocolo definido por el usuario en el escenario NAT. También mencionamos a Triplet NAT en la sección 4.1.6 Triplet NAT. ¿Cuál es la diferencia entre ellos?


4 Diferencias entre ASPF para protocolos definidos por el usuario y Triplet NAT

Triplet NAT permite la coexistencia de P2P y NAT. Cuando un host de intranet accede a Internet, se establece un sistema de red asimétrico después de que NAT se realiza en un firewall. Esto significa que el host de intranet puede acceder a Internet, pero los usuarios de Internet no pueden iniciar el acceso al host de la intranet.


Después de la implementación de triplet NAT, el firewall genera una entrada del servidor-mapa para permitir que los paquetes de un usuario de Internet al usuario de la intranet atraviesen el firewall. De esta manera, las aplicaciones basadas en P2P como el intercambio de archivos, las comunicaciones de voz y la transmisión de vídeo pueden ejecutarse correctamente en escenarios NAT.


El mapa del servidor para el triple NAT contiene las entradas de origen (forward) y destino (inversa).



Type: FullCone Src,  192.168.1.2:51451[1.1.1.1:2048] -> ANY,  Zone:---  

 Protocol: tcp(Appro: ---),  Left-Time:00:00:57,  Pool: 1, Section: 0          

 Vpn: public -> public

 Type: FullCone Dst,  ANY -> 1.1.1.1:2048[192.168.1.2:51451],  Zone:---  

 Protocol: tcp(Appro: ---),  Left-Time:00:00:57,  Pool: 1, Section: 0          

 Vpn: public -> public



En el ejemplo anterior, la entrada marcada FullCone Src es la entrada del servidor-mapa de origen. Antes de que expire el tiempo de envejecimiento, las direcciones de los paquetes que el host de intranet inicia utilizando el puerto específico (51451) a Internet se traducen a la dirección pública (1.1.1.1) y port (2048). Esta implementación garantiza que una aplicación específica (identificada por el número de puerto) para el usuario de la intranet se presente utilizando la dirección pública fija y el puerto, asegurando el funcionamiento normal de los servicios P2P. La entrada marcada FullCone Dst es la entrada del servidor-mapa de destino. Antes de que expire el tiempo de envejecimiento, los usuarios de Internet pueden iniciar el acceso al usuario de intranet especificado.



Si comparamos estas entradas del mapa del servidor con las entradas triplet server-map que ASPF genera para los protocolos definidos por user en los escenarios NAT, podemos encontrar que dos entradas del mapa del servidor se generan en ambas condiciones, incluyendo la dirección, el puerto y la información del protocolo. El procesamiento de ASPF para protocolos definidos por el usuario en escenarios NAT puede considerarse como una implementación NAT especial de triplet. Ambas técnicas permiten que los paquetes P2P atraviesen cortafuegos.



Vamos a ver su diferencia. ASPF se aplica tanto a los escenarios NAT como no -NAT. En los escenarios no -NAT, el mapa del servidor de triplet entries no lleva información de traducción de direcciones. En los escenarios NAT, las entradas triplet server-map llevan información de traducción de direcciones. Como modo NAT, triplet NAT sólo funciona en escenarios NAT, y sus entradas de mapa de servidores llevan información de traducción de direcciones.



Otra diferencia importante es que después de que un paquete coincida con una entrada de mapa de servidor de tripleta ASPF, el firewall permite que el paquete pase a través de las políticas de seguridad (el comando aspf packet-filter acl-number {inbound by outbound} en la vista interzone. Si esta función está habilitada, el firewall no verifica el paquete. Si esta función está deshabilitada, el firewall comprueba el paquete.


Desde la perspectiva de la configuración, la configuración de ASPF para un protocolo definido por el usuario requiere la familiaridad de las características del protocolo para la definición exacta de ACL. Una configuración incorrecta puede hacer que el protocolo no pueda funcionar o afectar el funcionamiento normal de otros servicios. En comparación con la configuración ASPF, la configuración NAT de triplet es más sencilla. Lo que debemos hacer es configurar una política NAT y especificar el modo de pool de direcciones para triplet NAT (full-cone).



Sus condiciones de soporte en los firewalls de Huawei también difieren. La serie USG9500 soporta tanto ASPF para protocolos definidos por el usuario como NAT de triplet; la serie USG2000/5000/6000 soporta sólo ASPF para protocolos usuario defined. Cuando existen aplicaciones NAT y P2P en una red, se recomienda configurar el NAT triplet en la serie USG9500 o ASPF para los protocolos definidos por el usuario en la serie USG2000/5000/6000 para el funcionamiento normal de los servicios P2P.



Table 1-2 lists the comparison between ASPF for user-defined protocols and triplet NAT.

Table 1-2 Differences between ASPF for user-defined protocols and triplet NAT

Item

ASPF for User-defined Protocols

Triplet NAT

Server-map entry elements

Triplet

Including the address, port, and protocol type

Triplet

Including the address, port, and protocol type

Number of server-map entries

Two

Including the forward and reverse entries

Two

Including the source and destination entries

Operating environment

NAT and non-NAT scenarios

NAT scenario

Impact on security policies

The packets matching ASPF server-map entries are not controlled by security policies.

A specific command setting determines whether the packets matching triplet NAT server-map entries are controlled by security policies.

Configuration requirement

ACL rules must be accurately defined.

The NAT address pool must be set to the full-cone mode.

Support condition

Supported by the USG2000/5000/6000/9500 series

Supported only by the USG9500

 


  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesi | Registrarse

Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente

¡Ingresa y disfruta de todos los beneficios para los miembros!

Aterrizaje
Respuesta rápida Desplácese hasta arriba