क्यों nc -uz यह साबित नहीं कर सकता कि OpenVPN सर्वर तैयार है

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

UDP जाँच क्या देख सकती है और क्या नहीं

nc -uz एक डेटाग्राम भेजता है और बाहर निकल जाता है, और जो स्थिति लौटाता है वह स्थानीय भेजने का वर्णन करती है। बंद पोर्ट ICMP port unreachable के साथ उत्तर दे सकता है, परंतु इस स्कैन मोड का प्रलेखित व्यवहार उसे विफलता में नहीं बदलता, और फ़िल्टर किया गया पोर्ट कोई उत्तर ही नहीं देता। इसलिए मौन और सफलता कॉलर के लिए एक ही अर्थ रखते हैं।

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

जाँच को कॉन्फ़िगर किए गए ट्रांसपोर्ट से मिलाना दोनों में से किसी भी परिणाम पर भरोसा करने से पहले आता है। UDP परिनियोजन को अलग संकेत चाहिए, अलग प्रोटोकॉल नहीं।

तीन कॉलर, तीन अलग प्रश्न

तैयारी इस पर निर्भर है कि कौन पूछ रहा है। दुर्घटनाग्रस्त प्रक्रिया को पुनः आरंभ करने वाले सेवा प्रबंधक को जानना चाहिए कि इंस्टेंस शुरू हुआ और उसने अपना श्रोता बाँधा। लोड बैलेंसर को जानना चाहिए कि अब आने वाला क्लाइंट स्वीकार किया जाएगा। निगरानी प्रणाली को जानना चाहिए कि वास्तविक नेटवर्क से मार्ग अभी भी अनुमत संसाधन तक सत्र ले जाता है।

ये एक ही जाँच नहीं हैं, और एक जाँच ईमानदारी से तीनों को कवर नहीं कर सकती। पहले कॉलर चुनें, फिर साक्ष्य।

जाँच को वर्तमान इंस्टेंस से बनाएँ

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

इसे जानबूझकर तोड़ें और जाँच देखें

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

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

ब्लॉक को पंक्ति दर पंक्ति पढ़ें। netcat कमांड छापता है exit=0 जबकि कुछ भी बंधा नहीं है, और पूरी समस्या एक ही पंक्ति में यही है। पहला ss कुछ नहीं छापता, पुनः आरंभ सफल होता है, और दूसरा ss फिर से श्रोता दिखाता है। यदि आपकी जाँच रुके हुए सर्वर के विरुद्ध पास होती है, तो वह स्थानीय स्टैक माप रही है और कुछ नहीं।

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

स्टेटस पंक्ति को क्या कहना चाहिए

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

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

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