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-ന് പിന്നിലുള്ള ബന്ധമില്ലാത്ത ഉപയോക്താക്കളെയും വിച്ഛേദിച്ചേക്കാം, അതിനാൽ തീരുമാനം പങ്കിടൽ നിർവചനത്തിലും നിരീക്ഷണം പ്രതികരണ പ്രക്രിയയിലും വേണം. രണ്ടും വേർതിരിച്ച് നിർത്തുക, രൂപകൽപ്പന താൻ നടപ്പിലാക്കുന്നതിനെക്കുറിച്ച് സത്യസന്ധമായി തുടരും.