Windows Sandbox को ट्राफिक डिफल्ट रूपमा होस्टको VPN लाई पछ्याउँदैन

तपाईं Windows Sandbox सुरु गर्नुहुन्छ, भित्र ब्राउजर खोल्नुहुन्छ, र एक मिनेट अघि होस्ट VPN मा हुँदा पनि पृष्ठ तपाईंको सामान्य जडानबाटै लोड हुन्छ। केही पनि बिग्रिएको छैन। स्यान्डबक्सले होस्टको डिफल्ट स्विचमा जोडिएको भर्चुअल नेटवर्क एडाप्टर पाउँछ, र होस्टको टनेलले त्यो बाटो ढाक्छ कि भन्ने कुरा VPN क्लाइन्टको गुण हो, Windows को होइन।

स्यान्डबक्सले वास्तवमा के पाउँछ

स्यान्डबक्स आफ्नै नेटवर्क एडाप्टर भएको हल्का भर्चुअल मेसिन हो। त्यो एडाप्टर होस्टको Hyper-V डिफल्ट स्विचमार्फत जोडिन्छ, जसले मेसिन छोड्नुअघि स्यान्डबक्सको ट्राफिकलाई होस्टको भर्चुअल Ethernet इन्टरफेसमा अनुवाद गर्छ। यही विवरणले यसबारे मानिसहरूले रिपोर्ट गर्ने लगभग सबै लक्षण व्याख्या गर्छ।

त्यसैले स्यान्डबक्स तपाईंको डेस्कटपमा चल्ने प्रक्रिया होइन। यो होस्टले प्याकेट अगाडि पठाउने छुट्टै नेटवर्क अन्त्यबिन्दु हो, र होस्टको फायरवाल तथा 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 प्रोफाइल वा निजी प्रमाणहरू नदिनुहोस्। यसले तपाईं स्थापित गर्न खोजेको सीमालाई हरियो नतिजासँग साट्छ, र प्रमाण परीक्षणभन्दा लामो समय टिक्छ।

परिनियोजन नोटहरूमा नेटवर्क मोड, देखिएको निकास र पुनः जडानको व्यवहार लेख्नुहोस्। क्लाइन्ट अद्यावधिकले अगाडि पठाइएको ट्राफिकको व्यवस्थापन कसरी हुन्छ भन्ने बदल्दा, ती नोटहरूले नै आवश्यकता साँच्चै कहिल्यै पूरा नभएको बताउँछन्।