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

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