NO_PROPOSAL_CHOSEN บน L2TP? สแกนเกตเวย์ก่อน

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

ข้อความนี้ตัดอะไรออกไป

การปฏิเสธเกิดขึ้นในโหมดหลัก ก่อนการแลกเปลี่ยน L2TP หรือ PPP ใด ๆ ดังนั้นอุโมงค์และฐานข้อมูลผู้ใช้ยังไม่ถูกสอบถาม เฟส 1 เจรจาเรื่องการเข้ารหัส ความสมบูรณ์ และกลุ่ม Diffie-Hellman เฟส 2 เจรจาเรื่องข้อเสนอ ESP สำหรับข้อมูล ความล้มเหลวในเฟส 1 แก้ไม่ได้ด้วยการเปลี่ยนการตั้งค่า PFS ในเฟส 2 และการเชื่อมโยง IKE ที่เสร็จสมบูรณ์ไม่ได้พิสูจน์ว่าข้อเสนอ ESP เหมาะสม

บันทึก backend ก่อนแก้ไขไวยากรณ์: ipsec --version. libreswan และ strongSwan ยอมรับการสะกดข้อเสนอที่ต่างกันสำหรับอัลกอริทึมเดียวกัน

จากนั้นอ่านการปฏิเสธในบริบทด้วย journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

สแกนเกตเวย์เพื่อดูชุดการแปลงของมัน

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

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

อุปกรณ์รุ่นเก่ามักเสนอ 3DES, SHA1 และ MODP1024 เพราะเป็นค่าเริ่มต้นตอนส่งมอบผลิตภัณฑ์และไม่มีใครทบทวนอีก เก็บเอาต์พุตดิบของการสแกนไว้ เพราะเป็นบันทึกเดียวว่าอีกฝ่ายเสนออะไรในวันนั้น หากนี่คือส่วนทับซ้อนที่แข็งแรงที่สุดที่มี การยกระดับที่ถูกต้องคือไปยังเจ้าของเกตเวย์ ไม่ใช่การกำหนดค่าไคลเอนต์ที่เปิดการเข้ารหัสอ่อนสำหรับทุกคนอีกครั้ง

จับคู่ส่วนทับซ้อนโดยไม่ปิดความปลอดภัย

ใส่เฉพาะการแปลงที่ปรากฏทั้งในการสแกนและในนโยบายของคุณ ตัวอย่างด้านล่างสะท้อนเกตเวย์ที่เสนอ 3DES, SHA1 และ MODP1024 ในเฟส 1 สังเกตข้อควรระวังเรื่อง backend: libreswan 4.x ไม่คอมไพล์กลุ่ม modp1024 ดังนั้นสิ่งนี้ใช้กับ strongSwan หรือบิลด์ libreswan ที่รองรับ DH2 ตรวจสอบเวอร์ชันก่อนสรุปว่าไคลเอนต์เสีย

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

เครื่องหมายอัศเจรีย์ท้ายข้อผูกข้อเสนอเดียว ใช้แยกการทดสอบ แล้วนำออกเพื่อให้เกตเวย์เจรจาสิ่งที่แข็งแรงกว่าในภายหลังได้

ตรวจสอบเดมอนและพอร์ตก่อนลองใหม่

NetworkManager-l2tp เริ่มอินสแตนซ์ xl2tpd ของตัวเอง หากบริการระบบเป็นเจ้าของ UDP 1701 อยู่แล้ว ไคลเอนต์จะถอยไปใช้พอร์ตต้นทางชั่วคราว ซึ่ง RFC 3193 อนุญาตและเซิร์ฟเวอร์บางตัวทิ้งไปอย่างเงียบ ๆ ตรวจสอบเจ้าของซ็อกเก็ตก่อนความพยายามครั้งถัดไป

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

ความลับที่สร้างไว้นานแล้วเป็นอีกสาเหตุเงียบ ไฟล์ใต้ /etc/ipsec.d/ ที่ตั้งชื่อตามการเชื่อมต่อเก่าอาจอยู่ได้นานกว่าข้อกำหนดที่สร้างมันขึ้นมา ดังนั้นลบไฟล์ที่ไม่มีอะไรอ้างถึงแล้วลองใหม่

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