[Dr.WoW] [No.22] Función de las rutas de agujero negro en escenarios de NAT

119 0 0 0

En las secciones anteriores, he mencionado varias veces que una ruta de agujero negro debe configurarse para NAT para evitar los bucles de enrutamiento. ¿Por qué deberíamos hacer ésto? Te diré la causa en esta sección.

1 ruta de agujero negro en un escenario NAT de origen


Primero, establezcamos una red NAT de origen típica, como se muestra en la Figura 1-1.


Figura 1-1 Diagrama de red 1 para Source NAT


083015mykr7q7blhhkz7rf.png?image.png


La configuración de NAT en el firewall es la siguiente:

Configurar un grupo de direcciones NAT.

[FW] nat address-group 1 202.1.1.10 202.1.1.10

Configure a NAT policy.

[FW] nat-policy interzone trust untrust outbound

[FW-nat-policy-interzone-trust-untrust-outbound] policy 1

[FW-nat-policy-interzone-trust-untrust-outbound-1] policy source 192.168.0.0 0.0.0.255

[FW-nat-policy-interzone-trust-untrust-outbound-1] action source-nat

[FW-nat-policy-interzone-trust-untrust-outbound-1] address-group 1

[FW-nat-policy-interzone-trust-untrust-outbound-1] quit

[FW-nat-policy-interzone-trust-untrust-outbound] quit

Configure a security policy.

[FW] policy interzone trust untrust outbound

[FW-policy-interzone-trust-untrust-outbound] policy 1

[FW-policy-interzone-trust-untrust-outbound-1] policy source 192.168.0.0 0.0.0.255

[FW-policy-interzone-trust-untrust-outbound-1] action permit

[FW-policy-interzone-trust-untrust-outbound-1] quit

[FW-policy-interzone-trust-untrust-outbound] quit

In addition, configure a default route with the next hop pointing to the address of the router interface.

[FW] ip route-static 0.0.0.0 0 202.1.1.2

The address in the NAT address pool is 202.1.1.10. The address of the interface connecting the firewall to the router is 202.1.1.1 with a 30-bit mask. The two addresses are not in the same network segment.

In normal conditions, when the intranet PC accesses the Web server on the Internet, a session table is generated, and the source address is translated.

[FW] display firewall session table

Current Total Sessions : 1

  http  VPN:public --> public 192.168.0.2:2050[202.1.1.10:2049]-->210.1.1.2:80

If a PC on the Internet proactively accesses the NAT address pool on the firewall, as shown in Figure 1-2, what will happen?

 

Figura 1-2 Diagrama de red 2 para Source NAT

083036rry09p93t752rnmy.png?image.png


Ejecute el comando ping 202.1.1.10 en la PC con Internet. El ping falla.

PC> ping 202.1.1.10

Ping 202.1.1.10: 32 data bytes, Press Ctrl_C to break

Request timeout!

Request timeout!

Request timeout!

Request timeout!

Request timeout!

 

--- 202.1.1.10 ping statistics ---

  5 packet(s) transmitted

  0 packet(s) received

  100.00% packet loss

 

Obviamente, este es el resultado esperado. El grupo de direcciones NAT se usa solo para la traducción de direcciones privadas. En otras palabras, el firewall traduce la dirección en el paquete de solicitud solo cuando la PC de la intranet inicia una solicitud de acceso. El grupo de direcciones NAT no proporciona otros servicios. Por lo tanto, cuando la PC de Internet inicia una solicitud de acceso al grupo de direcciones NAT, el paquete de solicitud no puede atravesar el firewall para llegar a la PC de la intranet. En consecuencia, el ping falla.

La situación actual es mucho más complicada. Si habilitamos la captura de paquetes en GE1 / 0/2 en el firewall y ejecutamos el comando ping 202.1.1.10 -c 1 en la PC con Internet para enviar solo un paquete, la salida del comando es la siguiente:

PC> ping 202.1.1.10 -c 1

Ping 202.1.1.10: 32 data bytes, Press Ctrl_C to break

Request timeout!

 

--- 202.1.1.10 ping statistics ---

  1 packet(s) transmitted

  0 packet(s) received

  100.00% packet loss


Luego, verifique la información sobre los paquetes capturados en GE1 / 0/2.


083057x0bgp4w9naq69gbr.png?image.png


¡Guauu! El resultado me sorprende. ¡Tantos paquetes ICMP! Conozco estos paquetes y encuentro que los valores TTL de los paquetes disminuyen en 1 y finalmente se convierten en 1. Sabemos que el TTL significa Tiempo de vida. El valor TTL de un paquete se reduce a 1 cada vez que un dispositivo reenvía el paquete. Cuando el valor TTL se convierte en 0, el paquete se descartará. Esto significa que el paquete de la PC de Internet al grupo de direcciones NAT se reenvía repetidamente entre el firewall y el enrutador hasta que el valor TTL del paquete se convierte en 0 y el paquete se descarta.

 

Vamos a pasar por el proceso:

 

1. El enrutador recibe un paquete desde la PC de Internet al grupo de direcciones NAT y encuentra que la dirección de destino no se encuentra en el segmento de red conectado directamente. Luego, el enrutador busca en su tabla de enrutamiento y reenvía el paquete al firewall.

 

2. Después de recibir el paquete, el firewall lo reenvía en función de la ruta predeterminada porque el paquete no es el paquete devuelto de la intranet a Internet y no coincide con la tabla de la sesión. Además, la dirección de destino no se encuentra en el segmento de red conectado directamente (el firewall no sabe que la dirección de destino es la dirección del grupo de direcciones NAT). A medida que el paquete entra y sale del firewall a través de la misma interfaz, fluye dentro de una zona de seguridad y, por lo tanto, el paquete no está controlado por políticas de seguridad de manera predeterminada. En consecuencia, el firewall reenvía el paquete a través de GE1 / 0/2 al enrutador.

 

3. Después de recibir el paquete, el enrutador busca de nuevo la tabla de enrutamiento y luego envía el paquete nuevamente al firewall. El proceso se repite. Este mal paquete es como una pelota pateada entre los dispositivos y finalmente descartada, dejando a la red con pena.

 

Bueno, ¿qué pasará si se configura una ruta de agujero negro? Primero, configuremos una ruta de agujero negro con la dirección de destino como la dirección del grupo de direcciones NAT. Para evitar que la ruta blackhole afecte a los servicios, establezca su máscara en 32 bits para que coincida exactamente con 202.1.1.10.

 

[FW] ip route-static 202.1.1.10 32 NULL 0

 

Luego, habilite la captura de paquetes en GE1 / 0/2 en el firewall y ejecute el comando ping 202.1.1.10 -c 1 en la PC con Internet. Esta vez también enviamos un solo paquete. Ver información sobre el paquete capturado.


083112a5g2lfe5lxqjeqdj.png?image.png


Puede ver que solo se captura un paquete ICMP, lo que indica que el paquete coincide con la ruta de agujero negro en el servidor de seguridad y el servidor de seguridad descarta directamente el paquete. La ruta de agujero negro evita los bucles de enrutamiento entre el firewall y el enrutador. El firewall envía dichos paquetes al agujero negro, en lugar de reenviarlos repetidamente. Además, la ruta de agujero negro no afecta a los servicios. La intranet PC todavía puede acceder al servidor web en Intern


Puede decir que el paquete se descartará finalmente incluso si no configuro la ruta de agujero negro. Así que la ruta de agujero negro no es necesaria. En el ejemplo anterior, usamos solo un paquete de ping para demostrar el proceso. Trate de imaginar, si un usuario malintencionado en Internet manipula miles de PC para iniciar el acceso al grupo de direcciones NAT, se reenviarán numerosos paquetes entre el firewall y el enrutador, consumiendo los recursos de ancho de banda del enlace y agotando los recursos del sistema en los dispositivos para procesarlos Tales paquetes, que probablemente afectan a los servicios normales.

Por lo tanto, cuando el grupo de direcciones NAT y la dirección de la interfaz pública están en diferentes segmentos de red, debe configurar una ruta de agujero negro para evitar bucles.


¿El problema persiste si el grupo de direcciones NAT y la dirección de interfaz pública están en el mismo segmento de red? Vamos a verificar el proceso.

Primero, cambie la máscara a 24 bits para la interfaz que conecta el firewall al enrutador. De esta manera, el grupo de direcciones NAT y la dirección de la interfaz están en el mismo segmento de red. Luego, elimine la configuración de la ruta de agujero negro, habilite la captura de paquetes en GE / 1/0/2, ejecute el comando ping 202.1.1.10 -c 1 en la PC con Internet y vea la información sobre los paquetes capturados.


083142lkwad2w43kw6dm25.png?image.png


El resultado muestra que solo se capturan tres paquetes ARP y un paquete ICMP. Los paquetes de la PC de Internet al grupo de direcciones NAT no se reenvían entre el firewall y el enrutador. Veamos el proceso:


1. Después de recibir un paquete que solicita acceder al grupo de direcciones NAT desde la PC con Internet, el enrutador encuentra que la dirección de destino del paquete pertenece a un segmento de red conectado directamente y envía una solicitud ARP. El firewall responde a la solicitud ARP. Los dos primeros paquetes capturados completan este proceso de interacción. Luego, el enrutador encapsula la dirección MAC notificada por el firewall en un paquete y envía el paquete al firewall.


2. Después de recibir el paquete, el firewall encuentra que la dirección de destino pertenece al mismo segmento de red que su GE1 / 0/2 y envía una solicitud ARP (el tercer paquete ARP capturado) para buscar la dirección MAC correspondiente a esta dirección IP (el servidor de seguridad aún no sabe que la dirección de destino es la dirección del grupo de direcciones NAT). El dispositivo no responde porque esta dirección solo está configurada en el firewall. Finalmente, el firewall descarta el paquete.


Por lo tanto, no se produce ningún bucle de enrutamiento en esta situación. Pero si los usuarios malintencionados en Internet inician una gran cantidad de solicitudes de acceso, el firewall debe enviar la cantidad correspondiente de solicitudes ARP, agotando los recursos del sistema. Por lo tanto, se recomienda una ruta de agujero negro incluso si el grupo de direcciones NAT y la dirección de interfaz pública están en el mismo segmento de red, lo que ahorra recursos del sistema en el firewall.

La siguiente captura de pantalla muestra información sobre el paquete capturado después de configurar una ruta de agujero negro. Puede ver que el firewall no envía solicitudes ARP.


083210dlqmaa25aee2mula.png?image.png


Existe un caso extremo en el que la dirección de la interfaz pública está configurada como la dirección posterior al NAT (en el modo Easy-IP) o el grupo de direcciones NAT. ¿Sigo necesitando configurar una ruta de agujero negro?


Veamos el proceso. El firewall recibe un paquete de la PC de Internet y encuentra que el firewall en sí mismo es el destino del paquete. La forma en que el firewall procesa el paquete está determinada por la política de seguridad que se aplica a la interzona entre la zona de la interfaz pública y la zona local. Si la acción para la condición coincidente es permitida, el firewall procesa el paquete; si la acción es denegada, el firewall descarta el paquete. En este proceso, no se produce ningún bucle de enrutamiento y no se requiere una ruta de agujero negro.


2 Ruta de agujero negro en un escenario de servidor NAT


Ahora, puedes preguntarme "¿Tiene NAT Server el mismo problema?" Sí, el servidor NAT también puede encontrar bucles de enrutamiento, pero los requisitos previos son especiales y están determinados por la configuración del servidor NAT. En la red típica del Servidor NAT que se muestra en la Figura 1-3, la dirección Global del Servidor NAT y la dirección de la interfaz pública están en diferentes segmentos de red. La siguiente descripción se basa en el supuesto de que las direcciones de la interfaz, las zonas de seguridad, las políticas de seguridad y las rutas se han configurado.


Figura 1-3 Red de servidores NAT


083252ywt4vqp1mtwqqvw0.png?image.png


Si configuramos un servidor NAT impreciso en el firewall para anunciar el servidor web de la intranet a Internet de la siguiente manera:

[FW] nat server global 202.1.1.20 dentro de 192.168.0.20


El firewall traduce las direcciones de destino de todos los paquetes de la PC con Internet a 202.1.1.20 en 192.168.0.20 y luego envía los paquetes al servidor web de la intranet. No se produce ningún bucle.


Si configuramos el Servidor NAT refinado para anunciar solo el número de puerto utilizado por el servidor web de intranet a Internet de la siguiente manera:


[FW] protocolo de servidor nat tcp 202.1.1.20 9980 dentro de 192.168.0.20 80

Pero la PC con Internet usa el comando ping para acceder a 202.1.1.20, en lugar de acceder al puerto 9980 para 202.1.1.20 como esperábamos, el paquete no coincide con el mapa del servidor o la tabla de sesión en el firewall. Finalmente, el firewall busca la tabla de enrutamiento y reenvía el paquete a través de GE1 / 0/2. Después de recibir el paquete, el enrutador lo envía de vuelta al firewall, causando un bucle de enrutamiento.


083323i414450z803ls839.png?image.png


Por lo tanto, cuando el Servidor NAT con el protocolo y el número de puerto especificados se configura en el firewall, y la Dirección global del Servidor NAT y la dirección de la interfaz pública están en diferentes segmentos de red, debe configurar una ruta de agujero negro para evitar los bucles.

Si la dirección Global para el Servidor NAT y la dirección de la interfaz pública están en el mismo segmento de red, después de que el cortafuegos recibe un paquete de ping, envía una solicitud ARP y el siguiente proceso es el mismo que el descrito anteriormente. Del mismo modo, se recomienda una ruta de agujero negro cuando se configuran el protocolo y el número de puerto especificados para el Servidor NAT y la dirección Global para el Servidor NAT y la dirección de la interfaz pública están en el mismo segmento de red, ahorrando recursos del sistema en el firewall.


Además, podemos configurar la dirección de la interfaz pública como la dirección Global al configurar el Servidor NAT. En este caso, después de recibir un paquete de la PC con Internet, si el paquete coincide con el mapa del servidor, el firewall traduce la dirección de destino del paquete y reenvía el paquete a la intranet; Si el paquete no coincide con el mapa del servidor, el firewall se considera a sí mismo como el destino del paquete. La forma en que el firewall procesa el paquete está determinada por la zona de seguridad que se aplica a la interzona entre la zona de la interfaz pública y la zona Local. No se produce ningún bucle de enrutamiento y no se requiere una ruta de agujero negro.

 

3 Resumen


Ahora, creo que has entendido por qué necesitamos configurar una ruta de agujero negro. ¿Sientes que tu "fuerza interna" ha mejorado? Vamos a resumir.

Para la fuente NAT:

Si el grupo de direcciones NAT y la dirección de la interfaz pública están en diferentes segmentos de red, se requiere una ruta de agujero negro.

Si el grupo de direcciones NAT y la dirección de la interfaz pública están en el mismo segmento de red, se requiere una ruta de agujero negro.

Para el servidor NAT con el protocolo y el número de puerto especificados:

Si la dirección global y la dirección de la interfaz pública están en diferentes segmentos de red, se requiere una ruta de agujero negro.

Si la dirección global y la dirección de la interfaz pública están en el mismo segmento de red, se recomienda una ruta de agujero negro.

Además de las ventajas descritas anteriormente, una ruta de agujero negro tiene otra función: anunciar la ruta de agujero negro en el firewall (ruta OSPF) al enrutador.


Cuando el grupo de direcciones NAT (o dirección global) y la dirección de la interfaz que conecta el firewall con el enrutador están en diferentes segmentos de red, se debe configurar una ruta estática en el enrutador al grupo de direcciones NAT o dirección global, de modo que el enrutador puede reenviar los paquetes destinados al grupo de direcciones NAT o la dirección Global al firewall.


Si el firewall y el enrutador ejecutan OSPF, pueden aprender automáticamente las rutas de OSPF, reduciendo las cargas de trabajo de configuración manual. Sin embargo, a diferencia de las direcciones de interfaz, el grupo de direcciones NAT y la dirección Global no se pueden anunciar utilizando el comando de red como rutas OSPF. Bueno, ¿cómo puede el enrutador aprender tales rutas?


La ruta de agujero negro ayuda a resolver el problema. Podemos importar la ruta de agujero negro como una ruta estática a la tabla de enrutamiento OSPF en el firewall y anunciar esta ruta OSPF al enrutador. De esta manera, el enrutador reenvía los paquetes destinados al grupo de direcciones NAT o la dirección Global al firewall (NO al agujero negro).


La red del servidor NAT se utiliza como ejemplo. La dirección global y la dirección de la interfaz pública están en diferentes segmentos de red. Tanto el firewall como el enrutador ejecutan OSPF. Importe la siguiente ruta estática a la tabla de enrutamiento OSPF en el firewall:


083353n5ptfyyf3bz3oowu.png?image.png

  • 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