Я администрировал только довольно маленькие сети (<= 25 узлов). Обычно я ставлю шлюз .1, dns / proxy как .10, почту на .20, принтеры на .30-39 и так далее и так далее. Я никогда не использую IP-адреса напрямую, поскольку имена хостов DNS - это явно лучший способ, но мне нравится иметь четкий шаблон / макет / дизайн при построении сети с нуля.
Мое сопоставление DNS также имеет простой шаблон / макет именования. Например, у всех моих устройств два имени; одно формальное имя на основе роли (dc01, mail02 и т. д.) и неофициальное имя. Ничего особенного, но очень просто и управляемо.
Я пытаюсь придумать более интуитивную / креативную схему IP / Subnet / DNS (если есть что-то получше). Я уверен, что у других есть более интуитивные схемы в зависимости от целей сети и тому подобного. Моя сеть, над которой я работаю, все еще мала, но мне приходится иметь дело с множеством устройств.
Я ищу общий шаблон или методологию для назначения IP-адреса (диапазонов / классов), имен DNS и сетей подсетей, которые включают 4-5 основных пунктов:
Я никогда не работал напрямую с VoIP, но это нужно учитывать в будущем.
В целом я получил от всех по-настоящему хорошие идеи. Хотел бы я дать больше голосов / принятых ответов. Спасибо за ответы!
Я работал в организации аналогичного размера (у нас был / 26), которая по причинам, не зависящим от меня, власть имущие считали, что детализированная схема распределения IP имеет первостепенное значение для операционной целостности. Шлюз было быть .1, принтеры было между .2 и .12, серверы между .13 и .20 и так далее. Мы даже хранили документацию по отдельным хостам.
Это огромная заноза в заднице. Каким бы прилежным я ни был, мне никогда не удавалось поддерживать документацию в актуальном состоянии. Не помогло то, что у нас не было никаких служб DNS, поэтому использование этой документации схемы распределения IP было единственной службой "именования", которая у нас была (что странным образом делало ее более необходимой, чем она была на самом деле).
Для сети вашего размера я бы порекомендовал несколько вещей (большинство из которых вы уже сделали):
просто - Вы не управляете сотнями хостов. Сложность вашего решения должна отражать сложность окружающей среды. Не поддавайтесь искушению быть слишком умным. Вы поблагодарите себя позже.
Используйте доступное IP-пространство и предоставьте 60% своим клиентам через DHCP. Настройте какие-то службы динамического DNS, чтобы вам больше никогда не приходилось смотреть на чертов IP-адрес. Забудьте о том, чтобы их отслеживать. Прибыль.
Оставшиеся 30% зарезервируйте для IP-адресов. ты управлять: серверами, принтерами, сетевыми устройствами, услугами тестирования. и т.д. ИСПОЛЬЗУЙТЕ DNS, ЧТОБЫ ДОКУМЕНТОВАТЬ ЭТО. На мой взгляд, нет большей траты времени, чем тщательное отслеживание всех этих «управляемых администратором» IP-адресов (в отличие от IP-адресов, управляемых DHCP) с помощью электронной таблицы Excel (которую вы должны постоянно использовать и поддерживать) , когда вы могли бы приложить эти усилия для поддержки самодокументируемого и гораздо более полезного решения DNS.
Не используйте последние 10% своего адреса в верхней части пространства IP-адресации. Немного резерва никогда не помешает.
Отрегулируйте соотношения по своему усмотрению. В некоторых средах будет больше клиентов, в других - «серверных» (т. Е. «Управляемых администратором»).
Оба они попадают в категорию IP-пространства, управляемого администратором.
На мой взгляд, это не имеет ничего общего с разбиением на подсети и полностью связано с мониторингом сети.
Серверы «управляются администратором», рабочие столы (то есть клиентские машины) должны «управляться DHCP».
Физически дискретная сеть была бы идеальной ... но это нереально. Следующим лучшим вариантом будет отдельный VLAN и подсеть. Это почти единственная точка в небольшой сети, где я действительно чувствую необходимость разделить трафик (за исключением вещей, которые общедоступны).
Будь проще. Максимально просто, но при этом обеспечивая безопасность и гибкость. Разрабатывайте абстракцию в вещах, что звучит непросто, но на самом деле это путь к самой простоте.
Что касается подсетей, это довольно распространенное явление:
При необходимости фильтруйте трафик через каждую подсеть. Возможно использование VLAN. Я надеюсь, что вы хорошо знакомы с интерфейсом командной строки выбранного поставщика сетевых устройств.
Что касается DNS, вам это не понравится, но ... используйте то, что вам подходит. Лично мне нравится давать серверам полностью абстрактное имя хоста, не связанное с его сервисами. Затем я службы CNAME для имени хоста. Таким образом, миграция служб не вызовет головной боли при смене DNS. Или, по крайней мере, не так много. Я также предпочитаю называть виртуальные серверы с v перед именем хоста.
Примеры:
Держать. Это. Просто. (но функциональный)
Для выделения IP
Мой совет - поместить все в подсеть 10.0.0.0/8, используя следующую структуру: 10.site.division.device
site - физическое местоположение или логический эквивалент (например, офис в Нью-Йорке, офис в Нью-Джерси, объект аварийного восстановления, среда разработки). division это логическое подразделение, которое имеет для вас смысл. напримерdevices - отдельные устройства (ПК, серверы, телефоны, коммутаторы и т. д.)Идея здесь в том, что вы можете легко определить, что это за устройство и где оно находится, по его адресу: 10.2.1.100 - это рабочая станция администратора на «Зоне №2».
Эта модель основана на назначении IP-адресов на основе классов: класс A (/ 8) - это ваше предприятие. Каждое местоположение получает класс B (/ 16), а каждое логическое подразделение в местоположении получает класс C (/ 24) для своих устройств.
Возможно (а иногда и желательно) использовать что-то большее, чем / 24 для уровня «деления», и вы, безусловно, можете это сделать: все, что угодно, от / 17 до / 24, обычно является честной игрой с этой схемой.
Для имен DNS
Мой совет - следовать схеме, аналогичной назначению IP-адреса, которое я описал выше:
mycompany.comsitename.mycompany.com поддомен.voip.mycompany.com (с такими устройствами, как tel0000.voip.mycompany.com, tel0001.voip.mycompany.com, и т.д.)switches.mycompany.comworkstations.mycompany.com (возможно, разделен на администратора, пользователя и гостя)www01, www02, db01, db02, mailи т. д.) или обнародовав схему именования и придерживаясь ее (например: почтовые серверы названы в честь камней, веб-серверы названы в честь деревьев, серверы баз данных названы в честь художников).Разные примечания
По поводу виртуальных серверов:
Считайте их такими же, как если бы они были физическими машинами (разделите их по разделу / назначению, а не по тому факту, что они «виртуальные». Создайте отдельное подразделение для сети администрирования гипервизора / виртуальных машин.
Вам может показаться важным узнать, является ли ящик виртуальным или физическим, но когда ваша система мониторинга говорит: «Эй, электронная почта не работает!» вопрос, который вы зададите, будет: «Какие машины связаны с электронной почтой?», а не «Какие машины виртуальные, а какие физические?».
Обратите внимание, что вы ДЕЛАТЬ нужен практический способ определения того, является ли машина виртуальной или физической, в случае взрыва хоста гипервизора, но это проблема для вашей системы мониторинга, а не для вашей сетевой архитектуры.
Что касается VOIP:
VOIP (в частности, звездочка) является синонимом «дыры в безопасности». Переместите весь свой VOIP-материал в его собственную подсеть и свою собственную VLAN и не позволяйте ему приближаться к чему-либо важному.
Каждый VOIP-телефон, который я видел в прошлом году, поддерживает сегрегацию VLAN (на самом деле все они поддерживают VLAN для голоса и данных, так что вы все равно можете использовать телефон в качестве сквозного соединения для настольных сетевых подключений). Воспользуйтесь этим - вы будете рады, что сделали это, если / когда ваша среда VOIP будет взломана.
Относительно планирования и документации:
Нарисуйте свою сеть на бумаге, прежде чем приступить к назначению адресов и DNS-имен. На самом деле, сначала нарисуйте это карандашом на БОЛЬШОМ листе бумаги.
Делайте много ошибок.
Обильно сотрите.
Бегло ругайтесь.
Как только вы перестанете ругаться и стирать по крайней мере на 10 дней, самое время поместить диаграмму в Visio / Graffle / какой-либо другой электронный формат в качестве официальной сетевой диаграммы. Сохраните эту диаграмму. Сохраняйте его Святейшую Правильность при добавлении и удалении устройств, расширении вашей организации и изменении сетевой структуры.
Эта сетевая диаграмма будет вашим лучшим другом, когда вам нужно будет внести изменения, объяснить сеть новым администраторам или устранить загадочный сбой.