התעבורה של Windows Sandbox אינה עוברת כברירת מחדל ב-VPN של המארח
ה-sandbox מגיע לרשת דרך מתאם וירטואלי במתג ברירת המחדל. אם המנהרה שלכם מכסה אותו זו תכונה של הלקוח, לכן בדקו מבפנים.
אתם מפעילים את Windows Sandbox, פותחים בו דפדפן, והדף נטען מחיבור הרשת הרגיל שלכם למרות שהמארח היה ב-VPN דקה קודם. שום דבר לא שבור. ה-sandbox מקבל מתאם רשת וירטואלי המחובר למתג ברירת המחדל של המארח, והשאלה אם המנהרה של המארח מכסה את הנתיב הזה היא תכונה של לקוח ה-VPN, לא של Windows.
מה ה-sandbox באמת מקבל
ה-sandbox הוא מכונה וירטואלית קלה עם מתאם רשת משלו. המתאם הזה מתחבר דרך מתג ברירת המחדל של Hyper-V במארח, שמתרגם את התעבורה של ה-sandbox לממשק ה-Ethernet הווירטואלי של המארח לפני שהיא יוצאת מהמכונה. הפרט הזה מסביר כמעט כל תסמין שאנשים מדווחים עליו בעניין.
אז ה-sandbox אינו תהליך על שולחן העבודה שלכם. הוא נקודת קצה רשתית נפרדת שהמארח מעביר את החבילות שלה, וחומת האש של המארח ולקוח ה-VPN רואים כל אחד את ההעברה בדרכו. כלל שנכתב עבור תהליך דפדפן אינו מתאים אוטומטית למסגרת מתורגמת ממתג וירטואלי.
שתי דרישות שנראות כאחת
הגעה למשאב פרטי וכפיית כל בקשה של ה-sandbox לעבור במנהרה הן מטרות שונות. הראשונה זקוקה לנתיב ולפתרון שמות שעובדים עבור נקודת הקצה של ה-sandbox. השנייה זקוקה לאכיפה ששורדת התחברות מחדש וכשל. אף אחת אינה נובעת מהשנייה, ובדיקה שמספקת אחת אינה אומרת דבר על השנייה.
בדיקת כתובת ציבורית אינה עונה במלואה על אף אחת משתי השאלות. לראות את יציאת ה-VPN מתוך ה-sandbox מראה שחלק מהתעבורה השתמש במנהרה. היא אינה אומרת דבר על האם שמות פרטיים נפתרים, או על מה קורה לבקשה שמתחילה כשהמנהרה מושבתת.
רשמו איזו מהשתיים אתם צריכים לפני שתבדקו משהו, כי שתי הדרישות מובילות לתכנונים שונים ורק אחת מהן ניתנת לאימות עם דפדפן.
בדקו מתוך ה-sandbox
התצפית המשמעותית היחידה מגיעה מהפעלה של ה-sandbox עצמו, לא מהמארח. פתחו שם PowerShell והביטו במתאם, בפתרון השמות ובנתיב לכתובת תיעוד:
ipconfig /all Resolve-DnsName files.corp.example Test-NetConnection 198.51.100.7 -Port 443 Get-NetRoute -DestinationPrefix 0.0.0.0/0
רשימת המתאמים מראה את הכתובת ואת שער ברירת המחדל שקיבל ה-sandbox. שער שונה מזה של המארח הוא נורמלי במתג ברירת המחדל, לכן השוו את היציאה ולא את השער. בדיקת פתרון השמות מראה אם שם פרטי נענה בכלל, וכאן בדרך כלל תצורות split-horizon נבדלות מהמארח. שורת הנתיב מראה איזה שער ה-sandbox חושב שהוא הבעלים של ברירת המחדל.
חזרו על אותן שלוש בדיקות כשהמנהרה מחוברת וכשהיא מנותקת. תוצאה שאינה משתנה בין שני המצבים האלה היא הוכחה שהמנהרה כלל אינה בנתיב של ה-sandbox, יהיה אשר יהיה הכתובת שהראתה הבדיקה הציבורית.
כבו את הרשת כשה-sandbox אינו צריך אותה
לבדיקה לא מקוונת, קובץ תצורה מותאם יכול להסיר את הרשת לגמרי. ההגדרה היא רכיב אחד במסמך התצורה:
<Configuration> <Networking>Disable</Networking> </Configuration>
עיון תצורת ה-sandbox מתעד רכיב זה ומזהיר שרשת מופעלת עלולה לחשוף רשתות פנימיות לאפליקציות שאינכם סומכים עליהן. האזהרה הזו היא כל הסיבה להגדיר זאת במפורש במקום לקבל את ברירת המחדל.
המתג עם זאת אינו בוחר ממשק VPN. זו החלטה בינארית אם יש רשת, לא דרך לקשור את ה-sandbox למנהרה מסוימת. דרישה שמציינת יציאה אינה יכולה להתמלא במתג שרק מחליט אם יש כזו.
תכננו את הגבול לפני שאתם מעניקים משהו
אם הדרישה היא בידוד קפדני, בחרו תכנון רשת של מכונה וירטואלית שיכול לאכוף אותו, והשתמשו במדיניות הנתמכת של מוצר ה-VPN לתעבורה מועברת או לתעבורת מכונות וירטואליות. ניחוש ההתנהגות של לקוח המארח אינו תכנון, ובדיקה מוצלחת אחת אינה יישום.
אל תיתנו ל-sandbox לא מהימן פרופיל VPN ארגוני או אישורים פרטיים כדי שבדיקה תעבור. זה מחליף את הגבול שניסיתם לקבוע בתוצאה ירוקה, והאישור שורד יותר מהבדיקה.
תעדו את מצב הרשת, את היציאה שנצפתה ואת התנהגות ההתחברות מחדש בהערות הפריסה. כשעדכון של הלקוח משנה את אופן הטיפול בתעבורה מועברת, ההערות האלה הן שאומרות שהדרישה מעולם לא מולאה באמת.