Esquemas de IP / sub-rede / dns criativos


11

Administrei apenas 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. Eu nunca uso endereços IP diretamente, já que os nomes de host DNS são claramente a melhor maneira, mas eu gosto de ter um padrão / layout / design claro ao construir uma rede do zero.

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

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

Estou procurando um padrão geral ou metodologia para atribuir endereços IP (intervalos / classes), nomes de DNS e redes de sub-rede que abrangem 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, grandes transferências de arquivos, arquivamento)
  4. Servidores / desktops virtuais
  5. VoIP

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


No geral, recebi boas idéias de todos. Gostaria de poder dar mais votos / respostas aceitas. Obrigado pelas respostas!

Respostas:


9

Mantenha simples. Tão simples quanto possível, mas ainda permitindo segurança e flexibilidade. Projete a abstração para as 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 através de cada sub-rede, conforme necessário. Possivelmente use VLANs. Espero que você esteja intimamente familiarizado com a CLI do seu fornecedor de dispositivos de rede preferido.

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, em seguida, CNAME serviços para o nome do host. Dessa forma, os serviços de migração não causam dores de cabeça com alterações no DNS. Ou pelo menos, não tantos. Também prefiro nomear servidores virtuais com av anexado ao nome do host.

Exemplos:

  • O novo servidor de banco de dados é chamado Athena. Será nomeado Athena para sempre.
  • O 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. Athena-ATL. Athena-Sydney. O que quer que funcione.
  • 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 apropriadas.

Manter. Isto. Simples. (mas funcional)


1
Athena é Atenas, que é uma cidade já ;-)
dmourati

+1: Amém no simples + funcional. Não pensei em uma política de negação padrão na sub-rede, então é algo que terei que incorporar. Não sou muito versado na CLI para o comutador de rede (Netgear), mas é algo que posso descobrir. Você usa sub-redes E VLANs ou apenas uma e não a outra? Quais devem ter precedência?
osij2is

Se eu pudesse te votar novamente, eu o faria. É exatamente por isso que estou fazendo esta pergunta aqui: " Projete a abstração nas coisas, o que parece não ser simples, mas na verdade é o caminho para a própria simplicidade ". É exatamente isso que estou buscando. Felizmente, você é mais eloquente e sucinto do que eu. ;)
osij2is

1
@ osij2is Eu não uso muito em sub-redes ou VLANs, já que sou principalmente um pequeno contratado de escritório. Eu preferiria usar VLANs, já que é exatamente isso que eu usei no passado. No entanto, estou disposto a ser acusado de síndrome do martelo. Quando tudo o que você tem é dot-one-q, tudo parece um problema de VLAN. Sim, uma camada de abstração é boa. Sempre. Duas camadas é uma toca de coelho. Três camadas é um sinal de abuso de LSD.
Wesley

1
@WesleyDavid - Re: Netgear, eles certamente não são a MELHOR escolha, mas o material "ProSafe" pode ser configurado para fazer 802.1Q (VLANs com tags). A implementação é compatível com os padrões, da melhor maneira que posso determinar: ela funciona bem com outros fornecedores e permite que você substitua os equipamentos Juniper ou Cisco posteriormente, conforme o tempo / o financiamento permitir. A desvantagem do material do Netgear é que ele é realmente mais voltado para a administração do navegador da Web do que o gerenciamento da CLI, o que atrasa um bom administrador da rede.
precisa saber é o seguinte

9

Eu trabalhei em uma organização de tamanho semelhante (tínhamos um / 26), que, por razões além de mim, considerava os poderes que um esquema de alocação de IP finamente refinado era fundamental para a integridade operacional. O gateway tinha que ser 0,1, as impressoras tinham que estar entre 0,2 e 0,12, os servidores entre 0,13 e 0,20 e assim por diante. Até mantivemos a documentação em hosts individuais.

Esta é uma enorme dor na bunda. Por mais diligente que fosse, nunca conseguia manter a documentação atualizada. Não ajudou que não tivéssemos nenhum serviço 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).

Para uma rede do seu tamanho, recomendo 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 mais tarde.

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

    2. Reserve os outros 30% para os endereços IP que você gerencia: servidores, impressoras, dispositivos de rede, serviços de teste. etc. USE DNS PARA DOCUMENTAR ISSO. Na minha opinião, não há perda de tempo maior do que estudar cuidadosamente todos esses endereços IP "gerenciados pelo administrador" (em oposição aos endereços IP gerenciados pelo DHCP) usando uma planilha do Excel (que você deve sempre consultar e manter) , quando você poderia fazer esse esforço para oferecer suporte a uma solução 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 sem uso. Uma pequena reserva nunca é demais.

    4. Ajuste as proporções como achar melhor para o seu ambiente. Alguns ambientes terão mais clientes, outros terão um "servidor" (ou seja, "gerenciado pelo administrador") pesado.


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

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

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

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

  • Servidores / desktops virtuais

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

  • VoIP

Uma rede fisicamente discreta seria ideal ... mas isso não é realista. A próxima melhor coisa seria uma VLAN e uma sub-rede separadas. Esse é o único ponto da pequena rede em que eu realmente sentiria a necessidade de segregar o tráfego (exceto itens publicamente acessíveis).


2
Palavras. Voto a favor. Oh espere, este não é o Reddit. Enfim, "resista à tentação de ser excessivamente esperto". Citado pela verdade!
21411 Wesley

5

Para alocações de IP

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

  • site é um local físico ou equivalente lógico (por exemplo, escritório de NY, escritório de NJ, instalação de recuperação de desastres, ambiente de desenvolvimento).
  • divisioné uma subdivisão lógica que faz sentido para você. por exemplo,
    0 => Switches / Roteadores
    1 => Administradores, 2 => Usuários
    3 => VOIP
    4 => Convidados
  • devices são dispositivos individuais (PCs, servidores, telefones, comutadores etc.)

A idéia aqui é que você pode determinar facilmente o que é um dispositivo e onde 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) é sua empresa. Cada local recebe uma classe B (/ 16) e cada divisão lógica em um local recebe uma classe C (/ 24) para seus dispositivos.
É possível (e algumas vezes desejável) usar algo maior que a / 24 para o nível "divisão", e você certamente pode fazê-lo: Qualquer coisa entre a / 17 e a / 24 geralmente é um jogo justo com esse esquema.


Para nomes DNS

Meu conselho é seguir um esquema semelhante à atribuição de IP que descrevi acima:

  • Tudo está enraizado em mycompany.com
  • Cada site (/ 16) possui seu próprio sitename.mycompany.comsubdomínio.
  • 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 administrador, usuário e convidado)
  • Os dispositivos devem ter nomes significativos. Por exemplo:
    • Nomeie os telefones para que você possa ver a extensão que eles tocam com base no nome DNS.
    • Nomeie estações de trabalho com base em seu usuário principal.
    • Identifique claramente os endereços IP "convidados".
    • Nomeie servidores para que você possa dizer o que são / o que fazem.
      Isso pode ser feito usando "chato" nomes ( www01, www02, db01, db02, mail, etc.) ou através da promulgação de um esquema de nomenclatura e aderindo a ela (por exemplo: servidores de correio são nomeados após rochas, servidores web são nomeados após árvores, servidores de banco de dados são nomeado após pintores).
      Nomes chatos são mais fáceis para uma nova pessoa aprender, esquemas de nomeação legais são mais divertidos. Faça sua escolha.

Notas diversas

Em relação aos servidores virtuais:
considere estes o mesmo como se fossem máquinas físicas (separe-os por divisão / objetivo, e não pelo fato de serem "virtuais". Tenha uma divisão separada para a rede Hypervisor / VM Administration.
Pode parecer importante agora para você saber se uma caixa é virtual ou física, mas quando o seu sistema de monitoramento disser "Ei, o email está inoperante!", a pergunta que você fará é: "Quais máquinas estão relacionadas ao email?", não "Quais máquinas estão virtual e que são física?".
Note que você nÃO precisa de uma maneira prática de identificar se uma máquina é virtual ou físico no caso de uma série hypervisor explode, mas este é um desafio para o sistema de monitoramento, não sua arquitetura de rede.

Em relação ao VOIP:
VOIP (asterisco em particular) é sinônimo de "Furo de segurança". Coloque todo o seu material VOIP em sua própria sub-rede e sua própria VLAN, e não deixe nada próximo a isso.
Todos os telefones VOIP que eu vi no ano passado são compatíveis com a segregação de VLAN (na verdade, todos eles oferecem suporte a VLANs de voz e de dados, para que você ainda possa usá-lo como passagem 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 no papel antes de começar a atribuir endereços e nomes DNS. De fato, desenhe-o a lápis em uma GRANDE folha de papel primeiro.
Cometer muitos erros.
Apague liberalmente.
Amaldiçoar fluentemente.
Depois que você parar 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 esse diagrama. Mantenha-o em sua santíssima correção ao adicionar e remover dispositivos, expandir sua organização e modificar 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.


Observe que eu suponho que você vá para o NAT - principalmente porque eu suponho que você deseja ter> 1 sites e deseja VPN entre eles.
precisa saber é o seguinte

+1: eu gosto do uso de octetos e da correlação com a localização (e / ou virtualização, como você mencionou). Isso pode ser expandido em diferentes divisões lógicas, mas a ideia faz muito sentido. Também para obter informações sobre VoIP.
osij2is

O octeto falha quando você tem mais de 200 dispositivos - pode ser limitado se você tiver 1000 pessoas em um escritório e todos eles tiverem telefones IP em suas mesas. Pequena ressalva que estar ciente de :-)
voretaq7

@ vortaq7: Eu assumi esse ponto, mas ainda é bom notar. De qualquer maneira, é bom usar o IP como uma maneira de organizar lógica e fisicamente as coisas. Além disso, um bom ponto de virtual versus físico é praticamente irrelevante. É bom ser organizado, mas a recompensa por essa separação é marginal, na melhor das hipóteses.
osij2is

@ osij2is - Virtual vs Físico é definitivamente relevante, acho que a infraestrutura de rede não é o lugar para gravá-la (ou, se necessário, faça-o com DNS criando registros A ou CNAME separados, como app01.hypervisor02.site.mycompany.com). Um sistema de monitoramento bem pensado e implementado é o segundo item essencial (depois da organização da rede) em qualquer ambiente de seu interesse.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.