בקשת TOTP של OpenConnect חסרה ב-NetworkManager: ארבע בדיקות

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

בדיקה ראשונה: קראו היכן האימות נעצר

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

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

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

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

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

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

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

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

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

בדיקה שלישית: ראו אם התוסף שלכם חושף מצב TOTP

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

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

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

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

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

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

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

אשרו את אותו שער ואת אותו חשבון

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

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

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