राउटर SMB क्लाइंट या पैकेट फ़ॉरवर्डर: कौन सी भूमिका उपयुक्त है

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

आगे भेजना और समाप्त करना अलग काम हैं

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

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

तुलना केवल क्षमता की नहीं है। जो प्लेटफ़ॉर्म शेयर माउंट कर सकता है वह अपने आप वह प्लेटफ़ॉर्म नहीं है जिसे ऐसा करना चाहिए, और जो प्लेटफ़ॉर्म एक भी माउंट नहीं कर सकता वह शायद फिर भी ट्रैफ़िक राउट करने की सही जगह हो।

कर्नेल CIFS माउंट को वास्तव में क्या चाहिए

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

क्षमता के इर्द-गिर्द डिज़ाइन करने से पहले उसे जाँचें, और कमांड नाम की मौजूदगी नहीं, संस्करण जाँचें। पैकेज सूची में मॉड्यूल का नाम और काम करने वाला क्लाइंट एक बात नहीं है।

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

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

क्रेडेंशियल और स्रोत पहचान लैपटॉप से अलग होती है

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

अगर भूमिका स्वीकृत है तो राउटर को संकीर्ण अधिकार वाली सेवा पहचान दें। पासवर्ड कभी सीधे माउंट कमांड लाइन में न रखें, क्योंकि वह शेल इतिहास में रह जाता है और माउंट चलने के दौरान प्रोसेस तालिका में दिखता है।

क्रेडेंशियल को प्लेटफ़ॉर्म की सुरक्षित व्यवस्था से संग्रहित करें और सीमित अनुमतियों वाली फ़ाइल से पढ़ें। वह फ़ाइल माउंट चलाने वाले खाते के अलावा किसी भी खाते के लिए अपठनीय होनी चाहिए।

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

शेयर गायब होने पर विफलता किसकी है

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

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

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

निर्णय को वास्तविक कार्य के सामने जाँचें

लिखें कि किस कार्य को फ़ाइलें चाहिए और वह कार्य कहाँ चलता है। अगर उत्तर वर्कस्टेशन है, शेयर को राउट करें और वहीं रुकें। अगर उत्तर उपकरण पर चलने वाली सेवा है, तो पहले माउंट से पहले क्लाइंट क्षमता, समर्थित डायलेक्ट और क्रेडेंशियल का पथ पुष्टि करें, फिर तय करें कि उपकरण वास्तव में सही होस्ट है या नहीं।

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

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

जो माउंट फ़ाइलें सूचीबद्ध करता है पर भरा हुआ या केवल-पढ़ने योग्य फ़ाइलसिस्टम बताता है, वह पहले ही बता चुका है कि रात 2 बजे आपको कौन सी विफलता मिलेगी। पुनर्प्राप्ति पथ भी पुष्टि करें: साफ़ तरीके से अनमाउंट करें, सुरंग नीचे उतारें, फिर ऊपर लाएँ और उपकरण रीबूट किए बिना दोबारा माउंट करें। अगर उस क्रम को हर बार सहायता मामला चाहिए, तो क्लाइंट भूमिका के लिए राउटर गलत जगह है।