VPN पोर्ट चुप? लिसनर, बाइंड पता या होस्ट फ़ायरवॉल

VPN अपने पोर्ट पर कुछ भी जवाब नहीं देता, और दो संभावित कारणों को उलटी मरम्मत चाहिए: या तो किसी प्रक्रिया ने सॉकेट नहीं खोला, या सॉकेट मौजूद है और मशीनों के बीच कुछ पैकेट रोक रहा है। एक ही कमांड उस सवाल का पहला आधा हिस्सा तय कर देती है, इसीलिए वह किसी भी फ़ायरवॉल नियम को छूने से पहले आती है। नीचे का क्रम हर चरण में एक व्याख्या हटाता है, न कि एक और अनुमान जोड़ता है। इन दोनों के बीच अनुमान लगाना ही दस मिनट की जाँच को पूरी शाम बना देता है।

मान लें कि आप सर्वर में लॉग इन कर सकते हैं और क्लाइंट स्कैनर नहीं बल्कि असली प्रोफ़ाइल है। दोनों अनुमान मायने रखते हैं, क्योंकि सामान्य प्रोब प्रोटोकॉल-विशिष्ट सवाल का जवाब नहीं दे सकता।

क्या सॉकेट है ही

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

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

सॉकेट की सूची वह तथ्य है जिस पर बाकी जाँच टिकी है। केवल पोर्ट नहीं, स्थानीय पते का कॉलम पढ़ें, क्योंकि उसी कॉलम में लूपबैक बाइंड और गलत इंटरफ़ेस के बाइंड दिखते हैं। 127.0.0.1 पर मौजूद लिसनर पूरी तरह चल रहा है और फिर भी आपके लैपटॉप के लिए अदृश्य है।

सॉकेट किस पते और किस परिवार पर जवाब देता है

दो गलतियाँ क्लाइंट की ओर से एक जैसी दिखती हैं और ज़्यादातर "पहुँच से बाहर" रिपोर्टों की वजह हैं। लूपबैक पते से बँधा सर्वर कभी दूसरी मशीन से ट्रैफ़िक नहीं लेता, और केवल IPv4 पते से बँधा सर्वर उसी होस्ट के IPv6 पते पर डायल करने वाले क्लाइंट को कभी जवाब नहीं देता। नीति के बारे में कुछ भी मानने से पहले सॉकेट तालिका के पते की तुलना क्लाइंट के वास्तव में डायल किए जा रहे पते से अक्षर-दर-अक्षर करें।

सूची को एक पोर्ट तक सीमित रखना इसे पढ़ने योग्य बनाए रखता है जब होस्ट कई सेवाएँ चलाता है। sport फ़िल्टर पोर्ट को उस ट्रांसपोर्ट के साथ लेता है जिसे आप जाँच रहे हैं:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

प्रोटोकॉल कॉलम पूरा जवाब बदल देता है

सॉकेट तालिका पोर्ट के साथ-साथ प्रोटोकॉल पर भी कुंजीबद्ध है, और ये दो स्वतंत्र प्रविष्टियाँ हैं। 1194 पर TCP का जवाब देने वाली सेवा इस बारे में कुछ नहीं बताती कि UDP 1194 पर कुछ सुन रहा है या नहीं, और क्लाइंट हमेशा इनमें से केवल एक ही इस्तेमाल करेगा। पुष्टि करें कि सर्वर कॉन्फ़िगरेशन कौन-सा ट्रांसपोर्ट चुनता है और क्लाइंट प्रोफ़ाइल कौन-सा भेजता है, फिर ठीक उसी पंक्ति को खोजें।

UDP में दूसरा मोड़ है: बिना प्रमाणित प्रोब कोई त्रुटि नहीं है जिसका जवाब सेवा को देना पड़े। पोर्ट को चुप बताने वाला स्कैन सेवा की सतर्कता मापता है, उसकी उपलब्धता नहीं, इसलिए असली क्लाइंट और प्रोफ़ाइल से जाँचें।

एक प्रयास, देखने के तीन स्थान

अधिकृत क्लाइंट से ठीक एक प्रयास करें और समय सेकंड तक लिख लें। फिर उस अवधि के लिए तीन स्रोत पढ़ें: प्रदाता का नेटवर्क नियम या कंसोल, होस्ट के फ़ायरवॉल काउंटर या लॉग, और सेवा का अपना लॉग। एक बार ऐसा करना ही तीनों विवरणों को तुलनीय बनाता है, और जिसका टाइमस्टैम्प किसी ने दर्ज नहीं किया ऐसे प्रयास को दोहराने से कम खर्चीला है।

दोनों परिणाम उलटी दिशाओं में इशारा करते हैं। अगर कोई पैकेट होस्ट तक नहीं पहुँचा, तो रास्ता उसे गिरा रहा है और लिसनर अप्रासंगिक है। अगर पैकेट सॉकेट तक पहुँचा और सेवा ने उसे ठुकराया, तो रास्ता ठीक है और जवाब प्रोटोकॉल, क्रिप्टोग्राफ़ी या क्रेडेंशियल में है। जो सेवा पहले ही कनेक्शन स्वीकार कर चुकी है उसके लिए पोर्ट खोलना अगली जाँच को आसान नहीं, मुश्किल बनाता है।

नियम बदलने से पहले चरण का नाम दें

शुरू होने वाली बातचीत और विफल होने वाला प्रमाणीकरण एक ही विफलता हैं, और जब अग्रेषण अटकता है तब बनने वाला टनल बिल्कुल दूसरी है। पहले चरण का नाम देना मरम्मत को सँकरा रखता है: क्रेडेंशियल की समस्या फ़ायरवॉल नियम से नहीं ठीक होती, और डेटा-पथ की समस्या रीस्टार्ट से नहीं ठीक होती।

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