ขีดจำกัดของ Cloud VPN ที่ปรับแต่งไม่ได้: อายุของ IKE และ NAT ของเพียร์
Cloud VPN เจรจาอายุของ IKE ภายในขอบเขตคงที่และต้องการ NAT แบบหนึ่งต่อหนึ่งที่เพียร์ ออกแบบอุปกรณ์ระยะไกลโดยยึดสิ่งนั้น ไม่ใช่ยึดฝั่ง Google
ให้อุปกรณ์ระยะไกลมีอายุเฟส 1 ที่ 24 ชั่วโมง แล้วอุโมงค์ Cloud VPN จะยังคงล่มอยู่ แม้ว่าทุกอย่างฝั่ง Google จะกำหนดค่าถูกต้องแล้วก็ตาม เพียร์เสนอค่าที่ผู้ตอบจะไม่ยอมรับ การเจรจาจึงล้มเหลวทั้งหมดหรือเริ่มใหม่ไม่รู้จบ Cloud VPN จำกัดเฟส 1 ไว้ที่ 36,000 วินาที หรือสิบชั่วโมง และเพดานนี้ไม่ใช่การตั้งค่าที่คุณจะเพิ่มได้ การแก้ไขอยู่ที่อุปกรณ์ระยะไกล
เพียร์ถาม ผู้ตอบตัดสิน
IKE คือการจับคู่ระหว่างชุดข้อเสนอสองชุด อุโมงค์จะเกิดขึ้นเฉพาะจุดที่ชุดทั้งสองซ้อนทับกันภายในขอบเขตที่ผู้ตอบยอมรับ ด้วยเหตุนี้อายุที่อยู่นอกช่วงจึงไม่สร้างอุโมงค์บางส่วนเลย ข้อผิดพลาดทั่วไปคือมองว่าการกำหนดค่าของเพียร์เป็นรายการความต้องการแทนที่จะเป็นข้อเสนอ จุดตัดที่เป็นศูนย์ทำให้อุโมงค์ยังล่มอยู่ ไม่ว่าการกำหนดเส้นทางและตัวเลือกจะถูกต้องเพียงใด
อ่านสถานะของอุโมงค์เองก่อนเปิดเคส เพราะสถานะโดยละเอียดมักระบุเฟสที่ล้มเหลว:
gcloud compute vpn-tunnels describe office-tunnel \
--region europe-west1 \
--format="value(status,detailedStatus)"
เปรียบเทียบสิ่งที่ได้กลับมากับชุดที่รองรับสำหรับประเภทเกตเวย์และเวอร์ชัน IKE ของคุณ และบันทึกตัวเลือกทราฟฟิกทั้งสองขณะอยู่ที่นั่น ตัวเลือกไม่ตรงกันให้อาการอุโมงค์ล่มเหมือนอัลกอริทึมไม่ตรงกัน และต่างจากอัลกอริทึม เรื่องนี้คุณต้องแก้เอง
36,000 วินาทีคือเพดาน
เฟส 1 หยุดที่ 36,000 วินาที อุปกรณ์ที่ตั้งไว้ 86,400 กำลังขอสิ่งที่ผู้ตอบจะไม่มีวันยอมรับ และการลองใหม่ไม่เปลี่ยนใจ Cloud VPN คืนข้อเสนอระยะไกลให้อยู่ในช่วง แล้วการกำหนดค่าเดิมจะสร้างขึ้นได้ ความไม่สมมาตรคือบทเรียนทั้งหมด เพราะคุณลดค่าของตัวเองได้แต่เพิ่มค่าของ Google ไม่ได้
เขียนค่าที่เลือกลงในบันทึกการออกแบบ ไม่เช่นนั้นวิศวกรคนต่อไปจะทำการทดลอง 24 ชั่วโมงซ้ำและชนกำแพงเดิม
ชุดที่รองรับเผยแพร่ตามประเภทเกตเวย์และเวอร์ชัน IKE ใน ภาพรวม Cloud VPNดังนั้นจงอ่านส่วนสำหรับโทโพโลยีของคุณ ไม่ใช่คู่มือ IKE ทั่วไป
อุโมงค์ที่ล่มตามกำหนดเวลา
เฟส 2 ทำงานต่างออกไป เมื่อปลายทั้งสองไม่ตรงกัน การต่ออายุคีย์จะเป็นไปตามช่วงที่สั้นกว่า เพียร์ที่ถือว่าความไม่ตรงกันเป็นเรื่องร้ายแรงจะปล่อยอุโมงค์ล่มแทน ความไม่ตรงกันเพียงอย่างเดียวจึงดูเหมือนความผิดพลาดสองอย่างที่ไม่เกี่ยวข้องกัน ดูจังหวะการต่ออายุคีย์ ไม่ใช่แค่การเชื่อมต่อครั้งแรก อุโมงค์ที่ขึ้นแล้วล่มเป็นจังหวะสม่ำเสมอ มักเป็นความไม่ตรงกันของอายุมากกว่าข้อบกพร่องของการกำหนดเส้นทาง
เชื่อมเวลาที่ล่มเหล่านั้นกับบันทึกของเพียร์เองก่อนแก้ไขสิ่งใด เพราะการเปลี่ยนตัวเลือกหรือเส้นทางสามารถเลียนแบบจังหวะเดียวกันได้ หากจังหวะตรงกับตัวจับเวลาเฟส 2 แสดงว่าพบสาเหตุแล้วโดยไม่ต้องแตะข้อเสนอ
ชุดเหล่านี้มาจากประเภทเกตเวย์
ชุดการเข้ารหัสและความสมบูรณ์ไม่ใช่โปรไฟล์ต่ออุโมงค์ที่คุณแก้ไขอย่างที่ strongSwan ทำได้ คุณเลือกตามประเภทเกตเวย์และเวอร์ชัน IKE และการตามหโปรไฟล์ที่ไม่มีอยู่ทำให้เสียเวลาหนึ่งบ่าย
อุปกรณ์เก่าที่ไม่เสนอสิ่งใดภายในชุดที่รองรับเหลือทางตรงไปตรงมาสองทาง คือเปลี่ยนอุปกรณ์ หรือไปสิ้นสุดที่เกตเวย์ซอฟต์แวร์ที่คุณควบคุมแล้วกำหนดเส้นทางเข้าสู่ VPC จากที่นั่น สิ่งอื่นใดคือทางอ้อมที่จะตกในการตรวจสอบครั้งถัดไป
ที่อยู่ภายนอกหนึ่งรายการต่ออุปกรณ์
ที่อยู่ภายนอกของเพียร์ต้องแมปแบบหนึ่งต่อหนึ่งกับที่อยู่ภายใน พูล PAT ที่โอเวอร์โหลดใช้งานไม่ได้ เพราะโฮสต์หลายเครื่องหลังที่อยู่สาธารณะเดียวไม่เปิดทางให้ผู้ตอบแยกแยะพวกมัน เมื่อโฮสต์หลายเครื่องต้องใช้ที่อยู่ร่วมกัน อุโมงค์ต้องสิ้นสุดที่จุดซึ่งแยกแยะพวกมันได้
รักษาที่อยู่ภายนอกนั้นให้คงที่ด้วย ย้ายอุปกรณ์ไปหลัง NAT อื่นแล้วความสัมพันธ์จะขาดแม้ทุกข้อเสนอยังตรงกัน ควรจดว่าค่าใดเป็นของ Google และค่าใดเป็นของคุณ อายุ ชุด และ NAT หนึ่งต่อหนึ่งถูกตรึงไว้ฝั่งเขา ส่วนข้อเสนอ ตัวเลือก การกำหนดเส้นทาง และลำดับความสำคัญ BGP เป็นของคุณ