क्या आपका किल स्विच उस ऐप को ब्लॉक करेगा जिसे आपने टनल से बाहर रखा था?

किल स्विच चालू, एक ऐप जानबूझकर टनल से बाहर रखा गया, और दोनों आवश्यकताएँ अब एक-दूसरे का विरोध करती हैं। एक कहती है कि टनल के अलावा कुछ बाहर नहीं जा सकता, दूसरी कहती है कि इस प्रोग्राम को सीधे जाना चाहिए। हर क्लाइंट इस टकराव को अलग तरह से सुलझाता है, और सेटिंग्स पेज शायद ही बताता है कि कौन-सा नियम जीतता है। किसी भी लेबल पर भरोसा करने से पहले हर ऐप के लिए नीति लिखें।

दो नीतियाँ, एक मशीन

किल स्विच विफलता के बारे में एक वादा है: जब टनल ट्रैफ़िक की सुरक्षा नहीं कर रही, ट्रैफ़िक रुक जाता है। विभाजित टनल चयन के बारे में एक वादा है: ये प्रोग्राम या गंतव्य टनल का उपयोग करते हैं, और वे नहीं। दूसरा वादा ऐसा ट्रैफ़िक बनाता है जिस पर पहले को फैसला करना है। कोई भी वादा ग़लत नहीं है; बस अलग-अलग लोगों ने उन्हें अलग-अलग ख़तरों के लिए लिखा।

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

नियम से पहले ऐप की सूची लिखें

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

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

एक नहीं, दो सूचियाँ चाहिए: टनल को क्या ढोना है, और क्या किसी भी कारण से उसके बाहर यात्रा नहीं करनी चाहिए। दोनों में दिखने वाला ऐप कार्यान्वयन का विवरण नहीं बल्कि आवश्यकता का टकराव है, और क्लाइंट कॉन्फ़िगर करने से पहले उसे सुलझाना होगा।

व्यवधान के दौरान क्लाइंट क्या करता है

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

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

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

तीन पल: टनल चालू, टनल बंद, फिर से जुड़ाव

तीन पलों में हानिरहित अनुरोध इस्तेमाल करें: जब टनल काम कर रही हो, जिस विफलता की आपको चिंता है उसके दौरान, और फिर से जुड़ने के बाद। एक ब्राउज़र परिणाम बाहर रखे गए ऐप का व्यवहार स्थापित नहीं कर सकता।

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

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

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