บริดจ์ TAP แยกส่วนระหว่างบอร์ดสองตัวผ่าน OpenVPN

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

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

บริดจ์ย้ายอะไรจริงๆ

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

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

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

กำหนดที่อยู่ให้บริดจ์ ไม่ใช่พอร์ตสมาชิก

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

ทำไมต้องมีพอร์ตเฉพาะหนึ่งพอร์ตต่อแท่นทดสอบ

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

การเชื่อมพอร์ตอะแดปเตอร์การจัดการทำให้ LAN ของสำนักงานอยู่ห่างจากการตัดสินใจส่งต่อหนึ่งครั้งจากบอร์ดพัฒนา และบอร์ดที่ประพฤติตัวไม่ดีในชั้นสองก็คืออุปกรณ์ประเภทที่คุณไม่ต้องการบนเซกเมนต์นั้น อะแดปเตอร์ Wi-Fi แย่กว่า: การบริดจ์อินเทอร์เฟซไร้สายในโหมดโครงสร้างพื้นฐานไม่ได้ทำงานเหมือนการบริดจ์ Ethernet และความล้มเหลวนั้นสับสนแทนที่จะสะอาด

เก็บช่วงแล็บไว้นอกขอบเขต DHCP การผลิตใดๆ หากบอร์ดต้องการที่อยู่แบบไดนามิกในภายหลัง ผู้จัดสรรที่ได้รับอนุญาตหนึ่งรายที่มีพูลเดียวคือการจัดวางเดียวที่ยังคาดเดาได้ เราเตอร์ธรรมดาของสองไซต์ที่ตอบบนเซกเมนต์เดียวกันสร้างที่อยู่ที่ไม่มีใครอธิบายได้

ขอบเขตที่บริดจ์ไม่ได้สร้าง

การบริดจ์ไม่ใช่การกำหนดเส้นทาง และไม่ใช่การแยกส่วน เฟรมที่ข้ามบริดจ์ยังสามารถไปถึงฮุกการกรองของโฮสต์ได้ ขึ้นอยู่กับเส้นทาง bridge-netfilter ที่ติดตั้ง ดังนั้นนโยบายที่มีผลจริงต้องตรวจสอบไม่ใช่สันนิษฐาน การปิดไฟร์วอลล์เพราะเฟรมหนึ่งหายไปแลกเปลี่ยนบั๊กเฉพาะกับบั๊กทั่วไป

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

อีกสองตระกูลสมควรได้รับการตัดสินใจอย่างชัดเจน แผนที่อยู่ไม่ได้ทำให้บริดจ์เป็น IPv4 เท่านั้น ดังนั้น IPv6 และ EtherType อื่นๆ ต้องมีแผนหรือตัวกรองของตนเอง และ ping ที่สำเร็จไม่ได้บอกอะไรเลยว่าการออกอากาศการค้นพบบอร์ด กลุ่มมัลติแคสต์ หรือเฟรมจัมโบจะผ่านเส้นทางหรือไม่ เพราะสิ่งเหล่านั้นเป็นชั้นทราฟฟิกที่แตกต่างกันด้วยค่าเริ่มต้นที่ต่างกัน

สุดท้าย การขนส่งและความเป็นส่วนตัวเป็นการซื้อที่แตกต่างกัน TAP ขนส่ง Ethernet บริการ OpenVPN ให้การป้องกันรอบๆ การซ้อนทับ VXLAN ก็ขนส่ง Ethernet และไม่ได้ให้ความเป็นส่วนตัวในตัวเอง ดังนั้นการแทนที่สิ่งหนึ่งด้วยอีกสิ่งหนึ่งจึงเปลี่ยนคุณสมบัติความปลอดภัยแม้แผนภาพโทโพโลยีดูเหมือนกัน

ความคงทนและการทดสอบที่พิสูจน์

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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