Programmes Creative IP / subnet / dns

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

Mon mappage DNS a également un modèle / mise en page 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 de chic, mais réel, 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 selon les objectifs du réseau et ceux-ci. Mon réseau sur lequel je travaille est encore petit, mais j'ai de nombreux appareils à affronter.

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

  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 virtuels / ordinateurs de bureau
  5. VoIP

Je n'ai jamais travaillé directement avec 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 tous. J'aimerais pouvoir donner plus de votes / réponses acceptées. Merci pour les réponses!

3 Solutions collect form web for “Programmes Creative IP / subnet / dns”

Rester simple. Le plus simple possible, tout en permettant la sécurité et la flexibilité. Concevez l'abstraction dans les choses, ce qui semble être simple, mais en fait, c'est la voie de la simplicité elle-même.

En ce qui concerne les sous-réseaux, c'est assez commun:

  • Utilisateurs sur un sous-réseau
  • Invités sur un autre
  • Les serveurs sur leur propre sous-réseau
  • VOIP à lui seul.

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

En ce qui concerne DNS, vous n'aimerez pas cela, mais … utilisez quoi que ce soit pour vous. Personnellement, j'aime donner aux serveurs un nom d'hôte totalement abstrait sans lien avec ses services. J'ai alors les services CNAME au nom d'hôte. De cette façon, les services de migration ne provoquent pas de maux de tête de changement de DNS. Ou du moins, pas autant. Je préfère également nommer des serveurs virtuels avec av précédé le nom d'hôte.

Exemples:

  • Le nouveau serveur de base de données s'appelle Athena. Ce sera Athena pour toujours.
  • Athena est CNAMED pour ce qu'il fait: SQL08ENT-CRM, SQL08ENT-AEGIS (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 aura une géographie. Athena-ATL. Athena-Sydney. Tout ce qui fonctionne.
  • Le serveur se trouve sur le sous-réseau du serveur qui a une politique de refus par défaut. Il comporte le trafic approprié qui provient des sous-réseaux appropriés.

Garder. Il. Simple. (Mais fonctionnel)

J'ai travaillé dans une organisation d'une taille similaire (nous avons eu un / 26), pour des raisons qui m'ont dépassé, les pouvoirs qui prétendent qu'un système d'allocation de propriété intellectuelle finement primé était primordial pour l'intégrité opérationnelle. La passerelle devait être .1, les imprimantes devaient être entre 0,2 et 0,12, les serveurs entre 0,13 et 0,20 et ainsi de suite. Nous avons même conservé la documentation sur les hôtes individuels.

C'est une énorme souffrance dans le cul. Quel que soit le degré de diligence nécessaire, je ne pourrais jamais conserver la documentation actuelle. Il n'a pas aidé que nous n'avions aucun service DNS, donc l'utilisation de cette documentation sur le schéma de répartition de l'IP était le seul service "nommant" 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 vous recommanderais quelques éléments (la plupart de ceux que vous avez déjà fait):

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

    1. Prenez votre espace IP disponible et donnez 60% à vos clients via DHCP. Installez des services DNS dynamiques de sorte que vous ne deviez jamais regarder une adresse IP damn à nouveau. Oubliez de les suivre. Profit.

    2. Réservez l'autre 30% pour les adresses IP que vous gérez: serveurs, imprimantes, périphériques réseau, services de test. Etc. UTILISEZ LE DNS POUR DOCUMENT CE. À mon avis, il n'y a pas plus de perte de temps que de suivre attentivement toutes ces adresses IP "administrées par l'administrateur" (par opposition aux adresses IP gérées par DHCP) en utilisant une feuille de calcul Excel (à laquelle vous devez vous référer et conserver constamment) , Lorsque vous pourriez mettre cet effort dans le soutien d'une solution de DNS auto-documentant et beaucoup plus utile.

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

    4. Ajustez les ratios que vous jugez bon pour votre environnement. Certains environnements auront plus de clients, certains seront «serveurs» (c'est-à-dire «gérés par l'administrateur») lourds.


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

Ceux-ci entrent tous deux dans la catégorie de l'espace IP «géré par l'administrateur».

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

À mon avis, cela a peu à voir avec les sous-réseaux et tout ce qui concerne la surveillance du réseau.

  • Serveurs virtuels / ordinateurs de bureau

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

  • VoIP

Un réseau physiquement discret serait idéal … mais c'est irréaliste. La prochaine meilleure chose serait un VLAN et un sous-réseau séparés. Il s'agit du seul point dans le petit réseau où je ressens vraiment la nécessité de séparer le trafic (à l'exception des objets publiquement accessibles).

Pour les allocations IP

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

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

L'idée ici est que vous pouvez déterminer facilement quel est un périphérique et où il se trouve par son adresse: 10.2.1.100 est un poste de travail de l'administrateur sur "Site # 2".

Ce modèle est dérivé des attributions IP class-based: la classe A (/ 8) est votre entreprise. Chaque emplacement reçoit 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 que a / 24 pour le niveau "division", et vous pouvez certainement le faire: Tout de un / 17 à un / 24 est généralement un jeu équitable avec ce schéma.


Pour les noms DNS

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

  • Tout est enraciné sur mycompany.com
  • Chaque site (/ 16) a son propre sous-domaine sitename.mycompany.com .
  • Les divisions logiques peuvent avoir un (ou plusieurs) sous-domaines dans le site, par exemple:
    • voip.mycompany.com (avec des appareils tels que tel0000.voip.mycompany.com , tel0001.voip.mycompany.com , etc.)
    • switches.mycompany.com
    • workstations.mycompany.com (éventuellement subdivisé en administrateur, utilisateur et invité)
  • Les appareils devraient avoir des noms significatifs. Par exemple:
    • Nommez les téléphones afin que vous puissiez voir l'extension qu'ils interférent en fonction du nom DNS.
    • Nommez les stations de travail en fonction de leur principal utilisateur.
    • Indiquez clairement les adresses IP "invité".
    • Serveurs de noms afin que vous puissiez dire ce qu'ils sont / ce qu'ils font.
      Cela peut être réalisé en utilisant des noms "ennuyeux" ( www01 , www02 , db01 , db02 , mail , etc.) ou en promulguant un schéma de dénomination et en adhérant (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 nommés d'après les peintres).
      Les noms ennuyeux sont plus faciles à apprendre à une nouvelle personne, les modèles de dénomination cool sont plus amusants. Faites votre choix.

Notes diverses

En ce qui concerne les serveurs virtuels:
Considérez-les comme s'il s'agissait de machines physiques (séparez-les par division / but plutôt que par le fait qu'ils sont «virtuels». Avoir une division distincte pour le réseau Hypervisor / VM Administration.
Il peut sembler important pour vous maintenant de savoir si une boîte est virtuelle ou physique, mais lorsque votre système de surveillance indique "Hé, le courrier électronique est en panne!" La question que vous poserez est: «Quelles machines sont liées au courrier électronique?», Non «Quelles machines sont virtuelles et physiques?».
Notez que vous avez besoin d'un moyen pratique d'identifier si une machine est virtuelle ou physique dans le cas où un hôte hyperviseur souffle, mais c'est un défi pour votre système de surveillance et non votre architecture de réseau.

En ce qui concerne VOIP:
VOIP (astérisque en particulier) est synonyme de "Trou de sécurité". Retirez tous vos produits 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 au cours de la dernière année prend en charge la ségrégation VLAN (en fait, ils prennent en charge tous les VLAN voix et données, de sorte que vous pouvez toujours utiliser le téléphone comme passerelle pour les connexions Ethernet de bureau). Profitez de cela – Vous serez heureux que vous ayez fait ou si 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 au crayon sur une grande feuille de papier d'abord.
Faites beaucoup d'erreurs.
Effacez généreusement.
Curse couramment.
Une fois que vous arrêtez de maudire et d'effacer pendant au moins 10 jours, il est temps de placer le diagramme dans Visio / Graffle / Un autre format électronique comme diagramme de votre réseau officiel. Sauvegarde ce diagramme. Maintenez-le dans sa plus grande précision en ajoutant et en supprimant des périphériques, développez votre organisation et modifiez votre structure de réseau.
Ce schéma de réseau sera votre meilleur ami lorsque vous devez apporter des modifications, expliquer le réseau à de nouveaux administrateurs ou dépanner un échec mystérieux.

  • Dans quels scénarios un VLAN n'allumerait-il pas 1: 1 avec un sous-réseau?
  • Confusion sur l'input VHost et DNS concernant la configuration du sous-domaine (Apache)
  • Apache2 dynamic-mapotot selon l'URL
  • Les sous-domaines ne prennent pas effet sur CentOS
  • Obtenir 403 - Interdit lors de la création d'un sous-domaine
  • Configuration d'un sous-domaine avec IIS 7
  • Où puis-je mettre mon application Web de sorte qu'elle soit privée par défaut mais accessible par sous-domaines?
  • créer des sous-domaines uniquement via un file php?
  • linux, mise en réseau, configuration du sous-réseau
  • Comment éviter les sous-domaines OpenShift mis en cache par Google?
  • Apache: comment créer un sous-domaine sur l'hôte virtuel basé sur le nom?
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.