เพิ่มซับเน็ตภายในองค์กรให้กับ AWS VPN: VGW กับ Transit Gateway

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

ประกาศเพรฟิกซ์ที่เกตเวย์ส่งได้จริง

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

รักษาการรวมเส้นทางและเส้นทางที่เจาะจงกว่าไว้อย่างตั้งใจ เส้นทางที่ซ้อนทับกันซึ่งมาจากสองทิศทางเป็นการตัดสินใจออกแบบ ไม่ใช่รายละเอียดที่ค่อยไปค้นพบทีหลัง

เส้นทางที่หนึ่ง: ขอบเขตของเกตเวย์ส่วนตัวเสมือน

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

เซสชัน BGP ที่แข็งแรงพิสูจน์ว่าช่องทางมีอยู่ ไม่ได้บอกอะไรว่าตารางซับเน็ตที่กำหนดได้รับเส้นทางนั้นหรือไม่

เส้นทางที่สอง: transit gateway เพิ่มตารางอีกหนึ่ง

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

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

การกระจายเส้นทางก็ไม่ได้ให้เพรฟิกซ์กับทุกสิ่งที่แนบ มันกระจายไปยังตารางที่กำหนดค่าให้รับ

เส้นทางขากลับเป็นการตัดสินใจเชิงนโยบายของตัวเอง

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

การซ้อนทับที่อยู่คือกับดักอีกอย่าง ช่วงที่แยกจากกันและมีเจ้าของชัดเจนทำให้เรื่องนี้เรียบง่าย ช่วงที่ซ้อนทับกันหมายถึงการแปลที่อยู่หรือการออกแบบใหม่ และทั้งสองไม่ใช่ทางเลือกที่แลกเปลี่ยนกันได้ของสูตรเดียวกัน

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

เมื่อพร็อกซีเป็นขอบเขตที่ดีกว่าจริง ๆ

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

ตัดสินใจตามลำดับนี้: การส่งต่อภายใน การประกาศ ขอบเขตตาราง นโยบายการส่งกลับ แก้ไขสิ่งแรกที่ล้มเหลว แล้วจึงถามว่าเส้นทางที่กำหนดเส้นทางแล้วเป็นคำตอบที่ถูกต้องหรือไม่