สองไซต์ต้องใช้ VLAN ID เดียวกันสำหรับ VPN ระหว่างไซต์หรือไม่

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

ตำนาน: VLAN ID เดียวกันที่ปลายทั้งสอง

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

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

การทดสอบย้อนกลับก็ให้ข้อมูลไม่แพ้กัน ให้ทั้งสองสำนักงานใช้ซับเน็ตเดียวกัน และจำนวนหมายเลข VLAN ที่เท่ากันไม่ทำให้ที่อยู่ชัดเจนขึ้น

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

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

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

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

ip xfrm policy
ip route show
swanctl --list-sas

การทับซ้อนที่ทำลายจริง ๆ

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

เมื่อการกำหนดหมายเลขใหม่เป็นไปไม่ได้ การออกแบบการแปลที่ตั้งใจสามารถนำเสนอมุมมองที่อยู่ที่แตกต่างให้แต่ละฝ่าย นั่นหมายถึงการแมปหนึ่งต่อหนึ่ง ตัวเลือกที่ตรงกัน รายการ DNS ที่สะท้อนมุมมองที่แปลแล้ว และการกำหนดเส้นทางกลับที่อยู่รอดจากการเขียนใหม่ เป็นการออกแบบที่รองรับได้โดยมีต้นทุนการดำเนินงานจริง และไม่ใช่สิ่งที่การเปลี่ยน VLAN ID ทำ

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

หนึ่งงานต่อหนึ่งชั้น เขียนไว้

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

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

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

ยืนยันภาพท้องถิ่นด้วยเครื่องมือบริดจ์ก่อนสันนิษฐานว่าแท็กไปถึงอุโมงค์

bridge vlan show
ip -br addr
ip route get 10.62.0.20

เมื่อการขยาย layer-2 เป็นข้อกำหนดจริง

การออกแบบบางอย่างต้องการพฤติกรรม Ethernet ระหว่างไซต์จริง ๆ: แอปพลิเคชันเก่าที่พึ่งการค้นหาผ่านการออกอากาศ การย้ายที่ต้องรักษาที่อยู่ขณะเครื่องย้าย หรือโปรโตคอลที่ฝังสมมติฐาน layer-2 กรณีเหล่านี้ต้องใช้โอเวอร์เลย์หรือบริการบริดจ์ที่ขนส่งเฟรม และจากนั้นการเป็นสมาชิก VLAN การป้องกันลูปและการจัดการความล้มเหลวจึงกลายเป็นเรื่องตั้งแต่ต้นจนจบ

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

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