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 వెనుక ఉన్న సంబంధం లేని వినియోగదారులను కూడా డిస్కనెక్ట్ చేయవచ్చు, అందుకే నిర్ణయం భాగస్వామ్య నిర్వచనానికి మరియు పర్యవేక్షణ ప్రతిస్పందన ప్రక్రియకు చెందుతాయి. రెండింటినీ వేరుగా ఉంచండి, రూపకల్పన తాను అమలు చేసే దాని గురించి నిజాయితీగా ఉంటుంది.