TAP เซิร์ฟเวอร์เดียวหรือหลายตัว? ไคลเอนต์ OpenVPN บนบริดจ์

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

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

สองสถาปัตยกรรม ไม่ใช่สองการตั้งค่า

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

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

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

ตัวช่วย server-bridge ทำอะไร

ตัวช่วย server-bridge กำหนดค่าโหมด Ethernet แบบหลายไคลเอนต์ รูปแบบพูลแอดเดรสใช้เกตเวย์ เน็ตมาสก์ และช่วงเฉพาะภายในซับเน็ตที่บริดจ์ ตัวอย่างเช่นเกตเวย์ที่ 192.168.50.1 พร้อมพูลตั้งแต่ 192.168.50.160 ถึง 192.168.50.199

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

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

การแยกไม่ได้มาจากจำนวนโปรเซส

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

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

หากข้อกำหนดเพียงคือไคลเอนต์เข้าถึงบริการ IP บางอย่าง การออกแบบ TUN แบบกำหนดเส้นทางมักง่ายกว่าการทำบริดจ์พร้อมการกรอง แต่ละไคลเอนต์ได้ลิงก์ของตัวเอง และนโยบายอยู่ในกฎการกำหนดเส้นทางและไฟร์วอลล์แทนที่จะอยู่ภายในบริดจ์

เมื่อใดที่หลายโปรเซสยังถูกต้อง

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

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

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

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