Креатив IP / подсеть / днс схемы

Я управлял только небольшими сетями (<= 25 узлов). Обычно я ставлю шлюз .1, dns / proxy как .10, почту в .20, принтеры в .30-39 и так далее и так далее. Я никогда напрямую не использую IP-адреса, так как имена хостов DNS явно лучше, но мне нравится иметь четкий шаблон / макет / дизайн при создании сети с нуля.

Мое сопоставление DNS также имеет простой шаблон именования. Например, все мои устройства имеют два имени; одно формальное имя, основанное на роли (dc01, mail02 и т. д.) и неформальное имя. Ничего особенного, но очень просто и легко.

Я пытаюсь найти более интуитивную / креативную схему IP / подсети / DNS (если есть что-то лучше). Я уверен, что другие имеют более интуитивные схемы в зависимости от целей сети и тому подобное. Моя сеть, над которой я работаю, все еще мала, но у меня есть множество устройств, с которыми приходится бороться.

Я ищу общий шаблон или методологию для назначения IP-адресов (диапазонов / классов), DNS-имен и сетей подсетей, которая охватывает 4-5 основных пунктов:

1. Сетевые сервисы (почта, файл, прокси и т. Д.)
2. Разработка программного обеспечения (среды - dev / staging / prod,
3. Медиа (потоковая передача, передача больших файлов, архивирование)
4. Виртуальные серверы / рабочие столы
5. VoIP

Я никогда не работал напрямую с VoIP, но это нужно учитывать в будущем.

В целом я получил несколько действительно хороших идей от всех. Хотел бы я выдать больше голосов / принятых ответов. Спасибо за ответы!

Будь проще. Как можно проще, но все же с учетом безопасности и гибкости. Создайте абстракцию в вещах, что звучит так, будто это не просто, но на самом деле это путь к самой простоте.

Что касается подсетей, это довольно распространено:

• Пользователи в одной подсети
• Гости по другому
• Серверы в своей подсети
• VOIP тоже сам по себе.

Фильтруйте трафик через каждую подсеть по мере необходимости. Возможно использовать VLAN. Я надеюсь, что вы хорошо знакомы с интерфейсом командной строки выбранного поставщика сетевых устройств.

Что касается DNS, вам это не понравится, но ... используйте то, что вам подходит. Лично мне нравится давать серверам абсолютно абстрактное имя хоста без привязки к его сервисам. Затем я CNAME службы для имени хоста. Таким образом, миграция служб не вызывает головной боли при изменении DNS. Или, по крайней мере, не так много. Я также предпочитаю называть виртуальные серверы с добавлением av к имени хоста.

Примеры:

• Новый сервер базы данных называется Athena. Он будет называться Афина навсегда.
• Афина CNAMED за то, что она делает: SQL08ENT-CRM, SQL08ENT-AEGIS (система безопасности), SQL08ENT-DOCMAN. Возможно также CNAMED, основанный на географии. Или, возможно, имя хоста будет иметь географию. Афина-АТЛ. Афина-Сидней. Что бы ни работало.
• Сервер находится в подсети сервера, для которой действует политика запрета по умолчанию. В него включен правильный трафик из соответствующих подсетей.

Держать. Это. Просто. (но функционально)

Я работал в организации такого же размера (у нас было / 26), что по не зависящим от меня причинам было очевидно, что детальная схема распределения IP имеет первостепенное значение для эксплуатационной целостности. Шлюз должен быть .1, принтеры должны быть между .2 и .12, серверы между .13 и .20 и так далее. Мы даже хранили документацию на отдельных хостах.

Это огромная боль в заднице. Независимо от того, насколько усердным я был, я никогда не мог поддерживать актуальность документации. Не помогло то, что у нас не было никаких DNS-сервисов, поэтому использование документации по схеме распределения IP-адресов было единственной услугой по «именованию», которая была у нас (что странным образом делало ее более необходимой, чем на самом деле).

Для сети вашего размера я бы рекомендовал несколько вещей (большинство из которых вы уже сделали):

• Просто - вы не управляете сотнями хостов. Сложность вашего решения должна отражать сложность среды. Не поддавайтесь искушению быть слишком умным. Вы будете благодарить себя позже.

  1. Займите свое доступное пространство IP и дайте 60% своим клиентам через DHCP. Настройте некоторые динамические службы DNS, чтобы вам больше никогда не приходилось смотреть на проклятый IP-адрес. Забудьте о отслеживании их. Прибыль.

  2. Зарезервируйте остальные 30% для IP-адресов, которыми вы управляете: серверы, принтеры, сетевые устройства, службы тестирования. и т.д. ИСПОЛЬЗУЙТЕ DNS ДЛЯ ДОКУМЕНТАЦИИ. На мой взгляд, нет большей траты времени, чем старательно отслеживать все эти «управляемые администратором» IP-адреса (в отличие от управляемых IP-адресов DHCP) с помощью электронной таблицы Excel (к которой вы должны постоянно обращаться и поддерживать) когда вы могли бы приложить эти усилия для поддержки самодокументируемого и гораздо более полезного решения DNS.

  3. Оставьте последние 10% своего адреса в верхней части своего пространства IP-адресов неиспользованными. Небольшой запас никогда не болит.

  4. Отрегулируйте соотношения так, как считаете нужным для вашей среды. В некоторых средах будет больше клиентов, а некоторые будут «серверными» (то есть «управляемыми администратором»).

• Сетевые сервисы (почта, файл, прокси и т. Д.)
• Разработка программного обеспечения (среды - dev / staging / prod,

Оба они попадают в категорию «управляемого администратором» IP-пространства.

• Медиа (потоковая передача, передача больших файлов, архивирование)

На мой взгляд, это не имеет ничего общего с подсетями и все, что связано с мониторингом сети.

• Виртуальные серверы / рабочие столы

Серверы управляются администратором, рабочие столы (то есть клиентские машины) должны управляться DHCP.

• VoIP

Физически дискретная сеть была бы идеальной ... но это нереально. Следующей лучшей вещью будет отдельная VLAN и подсеть. Это почти единственная точка в небольшой сети, где я действительно чувствую необходимость разделять трафик (за исключением общедоступных).

Для распределения IP

Мой совет - поместить все в подсеть 10.0.0.0/8, используя следующую структуру: 10 site.. division,device

• site является физическим местоположением или логическим эквивалентом (например, офис в Нью-Йорке, офис в Нью-Джерси, объект DR, среда разработки).
• divisionлогическое подразделение, которое имеет смысл для вас. например,
  0 => Коммутаторы / Маршрутизаторы
  1 => Администраторы, 2 => Пользователи
  3 => VOIP
  4 => Гости
• deviceЭто отдельные устройства (ПК, серверы, телефоны, коммутаторы и т. д.)

Идея заключается в том, что вы можете легко определить, что это за устройство и где оно находится по его адресу: 10.2.1.100 - рабочая станция администратора на «сайте № 2».

Эта модель основана на присвоении IP-адресов на основе классов: класс A (/ 8) является вашим предприятием. Каждое местоположение получает класс B (/ 16), а каждое логическое подразделение в местоположении получает класс C (/ 24) для своих устройств.
Можно (и иногда желательно) использовать что-то большее, чем / 24, для уровня «деления», и вы, безусловно, можете сделать это: все, от / 17 до / 24, как правило, является честной игрой с этой схемой.

Для DNS-имен

Мой совет заключается в том, чтобы следовать схеме, аналогичной назначению IP, которое я описал выше:

• Все коренится в mycompany.com
• Каждый сайт (/ 16) имеет свой собственный sitename.mycompany.comподдомен.
• Логические подразделения могут иметь один (или несколько) поддоменов на сайте, например:
  • voip.mycompany.com(с такими устройствами, как tel0000.voip.mycompany.com, tel0001.voip.mycompany.comи т. д.)
  • switches.mycompany.com
  • workstations.mycompany.com (возможно подразделяется на администратора, пользователя и гостя)
• Устройства должны иметь значимые имена. Например:
  • Назовите телефоны так, чтобы вы могли видеть добавочный номер, который они звонят, основываясь на имени DNS.
  • Назовите рабочие станции в зависимости от их основного пользователя.
  • Четко определите «гостевые» IP-адреса.
  • Серверы имен, чтобы вы могли сказать, что они / что они делают.
    Это может быть достигнуто с помощью «скучные» имена ( www01, www02, db01, db02, mailи т.д.) или обнародовав схему именования и приклеить к нему (например , серверы почты названы после того, как скалы, веб - серверы названы после того, как деревья, серверы баз данных назван в честь художников).
    Скучные имена легче выучить новому человеку, крутые схемы именования веселее. Выбирайте.

Разные заметки

Что касается виртуальных серверов:
рассмотрите их так же, как если бы они были физическими машинами (разделите их по подразделению / назначению, а не по факту, что они являются «виртуальными». Создайте отдельное подразделение для сети администрирования Hypervisor / VM.
Это может показаться важным Теперь вам нужно знать, является ли ящик виртуальным или физическим, но когда ваша система мониторинга говорит: «Эй, электронная почта не работает!», вы будете задавать вопрос: «Какие машины связаны с электронной почтой?», а не «Какие машины являются виртуальные и которые являются физическими?».
Обратите внимание , что вам нЕ нужен практический способ определения , является ли виртуальной машиной или физической в случае гипервизор хост взрывается, но это вызов для вашей системы мониторинга, а не архитектура сети.

Что касается VOIP:
VOIP (в частности, звездочка) является синонимом «дыры в безопасности». Перенесите все свои VOIP-материалы в свою подсеть и в свою собственную VLAN, и не допускайте, чтобы они находились рядом с чем-нибудь чувствительным.
Каждый телефон VOIP, который я видел в прошлом году, поддерживает сегрегацию VLAN (фактически все они поддерживают голосовые и виртуальные локальные сети передачи данных, поэтому вы все равно можете использовать телефон в качестве сквозного соединения для настольных Ethernet-соединений). Воспользуйтесь этим - вы будете рады, что сделали, если / когда ваша среда VOIP будет взломана.

Что касается планирования и документации:
нарисуйте свою сеть на бумаге, прежде чем начинать назначать адреса и имена DNS. На самом деле, сначала нарисуйте его карандашом на БОЛЬШОМ листе бумаги.
Делай много ошибок.
Стереть обильно.
Проклятие бегло.
Как только вы перестанете ругаться и стирать в течение как минимум 10 дней, пришло время поместить диаграмму в Visio / Graffle / некоторый другой электронный формат в качестве официальной сетевой диаграммы. Защитите эту схему. Сохраняйте его в самой святой правильности при добавлении и удалении устройств, расширении организации и изменении структуры сети.
Эта схема сети станет вашим лучшим другом, когда вам придется вносить изменения, объяснять сеть новым администраторам или устранять загадочные ошибки.