Múltiplas VLANs e Confusão de Grupos de Usuários

2

Estou implantando e projetando uma nova rede para nosso projeto danificado. Eu nunca projetei uma rede a partir do zero, por mim mesmo. O simples atropelo é este:

  • VLAN 1 - Produção no Centro de dados. 10.10.0.0/24
  • VLAN 2 - Usuários normais 10.10.20.0/24
  • VLAN 3 - IT 10.10.30.0/24
  • VLAN 4 - Voice 10.10.40.0/24

    1. Um servidor DHCP (2008R2)
    2. Dois PoE Juniper EX2200 em uma pilha no escritório local.
    3. Dois Juniper EX4200 em uma pilha no datacenter.

A questão sobre a qual estou confuso é que não quero permitir que usuários normais acessem prod. mas, eu preciso permitir-lhes acessos para trocar, citrix, IM e alguns outros servidores que são classificados como produção. Como as pessoas normalmente fazem isso? Eu apenas atribuo acesso à porta para a VLAN 1, o que parece que estou acabando com o propósito de tê-los ou separo os servidores que são necessários para usuários normais e os coloco na VLAN 2? Meu último pensamento é que eu só permito que eles acessem externamente para troca, ou seja, RPC ou HTTP?

Obrigado rapazes

    
por BrandonB 17.05.2011 / 04:39

2 respostas

7

Em resumo, os dispositivos que roteiam o tráfego entre suas várias sub-redes (atribuídas a várias VLANs) precisam impor a política de segurança de comunicação. No mínimo, isso significa usar roteadores (ou dispositivos com funcionalidade de roteador) que suportam listas de controle de acesso sem estado. Se você quiser ficar mais chique, você pode usar dispositivos com funcionalidade de filtragem de estado (firewalls stateful típicos, iptables do Linux, etc).

Acho que você pode ter uma concepção simplista do que significa não permitir que "usuários normais acessem a produção". O caminho que você está indo para baixo envolve a criação de gráficos dos vários protocolos (portas TCP e UDP, normalmente) com os quais os aplicativos clientes precisarão se comunicar nos computadores servidores (alguns dos quais, no caso do Microsoft RPC, são dinâmicos por padrão ). Depois de descobrir como essa comunicação deve funcionar, você cria listas de controle de acesso (ou regras de firewall) para permitir a comunicação necessária e, ao mesmo tempo, negar todo o tráfego.

Esta é uma linha dura para enxada. Eu vi poucos ambientes onde isso foi completamente pensado e implementado. Envolve um lote de comunicação entre os administradores do aplicativo e os administradores de rede (ou, se você é um no mesmo, muita documentação de software de estudo). Normalmente, será preciso fazer um lote de testes e, em muitos casos, você aprenderá que os desenvolvedores de aplicativos de software "boutique" nunca tiveram tempo de descobrir quais protocolos seus aplicativos usam para se comunicar (e muitas vezes apenas assumir uma rede aberta e plana entre o cliente e o servidor).

No final, você perceberá que terá mais sorte executando regras de firewall baseadas em host e sendo bastante tolerantes com suas listas de controle de acesso / regras de firewall dentro da VLAN, não necessariamente porque essa é a coisa certa a fazer, mas porque é a coisa viável a fazer. Boa sorte!

Como um aparte: Ver suas sub-redes planejadas aumentando em 10 no terceiro octeto diz a mesma coisa que sua declaração "Eu nunca projetei uma rede a partir do zero, por mim mesmo." Se você quiser permitir espaço para crescimento nessas sub-redes, considere fazer algo mais como:

  • 10.10.0.0 / 19
  • 10.10.32.0 / 19
  • 10.10.64.0 / 19
  • 10.10.96.0 / 19

Mesmo se você começar a usar essas várias sub-redes como / 24's, você terá espaço em cada uma para crescer até / 19's (com 4 / 19s disponíveis para uso futuro também). Com as sub-redes não contíguas que você está propondo em sua resposta, você está desperdiçando espaço de IP ou criando redes que não podem ser resumidas com uma única rota CIDR.

    
por 17.05.2011 / 04:56
1

É um plano razoável dividir seus servidores por VLAN, mas eu concordo com a @Evan que tentar fazê-lo pela porta é praticamente impossível, manter os servidores para usuários 'reais' completamente separados daqueles usados para desenvolvimento. Os desenvolvedores vão odiá-lo, mas firewall-los e seu ambiente de teste / dev completamente fora, se possível.

Tecnicamente, seria melhor evitar o uso da VLAN 1 para qualquer coisa envolvida com usuários ou servidores; ela costuma ser usada como a VLAN padrão para seus dispositivos de rede.

Depende do número de usuários que você tem, mas ter um de qualquer coisa é quase sempre ruim, mesmo que seja 'apenas' um servidor DHCP.

Eu concordo principalmente com a @Evan sobre as sub-redes, mas não ficaria muito empolgado com a sub-rede e ficaria com / 24s. Se você está em uma situação de precisar de mais hosts, adicione outra VLAN, é por isso que eles existem e ter um design onde você não pode (ou é complicação demais) adicionar outro é uma falha fundamental que deve ser resolvida antes.

A convenção de numeração para VLANs também deve ser diferente de 1 (!), 2,3,4, usar intervalos separados para usuários, servidores e desenvolvimento.

    
por 17.05.2011 / 07:03