L2TP เชื่อมต่อได้แต่การเจรจา PPP ล้มเหลว: ระยะใด?

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

อุโมงค์เป็นเพียงชั้นแรก

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

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

อ่านระยะสุดท้ายที่สำเร็จ

ไล่บันทึกไปข้างหน้าและ หยุดที่ระยะแรกที่ยังไม่เสร็จ LCP มาก่อน จากนั้นการพิสูจน์ตัวตน จากนั้น IPCP สำหรับพารามิเตอร์ IPv4

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

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

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

ความเห็นพ้องระหว่างไคลเอนต์และเซิร์ฟเวอร์

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

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

ตรวจสอบที่อยู่ ไม่ใช่การเข้าสู่ระบบ

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

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

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

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