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 सॉफ़्टवेयर समर्थित रखें, और उस बैकअप पर भरोसा करने से पहले उसके ज़रिए लिए गए हर बैकअप की पुनर्स्थापना जाँचें।