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 तपासणी सुरुवातीलाच अशीच टिकून राहिली।