บันทึกดีบัก L2TP ว่างเปล่า? ข้อผิดพลาดน่าจะอยู่ใน journal

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

สี่กระบวนการ จุดหมายของบันทึกสองแห่ง

การเชื่อมต่อเริ่มด้วย IPsec ซึ่งเป็น libreswan หรือ strongSwan ขึ้นอยู่กับการติดตั้ง จากนั้น daemon L2TP ซึ่งโดยปกติคือ xl2tpd และในบางบิลด์คือ kl2tpd จะขับเคลื่อนอุโมงค์ สุดท้าย pppd จัดการการพิสูจน์ตัวตนและการกำหนดที่อยู่ภายใน

บริการตัวช่วยประสานส่วนเหล่านั้นและพิมพ์ความคืบหน้าของตัวเอง โดยปกติ daemon IPsec และ pppd รายงานผ่าน journal ของระบบ จึงเป็นเหตุให้เทอร์มินัลแสดงการเชื่อมต่อที่ล้มเหลว ขณะที่สาเหตุอยู่ในไฟล์ที่คุณยังไม่ได้เปิด

การแยกนี้ยังอธิบายว่าทำไมข้อผิดพลาด PSK และข้อผิดพลาดรหัสผ่านจึงดูเหมือนกันจากเดสก์ท็อป ทั้งสองทำให้เกิดการตัดการเชื่อมต่อทั่วไป และขั้นตอนที่ล้มเหลวจะเห็นได้เฉพาะในผลลัพธ์ของแต่ละกระบวนการ นี่คือเหตุผลทั้งหมดที่ journal สำคัญที่นี่ ข้อความทั่วไปหนึ่งข้อความบนเดสก์ท็อป ผู้เขียนที่เป็นไปได้สี่รายอยู่เบื้องหลัง

เก็บความพยายามหนึ่งครั้ง แล้วอ่านลำดับ

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

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

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

ฟิลด์ที่ซ้ำกันในการเรียกครั้งเดียวจะเลือกการรวมของกระบวนการเหล่านั้น ซึ่งรักษาลำดับตามเวลา ในระบบที่ใช้ Debian คำสั่งที่เทียบเท่าคือ dpkg -L ประเด็นคือการหาว่าตัวช่วยอาศัยอยู่ที่ใดจริง ๆ ก่อนพยายามเรียกใช้ด้วยมือ

สามเงื่อนไขกำหนดก้าวต่อไป

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

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

สามสาขานี้ครอบคลุมเกือบทุกการตัดการเชื่อมต่อทั่วไป และตัดสินด้วยว่ากระบวนการใดบันทึกข้อผิดพลาดสุดท้าย ไม่ใช่ข้อความข้อผิดพลาดใดที่ดูน่ากังวลที่สุด

ควรยืนยันด้วยว่า backend ของ IPsec ใดถูกติดตั้ง ก่อนแตะการตั้งค่าการดีบัก ตัวเลือกการบันทึกที่เขียนสำหรับ strongSwan ไม่ทำอะไรเลยเมื่อ libreswan กำลังทำงาน และการเชื่อมต่อจะยังล้มเหลวที่จุดเดิมขณะคุณแก้ไขไฟล์ที่ไม่มีใครอ่าน

โหมดดีบักทิ้งไฟล์ไว้

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

ไฟล์เหล่านั้นมีวัสดุการพิสูจน์ตัวตน ได้แก่ คีย์ที่แชร์ล่วงหน้า ข้อมูลรับรอง หรือทั้งสองอย่าง การกำหนดค่าที่สร้างขึ้นซึ่งคัดลอกไปยังหน้าต่างแชตคือการเปิดเผยข้อมูลรับรอง ไม่ใช่ข้อความที่ตัดตอนจากบันทึก ลบเส้นที่เป็นความลับก่อนแชร์สิ่งใด และลบไดเรกทอรีเมื่อการสอบสวนสิ้นสุด ปฏิบัติต่อไฟล์เหล่านี้เป็นความลับ ดึงเฉพาะเส้นที่คุณต้องการสำหรับรายงาน แล้วลบภายหลัง แทนการวางไดเรกทอรีลงในตั๋ว

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

จากนั้นคืนค่าตัวช่วยปกติ

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

จากนั้นตรวจสอบผลลัพธ์ในชั้นที่ล้มเหลว ไม่ใช่ที่ไอคอนเดสก์ท็อป

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

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