GCP BYOIP: การประกาศสาธารณะไม่ใช่เส้นทางส่วนตัว
การแบ่งพรีฟิกซ์ BYOIP ระหว่างไซต์กับคลาวด์ต้องใช้สองแผน แยกการประกาศสาธารณะ การมอบหมาย และฮอปถัดไปแบบส่วนตัวออกจากกัน
บล็อกสาธารณะส่วนหนึ่งอยู่ที่ไซต์และอีกส่วนย้ายเข้า Google Cloud ประโยคนั้นอธิบายสองแผน ไม่ใช่แผนเดียว คือแผนประกาศบนอินเทอร์เน็ตและแผนส่งต่อแบบส่วนตัว การมองทั้งสองเป็นปัญหาเราเตอร์เดียวคือจุดที่การออกแบบ BYOIP ผิดพลาด
ออบเจ็กต์ที่เกี่ยวข้องตอบคำถามต่างกัน และมีเพียงตัวเดียวที่เกี่ยวกับว่าส่งแพ็กเก็ตต่อไปที่ใด
สามออบเจ็กต์ สามคำถาม
พรีฟิกซ์ที่ประกาศต่อสาธารณะคือหน่วยที่ Google ประกาศบนอินเทอร์เน็ตในนามของคุณ พรีฟิกซ์ที่มอบหมายต่อสาธารณะคือวิธีที่พื้นที่นำเข้าถูกจัดสรรให้ทรัพยากร Cloud ที่รองรับ เส้นทาง VPC ซึ่งรวมถึงเส้นทางที่เรียนรู้ผ่าน Cloud Router จาก VPN จะเลือกฮอปถัดไปแบบส่วนตัว แต่ละอย่างมีขอบเขตของตัวเอง มี API ของตัวเอง และมีข้อความข้อผิดพลาดของตัวเอง
เวอร์ชันตารางสั้นกว่า
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
มีเพียงแถวที่สามที่เกี่ยวกับการส่งต่อภายในเครือข่ายของคุณ
คำเตือนการทับซ้อนของ BYOIP ครอบคลุมอะไร
เอกสาร BYOIP ของ Google มองพรีฟิกซ์ที่ประกาศเป็นหน่วยประกาศ และเตือนเกี่ยวกับการประกาศภายนอกที่ทับซ้อนกัน รวมถึงพรีฟิกซ์ย่อยที่ประกาศนอก Google คำเตือนนั้นเกี่ยวกับแผนประกาศสาธารณะ ไม่ใช่ข้อความเกี่ยวกับทุกเส้นทางส่วนตัวที่คุณอาจเพิ่ม
การมอบหมายการจัดสรรที่เล็กกว่าภายในพรีฟิกซ์ที่นำเข้า ไม่ได้ให้สิทธิ์คุณโดยตัวมันเองในการประกาศส่วนที่เหลือจากต้นทางอื่น
ถามคำถามในแง่ของใครประกาศอะไร หาก Google ประกาศพรีฟิกซ์ที่นำเข้าทั้งหมด ต้นทางที่สองซึ่งประกาศพรีฟิกซ์ย่อยจะสร้างการทับซ้อนตามที่เอกสารเตือนไว้พอดี ไม่ว่าเส้นทาง VPC ของคุณจะดูเรียบร้อยเพียงใด
เส้นทางส่วนตัวตัดสินอะไร
พรีฟิกซ์ที่เรียนรู้ผ่าน VPN ไม่ใช่การประกาศบนอินเทอร์เน็ต และ BGP ปริมาณเท่าใดก็ไม่ทำให้เป็นเช่นนั้น มันคือรายการในตารางเส้นทาง VPC ที่บอกว่าอุโมงค์หรือเกตเวย์ใดควรขนส่งทราฟฟิกไปยังปลายทางนั้น การที่รายการนั้นมีคุณสมบัติ ได้รับเลือก หรือใช้งานได้ ขึ้นอยู่กับกฎการเราเตอร์ของ VPC เอง
การจับคู่พรีฟิกซ์ที่ยาวที่สุดใช้ภายในตารางเส้นทาง ดังนั้นเส้นทาง VPN ที่ยาวกว่าจึงชนะได้ในท้องถิ่นโดยไม่เปลี่ยนสิ่งใดที่ขอบสาธารณะ
การแบ่งพรีฟิกซ์: การตัดสินใจที่มาก่อน
หากสถาปัตยกรรมต้องการให้ครึ่งหนึ่งของบล็อกประกาศจากศูนย์ข้อมูลและอีกครึ่งจาก Google ให้ตัดสินแผนประกาศก่อนนำเข้าสิ่งใด ตอกย้ำว่าช่วงใดที่ Google อาจประกาศ ช่วงใดยังคงประกาศอยู่ที่อื่น และทั้งสองทับซ้อนกันหรือไม่ จากนั้นออกแบบเส้นทางส่วนตัวสำหรับแต่ละปลายทางและเส้นทางขากลับ หากผู้ให้บริการไม่รองรับการแบ่งที่คุณต้องการ ให้เปลี่ยนการแบ่งแทนที่จะหวังว่าพรีฟิกซ์ VPN ที่ยาวกว่าจะยกเลิกการตัดสินใจที่ขอบสาธารณะ
ลำดับนั้นสำคัญเพราะแผนที่สองไม่อาจซ่อมแผนแรกได้
ตรวจสอบทั้งสองแผนแยกกัน
ตรวจสอบด้านสาธารณะด้วย gcloud compute public-advertised-prefixes list และยืนยันช่วงและสถานะ ตรวจสอบด้านส่วนตัวด้วย gcloud compute routes list และ gcloud compute routers get-status ซึ่งแสดงว่า BGP แลกเปลี่ยนอะไรจริง
ชุดเอาต์พุตหนึ่งบอกคุณว่าอินเทอร์เน็ตเห็นอะไร อีกชุดบอกว่าทราฟฟิกของคุณไปที่ใด ไม่มีชุดใดแทนที่อีกชุด