AWS Site-to-Site VPN สู่ NAT Gateway: VGW หรือ Transit Gateway

ทุกคนวาดไดอะแกรมเดียวกันในครั้งแรก: VPN เข้า VPC แล้ว NAT gateway ออกสู่อินเทอร์เน็ต จบ แต่ AWS ไม่รองรับเส้นทางนั้นเมื่อ VPN สิ้นสุดที่ virtual private gateway และความล้มเหลวเงียบพอที่ทีมจะสร้างใหม่มากกว่าหนึ่งครั้ง การออกแบบที่ใช้ได้ต้องมี transit gateway ซึ่งเปลี่ยน gateway และตารางเส้นทางทั้งสองฝั่ง เปรียบเทียบทั้งสองรูปแบบก่อนวาดอะไร

โทโพโลยีที่ดูชัดเจนแต่ไม่รองรับ

เอกสาร NAT gateway ของ AWS ลากเส้นที่ทำให้ทุกคนที่เคยสร้างดีไซน์ VPC เดียวประหลาดใจ: ทราฟฟิกจาก Site-to-Site VPN ส่งต่อไปยัง NAT gateway ผ่าน virtual private gateway ไม่ได้ ประเภทของ gateway ที่ VPN สิ้นสุดเป็นตัวกำหนดว่ามีเส้นทางแปลอยู่หรือไม่ ความผิดพลาดยังอยู่เพราะสถานะทันเนลเป็น UP และอินสแตนซ์ EC2 ในซับเน็ตเดียวกันเข้าถึงอินเทอร์เน็ตได้โดยไม่มีปัญหา ทั้งสองการสังเกตไม่ได้ทดสอบทิศทางที่เสีย

ในทางปฏิบัติแพ็กเก็ตมาพร้อมที่อยู่ต้นทางจากเครือข่ายภายในและไม่พบฮอปถัดไปที่รองรับซึ่งจะแปลให้ ขึ้นกับตาราง แพ็กเก็ตจะถูกทิ้งที่ขอบขาออก และเนื่องจากทันเนลยังเป็น UP ขณะที่อินสแตนซ์ในซับเน็ตเดียวกันยังเข้าถึงอินเทอร์เน็ตได้ ความล้มเหลวจึงถูกรายงานว่าเป็นปัญหาไฟร์วอลล์ฝั่งองค์กร

Virtual private gateway กับ transit gateway

virtual private gateway เป็นของ VPC เดียว มันสิ้นสุด VPN ติดตั้งเส้นทางลงในตารางเส้นทางของ VPC นั้น และหยุดอยู่ตรงนั้น ไม่มีโมเดล attachment จึงส่งต่อทราฟฟิกให้ VPC อื่นหรือปล้องขาออกที่ใช้ร่วมกันไม่ได้ ขอบเขต VPC เดียวนี้คือข้อจำกัดทั้งหมด และไม่มีเส้นทางใดที่เพิ่มภายใน VPC จะเปลี่ยนได้

transit gateway คือศูนย์กลางระดับภูมิภาคที่ VPN, VPC spoke แต่ละแห่ง และ VPC สำหรับบริการร่วมปรากฏเป็น attachment มีตารางเส้นทางของตัวเองซึ่งเลือกว่า attachment ใดจะได้รับ prefix ที่กำหนด

ศูนย์กลางนี้ทำให้ขาออกแบบรวมศูนย์เป็นไปได้: VPN ลงจอดเป็น attachment หนึ่ง VPC ขาออกเป็นอีกอัน และตารางเส้นทางของ transit gateway ส่ง prefix ที่มุ่งสู่อินเทอร์เน็ตจากอันแรกไปยังอันที่สอง ด้วย virtual private gateway ไม่มี attachment ที่สองให้ส่งอะไรไป จึงไม่อาจเสริมดีไซน์ทีหลังได้

เส้นทางขาออกที่รองรับ ทีละฮอป

ดีไซน์อ้างอิงมีห้าฮอป และทุกศรคือการตัดสินใจด้านเส้นทางที่คุณต้องกำหนดค่า ทราฟฟิกออกจากเครือข่ายภายในเข้าสู่ attachment ของ Site-to-Site VPN ตารางของ transit gateway ส่งต่อไปยัง attachment ของ VPC ขาออก ซึ่งตารางซับเน็ตส่งต่อไปยัง NAT gateway สาธารณะ NAT gateway แปลที่อยู่ต้นทางและ internet gateway พาแพ็กเก็ตออกไป

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

สองรายละเอียดตัดสินว่าฮอปสุดท้ายจะทำงานหรือไม่ NAT gateway ต้องเป็นสาธารณะ มี elastic IP และเส้นทางไปยัง internet gateway เพราะ NAT gateway แบบส่วนตัวแปลระหว่างเครือข่ายและไม่เคยกลายเป็นทางออกอินเทอร์เน็ต

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

ดีไซน์เหล่านี้ล้มเหลวที่เส้นทางขากลับ

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

ตรวจสอบด้วยไคลเอนต์จริงหลัง VPN และดูว่ามันนำเสนอที่อยู่ต้นทางสาธารณะใด หากเป็น elastic IP ของ NAT gateway แสดงว่ามีการแปลอยู่ หากเป็นอย่างอื่น คุณกำลังวัดทางออกอื่น

รูปแบบอสมมาตรของความล้มเหลวนี้ควรรู้จักแต่เนิ่นๆ เมื่อตารางซับเน็ต NAT ของ Availability Zone หนึ่งมีเส้นทางกลับไปยัง prefix ของไคลเอนต์และอีกโซนไม่มี การเชื่อมต่อใหม่จะสำเร็จหรือล้มเหลวตามโซนที่โฟลว์ตกลงไป และรูปแบบนี้ถูกอ่านผิดว่าเป็นอินเทอร์เน็ตที่ไม่เสถียร เปรียบเทียบตารางซับเน็ตของทุกโซนที่คุณให้บริการแทนการแก้โซนที่เปิดตั๋ว เพราะเส้นทางที่ขาดคือความผิดพลาดทั้งหมดและอีกฝั่งไม่ต้องเปลี่ยนอะไร

เมื่อใด proxy แบบชัดเจนจึงเป็นดีไซน์ที่ดีกว่า

HTTP proxy บนอินสแตนซ์ใน VPC ขาออกเป็นทางเลือกที่ชอบด้วยกฎหมายและมักถูกกว่า ไคลเอนต์ถูกกำหนดค่าให้ใช้ proxy เปิดการเชื่อมต่อของตัวเองออกไป และเส้นทางขากลับกลายเป็นปัญหาของมันแทนที่จะเป็นปริศนาการกำหนดเส้นทางแบบสมมาตร สำหรับแอปพลิเคชันไม่กี่ตัว สิ่งนี้ตัดงานของ transit gateway ส่วนใหญ่ออกไป และยังให้บันทึกต่อผู้ใช้ที่ NAT gateway ผลิตไม่ได้

แต่มันไม่โปร่งใส สิ่งใดที่เพิกเฉยต่อการตั้งค่า proxy และทุกโปรโตคอลที่ไม่ใช่ HTTP จะไม่ไปตามเส้นทางนั้น

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