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 પાછળના અસંબંધિત વપરાશકર્તાઓ પણ ડિસ્કનેક્ટ થઈ શકે, તેથી નિર્ણય શેર વ્યાખ્યામાં અને દેખરેખ પ્રતિક્રિયા પ્રક્રિયામાં રહેવો જોઈએ. બંનેને અલગ રાખો અને ડિઝાઇન જે લાગુ કરે છે તે વિશે પ્રામાણિક રહે છે.