App Store לא מצליח להתחבר אחרי VPN או מסנן תוכן

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

תנו שם לכשל לפני שאתם משנים משהו

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

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

שלב ראשון: לשלול את שירותי Apple ואת השעון

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

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

בדקו התקן שני באותה רשת אם אפשר. שני התקנים שנכשלים יחד מצביעים על הרשת או על השירות; התקן אחד שנכשל לבדו מצביע על התצורה של אותו Mac.

שלב שני: לזהות איזה רכיב המוצר התקין

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

בגרסאות macOS הנוכחיות הרחבת הרשת מופיעה בהגדרות המערכת באזורי הפרטיות והרשת, לצד כל תצורת proxy וכל הגדרות DNS שהמוצר הוסיף. רשמו מה מצאתם, כולל אם המוצר אוכף חסימה שמחייבת בכוונה שה-VPN יהיה מחובר.

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

שלב שלישי: לשנות נתיב אחד בדיוק בכל פעם

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

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

שלב רביעי: לתקן בדיקה במערכת הבודקת

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

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

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

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

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

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