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

एक सेवा, तीन रिकॉर्ड

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

RecordAnswersGoes stale when
Intended serviceWho may reach whatA contract changes and nobody edits the record
Deployed configurationWhat the gateway was toldA device is edited by hand
Observed sessionWhat is running nowTelemetry stops or a session ends

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

किरायेदार दर्ज करें, इंटरफ़ेस नहीं

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

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

उत्पन्न कॉन्फ़िगरेशन का मालिक और संस्करण होता है

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

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

सत्र साक्ष्य हैं, अनुमति नहीं

जहाँ तैनाती RADIUS लेखांकन का उपयोग करती है, वहाँ RFC 2866 काम करने के लिए ठोस फ़ील्ड देता है। Acct-Status-Type शुरुआत को रुकने से अलग करता है, और एक ही सत्र के रिकॉर्ड एक Acct-Session-Id साझा करते हैं। ये फ़ील्ड आपको डैशबोर्ड के सारांश पर भरोसा किए बिना पुनर्निर्माण करने देते हैं कि सत्र कब शुरू और कब समाप्त हुआ।

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

निवृत्ति उसी जोड़ का उपयोग करती है

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

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

संबंधित लेख