VPN เกสต์บน ESXi: เราเตอร์หรือบริดจ์ ตัดสินใจก่อนพอร์ตกรุ๊ป
TUN แบบเราเตอร์ต้องมีเส้นทางขากลับ TAP แบบบริดจ์ต้องเข้าถึงเลเยอร์ 2 และนโยบายพอร์ตกรุ๊ปที่กว้างขึ้น กำหนดบทบาทก่อนขยายโหมด promiscuous
เลือกเส้นทางแพ็กเก็ตหรือขยายโดเมน Ethernet การเปลี่ยนพอร์ตกรุ๊ปเป็นสิ่งที่ตามมาหลังการตัดสินใจนั้น จากมุมมองของแอปที่ถือที่อยู่ส่วนตัว ผลลัพธ์อาจดูเหมือนกัน ทั้งที่ข้อกำหนดของไฮเปอร์ไวเซอร์ต่างกันโดยสิ้นเชิง นี่คือเหตุผลที่พอร์ตกรุ๊ปถูกขยายก่อนและคำถามเรื่องการออกแบบได้คำตอบทีหลัง มักหลังพายุ broadcast ทำตามรายการตรวจเหล่านี้ตามลำดับและหยุดเมื่อข้อกำหนดยังคลุมเครือ เพราะไม่มีตั้งค่าพอร์ตกรุ๊ปใดแก้การออกแบบที่ไม่เคยถูกเลือกได้
การตัดสินใจเป็นของเจ้าของบริการ การกำหนดค่าไฮเปอร์ไวเซอร์ควรนำไปปฏิบัติ ไม่ใช่กำหนดขึ้นโดยบังเอิญ
ตรวจสอบว่าปลายทางไกลต้องการอะไรจริง ๆ
ระบุบริการที่ไคลเอนต์ระยะไกลต้องเข้าถึงและโปรโตคอลที่ใช้ หากเป็นบริการ TCP ไม่กี่รายการบนพรีฟิกซ์ที่รู้จัก การเราเตอร์ก็เพียงพอ หากมีบางอย่างต้องการความใกล้ชิดเลเยอร์ 2 จริง ๆ เช่น การค้นหาที่พึ่ง broadcast โปรโตคอลที่ไม่ใช่ IP อุปกรณ์ที่ไม่ยอมรับเกตเวย์ การเราเตอร์ลอกเลียนไม่ได้และควรบอกตั้งแต่เนิ่น ๆ จงซื่อตรงกับรายการที่ไม่ใช่ IP ในลิสต์นั้น เพราะนั่นคือที่ที่การออกแบบแบบเราเตอร์ล้มเหลวเงียบ ๆ ในอีกหนึ่งสัปดาห์
จากนั้นตรวจสอบพูลไคลเอนต์ การออกแบบแบบเราเตอร์ต้องมีช่วงที่อยู่และเส้นทางขากลับที่ชัดเจนฝั่งไกล การออกแบบแบบบริดจ์ต้องให้โดเมน Ethernet ที่ขยายแล้วเป็นเจ้าของการจัดสรรที่อยู่และการแยกส่วน ไม่ว่าจะเลือกแบบไหน คนนอก VM นี้ต้องเห็นด้วย
แต่ละแบบเรียกร้องอะไรจากเครือข่ายเสมือน
สองแบบต่างกันที่สิ่งที่เครือข่ายเสมือนต้องทน และตารางคือวิธีที่สั้นที่สุดในการมองเห็น
| การออกแบบ | บทบาทฝั่งเกสต์ | สิ่งที่เครือข่ายเสมือนต้องรองรับ | รูปแบบความล้มเหลวหากเลือผิด |
|---|---|---|---|
| TUN แบบเราเตอร์ | เราเตอร์ระหว่างพรีฟิกซ์ที่แยกจากกัน | พูลไคลเอนต์แบบเราเตอร์พร้อมเส้นทางขากลับฝั่งไกล | ไคลเอนต์เข้าถึงเกตเวย์ได้แต่ไม่เคยเข้าถึงบริการที่อยู่ข้างหลัง |
| TAP แบบบริดจ์ | บริดจ์เลเยอร์ 2 สำหรับไคลเอนต์ที่เข้าร่วม | ตัวตน Ethernet เพิ่มเติม ทราฟฟิก broadcast และกฎ VLAN | vSwitch ทิ้งเฟรม หรือการออกแบบต้องใช้โหมด promiscuous ที่ไม่มีใครอนุมัติ |
การเราเตอร์เก็บโดเมน broadcast ไว้ที่เดิมและให้จุดที่เป็นธรรมชาติในการจำกัดว่าบริการใดข้ามเกตเวย์ การบริดจ์ย้ายขอบเขต ไคลเอนต์กลายเป็นผู้ร่วมในโดเมน Ethernet ที่ขยายแล้ว และการจัดสรรที่อยู่ การแยกส่วน ตลอดจนนโยบายเลเยอร์ 2 ใด ๆ ใช้กับพวกเขาตอนนี้ เขียนแถวที่เลือกไว้ในบันทึกการเปลี่ยนแปลง ประโยคอย่าง «TUN แบบเราเตอร์ พูลไคลเอนต์ 10.90.0.0/24 เส้นทางขากลับบนคอร์» กันไม่ให้วิศวกรคนถัดไปกลับมาเถียงเรื่องการออกแบบจากค่าตั้งพอร์ตกรุ๊ป
ใครควรได้รับอนุญาตให้เห็นเฟรมของใคร
ถามเจ้าของแพลตฟอร์มหนึ่งคำถามก่อนแตะพอร์ตกรุ๊ป การออกแบบกำหนดให้ VM นี้รับเฟรมที่ส่งถึงผู้ร่วมคนอื่นหรือไม่ หากคำตอบคือไม่ ส่วนนี้ไม่ใช้เลย เพราะ TUN แบบเราเตอร์ไม่ต้องการการมองเห็นนั้นเลย หากคำตอบคือใช่ คำแนะนำของ Broadcom เรื่องโหมด promiscuous คือสิ่งที่ควรอ่าน เพราะอธิบายว่า VM มองเห็น vSwitch ได้มากเพียงใดและแนะนำให้จำกัดนโยบายนั้นไว้ที่พอร์ตกรุ๊ปเดียว
ถือว่านี่คือการตรวจสอบข้อกำหนด ไม่ใช่ใบอนุญาต เปิดค่าตั้งสำหรับการเชื่อมต่อเฉพาะรายการเดียวเมื่อความต้องการบริดจ์ถูกเขียนไว้ และปิดไว้ที่อื่นทั้งหมด trunk VLAN แบบกว้างที่คัดลอกจากตัวอย่างบริดจ์อื่นคือส่วนที่ไม่มีใครจำได้ให้ลบ และการออกแบบ VLAN เดียวควรคงเป็น VLAN เดียว
บันทึกว่าพอร์ตกรุ๊ปใดเปลี่ยนและเพราะอะไร ในที่เดียวกับที่เขียนแถวการออกแบบ คู่นี้เองทำให้การตรวจสอบครั้งถัดไปเป็นไปได้
ทำให้วัตถุของเกสต์ชัดเจน
ภายใน Linux การเป็นสมาชิกบริดจ์และการถือกรรมสิทธิ์ที่อยู่เป็นวัตถุแยกกัน การหลอมรวมทั้งสองทำให้เกิดสภาพกึ่งทำงานที่สับสน มอบที่อยู่ให้อินเทอร์เฟซบริดจ์หรืออุโมงค์แบบเราเตอร์ ไม่ใช่ทั้งสองด้านของเส้นทางเดียวกัน และให้พอร์ตสมาชิกปลอดจากการกำหนดค่า IP
หลีกเลี่ยงการวางซับเน็ตหนึ่งไว้อย่างอิสระบน TUN แบบเราเตอร์และบนอินเทอร์เฟซ Ethernet ที่ไม่เกี่ยวข้อง การกำหนดค่านั้นสร้าง สองเส้นทางไปยังพรีฟิกซ์เดียวกัน คำตอบแบบอสมมาตร และกระทู้สนับสนุนเรื่อง flapping ที่ไม่กล่าวถึงเส้นทางใดเลย หากเกสต์โฮสต์คอนเทนเนอร์หรือไฮเปอร์ไวเซอร์ภายในด้วย ตรวจสอบว่าพวกเขาไม่ได้บริดจ์เข้าสู่ uplink เดียวกันอยู่แล้ว สองบริดจ์บน NIC เดียวคือการออกแบบ ไม่ใช่อุบัติเหตุที่คุณอยากค้นพบระหว่างหน้าต่างเปลี่ยนแปลง
ยืนยันด้วยเส้นทางแพ็กเก็ต ไม่ใช่ ping
ตรวจสอบเส้นทางจริง ไม่ใช่แค่การเข้าถึง จากไคลเอนต์ ยืนยันว่าที่อยู่ต้นทางใดไปถึงบริการไกล แล้วยืนยันว่าคำตอบกลับมาทางเดิม บนเกสต์ ดูตัวนับการส่งต่อสำหรับโฟลว์นั้น และบนพอร์ตกรุ๊ปยืนยันว่าไม่ได้เปิดการมองเห็นเพิ่มเติมเกินกว่าที่การออกแบบที่เลือกต้องการ
สุดท้าย ทดสอบทิศทางความล้มเหลว หยุดอุโมงค์หรือตัดไคลเอนต์ออก แล้วตรวจสอบว่าทราฟฟิกไม่ตกลงสู่เส้นทางแบบเราเตอร์ที่คุณคิดว่าไม่ได้ใช้อย่างเงียบ ๆ เพราะการตกนั้นคือวิธีที่การออกแบบแบบบริดจ์กลายเป็นเราเตอร์โดยไม่ตั้งใจอย่างเงียบ ๆ