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 לא ייחשב לכשל ניתוב.

כתבו את השלב, השיטה והכתובת בהערה אחת ותארכו אותה. אם אותו חשבון ייכשל שוב בעוד חודש, ההערה הזו היא ההבדל בין בדיקה של חמש דקות לחקירה חדשה. כשלים בשלבים שונים הם תקלות שונות, גם כשהלקוח מציג חלון אחד.