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 जाँच सुरुदेखि यसैगरी टिकिरह्यो।