Android होम LAN VPN अपवाद: एक सेवा के लिए रनबुक

आप चाहते हैं कि एक होम सेवा पहुँच में रहे जबकि VPN बाकी सब के लिए लागू रहे। लुभावनी सेटिंग हर निजी पते को ढकने वाला स्थानीय-रूट अपवाद है, और वह गलत नियंत्रण है: अगले होटल या कैफ़े नेटवर्क पर यह जवाब देने वाली किसी भी चीज़ को बायपास बना सकता है। यह रनबुक अपवाद को एक ही सेवा तक सीमित करता है और उन बदलावों के तहत उसे साबित करता है जो उसे तोड़ते हैं।

अपवाद को सबनेट नहीं, सेवा के रूप में परिभाषित करें

ऐप, गंतव्य का होस्टनाम और पता, प्रोटोकॉल और पोर्ट, वह नेटवर्क जहाँ इसकी अनुमति है, और सेवा द्वारा स्वयं किया गया पहचान जाँच दर्ज करें। प्रमाणीकरण वाले NAS के लिए प्रमाणपत्र या खाता ही साबित करता है कि आप सही मशीन तक पहुँचे। 192.168.0.0/16 में एक पता कुछ भी साबित नहीं करता, क्योंकि हर होम राउटर वही प्रीफ़िक्स बाँटता है।

यह भी तय करें कि निकट का क्या अर्थ है। रूटेड VLAN पर कोई सेवा फ़ोन से सीधे जुड़े सबनेट पर नहीं होती, और अतिथि Wi-Fi घर वाला ही निजी प्रीफ़िक्स साझा कर सकता है जबकि पूरी तरह अलग मशीन हो। अपवाद में सेवा और परिवेश का नाम होना चाहिए, केवल पता-सीमा नहीं।

सुनिश्चित करें कि प्लेटफ़ॉर्म नियंत्रण आवश्यकता से मेल खाता है

Android का IKEv2 प्रोफ़ाइल बिल्डर setLocalRoutesExcluded(true) प्रदान करता है, और उसका दस्तावेज़ीकरण बायपास हो सकने वाला VPN माँगता है: अपवाद तभी अर्थपूर्ण है जब क्लाइंट ट्रैफ़िक को टनल से बाहर जाने दे। वही दस्तावेज़ चेतावनी देता है कि अंतर्निहित नेटवर्क ऐसे रूट दे सकता है जो अपवाद को प्रभावित करते हैं, इसलिए सेटिंग उस नेटवर्क का पालन करती है जिससे आप जुड़ते हैं, न कि उसका जिस पर आप भरोसा करते हैं।

यह यह वादा भी नहीं है कि हर लॉकडाउन या प्रबंधित कॉन्फ़िगरेशन उपयोगकर्ता को वही अपवाद सक्षम करने देगा। रूट अपवाद, बायपास-क्षमता ध्वज और डिवाइस अवरोधन नीति अलग-अलग नियंत्रण हैं, और प्रबंधित डिवाइस तीसरे को मना करते हुए पहले दो की अनुमति दे सकता है। चेकबॉक्स के इर्द-गिर्द डिज़ाइन करने से पहले स्थापित प्रोफ़ाइल और प्रबंधन नीति जाँचें।

रनबुक: अपवाद बनाएँ और लागू करें

चरण 1: परिनियोजन के लिए समर्थित मार्ग से प्रोफ़ाइल बनाएँ, या तो प्रबंधित कॉन्फ़िगरेशन या क्लाइंट बिल्डर। चरण 2: VPN को बायपास-योग्य चिह्नित करें, क्योंकि स्थानीय-रूट अपवाद इसके बिना प्रभावी नहीं है। चरण 3: स्थानीय-रूट अपवाद सक्षम करें। चरण 4: सेवा का अपना प्रमाणीकरण और प्रमाणपत्र सत्यापन सक्षम रखें; अपवाद रूटिंग के बारे में है, भरोसे के बारे में नहीं। चरण 5: सहेजें और फिर से जुड़ें ताकि प्रोफ़ाइल लागू हो।

वापसी वही मार्ग उल्टे क्रम में है: अपवाद साफ़ करें, फिर बायपास-क्षमता साफ़ करें, फिर फिर से जुड़ें। डिवाइस पर सीधे रूट या फ़ायरवॉल हुक पैच न करें। नेटवर्क डेमन उन नियमों का स्वामी है, और हाथ से लिखा नियम किसी दूसरे पता-परिवार, पुनःकनेक्शन या नेटवर्क संक्रमण को चूक सकता है। यदि स्थापित कॉन्फ़िगरेशन नीति व्यक्त नहीं कर सकता, तो स्वामी द्वारा दूसरा डिज़ाइन स्वीकृत होने तक कड़ा अवरोध रखें।

चार महत्वपूर्ण मामले जाँचें

हानिरहित अनुरोध इस्तेमाल करें और हर मामला चलाने से पहले अपेक्षित परिणाम लिखें। नीचे दिया मैट्रिक्स स्वीकृति परीक्षण है, सुझाव नहीं: यदि कोई अस्वीकृत मामला सफल होता है, तो अपवाद नीति से व्यापक है।

मामला 3 वही है जो व्यापक निजी सबनेट बायपास पकड़ता है, और मामला 4 ऐसे क्लाइंट को पकड़ता है जिसने अपवाद केवल जुड़ते समय लागू किया। VPN काटे हुए और फ़ोन मोबाइल नेटवर्क पर ले जाए हुए मामला 4 चलाएँ, फिर फिर से जुड़ें और पुष्टि करें कि अपवाद रीबूट के बिना लौटता है। स्थानीय-रूट API संदर्भ वह बायपास-शर्त बताता है जो चरण 2 को अनिवार्य बनाती है।

अपवाद दर्ज करें और उसकी समीक्षा करें

रखे गए रिकॉर्ड में सेवा, उसे न्यायसंगत ठहराने वाला परिवेश, स्वामी और तारीख का नाम होना चाहिए। स्थानीय रूटिंग संबंध बताता है, भरोसे का स्तर नहीं, और फ़ोन अगली बार जिस नेटवर्क से जुड़ेगा वह वह नेटवर्क नहीं है जहाँ अपवाद स्वीकृत हुआ था।

OS अद्यतन, क्लाइंट अद्यतन या स्थानांतरण के बाद रिकॉर्ड की समीक्षा करें। जब भी अपवाद नवीनीकृत हो, मामला 3 फिर चलाएँ, क्योंकि जिस प्रोफ़ाइल ने एक बार बायपास को एक सेवा तक सीमित किया था वह एक ही डिफ़ॉल्ट बदलाव से व्यापक हो सकती है।