L2TP: สัญญาณถึงตาย 15, NO_PROPOSAL_CHOSEN และ modp1024 ที่หายไป

การเชื่อมต่อของคุณค้าง ไคลเอนต์ออกไป และบรรทัดสุดท้ายบนหน้าจอคือ death_handler: Fatal signal 15 received บรรทัดนั้นรายงานการถูกตัด ไม่ใช่สาเหตุ บรรทัดเหนือขึ้นไปในล็อก IPsec แทบทุกครั้งมี NO_PROPOSAL_CHOSEN และคู่นี้ชี้ไปที่เฟส 2 ของการแลกเปลี่ยน ซึ่งทั้งสองฝ่ายเทียบตัวเลือกการเข้ารหัสและแฮชแล้วหยุดเมื่อไม่มีอะไรที่เหมือนกัน ข้อมูลรับรองยังไม่ได้ถูกส่งในขั้นนั้น การพิมพ์รหัสผ่านใหม่จึงเปลี่ยนผลลัพธ์ไม่ได้

โดยปกติมีสองสิ่งทำให้ส่วนตัดกันนั้นว่างเปล่าบนไคลเอนต์ Linux เดมอนภายในอาจไม่รองรับกลุ่ม Diffie-Hellman ที่โปรไฟล์ขอแล้ว หรือโปรไฟล์อาจมีข้อเสนอของเฟส 1 อยู่ในช่องของเฟส 2 ทั้งสองอย่างทิ้งร่องรอยไว้ในล็อก และไม่ใช่ปัญหาเรื่องบัญชี

สองข้อความนั้นบอกอะไรจริง ๆ

IKE เจรจาเป็นรอบ เฟส 1 สร้างช่องทางที่ได้รับการป้องกันและเลือกอัลกอริทึมของตัวเอง ส่วนเฟส 2 คือ SA ลูก นำทราฟฟิกภายใต้ชุดแยกต่างหาก NO_PROPOSAL_CHOSEN คือการแจ้งเตือนที่ผู้ตอบส่งกลับมาเมื่อไม่มีชุดผสมใดที่เสนอไว้เป็นที่ยอมรับ และปรากฏเป็น [ HASH N(NO_PROP) ] ภายในการแลกเปลี่ยน INFORMATIONAL

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

อ่านการเจรจาก่อนแตะข้อมูลรับรอง

เพิ่มระดับล็อกในที่ที่เดมอนเขียน แล้วเชื่อมต่อใหม่พร้อมดูผลลัพธ์ บนโฮสต์ NetworkManager ปลั๊กอิน L2TP ส่งระดับนั้นต่อไปยังแบ็กเอนด์ และข้อความไปลงใน journal หรือไฟล์ syslog แบบดั้งเดิม ขึ้นอยู่กับการกระจายตัว อย่างใดอย่างหนึ่งจะแสดงการแลกเปลี่ยน: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' หรือ tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'

บรรทัดที่ระบุชื่อ pluto มาจาก libreswan ส่วน charon มาจาก strongSwan และทั้งสองอธิบายสภาพเดียวกันด้วยถ้อยคำต่างกัน รูปแบบที่ควรค่าแก่การค้นหาคือแบบที่ระบุชื่อกลุ่มที่ขาดหายไป เช่น algorithm 'modp1024' is not supported เพราะมันเปลี่ยนความล้มเหลวที่คลุมเครือให้เป็นความล้มเหลวที่ชัดเจน

modp1024 หายไปไหน

กลุ่ม 2 ของ Diffie-Hellman อ่อนแอพอที่หลายการกระจายตัวหยุดคอมไพล์มันลงใน libreswan ตั้งแต่ 3.30 เป็นต้นมา จากนั้นโปรไฟล์ที่เขียนไว้หลายปีก่อน หรือคัดลอกมาจากคู่มือเกตเวย์ที่ระบุเพียง aes128-sha1-modp1024 ก็ขอสิ่งที่เดมอนภายในทำไม่ได้เลยจากเดมอนนั้น บิลด์ NetworkManager-l2tp ใหม่ทำให้ผลลัพธ์นั้นเป็นไปได้มากขึ้น: ตั้งแต่ 1.2.16 พวกมันแทนชุดด้วยข้อเสนอสไตล์ Windows 10 และ iOS และทิ้ง modp1024 ทันทีที่ตรวจพบ libreswan ฝ่ายตรงข้ามมักไม่มีความผิดและยัง เสนอกลุ่มที่คุณตั้งค่าไว้พอดี

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

การซ่อมสองแบบที่ผลกระทบต่างกัน

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

การซ่อมแบบที่สองทำให้เกตเวย์เก่ายังเข้าถึงได้ด้วยการติดตั้ง strongSwan ซึ่งแพ็กเกจยังรองรับกลุ่ม 2 ในดิสทริบิวชันส่วนใหญ่ นั่นคือการเปลี่ยนเดมอน จึงมีต้นทุน: ตรวจสอบว่าอุโมงค์อื่นบนโฮสต์พึ่งพาการตั้งค่า libreswan หรือไม่ก่อนถอดออก และคาดว่าจะมีการปฏิเสธ SELinux ระหว่าง NetworkManager กับปลั๊กอิน strongSwan บน Fedora การปฏิเสธเหล่านั้นปรากฏในล็อกตรวจสอบ ไม่ใช่ในร่องรอย IKE จึงเป็นเหตุให้อุโมงค์ดูเหมือนพังทันทีหลังการติดตั้งสำเร็จ ลำดับที่ได้ผลคือ dnf install strongswan ก่อน แล้วจึง rpm -e libreswan

สตริงข้อเสนอที่ตรงกัน และกับดักรอบ ๆ

เมื่อต้องกรอกช่องด้วยมือ เฟส 1 และเฟส 2 รับค่าต่างกัน คู่ที่รู้กันว่าทำงานกับฝ่ายตรงข้ามสไตล์ Meraki เสนอ aes128-sha1-modp1024 ในเฟส 1 โดยมี 3des-sha1-modp1024 อยู่ข้างหลัง ทั้งคู่ปิดด้วยเครื่องหมายอัศเจรีย์ที่ทำให้ชุดเข้มงวด จึงส่งเฉพาะข้อเสนอเหล่านั้น

จากนั้นเฟส 2 แคบลงเหลือ aes128-sha1 และ 3des-sha1 ด้วยเครื่องหมายเข้มงวดเดียวกันและไม่มีส่วนต่อท้าย Diffie-Hellman เลย บรรทัดเฟส 2 ที่มี -modp1024 คือค่าของเฟส 1 ในช่องผิด และผู้ตอบปฏิเสธทุกครั้งที่ลองใหม่ คัดลอกบรรทัดนั้นไปยังโปรไฟล์ที่สองแล้วโปรไฟล์ที่สองก็ล้มเหลวแบบเดียวกัน นี่คือวิธีที่การพิมพ์ผิดครั้งเดียวกลายเป็นเหตุการณ์ทั้งกองเรือ

ข้อบกพร่องอื่นสวมป๊อปอัปเดียวกันโดยไม่ใช่ข้อเสนอไม่ตรงกัน บน KDE ประเภท L2TP อาจแสดงในรายการทั้งที่ติดตั้งปลั๊กอินแล้ว แต่ทุกการเชื่อมต่อตายทันที เพราะเอดิเตอร์การเชื่อมต่อและตัวช่วยรันไทม์ถูกส่งมาเป็นแพ็กเกจแยกกัน โฮสต์ที่ไม่มีจอสามารถใช้โปรไฟล์จากเดสก์ท็อปที่ใช้งานได้ซ้ำ: คัดลอกจาก /etc/NetworkManager/system-connections/ ตั้งโหมดเป็น 600 แล้วรัน nmcli con reload ยกขึ้นด้วย nmcli con up id work-l2tp เพราะรูปแบบเปล่าต้องการ UUID และลบรายการ ifname ที่ค้างอยู่ ถ้าไม่เช่นนั้นผู้จัดการจะตอบ Could not find source connection ทั้งที่อย่างอื่นถูกต้อง

คีย์ที่แชร์ล่วงหน้าอาจถูกเก็บเป็นข้อความธรรมดา หรือเป็น 0s ตามด้วย base64 ทั้งสองรูปแบบใช้ได้ แต่ค่าต้องตรงกับเกตเวย์ทุกไบต์ รวมถึงช่องว่างท้ายที่คุณคัดลอกมาด้วย