วิธีกำหนดเส้นทางทราฟฟิก SaaS ไปยัง VPN ของลูกค้าที่ถูกต้อง
ซับเน็ตของลูกค้าที่ทับซ้อนกันทำให้การกำหนดเส้นทางร่วมเสียหาย เลือกโมเดลการแยก ผูกแต่ละงานกับผู้เช่าที่ตรวจสอบแล้ว และทดสอบเส้นทางข้ามผู้เช่าก่อนเปิดตัว
แพลตฟอร์ม SaaS เชื่อมต่อกับเครือข่ายลูกค้าสิบกว่าแห่ง และลูกค้าสองรายในนั้นต่างใช้ 10.20.0.10 สำหรับฐานข้อมูลหลักของตน เวิร์กเกอร์ที่ได้รับที่อยู่นั้นในงานไม่รู้ว่างานหมายถึงฐานข้อมูลใด และตารางกำหนดเส้นทางร่วมจะส่งต่อไปยังอุโมงค์ที่คำนำหน้าชี้ไปอย่างเต็มใจ การแก้ไขไม่ใช่การเพิ่มอุโมงค์ แต่เป็นการตัดสินใจว่าตัวตนของผู้เช่าเข้าสู่เส้นทางตรงไหน และแผนที่อยู่นั้นต้องใช้โมเดลการแยกแบบใด เงื่อนไขสามข้อกำหนดการเลือก คือ คำนำหน้าของลูกค้าทับซ้อนกันหรือไม่ ข้อผิดพลาดลุกลามได้ไกลแค่ไหน และใครเป็นผู้ดำเนินการตัวเชื่อมต่อ
ฐานข้อมูลลูกค้าสองแห่ง ที่อยู่ปลายทางเดียว
ที่อยู่ IP คือตำแหน่ง ไม่ใช่ตัวตน คำขอต้องพาตัวตนผู้เช่าที่เซิร์ฟเวอร์ตรวจสอบแล้ว และผู้เช่านั้นต้องเลือกบริบทเครือข่ายก่อนที่จะแก้ไขปลายทาง
เมื่อไม่เป็นเช่นนั้น ความล้มเหลวจะเงียบ การเชื่อมต่อสำเร็จ คำสั่งทำงาน และคำตอบมาจากฐานข้อมูลของลูกค้าผิด เพราะตารางกำหนดเส้นทางมีรายการเดียวสำหรับ 10.20.0.10 DNS ทำให้แย่ลง ชื่อที่แคชไว้ซึ่งแก้ไขในบริบทของผู้เช่า A อาจถูกนำมาใช้ซ้ำโดยงานที่ทำงานให้ผู้เช่า B ไม่มีสิ่งใดในแพ็กเก็ตแยกความแตกต่างของทั้งสอง ดังนั้นตรรกะลองใหม่ไม่ว่าจะมากเพียงใดก็ซ่อมไม่ได้
ตัดสินใจเรื่องโมเดลการแยกก่อน
เขียนเงื่อนไขทั้งสามข้อก่อนเปรียบเทียบผลิตภัณฑ์ การทับซ้อนกำหนดว่าพื้นที่ที่อยู่หนึ่งสามารถแชร์ได้หรือไม่ รัศมีผลกระทบกำหนดว่าข้อผิดพลาดในการกำหนดเส้นทางเป็นตั๋วสนับสนุนหรือการละเมิด ความเป็นเจ้าของการดำเนินงานกำหนดว่าคุณสามารถดูแลกองตัวเชื่อมต่อต่อผู้เช่าได้หรือไม่
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
หากคำนำหน้าแตกต่างและนโยบายอนุญาตให้มีฮับที่ควบคุมได้ Transit Gateway หนึ่งตัวที่มีตารางกำหนดเส้นทางต่อผู้เช่าถือเป็นไปได้ การเชื่อมโยงสิ่งที่แนบจะเลือกตารางกำหนดเส้นทางที่ใช้กับทราฟฟิกที่เข้าจากสิ่งที่แนบนั้น และการเผยแพร่จะเลือกว่าเส้นทางใดปรากฏในตาราง สิ่งที่แนบของผู้เช่าที่เชื่อมโยงกับตารางของตนเท่านั้นและเผยแพร่เฉพาะคำนำหน้าของตนจะไปถึงฮับและไม่ถึงที่อื่น นี่คือการตัดสินใจด้านเส้นทาง และจะยังถูกต้องตราบเท่าที่ไม่มีใครเพิ่มเส้นทางเริ่มต้นลงในตารางร่วม
หากคำนำหน้าทับซ้อนกัน การกำหนดเส้นทางเพียงอย่างเดียวไม่สามารถแยกได้ คุณต้องมีบริบทเครือข่ายที่แตกต่างต่อผู้เช่า หรือแผนการแปลที่ให้ความหมายชัดเจนกับพื้นที่ของลูกค้าแต่ละราย
การแยกของ Transit Gateway หมายความว่าอย่างไรจริง ๆ
การเชื่อมโยงและการเผยแพร่คือสองปุ่มที่สำคัญ และสับสนได้ง่าย การเชื่อมโยงตอบว่าแพ็กเก็ตจากสิ่งที่แนบนี้ถูกค้นหาในตารางใด การเผยแพร่ตอบว่าตารางใดเรียนรู้เส้นทางของสิ่งที่แนบนี้ การแยกเกิดจากการทำให้ทั้งสองเฉพาะเจาะจงต่อผู้เช่า ไม่ใช่จากการสร้างสิ่งที่แนบเพิ่ม
การตั้งค่าเริ่มต้นแบบทุกคนถึงทุกคนนั้นสะดวกและไม่ใช่การแยก ตารางกำหนดเส้นทางแยกจำกัดการเชื่อมต่อ แต่ไม่ได้ให้ที่อยู่ปลายทางเดียวที่ไม่เปลี่ยนแปลงมีความหมายสองอย่างในบริบทเส้นทางเดียวกัน หากแอปพลิเคชันแก้ไข 10.20.0.10 ก่อนรู้จักผู้เช่า ชั้นกำหนดเส้นทางได้สูญเสียข้อมูลที่จำเป็นไปแล้ว
AWS เพิ่ม NAT 1:1 ระดับสิ่งที่แนบสำหรับ Transit Gateway และ Cloud WAN เมื่อวันที่ 23 ตุลาคม 2026 ซึ่งเปลี่ยนคำตอบเรื่องการทับซ้อนสำหรับสิ่งที่แนบที่รองรับ เอกสาร NAT ของ Transit Gateway อธิบายการแมป IPv4 แบบคงที่ ไม่มีสถานะ และคำนำหน้าเท่ากันโดยรักษาบิตโฮสต์ไว้ ตรวจสอบประเภทสิ่งที่แนบที่รองรับและข้อจำกัดระดับภูมิภาคก่อนออกแบบโดยอิงสิ่งนี้
ผูกงานกับผู้เช่าที่ตรวจสอบแล้ว
ทุกงานควรพาตัวตนผู้เช่าที่เซิร์ฟเวอร์ตรวจสอบแล้ว และตัวตนนั้นควรเลือกบันทึกการเชื่อมต่อที่ผู้ดูแลระบบเป็นเจ้าของ บันทึกระบุบริบทเครือข่ายที่อนุมัติ ที่อยู่บริการ การอ้างอิงข้อมูลรับรอง และการดำเนินการที่อนุญาตที่นั่น คำขอที่ไม่น่าเชื่อถือต้องไม่จัดหาตัวระบุ VPN เกตเวย์ หรือเป้าหมายส่วนตัวของตนเอง เพราะการเข้าสู่ระบบที่ถูกต้องไม่ใช่สิทธิ์ในการตรวจสอบพื้นที่ที่อยู่ของลูกค้าที่เชื่อมต่อทุกราย
ในการออกแบบตัวเชื่อมต่อที่แยกจากกัน งานของผู้เช่า A ไปยังตัวเชื่อมต่อเฉพาะ A ที่ทำงานใน VPC ของ A และเข้าถึงได้เฉพาะทรัพยากรที่อนุมัติของ A คอนเทนเนอร์แยกบนโฮสต์เดียวไม่ได้สร้างการแยกนั้นเอง เนมสเปซเครือข่าย เส้นทาง และนโยบายขาออกต้องนำไปปฏิบัติ ตัวเชื่อมต่อยังต้องการข้อมูลรับรองและคิวที่จำกัดตามผู้เช่า เพราะเส้นทางส่วนตัวไม่ได้จำกัดความลับร่วมหรือรายการงานร่วม เวิร์กเกอร์แอปพลิเคชันแบบรวมศูนย์ใช้ได้ตราบเท่าที่เลือกบริบทเครือข่ายและข้อมูลรับรองตามผู้เช่า ไม่ใช่ตามโฮสต์
การตรวจสอบสุขภาพควรระบุผู้เช่าและขั้นตอน อุโมงค์ที่สร้างแล้ว เส้นทางที่มีอยู่ และคำขอบริการจริงที่สำเร็จคือสามสัญญาณที่แตกต่างกัน การนับอุโมงค์ที่ทำงานรวมกันจะซ่อนลูกค้ารายเดียวที่ตัวเชื่อมต่อเสีย
ทดสอบเส้นทางที่ต้องล้มเหลว
ทำการทดสอบสามอย่างก่อนเปิดตัว การดำเนินการ A ที่อนุญาตต้องสำเร็จ การดำเนินการ B ที่อนุญาตต้องสำเร็จ และงาน A ที่จงใจมุ่งไปยังตัวเชื่อมต่อของ B หรือนามแฝงที่แปลแล้วต้องล้มเหลวแบบปิด จากนั้นตัดอุโมงค์หนึ่งเส้นและยืนยันว่างานล้มเหลวเฉพาะผู้เช่านั้น โดยไม่ถอยไปยังซับเน็ตหมายเลขเดียวกันของลูกค้ารายอื่น ควรทดสอบการกู้คืนด้วย เพราะเส้นทางเก่าหรือข้อมูลรับรองที่แคชไว้อาจอยู่ได้นานกว่าการหยุดชะงัก
สถาปัตยกรรมอาจเป็นเวิร์กเกอร์แบบรวมศูนย์ที่มีตัวเชื่อมต่อแยกจากกัน หรือทรัพยากรผู้เช่าที่แยกจากกันโดยสิ้นเชิง สิ่งที่ไม่เปลี่ยนแปลงคือ บริบทผู้เช่าที่ตรวจสอบแล้วเลือกเส้นทางและข้อมูลรับรอง และการเปลี่ยนเส้นทางไม่เคยให้สิทธิ์แอปพลิเคชันข้ามผู้เช่า