दो LAN पोर्ट वाला Synology NAS: VPN हैंडशेक क्यों विफल होता है

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

क्लाइंट क्या बताता है और वास्तव में क्या हुआ

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

पोर्ट और बँधा हुआ पता वे दो तथ्य हैं जो तय करते हैं कि पैकेट कभी पहुँचेगा या नहीं।

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

वह पता खोजें जहाँ पैकेज सुनता है

DSM Ethernet पोर्टों को क्रमांक देता है और हर एक का अपना पता होता है। VPN Server पृष्ठ उस इंटरफ़ेस का नाम बताता है जिसका उपयोग OpenVPN सेवा करती है, और नेटवर्क पैनल उस इंटरफ़ेस पर कॉन्फ़िगर किया गया पता दिखाता है। इन्हें इसी क्रम में पढ़ें, सेवा से बाहर की ओर, ताकि आप वर्णन करें कि क्या सुन रहा है, न कि यह मानें कि उसे क्या उपयोग करना चाहिए।

सेवा एक पते को बाँधती है। दोनों पोर्ट जुड़े और सक्रिय होने से सेवा दूसरे पर उत्तर नहीं देती। एक इंटरफ़ेस पर स्थिर पता और दूसरे पर DHCP पता आपको दो समान मान देता है जिन्हें एक नज़र में बदलना आसान है, खासकर जब वे केवल अंतिम ऑक्टेट में भिन्न हों। पता पैनल से कॉपी करें, स्मृति से टाइप न करें। फिर NAS पर पुष्टि करें कि पोर्ट से वास्तव में क्या बँधा है।

sudo ss -lunp | grep 1194

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

फ़ॉरवर्ड ठीक करें, फिर काउंटर देखें

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

यदि DSM वह पता DHCP से लेता है, तो पहले आरक्षण बनाएँ। लीज़ बदलने से कल काम करने वाला फ़ॉरवर्ड चुपचाप टूट जाता है।

sudo tcpdump -i any -n udp port 1194

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

तभी प्रमाणपत्र और ट्रांसपोर्ट देखें

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

अंतिम चरण के रूप में अपने नेटवर्क के बाहर से परीक्षण करें, क्योंकि LAN के भीतर से कनेक्शन ऐसे रास्ते से सफल हो सकता है जो फ़ॉरवर्ड को छूता ही नहीं।

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