Próba zrozumienia interakcji między dwiema różnymi podsieciami w tej samej sieci


9

Mam 10.0.0.0/8sieć podzieloną na dwie części. Serwer DHCP rozdaje adresy 10.0.0.10do 10.0.0.150z maską klasy A ( 255.0.0.0). To moja część sieci „Gość”.

Uprawnieni użytkownicy sieci mają zastrzeżenia dotyczące serwera DHCP z adresami w 10.100.0.10do 10.100.0.250zakresu z maską klasy A.
Serwer plików w sieci ma adres IP 10.100.0.1i maskę klasy B ( 255.255.0.0).

  • Urządzenia zarówno w sieci „Guest”, jak i „Authorized” mogą się widzieć.
  • Sieć „Autoryzowana” widzi serwer plików.
  • Sieć „Gość” nie widzi serwera plików.

Do tej pory działało to całkiem dobrze, ale mój instruktor klasy przysięga, że ​​nie powinno. Czytałem w kilku miejscach, że komputery z przypisanymi różnymi maskami podsieci nie powinny mieć możliwości komunikowania się ze sobą.

Czy ktoś może pomóc mi zrozumieć, dlaczego „Autoryzowane” komputery sieciowe mogą uzyskać dostęp do serwera plików w porządku pomimo różnych masek podsieci?


1
Dziękuję za edycję, JakeGould. Wygląda to znacznie lepiej
Jared

Odpowiedzi:


13

Teoria maski podsieci polega na tym, że określa, która część adresu IP jest adresem sieciowym, a która część adresu IP to adres hosta:

10.100.0.1 - Adres IP;

255.0.0.0 - Maska podsieci;

10- adres sieciowy, 100.0.1- adres hosta.

Hosty w tej samej podsieci mogą rozmawiać bezpośrednio ze sobą. Oznacza to, że jeśli host A i B znajdują się w tej samej podsieci, a A chce rozmawiać z B, wówczas A wyśle ​​swój ruch bezpośrednio do B. Jeśli host A chce rozmawiać z hostem C, który znajduje się w innej podsieci, A będzie miał aby skierować ten ruch do bramy, która wie (miejmy nadzieję), jak dotrzeć do innej sieci. Zatem to do hosta należy określenie, gdzie wysłać ruch:

  1. Bezpośrednio do hosta (drugi host znajduje się w tej samej podsieci)
  2. Do bramy (drugi host należy do innej podsieci)

W twoim przypadku zdarza się, że Twoi „autoryzowani” klienci mają adresy IP 10.100.0.10 - 10.100.0.250(zakładam, że jest to maska ​​podsieci 255.0.0.0). Serwer ma adres IP 10.100.0.1. Dla hosta z zakresu „Autoryzowanego” serwer ten znajduje się w tej samej podsieci.

Jeśli host 10.100.0.10z zakresu „Autoryzowany” chce rozmawiać z serwerem - najpierw sprawdza, czy ten serwer znajduje się w tej samej podsieci, czy nie. W przypadku hosta 10.100.0.10z maską 255.0.0.0podsieci ta sama podsieć byłaby wszystkimi hostami w zakresie 10.0.0.1 - 10.255.255.254. Adres IP serwera znajduje się w tym zakresie. Z tego powodu host z zakresu „Autoryzowany” podejmuje próbę bezpośredniego połączenia z serwerem i (zakładając, że znajdują się w tej samej sieci warstwy 2) próba ta kończy się powodzeniem.

W tym przypadku, mimo że serwer ma inną maskę podsieci - zdarza się, że znajduje się w większej podsieci (która jest również podsiecią dla „autoryzowanych” klientów). Jeśli twój serwer będzie miał inny drugi bajt w adresie IP ( 10.150.0.1na przykład), nie będzie w stanie odpowiedzieć hostowi z zakresu „autoryzowanego”, ponieważ z perspektywy serwera zakres „autoryzowanego” wyglądałby jak inna podsieć i serwer musiałby wysłać ruch do routera. Jeśli nie byłoby routera - nie byłoby komunikacji.

Jeśli chcesz oddzielić swoją sieć od części „Goście” i „Autoryzowane”, musisz ustawić je w różnych podsieciach, które się nie nakładają.

Na przykład:

  1. „Goście” - 10.10.0.1maska ​​podsieci255.255.0.0
  2. „Autoryzowany” - 10.20.0.1, maska ​​podsieci255.255.0.0

Serwer znajdowałby się w „autoryzowanej” części sieci posiadającej adres IP 10.20.0.100, maskę podsieci 255.255.0.0.

Dzięki tej konfiguracji podsieci te zostaną skutecznie oddzielone od siebie, ponieważ części adresów IP reprezentujące ich podsieć będą się różnić:

  1. 10.10 dla gości
  2. 10.20 dla Autoryzowanego

W tym momencie komunikacja między tymi podsieciami będzie możliwa tylko za pośrednictwem routera, który ma interfejsy w obu podsieciach.

Warto również wspomnieć, że chociaż wszystkie komputery korzystają z tej samej sieci warstwy 2, nic nie stoi na przeszkodzie, aby Goście mogli ręcznie przypisywać sobie adresy IP z zakresu „Autoryzowanych”. Skutecznie sprawi, że staną się częścią sieci autoryzowanej.


5

Wszystkie maszyny „Autoryzowane” i „Gość” znajdują się w tej samej podsieci, więc nic dziwnego, że wszystkie mogą się ze sobą skontaktować.

Ograniczona maska ​​podsieci serwera sprawia, że ​​myśli, że tylko „Autoryzowane” komputery znajdują się w tej samej podsieci, więc ARP dla nich bezpośrednio i może do nich dotrzeć.

Serwer uważa, że ​​komputery „gości” znajdują się w innej podsieci, więc próbuje wysłać swoje pakiety do domyślnej bramy (to znaczy w warstwie Ethernet adresuje je na adres MAC domyślnej bramy; nadal są adresowane do komputery „gości” w warstwie IP). Jeśli serwer nie ma zdefiniowanej bramy domyślnej lub jeśli jej brama domyślna jest nieosiągalna lub źle skonfigurowana, pakiety te nie będą mogły uzyskać dostępu do komputerów „Gość”.


3

Ponieważ pakiety znajdują się poza zasięgiem sieci LAN, wysyłają pakiety do domyślnego routera. Domyślny router przekazuje je do miejsca docelowego i wysyła przekierowanie ICMP do źródła. Niezależnie od tego, czy przekierowanie ICMP działa, ruch nadal tam dociera.

Zdecydowanie nie powinieneś robić tego w ten sposób.


Jeśli rozumiem twoją odpowiedź, ping z sieci gościa dotrze do serwera plików, ale odpowiedź serwera plików trafi do domyślnej bramy, a nie odpowie bezpośrednio z powrotem na hosta gościa. Router nie będzie wiedział, gdzie wysłać ruch i opróżnić ruch w dół dziury? Nie chcę, aby serwer plików rozmawiał z hostami sieci gości, więc wydaje się, że to plus. Dlaczego to zły pomysł?
Jared

1
@jared Przeczytaj to zdanie: „Ich domyślny router przekazuje je do miejsca docelowego i wysyła przekierowanie ICMP do źródła”. Oznacza to, że wszystko, co robisz, to dodatkowe „przeskok” z dala od ruchu. Pakiet zostaje „zgubiony” i trafia do routera z prośbą o pomoc, a następnie zostaje przekierowany. Więc nic nie zostanie spuszczone przez otwór. Po prostu się odrywa.
JakeGould,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.