Esquemas creativos de IP / subred / dns

Solo he administrado redes bastante pequeñas (<= 25 nodos). Por lo general, pongo la puerta de enlace .1, dns / proxy como .10, correo a .20, impresoras a .30-39 y así sucesivamente. Nunca uso directamente las direcciones IP, ya que los nombres de host DNS son claramente la mejor manera, pero me gusta tener un patrón / diseño / diseño claro cuando construyo una red desde cero.

Mi mapeo DNS también tiene un patrón / diseño de nombres simple. Por ejemplo, todos mis dispositivos tienen dos nombres; un nombre formal basado en el rol (dc01, mail02, etc.) y un nombre informal. Nada lujoso, pero realmente simple y manejable.

Estoy tratando de descubrir un esquema de IP / subred / DNS más intuitivo / creativo (si hay algo mejor). Estoy seguro de que otros tienen esquemas más intuitivos dependiendo de los objetivos de la red y tal. Mi red en la que estoy trabajando todavía es pequeña, pero tengo numerosos dispositivos con los que lidiar.

Estoy buscando un patrón o metodología general para asignar direcciones IP (rangos / clases), nombres DNS y redes de subred que abarque 4-5 puntos principales:

1. Servicios de red (correo, archivo, proxy, etc.)
2. Desarrollo de software (entornos - dev / staging / prod,
3. Medios (transmisión, transferencias de archivos grandes, archivo)
4. Servidores virtuales / escritorios
5. VoIP

Nunca he trabajado directamente con VoIP, pero es algo a tener en cuenta para el futuro.

En general, obtuve algunas ideas realmente buenas de todos. Ojalá pudiera dar más votos / respuestas aceptadas. Gracias por las respuestas!

Mantenlo simple. Lo más simple posible, pero aún permitiendo seguridad y flexibilidad. Diseñe la abstracción en las cosas, lo que parece que no es simple, pero de hecho es el camino hacia la simplicidad misma.

En cuanto a las subredes, esto es bastante común:

• Usuarios en una subred
• Invitados en otro
• Servidores en su propia subred
• VOIP por su cuenta también.

Filtre el tráfico a través de cada subred según sea necesario. Posiblemente use VLAN. Espero que esté íntimamente familiarizado con la CLI de su proveedor de dispositivos de red elegido.

En cuanto a DNS, no te va a gustar esto, pero ... usa lo que funcione para ti. Personalmente, me gusta dar a los servidores un nombre de host totalmente abstracto sin vínculos con sus servicios. Entonces CNAME servicios al nombre de host. De esa forma, la migración de servicios no causa dolores de cabeza de cambio de DNS. O al menos, no tantos. También prefiero nombrar servidores virtuales con av antepuesto al nombre de host.

Ejemplos:

• El nuevo servidor de base de datos se llama Athena. Se llamará Atenea para siempre.
• Athena es CNAMED por lo que hace: SQL08ENT-CRM, SQL08ENT-AEGIS (el sistema de seguridad), SQL08ENT-DOCMAN. Quizás también CNAMED basado en la geografía. O tal vez el nombre de host tendrá geografía. Atenea-ATL. Atenea-Sydney. Lo que sea que funcione.
• El servidor está en la subred del servidor que tiene una política de rechazo predeterminada. Tiene el tráfico adecuado incluido desde las subredes adecuadas.

Mantener. Eso. Simple. (pero funcional)

Trabajé en una organización de un tamaño similar (teníamos un / 26), que por razones ajenas a mí, los poderes fácticos consideraban que un esquema de asignación de IP finamente definido era primordial para la integridad operativa. La puerta de enlace tenía que ser .1, las impresoras tenían que estar entre .2 y .12, los servidores entre .13 y .20 y así sucesivamente. Incluso guardamos documentación en hosts individuales.

Este es un gran dolor en el culo. No importa cuán diligente sea, nunca podría mantener una documentación actualizada. No ayudó que no tuviéramos ningún servicio de DNS, por lo que usar esta documentación del esquema de asignación de IP fue el único servicio de "nomenclatura" que teníamos (lo que, de una manera extraña, lo hizo parecer más indispensable de lo que realmente era).

Para una red de su tamaño, recomendaría algunas cosas (la mayoría de las cuales ya ha hecho):

• Simple : no está administrando cientos de hosts. La complejidad de su solución debe reflejar la complejidad del entorno. Resista la tentación de ser demasiado inteligente. Te lo agradecerás más tarde.

  1. Aproveche su espacio IP disponible y otorgue el 60% a sus clientes a través de DHCP. Configure algunos servicios DNS dinámicos para que nunca más tenga que mirar una maldita dirección IP. Olvídate de seguirles la pista. Lucro.

  2. Reserve el otro 30% para las direcciones IP que administra: servidores, impresoras, dispositivos de red, servicios de prueba. etc. UTILICE DNS PARA DOCUMENTAR ESTO. En mi opinión, no hay mayor pérdida de tiempo que realizar un seguimiento cuidadoso de todas estas direcciones IP "administradas por el administrador" (a diferencia de las direcciones IP administradas por DHCP) mediante el uso de una hoja de cálculo de Excel (que debe consultar y mantener constantemente) , cuando podría dedicar ese esfuerzo a respaldar una solución de DNS autodocumentada y mucho más útil.

  3. Mantenga el último 10% de su dirección en la parte superior de su espacio de direccionamiento IP sin usar. Una pequeña reserva nunca está de más.

  4. Ajuste las proporciones como mejor le parezca a su entorno. Algunos entornos tendrán más clientes, otros serán "servidores" (es decir, "administrados por el administrador") pesados.

• Servicios de red (correo, archivo, proxy, etc.)
• Desarrollo de software (entornos - dev / staging / prod,

Ambos entran en la categoría de espacio IP "administrado por el administrador".

• Medios (transmisión, transferencias de archivos grandes, archivo)

En mi opinión, esto tiene poco que ver con las subredes y todo con la supervisión de la red.

• Servidores virtuales / escritorios

Los servidores son "administrados por el administrador", los escritorios (es decir, máquinas cliente) deben ser "administrados por DHCP".

• VoIP

Una red físicamente discreta sería ideal ... pero eso no es realista. La siguiente mejor opción sería una VLAN y una subred separadas. Este es el único punto en una red pequeña en la que realmente sentiría la necesidad de segregar el tráfico (a excepción de las cosas que son de acceso público).

Para asignaciones de IP

Mi consejo es colocar todo bajo la subred 10.0.0.0/8, usando la siguiente estructura: 10 site.. division.device

• site es una ubicación física o equivalente lógico (por ejemplo, oficina de Nueva York, oficina de Nueva Jersey, instalación de recuperación ante desastres, entorno de desarrollo).
• divisiones una subdivisión lógica que tiene sentido para ti. por ejemplo,
  0 => Interruptores / Enrutadores
  1 => Administradores, 2 => Usuarios
  3 => VOIP
  4 => Invitados
• devices son dispositivos individuales (PC, servidores, teléfonos, conmutadores, etc.)

La idea aquí es que puede determinar fácilmente qué es un dispositivo y dónde está por su dirección: 10.2.1.100 es una estación de trabajo de administrador en el "Sitio # 2".

Este modelo se deriva de las asignaciones de IP basadas en clases: la clase A (/ 8) es su empresa. Cada ubicación obtiene una Clase B (/ 16), y cada división lógica en una ubicación obtiene una Clase C (/ 24) para sus dispositivos.
Es posible (y a veces deseable) usar algo más grande que un / 24 para el nivel de "división", y ciertamente puede hacerlo: cualquier cosa desde un / 17 a un / 24 es generalmente un juego justo con este esquema.

Para nombres DNS

Mi consejo es seguir un esquema similar a la asignación de IP que describí anteriormente:

• Todo está arraigado en mycompany.com
• Cada sitio (/ 16) tiene su propio sitename.mycompany.comsubdominio.
• Las divisiones lógicas pueden tener uno (o más) subdominios dentro del sitio, por ejemplo:
  • voip.mycompany.com(con dispositivos como tel0000.voip.mycompany.com, tel0001.voip.mycompany.com, etc.)
  • switches.mycompany.com
  • workstations.mycompany.com (posiblemente subdividido en administrador, usuario e invitado)
• Los dispositivos deben tener nombres significativos. Por ejemplo:
  • Nombra los teléfonos para que puedas ver la extensión que suenan en función del nombre DNS.
  • Nombre las estaciones de trabajo en función de su usuario principal.
  • Identifique claramente las direcciones IP "invitadas".
  • Servidores de nombres para que pueda saber qué son / qué hacen.
    Esto se puede lograr mediante el uso de "aburrido" nombres ( www01, www02, db01, db02, mail, etc.) o mediante la promulgación de un esquema de nombres y ajustarse a él (por ejemplo: Los servidores de correo tienen el nombre de rocas, los servidores web tienen nombres de árboles, servidores de bases de datos son llamado así por los pintores).
    Los nombres aburridos son más fáciles de aprender para una persona nueva, los esquemas de nombres geniales son más divertidos. Elige tu opción.

Notas misceláneas

Con respecto a los servidores virtuales:
considérelos igual que si fueran máquinas físicas (segregarlos por división / propósito en lugar de por el hecho de que son "virtuales". Tenga una división separada para la red de administración de hipervisor / VM.
Puede parecer importante ahora para saber si un cuadro es virtual o físico, pero cuando su sistema de monitoreo dice "¡Hola, el correo electrónico está inactivo!", la pregunta que se hará es "¿Qué máquinas están relacionadas con el correo electrónico?", no "¿Qué máquinas están ¿virtual y cuáles son físicos? ".
Tenga en cuenta que SI necesita una forma práctica de identificar si una máquina es virtual o física en caso de que un host hipervisor explote, pero esto es un desafío para su sistema de monitoreo, no para su arquitectura de red.

Con respecto a VOIP:
VOIP (asterisco en particular) es sinónimo de "agujero de seguridad". Empuje todas sus cosas VOIP en su propia subred y su propia VLAN, y no permita que se acerque a nada sensible.
Todos los teléfonos VOIP que he visto en el último año son compatibles con la segregación de VLAN (de hecho, todos son compatibles con VLAN de voz y datos, por lo que aún puede usar el teléfono como una conexión directa para las conexiones de Ethernet de escritorio). Aproveche esto: se alegrará de haberlo hecho cuando su entorno VOIP sea pirateado.

Con respecto a la planificación y la documentación:
dibuje su red en papel antes de comenzar a asignar direcciones y nombres DNS. De hecho, primero dibuje con lápiz en una GRAN hoja de papel.
Comete muchos errores.
Borrar generosamente.
Maldecir con fluidez.
Una vez que deje de maldecir y borrar durante al menos 10 días, es hora de poner el diagrama en Visio / Graffle / Algún otro formato electrónico como su diagrama de red oficial. Salvaguarde este diagrama. Manténgalo en su Sagrada Corrección a medida que agrega y elimina dispositivos, hace crecer su organización y modifica la estructura de su red.
Este diagrama de red será tu mejor amigo cuando tengas que hacer cambios, explicar la red a los nuevos administradores o solucionar una falla misteriosa.