למה ההתחברות ל-openfortivpn נכשלת כשמדביקים את כתובת ה-URL של הפורטל

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

כתובת פורטל של Fortinet כמו https://vpn.example.com/ext נושאת כמה פריטי מידע בבת אחת, ורק חלק מהם שייכים ללקוח ה-VPN.

נקודת הקצה וה-realm הם קלטים נפרדים

openfortivpn מצפה לנקודת קצה בצורה host או host:port, בתוספת חשבון ואם הפריסה משתמשת בכך, ערך realm. ה-realm אומר לשער איזו מדיניות אימות להחיל לפני שהוא מעריך את החשבון. זהו שדה נפרד, לא סיומת שהלקוח מחלץ מכתובת URL.

בפריסה שהמפעיל שלה מאשר שה-realm הוא ext, קריאה שאינה סודית נראית כך: openfortivpn vpn.example.com:443 --username=alice --realm=ext. אותם ערכים שייכים לקובץ התצורה כרשומות host, port, username ו-realm. השאירו את הסיסמה מחוץ לשתי הצורות ותנו ללקוח לבקש אותה, כדי שהיא לא תגיע להיסטוריית ה-shell או לקובץ שכל אחד יכול לקרוא. ניסיון שני בזמן שהלקוח הראשון עדיין מחזיק במנהרה ייכשל מסיבה שאין לה שום קשר ל-realm.

מדריך openfortivpn מפרט את שתי האפשרויות, כך שקל לאמת את האיות המדויק לפני פנייה לתמיכה. עם זאת הוא אינו יכול לומר לכם איזה realm מוגדר בשער שלכם.

מקטע נתיב אינו realm באופן אוטומטי

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

realm אינו גם אותו דבר כמו סיומת דומיין בשם המשתמש או האזור שבו נמצא השער. יש פריסות שרוצות alice, אחרות רוצות alice@corp, וה-realm קובע איזה מהשניים השער יקבל. שינוי תבנית החשבון כדי לפצות על realm שגוי מייצר בדרך כלל דחייה שנייה ופחות אינפורמטיבית.

אל תתקנו שגיאת realm על ידי שינוי המארח

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

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

הפרידו בין כניסה שנדחתה לבין מנהרה שנכשלה

כשלי אימות וכשלי מנהרה מגיעים ברגעים שונים, וההודעות שונות. שגיאת פתרון שם מתרחשת לפני כל לחיצת יד TLS. דחיית TLS מתרחשת לפני שליחת האישורים. דחיית realm או חשבון חוזרת כתשובה ברמת HTTP מהפורטל. רק אחרי השלבים האלה מתחיל משא ומתן PPP, ורק אז מופיעים בעיות ניתוב ו-DNS.

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

שמרו את הערכים במקום שבו ההפעלה הבאה תמצא אותם

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

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