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 बजे तपाईंलाई कुन विफलता भेटिन्छ भनी पहिल्यै भनिसकेको छ। पुनःप्राप्ति मार्ग पनि पुष्टि गर्नुहोस्: सफासँग अनमाउन्ट गर्नुहोस्, सुरुङ तल झार्नुहोस्, फेरि माथि ल्याउनुहोस् र यन्त्र रिबुट नगरी फेरि माउन्ट गर्नुहोस्। यदि त्यो क्रमलाई हरेक पटक सहयोग केस चाहिन्छ भने, क्लाइन्ट भूमिकाका लागि राउटर गलत ठाउँ हो।