เดสก์ท็อปแสดงการเชื่อมต่อที่กำลังดำเนินอยู่ 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 หรือการดาวน์เกรดแบบปักหมุด แต่ละอย่างมีต้นทุนการบำรุงรักษาที่ควรบันทึก

บทความที่เกี่ยวข้อง