בקשת מנהל ב-Mac-VPN: התקנה, הרחבה או מדיניות?
בקשת מנהל ב-macOS יכולה להיות מתקין, תצורת רשת, אישור הרחבה או מדיניות MDM. זהה את ההודעה לפני שתקליד.
בקשות סיסמה מלקוח VPN נראות זהות ואינן כאלה. ארבע פעולות נפרדות מסתתרות מאחורי דיאלוג דומה: כתיבת קבצים למיקום מוגן בזמן ההתקנה, הוספה או שינוי של תצורת רשת, הפעלה של הרחבת מערכת שנושאת תעבורה, וציות למדיניות ששרת ניהול כבר הגדיר. לכל אחת בעלים אחר, רדיוס השפעה אחר ודרך אחרת לאמת שהיא עבדה. ההתאמה בין ההודעה שאתה רואה לאחת מארבע היא כל התרגיל.
שלושה אישורים שונים נראים אותו דבר
אישור מתקין הוא המקרה הפשוט ביותר: חבילה כותבת לתיקיות שמשתמש רגיל אינו יכול לשנות, ו-macOS מבקש פרטי מנהל כדי לאפשר זאת. המערכת אינה מחליטה אם התוכנה בטוחה; היא מחליטה אם מותר לך לכתוב שם. זו גם הסיבה שחבילה יכולה להתקין בצורה נקייה ועדיין להיות חסרת תועלת: אישור התקנה אינו אומר דבר על האם לקוד יורשה לרוץ אחר כך. לאחר ההתקנה, היישום עשוי להזדקק לאישור שני לפני שיוכל להשפיע על הרשת.
אישור תצורת רשת מכסה שינויים ברשימת החיבורים של המערכת. הוספת שירות VPN, או שינוי הגדרות שמנהל רשת הגדיר, דורשת הרשאה מוגברת מפני שהגדרות אלו משפיעות על כל חשבון במכונה. אישור זה מעניק סמכות תצורה, לא סמכות תעבורה.
אישור הרחבה הוא זה שחשוב לאופן שבו מנות נוסעות. לקוח מודרני מתקין הרחבת מערכת ש-macOS טוען לתוך המערכת, ו-macOS דורש החלטה מפורשת בפרטיות ואבטחה או בפריטי התחברות והרחבות לפני הפעלתה. מקרה רביעי הוא Mac מנוהל, שבו מדיניות כבר מאשרת מראש את ההרחבה והמשתמש אינו רואה דיאלוג כלל.
מה כל אישור באמת משנה
מתקין משנה קבצים בדיסק, והשלכותיו מסתיימות כשהקבצים מוסרים, מלבד שאריות. תצורת רשת מוסיפה הגדרת שירות שמופיעה ברשימת החיבורים ועשויה להיות מופעלת מחדש על ידי כללי דרישה. אישור הרחבה משנה איזה קוד המערכת תטען ותשאיר פועל, ולכן הוא שורד הסרת התקנה של היישום החזותי בחלק מתהליכי העבודה. הסרת חבילת יישום אינה תמיד מסירה את ההרחבה שלו, והרחבה שנותרה מאחור שומרת על הרשאות הרשת שלה.
ההבחנה חוזה את התסמין. מותקן אך אינו מתחבר בדרך כלל אומר שההרחבה אינה מאושרת בשום מקום; מתחבר אך עם הגדרות שחוזרות בשינוי הבא בדרך כלל אומר שמדיניות ניהול היא הבעלים של ההגדרה.
חתימה ומפרסם מכריעים את התשובה
לפני אישור, קרא מי חתם על הדבר ולא מה שהסמל של הדיאלוג מרמז. שתי בדיקות מקומיות מספיקות כדי לראות את סמכות החתימה ואם הערכת המערכת עוברת במכונה זו.
codesign -dv --verbose=2 /Applications/ExampleVPN.app
spctl -a -vv /Applications/ExampleVPN.app
חבילה לא חתומה או לא נוטררה אינה זדונית אוטומטית, אך היא ראויה להחלטה שונה מזו של חבילה חתומה מהספק שהתכוונת אליו. חבילה שהגיעה בהודעה ולא מאתר הספק עצמו היא המקרה שבו התשובה היא פשוט לא.
השווה את מזהה הצוות לזהות המפורסמת של הספק במקום לסמוך על שם התצוגה של היישום, שכן שמות קלים לשימוש חוזר ומזהים לא. אם הספק מפרסם את המזהה במדריך ההתקנה שלו, אותו עמוד הוא ההתייחסות להשוואה וגם המקום שבו יש לדווח על אי התאמה. לקוח מסוכן מפיץ, מבנייה ארוזה מחדש או מהעתק נייד מפורום ראוי לחשד רב יותר מאשר ההורדה החתומה של אותו ספק.
כשמדיניות היא הבעלים של ההחלטה
ב-Mac ארגוני ייתכן שהמנהל כבר החליט. פרופיל ניהול יכול לספק את הגדרת ה-VPN, לאשר מראש את ההרחבה ולנעול את החיבור כך שלא ניתן להסירו. בסידור כזה הבקשה להזין סיסמה היא לעתים קרובות בקשה לעקוף החלטה שמעולם לא הייתה שלך.
הורדת אבטחת האתחול או ניתוק הניהול כדי לכפות התקנה משנה את מודל האיומים של המכונה לצמיתות כדי לפתור בעיה זמנית. עסקה זו נעשית לעתים רחוקות במודע; היא קורית בדרך כלל בזמן מעקב אחר פוסט בפורום. בקש מהמנהל את הנתיב הנתמך במקום זאת, שעשוי להיות פשוט כמו שליחה מחדש של הפרופיל או אישור ההרחבה בצד השרת. אם המנהל אינו יכול לאשר אותה, התשובה הזו היא הממצא, לא מכשול לעקוף.
אמת את המצב לאחר האישור
לאחר שניתן אישור מורשה, אמת מה המערכת חושבת ולא מה הלקוח טוען. רשימת ההרחבות מדווחת על מצב ההפעלה בלי צורך בכלי צד שלישי.
systemextensionsctl list
רשומה המוצגת כמופעלת שייכת למזהה הצוות שבדקת קודם; רשומה המוצגת כמופסקת וממתינה לאישור משתמש מסבירה לקוח שמתחיל ואינו נושא תעבורה לעולם. אם הבקשה חוזרת לאחר כל ניסיון, תעד את ההודעה המדויקת ואת גרסת הלקוח, מפני שאישור חוזר בדרך כלל אומר שההרחבה מוחלפת בלי שהקודמת הופסקה, וזה מקרה תמיכה ולא בעיית סיסמה. רשום את הגרסה לפני שקוראים לתמיכה, שכן התיקון עשוי כבר להתקיים בבנייה חדשה יותר והשיחה תתחיל שם.