iOS IKEv2 ไปยัง strongSwan: ไม่มีข้อเสนอที่ถูกเลือก แก้รายการ

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

ที่ที่เกตเวย์ประกาศนโยบายของตน

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

ไคลเอนต์ที่เสนอรายการกว้างกว่ายังเชื่อมต่อกับเกตเวย์ที่ตรึงไว้ได้ ตราบใดที่มีชุดค่าผสมอย่างน้อยหนึ่งชุดอยู่ทั้งสองฝั่ง สิ่งที่เกิดขึ้นไม่ได้คือการเจรจานอกชุดที่ตรึงไว้

นั่นคือเหตุผลที่ โปรไฟล์ที่คัดลอกจากแอป VPN อื่น อาจทำงานในที่ที่ของคุณไม่ทำงาน: แอปนั้นส่งรายการอื่นมา

ชื่อต้องตรงกัน ไม่ใช่ดีขึ้น

การแปลสองจุดทำให้คนที่ย้ายค่าจาก strongSwan ไปยัง iOS สับสน อัลกอริทึมความสมบูรณ์ที่เขียนว่า SHA1 ในข้อเสนอ IKE จะเดินทางในรูปแบบที่ถูกตัดทอน ซึ่ง iOS เรียกว่า .SHA96 กลุ่ม Diffie-Hellman ที่เขียนว่า modp1024 คือกลุ่ม 2 ซึ่ง iOS เรียกว่า .group2 การแทนที่ด้วย SHA-256 หรือกลุ่ม 14 จะไม่เจรจากับเกตเวย์ที่ยอมรับเฉพาะคู่เก่า ไคลเอนต์ต้องอธิบายอัลกอริทึมเดียวกัน ไม่ใช่ที่แรงกว่า

ตั้งค่าเหล่านั้นอย่างชัดเจนใน NEVPNProtocolIKEv2 ค่าเริ่มต้นอาจกว้างหรือแคบกว่าโปรไฟล์ที่คุณแทนที่ และความแตกต่างจะปรากฏเฉพาะเมื่อแฮนด์เชกล้มเหลว

ข้อเสนอย่อยล้มเหลวช้ากว่าและเงียบกว่า

กำหนดค่าความสัมพันธ์ความปลอดภัยของลูกด้วย ไม่ใช่แค่ของ IKE เมื่อพารามิเตอร์ IKE ตรงกันเท่านั้น อุโมงค์จะยืนยันตัวตนแล้วไม่บรรทุกทราฟฟิก ซึ่งเป็นความล้มเหลวที่เงียบกว่าการปฏิเสธมาก ตั้งค่าการเข้ารหัส ความสมบูรณ์ กลุ่ม และอายุของลูกในการตั้งค่าครั้งเดียว รักษาอายุของไคลเอนต์ให้เท่าหรือต่ำกว่าค่าของเกตเวย์ เพราะการยืนกรานให้ยาวกว่านั้นให้ข้อความ no proposal chosen เดิมจากสาเหตุอื่น ความไม่ตรงกันตรงนั้นดูเหมือนกันกับ ความไม่ตรงกันของ IKE ในบันทึก

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

ปล่อยชุดเก่าไว้เฉพาะเท่าที่จำเป็น

การตรึง SHA-1 กับกลุ่ม 1024 บิตเป็นสะพาน ไม่ใช่ปลายทาง ทั้งคู่เลิกใช้แล้ว และไคลเอนต์ใหม่กว่าอาจปฏิเสธโดยสิ้นเชิง ซึ่งหมายความว่าโปรไฟล์จะล้มเหลวบนอุปกรณ์ถัดไปโดยไม่มีการเปลี่ยนแปลงฝั่งคุณ มองการตรึงเป็นเรื่องชั่วคราวและเขียนไว้ในบันทึก

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