स्प्लिट टनलिंग बनाम कंपनी नीति: कौन-सा नियम जीतता है

स्प्लिट-टनल क्लाइंट में एक ऐप को टिक करना स्थानीय पसंद जैसा लगता है, और प्रबंधित डिवाइस पर यह नीति बदलने के अधिक करीब है। यह अपवाद ट्रैफ़िक को स्वीकृत रास्ते से हटा देता है, जो वही रास्ता हो सकता है जिससे प्रबंधित DNS, फ़िल्टरिंग और वह स्रोत पता जाता है जिसे कोई सेवा पहचानती है। जब क्लाइंट आपका संपादन वापस लौटाता है तो वह गलत नहीं कर रहा; परिनियोजन अपना काम कर रहा है।

चेकबॉक्स पर बहस करने से पहले तय करें कि नीति किस गुण की रक्षा के लिए है।

नियम के पीछे का गुण

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

चौथा समूह एंडपॉइंट की स्थिति लागू करता है: डिस्क एन्क्रिप्शन की स्थिति, पैच स्तर, एजेंट का स्वास्थ्य। टनल बाँटने से यह नहीं बदलता, जबकि एजेंट के अपने ट्रैफ़िक से बचने वाला बायपास बदल सकता है।

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

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

जाँचें क्रम में चलाएँ

नीचे दिया क्रम अपवाद को उस सबसे छोटी चीज़ तक सीमित करता है जो वास्तव में विफल हुई। पहली ऐसी जाँच पर रुकें जो टिकती नहीं, क्योंकि बाद का सुधार पहले की कमी की भरपाई नहीं कर सकता।

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

हर जवाब एक तथ्य है, और अपवाद अनुरोध को तथ्यों की ज़रूरत होती है। VPN चिढ़ाने वाला है या नहीं, यह बहस उनमें नहीं है। बातचीत शुरू होने से पहले जवाब लिख लें।

संकीर्ण अपवाद मांगें

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

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

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

अपवाद को टिकाऊ बनाएँ

स्वीकृत बदलाव के बाद पहले काम करने वाले हिस्सों की पुष्टि करें, केवल टूटे हिस्से की नहीं। आंतरिक नाम अब भी कॉर्पोरेट रिज़ॉल्वर से हल होने चाहिए, निजी संसाधन जवाब देने चाहिए, और पहले विफल रहा कार्य अब पूरा होना चाहिए।

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

अपवाद, उसका उद्देश्य और उसके अंतर्गत आने वाले घटक उसी जगह दर्ज करें जहाँ परिनियोजन नोट्स हैं। अप्रलेखित अपवाद अगली तिमाही की घटना बन जाता है, और प्रलेखित अपवाद इस बात का प्रमाण बन जाता है कि डिज़ाइन वास्तविक कार्यभार सँभालता है।