AnyConnect מתנתק כשמסוף נסגר: בדיקות הפעלה

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

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

הפרידו בין נפילת הפעלה לנפילת שכבת הרשת

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

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

בדקו מה הלקוח רשם בעת ההתחברות

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

פרטו מה הלקוח יכול היה לראות לפני שתשנו משהו:

who
w
last -n 10
sudo ls -l /run/utmp

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

הסירו רק את הרשומה שלכם מ-utmp

העקיפה שפורסמה הופכת את ההפעלה שאתם עומדים להשתמש בה לבלתי נראית ב-utmp לפני שהלקוח מתחיל. תוכנית C קטנה עוברת על getutent(), מאתרת את הרשומה שה-ut_line שלה שווה ל-TTY של הקלט התקני, ואז כותבת מחדש את הרשומה הזו. הסדר מכוון: setutent(), לקרוא את הרשומה, להעתיק את ה-ut_id שלה, להגדיר ut_type ל-DEAD_PROCESS, לנקות את שדות המשתמש והשורה, לכתוב אותה בחזרה עם pututline(), ואז endutent().

קמפלו אותו, ואז הריצו אותו כ-root מהמעטפת שתתחיל את הלקוח:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

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

אשרו שהמנהרה שורדת את הסגירה

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

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

מתי כתיבה מחדש של utmp היא התשובה השגויה

utmp הוא חשבונאות משותפת, לא טבלה פרטית. כתיבה מחדש של רשומת הפעלה שעוד חיה גורמת ל-who, ל-w ולחלק מכלי הביקורת לדווח עליה בחסר, ותוכנית שתסגור אחר כך את אותה רשומה עלולה להיכשל לגמרי. הגבילו את הכלי להפעלה שלכם בלבד, שמרו עותק של הקובץ המקורי, ואל תהפכו אותו לשירות אתחול שמסיר כל רשומה.

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

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