Skąd klienci DHCP wiedzą, który z wielu DHCPOFFERS do zaakceptowania?

Wyobraź sobie, że mamy sieć jak na zdjęciu. Sześć hostów w sieci z jedną warstwą 2, bez sieci VLAN. Sieć powinna być podzielona na dwie podsieci, każda z jednym serwerem DHCP. Serwery DHCP mają ustalone adresy IP, więc oczywiście wiedzą, do której podsieci należą.

Następnie podłączają się nowi klienci. Nie wiedzą nic o podsieci, w której powinni być, i wysyłają DHCPDISCOVER do transmisji Ethernet 255.255.255.255, więc trafia ona na oba serwery DHCP. Oba serwery odpowiadają ofertą. Oto moje pytanie: Skąd klient wie, który DHCPOFFER powinien zaakceptować?

networking dhcp

— Michael Niemand
źródło

Porównaj to pytanie i odpowiedzi tam.

— Kamil Maciorowski

Oto kolejne powiązane pytanie .

— kasperd

„transmisja ethernetowa 255.255.255.255” - jest to adres emisji IP dla sieci lokalnej, a nie adres Ethernet. Początkowe komunikaty DHCP DISCOVER również prawdopodobnie wykorzystują adres rozgłoszeniowy Ethernet ff: ff: ff: ff: ff: ff, ale tak naprawdę to nie to samo.

— ilkkachu

Odpowiedzi:

Najprostsza odpowiedź - kto pierwszy, ten lepszy.

Jeśli masz wiele sieci VLAN, a 10.10.10.0/24 jest na innej sieci VLAN niż 10.10.20.0/24 - transmisja nie przekroczy sieci VLAN.

Jeśli serwer DHCP byłby w osobnej sieci VLAN dla klientów, iphelper na interfejsie routingu między sieciami VLAN skierowałby emisję do właściwej lokalizacji.

W twoim scenariuszu, w którym masz 2 oddzielne sieci w ramach tej samej sieci VLAN (lub jej brak) obsługujących różne podsieci - to wyścig.

DHCP Służy przy użyciu następujących transakcji:

Wykrywanie DHCP (DHCPDISCOVER) - transmisja klienta - „Czy istnieje serwer DHCP?”
Oferta DHCP (DHCPOFFER) - od serwera do klienta - „Tak, jestem tutaj i jestem dostępna!”
Żądanie DHCP (DHCPREQUEST) - klient do serwera „Niesamowite, czy mogę prosić o adres?”
Potwierdzenie DHCP (DHCPACK) - serwer do klienta „Jasne, oto adres IP, maska, brama, niektóre serwery DNS / WINS, serwer czasu i wszystkie inne rzeczy skonfigurowane dla twojego zakresu”

Wszystko to dzieje się na portach UDP 67 dla serwera i 68 dla klienta.

Jak tylko krok 2 zostanie osiągnięty - klient przestanie „nasłuchiwać” odpowiedzi innych serwerów DHCP - z przyjemnością poradzi sobie z pierwszym serwerem, aby zwrócić na niego uwagę.

Na marginesie - w rzeczywistości istnieje dobrze znana seria ataków DoS (Denial of Service), które naruszają to prawo. Atakujący podłącza urządzenie, które odpowiada i wysyła pakiety DHCPOFFER, a następnie nie wysyła DHCPACK, gdy jest o to poproszony ... w kółko. Istnieje również inny atak DoS, w którym „fałszywe” serwery DHCP oferują adresy, których nie można routować lub które powodują konflikt z innymi adresami IP, których węszy do sieci.

— Fazer87
źródło

I dlatego krótka odpowiedź na „Ale w jaki sposób mogę uruchomić wiele podsieci w jednym segmencie warstwy 2?” to „ Ty nie. ” (Tak, są sposoby, ale ogólnie nie należy tego robić. Jedna domena warstwy 2 = jedna podsieć.)

— user1686

Dziękuję wam, którzy naprawdę kliknęli na mnie. Zawsze zastanawiałem się, jak to byłoby możliwe, ale po prostu nie jest. Tak więc na wynos jest: czy router / warstwa 3 przełącza się między podsieciami lub segmentami za pomocą sieci VLAN, mam rację?

— Michael Niemand

Zasadniczo tak, potrzebujesz sieci VLAN lub fizycznej segmentacji. Udostępnianie domeny L2 byłoby możliwe tylko wtedy, gdy oba serwery DHCP były ograniczone do obsługi „znanych” klientów (np. Przez listę „dzierżaw statycznych” z dozwolonymi adresami MAC).

— user1686,

Myślę, że możesz nadać każdemu serwerowi DHCP białą listę adresów MAC i kontrolować, który klient pobiera adres z tego serwera w ten sposób.

— Darren

@grawity, możesz łatwo uruchamiać wiele podsieci IP w tym samym segmencie warstwy 2, jeśli podsieci są równe i nie obchodzi cię, który klient otrzyma adres z której podsieci. Masz tylko jeden serwer DHCP, który podaje adresy z obu bloków, i jeden router, który działa jako brama dla obu bloków (z adresem w każdym). Gotowy. Powiedzenie „nie” jest po prostu błędne.

— ilkkachu

Istniejący odpowiedź od @ Fazer87 jest zasadniczo poprawna w praktyce i polecam upvoting i przyjmując ją. Ta odpowiedź nieco dokładniej analizuje drobny szczegół.

Oba serwery DHCP mogą odpowiedzieć komunikatem DHCPOffer.

Klient DHCP może je akceptować na zasadzie „kto pierwszy, ten lepszy”. Takie podejście nie jest jednak wymagane.

RFC2131 określa:

Klient otrzymuje jeden lub więcej komunikatów DHCPOFFER z jednego lub więcej serwerów. Klient może poczekać na wiele odpowiedzi. Klient wybiera jeden serwer, z którego należy żądać parametrów konfiguracyjnych, w oparciu o parametry konfiguracyjne oferowane w komunikatach DHCPOFFER.

Tak więc, jeśli drugi serwer DHCP zaoferował dłuższą rezerwację adresu IP lub zaoferował serwer czasu, w którym drugi nie, lub może miał niestandardowe pole, które klient zaprogramował tak, aby mógł preferować, może zaakceptować drugą ofertę.

Zazwyczaj podejście „kto pierwszy, ten lepszy” zapewni ci ofertę, która nie była przeprowadzana przez kilka przeskoków na różnych urządzeniach (reemisje BOOTP), więc jest to dobry protokół do zastosowania, jeśli nie masz powodu, aby się tym przejmować.

Byłem przy jednym projekcie, w którym niestandardowe urządzenie wolałoby DHCPOffer, który zawierałby serwer TFTP, na którym można było znaleźć zaktualizowane oprogramowanie.

— Dziwne
źródło

... lub jeśli jeden serwer zaoferował adres, którego klient już wcześniej używał i chciał zachować

— ilkkachu

@ilkkachu: Tak, teoretycznie, ale istnieją na to lepsze mechanizmy (zarówno odnawianie rezerwacji przed jej wygaśnięciem ze starym serwerem DHCP, jak i wysyłanie DHCPDiscovery z żądaniem starego adresu IP), więc jest mało prawdopodobne, aby była przydatna w praktyce.

— Dziwne,