GCP HA VPN: เซสชัน BGP ค้างที่ Waiting for peer และการสลับคู่ที่อยู่

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

คำถามเดียวตัดสินได้เกือบทุกกรณี: อุปกรณ์คู่ค้ามองเห็นที่อยู่ของ Cloud Router หรือไม่

สถานะอุโมงค์กับสถานะเซสชันเป็นการตรวจคนละอย่าง

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

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

แต่ละอุโมงค์ต้องมี /30 ของตัวเองโดยเติมปลายทั้งสองข้าง

อุโมงค์ HA VPN ทุกอุโมงค์ได้ /30 แบบ link-local จาก 169.254.0.0/16 โดยที่อยู่หนึ่งอยู่บนอินเทอร์เฟซของ Cloud Router และอีกอันอยู่บนคู่ค้าของคุณ ฟิลด์คู่ค้าต้องระบุปลายทางไกล ไม่ใช่ที่อยู่ของเราเตอร์เอง

อุโมงค์สองอุโมงค์หมายถึงอินเทอร์เฟซสองอันบน Cloud Router แต่ละอันมี /30 ต่างกัน การนำคู่ของอุโมงค์ 0 ไปใช้ซ้ำกับอุโมงค์ 1 คือความผิดพลาดที่ดูเรียบร้อยในตารางสรุปและตายในแพ็กเก็ต OPEN

อ่านคู่ที่อยู่จากรีซอร์สของเราเตอร์ ไม่ใช่จากสรุปในคอนโซล สรุประบุที่อยู่ของคู่ค้าในคอลัมน์ที่อ่านผิดได้ง่าย และ ipRange ของอินเทอร์เฟซกับ peerIpAddress ของคู่ค้าต้องอธิบายปลายตรงข้ามของ /30 เดียวกัน

การสลับมักเกิดขึ้นระหว่างการสร้างใหม่

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

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

อีกสามสาเหตุที่เซสชันต้องรอ

อย่างแรกคือ ASN ของคู่ค้า: แต่ละฝั่งต้องถูกกำหนดด้วย ASN ของอีกฝั่ง และความไม่ตรงกันจะไปถึงคู่ค้าแต่ไม่มีวันสถาปนา อย่างที่สองคือไฟร์วอลล์ของคู่ค้าเอง ซึ่งต้องอนุญาต TCP 179 บนอินเทอร์เฟซของอุโมงค์ กฎ IKE หรือ ESP ไม่ครอบคลุมสิ่งนั้น อย่างที่สามคือคู่ค้าที่ตอบกลับจากที่อยู่ต้นทางอื่นที่ไม่ใช่ที่อยู่ที่กำหนดไว้เป็นเพื่อนบ้าน

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

ตรวจตามลำดับที่แพ็กเก็ตเดินทาง

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

gcloud compute routers get-status ROUTER --region=REGION พิมพ์สถานะคู่ค้าไว้ข้างที่อยู่ที่มันใช้อยู่ และนั่นคือคู่ที่คุณต้องเปรียบเทียบ

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