Samba ले सर्भरसम्म पुग्ने VPN क्लाइन्टहरूलाई किन अस्वीकार गर्छ

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

एउटै सन्देशसँग असफल हुने चार तह

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

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

smbd ले वास्तवमै देख्ने स्रोत ठेगाना पत्ता लगाउनुहोस्

राउट गरिएको पहुँचमा सर्भरले सामान्यतया VPN पूलबाट क्लाइन्टको ठेगाना देख्छ। गेटवेमा स्रोत अनुवाद भएमा यसले त्यसको सट्टा गेटवेको LAN ठेगाना देख्छ, र त्यो गेटवेपछाडिको प्रत्येक क्लाइन्ट छुट्याउन नसकिने हुन्छ।

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

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

अनुमति सूचीलाई Samba ले पढ्ने तरिकाले पढ्नुहोस्

hosts allow सेटिङले ठेगाना, नेटवर्क वा नामहरूको सूची लिन्छ, र यो विश्वव्यापी रूपमा वा साझेदारीभित्र हुन सक्छ। तपाईंलाई समान देखिने दुई प्रविष्टि पार्सरका लागि समान नहुन सक्छन्, त्यसैले प्रभावकारी कन्फिगरेसन नै जाँच्नुपर्ने चीज हो। यसको अर्थ एकीकृत दृश्य हो, तपाईंले संयोगवश सम्पादन गरेको फाइल होइन।

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

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

रिबुटपछि टिकिरहने फाइल परिवर्तन गर्नुहोस्

सामान्य Linux होस्टमा कन्फिगरेसन मार्ग निश्चित हुन्छ र पुनःसुरु गर्दा सेवाले त्यो फेरि पढ्छ। राउटर वा उपकरणमा चलिरहेको smb.conf प्रायः बुटमा उत्पन्न हुन्छ, र हातले गरेको सम्पादन अर्को रिबुटमा हराउँछ। उपकरणको समर्थित अनुकूलन विधि प्रयोग गर्नुहोस्, जुन सामान्यतया त्यसको आफ्नै कन्फिगरेसन फाइल हुन्छ।

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

तपाईंले कुन फाइल परिवर्तन गर्नुभयो र केले त्यसलाई फेरि बनाउँछ लेख्नुहोस्, ताकि अर्को व्यक्तिले निदान दोहोर्याउन नपरोस्।

एउटा अनुमति दिइएको र एउटा बहिष्कृत क्लाइन्ट परीक्षण गर्नुहोस्

दुवै नतिजाको परीक्षण गर्नुहोस्, तपाईंले चाहेको एउटाको मात्र होइन। जोडिने अनुमति दिइएको क्लाइन्टले परिवर्तन काम गर्छ भनी प्रमाणित गर्छ; अझै अस्वीकार हुने बहिष्कृत क्लाइन्टले नियमले भर्खर सबै खोलेको होइन भनी प्रमाणित गर्छ।

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

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