प्रत्येक एपका लागि VPN कि split tunnel? Mac को रुट के निर्णय गर्न सक्छ

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

चयनकर्ता गन्तव्य हो, कहिल्यै प्रक्रिया होइन

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

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

सामान्य split tunnel ले वास्तवमा के दिन्छ

split tunnel ले निजी प्रिफिक्सका लागि रुट स्थापना गर्छ र बाँकी सबै भौतिक बाटोमा छोड्छ। सामान्यतया अनुरोधको अर्थ यही हुन्छ: टनेलबाट अफिस सर्भरसम्म पुग्ने, सार्वजनिक ब्राउजिङ सिधा राख्ने। यो सरल छ, हरेक सामान्य क्लाइन्टले यसलाई समर्थन गर्छ, र यो अरू कुनै रुट जस्तै त्यही संयन्त्रबाट लागू हुन्छ। विशेष गन्तव्य route -n get बाट जाँच्नुहोस्, पूर्वनिर्धारित रुट पढ्नुको सट्टा, किनकि split tunnel ले प्रायः पूर्वनिर्धारित रुटलाई अछुतो राख्छ।

पूर्वनिर्धारित रुट हातले सम्पादन गर्नु कुनै कुरामा रूपान्तरण होइन। यसले क्लाइन्टको आफ्नै रुट पुनर्स्थापनासँग लड्छ र सुरक्षा नीति स्थापना गर्ने क्लाइन्टहरूमा मेसिनलाई यस्तो अवस्थामा छोड्न सक्छ जुन न तपाईंले अपेक्षा गर्नुहुन्छ न क्लाइन्टले। यसको सट्टा split tunnel क्लाइन्टका समर्थित सेटिङहरूमा कन्फिगर गर्नुहोस्।

macOS मा प्रति-एप VPN के आवश्यक छ

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

क्लाइन्ट हातले स्थापना गर्नाले त्यो म्यापिङ बन्दैन, र सामान्य सेटिङ प्यानलले एपहरूलाई छुट्टाछुट्टै छान्न मिल्ने बनाउँदैन। कुनै विक्रेताले आफ्नै एप नियमहरू दिन सक्छ, र ती सामान्य नियमको सट्टा उसको कागजातहरू पछ्याउँछन्।

MDM बिना एप-स्तरीय अलगावका तीन बाटो

जहाँ व्यवस्थापन उपलब्ध छैन, त्यहाँ प्रोक्सी व्यावहारिक उत्तर हो। एपको आफ्नै प्रोक्सी कन्फिगरेसन सेट गर्नुहोस्, वा यस्तो PAC फाइल प्रयोग गर्नुहोस् जसले त्यही एपका लागि मात्र गन्तव्य र प्रोटोकल अनुसार छनोट गर्छ।

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

अनुरोध यसरी लेख्नुहोस् कि जवाफ स्पष्ट होस्

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

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