ลูกค้า DHCP รู้ได้อย่างไรว่า DHCPOFFERS หลายรายการยอมรับได้อย่างไร

ลองนึกภาพเรามีเครือข่ายเหมือนในภาพ หกโฮสต์ในหนึ่งเลเยอร์ 2 เครือข่ายไม่มี VLANs เครือข่ายควรแบ่งเป็นสองเครือข่ายย่อยโดยมีเซิร์ฟเวอร์ DHCP หนึ่งเซิร์ฟเวอร์ เซิร์ฟเวอร์ DHCP มีที่อยู่ IP คงที่ดังนั้นพวกเขาจึงรู้ว่าพวกเขาอยู่ในเครือข่ายย่อยใด

จากนั้นลูกค้าใหม่จะได้รับการเชื่อมต่อพวกเขาไม่ทราบอะไรเกี่ยวกับซับเน็ตที่พวกเขาควรจะอยู่ในและส่ง DHCPDISCOVER ของพวกเขาไปยังอีเธอร์เน็ตออกอากาศ 255.255.255.255 ดังนั้นจึงไปที่เซิร์ฟเวอร์ DHCP ทั้งสอง เซิร์ฟเวอร์ทั้งสองตอบกลับพร้อมข้อเสนอ ทีนี้นี่คือคำถามของฉัน: ลูกค้าจะรู้ได้อย่างไรว่าเขาควรยอมรับ DHCPOFFER คนใด?

networking dhcp

— Michael Niemand
แหล่งที่มา

เปรียบเทียบคำถามนี้และคำตอบที่นั่น

— Kamil Maciorowski

นี่เป็นอีกคำถามที่เกี่ยวข้อง

— kasperd

"the ethernet broadcast 255.255.255.255" - นั่นคือที่อยู่ IP สำหรับเครือข่ายท้องถิ่นไม่ใช่ที่อยู่ Ethernet ข้อความ DHCP DISCOVER เริ่มต้นนั้นมีความเป็นไปได้สูงที่จะใช้ที่อยู่อีเธอร์เน็ตออกอากาศ ff: ff: ff: ff: ff: ff แต่สิ่งเหล่านี้ไม่เหมือนกันจริงๆ

— ilkkachu

คำตอบ:

คำตอบที่ง่ายที่สุด - มาก่อนได้ก่อน

หากคุณมี VLAN หลายตัวและ 10.10.10.0/24 อยู่บน VLAN ที่แตกต่างกันไปที่ 10.10.20.0/24 - การออกอากาศจะไม่ข้าม VLANs

หากเซิร์ฟเวอร์ DHCP อยู่บน VLAN แยกจากกันไปยังไคลเอนต์ iphelper บนอินเตอร์เฟสการกำหนดเส้นทางระหว่าง vlans จะนำการออกอากาศไปยังตำแหน่งที่ถูกต้อง

ในสถานการณ์ของคุณที่คุณมี 2 เครือข่ายแยกกันภายใน VLAN เดียวกัน (หรือขาดมัน) ให้บริการเครือข่ายย่อยที่แตกต่างกัน - มันเป็นการแข่งขัน

DHCP แสดงขึ้นโดยใช้รายการต่อไปนี้:

การค้นพบ DHCP (DHCPDISCOVER) - การถ่ายทอดไคลเอ็นต์ - "มีเซิร์ฟเวอร์ DHCP หรือไม่"
ข้อเสนอ DHCP (DHCPOFFER) - เซิร์ฟเวอร์ถึงลูกค้า - "ใช่ฉันอยู่ที่นี่และพร้อมให้บริการ!"
คำขอ DHCP (DHCPREQUEST) - ไคลเอนต์ไปยังเซิร์ฟเวอร์ "ดีเลิศฉันขอที่อยู่ได้ไหม"
รับทราบ DHCP (DHCPACK) - เซิร์ฟเวอร์ไปยังไคลเอนต์ "แน่นอนนี่คือ IP, มาสก์, เกตเวย์, DNS / WINS เซิร์ฟเวอร์บางตัว, เซิร์ฟเวอร์เวลาและสิ่งอื่น ๆ ทั้งหมดที่กำหนดค่าไว้สำหรับขอบเขตของคุณ"

ทั้งหมดนี้เกิดขึ้นใน UDP Ports 67 สำหรับเซิร์ฟเวอร์และ 68 สำหรับไคลเอ็นต์

ทันทีที่มาถึงขั้นตอนที่ 2 - ลูกค้าจะหยุด "ฟัง" การตอบกลับเซิร์ฟเวอร์ DHCP อื่น ๆ - ยินดีที่จะจัดการกับเซิร์ฟเวอร์เครื่องแรกเพื่อให้ความสนใจ

ในฐานะที่เป็นข้อความด้าน - มีการโจมตี DoS (ปฏิเสธการบริการ) ที่รู้จักกันดีซึ่งเป็นการละเมิดสิทธินี้ ผู้โจมตีเสียบอุปกรณ์ที่ตอบสนองและส่งแพ็กเก็ต DHCPOFFER จากนั้นจะไม่ส่ง DHCPACK ออกเมื่อถูกถาม ... ซ้ำแล้วซ้ำอีก นอกจากนี้ยังมีการโจมตี DoS อีกครั้งที่เซิร์ฟเวอร์ DHCP "ปลอม" เสนอที่อยู่ซึ่งไม่สามารถกำหนดเส้นทางได้หรือขัดแย้งกับ IP อื่น ๆ ที่ถูกดักจับเพื่อยุ่งกับเครือข่าย

— Fazer87
แหล่งที่มา

และดังนั้นคำตอบสั้น ๆ เกี่ยวกับ "แต่แล้วฉันจะรันหลายซับเน็ตในเซ็กเมนต์ Layer-2 ได้อย่างไร" คือ " คุณทำไม่ได้ " (ใช่มีหลายวิธี แต่ไม่ใช่สิ่งที่คุณควรทำโดยทั่วไปชั้นหนึ่ง -2 โดเมน = หนึ่งเครือข่ายย่อย)

— user1686

ขอบคุณพวกคุณที่คลิกกับฉันจริงๆ ฉันสงสัยอยู่เสมอว่ามันจะเป็นไปได้อย่างไร แต่มันก็ไม่ใช่ ดังนั้นสิ่งที่จะไปคือ: ให้เราเตอร์ / เลเยอร์ 3 สลับไปมาระหว่างซับเน็ตหรือเซกเมนต์ด้วย VLAN ใช่ไหม?

— Michael Niemand

โดยทั่วไปใช่คุณต้องการ VLANs หรือการแบ่งส่วนแบบฟิสิคัล การแชร์โดเมน L2 จะทำได้เฉพาะในกรณีที่เซิร์ฟเวอร์ DHCP ของคุณทั้งสองถูก จำกัด ให้จัดการไคลเอ็นต์ "ที่รู้จัก" (เช่นโดยรายการ 'สัญญาเช่าคงที่' กับที่อยู่ MAC ที่อนุญาต)

— user1686

ฉันคิดว่าคุณสามารถให้เซิร์ฟเวอร์ DHCP แต่ละรายการในรายการที่อยู่ MAC ของรายการที่อนุญาตและควบคุมว่าลูกค้าคนใดจะได้รับที่อยู่จากเซิร์ฟเวอร์แบบนั้น

— Darren

@grawity คุณสามารถเรียกใช้เครือข่ายย่อย IP หลายรายการในส่วนเลเยอร์ 2 เดียวกันได้หากเครือข่ายย่อยเท่ากันและคุณไม่สนใจว่าไคลเอ็นต์ใดจะได้รับที่อยู่จากเครือข่ายย่อยใด คุณมีเซิร์ฟเวอร์ DHCP เพียงเซิร์ฟเวอร์เดียวที่ให้ที่อยู่จากบล็อกทั้งสองและเราเตอร์หนึ่งตัวที่ทำหน้าที่เป็นเกตเวย์สำหรับบล็อกทั้งสอง (โดยมีที่อยู่ในแต่ละรายการ) เสร็จสิ้น การพูดเพียงว่า "คุณไม่ได้" นั้นผิดปกติ

— ilkkachu

คำตอบที่มีอยู่จาก @ Fazer87 เป็นวงกว้างที่ถูกต้องในการปฏิบัติและผมขอแนะนำให้ upvoting และยอมรับมัน คำตอบนี้สำรวจรายละเอียดเล็กน้อยอย่างแม่นยำยิ่งขึ้น

เซิร์ฟเวอร์ DHCP ทั้งสองอาจตอบกลับด้วยข้อความ DHCPOffer

ไคลเอ็นต์ DHCP อาจยอมรับพวกเขาในลักษณะ "มาก่อนได้ก่อน" อย่างไรก็ตามมันไม่จำเป็นต้องใช้วิธีการนั้น

RFC2131ระบุ:

ไคลเอนต์ได้รับข้อความอย่างน้อยหนึ่ง DHCPOFFER จากเซิร์ฟเวอร์หนึ่งหรือมากกว่า ลูกค้าอาจเลือกที่จะรอการตอบกลับหลายครั้ง ไคลเอ็นต์เลือกเซิร์ฟเวอร์หนึ่งตัวเพื่อร้องขอพารามิเตอร์การกำหนดค่าตามพารามิเตอร์การกำหนดค่าที่เสนอในข้อความ DHCPOFFER

ดังนั้นหากเซิร์ฟเวอร์ DHCP ตัวที่สองเสนอการสำรองที่อยู่ IP อีกต่อไปหรือเสนอเวลาเซิร์ฟเวอร์ที่ที่อื่นไม่ได้หรืออาจมีเขตข้อมูลที่กำหนดเองซึ่งไคลเอ็นต์ได้รับการตั้งโปรแกรมให้ชอบก็อาจยอมรับข้อเสนอที่สอง

โดยทั่วไปวิธีการ "มาก่อนได้ก่อน" จะทำให้คุณได้รับข้อเสนอที่ไม่ได้ผ่านหลายฮ็อปในอุปกรณ์ (rebootcasts BOOTP) ดังนั้นจึงเป็นโปรโตคอลที่ดีที่จะปฏิบัติตามหากคุณไม่มีเหตุผลที่จะต้องดูแล

ฉันอยู่ในโครงการหนึ่งที่อุปกรณ์แบบกำหนดเองต้องการ DHCPOffer ซึ่งรวมเซิร์ฟเวอร์ TFTP ที่สามารถพบเฟิร์มแวร์ที่อัปเดตได้

— Oddthinking
แหล่งที่มา

... หรือถ้าเซิร์ฟเวอร์หนึ่งเสนอที่อยู่ซึ่งลูกค้าเคยใช้มาแล้วและต้องการเก็บไว้

— ilkkachu

@ilkkachu: ตามทฤษฎีแล้ว แต่มีกลไกที่ดีกว่าสำหรับเรื่องนี้ (ทั้งการต่ออายุการจองก่อนที่จะหมดอายุด้วยเซิร์ฟเวอร์ DHCP เก่าหรือส่ง DHCPDiscovery ที่ร้องขอที่อยู่ IP เก่า) ดังนั้นจึงไม่น่าจะมีประโยชน์ในทางปฏิบัติ

— Oddthinking