पोर्ट 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

जर सॉकेट असेल आणि ग्राहक अजूनही अयशस्वी होत असेल, तर उर्वरित समस्या डाउनस्ट्रीम आहे आणि बाइंड त्रुटी आता इतिहास आहे। हेच विभाजन नेमका संदेश प्रथम वाचण्याचा संपूर्ण हेतू आहे: एक त्रुटी, एक स्तर, एक मालिक। असे वाचा आणि पुढील लक्षण अंदाजातून नाही तर ज्ञात स्थितीतून सुरू होईल।