Synology वर OpenVPN हँडशेक अयशस्वी? LAN फॉरवर्ड तपासा

तुमचा लॅपटॉप TLS हँडशेक अयशस्वी झाला असे सांगतो, त्यामुळे प्रमाणपत्रे पुन्हा तयार करण्याचा मोह होतो। त्याआधी अधिक कंटाळवाणा प्रश्न विचारा: Synology प्रत्यक्षात कोणत्या Ethernet पोर्टवर ऐकत आहे? दोन LAN पोर्ट असलेल्या NAS ला दोन पत्ते असतात, आणि DSM मधील VPN Server पॅकेज आपल्या OpenVPN श्रोत्याला त्यापैकी एकाला बांधते। राउटरने 1194 दुसऱ्या पत्त्यावर फॉरवर्ड केल्यास कोणतेही पॅकेट सेवेपर्यंत पोहोचत नाही, आणि क्लायंटकडे वाटाघाटी करण्यासाठी काहीही नसते।

त्रुटीचा मजकूर गोंधळवतो, कारण तो क्लायंटने शेवटी काय प्रयत्न केले याचे वर्णन करतो, सुरुवातीला काय बिघडले याचे नाही। पॅकेज पृष्ठाची राउटर नियमाशी तुलना करण्यासाठी दोन मिनिटे पुरतात।

श्रोता बांधलेला पत्ता शोधा

DSM आपल्या पोर्टना LAN 1 आणि LAN 2 म्हणते, आणि प्रत्येकाला स्वतंत्र पत्ता व सबनेट असते। VPN Server उघडा, OpenVPN टॅबवर नमूद केलेला इंटरफेस वाचा, नंतर Control Panel उघडून DSM कडे त्याच इंटरफेसवर असलेला IPv4 पत्ता लिहून घ्या। फॉरवर्डने 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 बंद असलेला फोन वापरा, किंवा नेटवर्कबाहेरील एखाद्याला विचारा, आणि त्या प्रयत्नादरम्यान राउटर काउंटर पहा। दूरस्थ प्रयत्न अयशस्वी होऊन स्थानिक यशस्वी झाल्यास, फॉरवर्ड किंवा फायरवॉल अजूनही चित्रात आहे।

जे काम करत आहे ते काम करत असतानाच नोंदवा: बाह्य पोर्ट, अंतर्गत पत्ता, प्रोटोकॉल, पॅकेज इंटरफेस, आणि प्रोफाइलचे नाव व निर्यात तारीख। हँडशेक पुन्हा अयशस्वी झाल्यास, ती नोंद आणि सध्याच्या संरचनेतील फरक हाच दोष आहे, आणि सेवा दोनपैकी कोणता पोर्ट वापरते हे कोणालाही पुन्हा शोधावे लागत नाही।