แยกแยะการแบ่งส่วนของ IKEv2 กับปัญหาห่วงโซ่ใบรับรอง

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

กลไกการแบ่งส่วนสองแบบ อาการเดียว

IKEv2 มีส่วนขยายการแบ่งส่วนของตัวเอง ซึ่งกำหนดไว้ใน RFC 7383 และแบ่งข้อความ IKE ที่ได้รับการป้องกันออกเป็นข้อความ IKE ที่เล็กกว่า คู่สัญญาทั้งสองเจรจาความสามารถนั้น และข้อความจะถูกประกอบกลับโดยการใช้งาน IKE ไม่ใช่โดยชั้น IP

การแบ่งส่วน IP ทั่วไปเป็นกลไกอื่นที่มีโหมดความล้มเหลวต่างกัน เราเตอร์ระหว่างคู่สัญญาจะแบ่งเดตาแกรมขนาดใหญ่ หรือทิ้งมันและส่งข้อความ ICMP กลับมาซึ่งอาจไม่ถึงผู้ส่งเลย บางเครือข่ายทิ้งชิ้นส่วนอย่างเงียบ ๆ และอุปกรณ์กลางบางตัวจัดการชิ้นส่วนแรกแต่ไม่จัดการส่วนที่เหลือ จากมุมมองของแอปพลิเคชัน ทั้งสามกรณีดูเหมือนกัน

การผ่าน NAT เพิ่มตัวแปรที่สาม เพราะ ESP จะถูกห่อใน UDP และแพ็กเก็ตภายนอกใหญ่ขึ้นในขณะที่ดูเหมือนทราฟฟิก UDP ปกติบนพอร์ต 4500 เส้นทางที่ผ่าน UDP ได้ดีก็ยังล้มเหลวกับเดตาแกรมที่ไม่พอดีอีกต่อไป

อ่านการแลกเปลี่ยนที่ล้มเหลว

มองหาการเปลี่ยนผ่าน ไม่ใช่ข้อผิดพลาด บันทึกที่แสดงว่าการแลกเปลี่ยนเริ่มต้นถูกส่งและตอบแล้ว ตามด้วยความว่างเปล่า บอกคุณว่าข้อความถัดไปไม่เคยเสร็จสิ้น เพิ่มระดับบันทึกชั่วคราวและเปรียบเทียบขนาดที่รายงานบนทั้งสองฝ่าย

สิ่งที่คุณต้องการพิสูจน์คือผู้ตอบเห็นคำขอหรือไม่ หากผู้เริ่มส่งบางอย่างและผู้ตอบไม่มีบันทึกใด ๆ เกี่ยวกับเรื่องนั้น ปัญหาอยู่ที่การส่งมอบ หากผู้ตอบวิเคราะห์คำขอและปฏิเสธ ปัญหาอยู่ที่ใบรับรองเอง และการแบ่งส่วนเป็นสิ่งที่เบี่ยงเบนความสนใจ ความแตกต่างนั้นมีค่ามากกว่าหน้าข้อความหมดเวลา

เปลี่ยนเส้นทาง ไม่ใช่ใบรับรอง

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

หากการจับมือเสร็จสิ้นบนเส้นทางที่สอง ห่วงโซ่ใบรับรองก็ปกติดีและเส้นทางแรกคือตัวแปร หากล้มเหลวเหมือนกันบนทั้งสอง ให้หยุดทดสอบเครือข่ายและดูข้อความเอง การเปรียบเทียบครั้งเดียวนั้นกำจัดคำอธิบายที่เป็นไปได้ราวครึ่งหนึ่ง

วัดการแลกเปลี่ยนก่อนแก้ไขอะไร

รับขนาดของห่วงโซ่และขนาดของเส้นทาง ตัวเลขทั้งสองจำกัดสิ่งที่การจับมือส่งได้ และทั้งสองวัดได้ถูก:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

สองตัวแรกให้จำนวนใบรับรองและขนาดไฟล์ ซึ่งเป็นตัวชี้วัดที่สมเหตุสมผลว่าข้อความพิสูจน์ตัวตนจะใหญ่แค่ไหน การทดสอบ ping รายงานว่าเดตาแกรมขนาดนั้นอยู่รอดบนเส้นทางหรือไม่ และตัวนับอินเทอร์เฟซแสดงว่าชิ้นส่วนถูกทิ้งที่ฝั่งคุณหรือไม่ บน Windows การทดสอบที่เทียบเท่าคือ ping ที่มีแฟล็ก do-not-fragment และขนาดเพย์โหลดที่ชัดเจน

ทำการทดสอบซ้ำลงไปจนกว่าจะสำเร็จ ขนาดที่ใหญ่ที่สุดที่ผ่านคืองบประมาณการทำงานของเส้นทางนั้น และมีประโยชน์กว่าค่าเริ่มต้นที่เผยแพร่ใด ๆ

ซ่อมชั้นที่เสียจริง

หากเส้นทางทิ้งเดตาแกรมขนาดใหญ่ ให้เปิดใช้การแบ่งส่วน IKE บนทั้งสองฝ่ายและยืนยันว่าส่วนขยายได้รับการเจรจา ไม่ใช่เพียงเสนอ หากเส้นทางจัดการชิ้นส่วนได้ไม่ดีในระดับ IP การแก้ไขเป็นเรื่องที่นั่นหรือที่ MTU ของอินเทอร์เฟซภายนอก ไม่ใช่ที่คลังใบรับรอง

หากห่วงโซ่ยาวเกินจำเป็น ให้ตัดให้เหลือใบรับรองระดับกลางที่อีกฝ่ายต้องการจริง ๆ การลบรูทที่ไคลเอนต์ไว้วางใจอยู่แล้วเป็นการบำรุงรักษาที่สมเหตุสมผล การลบตัวกลางไม่ใช่ และการปิดการตรวจสอบเพื่อย่อข้อความคือการแลกปัญหาการส่งมอบกับปัญหาความปลอดภัย

จดบันทึกว่าคุณเปลี่ยนกลไกใดและ handshake ดูเป็นอย่างไรหลังจากนั้น การเกิดครั้งต่อไปมักอยู่บนเครือข่ายอื่นที่มีอาการเดียวกัน และบันทึกนั่นเองที่เปลี่ยนสองชั่วโมงให้เป็นสิบนาที