Назад | Перейти на главную страницу

возможность перекрытия сетей

У меня есть вопрос.

Я столкнулся со следующей ситуацией на сервере Windows ...

192.168.0.0 маска 255.255.0.0 GTW x. . .

192.168.3.0 маска 255.255.255.0 GTW y


Случайно в этом сценарии есть возможность перекрытия сетей?

192.168.3.0/16 и 192.168.3.0/24 могут сосуществовать?

Нет ничего «плохого» в том, что вы видите. То, как этот компьютер с Windows Server подключается к этим двум сетям, ничего не говорит о том, что узлы в каждой сети взаимодействуют с другими сетями.

Рассматривать:

  192.168.0.1/16             192.168.3.1/24
              v   _________   v
              v  |         |  v
              .--| Win Srv |--.
__________    |  |_________|  |    _________
|         |   |               |   |         |
|  host   |---|               |---|  host   |
|_________|   |               |   |_________|
              |               |
__________    |               |    _________
|         |   |               |   |         |
|  host   |---|               |---|  host   |
|_________|   |   _________   |   |_________|
              |  |         |  |
              |--| router  |--|
              ^  |_________|  ^
              ^       |       ^
192.168.0.254/16      |      192.168.3.254/24
                     ///

Хосты, подключенные к каждой сети, будут иметь соответствующий интерфейс на этом маршрутизаторе, указанный в качестве шлюза по умолчанию. На компьютере с Windows Server в качестве шлюза по умолчанию будет указан IP-адрес интерфейса одного или другого маршрутизатора.

Вы бы не хотели назначать IP-адреса из сети 192.168.3.0/24 хостам в сети 192.168.0.0/16. Хостам в сети 192.168.0.0/16 потребуется статический маршрут, указанный в их таблицах маршрутизации для сети 192.168.3.0/24, чтобы они могли взаимодействовать с хостами в сети 192.168.3.0/24. Это неудобно, но ни в коем случае не мешает заключению сделки.

Редактировать:

В приведенном выше примере машина Windows Server будет доставлять данные в нужное место назначения без необходимости статических маршрутов. Сервер имеет записи в своей таблице маршрутизации в результате наличия локальных интерфейсов для каждой подсети. Из любого ящика в примере сценария Это будет самое легкое время.

Ваш пример (ниже) - это другое животное, чем мой пример, и отличается от вашего вопроса:

Вы говорите о сервере, который имеет статический маршрут к сети 192.168.0.0/16 через 192.168.9.2 и три статических маршрута к 192.168.6.0/24, 192.168.4.0/24 и 192.169. Сеть 8.0 / 24 доступна через шлюз 192.169.1.254.

Не разбираясь в топологии (IP-адреса, назначаемые интерфейсам на сервере, расположение различных сетей за различными активными маршрутизаторами), трудно что-либо сказать. Конечно, нет ничего "неправильного" в том, что я вижу на вашем изображении, за исключением очевидного и вопиющего факта, что сети, попадающие в 192.169.0.0/16, не являются адресным пространством RFC-1918 и не должны использоваться внутри частных сети.

Я бы не хотел такой ситуации, и ответ зависит от вашего определения «сосуществовать».

Не может быть хостов с одним и тем же адресом, т.е. если хост A имеет адрес 192.168.3.5/16, а хост B - 192.168.3.5/24, и они будут пытаться жить в одном сегменте Ethernet, они вызовут конфликты IP-адресов.

Когда вы отправляете пакет по IP-сети, вы не указываете подсеть, а только IP-адрес. Подсети - это инструмент маршрутизации, поэтому, если A и B находятся в разных сегментах Ethernet, только B будет получать пакеты, потому что маршрутизаторы выберут тот с самой длинной маской.

Фактически, единственная ситуация, в которой я ожидал бы появления определения 192.168.0.0/16 и 192.168.x.0 / 24, это таблица маршрутизации. Я мог себе представить, что хосты в подсети / 24 находятся в отдельном месте и требуют специального определения маршрутизации. В таком случае это нормально, приемлемо. По поводу любого другого есть что-то странное, по крайней мере, я не могу сейчас придумать рационального оправдания такой конфигурации.

Это больше, чем «возможность» перекрытия сетей, это факт. Тем не менее, это не проблема, потому что IP-маршрутизация достаточно умна, чтобы направлять пакеты по наиболее конкретному доступному маршруту, который подходит именно вам.