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 בשום מקום חדש.