תיקון כשל אתחול תת-מערכת החיבור ב-AnyConnect

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

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

קראו את התזמון לפני שמשנים משהו

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

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

שלב 1: ודאו ששירות הסוכן פועל

החלון שאתם לוחצים עליו הוא חזית; העבודה מתבצעת בשירות Cisco AnyConnect Secure Mobility Agent, הרשום בשם vpnagent. אם השירות הזה מופסק או מושבת, לממשק הגרפי אין עם מי לדבר והוא מדווח בדיוק על כשל האתחול הזה. בדקו את המצב ואת סוג האתחול משורת PowerShell עם הרשאות מוגברות:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

מתקין שכיבד סוג אתחול ידני קודם הוא הסיבה הרגילה לכך שזה נגמר מושבת, לכן בדקו את StartType במקום רק ללחוץ על הפעלה. אם השירות מתחיל ונעצר בתוך שניות, קראו ביומן System את רשומות Service Control Manager לפני לחיצה על תיקון:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

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

שלב 2: נקו את מצב אי-החיבור שהמחסנית HTTP מדווחת

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

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

ערך 1 פירושו שמחסנית WinINet אומרת לקוראים שלמכונה אין חיבור; מצב זה מוגדר בדרך כלל על ידי פריט התפריט עבודה לא מקוונת ב-Internet Explorer או על ידי סקריפט אוטומציה. החזירו אותו ל-0, התנתקו והתחברו מחדש, ונסו שוב את החיבור לפני שתשנו משהו אחר.

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

שלב 3: שחררו את המתאם הווירטואלי מ-Hyper-V או ICS

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

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

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

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

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

אמתו, ואז החזירו אחורה את מה שלא הייתם צריכים

האימות אינו המגן הירוק במגש. אשרו שהמתאם קיים, מחזיק כתובת ומעביר תעבורה: Get-NetAdapter -Name "Cisco AnyConnect*" אמור להציג אותו פעיל, ipconfig /all אמור להציג את הכתובת שהוקצתה ואת שרתי ה-DNS, ובקשה אמיתית לשם פנימי אמורה להיפתר דרך המנהרה ולא דרך הפותר המקומי.

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

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