הדואר עובד בלי VPN: האם הוא עובר בחשאי במנהרה?
חשבון Exchange אינו בוחר שער, פרוטוקול או נתיב. זהו את הפריסה, הכניסה הציבורית, ה-VPN המנוהל או המנהרה הפעילה לפני שאתם מניחים.
הדואר ממשיך להגיע לטלפון שמעולם לא הציג סמל VPN, והמסקנה הטבעית היא שמשהו בלתי נראה מעביר אותו במנהרה. בדרך כלל אין שום דבר בלתי נראה מעורב. הוספת חשבון Exchange אינה בוחרת שער, פרוטוקול, תעודה או נתיב, מפני שחשבון הוא זהות של שירות ומנהרה היא סידור רשת שמישהו אחר הגדיר. הצעד המועיל הוא לזהות איזה סידור באמת יש לכם במקום לחפש מנהרה שמעולם לא הייתה שם.
שלושה סידורים, מסך אחד זהה
כל השלושה מסתיימים בכך שהדואר מופיע במכשיר, ומסך ההגדרות נראה זהה בכל מקרה. מה ששונה הוא מי הגדיר את הנתיב ואיזו ראיה מוכיחה שהוא קיים.
| Arrangement | Who set it up | What proves it |
|---|---|---|
| Approved public mail entry | The service owner, at the publishing layer | A published endpoint reached over TLS with its own authentication |
| Managed app or account VPN | Device management, as explicit policy | A profile binding that traffic to a VPN association |
| Already active tunnel | An always-on service or an earlier manual connect | Tunnel state plus routes and scope that include the mail destination |
נגישות ציבורית ראויה למשפט משלה, מפני שהיא נקראת לא נכון כל הזמן. שירות דואר שפורסם אינו שירות ללא אימות, והעובדה שהדואר נגיש אינה אומרת דבר על נגישות שאר רשת החברה. אלו החלטות נפרדות שמקבלים אנשים נפרדים.
מה ניהול מכשירים יכול באמת לקשור
פלטפורמות Apple תומכות בכללי VPN לפי אפליקציה ולפי תחום דואר, ודואר מנוהל ב-iOS או ב-iPadOS יכול לשאת שיוך VPN ייחודי לחשבון. השיוך הזה הוא הגדרת אספקה עם ערך שמישהו בחר, וזו בדיוק הסיבה שאי אפשר להסיק אותו מהקלדת כתובת דואר וסיסמה בטלפון.
לניהול Android וללקוחות צד שלישי יש בקרות אפליקציה ופרופיל משלהם, ואף אחד מהם אינו ניתן להחלפה עם מטעני החשבון של Apple. מדיניות שקיימת בפלטפורמה אחת חייבת להיות משוכפלת במכוון באחרת. היא לא נוסעת עם חשבון הדואר, והיא לא מגיעה מפני שאותו אדם התחבר לשניהם. הציפייה שההעברה הזו תקרה מעצמה עומדת מאחורי חלק גדול מהדיווחים החוצי־פלטפורמות «אצלי זה עובד בטלפון».
זהות ותעבורה נשארות נפרדות
שירות דואר ו-VPN יכולים לחלוק כדין ספרייה או ספק זהות, ואנשים קוראים את הכניסה המשותפת הזו כהוכחה לסשן משותף. זה לא כך. שם משתמש חוזר אינו מראה שאפליקציית הדואר ירשה סשן VPN, ואינו סיבה להמציא סיסמאות לא קשורות לכל שירות.
שני השירותים דורשים אימות משלהם, בתנאים שלהם. אין להתייחס לכניסה מוצלחת לדואר כאל משהו שמדביקים בלקוח VPN, ומנהרה שעלתה אינה אומרת דבר על איזה חשבון שרת הדואר יקבל. ההפניה לפרופיל הדואר של Intune היא המחשה שימושית כאן, מפני שהיא מתייחסת לשיוך ה-VPN כהגדרה נפרדת ולא כמאפיין שנגזר משם החשבון.
סנכרון טרי עדיף על תיבת דואר שמורה במטמון
תיבת דואר שמורה במטמון יכולה להיראות בריאה לחלוטין בלי שום נתיב נוכחי, ולכן פתיחת האפליקציה וראיית ההודעות של השבוע שעבר אינה מוכיחה דבר. השתמשו בבדיקת סנכרון טרי מאושרת וקראו את ראיות המצב או היומן שמגיעות איתה.
לאחר מכן בדקו את ארבעת הדברים שבאמת קובעים את התוצאה: נקודת הקצה של השירות שהוגדרה, מה המפענח מחזיר, איזה פרופיל מנוהל חל, ומצב ה-VPN הנוכחי. עשו זאת בהקשר הנכון, מפני שאפליקציית דואר אישית בשם דומה אינה כפופה למדיניות הרשת של אפליקציית העבודה ותתנהג אחרת מסיבות לגיטימיות לחלוטין. ערבוב שני ההקשרים האלה הוא הדרך שבה תצורה עובדת מדווחת כשבורה. זה גם מסביר את רוב המקרים שבהם אפליקציה אחת מצייתת למדיניות והשכנה שכמעט זהה בשמה מתעלמת ממנה.
רשמו מה אימתתם
אם הגישה אמורה לדרוש מנהרה, הבעלים צריך לאשר גם את הנתיב הפרטי המותר וגם את ההתנהגות בלעדיה. אם השירות פורסם במכוון, השאירו את אימות ה-TLS, האימות ובקרות הגישה שלו במקומם במקום להתייחס להיעדר מנהרה כראיה שהדואר אינו מוצפן.
רשומת התמיכה צריכה למנות את מוצר הדואר, נקודת הקצה, היקף החשבון ומדיניות החיבור. סיסמאות זהות אינן ראיה לאף אחד מארבעת אלה, וזו הסיבה הנפוצה ביותר לכך שקריאה מכילה ארבע פסקאות ולא עובדות.