प्रति ऐप VPN अपवाद तब टूटते हैं जब साझा सेवा डेटा लाती है

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

इन टिकटों में आम तौर पर दो चीज़ें साथ-साथ गलत होती हैं: गलत घटक बाहर रखा जाता है, और अपवाद बाद में कभी संकुचित नहीं होता।

प्रक्रिया खोजें, विंडो नहीं

विफल क्रिया को दोहराएँ और घटित होते समय कनेक्शन का मालिक प्रक्रिया या पैकेज पहचानें। Windows पर यह इस सवाल से अलग है कि किस विंडो पर फ़ोकस है, क्योंकि पृष्ठभूमि स्थानांतरण की मध्यस्थता ऐसी सेवा कर सकती है जो अपनी पहचान के तहत चलती है। Linux और macOS पर वही विभाजन सहायक प्रक्रियाओं और सिस्टम डेमॉन के रूप में दिखता है।

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

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

DNS को अपना अलग मार्ग मानें

सिस्टम नाम रिज़ॉल्यूशन बाहर रखे गए ऐप का बिल्कुल भी पालन नहीं कर सकता, इसीलिए बाहर रखा गया ब्राउज़र निजी होस्टनाम पर फिर भी विफल हो सकता है जबकि उसका ट्रैफ़िक सही तरीके से टनल के बाहर है। ब्राउज़र बाहर रखा गया था; रिज़ॉल्वर नहीं।

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

दर्ज करें कि किस रिज़ॉल्वर ने उत्तर दिया और किस इंटरफ़ेस से। यह एक अवलोकन «ऐप बाहर रखा गया है पर नाम हल नहीं होता» रिपोर्टों का बड़ा हिस्सा सुलझा देता है, इसलिए इसे टिकट के साथ रखें।

साझा सहायक को चौड़ा न करें

साझा सेवा कई ऐप्लिकेशन के लिए काम करती है, इसलिए एक कार्यप्रवाह ठीक करने के लिए उसे बाहर रखने से असंबंधित ट्रैफ़िक भी बदलता है। Windows पर Background Intelligent Transfer Service इस आकार का अच्छा उदाहरण है: यह ऐसा ढाँचा है जिसका कई ऐप्लिकेशन उपयोग कर सकते हैं, और इसकी पहचान स्थानांतरण माँगने वाले ऐप की पहचान नहीं है।

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

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

पूरा कार्यप्रवाह जाँचें, विफल चरण नहीं

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

परीक्षण को छोटा और दोहराने योग्य रखें: वही गंतव्य, वही खाता, वही परिस्थितियाँ। अगर दूसरा कार्यप्रवाह प्रलेखित नहीं है, तो बदलाव को सुरक्षित मानने से पहले उसके स्वामी से पूछें कि वह किस पर निर्भर है।

नामों की सूची नहीं, कारण छोड़ें

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

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