DHCP istemcileri, birden fazla DHCPOFFER'dan hangilerinin kabul edileceğini nasıl bilir?

Resimdeki gibi bir ağımız olduğunu düşünün. Bir katman 2 ağda altı ana bilgisayar, VLAN yok. Ağın, her biri bir DHCP sunucusu olmak üzere iki alt ağa bölünmesi gerekiyor. DHCP sunucularının sabit IP adresleri vardır, bu nedenle hangi alt ağa ait olduklarını açıkça bilirler.

Sonra yeni istemciler takılır. Hangi alt ağda olmaları gerektiği hakkında hiçbir şey bilmezler ve DHCPDISCOVER'larını 255.255.255.255 Ethernet yayınına gönderirler , böylece her iki DHCP sunucusuna gider. Her iki sunucu da bir teklifle yanıt verir. Şimdi sorum şu: Müşteri hangi DHCPOFFER'ı kabul etmesi gerektiğini nereden biliyor?

networking dhcp

— Michael Niemand
kaynak

Karşılaştırma bu soruyu ve orada cevapları.

— Kamil Maciorowski

İşte ilgili başka bir soru .

— kasperd

"ethernet yayını 255.255.255.255" - Bu bir Ethernet adresi değil, yerel ağ için IP yayın adresidir. İlk DHCP DISCOVER iletilerinin de ff: ff: ff: ff: ff: ff Ethernet yayın adresini kullanması çok olasıdır, ancak bunlar gerçekten aynı değildir.

— ilkkachu

Yanıtlar:

En basit cevap - önce gelen ilk hizmet.

Birden fazla VLAN'ınız varsa ve 10.10.10.0/24, 10.10.20.0/24'ten farklı bir VLAN'da olsaydı - yayın VLAN'ları geçemezdi.

DHCP Sunucusu istemcilere ayrı bir VLAN üzerindeyse, vlanslar arasındaki yönlendirme arabirimindeki bir iphel yayını doğru konuma yönlendirir.

Aynı VLAN içinde farklı alt ağlara hizmet eden 2 ayrı ağın olduğu senaryoda - bu bir yarış.

DHCP Aşağıdaki işlemleri kullanarak hizmet verir:

DHCP Bulma (DHCPDISCOVER) - İstemci Yayını - "Orada bir DHCP Sunucusu var mı?"
DHCP Teklifi (DHCPOFFER) - Sunucudan İstemciye - "Evet, buradayım ve ulaşılabilirim!"
DHCP İsteği (DHCPREQUEST) - İstemciden Sunucuya "Harika, lütfen adres alabilir miyim?"
DHCP Onayı (DHCPACK) - Sunucudan istemciye "Tabii, işte IP, maske, ağ geçidi, bazı DNS / WINS Sunucuları, Zaman Sunucusu ve kapsamınız için yapılandırılmış tüm diğer şeyler"

Tüm bunlar, sunucu için UDP Bağlantı Noktaları 67 ve istemci için 68'de gerçekleşir.

Adım 2'ye ulaşılır ulaşılmaz - istemci diğer DHCP Sunucularının yanıtlarını "dinlemeyi" durduracaktır - dikkatini vermek için ilk Sunucu ile mutlu bir şekilde ilgilenir.

Bir yan not olarak - aslında bu hakkı kötüye kullanan iyi bilinen bir dizi DoS (Hizmet Reddi) saldırısı vardır. Saldırgan, DHCPOFFER paketlerini yanıtlayan ve gönderen bir aygıta takılır ve daha sonra sorulduğunda DHCPACK'i tekrar tekrar göndermez. "Sahte" DHCP Sunucularının yönlendirilemeyen veya ağlarla uğraşmak için kokladığı diğer IP'lerle çakışan adresler sunduğu başka bir DoS saldırısı da vardır.

— Fazer87
kaynak

Bu nedenle "Ama sonra tek bir Katman-2 segmentinde birden çok alt ağı nasıl çalıştırırım?" "dir Bilemezsin. " (Evet, yolları vardır, ancak bu bir şey değil gerektiğini genellikle do Tek katman-2 alanı = bir alt ağ..)

— user1686

Teşekkürler çocuklar, bu gerçekten beni tıkladı. Bunun nasıl mümkün olabileceğini hep merak ettim, ama öyle değil. Yani götürmek: VLAN'lı bir alt ağ veya segment arasında bir yönlendirici / katman 3 arasında geçiş var mı?

— Michael Niemand

Genel olarak, evet, ya VLAN'lara ya da fiziksel segmentasyona ihtiyacınız vardır. Bir L2 etki alanını paylaşmak, yalnızca DHCP sunucularınızın her ikisi de "bilinen" istemcileri işlemekle sınırlıysa (örn. İzin verilen MAC adresleri olan 'statik kiralamalar' listesiyle) yapılabilir.

— user1686

Her DHCP sunucusuna MAC adreslerinin beyaz listesini verebilir ve hangi istemcinin hangi sunucudan bu şekilde adres alacağını kontrol edebilirsiniz.

— Darren

@grawity, alt ağlar eşitse aynı katman-2 segmentinde birden çok IP alt ağını kolayca çalıştırabilirsiniz ve hangi istemcinin hangi alt ağdan adres aldığını umursamazsınız. Her iki bloktan da adresler veren bir DHCP sunucunuz ve her iki blok için de ağ geçidi görevi gören bir yönlendiriciniz var (her birinde bir adres bulunur). Bitti. Sadece "yapma" demek yanlıştır.

— ilkkachu

Varolan cevap Fazer87 @ dan pratikte genel olarak doğrudur ve ben upvoting ve kabul öneriyoruz. Bu cevap küçük bir ayrıntıyı biraz daha kesin bir şekilde araştırıyor.

Her iki DHCP sunucusu bir DHCPOffer iletisiyle yanıt verebilir.

Bir DHCP istemcisi onları "ilk gelen, ilk hizmet" esasına göre kabul edebilir. Ancak, bu yaklaşımı benimsemek gerekmez.

RFC2131 şunları belirtir:

İstemci, bir veya daha fazla sunucudan bir veya daha fazla DHCPOFFER iletisi alır. Müşteri birden fazla yanıt beklemeyi seçebilir. İstemci, DHCPOFFER iletilerinde sunulan yapılandırma parametrelerine dayalı olarak yapılandırma parametreleri isteyecek bir sunucu seçer.

Dolayısıyla, ikinci DHCP sunucusu daha uzun bir IP adresi rezervasyonu teklif ettiyse veya diğerinin vermediği bir zaman sunucusu teklif ettiyse veya istemcinin tercih etmek üzere programlanmış özel bir alanı varsa, ikinci teklifi kabul edebilir.

Tipik olarak, bir "ilk gelen, ilk hizmet" yaklaşımı size cihazlar arasında birkaç atlama (BOOTP rebroadcasts) geçmemiş teklif almak için gidecek, bu yüzden bakım için bir neden yoksa takip etmek için iyi bir protokol.

Özel bir cihazın, güncellenmiş ürün yazılımının bulunduğu bir TFTP sunucusu içeren bir DHCPOffer'ı tercih edeceği bir projedeydim.

— Oddthinking
kaynak

... ya da bir sunucu müşterinin daha önce kullandığı ve saklamak istediği bir adres teklif ederse

— ilkkachu

@ilkkachu: Evet, teorik olarak, ancak bunun için daha iyi mekanizmalar var (hem eski DHCP sunucusuyla sona ermeden önce bir rezervasyonu yenilemek, hem de eski IP adresini isteyen bir DHCPDiscovery göndermek), bu yüzden pratikte yararlı olma olasılığı düşüktür.

— 18'de