10 votos

Red de Reestructuración Método de Doble NAT red

Debido a una serie de pobre diseño de la red de decisiones (en su mayoría) hizo muchos años atrás con el fin de ahorrar unos cuantos dólares aquí y allá, tengo una red que es decididamente sub-óptima de la arquitectura. Estoy buscando sugerencias para mejorar este menos que placentera situación.

Somos una entidad sin fines de lucro basado en Linux, departamento de TI y un presupuesto limitado. (Nota: Ninguno de los Windows equipos con los que contamos funciona, algo que habla a Internet, ni tenemos ningún Windows administradores en el personal.)

Puntos clave:

  • Contamos con una oficina principal y cerca de 12 sitios remotos que esencialmente doble NAT sus subredes físicamente segregada de los interruptores. (No VLANing y limitada capacidad para hacerlo con la corriente cambie)
  • Estos lugares tienen una "zona de distensión" de subred que NAT había en una forma idéntica asignado 10.0.0/24 subred en cada sitio. Estas subredes no se puede hablar Dmz en cualquier otro lugar, porque no nos ruta a ellos en cualquier lugar excepto entre el servidor y el adyacente "firewall".
  • Algunos de estos lugares tienen múltiples conexiones ISP (T1, Cable y/o Dsl) que nos manualmente la ruta utilizando Herramientas de IP en Linux. Estos firewalls se ejecutan en el (10.0.0/24) de la red y la mayoría son de "pro-sumer" grado de firewalls (Linksys, Netgear, etc.) o ISP proporcionado por los módems ADSL.
  • La conexión de estos firewalls (a través de los switches no gestionados) es uno o más servidores que debe ser públicamente accesible.
  • Conectado a la oficina principal de la 10.0.0/24 subred son los servidores de correo electrónico, tele-cercanías VPN, oficina remota de servidor VPN, router principal a la interna 192.168/24 subredes. Estos tienen que ser de acceso de determinadas conexiones ISP basado en el tipo de tráfico y de la conexión de la fuente.
  • Todas nuestras rutas se realiza manualmente o con OpenVPN ruta declaraciones
  • Inter-oficina de tráfico que pasa a través de el servicio de OpenVPN en el principal 'Router' servidor que tiene su propia NAT ing involucrados.
  • Sitios remotos sólo tiene un servidor instalado en cada sitio y no puede permitirse el lujo de múltiples servidores debido a limitaciones de presupuesto. Estos servidores son todos LTSP servidores de varios 5-20 terminales.
  • La 192.168.2/24 y 192.168.3/24 subredes son en su mayoría pero NO en su totalidad en Cisco 2960 interruptores que pueden hacer VLAN. El resto son DLink DGS-1248 interruptores que no estoy seguro de que puedo confiar lo suficiente para usar con las Vlan. También hay algunas internas restantes preocupación acerca de las Vlan, dado que sólo el senior de red de personal de la persona entienda cómo funciona.

Todo el tráfico de internet pasa a través de CentOS 5 router servidor que se convierte en NATs el 192.168/24 subredes a la 10.0.0.0/24 subredes de acuerdo a la configurada manualmente las reglas de enrutamiento que utilizamos a punto de tráfico de salida a la correcta conexión de internet basado en el 'host' de enrutamiento declaraciones.

Quiero simplificar esto y listo Todas Las Cosas para ESXi de virtualización, incluyendo estas público de servicios. Hay un no - o solución de bajo coste que pudiera deshacerse de la Doble NAT y restaurar un poco de cordura a este desastre, así que mi futuro reemplazo no hunt me down?

Diagrama básico para la oficina principal: enter image description here

Estos son mis objetivos:

  • Público de Servidores con interfaces en las que el centro 10.0.0/24 red para mover a 192.168.2/24 subred de servidores ESXi.
  • Deshacerse de la doble NAT y obtener toda la red en una sola subred. Mi entendimiento es que esto es algo que lo vamos a hacer bajo el protocolo IPv6 de todos modos, pero creo que este lío está de pie en el camino.

2voto

rnxrx Puntos 6464

1.) Antes, básicamente, nada más llegar a su plan de direccionamiento IP enderezado. Es doloroso volver a numerar pero es el paso necesario para llegar a un aplicables de la infraestructura. Aparte cómodamente grande, fácil de resumir supernets para estaciones de trabajo, servidores, sitios remotos (con IP única, por supuesto), gestión de redes, bucles de retorno, etc. Hay un montón de RFC1918 espacio y el precio es correcto.

2.) Es difícil hacerse una idea de cómo diseñar la L2 en la red basada en el diagrama de arriba. VLAN puede no ser necesario si tienes un número suficiente de interfaces en las distintas pasarelas, así como un número suficiente de interruptores. Una vez que tienes un sentido de la #1 podría tener sentido reapproach la L2 pregunta por separado. Dicho esto, VLAN no son especialmente complejos o nuevos conjunto de tecnologías y no tiene por qué ser tan complicado. Una cierta cantidad de entrenamiento básico está en orden, pero, como mínimo, la capacidad de separar un interruptor estándar en varios grupos de puertos (es decir, sin trunking) puede ahorrar un montón de dinero.

3.) La DMZ hosts probablemente debe ser colocado en sus propias L2/L3 redes, no se combinan con las estaciones de trabajo. Idealmente, tendría enrutadores de borde conectado a un L3 dispositivo (otro conjunto de routers? L3 cambiar?) que, a su vez, conectar una red que contiene su externamente frente interfaces del servidor (host SMTP, etc). Estos hosts es probable que se conecta a una red distinta o (menos de manera óptima a un servidor común de subred. Si usted ha presentado su subredes adecuadamente, a continuación, las rutas estáticas necesarias para dirigir el tráfico entrante debe ser muy simple.

3a.) Trate de mantener las redes VPN separado de los otros entrantes servicios. Esto va a facilitar las cosas tan lejos como la supervisión de la seguridad, solución de problemas, contabilidad, etc.

4.) Corto de la consolidación de sus conexiones de Internet y/o el enrutamiento de una sola subred a través de diversos soportes (lea: BGP) tendrá el intermedio hop antes de los routers de frontera para ser capaz de redirigir y salida de tráfico de forma adecuada (como sospecho que estás haciendo en este momento). Esto parece como un mayor dolor de cabeza de VLAN, pero supongo que todo es relativo.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: