הדואר מגיע לשרת בלי VPN: היכן לאכוף את הכלל

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

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

התסמין נראה כמו ה-Mac, אבל השרת עשוי להיות הדלף

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

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

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

קבלה בשרת: סרבו למקור, לא לאפליקציה

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

זהו הגבול החזק ביותר כשהדרישה היא «השירות לא יעבוד לקוחות ישירים». הוא מחזיק גם אם המשתמש מתקין לקוח דואר אחר, כי הסירוב מתרחש לפני האימות. הוא שורד גם Mac שמתעלם ממדיניות ה-VPN שלו.

הגבול שלו חשוב באותה מידה. חיבור שנדחה מוכיח שהשירות סירב לסשן; הוא אינו מוכיח שה-Mac לא ניסה כלל. פתרון DNS, TCP SYN למאזן עומסים קודם וניסיון חוזר אחרי כשל יכולים כולם לקרות לפני שמגיעים לכלל השרת. אם הדרישה עוסקת בחשיפת ניסיונות ולא בגישה, קבלה בשרת היא רק חצי מהבקרה.

אכיפה בלקוח: חסמו את הניסיון, לא רק את המנהרה

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

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

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

לכללים ברמת האפליקציה וברמת היעד יש היקף השפעה שונה

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

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

בחרו לפי ניסוח הדרישה. «חשבון העבודה הזה לא יתחבר ישירות» מצביע על היקף היעד. «ה-Mac הזה לא יריץ דואר מחוץ ל-VPN» מצדיק את כלל האפליקציה הרחב יותר, בתנאי שהבעלים מקבל את תופעת הלוואי לחשבון האישי.

בדקו סירוב והיעדר בנפרד

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

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

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