રાઉટર SMB ક્લાયન્ટ કે પેકેટ ફોરવર્ડર: કઈ ભૂમિકા યોગ્ય છે

SMB ટ્રાફિક ફોરવર્ડ કરવો અને તેને સમાપ્ત કરવો એ એક જ કામ નથી, અને એક કરતું રાઉટર બીજું સંભાળી ન શકે. ફોરવર્ડ એટલે રાઉટર એવા પેકેટ ખસેડે છે જેની સામગ્રી તે ક્યારેય પૃથ્થકરણ કરતું નથી. માઉન્ટ એટલે રાઉટર ફાઇલ ક્લાયન્ટ બને છે, એવા સોફ્ટવેર સાથે જે તેની સાથે ન આવે, એવા ક્રેડેન્શિયલ સાથે જેને તેણે રક્ષવા પડે અને એવી નિષ્ફળતાની રીતો સાથે જે હવે તેની છે. બેમાંથી પસંદગી એ પ્રશ્ન છે કે ફાઇલો ક્યાં જરૂરી છે, એ નહીં કે રાઉટિંગ પ્લેટફોર્મને શું ઇન્સ્ટોલ કરવા મનાવી શકાય.

ફોરવર્ડ કરવું અને સમાપ્ત કરવું અલગ કામ છે

ફોરવર્ડની ભૂમિકામાં રાઉટરની એક જવાબદારી છે: માર્ગને જે નીતિ જોઈએ તે લાગુ કરીને ક્લાયન્ટ અને સર્વર વચ્ચે પેકેટ પહોંચાડવા. તે શેર પર પ્રમાણીકરણ કરતું નથી, ફાઇલ ડેટા કૅશ કરતું નથી અને સર્વર SMB2 બોલે છે કે SMB3 તેની ચિંતા કરતું નથી, કારણ કે તે પ્રવાહમાં ક્યારેય એટલું ઊંડું વાંચતું નથી. શેર પહોંચની બહાર જાય તો વપરાશકર્તાને ભૂલ દેખાય છે અને રાઉટર રાઉટિંગ ચાલુ રાખે છે.

ક્લાયન્ટની ભૂમિકામાં રાઉટર પ્રોટોકોલની વાતચીતમાં જોડાય છે. તે ડાયલેક્ટ પર વાટાઘાટ કરે છે, પ્રમાણીકરણ કરે છે, નામ ઉકેલે છે, માઉન્ટ પોઇન્ટ રાખે છે અને તેની ઉપર ચાલતી દરેક વસ્તુને સ્થાનિક ફાઇલસિસ્ટમનું દૃશ્ય બતાવે છે. આ જીવનચક્ર ધરાવતી સાચી સેવા છે, અને તે ગેટવેને ફાઇલ કાર્યપ્રવાહની અવલંબન બનાવે છે. તે તે અવલંબનની દરેક નિષ્ફળતાની રીત પણ વારસામાં લે છે, જેમાં બૂટ વખતની રાહ અને જૂનાં ક્રેડેન્શિયલનો સમાવેશ થાય છે.

સરખામણી ફક્ત ક્ષમતાની નથી. શેર માઉન્ટ કરી શકતું પ્લેટફોર્મ આપોઆપ એવું પ્લેટફોર્મ નથી જેને તે કરવું જોઈએ, અને જે પ્લેટફોર્મ એક પણ માઉન્ટ કરી શકતું નથી તે કદાચ ટ્રાફિક રાઉટ કરવા માટે હજી યોગ્ય જગ્યા હોઈ શકે.

કર્નલ CIFS માઉન્ટને ખરેખર શું જોઈએ

Linux આધારિત ઉપકરણ પર કર્નલ CIFS ક્લાયન્ટ અને યુઝરસ્પેસ ક્લાયન્ટ અલગ ક્ષમતાઓ છે, અને નાની ઇમેજમાં ઘણી વાર બંનેમાંથી એક પણ નથી હોતી. ચાલતી ઇમેજમાં કર્નલ સપોર્ટ હોવો જોઈએ, માઉન્ટ સહાયક અસ્તિત્વમાં હોવો જોઈએ, અને સર્વર સાથે વાટાઘાટ થયેલો SMB ડાયલેક્ટ એવો હોવો જોઈએ જે બંને પક્ષ સ્વીકારે. તેનું વર્ણન Linux CIFS ક્લાયન્ટ માર્ગદર્શિકા કરે છે, જે કર્નલની ગોઠવણી અને તેના માઉન્ટ વિકલ્પો સમજાવે છે, અને વેન્ડર બિલ્ડમાં તે છે એમ ધારવા પહેલાં આ જ યોગ્ય સંદર્ભ છે.

ક્ષમતાની આસપાસ ડિઝાઇન કરતાં પહેલાં તે તપાસો, અને આદેશના નામની હાજરી નહીં, આવૃત્તિ તપાસો. પેકેજ યાદીમાં મોડ્યુલનું નામ અને કામ કરતું ક્લાયન્ટ એક નથી.

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

લોડ થતું કર્નલ મોડ્યુલ અને આવૃત્તિ જણાવતું યુઝરલેન્ડ સાધન હજી પણ ખાતરી આપતાં નથી કે માઉન્ટ VPN કી નવીકરણમાંથી પસાર થશે, તેથી પરીક્ષણને પુરાવો નહીં, શરૂઆતની શરત ગણો. ઇમેજ ફક્ત SMB1 સપોર્ટ આપે તો તે સર્વર પર ચાલુ કરવાનું કારણ નહીં, અટકવાનું કારણ છે.

ક્રેડેન્શિયલ અને સ્રોત ઓળખ લેપટોપ કરતાં અલગ છે

ફોરવર્ડ થયેલી વિનંતી લેપટોપની ઓળખ સુરંગમાંથી લઈ જાય છે, જ્યારે રાઉટર પર બનેલી વિનંતી રાઉટરનું પોતાનું સ્રોત સરનામું, રિઝોલ્વર માર્ગ અને આઉટપુટ ફિલ્ટરિંગ લઈ જાય છે. એ અલગ ફાયરવોલ નિયમમાં, અલગ DNS દૃશ્યમાં અને સર્વર બાજુની અલગ પરવાનગી યાદીમાં પહોંચી શકે છે. તેથી વર્કસ્ટેશન પરથી ચાલતી નકલ રાઉટરની પોતાની માઉન્ટ વિશે કંઈ સાબિત કરતી નથી. માઉન્ટને રાઉટરની પોતાની શેલ પરથી ચકાસો, તેની પાછળની વર્કસ્ટેશન પરથી નહીં.

ભૂમિકા જો બિલકુલ મંજૂર હોય તો રાઉટરને સાંકડી સત્તાવાળી સેવા ઓળખ આપો. પાસવર્ડ ક્યારેય સીધો માઉન્ટ આદેશ લાઇનમાં ન મૂકો, કારણ કે તે શેલ ઇતિહાસમાં રહે છે અને માઉન્ટ ચાલતું હોય ત્યારે પ્રોસેસ કોષ્ટકમાં દેખાય છે.

પ્લેટફોર્મની સુરક્ષિત પદ્ધતિ દ્વારા ક્રેડેન્શિયલ સંગ્રહો અને મર્યાદિત પરવાનગીવાળી ફાઇલમાંથી તેને વાંચો. માઉન્ટ ચલાવતા ખાતા સિવાયનાં દરેક ખાતા માટે તે ફાઇલ અવાંચ્ય હોવી જોઈએ.

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

શેર અદૃશ્ય થાય ત્યારે નિષ્ફળતા કોની

ગેરહાજર દૂરસ્થ ફાઇલસિસ્ટમ ગેરહાજર માર્ગ કરતાં જુદી રીતે વર્તે છે. માઉન્ટ તેને સ્પર્શતી પ્રક્રિયાઓને અવરોધી શકે છે, સુરંગ બનતા પહેલાં બૂટ વખતે નિષ્ફળ જઈ શકે છે, અને સર્વર માટેનું લેખન ખોટી જગ્યાએ પડી શકે છે જો માઉન્ટ પોઇન્ટ નીચે સ્થાનિક ડિરેક્ટરી હોય. આ હવે નેટવર્ક ટીમની માલિકીની સંગ્રહ નિષ્ફળતાઓ છે, ટીમને એ જોઈતી હતી કે નહીં. કોઈએ એ માલિકી સ્વીકારી નહીં, પણ તે માઉન્ટ સાથે આવે છે.

બૂટ ક્રમ અને માઉન્ટ વિકલ્પો એ વાસ્તવિકતાની આસપાસ ડિઝાઇન કરો. ટૂંકી સમયમર્યાદા અને દસ્તાવેજી પુનઃપ્રાપ્તિ પગલાવાળું ફક્ત-વાંચવાનું માઉન્ટ, બાકીનું બધું જેના પર આધાર રાખે છે તેવા લખી શકાય તેવા માઉન્ટ કરતાં બચાવવું સહેલું છે. કંઈ પણ માઉન્ટ કરવાનો પ્રયાસ કરે તે પહેલાં સુરંગ ઉપર આવે છે તેની ખાતરી કરો, નહીં તો વીજ કપાત પછીનું પ્રથમ બૂટ અટકી જશે.

મોટા પાયે ફાઇલ પ્રોસેસિંગ માટે, અથવા ડેટાને આગળ ફરી નિકાસ કરતી કોઈપણ વસ્તુ માટે, અલગ હોસ્ટ સામાન્ય રીતે વધુ સ્પષ્ટ માલિકી સીમા આપે છે. રાઉટર રાઉટિંગ ચાલુ રાખે છે, અને ફાઇલ કાર્યપ્રવાહને નેટવર્ક સાથે ન લઈ જતાં ફરી ચાલુ કરી શકાય તેવું મશીન મળે છે.

નિર્ણયને વાસ્તવિક કાર્ય સામે ચકાસો

કઈ ફાઇલો કયા કાર્યને જરૂરી છે અને તે કાર્ય ક્યાં ચાલે છે તે લખો. જવાબ વર્કસ્ટેશન હોય તો, શેરને રાઉટ કરો અને ત્યાં જ અટકો. જવાબ ઉપકરણ પરની સેવા હોય તો, પ્રથમ માઉન્ટ પહેલાં ક્લાયન્ટ ક્ષમતા, સમર્થિત ડાયલેક્ટ અને ક્રેડેન્શિયલનો માર્ગ ચકાસો, પછી નક્કી કરો કે ઉપકરણ ખરેખર યોગ્ય હોસ્ટ છે કે નહીં.

માઉન્ટ થયેલું દૃશ્ય અને ખાલી જગ્યા રાઉટર પોતાના પરથી ચકાસો, કારણ કે કાર્યભાર ત્યાં જ તે જોશે. ફરી જોડાયા પછી ચકાસણીનું પુનરાવર્તન કરો, ફક્ત સ્વચ્છ બૂટ પછી નહીં.

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

ફાઇલોની યાદી બતાવતું પણ ભરેલી કે ફક્ત-વાંચવાની ફાઇલસિસ્ટમ જણાવતું માઉન્ટ તમને પહેલેથી કહી દીધું છે કે રાત્રે 2 વાગ્યે તમને કઈ નિષ્ફળતા મળશે. પુનઃપ્રાપ્તિ માર્ગ પણ ચકાસો: સ્વચ્છ રીતે અનમાઉન્ટ કરો, સુરંગ નીચે ઉતારો, ફરી ઉપર લાવો અને ઉપકરણ રીબૂટ કર્યા વિના ફરી માઉન્ટ કરો. જો એ ક્રમને દર વખતે સપોર્ટ કેસની જરૂર પડે, તો ક્લાયન્ટ ભૂમિકા માટે રાઉટર ખોટી જગ્યા છે.