पोर्ट 1194 पहिलेदेखि नै प्रयोगमा छ: यो OpenVPN सकेट कसको हो?

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

त्रुटिले स्थानीय बाइन्डको वर्णन गर्छ र त्यसभन्दा पर केही होइन। कुनै प्रदायकले पोर्ट अवरोध गरिरहेको, ग्राहकले गलत पासवर्ड पठाएको, वा प्रमाणपत्र शृंखला भाँचिएको यसको प्रमाण होइन।

ठ्याक्कै बाइन्ड त्रुटि पढ्नुहोस्

यो परिवारका दुई त्रुटिको अर्थ फरक हुन्छ, र तिनलाई मिसाउँदा तपाईं गलत तहमा पुग्नुहुन्छ। «ठेगाना पहिलेदेखि प्रयोगमा छ» भन्नुको अर्थ अर्को सकेटले तपाईंले मागेको अन्त्य बिन्दु राखेको छ। «ठेगाना उपलब्ध छैन» भन्नुको अर्थ तपाईंले मागेको ठेगाना यो होस्टमा अझै छैन, जो तयारीको समस्या हो, प्रतिलिपि होइन।

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

सकेटको सूची बनाउनुहोस्, पोर्टको होइन

पोर्ट नम्बर अपूर्ण सूची हो। अन्त्य बिन्दु भनेको यातायात, ठेगाना परिवार, स्थानीय ठेगाना र पोर्ट हो, सबै एउटै सञ्जाल नामस्थानभित्र। एउटै नम्बरमा UDP श्रोता र TCP श्रोता फरक सकेट हुन्, र फरक नामस्थानमा एउटै नम्बरका दुई प्रक्रिया कहिल्यै भेट्दैनन्।

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

पहिले प्रोफाइलले वास्तवमै प्रयोग गर्ने यातायात चलाउनुहोस्। त्यसपछि केवल नम्बर होइन, स्थानीय ठेगाना स्तम्भ हेर्नुहोस्: वाइल्डकार्ड बाइन्डले हरेक स्थानीय ठेगाना ढाक्छ, त्यसैले एउटा विशिष्ट ठेगाना माग्ने दोस्रो प्रक्रिया छापिएका स्ट्रिङ फरक भए पनि त्यससँग ठोक्किन सक्छ। सकेट पुनःप्रयोग विकल्प र प्लेटफर्म नियमले ठ्याक्कै नतिजा निर्धारण गर्छन्, त्यसैले यो हरेक तैनाथीमा लागू गर्ने नियम नभई अवलोकन हुनुपर्छ।

कुन प्रक्रिया यसको मालिक हो पत्ता लगाउनुहोस्

संख्यात्मक अन्त्य बिन्दु र प्रक्रिया जानकारीले तपाईंका विशेषाधिकारले अनुमति दिएमा मालिक पहिचान गर्छ, र तपाईंलाई मालिक चाहिन्छ, कार्यक्रमको नाम होइन। दुई OpenVPN प्रक्रियाले फरक प्रोफाइल चलाउन सक्छन्, र श्रोता राख्ने प्रक्रिया तपाईंले सबैभन्दा कम अपेक्षा गरेको हुन सक्छ।

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

एक मालिक, वा दुई डिजाइन गरिएका इन्स्ट्यान्स

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

यदि दुई इन्स्ट्यान्स इच्छित छन् भने, तिनलाई फरक श्रोता दिनुहोस् र बाँकी सबै फरक राख्नुहोस्: ठेगाना पूल, भर्चुअल इन्टरफेस, राउटिङ नीति र कन्फिगरेसनको स्वामित्व। केवल फरक पोर्टले सकेटबाहेक केही अलग गर्दैन, र दुवै सर्भर एउटै पूल र एउटै मार्गका लागि लडिरहनेछन्।

तीन छोटो बाटो नाम दिन लायक छन् किनकि ती यो त्रुटिबारे हरेक छलफलमा देखिन्छन्। दोषी जस्तो देखिने कुनै पनि PID मार्नु हुँदैन। सन्देश शान्त पार्न सकेट साझेदारी सक्षम गर्नु हुँदैन। सर्भर प्रोफाइललाई ग्राहक-शैलीको अनबाउन्ड कन्फिगरेसनमा बदल्नु हुँदैन किनकि त्यसले बाइन्ड त्रुटि हराउँछ; सर्भर मूल द्वन्द्वभन्दा निदान गर्न कठिन तरिकाले पहुँचबाहिर हुन्छ।

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

अरू सबैभन्दा पहिले बाइन्ड प्रमाणित गर्नुहोस्

सीमित सुधारपछि, इच्छित इन्स्ट्यान्स सक्रिय छ, त्यसको श्रोता अपेक्षित यातायातमा देखिन्छ, र ग्राहक जडान हुन सक्छ भनी पुष्टि गर्नुहोस्। सफल बाइन्डले स्थानीय सकेट चरण मात्र पूरा गर्छ; टनेल उठेपछि प्रमाणीकरण वा ट्राफिकबारे यसले केही प्रमाणित गर्दैन।

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

यदि सकेट छ र ग्राहक अझै असफल हुन्छ भने, बाँकी समस्या डाउनस्ट्रिममा छ र बाइन्ड त्रुटि अब इतिहास हो। यही विभाजन नै ठ्याक्कै सन्देश पहिले पढ्नुको पूरा उद्देश्य हो: एउटा त्रुटि, एउटा तह, एउटा मालिक। त्यसरी पढ्नुहोस् र अर्को लक्षण अनुमानबाट होइन, ज्ञात अवस्थाबाट सुरु हुनेछ।