Mac Mail, שני חשבונות וכלל VPN אחד שלא יכול להפריד ביניהם
כלל ברמת האפליקציה נוקב בשם Mail, לא באחד מהחשבונות שלו. הפרידו בין האפליקציה, השרת וההתחברות לפני שתבקשו מנהר שעוקב אחרי דואר העבודה.
Mail נפתח, תיבת העבודה מסתנכרנת, והאישית מתחילה לפגר בזמן. או ששתיהן מסתנכרנות, אבל שרת העבודה עונה רק כל עוד מנהר פעיל, ו-Mail לא יודע איזה חשבון הוא איזה. לתסמין תמיד אותה צורה: אפליקציה אחת, שני חשבונות וכלל שמזהה את האפליקציה. התיקון מתחיל בהודאה שהאפליקציה היא מכל, לא גבול.
שלושה בוררים פועלים כאן, והם אינם ניתנים להחלפה. האחד הוא התהליך שיוצר את החיבור, השני הוא המארח שאליו הוא מגיע, והשלישי הוא הזהות שמשמשת להתחברות דרך אותו מארח. מי מהם שהמדיניות שלכם יכולה לנקוב בשמו, הוא הגבול שאתם באמת יכולים לבנות.
למה האפליקציה היא היחידה הלא נכונה
Mail הוא תהליך אחד שמשרת כל חשבון מוגדר. כלל שנכתב נגד האפליקציה לוכד את כל החיבורים שלה, ולכן החשבון האישי יורש את מנהר העבודה ואת נתיב ברירת המחדל שלו. זה עשוי להיות מקובל, אבל זו החלטה, לא תופעת לוואי שאפשר להשאיר בלי בחינה.
בדקו על מה המשתמש באמת מתלונן לפני שמתקנים משהו. תיבה שמסתנכרנת אבל לא יכולה לשלוח מצביעה בדרך כלל על שרת השליחה ולא על תיבת הדואר הנכנס, ושניהם יכולים לשבת בכתובות שונות באותו טווח פרטי. שאלו אם הכשל הוא בקליטה, בשליחה או בשניהם. התשובה קובעת איזה קצה הכלל שלכם חייב לכסות, והיא חוסכת סבב אחד עם מי שמנהל את השרת.
כששני החשבונות משתמשים בשרתים שונים
אם דואר העבודה מדבר עם מארח בתוך הטווח הארגוני והדואר האישי עם ספק ציבורי, סידור מבוסס יעד יכול לבטא את הדרישה. הוא צריך את הכתובות האמיתיות של שרתי הדואר, את ה-DNS שמפענח אותן, וכל קצה שליחה או אימות שנוסע עם אותו שירות. אספו את שלושתם לפני כתיבת מדיניות, כי כלל שמכסה רק את תיבת הדואר הנכנס ייכשל בשליחה הראשונה.
השתמשו בכתובות, לא בחלק שאחרי סימן ה-@. תחום בכתובת דואר אינו הצהרת ניתוב, והתייחסות אליו ככזה מייצרת כלל שמופעל למארח הלא נכון או שלעולם אינו מופעל. אשרו את הקצוות בפועל מהגדרות החשבון או מהמנהל.
כששני החשבונות חולקים שרת אחד
שני חשבונות באותה כתובת מארח מבטלים לחלוטין בחירה מבוססת יעד. נתיב לכתובת הזו משרת כל מי שמתחבר, והוא לא יכול לבדוק איזו תיבה מתחברת לאחר מכן. הזזת הנתיב מזיזה את הדרך לשני החשבונות, וזו בדיוק התוצאה שהמשתמש ניסה להימנע ממנה.
בנקודה הזו האפשרויות הכנות הן מדיניות מודעת חשבון אם הפלטפורמה והלקוח תומכים באחת, לקוח דואר מאושר נפרד לחשבון העבודה כדי שגבול האפליקציה יהפוך אמיתי, או השלמה עם כך ששני החשבונות נוסעים יחד. בחרו אחת במכוון ואמרו איזו בחרתם.
הפעלת מנהר אינה אותו דבר כמו כיסויו
מטען ה-App Layer VPN של אפל מתעד הגדרה בשם MailDomains: תחומים ברשימה גורמים ל-Mail להפעיל חיבור VPN בפריסות מנוהלות נתמכות. זו יכולת שימושית, והיא צרה יותר ממה שהיא נשמעת. היא מפעילה את המנהר כשדואר מדבר עם התחומים האלה; היא לא מתארת כל נתיב, כל שיוך אפליקציה או מה קורה כשהמנהר למטה.
זה גם תכונה מנוהלת, לא תיבת סימון לכל חשבון בממשק Mail. אם הפריסה אינה מנוהלת, ההגדרה אינה זמינה לכם, ושום כמות של עריכת פרופילים לא תיצור אותה.
בדקו בסנכרון טרי, לא בתיבה שמורה במטמון
מבחן הקבלה הוא סנכרון טרי לכל חשבון תחת המדיניות המיועדת, ובנוסף מצב אי-הזמינות לחשבון המוגן. תיבה שמורה במטמון לא מוכיחה דבר על הבקשה הבאה, וסמל VPN מחובר אומר רק שקיים איזה מנהר.
תנו למנהל את הקצוות של חשבון העבודה ואת ההתנהגות שאתם רוצים לדואר האישי, ואז שאלו איזו מדיניות נתמכת, מודעת חשבון, מבוססת תחום או אפליקציה, מיישמת אותה. צפייה בשני החשבונות מסתנכרנים בכל תנאי היא ההוכחה היחידה שהגבול שעיצבתם הוא הגבול שהמכונה אוכפת.