DHCP ข้าม VPN: ทำสะพานบรอดแคสต์หรือส่งต่อคำขอ

แล็ปท็อปใหม่ที่อยู่อีกฟากของอุโมงค์ไม่ได้ที่อยู่ ขณะที่เครื่องเดียวกันทำงานได้ที่สำนักงานใหญ่ ข้อสันนิษฐานแรกที่พบบ่อยคืออุโมงค์บล็อก DHCP แต่บ่อยครั้งกว่านั้นคือบรอดแคสต์ไม่เคยมีเส้นทาง: ไคลเอนต์ที่ยังไม่ได้ตั้งค่าจะส่งไปที่ 255.255.255.255 และเราเตอร์ IP ทั่วไปไม่ส่งต่อแพ็กเก็ตนั้น อุโมงค์กำลังทำสิ่งที่อุโมงค์แบบกำหนดเส้นทางทำ

สองดีไซน์เปลี่ยนสิ่งนี้ได้ และทั้งสองไม่เทียบเท่ากัน แบบหนึ่งพาบรอดแคสต์ อีกแบบส่งต่อคำขอ

บรอดแคสต์ไม่เคยข้ามเราเตอร์

ไคลเอนต์ DHCPv4 ที่ไม่มีที่อยู่จะส่งจาก 0.0.0.0 ไปยังที่อยู่บรอดแคสต์แบบจำกัดบนพอร์ต UDP 67 และ 68 แพ็กเก็ตนั้นอยู่บนลิงก์ของตนตามการออกแบบ เราเตอร์ที่ส่งต่อมันจะท่วมทุกเซกเมนต์ที่ให้บริการ

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

สะพานอุโมงค์ขยายอะไรจริง ๆ

VPN ที่ทำสะพานโดยเจตนาสามารถพาบรอดแคสต์ของ Ethernet ภายในโทโพโลยีที่รองรับได้ และจากนั้น DHCP ก็ผ่านได้ในฐานะทราฟฟิกท้องถิ่น นี่เป็นตัวเลือกจริง แต่เป็นการตัดสินใจออกแบบชั้นที่ 2 คุณกำลังขยายโดเมนความล้มเหลวและขอบเขตการเข้าถึงไปพร้อมกับบรอดแคสต์

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

เป็นการตัดสินใจที่ใหญ่กว่าการให้ที่อยู่ และควรตัดสินใจอย่างตั้งใจ

ส่งต่อคำขอแทน

คำตอบปกติคือรีเลย์บนเครือข่ายท้องถิ่นของไคลเอนต์ มันรับบรอดแคสต์ แปลงเป็นคำขอ unicast และใส่ที่อยู่ของตัวเองในฟิลด์ที่อยู่เกตเวย์ เซิร์ฟเวอร์ตอบกลับไปยังที่อยู่รีเลย์นั้น

สำหรับสำนักงานระยะไกลเป็นตัวอย่าง รีเลย์อยู่บน LAN ของสำนักงานและเข้าถึงเซิร์ฟเวอร์ผ่าน VPN ของไซต์ กำหนดสโคปสำหรับสำนักงานนั้น ข้อมูลระบุตัวรีเลย์และเซิร์ฟเวอร์ และเส้นทางกลับที่สมบูรณ์ การอนุญาต UDP 67 ผ่านอุโมงค์ไม่ได้บอกเซิร์ฟเวอร์ว่าต้องใช้พูลใด

รีเลย์ที่ส่งต่อแต่ไม่เคยได้รับคำตอบมักเป็นปัญหาเส้นทางกลับ ตรวจสอบเส้นทางกลับไปยังที่อยู่รีเลย์ก่อนเปลี่ยนสโคป

แยก DHCP ออกจาก ARP และจากการกำหนดที่อยู่ของอุโมงค์

DHCP วิ่งบน UDP/IP บน Ethernet โฮสต์อาจใช้ ARP เพื่อตรวจว่าที่อยู่ที่เสนอถูกใช้อยู่แล้วหรือไม่ การตรวจความขัดแย้งนั้นเป็นการทำงานเฉพาะลิงก์แยกต่างหาก ไม่ใช่การขนส่งข้อความ DHCP การบอกว่า DHCP คือ ARP นั้นผิด และการบอกว่าทั้งสองไม่เกี่ยวข้องกันเลยนั้นกว้างเกินไป

ไคลเอนต์ VPN อาจได้ที่อยู่ของอุโมงค์จากโปรโตคอล VPN หรือจากพูลของเซิร์ฟเวอร์เองแทนที่จะเป็นบรอดแคสต์ DHCP ตัวเลือกที่มีคำว่า DHCP ในชื่ออาจอธิบายการตั้งค่าไคลเอนต์ที่ถูกส่งมา ไม่ใช่แพ็กเก็ต DHCP ที่ถูกรีเลย์ ตรวจสอบพูลของเซิร์ฟเวอร์ก่อนสันนิษฐานว่า DHCP เกี่ยวข้อง

บันทึกเครือข่ายปลายทาง เจ้าของการจัดสรร สโคป มีรีเลย์หรือไม่ และพฤติกรรมที่คาดหวังระหว่างเกิดเหตุขัดข้อง จากนั้นทดสอบสัญญาเช่าใหม่และการต่ออายุผ่านแบบจำลองนั้น หากสองไซต์ให้บริการพูลที่ไม่ได้จัดการเดียวกันได้ คุณมีความขัดแย้งรอแล็ปท็อปเครื่องแรกที่ย้ายที่อยู่