esquemas criativos de IP / sub-rede / DNS

Question

Eu só administrei redes bastante pequenas (< = 25 nós). Normalmente eu coloco o gateway .1, dns / proxy como .10, correio em .20, impressoras em .30-39 e assim por diante e assim por diante. Eu nunca uso endereços IP diretamente, pois os nomes de host DNS são claramente a melhor maneira, mas eu gosto de ter um padrão / layout / design claro ao criar uma rede a partir do zero.

Meu mapeamento de DNS também tem um padrão / layout de nomenclatura simples. Por exemplo, todos os meus dispositivos têm dois nomes; um nome formal baseado em função (dc01, mail02, etc.) e um nome informal. Nada extravagante, mas muito simples e gerenciável.

Estou tentando descobrir um esquema de IP / sub-rede / DNS mais intuitivo / criativo (se houver algo melhor). Tenho certeza que os outros têm esquemas mais intuitivos, dependendo dos objetivos da rede e tal. Minha rede em que estou trabalhando ainda é pequena, mas eu tenho vários dispositivos para enfrentar.

Estou à procura de um padrão geral ou metodologia para atribuir endereços IP (intervalos / classes), nomes de DNS e redes de sub-redes que englobem 4-5 pontos principais:

1. Serviços de rede (correio, arquivo, proxy etc.)
2. Desenvolvimento de software (ambientes - dev / staging / prod,
3. Mídia (streaming, transferências de arquivos grandes, arquivamento)
4. Servidores virtuais / desktops
5. VoIP

Eu nunca trabalhei diretamente com o VoIP, mas é algo a ser levado em consideração para o futuro.

No geral, tenho algumas boas ideias de todos. Gostaria de poder dar mais votos / respostas aceitas. Obrigado pelas respostas!

    

Answer 1

Mantenha a simplicidade. O mais simples possível, mas ainda permitindo segurança e flexibilidade. Projete abstração em coisas, o que parece não ser simples, mas na verdade é o caminho para a simplicidade em si.

Quanto às sub-redes, isso é bastante comum:

• Usuários em uma sub-rede
• Convidados em outro
• Servidores em sua própria sub-rede
• VOIP por conta própria também.

Filtre o tráfego em cada sub-rede, conforme necessário. Possivelmente use VLANs. Espero que você esteja intimamente familiarizado com o CLI do fornecedor de dispositivos de rede escolhido.

Quanto ao DNS, você não vai gostar disso, mas ... use o que for melhor para você. Pessoalmente, gosto de dar aos servidores um nome de host totalmente abstrato, sem vínculos com seus serviços. Eu, então, CNAME atende ao nome do host. Dessa forma, os serviços de migração não causam dores de cabeça de alteração de DNS. Ou pelo menos não tantos. Eu também prefiro nomear servidores virtuais com um v prefixado ao nome do host.

Exemplos:

• Novo servidor de banco de dados é chamado Athena. Será nomeado Athena para sempre.
• Athena é CNAMED pelo que faz: SQL08ENT-CRM, SQL08ENT-AEGIS (o sistema de segurança), SQL08ENT-DOCMAN. Talvez também CNAMED baseado em geografia. Ou talvez o nome do host tenha geografia nele. Athena-ATL. Athena-Sydney. Tudo o que funciona.
• O servidor está na sub-rede do servidor que possui uma política de negação padrão. Ele tem o tráfego adequado incluído nas sub-redes adequadas.

Mantenha. Isto. Simples. (mas funcional)

    

Answer 2

Eu trabalhei em uma organização de tamanho similar (nós tínhamos um / 26), que por razões além de mim, os poderes consideravam que um esquema de alocação de IPs finos era primordial para a integridade operacional. O gateway tinha para ser 0,1, as impressoras tinham entre 0,22 e 0,12, os servidores entre 0,13 e 0,20 e assim por diante. Nós até mantivemos a documentação em hosts individuais.

Esta é uma enorme dor no rabo. Não importa quão diligente eu fosse, nunca consegui manter nenhuma documentação atualizada. Não ajudou que não tivéssemos nenhum serviço de DNS, portanto, usar essa documentação do esquema de alocação de IP era o único serviço de "nomeação" que tínhamos (o que, de uma maneira estranha, fazia com que parecesse mais indispensável do que realmente era). p>

Para uma rede do seu tamanho, eu recomendaria algumas coisas (a maioria das quais você já fez):

• Simples - você não está gerenciando centenas de hosts. A complexidade da sua solução deve refletir a complexidade do ambiente. Resista à tentação de ser excessivamente inteligente. Você vai se agradecer depois.

  1. Pegue seu espaço IP disponível e dê 60% para seus clientes via DHCP. Configure algum tipo de serviço de DNS dinâmico para que você nunca tenha que olhar para um maldito endereço IP novamente. Esqueça-se de acompanhá-los. Lucro.

  2. Reserve os outros 30% para endereços IP você gerencia: servidores, impressoras, dispositivos de rede, serviços de teste. etc. USE DNS PARA DOCUMENTAR ISTO. Na minha opinião, não há maior desperdício de tempo do que manter um registro atento de todos esses endereços IP "gerenciados pelo administrador" (em oposição aos endereços IP gerenciados por DHCP) usando uma planilha do Excel (à qual você deve se referir e manter constantemente) , quando você poderia estar se esforçando para suportar uma solução de DNS auto-documentada e muito mais útil.

  3. Mantenha os últimos 10% do seu endereço na parte superior do espaço de endereçamento IP não utilizado. Uma pequena reserva nunca é demais.

  4. Ajuste as proporções conforme achar melhor para o seu ambiente. Alguns ambientes terão mais clientes, alguns serão "servidor" (ou seja, "gerenciados pelo administrador") pesados.

• Serviços de rede (correio, arquivo, proxy etc.)
• Desenvolvimento de software (ambientes - dev / staging / prod,

Esses dois se enquadram na categoria de espaço IP "gerenciado pelo administrador".

• Mídia (streaming, transferências de arquivos grandes, arquivamento)

Na minha opinião, isso tem pouco a ver com sub-redes e tudo a ver com monitoramento de rede.

• Servidores virtuais / desktops

Os servidores são "gerenciados pelo administrador", os desktops (ou seja, máquinas clientes) devem ser "gerenciados por DHCP".

• VoIP

Uma rede fisicamente discreta seria ideal ... mas que é irrealista. A próxima melhor coisa seria uma VLAN e uma sub-rede separadas. Este é o único ponto em uma pequena rede onde eu realmente sinto a necessidade de segregar o tráfego (exceto para coisas que são publicamente acessíveis).

    

Answer 3

Para alocações de IP

Meu conselho é colocar tudo sob a sub-rede 10.0.0.0/8, usando a seguinte estrutura: 10. site . division . device

• site é uma localização física ou equivalente lógica (por exemplo, escritório de NY, escritório de NJ, instalação de DR, Desenvolvimento meio Ambiente).
• division é uma subdivisão lógica que faz sentido para você. por exemplo,
  0 = > Switches / Roteadores 1 = > Admins, 2 = > Usuários
  3 = > VOIP
  4 = > Convidados
• device s são dispositivos individuais (PCs, servidores, telefones, switches, etc.)

A ideia aqui é que você pode determinar facilmente o que é um dispositivo e onde ele está por seu endereço: 10.2.1.100 é a estação de trabalho de um administrador no "Site # 2".

Este modelo é derivado de atribuições de IP baseadas em classe: a Classe A (/ 8) é a sua empresa. Cada local obtém uma Classe B (/ 16) e cada divisão lógica em um local obtém uma Classe C (/ 24) para seus dispositivos. É possível (e às vezes desejável) usar algo maior que um / 24 para o nível de "divisão", e você pode fazê-lo: Qualquer coisa de a / 17 a / 24 é geralmente um jogo justo com esse esquema.

Para nomes DNS

Meu conselho é seguir um esquema semelhante ao do IP que descrevi acima:

• Tudo está enraizado em mycompany.com
• Cada site (/ 16) tem seu próprio subdomínio sitename.mycompany.com .
• As divisões lógicas podem ter um (ou mais) subdomínios no site, por exemplo:
  • voip.mycompany.com (com dispositivos como tel0000.voip.mycompany.com , tel0001.voip.mycompany.com , etc.)
  • switches.mycompany.com
  • workstations.mycompany.com (possivelmente subdividido em admin, user & guest)
• Os dispositivos devem ter nomes significativos. Por exemplo:
  • Nomeie os telefones para que você possa ver a extensão que eles chamam com base no nome DNS.
  • Nomeie as estações de trabalho com base em seu usuário principal.
  • Identifique claramente os endereços IP "convidados".
  • Nome servidores para que você possa dizer o que eles são / o que eles fazem. Isso pode ser feito usando nomes "chatos" ( www01 , www02 , db01 , db02 , mail , etc.) ou promulgando um esquema de nomeação e aderindo a ele (por exemplo: servidores de email são nomeados após rocks, servidores web são nomeados após árvores, servidores de banco de dados são nomeados após pintores). Nomes chatos são mais fáceis para uma pessoa nova aprender, esquemas de nomeação legais são mais divertidos. Faça a sua escolha.

Notas diversas

Em relação aos servidores virtuais:
Considere-os como se fossem máquinas físicas (separe-as por divisão / finalidade e não pelo fato de serem "virtuais". Tenha uma divisão separada para a rede de administração do Hypervisor / VM.
Pode parecer importante agora saber se uma caixa é virtual ou física, mas quando o sistema de monitoramento diz "Ei, o e-mail está inativo!" a pergunta que você vai fazer é "Quais máquinas estão relacionadas ao email?", não "Quais máquinas são virtuais e quais são físicas?". Note que você DO precisa de uma maneira prática de identificar se uma máquina é virtual ou física no caso de um host hipervisor explodir, mas isso é um desafio para seu sistema de monitoramento, não para sua arquitetura de rede.

Sobre o VOIP:
VOIP (asterisco em particular) é sinônimo de "Security Hole". Enfie todas as suas coisas de VOIP em sua própria sub-rede e em sua própria VLAN, e não a deixe perto de nada sensível. Todos os telefones VOIP que vi no ano passado suportam a segregação VLAN (na verdade, todos suportam VLANs de voz e dados, portanto, você ainda pode usar o telefone como um pass-thru para conexões Ethernet de desktop). Tire proveito disso - Você ficará feliz em saber se / quando seu ambiente VoIP for invadido.

Sobre planejamento e documentação:
Desenhe sua rede em papel antes de começar a atribuir endereços e nomes DNS. Na verdade, desenhe em uma folha de papel GRANDE primeiro. Cometer muitos erros.
Apague liberalmente.
Maldito fluentemente.
Uma vez que você pare de xingar e apagar por pelo menos 10 dias, é hora de colocar o diagrama no Visio / Graffle / Algum outro formato eletrônico como seu diagrama de rede oficial. Proteja este diagrama. Mantê-lo em sua mais sagacidade correta à medida que você adiciona e remove dispositivos, amplia sua organização e modifica sua estrutura de rede. Este diagrama de rede será seu melhor amigo quando você precisar fazer alterações, explicar a rede a novos administradores ou solucionar uma falha misteriosa.