บริดจ์ TAP สำหรับ VLAN เดียว: เชื่อมต่ออินเทอร์เฟซย่อย

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

การขยาย VLAN หนึ่งครั้งหมายถึงโดเมนเลเยอร์ 2 หนึ่งโดเมน และบริดจ์ต้องเข้าร่วมโดเมนนั้น ไม่ใช่ทรังค์ที่พาทั้งหมด

แท็กไม่ปรากฏเพราะคุณทำบริดจ์บนทรังค์

ลองใช้อัปลิงก์ Linux eno1 ที่พา VLAN 120 ไปยังสวิตช์ที่จัดการได้ ดีไซน์ที่ใช้ได้กับ VLAN เดียวคือ tap_vpn ทำบริดจ์กับ br_vpn โดย br_vpn บรรจุ eno1.120 ไม่ใช่ eno1 อินเทอร์เฟซย่อย VLAN ใส่แท็กตอนขาออกและถอดออกตอนขาเข้า ดังนั้นบริดจ์จึงเห็นเฉพาะเฟรมที่ไม่มีแท็กสำหรับ VLAN นั้น หากใส่การ์ดอินเทอร์เฟซกายภาพลงในบริดจ์แทน เฟรมเดิมจะออกไปโดยไม่มีแท็กที่พอร์ตทรังค์ ซึ่งไม่ใช่สิ่งที่คุณวางแผนไว้

การทำบริดจ์บนทรังค์โดยปิดการกรอง VLAN ไม่ใช่ทางลัดไปสู่ผลลัพธ์เดียวกัน มันให้ทุก VLAN บนสายนั้นแก่บริดจ์ รวมถึง VLAN ที่ไคลเอนต์ไม่ควรเห็น

สองดีไซน์ที่ถูกต้อง เจ้าของแท็กเพียงหนึ่งเดียว

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

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

ย้ายแอดเดรสไปพร้อมสมาชิกภาพ

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

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

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

ตรวจสอบสมาชิกภาพก่อนตำหนิเส้นทาง

อ่านสถานะปัจจุบัน ไม่ใช่สถานะที่ตั้งใจไว้: ip -d link show dev eno1.120 พิมพ์ id ของ VLAN และพาเรนต์ของมัน ip link show master br_vpn แสดงรายชื่อสมาชิกของบริดจ์ และ bridge vlan show รายงานสมาชิกภาพรายพอร์ตและการจัดการขาออก ในดีไซน์อินเทอร์เฟซย่อย ให้ยืนยันว่าอุปกรณ์ TAP และอุปกรณ์ VLAN เป็นสมาชิก ในบริดจ์ที่รับรู้ VLAN ให้ตรวจสอบนโยบายของพอร์ตเอง เพราะบริดจ์ที่มีอยู่ไม่ได้พิสูจน์ว่ามันอนุญาตอะไร

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