¿Por qué es una mala idea usar varias capas NAT o es?

La red informática de una organización tiene un NAT con un rango de direcciones IP 192.168 / 16. Hay un departamento con un servidor que tiene una dirección IP 192.168.xy y este servidor maneja hosts de este departamento con otro NAT con el rango de direcciones IP 172.16 / 16.

Por lo tanto, hay 2 capas de NAT. ¿Por qué no tienen subredes en su lugar? Esto permitiría un enrutamiento fácil.

Siento que varias capas de NAT pueden causar pérdidas de rendimiento. ¿Podría ayudarme a comparar las dos estrategias de diseño?

Actualizar:

@ Jon Algo más de información

En una discusión con un amigo, nos dimos cuenta de que las subredes causarían el siguiente problema. Las solicitudes ARP de una computadora inundarían toda la red de la organización. Si el enrutador no reenvía estas solicitudes, las PC de un departamento no podrán conectarse a las PC de otros departamentos, lo que de todos modos no se puede hacer si están detrás de NAT diferentes. Con un sniffer de paquetes vimos que hay una gran cantidad de solicitudes ARP ya que la mayoría de las computadoras en el departamento tienen habilitado el uso compartido de archivos en Windows.

¿Cómo resolver este problema?

Además, si dos computadoras están detrás de NAT diferentes, entonces no hay forma de que se conecten entre sí.

El único problema real al hacer NATing de varias capas es que confunde la topología de su red. Si usa varias capas de NAT, descarta el enrutamiento simétrico entre todos los hosts de la organización y también se encuentra con el potencial de superponer espacios de direcciones privadas dentro de su red. Imagínese si usara un rango de direcciones en su capa NAT n + 1 que se estaba usando en la capa n NAT. Esas redes nunca podrían enrutarse entre sí, pero los hosts en la capa n + 1 podrían tener la misma dirección que la capa n, lo que confunde la identidad del servidor.

Si estuviera diseñando la topología de una red grande, usaría solo 10. * o 172.16-24. * Direcciones para hosts en cualquiera de nuestras subredes. Entonces, si algún departamento o individuo quisiera duplicar NAT, podrían (utilizando la red 192.168. *) Con el entendimiento de que son responsables de la red detrás de su host NAT. También estaría más inclinado a crear más subredes que dejar que cualquiera de esas redes con doble NAT se vuelva demasiado grande.

Los problemas con NAT de varios niveles son esencialmente los mismos que para NAT de una sola capa pero agravados. Como:

1. Latencia debido al trabajo adicional que se realiza en la vida útil de los paquetes (aunque es poco probable que esto sea significativo en la mayoría de los casos)

2. Saber de dónde viene algo. Si está tratando de rastrear de dónde provienen ciertas solicitudes (tal vez su firewall saliente ha registrado lo que parece una máquina comprometida que intenta arrojar correo no deseado o buscar otros objetivos de infección), NAT hace que tales diagnósticos sean mucho más difíciles.

3. El reenvío del puerto de conexión entrante, si necesita conexiones entrantes, es más fácil de configurar y mantener.

4. Número limitado de puertos. NAT funciona traduciendo direcciones de origen a sí mismo en diferentes puertos, por ejemplo:

   • la máquina 1 se comunica con un servidor web externo utilizando el puerto 1024 ya que su fuente se traduce a la dirección de la caja NAT en, digamos, el puerto 10000.
   • la misma máquina realiza dos solicitudes a ese u otro servidor web simultáneamente (no inusual) utilizando el puerto de origen 1025 (dos conexiones simultáneas deben tener puertos de origen diferentes). El cuadro NAT traduce esto a "yo en el puerto de origen 10001"
   • otra máquina habla hace tres conexiones a servidores externos. Bien, el cuadro NAT los traduce a "yo en los puertos 10002, 10003 y 10004"
   • A medida que los paquetes regresan a las máquinas externas, la caja NAT sabe que las cosas destinadas a sí mismas en el puerto 10000 realmente deben ir a la máquina 1 en el puerto 1024, y así sucesivamente para las otras conexiones activas.

   Todo está bien hasta que tenga muchas conexiones salientes, es decir, una red grande o una red más pequeña con máquinas que hacen muchas conexiones (las aplicaciones P2P como las que implementan el protocolo bittorrent pueden crear muchas conexiones concurrentes). Solo hay 65536 puertos en el protocolo IP, menos los 1024 que están reservados. Si bien 60,000 puede parecer mucho, se puede consumir rápidamente, entonces el cuadro NAT necesita decidir qué asignaciones antiguas se pueden eliminar, lo que generalmente no es tan simple como "descartar la más antigua". Esto puede provocar errores extraños (caídas de conexiones aleatorias por razones difíciles de diagnosticar) o la máquina simplemente no puede hacer nuevas conexiones por un tiempo.

5. cargar en la (s) caja (s) NAT. Si está utilizando pequeñas cajas de baja potencia (por ejemplo, enrutadores compatibles con NAT, en lugar de una PC completa con una CPU gruesa) para hacer su NAT el trabajo de traducción adicional (en comparación con simplemente reenviar paquetes según una tabla de enrutamiento básica) ) podría retrasar las transferencias a través de ellos. Para el acceso a Internet, es probable que esto no sea un problema (su 'conexión de red será el cuello de botella), pero a medida que se conecta a NAT entre segmentos de red locales, podría ser bastante notable.

La pérdida / velocidad de rendimiento se debe realmente a la calidad del enrutador que utiliza.

En cuanto a la buena / mala idea, estoy en contra cuando es posible simplemente usar el enrutamiento, sin embargo, realmente depende del entorno y de lo que está tratando de lograr.

Si las máquinas solo necesitan ejecutar algunas cosas que se comparten a través de puertos estándar, puede acceder al enrutador / dispositivo de entrega nat y establecer una regla para permitir lo que desea (1). Sin embargo, si va a realizar muchas tareas de dispositivo a dispositivo, será mucho más fácil tener una ruta adecuada con cada máquina que tenga su propia IP única (2).

(1) Por ejemplo, de uno a muchos: una máquina tiene un servidor web y desea compartirlo con otros: establecería una regla en el enrutador para el puerto 80 de la máquina, y luego cualquier máquina de la red externa (o interna si nat-loopback está habilitado) simplemente puede ir a http: //router.ip y acceder.

(2) Sin embargo, si cada máquina va a tener un servidor web encendido, o va a utilizar muchos servicios, tendrá una pesadilla al configurar todas las reglas (pero no es imposible).

En cuanto a su escenario: si un departamento está utilizando 192.168.xx y el otro 192.168.yx, revisaría los dispositivos y, si no hay superposiciones, simplemente podría ser posible cambiar la subred de / 24 a / 16 (o al revés), luego reemplace los enrutadores con conmutadores / o similares y no pierda servicios.

Es realmente difícil ayudar sin saber más acerca de su red, no hay nada "incorrecto" con el doble NAT, siempre y cuando esté configurado correctamente. Sin embargo, a menos que realmente lo necesite, o haya una muy buena razón para ello, consideraría migrar si puede (opinión personal)

@iamrohitbanga - En respuesta a sus preguntas (demasiado para comentarios).

Comparar es difícil: el enrutamiento funciona bien para redes privadas donde cada máquina tiene la capacidad de acceder a cada máquina. Nat funciona bien, pero se usa principalmente para redes que no necesitan enrutamiento, ya que generalmente tiene que configurar manualmente las reglas / rutas entrantes.

Por ejemplo, si tiene una conexión a Internet y deshabilita NAT, configure manualmente las rutas o el modo puenteado (su máquina estará directamente en Internet), todos los puertos accesibles y cualquier máquina puede hacer lo que quiera.

Si, por otro lado, tiene un enrutador con NAT, tomará la IP externa y proporcionará "¿Nat-ed?" (no estoy seguro de la terminología ...) Internet: todas las máquinas internas tienen una IP no accesible desde Internet, pero puede configurar reglas manuales, por ejemplo, el puerto 80 a una máquina ... Funciona muy bien para las conexiones salientes (firewall si las reglas lo permiten), pero puede ser una pesadilla configurar reglas entrantes si aloja muchos servicios ... y si hace algo que requiera puertos dinámicos (ftp, Windows AD, etc.) puede ser una pesadilla.

Espero que esto ayude, si quieres saber algo más, no dudes en preguntar.

El principal problema con NAT (en general y con múltiples capas específicamente) es que puede ser extremadamente difícil de solucionar.

El mayor problema con NAT es cuando hay un software de red desactualizado que hace la traducción, lo que perjudica a muchas aplicaciones (FTP, VoIP, etc.). Los firewalls / gateways modernos tienen traducciones (reparaciones en términos de Cisco) que lo hacen mucho más fácil.

No entiendo por qué su empresa usa NAT entre las subredes privadas. ¿Por qué no solo enrutarlo?

Simplemente actualice su red y clientes a IPV6, luego no tendrá que volver a usar NAT.

Para responder la nueva segunda parte de su pregunta ...

Los enrutadores rompen los dominios de difusión: los enrutadores no reenvían paquetes arp, permanecen dentro de una subred *. Su intercambio de archivos de Windows (¿en serio?) El tráfico de difusión de Netbios no abandonará la subred.

Con subredes:

Si necesita acceder a un recurso compartido de Windows desde fuera de una subred, puede acceder a él utilizando directamente su dirección IP o si tiene un servidor DNS o WINS configurado por nombre de host.

Con NAT:

Si su NAT es del tipo PAT y, por lo tanto, no es un mapeo uno a uno, necesitará configurar el reenvío de puertos para que esto funcione; esto sería malo.

Como se ha discutido ad naseum, NAT es en general algo malo, ya que rompe la funcionalidad de la red, solo usamos porque tenemos que hacerlo. Roll en IPv6.

* Por supuesto, existen reenviadores / retransmisores / ayudantes de difusión