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 वाजता तुम्हाला कोणती अयशस्वीता भेटेल हे आधीच सांगितले आहे। पुनर्प्राप्ती मार्गही तपासा: स्वच्छ अनमाउंट करा, बोगदा खाली घ्या, पुन्हा वर आणा आणि उपकरण रीबूट न करता पुन्हा माउंट करा। जर त्या क्रमाला दरवेळी सहाय्य प्रकरण लागत असेल, तर क्लायंट भूमिकेसाठी राउटर चुकीची जागा आहे।