Windows Sandbox را اجرا می‌کنید، داخل آن مرورگری باز می‌کنید و صفحه از اتصال عادی شما بارگذاری می‌شود، هرچند میزبان یک دقیقه پیش روی VPN بود. هیچ چیزی خراب نیست. سندباکس یک آداپتور شبکه مجازی می‌گیرد که به سوئیچ پیش‌فرض میزبان متصل است، و اینکه تونل میزبان آن مسیر را پوشش می‌دهد یا نه ویژگی کلاینت VPN است، نه Windows.

سندباکس در واقع چه چیزی می‌گیرد

سندباکس یک ماشین مجازی سبک با آداپتور شبکه مخصوص خود است. این آداپتور از طریق سوئیچ پیش‌فرض Hyper-V میزبان متصل می‌شود که ترافیک سندباکس را پیش از خروج از ماشین به رابط اترنت مجازی میزبان ترجمه می‌کند. همین جزئیات تقریباً هر نشانه‌ای را که مردم در این باره گزارش می‌کنند توضیح می‌دهد.

پس سندباکس فرآیندی روی میزکار شما نیست. یک نقطه پایانی شبکه جداگانه است که بسته‌هایش را میزبان ارسال می‌کند، و فایروال میزبان و کلاینت VPN هرکدام این ارسال را به روش خود می‌بینند. قاعده‌ای که برای یک فرآیند مرورگر نوشته شده به‌طور خودکار با قاب ترجمه‌شده از یک سوئیچ مجازی مطابقت نمی‌کند.

دو نیاز که شبیه یک نیاز به نظر می‌رسند

رسیدن به یک منبع خصوصی و مجبور کردن هر درخواست سندباکس به عبور از تونل دو هدف متفاوت است. اولی به مسیر و حل نام نیاز دارد که برای نقطه پایانی سندباکس کار کند. دومی به اجرای اجباری نیاز دارد که از اتصال دوباره و از خرابی جان سالم به در ببرد. هیچ‌یک از دیگری نتیجه نمی‌شود، و بررسی‌ای که یکی را برآورده کند درباره دومی چیزی نمی‌گوید.

بررسی نشانی عمومی به هیچ‌یک از دو پرسش کامل پاسخ نمی‌دهد. دیدن خروجی VPN از داخل سندباکس نشان می‌دهد بخشی از ترافیک از تونل استفاده کرده است. اما چیزی درباره حل‌شدن نام‌های خصوصی یا درباره آنچه بر سر درخواستی می‌آید که وقتی تونل قطع است آغاز می‌شود نمی‌گوید.

پیش از آزمایش هر چیزی بنویسید کدام‌یک را لازم دارید، چون این دو نیاز به طراحی‌های متفاوتی می‌رسند و تنها یکی از آن‌ها را می‌توان با مرورگر بررسی کرد.

از داخل سندباکس بررسی کنید

تنها مشاهده معنادار از نشست خود سندباکس می‌آید، نه از میزبان. آنجا PowerShell را باز کنید و به آداپتور، حل نام و مسیر تا یک نشانی مستندات نگاه کنید:

ipconfig /all
Resolve-DnsName files.corp.example
Test-NetConnection 198.51.100.7 -Port 443
Get-NetRoute -DestinationPrefix 0.0.0.0/0

فهرست آداپتورها نشانی و دروازه‌ای را که سندباکس گرفته است نشان می‌دهد. دروازه‌ای متفاوت از دروازه میزبان برای سوئیچ پیش‌فرض عادی است، پس خروجی را مقایسه کنید نه دروازه را. آزمون حل نام می‌گوید آیا به یک نام خصوصی اصلاً پاسخ داده می‌شود، و همین‌جاست که تنظیمات split-horizon معمولاً از میزبان جدا می‌شوند. خط مسیر می‌گوید سندباکس کدام دروازه را مالک مسیر پیش‌فرض می‌داند.

همان سه بررسی را با تونل متصل و قطع‌شده تکرار کنید. نتیجه‌ای که میان این دو حالت تغییر نمی‌کند گواه این است که تونل اصلاً در مسیر سندباکس نیست، هر نشانی که بررسی عمومی نشان داده باشد.

وقتی سندباکس به شبکه نیاز ندارد آن را خاموش کنید

برای بررسی برون‌خط، یک فایل پیکربندی سفارشی می‌تواند شبکه را کاملاً حذف کند. این تنظیم یک عنصر در سند پیکربندی است:

<Configuration>
  <Networking>Disable</Networking>
</Configuration>

مرجع پیکربندی سندباکس این عنصر را مستند می‌کند و هشدار می‌دهد که فعال بودن شبکه می‌تواند شبکه‌های داخلی را در معرض برنامه‌هایی قرار دهد که به آن‌ها اعتماد ندارید. همین هشدار تمام دلیل تنظیم صریح آن به‌جای پذیرفتن پیش‌فرض است.

اما سوئیچ یک رابط VPN انتخاب نمی‌کند. این یک تصمیم دودویی درباره وجود شبکه است، نه راهی برای بستن سندباکس به تونلی خاص. نیازی که یک خروجی را نام می‌برد با سوئیچی که فقط تصمیم می‌گیرد خروجی وجود دارد یا نه برآورده نمی‌شود.

پیش از اعطای هر چیزی مرز را طراحی کنید

اگر نیاز جداسازی سختگیرانه است، طراحی شبکه ماشین مجازی‌ای را انتخاب کنید که بتواند آن را اجرا کند، و سیاست پشتیبانی‌شده محصول VPN را برای ترافیک ارسال‌شده یا ترافیک ماشین‌های مجازی به کار ببرید. حدس زدن رفتار کلاینت میزبان طراحی نیست، و یک بررسی موفق پیاده‌سازی نیست.

به یک سندباکس غیرقابل‌اعتماد پروفایل VPN شرکتی یا اعتبارنامه خصوصی ندهید تا یک آزمون قبول شود. این کار مرزی را که می‌کوشیدید برقرار کنید با یک نتیجه سبز معاوضه می‌کند، و اعتبارنامه از آزمون بیشتر عمر می‌کند.

حالت شبکه، خروجی مشاهده‌شده و رفتار اتصال دوباره را در یادداشت‌های استقرار ثبت کنید. وقتی به‌روزرسانی کلاینت نحوه رسیدگی به ترافیک ارسال‌شده را تغییر دهد، همان یادداشت‌ها هستند که می‌گویند نیاز هرگز واقعاً برآورده نشده بود.

مقالات مرتبط