VPN แบบไซต์ทูไซต์หนึ่งตัวสำหรับหลาย VPC บน AWS Transit Gateway

ไตรมาสนี้มี VPC สองตัวที่ต้องการเครือข่ายสำนักงาน และจุดที่ประมาณการแตกคืออุโมงค์ที่สอง AWS Transit Gateway ทำหน้าที่เป็นศูนย์กลางการกำหนดเส้นทางที่ใช้ร่วมกันได้ โดย VPN เชื่อมต่อครั้งเดียวและแต่ละ VPC เชื่อมต่อกับศูนย์กลางเดียวกัน จากนั้นเครือข่ายภายในองค์กรก็เข้าถึงทุก VPC ที่เชื่อมต่อผ่านการเชื่อมต่อเดียว สิ่งนี้เปลี่ยนว่าใครเป็นเจ้าของการตัดสินใจเรื่องเส้นทาง และนั่นคือส่วนที่การออกแบบส่วนใหญ่ทำผิด

การเชื่อมต่อ VPN และการเชื่อมต่อ VPC เป็นออบเจ็กต์แยกกันบนเกตเวย์เดียวกัน เพราะเหตุนี้ความสัมพันธ์ด้านเส้นทางจึงต้องสร้างขึ้นภายหลัง

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

ทำไมเพียริงไม่ใช่ทางลัดที่ผู้คนหวังไว้

ทางเลือกที่น่าดึงดูดคือการสิ้นสุด VPN ที่ VPC A แล้วเพียร์ VPC B เข้ากับมัน เพียริง VPC ทั่วไปไม่ได้ให้การส่งผ่านจากขอบถึงขอบผ่านการเชื่อมต่อ VPN ของ A เพียร์เข้าถึงได้เฉพาะที่อยู่ที่เพียริงให้มา และขอบ VPN ก็ไม่ใช่หนึ่งในนั้น การส่งผ่านคือสิ่งที่ศูนย์กลางให้ ส่วนเพียริงให้คู่หนึ่ง

ข้อจำกัดนั้นเป็นคุณสมบัติของเพียริง ไม่ใช่โควตาที่เพิ่มได้

การเชื่อมโยงและการเผยแพร่ทำงานต่างกัน

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

ศูนย์กลางเล็กที่เชื่อมต่อกันทั้งหมดเป็นกรณีที่ง่าย

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

เส้นทางของเวิร์กโหลดอยู่ที่อื่น

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

เลือกการกำหนดเส้นทางแบบไดนามิกหรือแบบคงที่อย่างตั้งใจ เพียริงไม่ได้ให้ทั้งสองอย่าง

แยกสาขาออกจากกันโดยไม่เสียการเข้าถึงภายใน

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

นี่คือการแยกเส้นทาง และไม่ใช่การอนุญาตระดับแอปพลิเคชัน

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

สิ่งที่ศูนย์กลางไม่ได้แก้

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

การเชื่อมต่อ VPN และเกตเวย์ส่งผ่านตอนนี้เป็นโครงสร้างพื้นฐานที่ใช้ร่วมกัน

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

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