NAT bidireccional

120 0 0 0

Con la descripción en las secciones anteriores, creo que usted sabe cuáles son los servidores Source NAT y NAT Server. Con las dos funciones NAT, un firewall traduce fácil y hábilmente tanto el tráfico entrante como el saliente. Bueno, ¿pueden las dos funciones NAT trabajar juntas? La respuesta es definitivamente sí".

Si es necesario traducir las direcciones de origen y destino de los paquetes, se requieren los servidores Source NAT y NAT. Esta configuración también se llama "NAT bidireccional". Tenga en cuenta que la NAT bidireccional no es una función independiente. En su lugar, es solo una combinación de Source NAT y NAT Server. Esta combinación se aplica al mismo flujo (por ejemplo, un paquete de un usuario de Internet a un servidor de intranet). Al recibir el paquete, el firewall traduce las direcciones de origen y destino. Si la fuente NAT y el servidor NAT están configurados en un servidor de seguridad para diferentes flujos, la configuración no se llama NAT bidireccional.

Para ayudarlo a comprender el NAT de origen, asumimos la red en la que los usuarios de la intranet acceden a Internet y verificamos la configuración del NAT de origen en esa red. En realidad, la fuente NAT se puede clasificar en NAT interzona y NAT intrazona según las direcciones de transmisión de paquetes en el firewall.

·         Interzona NAT

NAT se realiza en el paquete transmitido entre zonas de seguridad. Interzona NAT también se puede clasificar en los siguientes tipos según las direcciones de transmisión de paquetes:

NAT entrante

NAT se realiza en los paquetes transmitidos desde una zona de seguridad de bajo nivel a una zona de seguridad de alto nivel. En general, este tipo de NAT se aplica cuando los usuarios de Internet acceden a una intranet y, por lo tanto, rara vez se utiliza esta técnica.

NAT saliente

NAT se realiza en los paquetes transmitidos desde una zona de seguridad de alto nivel a una zona de seguridad de bajo nivel. Dicho NAT se aplica cuando los usuarios de la intranet acceden a Internet, que es un escenario común.

·         Intrazona NAT

NAT se realiza cuando los paquetes se transmiten dentro de una zona de seguridad. Normalmente, NAT intrazona funciona con el servidor NAT. Intrazona NAT rara vez se configura por separado.

Cuando intrazona o interzona NAT funciona con NAT Server, se implementa NAT bidireccional. Por supuesto, los requisitos previos de la descripción anterior son la configuración adecuada de los niveles de seguridad para las zonas de seguridad y la planificación adecuada de la red: la intranet pertenece a la zona Trust (con un nivel de seguridad alto); Los servidores de intranet pertenecen a la DMZ (con un nivel de seguridad medio); e Internet pertenece a la zona Untrust (con un nivel de seguridad bajo).

 

El NAT bidireccional no es especial en términos de tecnologías y principios de implementación, pero su escenario aplicable tiene características. ¿Cuándo se requiere NAT bidireccional? ¿Cuáles son los beneficios después de configurar el NAT bidireccional? ¿Está bien si no configuro NAT bidireccional? Estas preguntas deben ser consideradas para la planificación y despliegue de redes en vivo.

1.      NAT Inbound + NAT Server

La Imagen 1-1 muestra un escenario típico de NAT Server en el que un usuario de Internet accede a un servidor de intranet. La siguiente parte describe cómo configurar y aplicar NAT bidireccional en este escenario y las ventajas de la NAT bidireccional.

Imagen 1-1 Redes para NAT entrante + servidor NAT

082513tp599i5kx6dr3i65.png?image.png


El servidor NAT y la fuente NAT se configuran de la siguiente manera. La política de seguridad y las configuraciones de ruta de agujero negro son las mismas que las proporcionadas en las secciones anteriores y, por lo tanto, se omiten en esta parte. Veamos primero la configuración del servidor NAT.

[FW] nat server protocol tcp global 1.1.1.1 9980 dentro de 10.1.1.2 80

Creo que no tienes dudas sobre la configuración del servidor NAT. Una vez que se completa la configuración, se genera el siguiente mapa de servidor en el firewall:

[FW] display firewall server-map

server-map item(s)

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

 Nat Server, any -> 1.1.1.1:9980[10.1.1.2:80], Zone: ---

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

   VPN: public -> public

 

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

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

   VPN: public -> public

 

 

 

 

 

 

Entonces, echemos un vistazo a la configuración NAT de origen.

[FW] nat address-group 1 10.1.1.100 10.1.1.100

[FW] nat-policy interzone untrust dmz inbound

[FW-nat-policy-interzone-dmz-untrust-inbound] policy 1

[FW-nat-policy-interzone-dmz-untrust-inbound-1] policy destination 10.1.1.2 0   // Como el Servidor NAT se realiza antes de la Fuente NAT, la dirección de destino aquí es la dirección del Servidor NAT posterior, es decir, la dirección privada del servidor. [FW-nat-policy-interzone-dmz-untrust-inbound-1] action source-nat

[FW-nat-policy-interzone-dmz-untrust-inbound-1] address-group 1

[FW-nat-policy-interzone-dmz-untrust-inbound-1] quit

[FW-nat-policy-interzone-dmz-untrust-inbound] quit

 

La configuración de NAT de origen es diferente de la descrita en la sección anterior. La diferencia es que el grupo de direcciones NAT aquí tiene direcciones privadas, no direcciones públicas. Además, la dirección de la política de NAT es entrante, lo que indica que la NAT se realiza cuando los paquetes fluyen desde una zona de seguridad de bajo nivel a una zona de seguridad de alto nivel. Esta configuración de NAT es NAT Inbound.

Una vez que se completa la configuración, cuando el usuario de Internet accede al servidor de intranet, podemos ver la tabla de sesión en el firewall. El resultado del comando muestra que las direcciones de origen y destino del paquete se han traducido.

[FW] display firewall session table

Current Total Sessions : 1

  http  VPN:public --> public 1.1.1.2:2049[10.1.1.100:2048]-->1.1.1.1:9980[10.1.1.2:80]

 

Veamos el proceso de NAT como se indica en la Imagen 1-2. Una vez que el paquete del usuario de Internet al servidor de la intranet llega al servidor de seguridad, el Servidor NAT traduce la dirección de destino (dirección pública del servidor de la intranet) a una dirección privada, y NAT Inbound traduce la dirección de origen a una dirección privada en la misma red segmento como la dirección del servidor. De esta manera, las direcciones de origen y destino del paquete se traducen, implementando NAT bidireccional. Cuando el paquete de respuesta del servidor de intranet llega al servidor de seguridad, se vuelve a realizar una NAT bidireccional. Para ser específicos, las direcciones de origen y destino del paquete se convierten en direcciones públicas.

Imagen 1-2 Procedimientos de traducción de direcciones para NAT Inbound + NAT Server

 

082548nsj6nx06hgf2j6h6.png?image.png


Aquí puede tener una pregunta: el usuario de Internet puede seguir accediendo al servidor de intranet incluso si NAT Inbound no está configurado. ¿Por qué lo configuras? La respuesta está en cómo el servidor de la intranet procesa el paquete de respuesta.

Hemos establecido las direcciones en el grupo de direcciones NAT en el mismo segmento de red que la dirección del servidor de intranet. Cuando el servidor de la intranet responde a las solicitudes de acceso del usuario de Internet, encuentra que su dirección y la dirección de destino están en el mismo segmento de red. Entonces, el servidor no busca en la tabla de enrutamiento. En su lugar, envía un paquete de difusión ARP para consultar la dirección MAC correspondiente a la dirección de destino. En este caso, el servidor de seguridad envía la dirección MAC de la interfaz que se conecta al servidor de la intranet al servidor de la intranet y solicita al servidor de la intranet que responda. Luego, el servidor de intranet envía el paquete de respuesta al firewall, y el firewall procesa el paquete.

Como el servidor de intranet no busca en la tabla de enrutamiento, no es necesario establecer un gateway. Este es el beneficio de usar NAT Inbound. Alguien puede decir "es más fácil establecer un gateway en el servidor que configurar NAT Inbound en el firewall". Es cierto si solo hay un servidor en la red. Si hay docenas o incluso cientos de servidores en la red, encontrará lo conveniente que es la configuración de entrada de NAT. Ciertamente, la aplicación de NAT bidireccional en tal escenario tiene un requisito previo de que el servidor de intranet y el firewall deben estar en el mismo segmento de red. De lo contrario, el NAT bidireccional no se aplica.

Si agrego una zona Trust en esta red y los usuarios de la intranet en la zona Trust necesitan acceder al servidor de la intranet en la DMZ, ¿cómo puedo configurar un NAT bidireccional? La configuración del servidor NAT permanece sin cambios, mientras que la configuración de la fuente NAT cambia un poco. Como el nivel de seguridad de la zona Trust es más alto que el de la DMZ, se requiere NAT Outbound para los paquetes transmitidos desde la zona Trust a la DMZ. Es decir, la configuración NAT bidireccional cambia a NAT Server + NAT Outbound.

 

1.      Intrazone NAT + NAT Server


La combinación de intrazone NAT + NAT Server se aplica a redes pequeñas. La Imagen 1-3 muestra una red pequeña típica. El administrador guarda el problema y planifica el servidor y el host de la intranet en la misma zona de seguridad.

 

Imagen 1-3 Diagrama de red para intrazona NAT + NAT Server


082608u6mkgskex5filpxz.png?image.png


En esta red, si el host de la intranet quiere usar la dirección pública 1.1.1.1 para acceder al servidor de la intranet, el Servidor NAT debe configurarse en el firewall. Sin embargo, simplemente configurar NAT Server no es suficiente. Como se muestra en la Imagen 1-4, después de que un paquete del servidor de la intranet al servidor de la intranet llegue al servidor de seguridad, el servidor de seguridad traduce la dirección de destino del paquete de 1.1.1.1 a 10.1.1.2. Cuando el servidor de la intranet responde, encuentra que la dirección de destino se encuentra en el mismo segmento de red que su propia dirección, y el paquete de respuesta se envía directamente a través del conmutador al host de la intranet, sin pasar por el firewall.


Imagen 1-4 Diagrama para el reenvío de paquetes después de configurar el Servidor NAT


082619yyqaylcy2v3xvaxl.png?image.png


Para mejorar la seguridad de la intranet forzando los paquetes respondidos por el servidor de la intranet a pasar a través del firewall, debemos configurar la intranet NAT para traducir la dirección de origen del paquete enviado desde el host de la intranet al servidor de la intranet. La dirección de origen posterior al NAT puede ser una dirección pública o privada siempre que no se encuentre en el mismo segmento de red que la dirección del servidor de la intranet, lo que garantiza que los paquetes de respuesta del servidor de la intranet puedan reenviarse al firewall.

El servidor NAT y el NAT intrazone se configuran de la siguiente manera. La configuración de la ruta de agujero negro es la misma que se proporciona en las secciones anteriores y, por lo tanto, se omite en esta parte. Veamos primero la configuración del servidor NAT.

[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80

Una vez que se completa la configuración, se genera el siguiente mapa de servidor en el firewall:

[FW] display firewall server-map

server-map item(s)

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

 Nat Server, any -> 1.1.1.1:9980[10.1.1.2:80], Zone: ---

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

   VPN: public -> public

 

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

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

   VPN: public -> public

 

Entonces, veamos la configuración NAT intrazona. La configuración NAT intrazona es casi la misma que la configuración NAT interzona. La única diferencia es que la NAT se realiza dentro de una zona para NAT intrazona, mientras que entre las zonas para NAT interzona.

[FW] nat address-group 1 1.1.1.100 1.1.1.100   // La dirección puede ser pública o privada, pero no puede estar en el mismo segmento de red que el servidor de intranet.

[FW] nat-policy zone trust

[FW-nat-policy-zone-trust] policy 1

[FW-nat-policy-zone-trust-1] policy destination 10.1.1.2 0   // Como el servidor NAT se realiza antes de la intrazona NAT, la dirección de destino aquí es la dirección del servidor posterior a NAT, es decir, la dirección privada del servidor. [FW-nat-policy-zone-trust-1] action source-nat

[FW-nat-policy-zone-trust-1] address-group 1

[FW-nat-policy-zone-trust-1] quit

[FW-nat-policy-zone-trust] quit

 

 

La configuración de la política de seguridad no se proporciona porque los firewalls (excepto la serie USG6000) no controlan los paquetes transmitidos dentro de una zona de seguridad de forma predeterminada. Por supuesto, los administradores pueden configurar políticas de seguridad intrazona adecuadas según sea necesario.

Una vez completada la configuración, cuando el host de la intranet en 1.1.1.1 acceda al servidor de la intranet, podemos ver la tabla de sesiones en el firewall. El resultado del comando muestra que las direcciones de origen y destino del paquete se han traducido.

 

 

[FW] display firewall session table

Current Total Sessions : 1

  http  VPN:public --> public 10.1.1.3:2050[1.1.1.100:2048]-->1.1.1.1:9980[10.1.1.2:80]

 

La Imagen 1-5 muestra el proceso de reenvío de paquetes.


Imagen 1-5 Diagrama para el reenvío de paquetes después de que se configuren los servidores NAT y NAT intrazona


082637gqk4x2s3qv4gw1bh.png?image.png


082641nsqvwfsfw6lfhx0f.png?image.png


Sobre la base de esta red, si conectamos el servidor y el servidor de la intranet a través de interfaces en diferentes segmentos de red, solo se requiere el Servidor NAT, y todos los paquetes transmitidos entre el servidor y el servidor de la intranet se reenvían a través del servidor de seguridad.


En la descripción anterior, ¿cree que el principio y la configuración de la NAT bidireccional no es complicado? Es importante aclarar la dirección de NAT y la función de las direcciones posteriores a NAT, no el atributo de las direcciones posteriores a NAT (públicas o privadas). Además, no se requiere NAT bidireccional. A veces, solo la fuente NAT o el servidor NAT pueden lograr el mismo efecto. El uso flexible de la NAT bidireccional simplifica la configuración de la red y facilita la administración de la red, logrando que uno más uno sea mayor que dos.


  • x
  • convención:

Responder

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

Aviso 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!

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

Aterrizaje