Synology पर OpenVPN हैंडशेक विफल? LAN फ़ॉरवर्ड जाँचें

आपका लैपटॉप बताता है कि TLS हैंडशेक विफल हो गया, इसलिए प्रमाणपत्र फिर से बनाने का लोभ होता है। उससे पहले एक अधिक नीरस प्रश्न पूछें: Synology वास्तव में किस Ethernet पोर्ट पर सुन रहा है? दो LAN पोर्ट वाले NAS के दो पते होते हैं, और DSM का VPN Server पैकेज अपने OpenVPN श्रोता को उनमें से एक से बाँधता है। जब राउटर 1194 को दूसरे पते पर फ़ॉरवर्ड करता है, तो कोई पैकेट सेवा तक कभी नहीं पहुँचता, और क्लाइंट के पास बातचीत करने को कुछ नहीं होता।

त्रुटि का पाठ भ्रमित करता है, क्योंकि वह क्लाइंट द्वारा आख़िरी बार आज़माई गई बात बताता है, पहली गड़बड़ नहीं। पैकेज पृष्ठ की राउटर नियम से तुलना करने के दो मिनट इसे तय कर देते हैं।

वह पता खोजें जिससे श्रोता बँधा है

DSM अपने पोर्ट को LAN 1 और LAN 2 कहता है, और हर एक का अलग पता और सबनेट होता है। VPN Server खोलें, OpenVPN टैब पर बताया गया इंटरफ़ेस पढ़ें, फिर Control Panel खोलें और वह IPv4 पता लिख लें जो DSM के पास उसी इंटरफ़ेस पर है। फ़ॉरवर्ड को इन दो मानों का नाम देना है, NAS का होस्टनाम नहीं।

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

SSH से सॉकेट को ही देखें, क्योंकि यही एकमात्र जगह है जो दिखाती है कि डेमन वास्तव में किससे बँधा, न कि सेटिंग्स पृष्ठ का इरादा।

sudo netstat -anp | grep 1194

दूसरा जोड़ने के बजाय मौजूदा फ़ॉरवर्ड संपादित करें

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

external 1194/udp  ->  192.0.2.20:1194/udp

आंतरिक पोर्ट को सुनने वाले पोर्ट के बराबर रखें, और प्रोटोकॉल सुसंगत रखें। UDP 1194 डिफ़ॉल्ट श्रोता है, जबकि TCP प्रोफ़ाइल को पैकेज की ओर अपना श्रोता और राउटर पर मेल खाता फ़ॉरवर्ड चाहिए। केवल UDP पर सुनने वाली सेवा की ओर TCP फ़ॉरवर्ड करने से त्रुटि नहीं, मौन मिलता है।

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

साबित करें कि पैकेट पहुँचते भी हैं या नहीं

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

sudo tcpdump -i any -n udp port 1194

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

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

जब पैकेट पहुँचें, तो फ़ॉरवर्ड को दोष देना बंद करें

प्रोफ़ाइल अगला संदिग्ध है, और सामान्य कारण पुराना होना है। निर्यात की गई .ovpn फ़ाइल में निर्यात के क्षण का प्राधिकार और सामग्री होती है, इसलिए जिस पैकेज का प्रमाणपत्र बाद में बदला गया वह उस क्लाइंट को अस्वीकार करेगा जो अब भी पुरानी प्रति लिए है।

परिवहन वह दूसरी असंगति है जिसे स्पष्ट रूप से जाँचना चाहिए, क्योंकि प्रोफ़ाइल और पैकेज अलग-अलग जगहों पर संपादित होते हैं। पैकेज बदले बिना प्रोफ़ाइल को UDP से TCP करने पर क्लाइंट ऐसे श्रोता की प्रतीक्षा करता है जो मौजूद नहीं है, और क्लाइंट वही सामान्य हैंडशेक पाठ बताता है जो हर दूसरी बात के लिए बताता है। फ़ाइल में proto पंक्ति पढ़ें, फिर सर्वर पृष्ठ पर चुना गया प्रोटोकॉल देखें, और तभी निष्कर्ष निकालें कि वे मेल खाते हैं। DSM फ़ायरवॉल नियम पढ़ना तीसरी जाँच है: स्थानीय सबनेट से पोर्ट खोलने वाला पर इंटरनेट से न खोलने वाला नियम परीक्षण के बाद छोड़ देना आसान है, और वह ऐसा कनेक्शन देता है जो रसोई से काम करता है और बाक़ी हर जगह से विफल होता है।

दूरस्थ उपयोगकर्ता जो रास्ता वास्तव में लेता है उसे जाँचें

उसी LAN के भीतर का क्लाइंट फ़ॉरवर्ड को कभी छुए बिना NAS तक पहुँच सकता है, इसलिए यह दूरस्थ पहुँच के बारे में कुछ साबित नहीं करता। Wi-Fi बंद वाला फ़ोन इस्तेमाल करें, या नेटवर्क से बाहर किसी से पूछें, और उस प्रयास के दौरान राउटर काउंटर देखें। अगर दूरस्थ प्रयास विफल हो और स्थानीय सफल हो, तो फ़ॉरवर्ड या फ़ायरवॉल अब भी तस्वीर में है।

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