VPN บนคลาวด์ต้องใช้ BGP: ทำไมโปรโตคอลกำหนดเส้นทางอื่นจึงล้มเหลว

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

อุโมงค์เชื่อมต่ออยู่แต่เส้นทางหายไป

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

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

ผู้ให้บริการมอบอะไรให้คุณจริง ๆ

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

Google Cloud เอกสารการกำหนดเส้นทาง BGP แบบไดนามิกสำหรับ HA VPN โดย Cloud Router เรียนรู้เส้นทางของเพื่อนบ้านและจัดหาเส้นทางไดนามิกที่กำหนดเองซึ่งมีสิทธิ์ให้กับ VPC AWS Site-to-Site VPN เอกสารการเลือกระหว่างการกำหนดเส้นทางแบบคงที่และแบบไดนามิก และอธิบายการตรวจสอบความมีชีวิตของ BGP ว่ามีประโยชน์สำหรับการสลับอุโมงค์ พร้อมทั้งรองรับการตรวจสอบสุขภาพสำหรับอุปกรณ์ที่ไม่มี BGP ด้วย ไม่ควรอนุมานพฤติกรรมของแพลตฟอร์มหนึ่งจากชื่อผลิตภัณฑ์ของอีกแพลตฟอร์ม

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

การป้องกันอุโมงค์และการเข้าถึงเป็นงานแยกกัน

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

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

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

จุดที่สมมติฐานเกี่ยวกับ OSPF พังทลาย

OSPF, IS-IS หรือโปรโตคอลอื่นภายในอุโมงค์ IPsec เป็นไปได้อย่างสมบูรณ์บนอุปกรณ์ที่จัดการเอง ซึ่งคุณเป็นเจ้าของทั้งสองปลายและการออกแบบการส่งต่อ ข้อเท็จจริงนั้นไม่ได้บอกอะไรเกี่ยวกับบริการแบบจัดการที่เสนอเพียง BGP เป็นโหมดการกำหนดเส้นทางแบบไดนามิก

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

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

อ่านข้อกำหนดของบริการแล้วจึงออกแบบ

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

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

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