Samba शेयरलाई एक प्रयोगकर्ता र एक VPN ठेगानामा सीमित गर्नुहोस्

यो डिजाइनमा दुई फरक अनुमतिहरू मिसिन्छन्: कसले निर्देशिका प्रयोग गर्न सक्छ, र कुन ठेगानाहरू जोडिन सक्छन्। स्रोत सूचीको छेउमा खाता सूची लेख्नु जोडी जस्तो लाग्छ, तर Samba दुवै सूचीलाई स्वतन्त्र सर्तका रूपमा मूल्याङ्कन गर्छ। दुवै पूरा गर्ने जो कोही स्वीकार गरिन्छ, र यो अधिकांश प्रशासकले चाहेको भन्दा फराकिलो नियम हो। समाधान या त फरक शेयर संरचना हो वा जोडी व्यक्त गर्न सक्ने नीति तह हो।

भ्रम: दुई सूचीले एउटा नियम बनाउँछन्

smb.conf सन्दर्भ ले valid users र hosts allow लाई दुई असम्बन्धित प्यारामिटरका रूपमा परिभाषित गर्छ, र एउटै शेयरमा दुवै सेट गर्दा भ्रम सुरु हुन्छ। valid users = mira, tomas र hosts allow = 10.77.0.21, 10.77.0.22 सेट गर्नुहोस्, र चार संयोजन स्वीकार गरिन्छ: मीरा कुनै पनि ठेगानाबाट, टोमस कुनै पनि ठेगानाबाट। कन्फिगरेसनमा केहीले पहिलो नामलाई पहिलो ठेगानासँग बाँध्दैन, र नामहरू आउने क्रमको कुनै अर्थ छैन। तिनीहरूलाई पुनः क्रमबद्ध गर्नु, दोस्रो hosts allow लाइन थप्नु वा प्रत्येक लाइनमा एउटा नाम राख्नु केही पनि बदल्दैन। नतिजा दुई सूचीको गुणनफल हो, तिनीहरूबीचको म्यापिङ होइन।

अधिकांश मानिसहरूले वास्तवमा चाहने कुरा साँघुरो छ: मीरा एउटा ठेगानाबाट मात्र, टोमस अर्कोबाट मात्र। एउटा शेयर परिभाषामा त्यो बाँधाइको लागि वाक्यरचना छैन, र कुनै चतुर क्रमले त्यो बनाउँदैन। यो Samba ले एउटा शेयरभित्र व्यक्त नगर्ने नीतिको स्वरूप हो, र त्यहीँ भ्रम जीवित रहन्छ।

Samba ले के र कुन क्रममा मूल्याङ्कन गर्छ

चरणहरू निश्चित क्रममा चल्छन्, र क्रम गल्ती हुँदा गलत निदान आउँछ। क्लाइन्टले जडान खोल्छ; कन्फिगर गरिएको भए विश्वव्यापी होस्ट जाँच चल्छ; सत्र सेटअपले खाता प्रमाणित गर्छ; त्यसपछि क्लाइन्ट एउटा शेयरसँग जोडिन्छ, जहाँ त्यो शेयरको आफ्नै होस्ट सूची, valid users र पढ्ने-मात्र सेटिङ लागू हुन्छ; र फाइल खोल्दा मात्र प्रमाणित पहिचानको फाइलसिस्टम अनुमतिले निर्णय गर्छ। प्रत्येक चरणले आफैं अनुरोध अस्वीकार गर्न सक्छ, र एउटा पार गर्नु अर्कोबारे केही भन्दैन। महत्त्वपूर्ण परिणाम यो हो कि शेयरको होस्ट सूची मूल्याङ्कन हुँदासम्म खाता पहिले नै थाहा हुन्छ, र होस्ट सूचीसँग त्यो खाताको नाम लिने बाटो अझै छैन।

यही कारणले एउटा शेयरले एक प्रयोगकर्तालाई एक ठेगानासँग बाँध्न सक्दैन: hosts allow र valid users एउटै रूख-जडान चरणमा लागू हुने छुट्टाछुट्टै सर्त हुन्, र प्रत्येकले आफ्नै प्रश्नको उत्तर दिन्छ। होस्ट सर्तले कहिल्यै खाताको नाम इनपुटका रूपमा लिँदैन, त्यसैले यो प्रत्येक प्रयोगकर्ताका लागि लेख्न सकिँदैन। जोडी दोस्रो शेयर वा Samba बाहिरको नीति तहले मात्र व्यक्त गर्न सक्छ।

विश्वव्यापी मानहरू वंशानुगत हुने तरिकाका कारण महत्त्वपूर्ण छन्। hosts allow छोड्ने शेयरले विश्वव्यापी मान पाउँछ, र आफ्नै सेट गर्ने शेयरले त्यो मान विश्वव्यापीको सट्टा प्रयोग गर्छ, थपका रूपमा होइन। त्यसैले फराकिलो विश्वव्यापी सूचीले प्यारामिटर कहिल्यै सेट नगर्ने शेयरहरूलाई फराकिलो बनाउँछ, र आफ्नै परिभाषित गर्ने शेयरमा केही गर्दैन। testparm -s चलाउनुहोस् र यसले छाप्ने प्रत्येक शेयरको मान पढ्नुहोस्, किनकि त्यही आउटपुट प्रभावकारी नीति हो, डिस्कमा रहेको फाइल होइन।

एउटा शेयर साँघुरो गर्नाले बाँकी सर्भरमा केही गर्दैन। अन्य शेयर, प्रिन्टर लाइन र IPC जडानले आफ्नै नियम राख्छन्, त्यसैले एउटा शेयरको ठेगाना सूचीमा भर पर्ने डिजाइनले होस्ट होइन, एउटा मार्ग सुरक्षित गर्छ।

एउटा निर्देशिकामा दुई शेयर नाम

जब एउटै निर्देशिका दुई जनाका लागि दुई ठेगानाबाट पहुँचयोग्य हुनुपर्छ, तब यसलाई फरक नाममा दुई पटक खोल्नुहोस्। प्रत्येक ब्लकले एउटा खाता र एउटा स्रोत बोक्छ, जसले जोडीलाई कन्फिगरेसनले लागू गर्न सक्ने कुरा बनाउँछ। मूल्य यो हो कि प्रत्येक व्यक्तिले एउटै फाइलहरूमा पुग्न फरक शेयर नाम प्रयोग गर्छ, र त्यो क्लाइन्ट पक्षमा जानाजान गरिएको परिवर्तन हुनुपर्छ।

[shared-mira]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = mira
    hosts allow = 10.77.0.21
    hosts deny = ALL

[shared-tomas]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = tomas
    hosts allow = 10.77.0.22
    hosts deny = ALL

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

दुवै ब्लक एउटै मार्गतिर देखाउँछन्, त्यसैले निर्देशिकामा परिवर्तनले दुवै शेयरलाई असर गर्छ। सामान्यतया यही उद्देश्य हो, तर यसको अर्थ अनुमतिको गल्ती दुवै प्रयोगकर्तालाई एकैचोटि देखिन्छ भन्ने पनि हो।

स्रोत ठेगानाले के प्रमाणित गर्न सक्छ

Samba ले देख्ने ठेगाना सर्भरसम्म पुगेको ठेगाना हो, क्लाइन्टले आफूसँग छ भनी ठान्ने ठेगाना होइन। प्रत्येक क्लाइन्टलाई एउटै स्रोत ठेगानामा अनुवाद गर्ने VPN गेटवेले त्यो भिन्नता मेटाउँछ: सबै क्लाइन्ट एउटै होस्टका रूपमा आउँछन् र स्रोत सूचीले अब तिनीहरूलाई छुट्याउन सक्दैन। प्रत्येक क्लाइन्टको स्थिर बाँडफाँट र स्रोत जोगाउने गेटवे ठेगानालाई नीतिका रूपमा प्रयोग गर्ने पूर्वसर्त हुन्। दुवै नभए सीमाले प्रयोगकर्तालाई होइन, गेटवेलाई नाप्छ।

तैपनि, ठेगाना उपकरण होइन। एउटा सुरुङ ठेगानापछाडि दुई ल्यापटप, पुनः बाँडिएको लिज र साझा कार्यस्थल सबैले स्रोतले व्यक्ति चिन्छ भन्ने अनुमानलाई खण्डन गर्छन्। सीमालाई सञ्जाल क्षेत्रका रूपमा लिनुहोस् र प्रमाणित SMB खाताहरूलाई पहिचान तहका रूपमा राख्नुहोस्, उपकरण अनुमति चाहिएमा प्रमाणपत्र जस्ता उपकरण प्रमाणसहित।

यही कारणले डिजाइनले सर्भर होइन, शेयरहरूमा ढोका लगाउँछ। अस्वीकृत जोडीले अझै सत्र खोल्न, अर्को शेयरमा पुग्न वा सर्भर सूचीबद्ध गर्न सक्छ, जो जडानको समयमा प्रमाणीकरण असफलताभन्दा फरक नतिजा हो। यदि आवश्यकता प्रमाणीकरणअघि अस्वीकृति हो भने, Samba का शेयर प्यारामिटरहरू गलत साधन हुन्।

क्रस जोडीहरूले प्रमाणित गर्नुहोस्

कन्फिगरेसन प्रमाणित गर्नुहोस्, त्यसपछि चारै संयोजन पुनः प्रयोग गरिएको सत्रको सट्टा नयाँ जडानहरूले परीक्षण गर्नुहोस्। इच्छित जोडी निर्देशिकासम्म पुग्नुपर्छ, र दुवै क्रस जोडी असफल हुनुपर्छ। अघिल्लो परीक्षणको क्यास गरिएको सत्रले गलत संयोजनका लागि खुसीसाथ जवाफ दिन्छ र भाँचिएको नियमलाई सही देखाउँछ।

testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares

वाक्यरचना जाँचले फाइल पार्स हुन्छ भन्ने मात्र प्रमाणित गर्छ। प्रमाणहरू, ACL र होस्ट निर्णय वास्तविक जडानले परीक्षण गरिन्छ, त्यसैले जुन ठेगाना परीक्षण गर्न चाहनुहुन्छ त्यहीँबाट क्लाइन्ट आदेश चलाउनुहोस् र कुन चरणले अस्वीकार गर्छ हेर्नुहोस्। क्रस जोडी सफल भएमा प्रभावकारी होस्ट सूची ब्लकले संकेत गरेभन्दा फराकिलो छ, र testparm -s पहिलो पढ्नुपर्ने कुरा हो। क्रस जोडी गलत कारणले असफल भएमा शंकास्पद खाता वा ACL हो।

smbstatus प्रयोग गरी सत्रहरू अनुगमन गर्नु र तिनलाई बन्द गर्नु पहुँच सुरु भएपछिको प्रतिक्रिया हो, पहुँच नियन्त्रण होइन। पूरै अवलोकन गरिएको ठेगाना अवरुद्ध गर्नाले त्यही NAT पछाडिका असम्बन्धित प्रयोगकर्ताहरू पनि विच्छेद हुन सक्छन्, त्यसैले निर्णय शेयर परिभाषामा र अनुगमन प्रतिक्रिया प्रक्रियामा रहनुपर्छ। दुवैलाई छुट्टै राख्नुहोस् र डिजाइनले आफूले लागू गर्ने कुरामा इमानदार रहन्छ।