कुन macOS औजारले एउटा एपलाई VPN बाट मात्र जान बाध्य पार्न सक्छ?
VPN-मात्र सीमाका लागि बाटो र अस्वीकार दुवै चाहिन्छ। प्रति-एप प्रोफाइल, प्रोक्सी, फिल्टर र PF तुलना गर्नुहोस्, त्यसपछि तपाईंलाई महत्त्वपूर्ण त्यही एउटा एप परीक्षण गर्नुहोस्।
आवश्यकता-कागजातको एउटा पङ्क्ति — “यो एपले VPN प्रयोग गर्न सक्छ, र अरू केही होइन” — कुनै एक स्विचले दिँदैन भन्ने दुई संयन्त्र शान्तसँग माग्छ। ट्राफिकलाई इच्छित सुरुङबाट जाने बाटो चाहिन्छ, र सिधै बाहिर जाने ट्राफिक अस्वीकार हुनुपर्छ। यीमध्ये एउटा राम्रो गरेर अर्को केही नगर्ने औजार सामान्य छन्, त्यसैले केही कुराले ब्लक गर्न सक्छ कि भनेर मात्र सोध्ने तुलनाले प्रश्नको आधा भागको आत्मविश्वासका साथ जवाफ दिन्छ। पहिले सीमा लेख्नुहोस्, त्यसपछि त्यसका दुवै आधा भाग ढाक्ने घटक छान्नुहोस्।
एउटै वाक्यमा लुकेका दुई आवश्यकता
मार्गदर्शन भनेको जडानलाई सुरुङ वा प्रोक्सीमा राख्ने भाग हो। अस्वीकार भनेको त्यही जडान अरू कुनै बाटोबाट बाहिर जानबाट रोक्ने भाग हो। फरक-फरक घटकले ती लागू गर्छन्, ती फरक तरिकाले असफल हुन्छन्, र कुनै उत्पादन एकमा उत्कृष्ट हुन सक्छ र अर्कोबारे केही नभन्न सक्छ:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
तालिकालाई श्रेणीकरण होइन, जाँचसूचीका रूपमा पढ्नुहोस्। कुनै पङ्क्तिले दुवै बीचका स्तम्भ भर्दैन, र ती ढाक्ने पङ्क्तिहरू सहकार्य गर्ने दुई घटक हुन्: एउटा बाटोको मालिक, अर्को अस्वीकारको। पहिचानको स्तम्भ अर्कै कारणले महत्त्वपूर्ण छ, किनकि एपको नाम बताउन नसक्ने नियमले त्यो एपबारे नियम लागू गर्न सक्दैन। तपाईंले जे तैनाथ गर्नुभए पनि तीनैको जवाफ दिनुपर्छ, अन्यथा आवश्यकता-कागजातको सीमा मेसिनमा भएको सीमा होइन।
मार्गदर्शन मात्रले बाहिर निस्कने बाटो छोड्छ
एप्लिकेसन प्रोक्सी सेटिङ अस्वीकार बिनाको मार्गदर्शनको सबैभन्दा स्पष्ट उदाहरण हो। यसले प्रणाली प्रोक्सीको सम्मान गर्ने एपका अनुरोध मार्गदर्शन गर्न सक्छ, र अरू केही ढाक्दैन: सहायक प्रक्रिया, अपडेटर, पृष्ठभूमि सेवा वा फरक प्रोटोकल त्यो सेटिङ कहिल्यै नपढी आफ्नै बाटो जान सक्छन्। त्यसैले एउटा प्यानलमा SOCKS अन्त्य-बिन्दु छान्नुले एपका लागि सिधा निर्गमनमा रोक लगाउने नीति बनाउँदैन। आवश्यकता सम्पूर्ण एपबारे भए, नियमले वास्तवमा कुन घटक पहिचान गर्छ भनेर सोध्नुहोस्।
प्रति-एप VPN प्रोफाइलले प्रोक्सीभन्दा राम्रो मार्गदर्शन गर्छ, किनकि कुन एप सुरुङमा प्रवेश गर्ने भन्ने प्लेटफर्मले निर्णय गर्छ प्रत्येक एपले आफैँ निर्णय गर्नुको सट्टा। तैपनि यसले केही अस्वीकार गर्दैन: प्रोफाइल बाटो दिन्छ, र त्यससँग नमिल्ने ट्राफिक सामान्य मार्ग लिन्छ। त्यही खाडल भनेको दोस्रो घटकले आफ्नो स्थान कमाउने ठाउँ हो, र त्यसैले एउटा स्विचजस्तो देखिने उत्पादन सामान्यतया दुई हुन्छन्।
अस्वीकार मात्रले एप बिगार्छ
Apple को कागजात सामग्री-फिल्टरबारे ले नेटवर्क स्ट्याक हुँदै जाने ट्राफिकमा अनुमति-वा-ब्लक निर्णयको वर्णन गर्छ। त्यो निर्णय सुरुङ होइन र प्रोक्सी जडान पनि होइन, किनकि यसले केही अगाडि बढ्न सक्छ कि भन्ने निर्णय गर्छ, कहाँ जान्छ भन्ने होइन। फिल्टर मात्रले अस्वीकार पूर्ण रूपमा लागू गर्छ र एप्लिकेसनलाई अप्रयोग्य छोड्छ, सफा लगसहित र कुनै व्याख्या बिना। फिल्टरको निर्णयले जडान रोक्न सक्छ तर सुरुङ कहिल्यै दिँदैन, त्यसैले त्यसलाई मार्गदर्शनसँग जोड्नु नै डिजाइनको निर्णय हो, वैकल्पिक थप होइन।
स्थानीय रूपमा व्यवस्थापित PF नियमसमूह त्यो स्पेक्ट्रमको अर्को छेउमा बस्छ। यो प्रशासकको स्वामित्वको मेसिनमा वैध सहयोग-निर्णय हो, र यो आफैँमा वितरणयोग्य उत्पादनको आधार हुँदैन, किनकि जसको नियमसमूह छ उसको अन्य फायरवाल प्रयोगकर्तासँगको अन्तरक्रिया, अपग्रेड मार्ग र नियम गलत हुँदा त्यसको पुनःप्राप्ति पनि हुन्छ। उत्पादनमा PF थप्दा त्यो स्वामित्वको प्रश्न हट्दैन; यसले त्यसलाई परिभाषित गर्छ।
तैनाथीले नियम भोलि पनि रहन्छ कि रहँदैन भन्ने निर्णय गर्छ
Apple प्लेटफर्ममा Network Extension कसरी तैनाथ हुन्छ भन्ने तपाईंको अगाडिको प्रदायक-प्रकार, प्याकेजिङ र OS संस्करणमा निर्भर छ। macOS मा एप विस्तार प्रयोगकर्ता सन्दर्भमा चल्छ र त्यो प्रयोगकर्ता लगआउट हुँदा अन्त्य हुन्छ, जबकि सिस्टम विस्तारको सन्दर्भ सत्रमा निर्भर नहुने विश्वव्यापी हुन्छ। यदि सुरक्षा लगआउटपछि पनि टिक्नुपर्छ भने त्यो भिन्नता पादटिप्पणी होइन, सम्पूर्ण डिजाइन हो। व्यवहारको वाचा गर्नुअघि तैनाथीको मार्ग पुष्टि गर्नुहोस्, किनकि एउटै कोड कुन विस्तार-प्रकार पठाइन्छ भन्ने अनुसार फरक तरिकाले अवतरण हुन्छ।
स्रोतको उपलब्धता कार्यान्वयनभन्दा छुट्टै विषय हो। कुनै भण्डार पढ्दा केही कुरा कसरी कार्यान्वयन भएको छ भन्ने थाहा हुन्छ, तर स्थापित बाइनरीले यो मेसिनमा के गर्न पाउँछ भन्ने होइन। हस्ताक्षर, स्थापना र अधिकृतता अझै लागू हुन्छन्, र पुरानो कर्नेल विस्तार वा लाइब्रेरी-इन्जेक्सनको चाल वरिपरि बनेका निर्देशनहरूले अर्को प्लेटफर्म र अर्को जोखिम-स्थिति वर्णन गर्छन्, एक समय कति राम्रो चले पनि।
एपको नाम लिने स्वीकृति-अवस्था
एपले आफैँ गर्ने एउटा क्रिया छान्नुहोस्, पुग्नुपर्ने ठेगाना र त्यो ठेगाना IPv4 हो कि IPv6 लेख्नुहोस्, त्यसपछि स्वीकृत सुरुङ-रहित अवस्थामा त्यही क्रिया दोहोर्याउनुहोस्। दोस्रो चालमा घोषित अस्वीकार आउनुपर्छ, चुपचाप सिधा पुनःप्रयास होइन। यही त्यो आधा भाग हो जो मानिसहरूले अनिर्दिष्ट छोड्छन्, र अस्वीकार अस्तित्वमा छ भनी प्रमाणित गर्ने एकमात्र आधा भाग। पहिले सुरुङ उपलब्ध हुँदा चलाउनुहोस्, ताकि दुई नतिजाबीचको फरक अनुपस्थित सुरुङबाट मात्र आउन सकोस्।
त्यसपछि आवश्यकताले नाम लिएका संक्रमणहरूबाट जानुहोस्: एप पुनः सुरु, सहायक प्रक्रिया सक्रिय हुनु, सुरुङ पुनः जोडिनु, मेसिनले सञ्जाल बदल्नु, र लागू हुने ठाउँमा लगआउट वा रिबुट। ब्राउजरको सार्वजनिक-IP पृष्ठ अर्को एप्लिकेसनका सकेटको परीक्षण होइन, त्यसैले यसको ठाउँ लिन सक्दैन। जहाँ कुनै समर्थित तैनाथीले एपको वास्तविक व्यवहार ढाक्दैन, त्यहाँ स्पष्ट गेटवे र वैकल्पिक निर्गमन नभएको अधिकृत पृथक वातावरण आफ्नै व्यवस्थापन-लागत भएको संयमन-निर्णय हो, चेकबक्सको विकल्प होइन।
चार प्रविष्टि लेखेर टुङ्ग्याउनुहोस्: एप कुन घटकले बनेको छ, मार्गदर्शनको मालिक को हो, अस्वीकारको मालिक को हो, र नियम अझै लागू रहनुपर्ने अवस्था। सार्वजनिक भण्डार छनोटको एउटा मापदण्ड हुन सक्छ, तर त्यो चारमध्ये एक होइन, र ती प्रविष्टिले नै दिइएको औजारले सञ्जाल आवश्यकता पूरा गर्छ कि गर्दैन भन्ने निर्णय गर्छन्।