(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.