A melhor maneira de segmentar tráfego, VLAN ou sub-rede?

Temos uma rede de tamanho médio de cerca de 200 nós e atualmente estamos no processo de substituir switches antigos encadeados em série por switches empilháveis ​​ou no estilo de chassi.

No momento, nossa rede está dividida por meio de sub-redes: produção, gerenciamento, propriedade intelectual (IP) etc., cada uma em uma sub-rede separada. Criar VLANs em vez de sub-redes seria mais benéfico?

Nosso objetivo geral é evitar gargalos, separar o tráfego por segurança e gerenciar o tráfego com mais facilidade.

VLANs e sub- redes resolvem problemas diferentes. As VLANs funcionam na camada 2 , alterando assim os domínios de broadcast (por exemplo). Enquanto as sub-redes são a Camada 3 no contexto atual

Uma sugestão seria realmente implementar ambos

Tenha, por exemplo, VLAN 10 a 15 para seus diferentes tipos de dispositivos (desenvolvedor, teste, produção, usuários etc.)

VLAN 10, você pode ter a sub-rede 192.168.54.x / 24 VLAN 11, você pode ter a sub-rede 192.168.55.x / 24

E assim por diante

Isso exigiria que você tivesse um roteador dentro da sua rede, embora

Depende de você o caminho a seguir (você conhece sua rede melhor do que eu jamais). Se você acha que o tamanho do seu domínio de broadcast será algum tipo de problema, use VLANs. Se você acha que o tamanho dos seus domínios de gerenciamento de rede (por exemplo, sua rede de gerenciamento), possivelmente, use uma rede mais próxima de um / 16 sobre um / 24

Seus 200 nós se encaixam em um / 24, mas isso obviamente não oferece muito espaço para crescimento

Pelo jeito, você já está usando sub-redes diferentes para diferentes tipos de dispositivos. Então, por que não ficar com isso? Você pode, se quiser, vincular cada sub-rede a uma VLAN. A segmentação da camada 2 resultará na alteração do comportamento da sua rede, de como ela se comporta atualmente

Você teria que investigar o impacto potencial desse

(Estive na estrada o dia todo e senti falta de pular nessa ... Ainda assim, atrasado para o jogo, verei o que posso fazer.)

Normalmente, você cria VLANs na Ethernet e mapeia as sub-redes IP 1 a 1 para elas. Existem maneiras de não fazer isso, mas, seguindo um mundo estritamente "simples de baunilha", você criaria uma VLAN, pensaria em uma sub-rede IP a ser usada na VLAN, atribuiria a um roteador um endereço IP nessa VLAN, anexa-o ao roteador. a VLAN (com uma interface física ou uma subinterface virtual no roteador), conecte alguns hosts à VLAN e atribua-lhes endereços IP na sub-rede que você definiu e direcione o tráfego para dentro e para fora da VLAN.

Você não deve iniciar a sub-rede de uma LAN Ethernet, a menos que tenha boas razões para fazê-lo. Os dois melhores motivos são:

• Atenuando problemas de desempenho. As LANs Ethernet não podem ser escalonadas indefinidamente. Transmissões excessivas ou inundação de quadros para destinos desconhecidos limitarão sua escala. Qualquer uma dessas condições pode ser causada ao tornar um único domínio de broadcast em uma LAN Ethernet muito grande. O tráfego de transmissão é fácil de entender, mas a inundação de quadros para destinos desconhecidos é um pouco mais obscura. Se você obtiver tantos dispositivos que as tabelas MAC do seu switch estiverem transbordando, os switches serão forçados a inundar os quadros não transmitidos por todas as portas se o destino do quadro não corresponder a nenhuma entrada na tabela MAC. Se você tiver um domínio de broadcast único grande o suficiente em uma LAN Ethernet com um perfil de tráfego que hospeda a conversa com pouca frequência (ou seja,

• O desejo de limitar / controlar o tráfego que se move entre os hosts na camada 3 ou acima. Você pode fazer alguma invasão examinando o tráfego na camada 2 (ala Linux ebtables), mas isso é difícil de gerenciar (porque as regras estão vinculadas aos endereços MAC e a mudança de NICs exige mudanças de regra) pode causar comportamentos que parecem realmente estranhos (fazer o proxy transparente do HTTP na camada 2, por exemplo, é esquisito e divertido, mas é totalmente natural e pode ser muito intuitivo para solucionar problemas) e geralmente é difícil de ser feito nas camadas inferiores (porque as ferramentas da camada 2 são como paus e rochas ao lidar com as preocupações da camada 3+). Se você deseja controlar o tráfego IP (ou TCP, UDP, etc) entre hosts, em vez de atacar o problema na camada 2, sub-rede e cole firewalls / roteadores com ACLs entre as sub-redes.

Os problemas de exaustão da largura de banda (a menos que sejam causados ​​por pacotes de transmissão ou inundação de quadros) não são resolvidos com VLANs e sub-redes normalmente. Elas acontecem devido à falta de conectividade física (poucas NICs em um servidor, poucas portas em um grupo de agregação, a necessidade de subir para uma velocidade de porta mais rápida) e não podem ser resolvidas sub-redes ou implantando VLANs desde aumentar a quantidade de largura de banda disponível.

Se você não possui nem mesmo algo simples como o MRTG executando gráficos de estatísticas de tráfego por porta em seus switches, essa é realmente a sua primeira ordem de negócios antes de começar a introduzir gargalos com sub-redes bem-intencionadas, mas não informadas. A contagem bruta de bytes é um bom começo, mas você deve segui-lo com sniffing direcionado para obter mais detalhes sobre os perfis de tráfego.

Depois de saber como o tráfego circula na sua LAN, você pode começar a pensar em sub-redes por motivos de desempenho.

No que diz respeito à "segurança", você precisará saber muito sobre o seu aplicativo e como ele fala antes de prosseguir.

Eu fiz um design para uma LAN / WAN de tamanho razoável para um cliente comercial há alguns anos e me pediram para colocar listas de acesso na entidade da camada 3 (um módulo supervisor Cisco Catalyst 6509) para controlar o tráfego que se move entre as sub-redes por um " engenheiro ", que tinha pouco entendimento de que tipo de trabalho seria necessário, mas estava muito interessado em" segurança ". Quando voltei com uma proposta para estudar cada aplicativo para determinar as portas TCP / UDP e os hosts de destino necessários, recebi uma resposta chocada do "engenheiro" afirmando que não deveria ser tão difícil. A última vez que ouvi dizer que eles estavam executando a entidade da camada 3 sem listas de acesso, porque não conseguiam que todo o software funcionasse de maneira confiável.

A moral: se você realmente quiser abaixar o acesso de pacotes e de nível de fluxo entre VLANs, esteja preparado para fazer um monte de trabalho braçal com o software aplicativo e aprendendo / fazendo engenharia reversa como ela fala por fio. A limitação do acesso dos hosts aos servidores geralmente pode ser realizada com a funcionalidade de filtragem nos servidores. A limitação do acesso por fio pode fornecer uma falsa sensação de segurança e impedir que os administradores cheguem a uma complacência em que pensam "Bem, não preciso configurar o aplicativo com segurança, porque os hosts que podem conversar com o aplicativo são limitados por 'the rede'." Recomendamos que você audite a segurança da configuração do servidor antes de começar a limitar a comunicação host a host na conexão.

99% do tempo, uma sub-rede deve ser equivalente a uma VLAN (ou seja, cada sub-rede de acesso deve mapear para uma e apenas uma VLAN).

Se você possui hosts de mais de uma sub-rede IP na mesma VLAN, derrota o objetivo das VLANs, pois as duas (ou mais) sub-redes estarão no mesmo domínio de broadcast.

Como alternativa, se você colocar uma sub-rede IP em várias VLANs, os hosts na sub-rede IP não poderão se comunicar com os hosts na outra VLAN, a menos que o seu roteador tenha o ARP proxy ativado.

Eu concordo principalmente com David Pashley :

1. Eu uso um single / 16 para tudo.
   • mas é segmentado em várias VLANs, unidas por uma ponte de software em uma máquina Linux.
   • Nesta ponte, tenho várias regras do iptables para filtrar o acesso entre grupos.
   • não importa como você segmenta, use intervalos de IP para agrupar, facilita a reestruturação e casos especiais.