Креативні схеми IP / subnet / dns

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

Моє відображення DNS також має простий шаблон / макет імен. Наприклад, усі мої пристрої мають два імені; одне формальне ім’я на основі ролі (dc01, mail02 тощо) та неофіційне ім'я. Нічого фантазійного, але справді простого і керованого.

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

Я шукаю загальну схему чи методологію для призначення IP-адреси (діапазонів / класів), імен dns та мереж підмережі, яка охоплює 4-5 основних моментів:

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

Я ніколи не працював безпосередньо з VoIP, але це щось, що слід враховувати в майбутньому.

В цілому я отримав від всіх справді хороші ідеї. Бажаю, щоб я міг дати більше голосів / прийнятих відповідей. Дякуємо за відповіді!

Не ускладнювати. Як можна простіше, але все ж забезпечуючи безпеку та гнучкість. Дизайн абстрагування речей, що здається, це не просто, але насправді це шлях до самої простоти.

Що стосується підмереж, то це досить поширене:

• Користувачі в одній підмережі
• Гості на іншому
• Сервери у власній підмережі
• VOIP і сам.

За необхідності фільтруйте трафік по кожній підмережі. Можливо, використовуйте VLAN. Сподіваюсь, ви добре знайомі з CLI вашого постачальника мережевих пристроїв на вибір.

Що стосується DNS, то вам це не сподобається, але ... використовуйте все, що працює для вас. Особисто мені подобається надавати серверам абсолютно абстрактне ім’я хоста, не пов'язане з його послугами. Потім я передаю послуги CNAME до імені хоста. Таким чином міграційні служби не викликають головних болів у зміні DNS. Або принаймні, не так багато. Я також вважаю за краще називати віртуальні сервери з av, створеними для імені хоста.

Приклади:

• Новий сервер баз даних називається Athena. Він назавжди буде названий Афіною.
• Афіна CNAMED для того, що робить: SQL08ENT-CRM, SQL08ENT-AEGIS (система безпеки), SQL08ENT-DOCMAN. Можливо також CNAMED на основі географії. Або, можливо, ім'я хоста матиме географію. Афіна-ATL. Афіна-Сідней. Що б не працювало.
• Сервер знаходиться в підмережі сервера, яка має політику заборони за замовчуванням. До нього належний трафік, включений із відповідних підмереж.

Тримайте. Це. Простий. (але функціональний)

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

Це величезний біль у попі. Якою б старанною я не була, я ніколи не можу видавати жодну документацію актуальною. Це не допомогло, що у нас не було жодних служб DNS, тому використання цієї документації щодо схеми розподілу IP було єдиним сервісом «іменування», який ми мали (що дивним чином зробило це незамінним, ніж насправді).

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

• Просто : Ви не керуєте сотнями хостів. Складність вашого рішення повинна відображати складність середовища. Встояти перед спокусою бути надмірно розумними. Ви подякуєте пізніше.

  1. Займіть доступний ІР-простір і дайте 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 - це фізичне місце розташування або логічний еквівалент (наприклад, офіс Нью-Йорка, офіс штату Нью-Джерсі, станція охорони здоров'я, середовище розробки).
• division- це логічний підрозділ, який має для вас сенс. наприклад
  0 => комутатори / маршрутизатори
  1 => адміністратори, 2 => користувачі
  3 => VOIP
  4 => гості
• devices - це окремі пристрої (ПК, сервери, телефони, комутатори тощо)

Ідея тут полягає в тому, що ви можете легко визначити, що таке пристрій і де він знаходиться за його адресою: 10.2.1.100 - це робоча станція адміністратора на "Сайті №2".

Ця модель походить від IP-призначень на основі класу: клас А (/ 8) - це ваше підприємство. Кожна локація отримує клас B (/ 16), а кожен логічний поділ у локації отримує клас C (/ 24) для своїх пристроїв.
Можна (і іноді бажано) використовувати щось більше, ніж / 24 для рівня "поділу", і ви, звичайно, можете це зробити: Що-небудь від a / 17 до a / 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 (адже вони всі підтримують як голосові, так і дані VLAN, тому ви все ще можете використовувати телефон як пропускну мережу для підключення до настільних мереж). Скористайтеся цим - Ви будете раді, що зробили, коли / коли ваше середовище VOIP буде зламано.

Щодо планування та документації:
Накресліть свою мережу на папері перед тим, як почати присвоювати адреси та імена DNS. Насправді намалюйте його олівцем на ВЕЛИКОМУ аркуші паперу.
Зробіть багато помилок.
Стерти ліберально.
Проклинайте плавно.
Як тільки ви припините проклинання та стирання принаймні на 10 днів, настав час поставити діаграму у Visio / Graffle / якийсь інший електронний формат як вашу офіційну мережну діаграму. Захистіть цю діаграму. Підтримуйте це у своїй найсвятішій правильності під час додавання та видалення пристроїв, розширення організації та модифікації структури мережі.
Ця мережна діаграма стане вашим найкращим другом, коли вам доведеться внести зміни, пояснити мережу новим адміністраторам або вирішити таємничий збій.