Schémas créatifs IP / sous-réseau / DNS

Je n'ai administré que des réseaux plutôt petits (<= 25 nœuds). Habituellement, je mets la passerelle .1, dns / proxy comme .10, mail à .20, imprimantes à .30-39 et ainsi de suite et ainsi de suite. Je n'utilise jamais directement les adresses IP car les noms d'hôte DNS sont clairement la meilleure façon, mais j'aime avoir un modèle / une disposition / une conception claire lors de la construction d'un réseau à partir de zéro.

Mon mappage DNS a également un modèle / disposition de nommage simple. Par exemple, tous mes appareils ont deux noms; un nom formel basé sur le rôle (dc01, mail02, etc.) et un nom informel. Rien d'extraordinaire, mais vraiment simple et gérable.

J'essaie de trouver un schéma IP / sous-réseau / DNS plus intuitif / créatif (s'il y a quelque chose de mieux). Je suis sûr que d'autres ont des schémas plus intuitifs en fonction des objectifs du réseau et autres. Mon réseau sur lequel je travaille est encore petit, mais j'ai de nombreux appareils à gérer.

Je recherche un modèle ou une méthodologie générale pour attribuer une adresse IP (plages / classes), des noms DNS et des réseaux de sous-réseaux qui englobent 4-5 points principaux:

1. Services réseau (courrier, fichier, proxy, etc.)
2. Développement de logiciels (environnements - dev / staging / prod,
3. Médias (streaming, transferts de fichiers volumineux, archivage)
4. Serveurs / bureaux virtuels
5. VoIP

Je n'ai jamais travaillé directement avec la VoIP, mais c'est quelque chose à prendre en considération pour l'avenir.

Dans l'ensemble, j'ai eu de très bonnes idées de tout le monde. J'aimerais pouvoir donner plus de votes / réponses acceptées. Merci pour les réponses!

Rester simple. Aussi simple que possible, mais permettant toujours la sécurité et la flexibilité. Concevez l'abstraction en choses, ce qui ne semble pas être simple, mais en fait, c'est la voie de la simplicité elle-même.

Quant aux sous-réseaux, c'est assez courant:

• Utilisateurs sur un sous-réseau
• Invités sur un autre
• Serveurs sur leur propre sous-réseau
• VOIP seul aussi.

Filtrez le trafic via chaque sous-réseau si nécessaire. Utilisez éventuellement des VLAN. J'espère que vous connaissez intimement la CLI de votre fournisseur de périphériques réseau de choix.

Quant au DNS, vous n'aimerez pas ça mais ... utilisez ce qui vous convient. Personnellement, j'aime donner aux serveurs un nom d'hôte totalement abstrait sans aucun lien avec ses services. J'ai ensuite CNAME services au nom d'hôte. De cette façon, la migration des services ne provoque pas de maux de tête de changement DNS. Ou du moins, pas autant. Je préfère également nommer les serveurs virtuels avec av ajouté au nom d'hôte.

Exemples:

• Le nouveau serveur de base de données s'appelle Athena. Il sera nommé Athéna pour toujours.
• Athena est CNAMED pour ce qu'elle fait: SQL08ENT-CRM, SQL08ENT-AEGIS (le système de sécurité), SQL08ENT-DOCMAN. Peut-être aussi CNAMED basé sur la géographie. Ou peut-être que le nom d'hôte contiendra de la géographie. Athena-ATL. Athéna-Sydney. Tout ce qui fonctionne.
• Le serveur se trouve sur le sous-réseau du serveur qui a une stratégie de refus par défaut. Il a le trafic approprié inclus dans les sous-réseaux appropriés.

Garder. Il. Facile. (mais fonctionnel)

J'ai travaillé dans une organisation de taille similaire (nous avions un / 26), qui pour des raisons indépendantes de moi, les pouvoirs en place estimaient qu'un schéma d'attribution de propriété intellectuelle finement défini était primordial pour l'intégrité opérationnelle. La passerelle devait être .1, les imprimantes devaient être entre .2 et .12, les serveurs entre .13 et .20 et ainsi de suite. Nous avons même conservé de la documentation sur des hôtes individuels.

C'est une énorme douleur dans le cul. Peu importe à quel point j'étais diligent, je n'arrivais jamais à tenir à jour les documents. Cela ne nous a pas aidé de ne pas avoir de services DNS, donc l'utilisation de cette documentation sur le schéma d'allocation IP était le seul service de «nommage» que nous avions (ce qui, d'une manière étrange, le rendait plus indispensable qu'il ne l'était vraiment).

Pour un réseau de votre taille, je recommanderais quelques choses (dont la plupart vous avez déjà fait):

• Simple - Vous ne gérez pas des centaines d'hôtes. La complexité de votre solution doit refléter la complexité de l'environnement. Résistez à la tentation d'être trop intelligent. Vous vous remercierez plus tard.

  1. Prenez votre espace IP disponible et donnez 60% à vos clients via DHCP. Configurez des services DNS dynamiques afin de ne plus jamais avoir à regarder une putain d'adresse IP. Oubliez de garder une trace d'eux. Profit.

  2. Réservez les 30% restants pour les adresses IP que vous gérez: serveurs, imprimantes, périphériques réseau, services de test. etc. UTILISEZ DNS POUR DOCUMENTER CELA. À mon avis, il n'y a pas de plus grande perte de temps que de suivre attentivement toutes ces adresses IP "gérées par l'administrateur" (par opposition aux adresses IP gérées par DHCP) en utilisant une feuille de calcul Excel (que vous devez constamment consulter et maintenir) , alors que vous pourriez faire cet effort pour prendre en charge une solution DNS auto-documentée et beaucoup plus utile.

  3. Gardez les 10% restants de votre adresse en haut de votre espace d'adressage IP inutilisés. Une petite réserve ne fait jamais de mal.

  4. Ajustez les ratios comme bon vous semble pour votre environnement. Certains environnements auront plus de clients, d'autres seront lourds sur le "serveur" (c'est-à-dire "gérés par l'administrateur").

• Services réseau (courrier, fichier, proxy, etc.)
• Développement de logiciels (environnements - dev / staging / prod,

Ces deux éléments entrent dans la catégorie des espaces IP "gérés par l'administrateur".

• Médias (streaming, transferts de fichiers volumineux, archivage)

À mon avis, cela a peu à voir avec le sous-réseau et tout à voir avec la surveillance du réseau.

• Serveurs / bureaux virtuels

Les serveurs sont "gérés par l'administrateur", les postes de travail (c'est-à-dire les machines clientes) doivent être "gérés par DHCP".

• VoIP

Un réseau physiquement discret serait idéal ... mais ce n'est pas réaliste. La prochaine meilleure chose serait un VLAN et un sous-réseau séparés. Il s'agit du seul point dans un petit réseau où je ressentirais vraiment le besoin de séparer le trafic (sauf pour les choses accessibles au public).

Pour les attributions IP

Mon conseil est de tout placer sous le sous-réseau 10.0.0.0/8, en utilisant la structure suivante: 10 site.. division.device

• site est un emplacement physique ou un équivalent logique (par exemple, bureau NY, bureau NJ, installation DR, environnement de développement).
• divisionest une subdivision logique qui a du sens pour vous. par exemple
  0 => Commutateurs / Routeurs
  1 => Administrateurs, 2 => Utilisateurs
  3 => VOIP
  4 => Invités
• devices sont des appareils individuels (PC, serveurs, téléphones, commutateurs, etc.)

L'idée ici est que vous pouvez facilement déterminer ce qu'est un appareil et où il se trouve par son adresse: 10.2.1.100 est le poste de travail d'un administrateur sur "Site # 2".

Ce modèle est dérivé des attributions IP basées sur les classes: la classe A (/ 8) est votre entreprise. Chaque emplacement obtient une classe B (/ 16), et chaque division logique à un emplacement obtient une classe C (/ 24) pour leurs appareils.
Il est possible (et parfois souhaitable) d'utiliser quelque chose de plus grand qu'un / 24 pour le niveau "division", et vous pouvez certainement le faire: tout ce qui va de / 17 à a / 24 est généralement un jeu équitable avec ce schéma.

Pour les noms DNS

Mon conseil est de suivre un schéma similaire à l'attribution IP que j'ai décrit ci-dessus:

• Tout est enraciné dans mycompany.com
• Chaque site (/ 16) possède son propre sitename.mycompany.comsous-domaine.
• Les divisions logiques peuvent avoir un (ou plusieurs) sous-domaines au sein du site, par exemple:
  • voip.mycompany.com(avec des appareils comme tel0000.voip.mycompany.com, tel0001.voip.mycompany.com, etc.)
  • switches.mycompany.com
  • workstations.mycompany.com (éventuellement subdivisé en admin, utilisateur et invité)
• Les appareils doivent avoir des noms significatifs. Par exemple:
  • Nommez les téléphones afin que vous puissiez voir l'extension qu'ils sonnent en fonction du nom DNS.
  • Nommez les postes de travail en fonction de leur utilisateur principal.
  • Identifiez clairement les adresses IP «invitées».
  • Serveurs de noms pour que vous puissiez dire ce qu'ils sont / ce qu'ils font.
    Ceci peut être accompli en utilisant « ennuyeux » noms ( www01, www02, db01, db02, mail, etc.) ou en promulguant un schéma de nommage et de s'y tenir (par exemple: Les serveurs de messagerie sont nommés d' après les roches, les serveurs Web sont nommés d' après les arbres, les serveurs de base de données sont du nom de peintres).
    Les noms ennuyeux sont plus faciles à apprendre pour une nouvelle personne, les schémas de nommage sympas sont plus amusants. Faites votre choix.

Notes diverses

En ce qui concerne les serveurs virtuels:
considérez-les comme s'ils étaient des machines physiques (séparez-les par division / objectif plutôt que par le fait qu'ils sont "virtuels". Ayez une division distincte pour le réseau d'administration de l'hyperviseur / VM.
Cela peut sembler important à vous maintenant de savoir si une boîte est virtuelle ou physique, mais lorsque votre système de surveillance dit "Hé, le courrier électronique est en panne!", la question que vous poserez est "Quelles sont les machines liées au courrier électronique?", et non "Quelles machines sont virtuel et qui sont physiques? ».
Notez que vous N'ÊTES besoin d' un moyen pratique d'identifier si une machine est virtuelle ou physique dans le cas où un hôte hyperviseur explose, mais cela est un défi pour votre système de surveillance, pas votre architecture réseau.

Concernant VOIP:
VOIP (astérisque en particulier) est synonyme de "Security Hole". Poussez tous vos trucs VOIP sur son propre sous-réseau et son propre VLAN, et ne le laissez pas près de quelque chose de sensible.
Chaque téléphone VOIP que j'ai vu l'année dernière prend en charge la ségrégation VLAN (en fait, ils prennent tous en charge les VLAN voix et données, vous pouvez donc toujours utiliser le téléphone comme passe-système pour les connexions Ethernet de bureau). Profitez-en - Vous serez heureux de l'avoir fait si / quand votre environnement VOIP est piraté.

Concernant la planification et la documentation:
dessinez votre réseau sur papier avant de commencer à attribuer des adresses et des noms DNS. En fait, dessinez-le d'abord au crayon sur une GRANDE feuille de papier.
Faites beaucoup d'erreurs.
Effacez généreusement.
Malédiction couramment.
Une fois que vous arrêtez de maudire et d'effacer pendant au moins 10 jours, il est temps de mettre le diagramme en Visio / Graffle / Un autre format électronique comme diagramme de réseau officiel. Protégez ce diagramme. Conservez-le dans sa plus grande exactitude lorsque vous ajoutez et supprimez des périphériques, développez votre organisation et modifiez la structure de votre réseau.
Ce diagramme de réseau sera votre meilleur ami lorsque vous devrez apporter des modifications, expliquer le réseau à de nouveaux administrateurs ou résoudre un mystérieux échec.