iOS ปฏิเสธอุโมงค์ strongSwan ของคุณ: เทียบข้อเสนอ IKE
ที่อยู่ที่ใช้งานได้และใบรับรองที่ถูกต้องยังแพ้การเจรจาได้ เทียบบรรทัด ike และ esp กับสิ่งที่โทรศัพท์ยอมรับ
ไม่มีอะไรในใบรับรองหรือที่อยู่ที่อธิบายได้ว่าทำไม iPhone ที่เคยเชื่อมต่อกับ strongSwan เมื่อปีที่แล้วจึงล้มเหลวในปีนี้ ไม่มีอะไรในที่อยู่ คีย์ที่แชร์ไว้ล่วงหน้า หรือตัวตนของไคลเอนต์ที่ต้องเปลี่ยน สิ่งที่ขยับคือรายการทรานส์ฟอร์มที่ไคลเอนต์ในตัวของโทรศัพท์พร้อมจะเจรจา และเมื่อรายการนั้นไม่ทับซ้อนกับของเซิร์ฟเวอร์อีกต่อไป การแลกเปลี่ยนก็จบลงก่อนที่จะมีการตรวจสอบตัวตนของใคร
บรรทัดล็อกที่ชี้ขาด
เพิ่มระดับล็อกของการเชื่อมต่อนั้นแล้วหาสองรายการที่ชี้ขาดผลลัพธ์ คือสิ่งที่โทรศัพท์เสนอและสิ่งที่เซิร์ฟเวอร์เลือก ถ้าล็อกจบลงโดยไม่มีข้อเสนอที่ถูกเลือกและรายงานว่าไม่มีอะไรตรงกัน แสดงว่าการพิสูจน์ตัวตนไม่เคยถูกทดลองเลย ใบรับรองใหม่และรหัสผ่านใหม่ไม่เปลี่ยนอะไร ณ จุดนั้น เพราะทั้งสองถูกใช้ในขั้นตอนถัดไป ทั้งคู่ไม่อาจมีผลต่อผลลัพธ์ที่ตัดสินไปแล้วก่อนการตรวจสอบตัวตน
แยกความล้มเหลวสองแบบออกจากกันก่อนแก้ไขสิ่งใด การแก้ทรานส์ฟอร์มไม่ช่วยกู้ข้อมูลรับรองที่ถูกปฏิเสธ และการแก้ข้อมูลรับรองก็ไม่ช่วยกู้ทรานส์ฟอร์มที่ถูกปฏิเสธ รายการล็อกที่ระบุชื่อข้อเสนอที่ถูกเลือกบอกคุณว่าคุณอยู่ในกรณีไหน ถ้าไม่มีรายการนั้น คุณกำลังเดา
บรรทัดที่ถูกเลือกระบุข้อเสนอด้วยชุดทรานส์ฟอร์ม ไม่ใช่ด้วยป้ายชื่อที่เป็นมิตร เทียบค่าฟิลด์การเข้ารหัส ความสมบูรณ์ และกลุ่ม ในบรรทัดนั้นกับรายการที่โทรศัพท์ส่งมา เพราะความไม่ตรงกันในฟิลด์ใดฟิลด์หนึ่งก็เพียงพอที่จะแพ้
อะไรเปลี่ยนไปในโทรศัพท์
iOS รุ่นหนึ่งตัดอัลกอริทึมที่ไคลเอนต์ยินดีใช้ลง แฮชความสมบูรณ์ที่อ่อนแอ กลุ่ม Diffie-Hellman ขนาดเล็ก และข้อเสนอที่เรียงตัวเลือกเก่าไว้ก่อน ไม่เป็นที่ยอมรับอีกต่อไป
รายการที่ยาวขึ้นไม่ได้ปลอดภัยกว่าตรงนี้ การเลือกเป็นไปตามชุดที่โทรศัพท์ยอมรับและลำดับความชอบของมันเอง เซิร์ฟเวอร์ที่ประกาศแคตตาล็อกกว้างจึงยังแพ้การเจรจาได้เมื่อรายการใหม่ไม่ใช่รายการที่ถูกเลือก ให้เลือกรายการสั้นที่มีรายการใหม่ขึ้นก่อน รายการยาวที่เริ่มด้วยตัวเลือกเก่าเชิญความล้มเหลวที่คุณพยายามหลีกเลี่ยง ชุดที่ยอมรับเป็นข้อจำกัดภายนอกที่ขยับทุกครั้งที่ไคลเอนต์อัปเดต การตั้งค่าที่ใช้ได้เมื่อวานจึงเป็นหลักฐานเกี่ยวกับเมื่อวาน
คู่หนึ่งที่ยังเจรจากันได้
สำหรับโทรศัพท์ปัจจุบัน ชุดผสมที่ทันสมัยชุดเดียวก็เพียงพอ คู่ที่เจรจากันได้มีลักษณะเช่นนี้
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256
บรรทัด ike พาการเข้ารหัส ความสมบูรณ์ และกลุ่ม Diffie-Hellman ที่ใช้ระหว่างการแลกกุญแจ บรรทัด esp ครอบคลุมเฉพาะช่องทางข้อมูล เพราะกลุ่มถูกกำหนดไว้ก่อนที่มันจะมีผล โหลดการเชื่อมต่อใหม่หรือรีสตาร์ตดีมอน แล้วเชื่อมต่อโทรศัพท์อีกครั้ง เก็บค่ากลุ่มนั้นไว้เฉพาะเมื่อไคลเอนต์ทุกรายที่คุณให้บริการยังยอมรับ และอย่าขยายข้อเสนอให้ทุกคนเพียงเพราะเพื่อนเก่ารายหนึ่งต้องการมากกว่า
สามจุดที่แก้ได้ จุดหนึ่งมักปิดอยู่
- ข้อเสนอที่ทันสมัยหนึ่งข้อสำหรับทุกเพื่อน ถูกต้องเมื่อไคลเอนต์ทั้งหมดเป็นโทรศัพท์และเดสก์ท็อปปัจจุบัน มันลบทรานส์ฟอร์มเก่าทิ้งแทนที่จะเจรจารอบ ๆ
- คำนิยามการเชื่อมต่อที่สองสำหรับไคลเอนต์ Apple ทำให้เพื่อนเก่ารายหนึ่งยังมีชีวิตอยู่ พร้อมให้ข้อเสนอที่โทรศัพท์ยอมรับ ต้องใช้บล็อกการเชื่อมต่อเพิ่มอีกหนึ่งบล็อกและทำให้ข้อยกเว้นมองเห็นได้
- การเปลี่ยนไคลเอนต์ แทบไม่เปิดให้คุณ เพราะเมื่อระบบจัดการหรือแอปเป็นผู้ส่งโปรไฟล์ ก็ไม่มีตัวแก้ไขข้อเสนอให้แตะ และไคลเอนต์ในตัวก็ไม่เปิดให้
เลือกตัวเลือกที่สองเมื่ออุปกรณ์นอกการควบคุมของคุณอัปเดตไม่ได้ เลือกตัวแรกเมื่อคุณปลดระวางเพื่อนเก่าได้และอยากถือแนวนโยบายเดียว
ไม่ว่าจะทางไหน ตัวเลือกนั้นมองเห็นได้ในการตั้งค่า และนั่นคือประเด็น การถอยกลับเงียบ ๆ ที่เจรจาลงไปจนถึงทรานส์ฟอร์มเก่าแย่กว่าบล็อกที่ชัดเจน เพราะไม่มีการทบทวนใดจะเปิดเผยมันได้
พิสูจน์ให้ได้ แล้วจึงบันทึก
เชื่อมต่อใหม่และตรวจสอบสามข้อแยกกันบนเซิร์ฟเวอร์ มีข้อเสนอถูกเลือก การเชื่อมต่อแสดงว่าสถาปนาแล้ว และไคลเอนต์ได้รับที่อยู่ แฮนด์เชกที่สถาปนาแล้วแต่ไม่มีที่อยู่ระยะไกลชี้ไปที่พูลหรือตัวเลือกทราฟฟิก และควรอยู่ในการเปลี่ยนแปลงแยกต่างหาก การจัดการทั้งสองอย่างรวมกันทำให้การเจรจาที่แก้ได้ดูเหมือนแก้ไม่ได้
จดชุดทรานส์ฟอร์มที่ถูกยอมรับ ว่าเปลี่ยนเมื่อใด และตรวจสอบไคลเอนต์บิลด์ใด การอัปเดตครั้งต่อไปอาจเลื่อนข้อกำหนดอีก และค่าที่เคยใช้ได้คือสิ่งแรกที่คุณอยากมีไว้ข้างค่าชุดใหม่