VPN द्वारे NAS पर्यंत पोहोचता नाही: पत्ता, परतीचा मार्ग की सेवा?
खाजगी बोगद्याला NAS पर्यंत मार्ग, उत्तरेचा मार्ग आणि परवानगी असलेली सेवा लागते। क्रेडेन्शियल बदलण्यापूर्वी तीनपैकी कोणती अयशस्वी झाली ते ठरवा।
बोगदे वर येतात, क्लायंटला पत्ता मिळतो, आणि NAS अजिबात उत्तर देत नाही। हे एकच लक्षण तीन असंबंधित बिघाड झाकते, आणि ते कोणत्या क्रमाने तपासता यावर दुरुस्तीला किती वेळ लागेल हे ठरते। पत्ता-निर्धारण प्रथम येते, कारण एक अतिव्यापी सबनेट तुमची विनंती अनोळखी उपकरणाकडे पाठवू शकते। परतीचा मार्ग दुसरा येतो, कारण उत्तराशिवाय येणारी विनंती बंद सेवेसारखीच दिसते। सेवा आणि परवानगी शेवटी येतात, आणि फक्त पहिल्या दोन सिद्ध झाल्यानंतर।
तीन बिघाड जे सर्व अगम्य म्हणून वाचले जातात
पत्ता निवड, परतीचे राउटिंग आणि सेवा अधिकृतता एकच दिसणारा संदेश देतात: काहीच होत नाही। त्यांचे पुरावे, जबाबदार आणि दुरुस्त्या वेगळ्या आहेत, त्यामुळे ते वेगळे करणे हेच संपूर्ण काम आहे। अयशस्वी ping स्वतः फारसे सिद्ध करत नाही, आणि यशस्वी TCP नकार ही खरंतर चांगली बातमी आहे।
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
तक्ता कारणांची यादी नव्हे तर तपासण्यांचा क्रम म्हणून वाचा। प्रत्येक ओळ पुढच्या ओळीला मर्यादित करते, कारण नकार आधीच सिद्ध करतो की पत्ता-निर्धारण आणि परतीचा मार्ग चालतात। राउटने कोणते इंटरफेस निवडले हे तपासण्यापूर्वी फायरवॉल नियमांमध्ये वीस मिनिटे घालवणे हा दुपार वाया घालवण्याचा सर्वात सामान्य मार्ग आहे। वरून खाली काम करा आणि पहिल्या जुळणाऱ्या ओळीवर थांबा।
अट एक: तो पत्ता योग्य उपकरण आहे का?
NAS चे सबनेट आणि VPN क्लायंटना देत असलेली श्रेणी लिहा, नंतर दोन्ही तुमचा लॅपटॉप सध्या ज्या नेटवर्कवर आहे त्याशी तुलना करा। या फेरीत NAS 10.40.7.25 वर आहे आणि VPN पूल 10.40.9.0/24 आहे, एका साइट योजनेत दोन वेगळ्या खाजगी श्रेणी; जे घर 192.168.0.0/24 किंवा 10.0.0.0/24 वापरते त्यांची त्यातल्या एकाशी टक्कर होण्याची शक्यता खूपच जास्त आहे।
जेव्हा स्थानिक नेटवर्क आणि NAS नेटवर्क अतिव्यापी होतात, तेव्हा क्लायंट तो रहदारी स्वतःच्या गेटवेवर पाठवतो आणि योगायोगाने तोच पत्ता असलेल्या असंबंधित उपकरणापर्यंत पोहोचू शकतो। उत्तर देणाऱ्या कोणत्याही गोष्टीत क्रेडेन्शियल लिहिण्यापूर्वी मार्ग पडताळा।
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25पहिला आदेश कर्नेल वापरेल ते इंटरफेस आणि गेटवे सांगतो, आणि दुसरा प्रत्यक्ष उत्तर देणारे पहिले हॉप दाखवतो। दोन्ही जुळत नसतील तर शोधावर विश्वास ठेवा, कारण पॅकेट याच मार्गाने जाईल। NAS च्या एक हॉप आधी थांबणारी हॉप-यादीही एक निष्कर्ष आहे, अपयश नाही। जो शोध बोगद्याऐवजी भौतिक अडॅप्टरवर सुटतो तो या टप्प्यावर तपासणी संपवतो।
अट दोन: उत्तर परत येते का?
क्लायंटला NAS कडे मार्ग हवा, आणि NAS नेटवर्कला VPN पूलकडे परतीचा मार्ग हवा। गेटवे फॉरवर्डिंग, फायरवॉल नियम आणि जाणूनबुजून केलेले भाषांतर प्रत्येकी त्या जोडीवर परिणाम करतात। strongSwan च्या फॉरवर्डिंगवरील टिपा गेटवेमागील खाजगी सबनेटसाठी परतीचा मार्ग आणि भाषांतराचे पर्याय वर्णन करतात।
जेव्हा विनंती येते आणि उत्तर दुसऱ्या गेटवेने बाहेर पडते, तेव्हा कोणताही DNS बदल ती विषमता दुरुस्त करत नाही। दोन्ही बाजूंनी कॅप्चर एका प्रयत्नात ते ठरवते, आणि भाषांतराने NAS ने उत्तर दिलेला स्रोत पुन्हा लिहिला का हेही दाखवते। प्रशासक या सीमेचा जबाबदार आहे: फक्त आवश्यक सेवा आणि VPN क्लायंट श्रेणीला परवानगी द्या, आणि राउटिंग निवडले की भाषांतर ते लिहा।
अट तीन: सेवा तिथे आहे आणि परवानगी आहे का?
व्यवस्थापन पृष्ठ आणि फाइल शेअरिंग सेवा एकाच मशीनवर वेगळे अंतिम बिंदू आहेत, आणि एक जोडण्या स्वीकारू शकते तर दुसरी होस्ट फायरवॉल, सेवा संरचना किंवा शेअर परवानगीने अडवली जाते। जे उपकरण नकार देऊन उत्तर देते त्याने पहिल्या दोन अटी आधीच सिद्ध केल्या आहेत, ज्यामुळे तिसरी बरीच अरुंद होते।
ज्या खात्याला खरोखर फाइलींची गरज आहे त्या खात्याने चाचणी करा, इन्स्टॉलच्या वेळी वापरलेल्या प्रशासक खात्याने नाही, कारण प्रशासकीय अधिकार गहाळ मार्ग दुरुस्त करू शकत नाहीत आणि मार्ग शेअर परवानगी देऊ शकत नाही। नावेही इथे येतात: घरी सापडलेले NAS नाव अनेकदा स्थानिक multicast वर अवलंबून असते, जे राउटेड बोगदा वाहून नेत नाही, म्हणून नावकरण प्रवेशापासून वेगळे करण्यासाठी उत्पादकाचे दस्तऐवजीकृत खाजगी होस्टनाव किंवा पत्ताच वापरून पहा।
NAS नेटवर्कबाहेरून चाचणी करा, नंतर हळूहळू वाढवा
त्याच LAN वर केलेली चाचणी दूरच्या मार्गाचा प्रत्येक अपूर्ण भाग लपवते, म्हणून पहिला यशस्वी दूरस्थ प्रयत्न बदल-नोंदीत नोंदीचा हक्कदार आहे। जो क्लायंट फक्त बोगद्यातून NAS पर्यंत पोहोचतो त्याच्याकडून तपासण्या चालवा, आणि प्रत्येक प्रयत्नाचा मूळ त्रुटी मजकूर जपून ठेवा।
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestमार्ग चालू झाल्यावर निरुपद्रवी फाइल हस्तांतरित करा आणि तुम्हाला खरोखर आवश्यक असलेले वाचन किंवा लेखन वर्तन पुष्टी करा। मोठी हस्तांतरणे अडकतात आणि लहान जातात असे असेल तर उरलेली समस्या पॅकेट आकाराची हाताळणी किंवा जोडणीची स्थिरता आहे, पत्ता-निर्धारण नाही।
अस्पष्ट बिघाड टाळण्यासाठी फाइल शेअरिंग किंवा व्यवस्थापनाचे पोर्ट इंटरनेटवर प्रकाशित करू नका। खाजगी मार्ग दुरुस्त करा, NAS सॉफ्टवेअर समर्थित ठेवा, आणि त्या बॅकअपवर अवलंबून राहण्यापूर्वी त्यातून घेतलेल्या प्रत्येक गोष्टीची पुनर्संचयिती तपासा।