स्प्लिट टनेलिंग विरुद्ध कंपनी धोरण: कोणता नियम जिंकतो

स्प्लिट-टनेल क्लायंटमध्ये एक अ‍ॅप टिक करणे स्थानिक पसंतीसारखे वाटते, आणि व्यवस्थापित उपकरणावर ते धोरण बदलण्याच्या जवळ आहे। हा अपवाद रहदारी मंजूर मार्गावरून दूर करतो, जो कदाचित तोच मार्ग असू शकतो ज्यावरून व्यवस्थापित DNS, फिल्टरिंग आणि सेवा ओळखत असलेला स्रोत पत्ता जातो। क्लायंटने तुमचे संपादन परत केल्यावर तो चुकीचे वागत नाही; उपयोजन आपले काम करत आहे।

चेकबॉक्सबद्दल वाद घालण्यापूर्वी धोरण कोणत्या गुणधर्माच्या रक्षणासाठी आहे ते ठरवा।

नियमामागील गुणधर्म

काही उपयोजने सर्व काही मार्गित करतात जेणेकरून सर्व रहदारी मंजूर गेटवेमधून जाईल। इतरांना नाव निराकरणाची काळजी असते आणि ते प्रश्न स्थानिक नेटवर्कऐवजी कॉर्पोरेट रिझोल्व्हरवर ठेवतात। अजून काहींना स्थिर स्रोत पत्ता हवा असतो जेणेकरून अंतर्गत सेवा उत्तर द्यायचे की नाही हे ठरवू शकतील।

चौथा गट एंडपॉइंटची स्थिती लादतो: डिस्क एन्क्रिप्शन स्थिती, पॅच पातळी, एजंटचे आरोग्य। टनेल विभागल्याने ते बदलत नाही, पण एजंटच्या स्वतःच्या रहदारीला टाळणारा बायपास बदलू शकतो।

या चार वेगळ्या आवश्यकता आहेत, आणि प्रत्येकाला वेगळा अपवाद मोडतो। बदल सुचवण्यापूर्वी आवश्यकता वाचा, कारण ज्याने लिहिली तो कोणती लागू होते हे लगेच सांगू शकतो। चुकीची आवश्यकता पूर्ण करणारा बदल काहीही विकत नाही।

दोन दावे लवकर फेटाळण्यासारखे आहेत। संपूर्ण टनेलिंग प्रशासकांना प्रत्येक साध्या मजकुराचे पृष्ठ देत नाही, कारण काय दिसेल हे अ‍ॅप्लिकेशन एन्क्रिप्शन आणि एंडपॉइंट नियंत्रणे ठरवतात। स्प्लिट टनेलिंगही सार्वत्रिकपणे असुरक्षित नाही, कारण व्यवस्थापित DNS, प्रति-अ‍ॅप धोरणे आणि एंडपॉइंट एजंट मार्गाकडे दुर्लक्ष करून टिकू शकतात।

तपासण्या क्रमाने करा

खालील क्रम अपवादाला प्रत्यक्षात अयशस्वी झालेल्या सर्वात लहान गोष्टीपर्यंत मर्यादित करतो। जी तपासणी टिकत नाही तिथेच थांबा, कारण नंतरची दुरुस्ती आधीची त्रुटी भरून काढू शकत नाही।

आता कोणती रहदारी मंजूर गेटवे चुकवत आहे ते विचारा, नंतर नाव निराकरण अजूनही कॉर्पोरेट रिझोल्व्हरपर्यंत पोहोचते याची खात्री करा। संबंधित अ‍ॅप किल स्विचचा आदर करते की अयशस्वी प्रयत्न थेट मार्गावर घालवला हे पहा। नंतर सामायिक सेवा पहा: दस्तऐवज दर्शक किंवा अद्यतन ब्रोकर चेकबॉक्स सुचवते त्यापेक्षा अपवाद दूर नेऊ शकतो। शेवटी, पुन्हा जोडल्यावर धोरण पुन्हा लागू होते का ते नोंदवा, कारण ते वर्तन कोणताही स्थानिक बदल टिकेल का हे ठरवते।

प्रत्येक उत्तर एक तथ्य आहे, आणि अपवाद विनंतीला तथ्येच हवी असतात। VPN त्रासदायक आहे का यावरचा वाद त्यापैकी नाही। संभाषण सुरू होण्यापूर्वी उत्तरे लिहा।

अरुंद अपवाद मागा

अ‍ॅप्लिकेशन, गंतव्य आणि अयशस्वी झालेली क्रिया याच क्रमाने नोंदवा। एक अद्यतनकर्ता थेट मार्गावर ठेवण्याची विनंती पुनरावलोकनायोग्य आहे; संपूर्ण ब्राउझरसाठी टनेल टाळण्याची विनंती नाही।

तुम्ही आधी काय प्रयत्न केले आणि लॉगने काय दाखवले ते वर्णन करा, आणि ते हेल्प डेस्कवर उत्तर देणाऱ्याऐवजी प्रोफाइलच्या मालक असलेल्या टीमला पाठवा। व्यवस्थापित उपकरणावर प्रोफाइल मालक सामान्यतः अद्यतनांनंतरही टिकणारा समर्थित अपवाद तयार करू शकतो, तर स्थानिक मार्ग संपादन ते करू शकत नाही।

उत्तर नाही असेल तर ते टाळावयाचा अडथळा न मानता रचना निर्णय माना। पुढील पुनरावलोकन ते पुन्हा उघडण्याची जागा आहे, अयशस्वी क्रिया नोंदवून व्यावसायिक कारण जोडून। त्याला वळसा घालणे अपवाद कधीही लायक होता त्यापेक्षा जास्त धोका पत्करते।

अपवाद टिकाऊ करा

मंजूर बदलानंतर आधी काम करणारे भाग तपासा, केवळ तुटलेला भाग नाही। अंतर्गत नावे अजूनही कॉर्पोरेट रिझोल्व्हरमधून सोडवली पाहिजेत, खाजगी संसाधने उत्तर दिली पाहिजेत, आणि आधी अयशस्वी झालेले कार्य आता पूर्ण व्हावे।

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

पहिला आदेश रिझोल्व्हर अजूनही अंतर्गत प्रत्ययासाठी उत्तर देतो हे सिद्ध करतो, आणि दुसरा विनंती सध्याच्या मार्गावरून अंतर्गत सेवेपर्यंत पोहोचते हे सिद्ध करतो। पुन्हा जोडल्यानंतर ते पुन्हा चालवा, कारण धोरण पुश चाचणीत स्थिर दिसणारा बदल शांतपणे रद्द करू शकतो। तिकिटासोबत ठेवलेल्या दोन आउटपुट ओळी वर्तुळ बंद करतात। त्या नसल्यास अपवाद एकदा लोड झालेल्या पृष्ठाबद्दलच्या कोणाच्या तरी स्मरणावर अवलंबून असतो।

अपवाद, त्याचा उद्देश आणि त्याने व्यापलेले घटक उपयोजन नोंदींसारख्याच ठिकाणी नोंदवा। अप्रलेखित अपवाद पुढील तिमाहीची घटना बनतो, आणि प्रलेखित अपवाद रचना प्रत्यक्ष कार्यभार सांभाळते याचा पुरावा बनतो।