Интересно узнать, как это делают другие.
На объекте, который я рассматриваю, есть несколько зданий, соединенных оптоволокном, и каждое из них находится в собственной подсети.
192.168.0.0 - Building 1 - VLAN10
192.168.1.0 - Building 2 - VLAN20
192.168.2.0 - Building 3 - VLAN30
и т. д.
(для справки: я понимаю нежелательные последствия нахождения в подсети 192.168)
В каждом здании имеется собственный небольшой центр обработки данных с DHCP-серверами и контроллерами домена.
Моя главная проблема в том, что я считаю, что очень запутанно иметь серверы в одном месте.
192.168.0.1 - building 1
192.168.0.5 - building 1
192.168.1.11 - building 2
192.168.2.5 - building 3
etc.
Конечно, я мог бы поместить все сетевое оборудование в подсеть 192.168.0.0, все серверы — в подсеть 192.168.1.0, DHCP — в подсеть 192.168.3.0, но это приведет к созданию перекрестных VLAN.
Например, мне, вероятно, все равно понадобится DHCP-сервер в VLAN20 для всех компьютеров в этом здании, а также DHCP-сервер в VLAN10 для компьютеров в этом здании.
Традиционно VLAN поддерживаются в соотношении 1 к 1 со своей подсетью.
Как другие справляются с этим? Вы просто знаете, что 192.168.0.1-.50 зарезервирован для серверного оборудования?
Я пришел из сети 10.1.0.0/21, поэтому у нас было достаточно адресов, чтобы все было разделено, и мы вообще не использовали VLAN.
решение1
Это очень сложный вопрос, на который можно ответить на основе сценария, поскольку необходимо учитывать множество факторов при небольшом количестве предоставленной информации. Однако, в общем смысле, вот мое понимание.
Во-первых, я согласен с комментариями против вопроса, что ни одна частная группа адресов не является более или менее желательной, чем другая, исходя из восприимчивости к тому, чтобы быть похожей на домашних пользователей. По моему опыту, как бы вы ни старались избегать конфликтов с пользователями VPN, если этого не происходит для пользователя 'A', в конечном итоге найдется какой-то пользователь 'B', для которого это происходит.
Одна из критических вещей, которую вы не упомянули в вопросе, это объем устройств и ожидаемый рост в течение срока службы инфраструктуры. Я буду придерживаться общих положений из-за открытого охвата и неоднозначности.
Если вы решили разделить свою сеть на подсети по зданиям, сначала определите необходимое количество зданий, а затем рассмотрите вероятность того, что этого будет достаточно на более длительный срок (5-10 лет). Постарайтесь прийти к количеству сетей, которое не будет чрезмерным, но реалистичным. Я бы обычно был либерален и допускал бы предельные накладные расходы. Используйте это, чтобы определить самый узкий диапазон, который можно использовать для подсетей более высокого уровня.
Например, если у вас 3 здания, но ожидается, что за 10 лет их число вырастет до 5, выберите основание 2, кратное этому, и разделите первый используемый октет с этим префиксом. Например, 172.16.xx с 8 сетями:
000 | x xxxx . xxxx xxxx - Common Equiptment. 192.168.0.0 /19
001 | x xxxx . xxxx xxxx - Building 1. 172.16.32.0 /19
010 | x xxxx . xxxx xxxx - Building 2. 172.16.64.0 /19
011 | x xxxx . xxxx xxxx - Building 3. 172.16.96.0 /19
100 | x xxxx . xxxx xxxx - Building 4. 172.16.128.0 /19
Это максимизирует область вашего адреса и позволит дальнейшее разбиение на подсети. Это также упрощает определение маршрутов, если все подсети в любой области .19 проходят через один и тот же узел для большей части оставшейся сети. Обратите внимание, что этот баланс должен работать в двух направлениях. Допустим, например, что у вас есть небольшое количество зданий в дополнение к вашим основным зданиям, например, удаленные офисы, которым не нужно много адресов, но которые просто должны быть подключены — вы можете выделить им одну «родительскую» подсеть здания и разделить ее для их обслуживания. Ваша цель в конечном итоге — сохранить наибольшее адресное пространство там, где оно, скорее всего, понадобится больше всего.
Отсюда вы можете обнаружить, что вы разделяете свою сеть дальше, на специфичные для приложений выделения. Вы можете сделать что-то вроде следующего:
Здание 1 (вид сверху).
001 | 0 0 | xxx . xxxx xxxx - Building 1's Default Network. 172.16.32.0 /21
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 1 0 | xxx . xxxx xxxx - Building 1's Phone Network. 172.16.48.0 /21
Мы могли бы пойти дальше и сделать следующее:
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 0 1 | 001 . xxxx xxxx - Management Network. 172.16.41.0 /24
001 | 0 1 | 010 . xxxx xxxx - Security Camera Network. 172.16.42.0 /24
001 | 0 1 | 011 . xxxx xxxx - Alarm System Network. 172.16.43.0 /24
Я считаю, что важно вынести из этого, найти решение, которое подойдет для вашего сценария. Вероятно, вам захочется:
- Максимизируйте пространство для роста там, где он, скорее всего, произойдет. По моим догадкам, это будет ваша сеть конечных пользователей.
- Поддерживайте согласованные шаблоны, где это возможно, чтобы можно было упростить списки контроля доступа и правила брандмауэра. Например, если вы знаете в 3-м октете, что 4-й и 5-й биты с шаблоном '01' всегда будут обозначать 'misc networks', вы можете иметь одну битовую маску для захвата всех зданий в одном правиле.
- Вместо того, чтобы сосредотачиваться на том, может ли адресное пространство конфликтовать с домашней сетью пользователя, попытайтесь сфокусировать свой дизайн на том, как они будут его использовать. Например, если это VPN точка-точка, без трансляции или перегрузки, с дополнительным маршрутизируемым трафиком, проходящим через него, может быть важно поддерживать совместимые адресные области. Однако для большинства домашних пользователей коллизия не будет иметь значения, поскольку они будут подключаться со своего конечного устройства, а их устройство будет рассматривать их соединение как шлюз для всего трафика. Любое отклонение от этого может противоречить вашей политике использования и выходить за рамки поддержки.
- Сети одной подсети не обязательно должны быть в одной VLAN... но, вероятно, должны. VLAN ID — это именно то, что нужно; просто число. Он не обязательно должен быть одинаковым на всех подключенных устройствах, если они им не обмениваются, но я не могу придумать ни одного сценария, в котором было бы полезно иметь непоследовательную структуру VLAN ID. Чтобы объединить две разные VLAN в одной сети, вам нужно использовать мост (коммутатор). По сути, вы разделите коммутатор на несколько подкоммутаторов и неэффективно соедините их таким образом, что их будет трудно поддерживать.
- Минимизируйте ненужную маршрутизацию. Хотя наличие всех этих сетей может быть приятным и логичным, если большой объем трафика проходит из сети A в сеть B через маршрутизатор, недостаточно просто предположить, что маршрутизатор способен поддерживать его, исходя из предпосылки, что скорости его портов достаточны. Например, маршрутизатор Cisco 1941 с двумя гигабитными портами Ethernet, хотя и имеет два гигабитных порта, имеет предполагаемую пропускную способность только 153 Мбит/с между сетями.Характеристики пропускной способности)
- Не иметь недостаточно сетей (...в духе противоречия). Если вы не использовали подсети для разделения сети, широковещательная рассылка достигла бы всех устройств. Если вы обнаружили, что некоторым группам устройств не нужно часто напрямую общаться, это хороший признак того, что их следует разделить.
- Используйте горизонтальную масштабируемость как внутри сетей, так и между ними. Вместо того, чтобы иметь один большой сервер, обслуживающий всех ваших пользователей, используйте меньший сервер для каждой сети, чтобы обслуживать только ее клиентов. Они могли бы совместно использовать общий источник данных, и это также сняло бы нагрузку с вашего маршрутизатора. Однако существует много способов достижения горизонтального масштабирования.
Надеюсь, это поможет вам или даст вам какие-нибудь идеи :)