สถานะ Cloud VPN: อ่านสถานะของรีซอร์สก่อนบันทึก IKE
อุโมงค์ที่ได้รับการจัดการรายงานการจัดสรร IKE และทราฟฟิกที่กำหนดเส้นทางเป็นขั้นตอนแยกกัน จับคู่วัตถุหนึ่งชิ้นกับช่วงเวลาหนึ่งช่วงก่อนแก้ไขเพียร์
อุโมงค์ Cloud VPN รันวงจรชีวิตสองวงพร้อมกัน และทั้งสองไม่ได้อยู่บนนาฬิกาเดียวกัน รีซอร์สต้องได้รับการจัดสรรและกำหนดค่าก่อนจึงจะเจรจาได้ และหลังจากนั้นโปรโตคอลก็มีลำดับข้อความ IKE ของตัวเอง ฟิลด์สถานะอาจรายงานส่วนแรกโดยไม่บอกอะไรที่มีประโยชน์เกี่ยวกับส่วนที่สอง การอ่านทั้งสองเป็นสิ่งเดียวกันคือวิธีที่ความไม่ตรงกันของคีย์ถูกกล่าวโทษว่าเป็นสาเหตุของความล่าช้าในการจัดเตรียม
เริ่มด้วยวัตถุอุโมงค์หนึ่งชิ้นและช่วงเวลาหนึ่งช่วง
สองวงจรชีวิต วัตถุอุโมงค์หนึ่งชิ้น
วงจรชีวิตของรีซอร์สคือผู้ให้บริการเตรียมอุโมงค์ ได้แก่ ที่อยู่ การกำหนดค่า ความจุ วงจรชีวิตของโปรโตคอลเริ่มเมื่อทั้งสองฝ่ายมีข้อมูลกำหนดค่าพอที่จะแลกเปลี่ยน IKE_SA_INIT จากนั้น IKE_AUTH จากนั้นสมาคมความปลอดภัยลูก อุโมงค์ที่ยังอยู่ในระยะแรกยังไม่ได้ล้มเหลวในการพิสูจน์ตัวตน เพราะยังไม่ได้ลองพิสูจน์ตัวตน
ความต่างนั้นคือปัญหาทั้งหมด ส่วนที่เหลือคือวิธีสังเกตมันโดยไม่รวมข้อความที่ไม่เกี่ยวข้องเข้าด้วยกัน
อ่านวัตถุ ไม่ใช่อ่านสรุปของคอนโซล
ขอจาก API เฉพาะสองฟิลด์ที่สำคัญและไม่ขออย่างอื่น คำตอบจะได้เล็กพอที่จะอ่านตอนตีสาม: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". ฟิลด์ status ระบุชื่อระยะของวงจรชีวิต และ detailedStatus พาเหตุผลที่อ่านได้ซึ่งผูกอยู่กับระยะนั้น การดัมป์การกำหนดค่าทั้งหมดตอบคำถามอื่นและวางลงในตั๋วได้ยากกว่า การเรียกแบบอ่านอย่างเดียวเช่นนี้เปลี่ยนอุโมงค์ไม่ได้ ซึ่งสำคัญในขณะที่เหตุการณ์ยังดำเนินอยู่
บันทึกเวลาของการเรียกไว้ข้างค่า เพราะทั้งสองฟิลด์เคลื่อนไหว
ALLOCATING_RESOURCES ไม่ใช่ความไม่ตรงกันของคีย์
เมื่ออุโมงค์รายงาน ALLOCATING_RESOURCES ผู้ให้บริการยังประกอบวัตถุอยู่ ความไม่ตรงกันของคีย์ที่แชร์ไว้ล่วงหน้าไม่สามารถสังเกตได้ในระยะนั้น และพอร์ตของเพียร์ที่ถูกบล็อกก็พิสูจน์ไม่ได้เช่นกัน สิ่งที่ตรวจสอบได้คือข้อความโดยละเอียด โปรเจกต์และบริการดูแข็งแรงหรือไม่ และการกำหนดค่าอุโมงค์สมบูรณ์พอที่จะติดต่อเพียร์ได้หรือไม่ การเปลี่ยนความลับตอนนี้เป็นการเปลี่ยนค่าที่ไม่เคยถูกทดสอบ
รอให้สถานะเคลื่อนไหวก่อนสรุปเกี่ยวกับการกำหนดค่า
ESTABLISHED คือจุดเริ่มต้นของการตรวจสอบการเข้าถึง
อุโมงค์ที่สร้างสำเร็จหมายถึง IKE เสร็จสิ้น ไม่ได้หมายถึงทราฟฟิกไหล ยืนยันเส้นทางที่อุโมงค์บรรทุก และในจุดที่มี Cloud Router เกี่ยวข้อง ยืนยันเซสชัน BGP และคำนำหน้าที่มันเรียนรู้ จากนั้นทดสอบการแลกเปลี่ยนแอปพลิเคชันที่ได้รับอนุญาต เพราะกฎไฟร์วอลล์หรือเส้นทางที่หายไปสามารถบล็อกทราฟฟิกผ่านอุโมงค์ที่แข็งแรงสมบูรณ์ได้ แต่ละอย่างเป็นการสังเกตแยกและการแก้ไขแยก
สถานะบอกคุณว่าควรถามคำถามใดต่อไป มันไม่เคยตอบคำถามเรื่องการเข้าถึงแทนคุณ
จับคู่วัตถุหนึ่งชิ้นกับช่วงเวลาหนึ่งช่วง
ความล้มเหลวในการพิสูจน์ตัวตนเก่าในบันทึกเป็นของความพยายามก่อนหน้า เว้นแต่เวลาของมันจะตกอยู่ในช่วงที่คุณกำลังตรวจสอบ ดึงบันทึกของรีซอร์สอุโมงค์สำหรับนาทีเดียวกับสถานะที่คุณบันทึกไว้ และเก็บตัวระบุไว้ด้วยกัน เหตุการณ์ IKE ที่เกิดภายหลังอาจแสดงว่าการเจรจาเริ่มแล้ว ในขณะที่ข้อความบนคอนโซลที่คุณจ้องอยู่ล้าสมัยไปแล้ว
ถ้าอุโมงค์ฟื้นก่อนที่คุณจะเก็บอะไรได้ ให้บอกเช่นนั้น สาเหตุที่ไม่ทราบแน่ชัดเป็นบันทึกที่ดีกว่าเรื่องเล่ามั่นใจที่ประกอบขึ้นจากบรรทัดที่ไม่เกี่ยวข้อง
ก้าวต่อไปมีรูปร่างเหมือนเดิมเสมอ: วัตถุหนึ่งชิ้น ช่วงเวลาหนึ่งช่วง ระยะหนึ่ง การใดที่กว้างกว่านั้นเป็นบทสรุป ไม่ใช่การวินิจฉัย