LCP ถูกยุติโดยคู่บน PPTP: เปิดใช้ MPPE ก่อน

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

LCP ล้มเหลวบอกอะไรเกี่ยวกับขั้น PPP

PPTP ห่อ PPP ไว้ใน GRE การเชื่อมต่อควบคุม TCP 1723 ตั้งสายเรียก GRE ขนส่งข้อมูล แล้ว LCP จึงเจรจาตัวเลือกอย่างโปรโตคอลการพิสูจน์ตัวตน การบีบอัด และ MPPE คู่จะยุติ LCP เมื่อตัวเลือกที่จำเป็นไม่เป็นที่ยอมรับฝั่งของตน บันทึกที่การแลกเปลี่ยน CHAP หรือ MSCHAPv2 เสร็จสิ้นแล้ว LCP จบลงทันทีหลังจากนั้นคือการปฏิเสธเชิงนโยบาย ไม่ใช่ความล้มเหลวในการเข้าถึง ถ้าอุโมงค์ไปไม่ถึงการเจรจาเลย ให้ตรวจสอบ pppd และปลั๊กอินก่อนอ่านบรรทัด LCP

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

เปิดใช้ MPPE ฝั่งที่เรียกหา

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

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

โหลดโมดูลด้วย modprobe ppp_mppe ก่อนหมุนสาย เพราะ require-mppe-128 จะล้มเหลวหากไม่มี บน Windows ตัวควบคุมที่เทียบเท่าคือแท็บความปลอดภัยของรายการ VPN ซึ่งต้องสั่งให้ไคลเอนต์เรียกหาการเข้ารหัสแทนที่จะยอมรับสิ่งที่เซิร์ฟเวอร์เสนอ หากเซิร์ฟเวอร์ยังยุติ LCP ให้ถามผู้ดูแลว่าระบบบังคับ เป็นทางเลือก หรือปิดใช้งาน MPPE เพราะไคลเอนต์เจรจาการป้องกันที่เซิร์ฟเวอร์ปฏิเสธไม่ได้ การปิดการเข้ารหัสเพื่อให้ข้อความหายไปเป็นทิศทางที่ผิด เพราะเป็นการถอดการป้องกันเดียวที่โปรโตคอลนี้มี

บันทึกไฟล์คู่ที่ใช้งานได้ก่อนแก้ไข บรรทัด require-mppe ที่พิมพ์ผิดจะสร้างความล้มเหลว LCP แบบทั่วไปเดิมขึ้นมาอีกและพาคุณกลับไปเริ่มต้น

อ่านบันทึกของ pppd เอง ไม่ใช่แอปเพล็ต

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

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

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

รักษาการแก้ไขให้อยู่รอดเมื่อเชื่อมต่อใหม่: ชื่อฮุกและ MTU

เมื่อลิงก์ยังอยู่ รายละเอียดสองอย่างตัดสินว่าจะทนการเชื่อมต่อใหม่ได้หรือไม่ ฮุกอยู่ใน /etc/ppp/ip-up.d และ /etc/network/if-up.d และทั้งสองไดเรกทอรีถูกประมวลผลโดย run-parts ซึ่งตัวกรองชื่อไฟล์จะปฏิเสธทุกอย่างที่มีจุด ดังนั้นสคริปต์ชื่อ set-pptp.sh จะถูกข้าม ขณะที่ set-pptp ถูกเรียกใช้ ตรวจสอบชื่อก่อนแก้ไขเนื้อหาสคริปต์ แล้วตั้ง MTU ที่เล็กกว่าจากภายในฮุกนั้น เพื่อให้ทุกอินเทอร์เฟซ ppp ใหม่ได้รับค่าโดยไม่ต้องสั่งด้วยมือ

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

หากต้องการจบเซสชันโดยเจตนา ให้เล็งที่ pid ที่ pppd บันทึกไว้แทนการจับคู่ชื่อโปรเซส เพราะการฆ่าทุกอย่างที่มี ppp จะทำให้ลิงก์ที่ไม่เกี่ยวข้องขาดด้วย PPTP ล้าสมัยและ MS-CHAPv2 อ่อนแอ ดังนั้นจงถือการตรวจเหล่านี้เป็นการบำรุงรักษาลิงก์ที่ต้องทำงานต่อไป ไม่ใช่เหตุผลในการติดตั้ง PPTP ที่ไหนใหม่