സർവറിലേക്ക് എത്തുന്ന VPN ക്ലയന്റുകളെ Samba എന്തുകൊണ്ട് നിരസിക്കുന്നു

ഒരു 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 ലോഗ് ഷെയർ പാത്തുകളും അക്കൗണ്ട് പേരുകളും വെളിപ്പെടുത്തിയേക്കാം. ഓരോ ശ്രമത്തിലും ഒരു പാളി മാറ്റുക, അല്ലെങ്കിൽ അടുത്ത ഫലം നിങ്ങളോട് ഒന്നും പറയില്ല.