VLAN ของไคลเอนต์หรือทรังค์ที่ติดแท็ก: เลือกโหมด OpenVPN ให้ถูกต้อง

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

โหมดที่รับรู้ VLAN สร้างอะไรจริง ๆ

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

ฝั่ง TAP ของเซิร์ฟเวอร์ได้นโยบายการยอมรับแบบติดแท็กหรือไม่ติดแท็กของตนเองผ่าน vlan-accept การส่งต่อภายในสวิตช์นั้นเกิดขึ้นเฉพาะระหว่าง VID ที่ตรงกัน รวมถึงเมื่อตั้ง client-to-client ไว้ ดังนั้นไคลเอนต์สองรายใน VLAN ต่างกันจึงไปถึงกันผ่านเซิร์ฟเวอร์ไม่ได้ แม้ทั้งคู่จะเชื่อมต่อกับมัน

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

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

ทรังค์แบบโปร่งใสต้องมีอะไรแทน

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

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

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

สามเงื่อนไขที่ตัดสินคำตอบ

ข้อแรก แพลตฟอร์มไคลเอนต์รองรับ TAP หรือไม่ Android และ iOS ไม่รองรับ และการรองรับ macOS มีจำกัด ดังนั้นกลุ่มผู้ใช้มือถือจึงตัดการออกแบบ TAP ทั้งสองแบบทิ้ง ไม่ว่าจะจัดวาง VLAN อย่างไร เซสชัน TUN แบบกำหนดเส้นทางขนส่งแพ็กเก็ต IP ไม่ใช่เฟรมอีเทอร์เน็ต และการกำหนดค่า VLAN ฝั่งเซิร์ฟเวอร์ก็เปลี่ยนสิ่งนั้นไม่ได้ ตรวจสอบกลุ่มผู้ใช้ก่อนออกแบบโทโพโลยี เพราะเงื่อนไขนี้คือเงื่อนไขที่หลีกเลี่ยงไม่ได้ และยังเป็นเงื่อนไขที่มักถูกค้นพบหลังจากงานสวิตช์เสร็จแล้ว

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

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

การทดสอบตัวเลือกที่คุณทำ

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

ip -d link show tap0
bridge vlan show

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

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