Método de reestructuración de red para red de doble NAT

Debido a una serie de malas decisiones de diseño de red (en su mayoría) tomadas hace muchos años para ahorrar unos cuantos dólares aquí y allá, tengo una red que está decididamente con una arquitectura subóptima. Estoy buscando sugerencias para mejorar esta situación poco placentera.

Somos una organización sin fines de lucro con un departamento de TI basado en Linux y un presupuesto limitado. (Nota: ninguno de los equipos de Windows que tenemos ejecuta algo que habla con Internet ni tenemos administradores de Windows en el personal).

Puntos clave:

• Tenemos una oficina principal y unos 12 sitios remotos que esencialmente duplican NAT sus subredes con conmutadores físicamente segregados. (Sin VLAN y capacidad limitada para hacerlo con los conmutadores actuales)
• Estas ubicaciones tienen una subred "DMZ" que tiene NAT en una subred 10.0.0 / 24 asignada de forma idéntica en cada sitio. Estas subredes no pueden comunicarse con las DMZ en ninguna otra ubicación porque no las direccionamos a ningún lado, excepto entre el servidor y el "firewall" adyacente.
• Algunas de estas ubicaciones tienen múltiples conexiones ISP (T1, Cable y / o DSL) que enrutamos manualmente usando las herramientas IP en Linux. Todos estos cortafuegos se ejecutan en la red (10.0.0 / 24) y son en su mayoría cortafuegos de grado "profesional" (Linksys, Netgear, etc.) o módems DSL proporcionados por el ISP.
• La conexión de estos firewalls (mediante conmutadores simples no administrados) es uno o más servidores que deben ser accesibles públicamente.
• Conectados a la subred 10.0.0 / 24 de la oficina principal hay servidores para correo electrónico, VPN de teletrabajador, servidor VPN de oficina remota, enrutador primario a las subredes internas 192.168 / 24. Deben tener acceso desde conexiones ISP específicas según el tipo de tráfico y la fuente de conexión.
• Todo nuestro enrutamiento se realiza manualmente o con declaraciones de ruta OpenVPN
• El tráfico entre oficinas pasa por el servicio OpenVPN en el servidor principal 'Enrutador' que tiene su propia NAT 'involucrada.
• Los sitios remotos solo tienen un servidor instalado en cada sitio y no pueden permitirse múltiples servidores debido a restricciones de presupuesto. Estos servidores son todos servidores LTSP de varias terminales 5-20.
• Las subredes 192.168.2 / 24 y 192.168.3 / 24 se encuentran principalmente pero NO completamente en los switches Cisco 2960 que pueden hacer VLAN. El resto son conmutadores DLink DGS-1248 en los que no estoy seguro de confiar lo suficiente como para usar con VLAN. También existe cierta preocupación interna sobre las VLAN, ya que solo el personal superior de redes comprende cómo funciona.

Todo el tráfico regular de Internet pasa a través del servidor de enrutador CentOS 5, que a su vez convierte las subredes 192.168 / 24 en las subredes 10.0.0.0/24 de acuerdo con las reglas de enrutamiento configuradas manualmente que utilizamos para señalar el tráfico saliente a la conexión a Internet adecuada según declaraciones de enrutamiento '-host'.

Quiero simplificar esto y preparar All Of The Things para la virtualización de ESXi, incluidos estos servicios públicos. ¿Existe una solución gratuita o de bajo costo que elimine el doble NAT y restablezca un poco la cordura a este desorden para que mi futuro reemplazo no me persiga?

Diagrama básico para la oficina principal:

Estas son mis metas:

• Los servidores públicos con interfaces en esa red 10.0.0 / 24 intermedia se trasladarán a la subred 192.168.2 / 24 en los servidores ESXi.
• Deshágase del doble NAT y obtenga toda nuestra red en una sola subred. Tengo entendido que esto es algo que tendremos que hacer bajo IPv6 de todos modos, pero creo que este desastre se interpone en el camino.

1.) Básicamente, antes de cualquier otra cosa, arregle su plan de direccionamiento IP. Es doloroso volver a numerar, pero es el paso necesario para llegar a una infraestructura viable. Reserve superredes cómodamente grandes y fáciles de resumir para estaciones de trabajo, servidores, sitios remotos (con IP únicas, naturalmente), redes de administración, bucles, etc. Hay mucho espacio RFC1918 y el precio es justo.

2.) Es difícil tener una idea de cómo diseñar L2 en su red según el diagrama anterior. Es posible que las VLAN no sean necesarias si tiene una cantidad suficiente de interfaces en sus diversas puertas de enlace, así como también una cantidad suficiente de conmutadores. Una vez que tenga una idea de # 1, puede tener sentido volver a abordar la pregunta L2 por separado. Dicho esto, las VLAN no son un conjunto de tecnologías especialmente complejo o novedoso y no necesitan ser tan complicadas. Se requiere cierta cantidad de entrenamiento básico, pero como mínimo la capacidad de separar un switch estándar en varios grupos de puertos (es decir, sin trunking) puede ahorrar mucho dinero.

3.) Los hosts DMZ probablemente deberían colocarse en sus propias redes L2 / L3, no fusionarse con estaciones de trabajo. Lo ideal sería que sus enrutadores fronterizos estuvieran conectados a un dispositivo L3 (¿otro conjunto de enrutadores? ¿Interruptor L3?) Que, a su vez, conectaría una red que contiene sus interfaces de servidor externas (host SMTP, etc.). Es probable que estos hosts se conecten nuevamente a una red distinta o (menos óptimamente) a una subred de servidor común. Si ha diseñado sus subredes adecuadamente, las rutas estáticas necesarias para dirigir el tráfico entrante deberían ser muy simples.

3a.) Intente mantener las redes VPN separadas de otros servicios entrantes. Esto facilitará las cosas en cuanto a monitoreo de seguridad, resolución de problemas, contabilidad, etc.

4.) A falta de consolidar sus conexiones a Internet y / o enrutar una subred única a través de varios operadores (lea: BGP), necesitará el salto intermedio antes de sus enrutadores fronterizos para poder redirigir el tráfico entrante y saliente de manera adecuada (como Sospecho que lo estás haciendo en este momento). Esto parece un dolor de cabeza más grande que el de las VLAN, pero supongo que todo es relativo.