कोणते 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 पान दुसऱ्या अॅप्लिकेशनच्या सॉकेटची चाचणी नाही, म्हणून ते याची जागा घेऊ शकत नाही। जिथे कोणतीही समर्थित तैनाती अॅपच्या प्रत्यक्ष वर्तनाला झाकत नाही, तिथे स्पष्ट गेटवे आणि पर्यायी निर्गमन नसलेले अधिकृत विलगित वातावरण हे स्वतःच्या व्यवस्थापन-खर्चासह संयमन-निर्णय आहे, चेकबॉक्सचा पर्याय नाही।
चार नोंदी लिहून पूर्ण करा: अॅप कोणत्या घटकांनी बनलेले आहे, मार्गदर्शनाचा मालक कोण आहे, नकाराचा मालक कोण आहे, आणि नियम अजूनही लागू राहिला पाहिजे अशा स्थिती। सार्वजनिक साठा-स्थान निवडीचा एक निकष असू शकतो, पण तो चारपैकी एक नाही, आणि त्या नोंदीच ठरवतात की दिलेले साधन नेटवर्किंग गरज पूर्ण करते की नाही।