Зачем разделять IPv4 сети на подсети

Предположим, что у вас есть своя сеть класса B (префикс /16). Публичная сеть, или вам вышестоящие админы выдали такую приватную — в данном случае не важно. Вы имеете в своём распоряжении 216-2=65534 адреса. Как же ими распорядиться? Раздать всем пользователям и воткнуть их в огромную цепочку коммутаторов? Это плохое решение. Сеть такого размера обычно разбивают на несколько более мелких и для этого есть ряд причин.

Разбиение домена широковещания.

Первая причина разбиения сети на подсети заключается в том, чтобы не получить огромный broadcast домен. В современных IPv4 сетях широковещательный (broadcast) трафик является необходимым злом. Например, при помощи широковещательных запросов работает протокол ARP, операционная система Windows постоянно что-то рассылает в сеть, чтобы обнаружить другие компьютеры и т.п. Если мы подключим в одну сеть 65 тысяч устройств, то получится, что каждый квант времени кто-то что-то да отправит широковещательного. Такая сеть совершенно не сможет работать, потому что все будут заняты получением широковещательных пакетов. Если мы разобьём такую сеть, например, на 256 сетей в каждой из которых 254 хоста, то мы получим 256 отдельных небольших broadcast доменов, в каждом из которых действует сравнительно небольшое (254) количество источников широковещательного трафика. Такие сети уже смогут работать нормально.

На самом деле, объём широковещательного трафика является основным ограничителем, не позволяющим делать большие сети. Сеть на 254 хоста (/24) работает хорошо, на 510 (/23) средненько и сильно зависит от приложений, которые ней крутятся. На 1022 хоста (/22) сеть можно сделать, но лучше не помещать туда компьютеры. Например, такого размера может быть сеть, в которую подключено 1022 маршрутизатора, использующихся для подключения к удалённым филиалам. Обязательное условие — на этих маршрутизаторах необходимо контролировать каждый чих. Потому что если они начнут слать брудкасты, то сеть перестанет работать. К слову сказать, бывают безбрудкастовые сети с множественным доступом (NBMA сети). Но это, пожалуй, тема для отдельной статьи

Безопасность при разделении сети на подсети

Второй немаловажной причиной разделения сети на подсети является обеспечение определённого уровня безопасности. Дело в том, что в пределах локальной сети у нас сравнительно мало возможностей обеспечения контроля за трафиком. Мы можем, конечно, контролировать на коммутаторах MAC адреса, можем довольно много чего настроить на конечных устройствах (например, сложные правила файрвола на компьютерах). Но лучше всего этим заниматься централизованно при переходе трафика из одной сети в другую. На маршрутизаторе настраивается централизованная фильтрация, можно даже настроить Firewall на маршрутизаторе.

Например, вы планируете разместить в сети камеры видеонаблюдения, бухгалтерию, сервера организации, компьютеры программистов и менеджеров. Совершенно логичным шагом видится разбить сеть на подсети, чтобы в каждой сети были устройства определённого типа. Тогда у нас появляется возможность запретить доступ программистов к бухгалтерии, всем — к камерам видеонаблюдения. При этом разрешить доступ из всех сетей к корпоративным серверам.

Комментарии

Здравствуйте, Василий!
Давно мучает вопрос, подскажите пожалуйста.
Условия: 
Есть свитч L2, и два хоста.

Хост №1
192.168.0.100
/24
192.168.0.1 

Хост №2
192.168.1.100
/24
192.168.1.1 

Будет ли проходить пинг между хостами?

Ход моих мыслей:
Хост 1 начинает формировать ethernet-фрейм.
MAC-адреса Хост 2 он пока не знает.
Хост 1 смотрит по своей сетевой маске и видит хост 2 - вне его сети.

Тут у меня два варинта
Вариант 1
Тут логика коммутации(маршрутизации) должна ему подсказать отправить сей пакет в сторону шлюза по умолчанию (ставит в заголовок MAC-адрес шлюза)(вариант 1)
Следуя этому "варианту 1", маршрутизатор получив пакет и сравнив IP-заголовок, определяет куда направить этот пакет (что вообще немного опять же странно, машрутизатор увидит что пакет принадлежит его же сети и отбросит, ведь его дело машрутизировать сетевые пакеты из своей сети в другие и наоборот?)
И если учесть изначальные условия, что в схеме оборудования вообще отсутствует машрутизатор, вообще не понятно, состоятелен ли данный вариант?
Вариант 2
Хост 1 формирует бродкаст ARP и отсылает в сеть- "Хост 192.168.1.100 сообщите свой МАК".
Согласно логике бродкаста  в одном широковещательном домене (Хосты 1 и 2 физически подключены к одному свитчу (один широковещательный домен)), сей АРП-запрос достигнет-таки хоста 2.
Хост 2 увидив в заголовке свой МАК, примет его и обработает.
Затем Хост 2 отправит Хосту 1 свой MAC (ведь ему уже известен МАК Хоста 1)
Хост 1 получив МАК Хоста 2 сможет пропинговать его.

Но в реальных условиях пинги не проходят.

Скажите, пожалуйста, где я ошибаюсь в своих рассуждениях?
 

Аватар пользователя bacek

Здравствуйте.

Спасибо за интересный вопрос. Первый вариант близок к истине. Если нет маршрутизатора совсем - то пинг не выйдет за пределы отправителя. Потому что отправитель сразу поймёт что адресат в другой сети, далее попытается АРП-ом получить мак адрес своего шлюза, шлюз (роутер) ему не ответит, потому что роутера нет. И до отправки самого пинга дело не дойдёт, потому что нет мак адреса шлюза. Напрямую АРП получателю он слать не будет:  если бы по этой логике ваш компьютер "на всякий случай" слал АРП каждый раз когда вы открываете microsoft.com или google.com (далёкие незнакомые сети), локальный сегмент бы слёг от брудкастов. :-)

Если роутер есть - то надо смотреть, как он подключем. Если на роутере есть два интерфейса (шлюзы одной и другой сети) и они оба воткнуты в свич - то по идее всё будет работать через роутер. Полагаю так же, что всё будет рабоать если на роутере один интерфейс и на нём настроены айпи адреса двух шлюзов одновременно (secondary address) но последнее утверждение требует проверки.

Спасибо за ответ!

Василий, здравствуйте!
Позвольте еще один вопрос, из этой же темы.
На практике сталкивался с след.ситуацией:
Хост 1.
10.18.173.15
/8

Хост 2
10.18.173.16
/24

(если я не ошибаюсь, шлюзы не был указаны не у одного из хостов)
Так вот, пинг не проходил между этими хостами.
Что меня удивило,  т.к. я думал что сеть 10.0.0.0 /8 в любом случае уже включает в себя 10.8.173.0/24.
Но оказалось, что нет.
Пока не поставил маску /24 у первого хоста, пинги не проходили.
К чему я?
Сам термин "подсеть" вводит неискушенных в наивное заблуждение.
"По умолчанию" все мы, обычные, простые люди, интерпретируем слово "подсеть" как некую составную часть большей "сети".
И применяем "бытовую" логику (подход, закономерность)- раз название объекта А(подсеть) звучит как составная часть объекта Б(сеть), то скорее всего  можно сделать следующее умозаключение:эти два объекта (А и Б) взаимосвязаны, у них общая природа происхождения и законы взаимодействия (они не являются самостоятельными, независимыми друг от друга, уникальными единицами).
На мой взгляд, стоило подыскать другое слово для термина "подсеть".
Но я могу трижды ошибаться, так как "юн еще в сетях", поэтому прошу вас прокомментировать мои слова.
Спасибо!

 

Аватар пользователя bacek

В вашем примере хосты должны общаться. Либо какая-то другая причина, либо не точно воспроизвели пример.
Вот скажем 10.1.2.3 /24 не будет пинговать 10.3.2.1/8 так как первый хост будет слать второму запросы (или ответы) через отсутствующий шлюз. То есть если пинговать с /8 -> /24 то запросы дойдут, а ответы не вернутся.

В подсетях надо понимать, что всё что их касается содержится локально на каждом индивидуальном устройстве, принимаеющем решение ) Просто подсеть в вакууме есть только в голове админа, в реальной жизни это подсеть в таблице маршрутизации компа А, или подсеть в таблице компа Б, или подсеть в таблице роутера В. Они не обязаны быть одними и теми же ) Поэтому, если мы прогнозируем события, то важно именно рассуждать от лица очередного устройства, а не от топологии. Комп А отправляет туда-то исходя из своей таблицы, Роутер пересылает туда-то — исходя из своей.

Спасибо за ответ!
Перепроверил, вы правы пинги проходят от 10.18.173.15/8 до 10.18.173.16/24.
В чем-то я ошибся, озвучивая условия.

настроить наконечных устройствах

мне кажется стоит исправить

Аватар пользователя bacek
Спасибо.

Добавить комментарий