स्प्लिट टनल अब भी उस ऐप को बाहर रखता है जिसे आपने अनइंस्टॉल किया

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

इसे साफ़ करना मुख्यतः पहचान का मामला है: नियम अब किस ओर इशारा करता है, और सूची किसकी है।

लक्षण: ऐसा बहिष्करण जो किसी से मेल नहीं खाता

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

नियम को मिटाने से नहीं, उसे पढ़ने से शुरू करें।

पता लगाएँ कि नियम क्या पहचानता है

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

दिखाया गया नाम प्रविष्टि का सबसे कम भरोसेमंद हिस्सा है, और लोग ठीक वही हिस्सा पढ़ते हैं।

पथ के नियम और पैकेज के नियम अलग-अलग व्यवहार करते हैं

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

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

मालिक के ज़रिए उसे हटाएँ

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

खाली सूची लक्ष्य नहीं है। लक्ष्य वह सूची है जिसकी प्रविष्टियाँ अब भी वास्तविक आवश्यकताओं से मेल खाती हैं।

सफ़ाई के बाद दोनों दिशाओं का परीक्षण करें

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

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