L2TP NO_PROPOSAL_CHOSEN: ระยะใดล้มเหลวจริง ๆ?
การแจ้งเตือนบอกว่าข้อเสนอถูกปฏิเสธ ไม่ได้บอกว่าข้อไหน อ่านบันทึกของ backend เพื่อหาระยะ แล้วเปรียบเทียบชุดกับผู้ดูแลเกตเวย์
NO_PROPOSAL_CHOSEN มาถึงก่อนที่จะมีการตรวจสอบชื่อผู้ใช้ PPP ใด ๆ ซึ่งเป็นข้อเท็จจริงที่มีประโยชน์และเป็นเหตุผลที่ข้อความทำให้เข้าใจผิดด้วย มันรายงานว่าฝ่ายหนึ่งปฏิเสธข้อเสนอ แต่ไม่รายงานว่าพารามิเตอร์ใดไม่ตรงกัน และไม่พูดอะไรเลยว่าการปฏิเสธเกิดขึ้นระหว่างการสร้างความสัมพันธ์ IKE หรือเกิดขึ้นภายหลังระหว่างการเจรจาเรื่องการปกป้องทราฟฟิก หลังความเป็นไปได้ทั้งสองนี้มีวิธีแก้ที่ต่างกันสองวิธี และมีเพียงวิธีเดียวเท่านั้นที่เกี่ยวกับช่องทำเครื่องหมาย PFS ซึ่งผู้คนมักเอื้อมไปหก่อน
ข้อความเดียว สองชุดข้อเสนอ
การจัดวาง IKEv1 L2TP/IPsec มีการเจรจาสองรอบต่อเนื่องกัน ระยะ 1 สร้างความสัมพันธ์ความปลอดภัย IKE จากอัลกอริทึมการเข้ารหัส อัลกอริทึมความสมบูรณ์ และกลุ่ม Diffie-Hellman จากนั้นระยะ 2 เจรจาว่าทราฟฟิกจะได้รับการปกป้องอย่างไร และข้อกำหนด PFS เป็นของการสนทนารอบที่สองนั้น
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
เนื่องจากระยะต่าง ๆ เรียงต่อกัน ตำแหน่งของความล้มเหลวจึงบอกคุณว่าควรเปรียบเทียบรายการใด คุณค่าด้านการวินิจฉัยทั้งหมดของข้อความอยู่ตรงนั้น และคุ้มค่าที่จะดึงออกมาก่อนจะแตะการตั้งค่าใด ๆ
ทำไมช่องทำเครื่องหมาย PFS จึงซ่อมระยะ 1 ไม่ได้
การปิด PFS เปลี่ยนคุณสมบัติของระยะ 2 หากทั้งสองฝ่ายไม่เคยตกลงเรื่องระยะ 1 การสนทนา ESP จะไม่เกิดขึ้นเลย ช่องทำเครื่องหมายจึงไม่มีผลใด ๆ ต่อการปฏิเสธ และนั่นคือเหตุผลที่การสลับมันให้ข้อผิดพลาดเดิมพร้อมตราเวลาที่ต่างออกไป
ข้อผิดพลาดตรงข้ามก็พบบ่อยพอ ๆ กัน ความสัมพันธ์ IKE ที่สำเร็จไม่ได้พิสูจน์ว่าข้อเสนอ ESP ยอมรับได้ และไม่พิสูจน์เลยว่ากลุ่มของระยะ 2 ตรงกัน ให้ถือว่าอุโมงค์บริหารที่สร้างแล้วเป็นหลักฐานเฉพาะเกี่ยวกับระยะ 1 เท่านั้น ผู้คนอ่านบรรทัดสีเขียวว่า «อุโมงค์ทำงานอยู่» แล้วใช้เวลาหนึ่งชั่วโมงกับระยะที่ผิด เพราะไม่มีอะไรบอกพวกเขาว่าการเจรจารอบที่สองยังไม่เริ่ม
อ่านบันทึกก่อนเลือกอัลกอริทึม
รวบรวมข้อความที่เกิดขึ้นก่อนการปฏิเสธจาก backend ที่จัดการการเชื่อมต่อจริง แล้วเชื่อมโยงกับความพยายามเดียวกัน หากไม่มีการเชื่อมโยงนั้น คุณกำลังอ่านประวัติของการเชื่อมต่ออื่นและสรุปผลจากมัน
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanจากบรรทัดเหล่านั้น ให้ตอบสองคำถาม: มีการสร้างความสัมพันธ์ระยะ 1 หรือไม่ และการแลกเปลี่ยนใดล้มเหลว คำตอบทั้งสองนี้จำกัดการค้นหาให้เหลือรายการแอตทริบิวต์เดียว การแจ้งเตือนเปล่า ๆ ที่ไม่มีบริบทโดยรอบทำสิ่งนั้นไม่ได้ ไม่ว่าจะน่าดึงดูดเพียงใดที่จะ ลองข้อเสนอจากกระทู้ฟอรัม การคัดลอกสตริงที่ใช้งานได้จากเครื่องที่มี backend อื่นมักจะแทนที่การปฏิเสธหนึ่งด้วยอีกอันหนึ่ง ช้ากว่าเล็กน้อย
ไวยากรณ์ของ backend ไม่เดินทาง
บันทึกเวอร์ชันของ NetworkManager-l2tp และเวอร์ชันของ backend IPsec ก่อนเปรียบเทียบสิ่งใด Libreswan และ strongSwan ไม่ได้ใช้ไวยากรณ์ข้อเสนอร่วมกันหรือชุดอัลกอริทึมที่เหมือนกัน ดังนั้นสตริงที่ใช้ได้ในตัวหนึ่งจึงเป็นข้อผิดพลาดทางไวยากรณ์ในอีกตัว backend ที่ติดตั้งอาจปฏิเสธ IKEv1 ตามนโยบายด้วย และในกรณีนั้นจะไม่มีข้อเสนอใดได้รับการยอมรับเลย
README ของโครงการบันทึกความแตกต่างระหว่าง backend เหล่านั้นและแยกฟิลด์ของระยะ 1 กับระยะ 2 ไว้จากกัน อ่านมันเป็นเอกสารของโครงสร้าง ไม่ใช่คำเชิญให้เปิดใช้การเข้ารหัสเชิงประวัติทั้งหมดและกลุ่มที่อ่อนแอ เพราะการเชื่อมต่อที่สำเร็จได้ด้วยวิธีนั้นเท่านั้นไม่ใช่การเชื่อมต่อที่คุณได้รับคำสั่งให้สร้าง
ตกลงชุดให้ตรงกัน แล้วตรวจสอบขั้นตอน
ถามผู้ดูแลเกตเวย์ว่าชุด IKE และ ESP ใดได้รับการสนับสนุนและอนุมัติ แล้วเปรียบเทียบคำตอบนั้นกับข้อเสนอที่แท้จริงของไคลเอนต์ ไม่ใช่กับไฟล์กำหนดค่าของมัน หากความขัดแย้งเกี่ยวกับ PFS ของระยะ 2 โดยเฉพาะ ให้ตัดสินด้วยกลุ่มที่ได้รับการสนับสนุนหรือนโยบายที่ไม่ใช้ PFS ซึ่งอนุมัติอย่างชัดเจน อย่าเดานโยบายจากชื่อข้อผิดพลาด
เมื่อส่วนที่ทับซ้อนกันเพียงอย่างเดียวต้องใช้การเข้ารหัสที่องค์กรไม่ยอมรับแล้ว การตัดสินใจเป็นของเกตเวย์หรือการย้ายโปรโตคอล การขยายสตริงของไคลเอนต์จนกว่าจะมีอะไรเจรจาได้เป็นวิธีส่งมอบจุดอ่อนที่รู้กันดีพร้อมเครื่องหมายถูกสีเขียวข้าง ๆ
หลังจากแก้ไขความไม่ตรงกันที่แท้จริงแล้ว ให้ยืนยันการสร้าง IPsec ก่อนตรวจสอบ L2TP และ PPP และถือว่าการปฏิเสธการยืนยันตัวตนในภายหลังเป็นของขั้นตอนถัดไป จากนั้นทดสอบการต่ออายุในกระบวนการทดสอบที่อนุมัติแล้ว เพราะการสร้างความสัมพันธ์แรกไม่ได้บอกอะไรเกี่ยวกับอายุที่เหลือของมัน