SSTP בלינוקס נכשל לפני התחברות? בדקו את חלקי זמן הריצה

אתם מתקינים את התוסף SSTP, כפתור הבחירה מופיע בעורך הרשת, ממלאים שער ושם משתמש, והפרופיל נכשל בשגיאה כללית לפני שהוא בכלל מבקש סיסמה. אין שום דבר חריג ברצף הזה, ואין בו דבר שמוכיח שתוכנת המנהרה מותקנת. חיבור SSTP מורכב מחלקים שנשלחים בנפרד: תוסף VPN ש-NetworkManager יכול להפעיל, תוכנת לקוח SSTP שמחזיקה בהפעלת TLS ו-PPP, דמון ה-PPP שמתחתיה, ומאגר סודות שמותר לחיבור לקרוא.

מה רשומת התפריט מוסיפה ומה לא

התוסף תורם תיאור שירות שאומר ל-NetworkManager איך להפעיל אותו, וברוב ההפצות עורך קטן שמצייר את הטופס. זה כל היקף רשומת התפריט. תוכנת הלקוח מגיעה מחבילת מקור אחרת, וה-README של התוסף עצמו אומר את הפיצול ישירות: זה תוסף, לא לקוח.

אחר כך הלקוח צריך PPP, כי SSTP נושא הפעלת PPP בתוך חיבור TLS. בלי pppd המנהרה יכולה להשלים את לחיצת היד של TLS ובכל זאת למות במסגרת הבקרה הראשונה, מה שנראה כמו בעיית אישורים ולא כך. ב-Debian וב-Ubuntu החלקים מגיעים כ-network-manager-sstp, sstp-client ו-ppp, והתקנה של הראשון בלבד היא הסיבה הנפוצה ביותר לכך שהטופס מקבל כל שדה אבל החיבור לא מסתיים לעולם.

בחירת שולחן העבודה מוסיפה פיצול נוסף. Plasma עורך פרופילים דרך plasma-nm, שזקוק לרכיב SSTP משלו וקורא את אותו תיאור שירות, כך שעורך בלי רשומת SSTP ו-CLI שיוצר פרופילים היטב הוא חצי עורך חסר, לא סביבת ריצה שבורה.

קראו את השלב הראשון שנכשל לפני שמתקינים מחדש משהו

ניסיון SSTP כושל עובר שלבים בסדר קבוע, והשלב שנכשל אומר לכם באיזה רכיב להסתכל.

הפעלת התוסף היא הראשונה, וכשל בה מייצר הודעה על שירות ה-VPN ולא על השרת. אחר כך מגיע חיבור TCP לפורט 443; סירוב או פסק זמן כאן הם בעיית נגישות, לא בעיית TLS. אחר כך לחיצת היד של TLS ובדיקת זהות השרת, אחר כך משא ומתן PPP ואימות החשבון, ולבסוף הקצאת כתובת ומסלולים. עקבו אחרי journalctl -f -u NetworkManager כשאתם מפעילים את הפרופיל פעם אחת, וקראו את השורה הספציפית הראשונה ולא את האחרונה הכללית.

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

אמון בתעודה והתחברות לחשבון הם שני שערים נפרדים

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

פרופיל שסומך על המנפיק הלא נכון נכשל בשער הראשון בשגיאת זהות. פרופיל שסומך עליו נכון אבל שומר סיסמה מיושנת נכשל בשני בדחיית אימות. שניהם נראים כמו VPN שלא יתחבר, ואף אחד מהם לא מתוקן בתרופה של האחר.

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

תנו לבעלים אחד להחזיק בפרופיל ובסודות

לאחר שהפרופיל קיים, הפעילו אותו דרך NetworkManager ותנו למנהל הזה להחזיק במסלולים ובשינויי הפותר שנובעים מכך. הפעלת לקוח SSTP עצמאי שני בזמן ש-NetworkManager כבר מריץ את החיבור נותנת לכם שתי קבוצות מסלולים, שני תצורי DNS והפעלת ניפוי באגים בלי מקור אמת אחד.

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

בדקו את המנהרה, המסלולים והפותר בנפרד

מחוון «מחובר» טוען רק שהקישור עלה. בדקו את היעד שאתם באמת צריכים, את המסלול שנושא אותו, ואת הפותר שבשימוש, אחד בכל פעם; כל אחד יכול להיות שגוי כשהשניים האחרים תקינים.

בניסיון כושל, תעדו את הגרסה של כל רכיב ואת טקסט השגיאה המנוקה. שתפו אותם, לא את הפרופיל המלא, כי הפרופיל יכול להכיל את הסוד המשותף מראש ואת האישורים השמורים שלכם.

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