ประกาศ BGP ของ VGW เทียบกับตารางเส้นทางของ VPC: อะไรเปลี่ยนอะไร

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

ตั้งชื่อสิ่งที่เชื่อมต่อก่อนอ่านตารางใด ๆ

VPN แบบไซต์ถึงไซต์สิ้นสุดที่เกตเวย์ส่วนตัวเสมือนหรือเกตเวย์ขนส่ง และรหัสทรัพยากรเป็นตัวกำหนดว่าจะใช้รูปแบบการกำหนดเส้นทางใด อ่านสิ่งเหล่านี้ก่อน: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}' คำตอบจะบอกว่าตารางถัดไปที่ต้องตรวจสอบคือตารางเส้นทางของ VPC หรือตารางเส้นทางของเกตเวย์ขนส่ง

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

ทิศทางจาก AWS ไปยังสำนักงานคือการประกาศ

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

กฎง่าย ๆ มีข้อยกเว้น จึงควรจำกัดขอบเขตให้อยู่ในกรอบ การจัดวางแบบ VPN CloudHub สามารถประกาศคำนำหน้าของไซต์ซ้ำระหว่างเกตเวย์ของลูกค้า และเกตเวย์ขนส่งก็มีกฎการกระจายเส้นทางของตนเอง ข้อความที่ว่า VGW ประกาศเฉพาะ VPC ของตนเป็นค่าตั้งต้นที่เป็นประโยชน์ ไม่ใช่กฎหมายที่ครอบคลุมทุกโครงสร้างที่คุณจะพบ

ทิศทางจากสำนักงานไปยัง AWS คือการกระจายเส้นทางบวกการเลือก

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

อ่านแหล่งที่มาแทนการสันนิษฐาน: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes' รายการที่มีแหล่งที่มา EnableVgwRoutePropagation มาจาก BGP ส่วนรายการที่มีแหล่งที่มา CreateRoute ถูกพิมพ์โดยมนุษย์และจะชนะต่อไปจนกว่าจะมีคนลบมัน

คู่มือปฏิบัติที่แยกสองทิศทางออกจากกัน

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

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

สิ่งที่ไม่ควรเปลี่ยนขณะอยู่ที่นั่น

อย่าเปิดหรือปิดการกระจายเส้นทางบนตารางเส้นทางที่ไม่เกี่ยวข้องเพื่อแก้คำนำหน้าที่หายไปเพียงหนึ่งรายการ และอย่าเพิ่มเส้นทางเริ่มต้นเพื่อกลบ CIDR ที่หายไปเพียงรายการเดียว การเปลี่ยนแปลงทั้งสองขยายขอบเขตผลกระทบและทำให้การวินิจฉัยครั้งถัดไปยากขึ้น จำกัดการแก้ไขไว้ที่ตารางที่ให้บริการซับเน็ตของภาระงานที่พิจารณาเท่านั้น

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

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