Samba સર્વર સુધી પહોંચતા VPN ક્લાયન્ટ્સને કેમ નકારે છે

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