एउटै Mac का दुई लगइन खाताले VPN ट्राफिक बाँड्दैनन्

एउटै Mac का दुई लगइन खाता नेटवर्क नआउँदासम्म दुई छुट्टै संसारजस्ता देखिन्छन्। एउटा सत्रमा सुरु गरिएको सुरुङले अर्को सत्रले भोग्ने कुरा बदल्न सक्छ, कुन क्लाइन्ट यसको मालिक हो र यससँग कुन नीति आउँछ भन्नेमा निर्भर गर्दै। यसलाई लागू गर्ने संयन्त्र छान्नुअघि तपाईंलाई चाहिने पृथकीकरण वर्णन गर्नुहोस्। क्रम महत्त्वपूर्ण छ, किनकि पहिले छानिएको संयन्त्रले आवश्यकतालाई आफ्नै वरिपरि पुनः परिभाषित गर्ने प्रवृत्ति राख्छ।

तीन प्रश्नले धेरैजसो काम गर्छन्: कसका एपलाई कुन निजी स्रोत चाहिन्छ, दुवै सत्र एकैचोटि सक्रिय हुनुपर्छ कि पर्दैन, र तिनीहरूको सुरुङ उपलब्ध नहुँदा ती एपलाई के गर्न अनुमति छ।

खाताको सूचीबाट होइन, ट्राफिकबाट सुरु गर्नुहोस्

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

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

प्रोफाइल च्यानल र ट्राफिकको दायरा फरक कुरा हुन्

Apple ले प्रयोगकर्ता वा यन्त्रअनुसार पुर्‍याइने व्यवस्थित VPN व्यवस्थालाई समर्थन गर्छ, र तैनाथी मार्गदर्शिकाले ती मोडेललाई आपूर्तिकर्ता-निर्भर एकीकरणसँगै वर्णन गर्छ। डेलिभरी च्यानलले कसले कन्फिगरेसन पाउँछ र यसको मालिक को हो भन्ने बताउँछ। कुन ट्राफिक समातिन्छ भन्ने यसले आफै तय गर्दैन, किनकि क्लाइन्टको कार्यान्वयन र कन्फिगर गरिएको नीतिले अझै त्यो तय गर्छन्।

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

पाहुना प्रणाली वास्तविक सीमाहरू भएको वास्तविक सीमा हो

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

भर्चुअल नेटवर्क मोडलाई अझै समीक्षा चाहिन्छ। पाहुना ब्रिज हो, NAT पछाडि छ वा अलग छ भन्नेले उसले के-के पुग्न सक्छ र के-के उससम्म पुग्न सक्छ भन्ने निर्धारण गर्छ, र पाहुना संयोगवश जोडिएको हुँदैमा होस्टका एप पाहुनाका एप बन्दैनन्। ब्लकिङ नीति पनि जाँच्नुहोस्, नत्र खस्रेको पाहुना सुरुङ कसैले नचाहेको तरिकाले होस्टको बाटोमा फर्किनेछ।

प्रोक्सी प्रयोगकर्ता खाताभन्दा साँघुरो हुन्छ

होस्टको एउटा एप स्वीकृत पाहुना वा कन्टेनरमा चल्ने वास्तविक प्रोक्सी सेवासम्म पुग्न सक्छ, र त्यसले एपले समर्थित प्रोटोकलमार्फत साँच्चै पठाउने ट्राफिक समेट्छ। त्यसले त्यो Mac खाताको स्वामित्वको हरेक प्रक्रिया समेट्दैन, र एपले प्रोक्सी प्रोटोकलबाहिर पठाउने ट्राफिक पनि समेट्दैन।

साझा मेसिनमा अर्को सावधानी: होस्टको लुपब्याकमा बाँधिएको TCP श्रोता प्रयोगकर्तानामको जाँच होइन। प्रोक्सीलाई स्थानीय मेसिनसम्म सीमित गर्दा त्यो नेटवर्कबाट टाढा रहन्छ, तर पहिले नै लगइन भइसकेको अर्को स्थानीय प्रयोगकर्तामाथि एकलाई अधिकार दिँदैन। यदि त्यो भिन्नता महत्त्वपूर्ण छ भने सेवाको प्रमाणीकरण स्पष्ट राख्नुहोस्।

दुई परीक्षणले सीमा प्रमाणित गर्नुहोस्

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

यदि कन्टेनर वा पाहुनाले सुरुङ चलाउँछ भने, तेस्रो जाँच थप्नुहोस्: त्यसको बाहिरको मूल Mac एपले अझै डिजाइनअनुसार व्यवहार गर्छ भनी पुष्टि गर्नुहोस्। जसको दायरा तपाईं देखाउन सक्नुहुन्छ त्यो सबैभन्दा सरल व्यवस्था छान्नुहोस्, र यी परीक्षण गर्नुअघि भर्चुअल मेसिनलाई सार्वभौम रूपमा आवश्यक वा खाता बदल्नुलाई सार्वभौम रूपमा पर्याप्त भन्नुहोस्।