שער Juniper או Pulse: איזה פרוטוקול OpenConnect להשתמש

בחירת פרוטוקול ל-OpenConnect היא תרגיל התאמה, לא חיפוש מותג. שער שאומר Juniper בעמוד הכניסה עשוי לחשוף Network Connect, Pulse או את שניהם, וברירת המחדל של הלקוח היא אף אחד מהם. ניחוש עולה בכניסה כושלת ובדיון תמיכה שמאשים את פרטי הכניסה באי-התאמת פרוטוקול. אשרו את השירות לפני שאתם מקלידים שם מארח בפרופיל.

OpenConnect מכנה את הפרוטוקול הישן nc ואת החדש pulse, ושניהם חיים באותו קובץ בינארי. הדגל שבוחרים משנה את חילופי הכניסה, לא את הניתוב שאחרי חיבור מוצלח.

שני שמות הפרוטוקול חולקים היסטוריית מוצר אחת

Network Connect של Juniper ולקוח Pulse Secure המאוחר יותר הם פרוטוקולים שונים שמשפחת התקנים אחת חשפה לאורך זמן. OpenConnect פיתח מטפל nc לראשון ומטפל pulse לשני. אלו מסלולי קוד נפרדים עם פורמטי בקשה נפרדים, כך שתמיכה באחד לא אומרת דבר על השני.

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

בחירה בשורת הפקודה היא שינוי של מילה אחת: openconnect --protocol=nc vpn.example.com עבור Network Connect, או openconnect --protocol=pulse vpn.example.com עבור Pulse. שתי הניסיונות הם ניסיונות חיבור אמיתיים שיכולים להגדיר מחדש מסלולים ו-DNS, לכן הריצו אותם בכוונה. לעולם אל תשימו סיסמה בשורת הפקודה ואל תכבו בדיקות תעודות כדי לעקוף שגיאת פרוטוקול, כי זה מסתיר את אי-ההתאמה במקום לתקן אותה. אם צריך לראות מה הלקוח שולח, --dump-http-traffic מדפיס את החילוף, שלרוב מזהה את המטפל שהשער מצפה לו.

התאימו את הפרוטוקול למה שהשער חושף

ההתקן עונה רק לפרוטוקול שלו הוא מוגדר. שירות Pulse בלבד דוחה כניסת nc גם עם פרטי כניסה תקפים, ולשירות Network Connect ישן אין נקודת קצה pulse שתענה. שאלו את המנהל איזה מהם מופעל, ואיזה לקוח הם תומכים בו. התקן ששמו שונה, עמוד ויקי מיושן ופורטל אינטרנט מוכר הם כולם ראיות חלשות.

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

האימות יכול להכריע בשאלה לפני הפרוטוקול

פריסה עשויה לדרוש תעודת לקוח, סבב SAML דרך דפדפן, או בודק מארח שבוחן את המכונה לפני מתן גישה. מטפל ה-pulse של OpenConnect מתעד מגבלות תאימות לחלק מהזרימות האלה, ולמטפל nc יש פערים משלו. סיסמה שעובדת בדפדפן מוכיחה שהחשבון תקף; היא לא מוכיחה שממשק CLI או תוסף שולחני כלשהו יכול להשלים את אותו רצף. כשמעורב בודק מארח, הלקוח צריך סקריפט עטיפה שהמנהל מספק. בלעדיו הכניסה נתקעת אחרי התגובה הראשונה ונראית כמו כשל פרוטוקול כשבפועל זה שלב תאימות חסר.

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

בשורת הפקודה, --authgroup="Employees" מספק את הבחירה הזו, והשמטתו עלולה להשאיר את החיבור בקבוצת ברירת מחדל שדוחה את החשבון. עם תעודות, --certificate מצביע על תעודת הלקוח והמפתח, והשער עשוי עדיין לדרוש טוקן אחר כך. בדקו את הרצף המלא פעם אחת עם פלט מפורט לפני שתאוטמטו משהו סביבו.

כשממשק שולחן העבודה לא יכול לבטא את הבחירה

ממשקים גרפיים נושאים מערכי תכונות משלהם, ותוסף ישן עשוי להיות לפני הפרוטוקול שאתם צריכים. שילוב ה-OpenConnect של NetworkManager שומר את הבחירה בנתוני החיבור שלו, כך ש-nmcli connection modify "Office VPN" vpn.data "protocol=pulse" יכול לקבוע את מה שהעורך לא מציג. בדקו שהגרסה המותקנת של התוסף תומכת במפתח לפני שתניחו שהעריכה נכנסה לתוקף.

אם תפריט מציע רק PPTP או L2TP, בחירת אחד מהם לא ממירה שירות Pulse לפרוטוקול הזה. התקינו את השילוב המאושר במקום לעבור למה שהתפריט במקרה מפרט.

מה לתעד כשהכניסה עדיין נכשלת

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

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