कौन-सा 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 पृष्ठ किसी दूसरे ऐप्लिकेशन के सॉकेट की जाँच नहीं है, इसलिए यह इसकी जगह नहीं ले सकता। जहाँ कोई समर्थित तैनाती ऐप के वास्तविक व्यवहार को कवर नहीं करती, वहाँ स्पष्ट गेटवे और वैकल्पिक निर्गम के बिना एक प्राधिकृत पृथक परिवेश अपनी प्रबंधन-लागत वाला संयमन-निर्णय है, चेकबॉक्स का विकल्प नहीं।
चार प्रविष्टियाँ लिखकर समाप्त करें: ऐप किन घटकों से बना है, मार्गदर्शन का मालिक कौन है, इनकार का मालिक कौन है, और वे स्थितियाँ जिनमें नियम अब भी लागू रहना चाहिए। कोई सार्वजनिक रिपॉज़िटरी चयन का एक मानदंड हो सकती है, पर वह उन चार में से एक नहीं है, और वही प्रविष्टियाँ तय करती हैं कि दिया गया औज़ार नेटवर्किंग आवश्यकता पूरी करता है या नहीं।