Намагаючись зрозуміти взаємодію між двома різними підмережами в одній мережі


9

У мене 10.0.0.0/8мережа розділена на дві частини. Сервер DHCP роздає адреси 10.0.0.10на 10.0.0.150маску класу A ( 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 - IP-адреса;

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.