సర్వర్ను చేరుకునే VPN క్లయింట్లను Samba ఎందుకు తిరస్కరిస్తుంది
VPN క్లయింట్ Samba సర్వర్ను చేరుకోగలదు, అయినా hosts allow ద్వారా తిరస్కరించబడవచ్చు. సవరించే ముందు smbd చూసే మూలం మరియు షేర్ స్థాయి విధానాన్ని తనిఖీ చేయండి.
VPN క్లయింట్ ఫైల్ సర్వర్కు ping చేస్తుంది, దాని పేరును పరిష్కరిస్తుంది, అయినా షేర్ తెరవలేదు. 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 లాగ్ షేర్ మార్గాలు మరియు ఖాతా పేర్లను బహిర్గతం చేయగలదు. ప్రతి ప్రయత్నానికి ఒక పొరను మార్చండి, లేకపోతే తదుపరి ఫలితం మీకు ఏమీ చెప్పదు.