หาไฟล์ไบนารี pppd ไม่พบ: แก้สภาพแวดล้อมรันไทม์ ไม่ใช่การยืนยันตัวตน

ไม่มีข้อมูลไปถึงเกตเวย์ เพราะไคลเอนต์หาไบนารีที่ต้องใช้ก่อนไม่พบ ข้อความระบุตัวช่วยของสภาพแวดล้อมรันไทม์ และปฏิกิริยาตามปกติคือสันนิษฐานว่าอีกฝั่งปฏิเสธบางอย่าง มันไม่ได้ปฏิเสธ การเชื่อมต่อที่ใช้ PPP ต้องมีตัวช่วยนั้นบนเครื่องท้องถิ่น และมันหายไป อ่านไม่ได้ หรือไม่อยู่ในที่ที่ผู้เรียกค้นหา

เมนูกับเดมอนเป็นคนละเรื่อง

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

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

อ่านแพ็กเกจ ไม่ใช่ไฟล์

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

แยกโหมดล้มเหลวสามแบบ: แพ็กเกจที่ติดตั้งไม่สำเร็จ รีโพซิทอรีที่ไม่เสนอผู้สมัคร และไบนารีที่ติดตั้งด้วยมือบอกความเป็นเจ้าของของแพ็กเกจ สิ่งเหล่านี้ต้องแก้ต่างกัน และแก้ได้เฉพาะแบบแรกด้วยการติดตั้งแพ็กเกจเดิมซ้ำ

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

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

ซ่อมสภาพแวดล้อมโดยไม่ทำให้ตัวอื่นพัง

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

การติดตั้งไคลเอนต์ VPN อื่นก็ไม่ใช่การซ่อมแซมเช่นกัน มันสร้างข้อกำหนดด้านความเข้ากันได้ใหม่พร้อมทิ้งโปรไฟล์เดิมไว้โดยไม่อธิบาย

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

ถือว่าข้อผิดพลาดถัดไปเป็นขั้นใหม่

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

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

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