VPN चालू होने पर Android फ़ायरवॉल नियम कहाँ रहना चाहिए
केवल एक VpnService सक्रिय हो सकता है, इसलिए फ़ायरवॉल ऐप और VPN ऐप एक-दूसरे पर नहीं चढ़ते। एक कार्य अनुरोध को चलाइए और हर नियम वहाँ रखिए जहाँ उसका ट्रैफ़िक वास्तव में गुज़रता है।
आपके पास एक ही वाक्य की नीति है: यह ऐप कार्य सेवा तक पहुँच सकता है, और कुछ नहीं। अगला सवाल उत्पाद चुनने जैसा दिखता है, पर वह जगह का सवाल है, क्योंकि हर संभावित प्रवर्तन-बिंदु फ़ोन के ट्रैफ़िक का अलग हिस्सा देखता है। गेटवे केवल वह देखता है जो सुरंग में प्रवेश करता है। फ़ोन की ओर का फ़िल्टर केवल वह देखता है जिसे देखने की उसे अनुमति है। एक अनुरोध दोनों से गुज़ारना उत्तर को स्पष्ट कर देता है।
उत्पाद से नहीं, वाक्य से शुरू करें
कुछ भी चुनने से पहले आवश्यकता को फैलाइए। इसका अर्थ है पैकेज और वह प्रोफ़ाइल जिसमें वह चलता है, क्योंकि कार्य प्रोफ़ाइल का ऐप निजी प्रोफ़ाइल के उसी ऐप से अलग उपयोगकर्ता है। इसका अर्थ है गंतव्य: होस्ट, पोर्ट और प्रोटोकॉल, सेवा का नाम नहीं। इसका अर्थ है वह DNS पथ जो उस नाम को हल करता है, और इसका अर्थ है कि सुरंग उपलब्ध न होने पर क्या होना चाहिए।
लिखित रूप में उदाहरण की नीति चार पंक्तियाँ हैं: कार्य ऐप कार्य सेवा तक पहुँच सकता है; कार्य ऐप कहीं और नहीं पहुँच सकता; अन्य ऐप अपरिवर्तित रहते हैं; सुरंग के बिना कार्य ऐप को सीधे रास्ते पर गिरने के बजाय अस्वीकार किया जाता है। हर पंक्ति का एक स्वामी है, और सब एक ही स्वामी नहीं हैं।
चरण 1: फ़ोन स्वयं क्या लागू कर सकता है
रूट के बिना Android फ़ायरवॉल एक VpnService है जो ट्रैफ़िक को स्थानीय रूप से पकड़ता है, तब भी जब उसके पीछे कोई दूरस्थ सुरंग न हो। Android प्रति उपयोगकर्ता प्रोफ़ाइल एक सक्रिय VPN सेवा की ही अनुमति देता है, इसलिए दूसरा फ़ायरवॉल ऐप पहले के पीछे श्रृंखलाबद्ध नहीं होता। वह उसकी जगह लेता है, और जिस इंटरफ़ेस को पहला ऐप फ़िल्टर कर रहा था वह गायब हो जाता है।
इसीलिए VPN क्लाइंट के साथ फ़ायरवॉल लगाने पर लोगों की अपेक्षित जोड़ी कम ही बनती है। अगर फ़ायरवॉल शुरू होता है और VPN टूट जाता है, तो कुछ भी नहीं जुड़ा; दोनों ने जगह बदल ली। इंटरफ़ेस बदलना सहयोग नहीं है, और लक्षण वह सुरंग है जो दूसरा ऐप खुलते ही बार-बार गिरती है।
समर्थित व्यवस्थाएँ मौजूद हैं: आप जो VPN क्लाइंट पहले से चलाते हैं उसमें अंतर्निहित फ़िल्टरिंग, डिवाइस नीति नियंत्रक या कार्य प्रोफ़ाइल के ज़रिए प्रबंधित प्लेटफ़ॉर्म नियंत्रण, या निर्माता द्वारा प्रलेखित संरचना। बाकी सब एक प्रयोग है जिसे हर ऐप अपडेट के बाद फिर से जाँचना पड़ता है।
चरण 2: गेटवे क्या लागू कर सकता है
दूरस्थ छोर पर ट्रैफ़िक डिक्रिप्ट होने के बाद, गेटवे आगे भेजे गए पैकेट को स्वीकृत पतों, सेवाओं या प्रमाणित VPN पहचानों तक सीमित कर सकता है। यह उससे बाहर जाने वाली हर चीज़ के लिए वास्तविक प्रवर्तन है, और निजी सबनेट तक पहुँच सीमित करने की सही जगह यही है।
जो उसे नहीं मिलता वह हर सामान्य IP पैकेट से जुड़ी फ़ोन की ऐप पहचान है। एक ही सुरंग पता साझा करने वाले कई ऐप गेटवे के लिए एक ही विषय हैं, जब तक डिज़ाइन उन्हें अलग पते या अलग प्रमाणित पहचान न दे। इसलिए गेटवे पर प्रति-उपयोगकर्ता नियम फ़ोन पर प्रति-ऐप नियम नहीं है, प्रबंधन कंसोल इसे जो भी कहे।
चरण 3: जो कभी नहीं पहुँचता उसकी सूची बनाएँ
VPN से बाहर रखा गया ऐप किसी निकट उपकरण से संपर्क करता है तो गेटवे तक कभी नहीं पहुँचता, इसलिए बाहर जाने वाला फ़ायरवॉल ऐसे पैकेट को अस्वीकार नहीं कर सकता जो उसे कभी मिलता ही नहीं। यही बात किसी रुकावट के दौरान अनजाने सीधे रास्ते और स्थानीय पहुँच नेटवर्क पर आने वाले संपर्क के लिए भी लागू है। ये परिभाषा से स्थानीय सीमाएँ हैं।
उल्टा भी सच है: कनेक्शन की अनुमति देने वाला स्थानीय नियम गेटवे के निजी नेटवर्क ACL से पहुँच नहीं देता। एक अनुरोध दोनों सीमाओं के अधीन हो सकता है, और एक को पूरा करना दूसरे के बारे में कुछ नहीं कहता।
चरण 4: हर नियम को एक पथ सौंपें
कुछ भी कॉन्फ़िगर करने से पहले निर्णय को तालिका में रखिए, क्योंकि खाली खाने ही वह जगह हैं जहाँ डिज़ाइन विफल होते हैं।
| पथ | कौन लागू कर सकता है | अंधा बिंदु |
|---|---|---|
| कार्य ऐप से कार्य सेवा तक, सुरंग चालू | पते और सेवा पर गेटवे ACL, साथ में अन्य पथों पर स्थानीय रोक | गेटवे नहीं देख सकता कि किस ऐप ने पैकेट भेजा |
| कार्य ऐप से अन्य गंतव्यों तक, सुरंग चालू | ऐप-सजग स्थानीय फ़िल्टर, या गेटवे यदि वे गंतव्य वहाँ पतेबद्ध हैं | स्थानीय फ़िल्टर ही सक्रिय VpnService होना चाहिए |
| सुरंग के बिना कार्य ऐप | स्थानीय अस्वीकृति, ताकि ऐप सीधा रास्ता न ले सके | फ़िल्टर को सुरंग जाने के बाद भी टिकना होगा |
| निकट का LAN उपकरण | केवल स्थानीय नीति | गेटवे उसे कभी नहीं देखता |
जो आकार काम करता है वह दो कामों वाली दो सीमाएँ हैं। ऐप-सजग स्थानीय सीमा फ़ोन के व्यवहार को नियंत्रित करती है, सीधे गिरने सहित, और गेटवे की सीमा दूरस्थ संसाधनों को नियंत्रित करती है। गेटवे की ओर कार्य सेवा को अनुमति देकर बाकी हर निजी सबनेट को अस्वीकार कर सकती है, जबकि फ़ोन की ओर की नीति उस सीधे रास्ते पर स्वयं निर्णय लेती है जो ऐप अन्यथा ले सकता था।
चरण 5: परिवहन को जीवित रखें, फिर सत्यापित करें
आप जो भी स्थानीय नीति चुनें, उसे उस परिवहन की अनुमति देनी होगी जो VPN स्थापित करता है और बनाए रखता है। उस परिवहन को अवरुद्ध करना फ़ोन को सुरंग और नीति दोनों से बिना छोड़ देता है, जो कुछ भी सुसंगत रूप से लागू नहीं करता और निदान करना कठिन है, क्योंकि ऐप के पास बस नेटवर्क ही नहीं होता।
फिर सामान्य धारणा के बजाय मूल वाक्य की हर पंक्ति सत्यापित करें: कार्य ऐप कार्य सेवा तक पहुँचता है, वही ऐप किसी अन्य गंतव्य पर अस्वीकार होता है, जो ऐप कार्य का नहीं है वह पहले जैसा व्यवहार करता है, और सुरंग रोकने पर कार्य ऐप सीधे कनेक्शन पर नहीं गिरता। DNS पथ अलग से जाँचें, क्योंकि निजी DNS या एन्क्रिप्टेड रिज़ॉल्वर ऐसे फ़िल्टर से बच सकता है जो केवल पते देखता है।
अगर इनमें से कोई चरण फ़ोन पर पूरा नहीं हो सकता, तो आवश्यकता वास्तुकला का सवाल है, फ़ायरवॉल की सेटिंग नहीं। नीति को उस उपकरण और उस गेटवे के बीच बाँटना जिन्हें आप नियंत्रित करते हैं, आमतौर पर ईमानदार उत्तर है, और Android VPN कनेक्टिविटी दस्तावेज़ वह जगह है जहाँ आप पुष्टि करते हैं कि प्लेटफ़ॉर्म एक सेवा को क्या अनुमति देगा और क्या नहीं।