1 Servidor DHCP, dois escopos, duas VLANs diferentes - Um problema maior do que parece?

2

Portanto, estamos executando servidores DHCP únicos (em cada local, temos três locais) que exibem endereços IP para nossos funcionários / funcionários, bem como nosso corpo discente. Temos um único servidor DHCP que se conecta aos nossos switches em nossa área central de comutação.

Como estou redesenhando nossa rede e analisando problemas de DHCP que estamos tendo em vários campus conectados com seus próprios servidores DHCP, basicamente, a partir desta questão, temos um hub gigantesco no qual o servidor DHCP responde primeiro esse endereço IP. O problema é que estamos recebendo problemas de roteamento e uma bagunça de outros problemas devido a concessões de DHCP. As funções dos servidores DHCP em cada local remoto são simplesmente arrendamento de IP e hospedagem de arquivos de impressora para funcionários / funcionários e alunos.

Neste mês de dezembro, estamos criando "ilhas" dentro das 3 redes e o roteamento será tratado por alguns switches L3 e firewalls reais. Minha pergunta é com essa mudança na rede, é hora de se libertar e ter servidores DHCP independentes para os alunos? Eu estou tentando projetar tudo isso com muita conveniência e segurança em mente, o que é um pesadelo, considerando que eu herdei um sistema quebrado com enormes buracos abertos apenas 3 pessoas de TI para fazer o trabalho.

Depois de ler um monte de artigos sobre o BKM do TechNet, eu queria um conhecimento do mundo real de todos aqui.

    
por Aaron H 20.09.2011 / 00:39

1 resposta

2

Alguma elaboração sobre o que você entende por "problemas de roteamento e uma bagunça de outros problemas devido a concessões de DHCP" pode nos ajudar a entender melhor de onde você vem. Não há nenhum motivo inerente para que um servidor DHCP central não possa fazer o que você deseja.

Acredito que tenho uma situação semelhante à sua em um dos clientes. Eles têm um campus de 5 prédios com cerca de 1.000 clientes com fio fixo e 200 clientes sem fio (alguns dos quais se movem entre os prédios). Usamos um par de computadores servidores DHCP centrais (executando o Windows Server 2008 R2) para fornecer o DHCP para toda a rede. Estou muito feliz com a configuração.

Os edifícios individuais têm switches da camada 3 que executam o roteamento intra-VLAN e o roteamento entre construções. Não há firewalls nos prédios, mas há algumas ACLs nos switches da camada 3 que fornecem alguma funcionalidade de firewall.

Estou contando com recursos em meus pontos de acesso sem fio (Ruckus) e switches de camada 2/3 (Dell e Cisco) para impedir que os clientes esgotem os escopos DHCP com solicitações falsas e para identificar e bloquear portas com DHCP não autorizado. servidores. Se eu quisesse ser realmente chique, eu poderia considerar o uso de MAC filtragem baseada em endereço nos servidores DHCP para escopos sensíveis, bloqueio de portas de switch específicas para apenas endereços MAC conhecidos e / ou outros truques para ser mais draconiano. (Estamos separando o DHCP das sub-redes públicas de wifi para um par de servidores ISC DHCPd, mas estamos fazendo isso por causa das discrepâncias da Microsoft nas declarações sobre se uma CAL é ou não necessária para o DHCP, não por causa de qualquer problema de arquitetura .)

Não tenho espaço seguro em cada prédio para os servidores, portanto, colocar os servidores DHCP em cada prédio não era possível de uma perspectiva de segurança física pura. Também não vi nenhuma vantagem funcional em ter servidores DHCP distribuídos. Se os links entre edifícios estiverem inativos, ter DHCP em qualquer edifício não ajudará, porque eles não têm recursos no local para acessar de qualquer maneira. Ter 5 pontos únicos de falha em vez do par de servidores DHCP centrais também parecia uma má ideia. Da mesma forma, colocar 2 servidores DHCP em cada edifício para fornecer redundância no edifício e aumentar a contagem de servidores para 10 parecia criar uma grande carga administrativa e despesa de licenciamento de hardware / software para servidores.

    
por 20.09.2011 / 14:38