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


9

У меня есть 10.0.0.0/8сеть, разделенная на две части. DHCP - сервер раздает адреса 10.0.0.10в 10.0.0.150с маской класса А ( 255.0.0.0). Это моя «гостевая» часть сети.

Авторизованные пользователи сети имеют резервирование на сервере DHCP с адресами в 10.100.0.10в 10.100.0.250диапазон с маской класса А.
Файловый сервер в сети имеет IP-адрес 10.100.0.1и маску класса B ( 255.255.0.0).

  • Устройства как в гостевой, так и в авторизованной сети могут видеть друг друга.
  • «Авторизованная» сеть может видеть файловый сервер.
  • «Гостевая» сеть не видит файловый сервер.

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

Может кто-нибудь помочь мне понять, почему «Авторизованные» сетевые ПК могут нормально обращаться к файловому серверу, несмотря на разные маски подсети?


1
Спасибо за редактирование, JakeGould. Это выглядит намного лучше
Джаред

Ответы:


13

Теория маски подсети заключается в том, что она определяет, какая часть IP-адреса является сетевым адресом, а какая часть IP-адреса является адресом хоста:

10.100.0.1 - Айпи адрес;

255.0.0.0 - Маска подсети;

10- сетевой адрес, 100.0.1- адрес хоста.

Хосты в пределах одной подсети могут напрямую общаться друг с другом. Это означает, что если хост A и B расположены в одной подсети и A хочет установить связь с B, то A отправит свой трафик непосредственно на B. Если хост A хочет установить связь с хостом C, который находится в другой подсети, то A получит направить этот трафик на шлюз, который знает (надеюсь), как добраться до другой сети. Итак, хост должен определить, куда отправлять трафик:

  1. Непосредственно к хосту (второй хост находится в той же подсети)
  2. К шлюзу (второй хост принадлежит другой подсети)

Что происходит в вашем случае, так это то, что ваши «Авторизованные» клиенты имеют IP-адреса 10.100.0.10 - 10.100.0.250(я предполагаю, что маска подсети 255.0.0.0). Сервер имеет IP-адрес 10.100.0.1. Для хоста из диапазона «Авторизованный» этот сервер находится в той же подсети.

Если хост 10.100.0.10из «Авторизованного» диапазона хочет общаться с сервером - он сначала проверяет, находится ли этот сервер в той же подсети или нет. Для хоста 10.100.0.10с маской подсети 255.0.0.0одной и той же подсетью будут все хосты в диапазоне 10.0.0.1 - 10.255.255.254. IP-адрес сервера находится в этом диапазоне. По этой причине хост из «Авторизованного» диапазона пытается напрямую связаться с сервером и (при условии, что они находятся в одной сети уровня 2) эта попытка завершается успешно.

В этом случае, хотя сервер имеет другую маску подсети - он расположен в большей подсети (которая также является подсетью для «авторизованных» клиентов). Если у вашего сервера будет другой второй байт в IP-адресе ( 10.150.0.1например), он не сможет отвечать на хост из диапазона «Авторизованный», поскольку с точки зрения сервера диапазон «Авторизованный» будет выглядеть как другая подсеть и сервер нужно будет отправлять трафик на маршрутизатор. Если бы не было маршрутизатора - тогда не было бы связи.

Если вы хотите разделить свою сеть на части «Гости» и «Авторизованные», то вам нужно, чтобы они были расположены в разных подсетях, которые не перекрываются.

Например:

  1. "Гости" - 10.10.0.1маска подсети255.255.0.0
  2. «Разрешено» - 10.20.0.1, маска подсети255.255.0.0

Сервер будет находиться в «авторизованной» части сети, имеющей IP-адрес 10.20.0.100, маску подсети 255.255.0.0.

При такой настройке эти подсети будут эффективно отделены друг от друга, так как части IP-адресов, представляющих их подсеть, будут отличаться:

  1. 10.10 для гостей
  2. 10.20 для авторизованных

На этом этапе связь между этими подсетями будет возможна только через маршрутизатор, имеющий интерфейсы в обеих подсетях.

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


5

Все «Авторизованные» и «Гостевые» машины находятся в одной подсети, поэтому неудивительно, что все они могут общаться друг с другом.

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

Сервер считает, что «гостевые» компьютеры находятся в другой подсети, поэтому он пытается отправить свои пакеты на свой шлюз по умолчанию (то есть на уровне Ethernet он направляет их на MAC-адрес шлюза по умолчанию; они все еще адресованы «Гостевые» компьютеры на уровне IP). Если на сервере не определен шлюз по умолчанию или если его шлюз по умолчанию недоступен или неправильно настроен, эти пакеты не смогут достичь "гостевых" компьютеров.


3

Поскольку пакеты находятся за пределами диапазона локальной сети, они отправляют пакеты на маршрутизатор по умолчанию. Маршрутизатор по умолчанию перенаправляет их к месту назначения и отправляет ICMP-перенаправление источнику. Работает ли перенаправление ICMP, трафик все еще туда попадает.

Вы определенно не должны делать вещи таким образом.


Если я понимаю ваш ответ, эхо-запрос из гостевой сети достигнет файлового сервера, но ответ файлового сервера пойдет на шлюз по умолчанию, а не ответит непосредственно на гостевой хост. Маршрутизатор не будет знать, куда отправлять трафик и сбрасывать трафик в яму? Я не хочу, чтобы файловый сервер общался с гостевыми сетевыми хостами, так что это кажется плюсом. Почему это плохая идея?
Джаред

1
@jared Прочтите это предложение: «Маршрутизатор по умолчанию перенаправляет их к месту назначения и отправляет ICMP-перенаправление источнику». Это означает, что все ваши текущие настройки - это дополнительный «переход» в сторону от трафика. «Потерянный» пакет отправляется маршрутизатору с просьбой о помощи, а затем все равно перенаправляется. Так что ничто не спускается в дыру. Это просто отклоняется.
JakeGould
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.