פרופיל VPN לא מיובא ב-macOS: קראו קודם את המטען

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

קראו את הפרופיל במקום לאפס את ה-Mac

ייצאו את .mobileconfig ובדקו מה באמת יש בו לפני שאתם נוגעים בלקוח:

plutil -p profile.mobileconfig | head -60

פרופיל VPN הוא למעשה שני מטענים עם תפקידים שונים: com.apple.vpn.managed מחזיק את החיבור, ו-com.apple.dnsSettings.managed מחזיק את תצורת הפותר. ההתקנה נעצרת במטען הראשון שהמתקין דוחה, והדחייה נרשמת ביומן המערכת עם שם אותו מטען, ולכן היומן הוא זה שאומר לכם איזה סעיף לפתוח. שמרו עותק של הפרופיל האחרון שכן יובא, מפני שקובץ זה הוא הבסיס שמולו נמדד ההבדל שלכם.

מה המחולל הוסיף בשקט

Apple Configurator 2.15, גרסה 7A23, פלט את הבלוק הבא בתוך מטען ה-DNS שלו:

<key>DNS</key>
<dict>
  <key>SupplementalMatchDomainsNoSearch</key>
  <integer>0</integer>
</dict>

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

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

מסלול ה-MDM נכשל במקום אחר

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

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

ודאו שהפרופיל באמת נחת

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

profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20

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

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

פרסו בשלבים, Mac אחד בכל פעם

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

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