איך להעביר את OpenConnect לרקע לאחר התחברות אינטראקטיבית
סיימו את ההתחברות בחזית, ואז מסרו את המנהרה למצב הרקע של הלקוח עצמו. הבדיקות ששומרות עליו ניתן לאיתור ולעצירה.
אתם מסיימים את בקשת ה-MFA, המנהרה עולה, וסגירת הטרמינל מורידה איתה את החיבור. זו בעיית פיקוח ולא בעיית אימות, ו-OpenConnect כבר כולל את המתג שפותר אותה. הפתרון הוא לתת ללקוח להסתעף לרקע לאחר שהאתחול מסתיים, כשהחלק האינטראקטיבי באמת נגמר. להלן רצף בדיקות: עברו עליהן לפי הסדר ועצרו בראשונה שאינה מתקיימת בשער שלכם.
ודאו מה השער דורש בהתחברות
לפני שאתם מקלידים פקודה, רשמו את נתיב ההרשאות שהפריסה כופה. תעודה בלבד, סיסמה בתוספת אסימון, וסבב דפדפן דרך ספק SAML מתנהגים אחרת זה מזה, ומצב רקע אינו יכול לדלג על אף אחד מהם. האפשרות משנה את מה שקורה לאחר האתחול, ולעולם לא את מה שקורה במהלכו.
הפתרון המפתה הוא להפוך את הבקשה לאוטומטית. עטיפה שמקלידה תשובה קבועה כשהיא מזהה בקשת סיסמה נשברת ברגע שהשער מבקש קוד חד-פעמי, והיא משאירה הרשאה בקובץ שחשבונות אחרים יכולים לקרוא. אם אדם חייב לאשר את ההפעלה, השאירו את האדם בתהליך.
הריצו את ההפעלה הראשונה בחזית וקראו את הפלט
התחברו פעם אחת כרגיל והניחו לכל לחיצת היד להיות מודפסת. שימו לב לפרוטוקול שבו משתמשים, לנתיב התעודה או האסימון, לכתובת המנהרה שהשרת מקצה, ולכל אזהרה לפני קבלת החיבור. התמלול הזה הוא קו הבסיס שלכם והדרך הזולה היחידה להבחין מאוחר יותר בין תקלת לקוח לשינוי בשער. שמרו אותו מחוץ לחוצץ הטרמינל.
לאחר מכן חזרו על אותה קריאה עם מצב רקע וקובץ PID שהוסף, למשל openconnect --background --pid-file /run/openconnect.pid vpn.example.net, תוך שמירה על הפרוטוקול ואפשרויות האימות שהשער שלכם דורש באותה שורה. מדריך OpenConnect מתאר את האפשרות הזו כהמשך ברקע לאחר סיום האתחול, וזו בדיוק הסיבה לכך שהשלב האינטראקטיבי חייב להסתיים קודם.
הפכו את התהליך הפועל לניתן לאיתור ולעצירה
קובץ PID הוא ראיה רק כל עוד הוא תואם לתהליך חי. שימו אותו בספרייה שבבעלות חשבון השירות, והשוו את המספר שנרשם לטבלת התהליכים לפני שאתם שולחים אות. אתחולים מחדש וקריסות משאירים את הקובץ, וקובץ מיושן הוא הסיבה הרגילה לכך שסקריפט עצירה מדווח על הצלחה בזמן שהמנהרה עדיין עולה. התייחסו לבדיקה כחלק מהליך העצירה, לא כשלב רשות.
שלחו אות ל-PID המאומת, ואז ודאו שממשק המנהרה אכן נעלם במקום לסמוך על סטטוס היציאה. אם הלקוח זקוק להרשאות מוגברות כדי להגדיר את הממשק, האות חייב לבוא מחשבון שמורשה לשלוח אותו.
אל תערמו מצב רקע תחת מפקח
systemd ומפקחים דומים מצפים להחזיק בתהליך שהם הפעילו, ולכן לקוח שמסתעף החוצה מבלבל אותם. המפקח רואה משגר יוצא בזמן שהחיבור האמיתי ממשיך לחיות, כך שלוגיקת האתחול מחדש, דיווח המצב וזמני העצירה מתארים משהו שכבר אינו נכון. כתבו את היחידה במערך החזית הנתמך והשאירו את עבודת הדמון למפקח.
שמרו את --background להפעלות שאדם מתחיל ואז עוזב. אם הדרישה היא מנהרה שקיימת לפני שמישהו מתחבר, החלק החסר הוא זהות לא-אינטראקטיבית מאושרת בתוספת תוכנית לחידושה, ואף דגל שורת פקודה לא מספק אף אחד מהם. הוספת הדגל לסקריפט אתחול מייצרת מנהרה שנכשלת בשקט בהרשאה הראשונה שפגה.
התייחסו לקוקי ההפעלה כאל הרשאה
OpenConnect מתעד שלב אימות נפרד דרך --authenticate, ואת החומר שנוצר אפשר למסור בחזרה עם --cookie-on-stdin. הזוג הזה קיים לעבודת אינטגרציה, ומה שהוא מייצר רגיש כמו הסיסמה שיצרה אותו.
הרחיקו את הערך מהיסטוריית ה-shell, מהלוגים ומכל קריאה שאתם פותחים. סקריפט מסירה חייב גם לשמר את פרטי נקודת הקצה המאומתים שהלקוח קיבל עם הקוקי; אם תאבדו אותם, ריצה מאוחרת עשויה להתחבר למארח שמעולם לא אימתתם, וזה גרוע מחיבור שפשוט נכשל.
עברו על הרשימה לפני שתסגרו את הטרמינל
ארבעה דברים צריכים להתקיים: ההתחברות האינטראקטיבית הסתיימה בחזית, קובץ ה-PID מצביע על תהליך שאימתתם, שאלת המפקח הוכרעה לכאן או לכאן, ולקוקי יש תוכנית אחסון שאינה קובץ טקסט פשוט. כשכל הארבעה מתקיימים, עזיבת הטרמינל בטוחה והמנהרה ממשיכה לפעול.
אם אחד נכשל, תקנו את הפריט הזה לפני שתגעו באחרים, כי שאר הבדיקות אינן יכולות לפצות עליו. שמרו גם את תמלול החזית מהריצה הראשונה: בפעם הבאה שהמנהרה תיפול בלי אזהרה, קו הבסיס הזה מפריד בין שינוי בצד השער לשינוי בצד הלקוח.