L2TP หมดเวลาใน Ubuntu 22.04: บั๊กอุโมงค์ของ xl2tpd
IPsec เชื่อมต่อ PPP ไม่เคยเริ่ม และ xl2tpd ทวนอุโมงค์ที่จับคู่ไม่ได้ ตรวจสอบบิลด์ที่ติดตั้งก่อนแตะ PSK หรือเซิร์ฟเวอร์
เดสก์ท็อปแสดงการเชื่อมต่อที่กำลังดำเนินอยู่ IPsec รายงานความสำเร็จ แต่ส่วนติดต่อ PPP ไม่เคยปรากฏ ใน syslog หมายเลขอุโมงค์เดิมซ้ำไปเรื่อยๆ จนกว่าการพยายามจะหมดเวลาบน UDP 1701 ก่อนแก้ไขคีย์ที่แชร์ล่วงหน้าหรือการตั้งค่าเซิร์ฟเวอร์ ให้รู้จักรูปแบบนี้: บน Ubuntu 22.04 มักเป็นรีเกรสชันของแพ็กเกจใน xl2tpd และเซิร์ฟเวอร์ถูกต้องมาตลอด
คู่บรรทัดใน syslog ที่ซ้ำๆ บอกอะไรคุณ
เซสชันที่ล้มเหลวจะพิมพ์สองบรรทัดเป็นระยะ: เดมอนหาอุโมงค์สำหรับข้อความควบคุมที่เข้ามาไม่พบ แล้วทิ้งตัวระบุการเรียกและอุโมงค์ที่ได้รับมา ต่อมาตัวนับการลองใหม่ถึงขีดจำกัดและการเชื่อมต่อปิดลงด้วยการหมดเวลาที่พอร์ต 1701 ที่อยู่และตัวระบุเป็นเรื่องบังเอิญ รูปแบบต่างหากที่สำคัญ IKE เสร็จสิ้น ทราฟฟิกควบคุม L2TP มาถึง และเดมอนเชื่อมโยงกับอุโมงค์ที่มันสร้างไว้แล้วไม่ได้
ดังนั้นข้อบกพร่องอยู่ระหว่างการควบคุม L2TP กับ PPP ยังไม่มีการทดสอบอะไรเกี่ยวกับความลับ ตัวเลือก PPP หรือซับเน็ตระยะไกล
ยืนยันว่า IPsec สำเร็จจริง
การตรวจสอบสองอย่างแยกกรณีนี้ออกจากปัญหาข้อมูลรับรอง และทั้งสองต้องทำก่อนการเปลี่ยนแปลงแพ็กเกจใดๆ
ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"ผลลัพธ์สถานะแสดงการเชื่อมต่อและสถานะของมัน และอุโมงค์ที่สร้างขึ้นหมายถึงเฟสหนึ่งและเฟสสองเสร็จสมบูรณ์ บรรทัดบันทึกเกี่ยวกับคีย์ที่แชร์หายไปชี้ไปที่ความลับเท่านั้น ดังนั้นหยุดและแก้ไขสิ่งนั้นก่อน เมื่อ IPsec สร้างเสร็จและยังมีการหมดเวลา L2TP ปรากฏ เดมอนคือผู้ต้องสงสัยที่เหลือ เก็บบรรทัดที่แน่นอนจากการพยายามครั้งเดียวแทนการลองใหม่ทั้งวัน
ตรวจสอบบิลด์ของ xl2tpd ไม่ใช่ชื่อรีลีส
บิลด์ jammy ของ Ubuntu สำหรับ xl2tpd 1.3.16 เปิดใช้การปรับให้เหมาะสมตอนเชื่อมโยง ซึ่งทำให้การแยกวิเคราะห์ตัวระบุอุโมงค์ในคำตอบ SCCRP ของเซิร์ฟเวอร์เสีย เดมอนจึงทิ้งแพ็กเก็ตควบคุมสำหรับอุโมงค์ที่มันสร้างเอง สตริงเวอร์ชันสำคัญกว่าชื่อดิสทริบิวชัน
dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showholdแพ็กเกจที่แก้ไขแล้วคือ 1.3.16-1ubuntu0.1 ดังนั้นบิลด์ที่ไม่มีส่วนต่อท้ายนั้นเก่ากว่าการแก้ไข ผลลัพธ์นโยบายแสดงว่าการอัปเกรดจะติดตั้งตัวเลือกใด และรายการระงับอธิบายว่าทำไมการแก้ไขจึงยังไม่มา เมื่อมีแพ็กเกจ ให้อัปเกรดและเชื่อมต่อใหม่ผ่านโปรไฟล์ปกติแทนการแก้ไฟล์ด้วยมือ อย่าสร้างโมดูลใหม่หรือเปลี่ยนความลับขณะที่บิลด์เก่ายังติดตั้งอยู่
ตรวจสอบ PPP หลังการเปลี่ยนแปลง
การอัปเกรดที่สำเร็จพิสูจน์ได้ที่ชั้นที่เสียหาย ตรวจสอบว่า PPP ขึ้นมา ไม่ใช่แค่ว่าไอคอนเปลี่ยน
ip -4 addr show ppp0
ip route | grep pppรายการอินเทอร์เฟซควรแสดงที่อยู่ภายในและที่อยู่เพียร์ และตารางเส้นทางควรมีคำนำหน้าของอุโมงค์ syslog ควรแสดงว่าอุโมงค์ได้รับการยอมรับและ pppd รายงานทั้งสองที่อยู่ โดยไม่มีบรรทัดหาอุโมงค์ไม่พบซ้ำ ถ้า PPP ขึ้นแล้วแต่ทราฟฟิกยังล้มเหลว ให้ดูเส้นทางหรือ MTU ต่อไป เพราะขั้นตอน L2TP ได้ทำงานเสร็จแล้ว บันทึกเวอร์ชันแพ็กเกจที่ใช้งานได้ในบันทึกของเครื่อง เพื่อให้การติดตั้งใหม่ในอนาคตไม่คืนบิลด์ที่เสีย
เมื่อไม่มีแพ็กเกจที่แก้ไขแล้ว ทางเลือกที่บันทึกไว้คือบิลด์จากซอร์สในเครื่องของ 1.3.16 หรือ 1.3.17 การเปลี่ยนไปใช้ kl2tpd หรือการดาวน์เกรดแบบปักหมุด แต่ละอย่างมีต้นทุนการบำรุงรักษาที่ควรบันทึก