स्टेटस फ़ाइल सत्र गिनती है, उनके पीछे का LAN नहीं

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

स्नैपशॉट में वास्तव में क्या होता है

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

status /run/openvpn/office.status 30
status-version 3

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

सत्र गिनें, लोग या मशीनें नहीं

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

यदि संख्या लाइसेंसिंग या क्षमता के लिए मायने रखती है, तो इकाई को रिपोर्ट वाले उसी दस्तावेज़ में परिभाषित करें। जो रिपोर्ट यह नहीं बताती कि वह सत्र, पहचान या डिवाइस गिनती है, उसे पाठक द्वारा अपेक्षित इकाई के रूप में पढ़ा जाएगा।

बाहरी पता पहचानकर्ता नहीं है

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

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

रूटिंग पंक्तियाँ होस्ट सूची नहीं हैं

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

कई पंक्तियाँ एक ही पीयर की ओर भी संकेत कर सकती हैं, क्योंकि कोई साइट एक से अधिक श्रेणी घोषित कर सकती है। पंक्तियाँ गिनकर परिणाम को डिवाइस गणना कहना तैनाती को मनमाने गुणक से बढ़ा-चढ़ाकर दिखाता है।

यदि आवश्यकता वास्तव में परिसंपत्ति सूची है, तो उस नेटवर्क के स्वामी इन्वेंटरी प्रक्रिया का उपयोग करें। VPN पहचान सकता है कि कौन-सा पीयर मार्ग ले जाता है, और यह उस तथ्य से भिन्न है कि उसके पीछे कौन-से होस्ट हैं।

आयु, अनुमतियाँ और लाइव दृश्य

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

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

घटना-चालित आवश्यकताओं के लिए तेज़ पोलिंग के बजाय समर्थित प्रबंधन इंटरफ़ेस का उपयोग करें। उस इंटरफ़ेस को नियंत्रण मानें, मेट्रिक्स नहीं, और केवल सत्र गिनने के लिए उसे कभी इंटरनेट पर उजागर न करें।