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 लॉग शेयर पथ और खाता नाम उजागर कर सकता है। प्रति प्रयास एक परत बदलें, वरना अगला परिणाम आपको कुछ नहीं बताएगा।