¿Por qué más organizaciones no usan NAT de adentro hacia adentro o soluciones similares para permitir horquillas NAT?

NAT de adentro hacia adentro, también conocido como NAT loopback, resuelve los problemas de NAT cuando se accede a un servidor web en la interfaz externa de un dispositivo ASA o similar desde computadoras en la interfaz interna. Esto evita que los administradores de DNS tengan que mantener una zona de DNS interna duplicada que tenga las direcciones RFC1918 correspondientes para sus servidores que están NATizadas en direcciones públicas. No soy un ingeniero de redes, por lo que podría estar perdiendo algo, pero parece una tarea fácil de configurar e implementar. El enrutamiento asimétrico puede ser un problema, pero se mitiga fácilmente.

En mi experiencia, los administradores / ingenieros de red prefieren que la gente de sistemas simplemente ejecute split-dns en lugar de configurar sus firewalls para manejar correctamente las horquillas NAT. ¿Por qué es esto?

Hay algunas razones por las que no lo haría:

• ¿Por qué ejercer presión adicional sobre los enrutadores DMZ y el firewall si no es necesario? La mayoría de nuestros servicios internos no se encuentran en la DMZ, sino en el área corporativa general, con servicios de representación en la DMZ para acceso remoto ocasional. Hacer nat de adentro hacia adentro agrega más carga a la DMZ, lo que en nuestro caso sería significativo.
• Si no hace DNAT + SNAT, obtendrá un enrutamiento asimétrico, que es muy difícil de corregir. Entonces SNAT y pierde la información de IP de origen. Sin embargo, es muy útil vincular las IP de origen con las personas para solucionar problemas. O, ocasionalmente, con fines de tiro en caso de estupidez. "Hey, esta IP está haciendo algo raro en el servicio no autenticado X" "Oh, echemos un vistazo en los registros del servidor de imap quién es".

Obviamente, no puede haber una respuesta definitiva para esto, pero podría pensar en una serie de razones:

1. Elegancia: NAT no es muy elegante para empezar, pero es una necesidad con el espacio de direcciones restringido de IPv4. Si puedo evitar NAT, lo haré. Con IPv6, el problema desaparece de todos modos.
2. Complejidad: especialmente en un caso en el que no tiene un solo enrutador "núcleo" que crea todos sus límites de seguridad, las configuraciones de filtro pueden volverse bastante complicadas. O eso, o tendría que difundir y mantener las reglas NAT en casi todos los dispositivos de enrutador.
3. Referencia: siempre que los administradores de firewall sean personas diferentes al resto del equipo de administración del servidor, puede ser difícil llegar a ellos. Con el fin de garantizar que los cambios no se retrasen por la acumulación (o las vacaciones) del administrador del firewall, se elige la opción de mantener la responsabilidad en el mismo equipo
4. Portabilidad y práctica común: el uso de vistas DNS es "justo lo que todos saben que se hace" para resolver este problema. No todos los enrutadores de límite admitirían NAT de bucle invertido de una manera directa, es probable que menos personas sepan cómo configurarlo correctamente en su entorno específico. Al solucionar problemas de red, la tripulación debería ser consciente de la configuración NAT de horquilla y todas sus implicaciones, incluso cuando persiguen un problema aparentemente no relacionado

Descargo de responsabilidad: esta es una respuesta de cebo de llama.

Una razón común por la que creo que se evitan soluciones como esta es un miedo / odio irracional hacia NAT por parte de los ingenieros de redes . Si desea ver algunos ejemplos de discusión sobre esto, consulte estos:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (el blog de Tom parece seguir atrayendo una discusión ferviente sobre NAT / IPv6)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (mi blog)

Por lo que puedo decir, gran parte de este miedo proviene de las malas implementaciones de NAT de Cisco (por lo que, en ese sentido, puede no ser irracional), pero en mi opinión, el ingeniero de red "clásico" está tan bien educado en el tema "NAT es mala "cosmovisión", que él o ella no puede ver ejemplos obvios como este donde tiene mucho sentido y en realidad simplifica la solución.

Ahí tienes: ¡vota a tu gusto! :-)

Mi suposicion es:

1. Split DNS se entiende más fácilmente.
2. NAT Hairpin utiliza recursos en el enrutador mientras que split-dns no.
3. Los enrutadores pueden tener limitaciones de ancho de banda que no puede obtener a través de una configuración de división de DNS.
4. Split-dns siempre tendrá un mejor rendimiento ya que evita los pasos de enrutamiento / NAT.

En el lado positivo de la horquilla NAT,

• Una vez que está configurado, simplemente funciona.
• No hay problemas con los cachés de DNS para portátiles movidos entre la red de trabajo y la Internet pública.
• El DNS para un servidor solo se administra en un lugar.

Para una red pequeña con bajos requisitos de tráfico a un servidor interno, iría con la horquilla NAT. Para una red más grande con muchas conexiones al servidor y donde el ancho de banda y la latencia son importantes, elija split-dns.

Desde mi perspectiva, esto cambió un poco entre la transición de Cisco Pix a ASA. Perdió el aliascomando. Y, en general, acceder a la dirección externa desde la interfaz interna en un firewall de Cisco requiere algún tipo de truco. Consulte: ¿Cómo llego a mi servidor interno en la IP externa?

Sin embargo, no siempre necesitamos mantener una zona DNS interna duplicada. Cisco ASA puede redirigir las consultas DNS para direcciones externas a direcciones internas si está configurado en la instrucción NAT. Pero prefiero mantener una zona interna para la zona DNS pública para tener esa granularidad y poder administrar esto en un lugar en lugar de pasar al firewall.

Por lo general, solo hay unos pocos servidores que pueden requerir esto dentro de un entorno (correo, web, algunos servicios públicos), por lo que no ha sido un problema tremendo.

Se me ocurren algunas razones:

1. Muchas organizaciones ya han dividido DNS como resultado de no querer publicar toda su información interna de DNS en el mundo, por lo que no es un esfuerzo adicional manejar los pocos servidores que también están expuestos a través de una IP pública.
2. A medida que una organización y su red se hacen más grandes, a menudo separan los sistemas que prestan servicio a las personas internas de los servidores que prestan servicios externos, por lo que el enrutamiento a los externos para uso interno puede ser una ruta de red mucho más larga.
3. Cuantas menos modificaciones hagan los dispositivos intermediarios a los paquetes, mejor será cuando se trate de latencia, tiempo de respuesta, carga del dispositivo y resolución de problemas.
4. (muy pequeño, lo admito) Hay protocolos que NAT aún romperá si el dispositivo NATing no va más allá de los encabezados del paquete y modifica los datos con las nuevas direcciones IP. Incluso si se trata solo de un caso de memoria institucional, sigue siendo una razón válida para que las personas lo eviten, especialmente si se trata de un protocolo del que no están 100% seguros.

Si fuera a usar NAT loopback, me preocuparía un poco cómo el dispositivo NAT manejará las direcciones de origen falsificadas. Si no comprueba en qué interfaz entró el paquete, podría falsificar direcciones internas de la WAN y enviar paquetes al servidor con direcciones internas. No pude obtener respuestas, pero podría comprometer el servidor usando una dirección interna.

Configuraría el loopback NAT, me conectaría al conmutador DMZ y enviaría paquetes con direcciones de origen internas falsificadas. Verifique el registro del servidor para ver si se recibieron. Luego iría a la cafetería y vería si mi ISP está bloqueando direcciones falsificadas. Si descubriera que mi enrutador NAT no estaba verificando la interfaz de origen, probablemente no usaría el loopback NAT incluso si mi ISP lo está haciendo.