למה ה-VPN ב-Mac שלך מבקש גישה ל-Keychain בכל פעם
מפו איזה רכיב מעלה כל בקשת VPN ב-Mac, עצרו ניסיונות התחברות כפולים ותקנו את הגישה ל-Keychain בלי לאפס את כל צרור המפתחות.
לחיצה אחת על Connect אמורה להפיק חלון התחברות אחד. ב-Mac היא לעתים קרובות מפיקה שלושה, ולעיתים נדירות יש להם אותו בעלים: צרור המפתחות הוא הבעלים של בקשות פרטי הגישה המקומיות, שער ה-VPN הוא הבעלים של האימות, והלקוח הוא הבעלים של ההודעות שלו עצמו. במקום לחפש מתג שמשתק הכול, התייחסו לכל חלון כתקלה נפרדת עם התיקון שלה. המדריך שלהלן עובר ניסיון התחברות אחד מכוון ומסתיים בבדיקה שאפשר לחזור עליה.
תנו שם לבעלים של כל דיאלוג לפני ששינוי הגדרה
השלב הראשון הוא תיעוד, לא תצורה. בצעו ניסיון התחברות אחד ולכל חלון שמופיע רשמו ארבעה שדות: שם האפליקציה בדיאלוג, הטקסט המדויק בלי שום דבר סודי, השלב שבו הוא הופיע ומה קרה כשהלכתם לבטל. שלוש שורות כאלה מכסות כמעט כל דוח שבדקתי.
הבעלים קובע את התיקון הנכון, והתיקון השגוי הוא בדרך כלל מה שהופך בקשה אחת לשלוש:
| Window | Who owns it | Correct fix | What not to do |
|---|---|---|---|
| “wants to use your confidential information stored in…” | The item's access control list in your login keychain | Approve the specific client helper, once, after checking the name | Resetting the login keychain, or granting Always Allow to every application |
| “Sign in to <organization>” or an MFA push | The gateway's identity provider | Use the client's supported session renewal, or re-authenticate | Scripting a fixed password or code into the client |
| “Connection failed”, “Update required”, a policy banner | The client or your organization | Read the first error and fix its cause | Hiding notices by editing a preference file the client rewrites |
בקשה שחוזרת במהלך אותו ניסיון היא אות שונה מזו שחוזרת בניסיון הבא. הראשונה בדרך כלל אומרת שהחיבור הופעל מחדש מתחתיכם; השנייה בדרך כלל אומרת שנשאלת שוב פרט גישה שמור. סמנו איזו מהן יש לכם לפני שאתם נוגעים בצרור המפתחות, כי לשתיים אין כמעט דבר משותף.
בררו כמה דברים מפעילים את המנהרה
ארבעה מנגנונים יכולים להפעיל אותו VPN ב-Mac: פעולה בשורת התפריטים, פריט התחברות, כלל On Demand וסקריפט או סוכן. כששניים מהם מופעלים, ההפעלה השנייה עשויה להגיע בזמן שהראשונה עדיין ממתינה לאימות, מה שמייצר חלון כפול בלי שום התקדמות. רשמו תחילה מה מוגדר: scutil --nc list מדפיס את שירותי ה-VPN שהגדרות המערכת מכירות, עם מצבם הנוכחי. לקוחות שמספקים הרחבת רשת משלהם שומרים פרופילים בתוך האפליקציה ואולי לא יופיעו שם, לכן בדקו גם את רשימת החיבורים של הלקוח עצמו.
ואז חפשו מפעילים מתחרים. scutil --nc show "Work VPN" מדפיס את מילון התצורה של שירות מובנה, כולל כללי On Demand; כלל שמתחבר מחדש בכל שינוי ממשק יפעיל מחדש את המנהרה — ויפתח שוב את בקשת האימות — בכל פעם שה-Wi-Fi נודד או שמסך מעיר את מחסנית הרשת. בדקו פריטי התחברות תחת הגדרות המערכת > כללי > פריטי התחברות, ורשמו סוכנים לכל משתמש בעזרת ls ~/Library/LaunchAgents. הניחו לכל מה ששייך למחסנית אבטחה המנוהלת ב-MDM; הסרתו בדרך כלל נדחפת חזרה בבדיקה הבאה.
כדי לראות מה באמת פועל במהלך ניסיון: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. שני עוזרי לקוח במקום שבו ציפיתם לאחד מסבירים "למה קיבלתי שתי בקשות" לעתים קרובות הרבה יותר מכל בעיית פרטי גישה.
תקנו את הגישה לצרור המפתחות בלי לאפס את צרור המפתחות
הבקשה מגיעה מרשימת בקרת הגישה של הפריט השמור, לא מפרוטוקול ה-VPN. כל פריט רושם אילו אפליקציות רשאיות לקרוא אותו בלי לשאול. לאחר עדכון לקוח, העוזר ששואל עשוי לשאת שם או חתימה שונים בעוד הפריט עדיין מפרט את הישן, ולכן macOS שואל שוב בכל חיבור. אישור העוזר החדש לאותו פריט אחד הוא כל התיקון; אישור כל אפליקציה אינו.
אפשר לאשר שה-ACL הוא הסיבה בלי לגעת ב-VPN: security find-generic-password -s "service-name" -g קורא את אותו פריט ממסוף. אם גם הפקודה הזו מעלה את הבקשה, הדיאלוג שייך לצרור המפתחות והמנהרה רק הטריגר. ההנחיות של Apple על שלושת הכפתורים — אפשר פעם אחת, אפשר תמיד, דחה — שוות קריאה אחת, כי דחייה היא מה שמחזיר את הבקשה מיד ולא בניסיון הבא.
אם אישרתם את העוזר הלא נכון, פתחו את הפריט ב-Keychain Access, עברו ל-Access Control והסירו את הרשומה; זה הביטול. מחיקת צרור המפתחות של ההתחברות, או הרצת כלי תיקון שבונה אותו מחדש, משליכה גם סיסמאות לא קשורות ומהווה שינוי גדול בהרבה מהבעיה.
השאירו את שלבי ההתחברות והמדיניות בזרימות שהם שייכים להן
התחברות בדפדפן או אתגר MFA שייכים לשער. אם הארגון שלכם מציע התמדת הפעלה או אימות מבוסס תעודות, השתמשו בו, כי זו הדרך הנתמכת לאמת לעתים רחוקות יותר. הקלדת קוד קבוע בלקוח, או שמירת סיסמה בסקריפט כך שהבקשה לא תופיע לעולם, מחליפה גורם אינטראקטיבי בסוד סטטי ונכשלת בפעם הבאה שהמדיניות מתחלפת.
הודעות הארגון הן הקטגוריה היחידה שאסור להשתק. הן בדרך כלל אוכפות בדיקת מצב או אישור שימוש מקובל, והסתרתן עלולה להוציא את המכשיר מהעמידה בדרישות גם כשהמנהרה עובדת. דיאלוגי השגיאה הם הקטגוריה האחרת: שמרו את טקסט השגיאה הראשון, כי דיאלוג שני הוא לעתים קרובות רק אותה תקלה שדווחה אחרי ניסיון חוזר.
אמתו בניסיון אחד, ואחר כך לאחר אתחול
לאחר שהמפעילים הכפולים הוסרו ורשומת צרור המפתחות תוקנה, בצעו ניסיון אחד: סגרו כל מופע של הלקוח כולל עוזר שורת התפריטים, התחברו פעם אחת וספרו את החלונות. אתם רוצים את אישור צרור המפתחות, אם הפריט נבנה מחדש, ושלב אימות אחד. לא יותר. scutil --nc status "Work VPN" אמור לדווח Connected עבור שירות מובנה.
ואז אתחלו פעם אחת וחזרו. בקשה שחוזרת רק לאחר אתחול מצביעה על פריט התחברות או כלל On Demand, לא על פרטי גישה; זו שחוזרת בתוך ההפעלה מצביעה על ה-ACL או על מפעיל שני. אם היא עדיין חוזרת לאחר שני המעברים, הדבר השימושי לתת למנהל שלכם הוא הטבלה בת שלוש השורות מהניסיון הראשון — בעלים, טקסט מדויק, שלב — ולא צילום מסך של הדיאלוג.
פחות בקשות הוא היעד, לא בקשות שקטות. חיבור שמסתיר את שלבי ההרשאה שלו הוא חיבור שכבר אי אפשר לבקר, וסבב התעודות הבא ימצא אתכם בלי מושג איזה רכיב נכשל.