ทำไมการนำเข้าซ้ำซึ่งใบรับรอง Client VPN จึงต้องมีปลายทางใหม่
ปลายทางของ Client VPN ผูกใบรับรองไว้ตั้งแต่สร้าง การนำเข้าซ้ำซึ่งออบเจ็กต์ใน ACM ไม่เปลี่ยนการผูกนั้น การกู้คืนจึงหมายถึงปลายทางใหม่
การเชื่อมต่อ Client VPN ขาดหาย ใบรับรองใน ACM ถูกแทนที่ และไม่มีอะไรเปลี่ยนแปลง วัตถุใบรับรองไม่เคยเป็นสิ่งที่ปลายทางใช้งาน ปลายทางเก็บความเชื่อมโยงกับใบรับรองตอนสร้าง พร้อมด้วย CA ของไคลเอนต์ที่จะใช้ตรวจสอบ ชนิดการพิสูจน์ตัวตน ซับเน็ต และกฎการอนุญาต และไม่มีความเชื่อมโยงใดมีการเรียกแก้ไขที่รับใบรับรองทดแทน การแทนไบต์เบื้องหลัง ARN เป็นการเปลี่ยนแปลงของใบรับรอง ไม่ใช่ของปลายทางที่จับมันไว้
ปลายทางเก็บการอ้างอิง ไม่ใช่ใบรับรอง
กลไกนี้ควรอธิบายให้แม่นยำ เพราะมันอธิบายความล้มเหลวทั้งหมด create-client-vpn-endpoint รับ ARN ของใบรับรองเซิร์ฟเวอร์และ ARN ของห่วงโซ่ใบรับรองรากของไคลเอนต์ และปลายทางที่ได้จะเก็บการอ้างอิงเหล่านั้นพร้อมตัวเลือกการพิสูจน์ตัวตนเป็นคุณสมบัติคงที่ API ไม่มีปฏิบัติการใดที่สลับใบรับรองเซิร์ฟเวอร์บนปลายทางที่มีอยู่
คุณยืนยันความเชื่อมโยงได้โดยไม่ต้องเดา aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 พิมพ์ ARN ของใบรับรอง ARN ของห่วงโซ่รากของไคลเอนต์ ชนิดการพิสูจน์ตัวตน CIDR ของไคลเอนต์ และซับเน็ตที่เกี่ยวข้อง ซึ่งเป็นชุดคุณสมบัติทั้งหมดที่คุณต้องสร้างซ้ำ รันมันก่อนและหลังการนำเข้าซ้ำ แล้วผลลัพธ์จะไม่ขยับ นั่นคือหลักฐานว่าการนำเข้าซ้ำไม่เคยจะช่วยได้
ทำไมการนำเข้าซ้ำจึงไปไม่ถึงปลายทาง
การนำเข้าซ้ำเขียนเนื้อใบรับรองใหม่ภายใต้ ARN ที่มีอยู่ นั่นเป็นปฏิบัติการที่ชอบด้วยกฎหมายเมื่อใบรับรองใกล้หมดอายุ และ ACM จะยอมรับตราบใดที่คีย์ส่วนตัวตรงกันและห่วงโซ่ตรวจสอบผ่าน สิ่งที่มันไม่ทำคือรันการตรวจสอบตอนสร้างปลายทางซ้ำ ความเชื่อมโยงและวัสดุเบื้องหลังจึงคงอยู่เหมือนตอนที่สร้างปลายทาง
นี่จึงเป็นเหตุผลที่อาการอ่านเหมือนความผิดพลาดของเครือข่าย การจับมือ TLS ล้มเหลวหรือรีเซ็ตก่อนที่การอนุญาตจะถูกประเมินด้วยซ้ำ กลุ่มความปลอดภัย เส้นทาง และกฎการอนุญาตจึงดูบริสุทธิ์ทั้งหมด และพวกมันก็บริสุทธิ์จริง
ห่วงโซ่เป็นส่วนหนึ่งของใบรับรองไคลเอนต์
ครึ่งหลังของความล้มเหลวอยู่ในใบรับรองไคลเอนต์ และมันถูกมองข้ามได้ง่ายกว่า ใบรับรองไคลเอนต์ต้องนำเข้าพร้อมห่วงโซ่ที่ออกให้ แม้ว่าแบบฟอร์มนำเข้าจะแสดงช่องนั้นเป็นทางเลือกก็ตาม หากไม่มีห่วงโซ่ ปลายทางจะสร้างเส้นทางจากใบรับรองไคลเอนต์ไปยัง CA รากของไคลเอนต์ที่กำหนดไว้ไม่ได้ และการเชื่อมต่อจะจบด้วยการรีเซ็ตแบบนุ่มนวลที่ฟังดูเหมือนไฟร์วอลล์ทิ้งแพ็กเก็ต openssl verify -CAfile root-ca.pem client.crt ตอบคำถามนั้นในเครื่องภายในหนึ่งวินาที และมันควรเป็นคำสั่งแรกที่คุณรัน
การนำเข้าซ้ำพร้อมห่วงโซ่เป็นการแก้ที่แท้จริงสำหรับครึ่งนั้น และยังไม่พอโดยลำพัง เมื่อวัตถุใน ACM เปลี่ยนแล้ว ปลายทางที่ถือความเชื่อมโยงเก่าคือสิ่งที่ผิดที่จะทดสอบต่อไป สองขั้นตอนเป็นของการซ่อมเดียวกัน นี่จึงไม่ใช่ความขัดแย้ง
การสร้างปลายทางใหม่คือการย้ายระบบ
การสร้างปลายทางทดแทนคือการย้ายระบบ ไม่ใช่การลองใหม่ และการปฏิบัติต่อมันเหมือนการลองใหม่คือวิธีที่ทีมลงเอยด้วยปลายทางที่ตั้งค่าไว้ครึ่งๆ สองอัน ปลายทางใหม่ได้ ID ใหม่ และหากคุณไม่ได้วางแผนไว้ ก็ได้ชื่อ DNS ใหม่สำหรับผู้ใช้ทุกคน ให้โปรไฟล์ไคลเอนต์ชี้ไปที่ชื่อไม่ใช่ที่อยู่ การสลับจึงเป็นการเปลี่ยนระเบียนไม่ใช่การแจกจ่ายใหม่
ลำดับที่ทำให้ปลอดภัยนั้นสั้น สร้างปลายทางใหม่ด้วย CIDR ซับเน็ต และกฎการอนุญาตเดียวกัน ส่งออกโปรไฟล์ใหม่ด้วย aws ec2 export-client-vpn-client-configuration และตรวจสอบกับผู้ใช้หนึ่งคน หลังจากนั้นเท่านั้นที่ปลายทางเก่าถูกปลด
การปลดปลายทางเก่ามีลำดับของมันเอง เพิกถอนใบรับรองไคลเอนต์ที่คุณตั้งใจจะปลดก่อนลบมัน เพราะปลายทางใหม่ที่ยังเชื่อถือ CA เก่ายังคงรับใบรับรองที่คุณคิดว่าหายไปแล้ว จากนั้นลบปลายทางเก่าและถอดกฎการอนุญาตของมัน เพื่อให้โปรไฟล์เก่าเชื่อมต่อกลับไปยังเครือข่ายเป้าหมายที่คุณคิดว่าปิดแล้วไม่ได้ บันทึก ID ของปลายทางเก่าและตัวระบุความเชื่อมโยงลงในบันทึกการเปลี่ยนแปลง เพราะการย้ายที่เทียบกับความจำคือวิธีที่ปลายทางที่ใช้งานได้ถูกสร้างใหม่สองครั้ง
จัดลำดับการวินิจฉัย
แยกความล้มเหลวสามอย่างก่อนเปลี่ยนการกำหนดค่าใดๆ ไคลเอนต์ทำ TLS ไม่สำเร็จ ไคลเอนต์ทำ TLS สำเร็จแต่ไม่ได้รับอนุญาต หรือไคลเอนต์เชื่อมต่อได้แต่ไปไม่ถึงปลายทาง ความเชื่อมโยงใบรับรองเป็นของอย่างแรก กฎการอนุญาตที่ไม่ครอบคลุมที่อยู่ไคลเอนต์เป็นของอย่างที่สอง และเส้นทางหรือกลุ่มความปลอดภัยเป็นของอย่างที่สาม ซึ่งการสร้างปลายทางใหม่แทบทุกครั้งเป็นก้าวที่ผิด
ปลายทางที่ทำงานมาหลายเดือนแล้วหยุด โดยไม่มีการเปลี่ยนใบรับรองหรือนโยบาย เป็นกรณีของตัวเอง การสร้างใหม่ด้วยการตั้งค่าเดิมอาจคืนบริการได้ แต่นั่นเป็นเหตุผลให้เก็บการกำหนดค่าให้ทำซ้ำได้ ไม่ใช่เหตุผลให้สร้างใหม่ทุกครั้งที่เกิดเหตุ
เก็บสี่สิ่งไว้ในระบบควบคุมเวอร์ชันเพื่อให้การสร้างใหม่ครั้งหน้าเป็น diff ไม่ใช่การด้นสด พารามิเตอร์ของปลายทาง ARN ของใบรับรองและห่วงโซ่ กฎการอนุญาต และ CIDR ของไคลเอนต์ เอกสารการพิสูจน์ตัวตนของ Client VPN ระบุว่าใบรับรองใดมีบทบาทใด ซึ่งควรตรวจสอบก่อนสันนิษฐานว่าใบรับรองคือปัญหา หากการนำเข้าซ้ำไม่เปลี่ยนอะไรและปลายทางยังรีเซ็ต ผู้ต้องสงสัยคือความเชื่อมโยง และคำตอบคือปลายทางใหม่ที่สร้างจากพารามิเตอร์ที่บันทึกไว้ หากปลายทางรับวัตถุใหม่จริง ความเชื่อมโยงถูกต้องอยู่แล้ว และความผิดพลาดอยู่ที่ห่วงโซ่ไคลเอนต์หรือชั้นการอนุญาต