สองเจ้าของ หนึ่งแอดเดรส: IP ซ้ำบนบริดจ์ TAP

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

อ่านหลักฐานของความขัดแย้งก่อนแตะบริดจ์

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

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

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

ทำบัญชีทุกการอ้างสิทธิ์ในเซกเมนต์

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

ไล่รายการตามลำดับนี้: แอดเดรสบนอุปกรณ์บริดจ์แต่ละตัวและพอร์ตสมาชิกของมัน พูล OpenVPN และการกำหนดแบบตายตัวใด ๆ ต่อไคลเอนต์ และเซิร์ฟเวอร์ DHCP ใด ๆ ที่ครอบคลุมเซกเมนต์ที่ทำบริดจ์ จากนั้นจับคู่แอดเดรสฮาร์ดแวร์จากรายงานความขัดแย้งกับอินเทอร์เฟซที่คุณพบ

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

พูลและช่วง DHCP คือสองเจ้าของที่ผู้คนลืม พิมพ์ช่วงทั้งสองออกมาพร้อมกันและมองหาการทับซ้อนก่อนทำอย่างอื่น แอดเดรสบริดจ์ที่กำหนดด้วยมือและพูลที่แจกค่าเดียวกันจะชนกันในที่สุด และการชนดูเหมือนสุ่มจนกว่าจะพิมพ์ช่วงทั้งสองออกมาเคียงกัน

ใส่หมายเลขให้บริดจ์เฉพาะที่ที่ต้องการอัตลักษณ์

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

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

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

ทำให้การแก้ไขอยู่รอดหลังรีบูต

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

หาเจ้าของการตั้งค่านั้น: โปรไฟล์ตัวจัดการเครือข่าย ไฟล์ต่ออินเทอร์เฟซ คำจำกัดความของคอนเทนเนอร์หรือ VM หรือส่วนของ cloud-init เปลี่ยนมันที่นั่น จากนั้นรีบูตโฮสต์ที่ได้รับผลกระทบหนึ่งเครื่องอย่างตั้งใจเพื่อยืนยันว่าค่าใหม่คือค่าที่กลับมา การรีบูตคือการทดสอบเดียวที่พิสูจน์ความคงอยู่

จองแอดเดรสบริดจ์ภายในช่วง DHCP เป็นข้อยกเว้น หรือย้ายออกไปนอกช่วง การจองที่มีอยู่เพียงในสเปรดชีตไม่ใช่ข้อยกเว้น และตัวจัดสรรจะไม่อ่านมัน

พิสูจน์ด้วยไคลเอนต์ทุกตัวออนไลน์

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

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

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

การตรวจสอบที่ไม่ได้รับคำตอบคือผลลัพธ์ที่คาดหวังบนเซกเมนต์ที่สะอาด การตรวจสอบที่ดึงคำตอบออกมาให้แอดเดรสฮาร์ดแวร์ของเจ้าของที่เหลือ ซึ่งเป็นหลักฐานเดียวกับที่เหตุการณ์ Windows ให้คุณตั้งแต่ต้น เก็บเอาต์พุตนั้นไว้กับบันทึกการเปลี่ยนแปลง เพราะมันเป็นหลักฐานเดียวว่าแอดเดรสถูกรักษาไว้อย่างเป็นเอกลักษณ์