שני חשבונות התחברות ב-Mac אינם מחלקים תעבורת VPN

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

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

התחילו מהתעבורה, לא מרשימת החשבונות

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

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

ערוץ הפרופיל והיקף התעבורה הם דברים שונים

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

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

מערכת אורח היא גבול אמיתי עם מגבלות אמיתיות

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

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

פרוקסי צר יותר מחשבון משתמש

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

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

הוכיחו את הגבול בשני מבחנים

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

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