Transit Gateway ที่แชร์ร่วมกัน: ใครเป็นเจ้าของเส้นทางใน AWS RAM
การแชร์ผ่าน RAM ทำให้บัญชีอื่นเชื่อมต่อ VPC ได้ แต่ตารางเส้นทาง ความเชื่อมโยง และการเผยแพร่ยังอยู่กับเจ้าของเกตเวย์ นี่คือขอบเขต
การแชร์ Transit Gateway ด้วย Resource Access Manager ทำสิ่งเดียวที่เฉพาะเจาะจง คือเปิดให้บัญชีอื่นเรียกชุด API การเชื่อมต่อที่กำหนดไว้กับทรัพยากรที่ตนไม่ได้เป็นเจ้าของ มันไม่ได้โอนเกตเวย์ ตารางเส้นทาง หรือสิทธิ์ในการตัดสินใจว่าทราฟฟิกจะถูกส่งต่ออย่างไร ผู้คนมักเข้าใจผิดเพราะการเชื่อมต่อปรากฏในคอนโซลของผู้รับและทำงานได้ทันที ซึ่งรู้สึกเหมือนความเป็นเจ้าของ กลไกเบื้องหลังคือการให้สิทธิ์บนทรัพยากรที่แชร์ และออบเจ็กต์ลูกทุกตัวยังอยู่ในขอบเขตบัญชีของเจ้าของ การแยกส่วนนี้อธิบายตั๋วการปฏิเสธการเข้าถึงส่วนใหญ่ที่เกี่ยวกับทรานซิตที่แชร์
การแชร์มอบหมายอะไรจริง ๆ
การแชร์ทรัพยากรระบุทรัพยากร ตัว principal และสิทธิ์ที่จัดการ สิทธิ์จะระบุการกระทำที่ principal นั้นทำได้ และสำหรับ Transit Gateway รายการนั้นครอบคลุมการดำเนินการเชื่อมต่อบนทรัพยากรที่แชร์
สิ่งใดก็ตามนอกรายการจะล้มเหลวที่ API ไม่ใช่ที่คอนโซล นั่นคือเหตุผลที่ข้อผิดพลาดมักปรากฏเมื่อรันสคริปต์ครั้งแรก
ตารางเส้นทาง ความเชื่อมโยง และการเผยแพร่ยังอยู่กับเจ้าของ
การส่งต่อถูกกำหนดโดยออบเจ็กต์ลูกสามตัว คือการเชื่อมต่อผูกกับตารางเส้นทางใด มันเผยแพร่ไปยังตารางใด และตารางเหล่านั้นมีเส้นทางอะไรบ้าง เอกสารการแชร์ของ AWS ระบุว่าผู้รับไม่สามารถสร้าง แก้ไข หรือลบตารางเส้นทางของเกตเวย์ทรานซิตหรือความเชื่อมโยงและการเผยแพร่ผ่านการแชร์ได้ การเรียกเหล่านั้นเป็นของบัญชีเจ้าของ ผู้รับที่ต้องการความเชื่อมโยงใหม่กำลังขอการเปลี่ยนแปลงเชิงบริหาร ไม่ได้ใช้สิทธิ์ที่ลืมเปิดใช้งาน
ตารางด้านล่างคือการแบ่งส่วนที่ฉันใส่ในเอกสารออกแบบ เพราะมันอยู่รอดเมื่อบุคลากรเปลี่ยน
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
อ่านแถวกลางอย่างระมัดระวัง เจ้าของ VPC ควบคุมเส้นทางซับเน็ตของตน เจ้าของเกตเวย์ควบคุมการตัดสินใจส่งต่อส่วนกลาง และเส้นทางที่ใช้งานได้ต้องมีทั้งสองอย่าง ไม่มีบัญชีใดบัญชีหนึ่งทำเสร็จคนเดียวได้
เส้นทางเดียว สองบัญชี
ติดตามแพ็กเก็ตจาก VPC spoke ไปยังคำนำหน้าในองค์กร ตารางเส้นทางของซับเน็ต spoke ต้องส่งคำนำหน้านั้นไปยังการเชื่อมต่อเกตเวย์ทรานซิต ซึ่งเจ้าของ VPC เปลี่ยนได้ จากนั้นเกตเวย์ต้องมีเส้นทางในตารางที่เชื่อมโยงของการเชื่อมต่อซึ่งชี้ไปยังการเชื่อมต่อ VPN ซึ่งมีเพียงเจ้าของที่เปลี่ยนได้ ทราฟฟิกขากลับต้องมีเงาสะท้อนของทั้งสอง พลาดฝั่งใดฝั่งหนึ่งคุณจะได้ เส้นทางที่ติดตั้งครึ่งเดียวซึ่งดูเหมือนปัญหาไฟร์วอลล์
เขียนการเปลี่ยนแปลงทั้งสองลงในตั๋วเดียวพร้อมผู้รับผิดชอบสองคน ไม่อย่างนั้นจะเสร็จคนละสัปดาห์
ใช้ ID โซนความพร้อมใช้งานเมื่อตำแหน่งสำคัญ
ชื่อโซนเป็นนามแฝงเฉพาะบัญชี us-east-1a ในบัญชีหนึ่งไม่รับประกันว่าจะเป็นโซนทางกายภาพเดียวกับ us-east-1a ในอีกบัญชี เมื่อการออกแบบต้องการการเชื่อมต่อและเวิร์กโหลดในโซนเดียวกัน ให้เปรียบเทียบ ID ของ AZ และบันทึกไว้
การเปรียบเทียบชื่อให้แผนภาพที่ดูถูกต้องและโปรไฟล์ความหน่วงที่ไม่ถูกต้อง ตรวจสอบขณะที่แผนภาพยังถูกวาดอยู่ ไม่ใช่หลังจากมีคนวัดความแตกต่างแล้ว
การยกเลิกการแชร์ไม่ได้ตัดเส้นทางข้อมูล
การลบการแชร์รู้สึกเหมือนการเพิกถอน และไม่ใช่การหยุดทราฟฟิกทันที AWS เอกสารว่าการเชื่อมต่อยังทำงานได้เมื่อเกตเวย์ถูกถอดออกจากการแชร์ สิทธิ์ในการจัดการทรัพยากรหายไป ขณะที่การเชื่อมต่อที่มีอยู่ยังส่งต่อจนกว่าจะมีคนลบหรือปิดใช้งาน วางแผนการเพิกถอนเป็นสองขั้นตอน คือลบการแชร์ แล้วจึงลบการเชื่อมต่อ โดยเจ้าของเป็นผู้ทำขั้นที่สอง
ถ้าการแชร์เป็นการควบคุมเดียวของคุณ คุณก็ไม่มีการควบคุม
เก็บบันทึกการแชร์และบันทึกการกำหนดเส้นทางไว้ด้วยกัน
สองสิ่งตอบคำถามที่แตกต่างกันสองข้อ บันทึกการแชร์บอกว่าใครทำงานกับทรัพยากรได้ ตารางเส้นทางบอกว่าเครือข่ายใดสื่อสารกันได้จริง เก็บทั้งสองไว้ด้วยกันพร้อมรายชื่อเจ้าของเดียวกัน ไม่อย่างนั้นเหตุการณ์ครั้งหน้าจะเริ่มด้วยคนที่พิสูจน์สิทธิ์ที่ไม่เคยเป็นปัญหา
จากนั้นทดสอบหนึ่งโฟลว์ในแต่ละทิศทางและหนึ่งคำนำหน้าที่ควรเข้าถึงไม่ได้