הכניסה של OpenConnect נוחתת בעמוד הלא נכון? בדקו קודם את הנתיב

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

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

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

עם כתובת כמו https://vpn.example.net/partners, הפעולה הראשונה של הלקוח היא בקשת HTTPS לנתיב הזה ולא למארח החשוף. מה שחוזר הוא בדרך כלל הפניה לנקודת ההתחברות, או הטופס עצמו. לקוח שמקבל רק vpn.example.net מתחיל בעמוד הנחיתה שמוגדר כברירת מחדל, וזה יכול להיות פורטל אחר, רשימת קבוצות אחרת או עמוד שמצפה לפרוטוקול אחר לגמרי. ההבדל נראה בכותרות התגובה הרבה לפני שהוקלדו פרטי התחברות כלשהם.

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

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

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

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

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

למה קיצור הנתיב משנה את התוצאה

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

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

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

אשרו את נקודת הכניסה לפני שתערכו כל דבר אחר

קראו את הכותרות של הנתיב שקיבלתם. בקשה כמו curl -sS -o /dev/null -D - https://vpn.example.net/partners מדפיסה את שורת המצב וכל כותרת Location בלי לעקוב אחרי ההפניה. 302 שמצביע לנקודת התחברות בעלת שם מאשר שהנתיב קיים ומראה לאן הוא מוביל; 404 אומר שהכתובת של המפעיל מיושנת.

לאחר מכן שחזרו את אותה נקודת כניסה בלקוח המאושר, למשל openconnect --usergroup=partners vpn.example.net, וצפו איזה טופס מופיע. אם הטופס נכון והמנהרה עדיין נכשלת, הנתיב מעולם לא היה הבעיה והתחנה הבאה היא מדיניות או ניתוב.

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