¿La mejor forma de segmentar tráfico, VLAN o subred?

Tenemos una red de tamaño medio de alrededor de 200 nodos y actualmente estamos en el proceso de reemplazar los viejos conmutadores en cadena con conmutadores apilables o de estilo chasis.

En este momento, nuestra red se divide a través de subredes: producción, administración, propiedad intelectual (IP), etc., cada una en una subred separada. ¿Sería más beneficioso crear VLAN en lugar de subredes?

Nuestro objetivo general es evitar cuellos de botella, separar el tráfico por motivos de seguridad y gestionar el tráfico con mayor facilidad.

Las VLAN y subredes resuelven diferentes problemas. Las VLAN funcionan en la capa 2 , alterando así los dominios de difusión (por ejemplo). Mientras que las subredes son la capa 3 en el contexto actual

Una sugerencia sería implementar ambos

Tenga, por ejemplo, VLAN 10-15 para sus diferentes tipos de dispositivos (Dev, Test, Production, Users, etc.)

VLAN 10, puede tener la subred 192.168.54.x / 24 VLAN 11, puede tener la subred 192.168.55.x / 24

Y así

Sin embargo, esto requeriría que tenga un enrutador dentro de su red

Depende de usted en qué ruta se encuentre (conoce su red mejor que nunca). Si cree que el tamaño de su dominio de transmisión será algún tipo de problema, utilice las VLAN. Si cree que el tamaño de sus dominios de administración de red (por ejemplo, su red de administración), posiblemente use una red más cercana a un / 16 sobre un / 24

Sus 200 nodos encajarán en un / 24, pero eso obviamente no le da muchas posibilidades de crecimiento

Por lo que parece, ya está utilizando diferentes subredes para diferentes tipos de dispositivos. Entonces, ¿por qué no seguir con eso? Si lo desea, puede vincular cada subred a una VLAN. Sin embargo, la segmentación de capa 2 hará que el comportamiento de su red cambie de cómo se comporta actualmente

Tendría que investigar el impacto potencial de ese

(He estado en la carretera todo el día y me perdí el salto en este ... Aún así, tarde en el juego veré qué puedo hacer).

Por lo general, crea VLAN en Ethernet y asigna subredes IP 1 a 1 en ellas. Hay maneras de no hacer esto, pero si se queda en un mundo estrictamente "simple" crearía una VLAN, piense en una subred IP para usar en la VLAN, asigne a algún enrutador una dirección IP en esa VLAN, conecte ese enrutador a la VLAN (ya sea con una interfaz física o una subinterfaz virtual en el enrutador), conecte algunos hosts a la VLAN y asígneles direcciones IP en la subred que definió, y enrute su tráfico dentro y fuera de la VLAN.

No debe comenzar a dividir en subredes una LAN Ethernet a menos que tenga buenas razones para hacerlo. Las mejores dos razones son:

• Mitigación de problemas de rendimiento. Las LAN Ethernet no pueden escalar indefinidamente. Las transmisiones excesivas o la inundación de tramas a destinos desconocidos limitarán su escala. Cualquiera de estas condiciones puede ser causada por hacer que un solo dominio de difusión en una LAN Ethernet sea demasiado grande. El tráfico de transmisión es fácil de entender, pero la inundación de tramas a destinos desconocidos es un poco más oscura. Si obtiene tantos dispositivos que las tablas MAC de su conmutador se desbordan, los conmutadores se verán obligados a inundar las tramas que no son de difusión en todos los puertos si el destino de la trama no coincide con ninguna entrada en la tabla MAC. Si tiene un dominio de difusión único lo suficientemente grande en una LAN Ethernet con un perfil de tráfico que los hosts hablan con poca frecuencia (es decir,

• Un deseo de limitar / controlar el tráfico que se mueve entre los hosts en la capa 3 o superior. Puede hacer un poco de piratería informática examinando el tráfico en la capa 2 (ebtables de ala Linux), pero esto es difícil de administrar (porque las reglas están vinculadas a las direcciones MAC y el cambio de NIC requiere cambios de reglas) puede causar lo que parecen ser comportamientos realmente extraños (hacer El proxy transparente de HTTP en la capa 2, por ejemplo, es extraño y divertido, pero no es natural y puede ser muy poco intuitivo para solucionar problemas, y generalmente es difícil de hacer en las capas inferiores (porque las herramientas de la capa 2 son como palos) y rocas para lidiar con las preocupaciones de la capa 3+). Si desea controlar el tráfico IP (o TCP, o UDP, etc.) entre hosts, en lugar de atacar el problema en la capa 2, debe subred y pegar firewalls / enrutadores con ACL entre las subredes.

Los problemas de agotamiento del ancho de banda (a menos que sean causados ​​por paquetes de difusión o inundación de tramas) no se resuelven con las VLAN y las subredes típicamente. Suceden debido a la falta de conectividad física (muy pocas NIC en un servidor, muy pocos puertos en un grupo de agregación, la necesidad de avanzar a una velocidad de puerto más rápida) y no pueden resolverse dividiendo subredes o implementando VLAN desde que ganó No aumente la cantidad de ancho de banda disponible.

Si ni siquiera tiene algo simple como MRTG ejecutando gráficas de estadísticas de tráfico por puerto en sus conmutadores, ese es realmente su primer negocio antes de comenzar a introducir cuellos de botella con subredes bien intencionadas pero desinformadas. El recuento de bytes sin procesar es un buen comienzo, pero debe seguirlo con la detección selectiva para obtener más detalles sobre los perfiles de tráfico.

Una vez que sepa cómo se mueve el tráfico en su LAN, puede comenzar a pensar en subredes por razones de rendimiento.

En cuanto a la "seguridad", necesitará saber mucho sobre el software de su aplicación y cómo habla antes de poder continuar.

Hice un diseño para una LAN / WAN de tamaño razonable para un cliente médico hace unos años y me pidieron que pusiera listas de acceso en la entidad de capa 3 (un módulo supervisor Cisco Catalyst 6509) para controlar el tráfico que se mueve entre las subredes mediante un " ingeniero "que tenía poca comprensión de qué tipo de trabajo preliminar realmente requeriría pero estaba muy interesado en la" seguridad ". Cuando regresé con una propuesta para estudiar cada aplicación para determinar los puertos TCP / UDP necesarios y los hosts de destino, recibí una respuesta impactante del "ingeniero" que decía que no debería ser tan difícil. Lo último que escuché es que están ejecutando la entidad de capa 3 sin listas de acceso porque no pudieron hacer que todo su software funcionara de manera confiable.

La moraleja: si realmente va a tratar de abotonar el acceso de paquetes y de nivel de transmisión entre las VLAN, prepárese para hacer mucho trabajo de campo con el software de aplicación y el aprendizaje / ingeniería inversa de cómo se habla por cable. La limitación del acceso de los hosts a los servidores a menudo se puede lograr con la funcionalidad de filtrado en los servidores. Limitar el acceso al cable puede proporcionar una falsa sensación de seguridad y calmar a los administradores en una complacencia en la que piensan "Bueno, no necesito configurar la aplicación de forma segura porque los hosts que pueden hablar con la aplicación están limitados por" red'." Le recomiendo que audite la seguridad de la configuración de su servidor antes de comenzar a limitar la comunicación de host a host en el cable.

El 99% del tiempo, una subred debe ser equivalente a una VLAN (es decir, cada subred de acceso debe asignarse a una sola VLAN).

Si tiene hosts de más de una subred IP en la misma VLAN, anula el propósito de las VLAN, ya que las dos (o más) subredes estarán en el mismo dominio de difusión.

Alternativamente, si coloca una subred IP en varias VLAN, los hosts en la subred IP no podrán comunicarse con los hosts en la otra VLAN a menos que su enrutador tenga habilitado el proxy ARP .

Estoy de acuerdo con David Pashley :

1. Yo uso un solo / 16 para todo.
   • pero está segmentado en varias VLAN, unidas por un puente de software en una máquina Linux.
   • En este puente, tengo varias reglas de iptables para filtrar el acceso entre grupos.
   • No importa cómo segmente, use rangos de IP para agrupar, facilita la reestructuración y los casos especiales.