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

11

Я управлял только небольшими сетями (<= 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, но это нужно учитывать в будущем.


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

osij2is
источник

Ответы:

9

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

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

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

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

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

Примеры:

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

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

Wesley
источник
1
Афина - это Афины, а это уже город ;-)
dmourati
+1: аминь на простом + функционале. Я не думал о политике запрета по умолчанию в подсети, поэтому мне придется включить ее. Я не очень разбираюсь в CLI для сетевого коммутатора (Netgear), но это то, что я могу понять. Используете ли вы обе подсети И VLAN или только одну, а не другую? Какой должен иметь приоритет?
osij2is
Если бы я мог снова проголосовать за тебя, я бы сделал это. Именно поэтому я задаю этот вопрос здесь: « Создайте абстракцию в вещах, которые звучат так, будто это не просто, но на самом деле это путь к самой простоте ». Это именно то, к чему я стремлюсь. К счастью, вы более красноречивы и лаконичны, чем я. ;)
osij2is
1
@ osij2is Я не очень много использую в подсетях или виртуальных локальных сетях, так как я в основном небольшой офисный подрядчик. Я бы предпочел использовать VLAN, так как это то, что я в основном использовал в прошлом. Тем не менее, я готов быть обвиненным в синдроме молотка. Когда все, что у вас есть, это точка-один-q, все выглядит как проблема VLAN. Да, один уровень абстракции хорош. Всегда. Два слоя - это кроличья нора. Три слоя - признак злоупотребления ЛСД.
Уэсли
1
@WesleyDavid - Re: Netgear, они, конечно, не ЛУЧШИЙ выбор, но их материал "ProSafe" может быть настроен для поддержки 802.1Q (Tagged VLAN). Реализация соответствует стандартам, насколько я могу судить: она хорошо работает с другими поставщиками и позволяет вам заменить ее на Juniper или Cisco, если позволит время и средства. Недостатком Netgear является то, что он действительно больше ориентирован на администрирование веб-браузера, чем на управление CLI, что замедляет работу хорошего сетевого администратора.
voretaq7
9

Я работал в организации такого же размера (у нас было / 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 и подсеть. Это почти единственная точка в небольшой сети, где я действительно чувствую необходимость разделять трафик (за исключением общедоступных).


источник
2
Слова. Upvote. Ой, подождите, это не Reddit. В любом случае, «не поддавайтесь искушению быть слишком умным». Цитируется за правду!
Уэсли
5

Для распределения 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 / некоторый другой электронный формат в качестве официальной сетевой диаграммы. Защитите эту схему. Сохраняйте его в самой святой правильности при добавлении и удалении устройств, расширении организации и изменении структуры сети.
Эта схема сети станет вашим лучшим другом, когда вам придется вносить изменения, объяснять сеть новым администраторам или устранять загадочные ошибки.

voretaq7
источник
Обратите внимание, что я предполагаю, что вы собираетесь использовать NAT - в основном потому, что я предполагаю, что вы захотите иметь> 1 сайтов и хотите использовать VPN между ними.
voretaq7
+1: мне нравится использование октетов и соотношение к местоположению (и / или виртуализация, как вы упомянули). Это может быть расширено на различные логические подразделения, но идея имеет большой смысл. Также для информации о VoIP.
osij2is
Октет не работает, когда у вас есть> 200 или около того устройств - это может стать ограничением, если у вас есть 1000 человек в офисе, и у всех из них есть IP-телефоны на их столах. Небольшое предостережение, о котором следует знать :-)
voretaq7
@ vortaq7: Я предположил этот момент, но все же приятно отметить. В любом случае, использование IP как способа логической и физической организации вещей - это хорошо. Кроме того, хорошая точка зрения виртуального или физического существа практически не имеет значения. Хорошо быть организованным, но отдача от такого разделения в лучшем случае незначительна.
osij2is
@ osij2is - Virtual vs Physical определенно важен, я просто не думаю, что сетевая инфраструктура - это место для его записи (или, если вам нужно, сделайте это с DNS, создав отдельные записи A или CNAME, как app01.hypervisor02.site.mycompany.com) Хорошо продуманная и внедренная система мониторинга является вторым важным элементом (после организации сети) в любой среде, которая вас интересует.
voretaq7