VPN પર NFS clientaddr: ગૌણ આવૃત્તિ પ્રમાણે નિર્ણય લો, ટેવ પ્રમાણે નહીં
clientaddr ફક્ત NFSv4.0 માટે કૉલબૅક સરનામું જાહેર કરે છે. વાટાઘાટ થયેલી ગૌણ આવૃત્તિ વાંચો, પરત માર્ગ તપાસો અને તેને માઉન્ટ નિષ્ફળતાઓથી અલગ કરો.
clientaddr એ એવા માઉન્ટ વિકલ્પોમાંનો એક છે જેનું કારણ ગાયબ થયાના ઘણા સમય પછી પણ કમાન્ડ લાઇનમાં કૉપી થાય છે. તે NFSv4.0 સર્વરને કહે છે કે ક્લાયન્ટને ક્યાં પાછો બોલાવવો. તે સર્વર પસંદ કરતું નથી, દરેક વિનંતીને સ્રોત સરનામા સાથે બાંધતું નથી અને ટ્રાફિકને ટનલમાં ધકેલતું નથી. ઘણા સરનામાં ધરાવતા લૅપટૉપ પર, તે બિલકુલ લાગુ પડે છે કે કેમ તે નક્કી કરવા ત્રણ પ્રશ્નો જરૂરી છે.
ત્રણ શરતો નક્કી કરે છે કે વિકલ્પ મહત્ત્વનો છે કે નહીં
પ્રથમ વાટાઘાટ થયેલી ગૌણ આવૃત્તિ છે, કારણ કે 4.1 અને 4.2 કૉલબૅકની ભિન્ન રીતે સંભાળ લે છે. બીજી એ છે કે સર્વર તમે જાહેર કરેલા સરનામા સુધી પહોંચી શકે છે કે નહીં; રૂટ થયેલી ટનલ સામાન્ય રીતે તેને મંજૂરી આપે છે અને અનુવાદિત માર્ગ સામાન્ય રીતે નહીં. ત્રીજી એ છે કે તમે પીછો કરી રહ્યા છો તે નિષ્ફળતા બિલકુલ કૉલબૅક નિષ્ફળતા છે કે નહીં.
| Condition | If yes | If no |
|---|---|---|
| Version is 4.0 | The option can matter | Skip it; inspect the session instead |
| Server can reach the address | Advertise it | Fix reachability first |
| Failure is a callback | Diagnose callback path | Look at mount and export |
તેમને ખોટા ક્રમમાં જવાબ આપવો એ જ રીત છે જેમાં લોકો 4.2 માઉન્ટમાં કૉલબૅક સરનામું ઉમેરે છે અને તારણ કાઢે છે કે વિકલ્પ બગડ્યો છે.
પહેલા ગૌણ આવૃત્તિ વાંચો
nfsstat -mહાલના માઉન્ટ માટે, આ માઉન્ટ માહિતી અને ફ્લૅગ છાપે છે, જેમાં અસરકારક આવૃત્તિ vers=4.0, vers=4.1 કે vers=4.2 તરીકે હોય છે. ફક્ત “NFSv4” કહેતી નોંધ એ એકમાત્ર વિગત છોડી દે છે જે નક્કી કરે છે કે આ વિકલ્પ સુસંગત છે કે નહીં. શબ્દ નહીં, આંકડો વાંચો.
જો આવૃત્તિ શબ્દમાળા તમારી કમાન્ડ લાઇનને બદલે સર્વરના મૂળભૂત મૂલ્યમાંથી આવી હોય, તો પૂછો કે કઈ ગૌણ આવૃત્તિ પર વાટાઘાટ થઈ. સર્વર ઊંચી ગૌણ આવૃત્તિ નકારીને પાછું પડી શકે છે, અને એ પડવું જ એ કિસ્સો છે જ્યાં કૉલબૅક અચાનક મહત્ત્વનો બને છે. તમે લખેલી માઉન્ટ લાઇન તમારી પાસેની માઉન્ટનું વર્ણન ન પણ કરે.
4.0 માટે, સર્વર પહોંચી શકે તેવું સરનામું જાહેર કરો
NFSv4.0 સર્વરને ક્લાયન્ટ તરફ પાછું અલગ જોડાણ જોઈ શકે, ઉદાહરણ તરીકે જ્યારે તે પ્રતિનિધિત્વ પાછું મંગાવે. ઘણા ઇન્ટરફેસ કે અસામાન્ય રૂટિંગ કોષ્ટક હોય ત્યારે કૉલબૅક સરનામાની સ્વયંસંચાલિત શોધ એવું પસંદ કરી શકે છે જે સર્વર વાપરી ન શકે.
mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/shareકોલન પહેલાનું સરનામું સર્વર છે અને લક્ષ્ય જ રહે છે. કૉલબૅક સરનામું ક્લાયન્ટનું છે, અને તે ટનલની સર્વર બાજુથી પહોંચી શકાય તેવું હોવું જોઈએ. લૂપબૅક સરનામું સર્વરને પાછું તેના પોતા તરફ વાળે છે. પરત માર્ગ વગરનું ખાનગી ક્લાયન્ટ સરનામું પણ એટલું જ નકામું છે, જોકે ક્લાયન્ટ પર તે સાચું દેખાય છે.
આને ઉદાહરણ તરીકે વાપરો, કામ કરતું માઉન્ટ નીચું કરવાના કારણ તરીકે નહીં. સરનામાં અને નિકાસ માર્ગ બદલો, અને સર્વરને જરૂરી પ્રમાણીકરણ તથા બીજા વિકલ્પો રાખો. એક ઉદાહરણ બંધ બેસે તે માટે તેમને છોડી દેવું એ ભિન્ન પરિણામ ધરાવતો ભિન્ન ફેરફાર છે, અને સુરક્ષા પ્રકાર લાદતા સર્વર પર કોઈપણ કૉલબૅક પ્રયાસ પહેલાં તે નિષ્ફળ જાય છે.
4.1 અને 4.2 આ વિકલ્પ વાપરતા નથી
Linux NFSv4.1 અને 4.2 ક્લાયન્ટે સ્થાપેલા જોડાણો પર કૉલબૅક વહન કરે છે, અને 4.1 એ સુવિધાને backchannel કહે છે. તેઓ સર્વર દ્વારા જાહેર સરનામા પર નવું જોડાણ ખોલવા પર આધાર રાખતા નથી, તેથી clientaddr 4.1 કે 4.2 નો કૉલબૅક માર્ગ સુધારતું નથી.
એમ નથી કે 4.1 અને 4.2 માં કૉલબૅક સમસ્યાઓ નથી. એમ છે કે નિદાન ભિન્ન છે: સ્થાપિત સત્ર અને તેની backchannel સ્થિતિ તપાસો, એવા આવક કૉલબૅક પોર્ટની શોધને બદલે જે ક્યારેય હોવાનો ઇરાદો ન હતો. ગુમ થયેલો આવક નિયમ અપેક્ષિત સ્થિતિ છે, સુધારવાની ખામી નહીં.
માઉન્ટ નિષ્ફળતાને કૉલબૅક નિષ્ફળતાથી અલગ કરો
પહેલા નક્કી કરો કે ક્લાયન્ટ NFS સેવા સુધી પહોંચે છે કે નહીં અને સર્વર નિકાસ તથા પ્રમાણીકરણ વિનંતી સ્વીકારે છે કે નહીં. એ આદાનપ્રદાન પહેલાનો સમયસમાપ્તિ કૉલબૅક સરનામા વિશે કંઈ કહેતો નથી. માઉન્ટ હજી નિષ્ફળ થતું હોય ત્યારે એક બદલવાથી તપાસ નજીક આવતી નથી, અને તે મૂળ ભૂલને નવા માઉન્ટ વિકલ્પ પાછળ છુપાવે છે.
ફક્ત ત્યારે જ જ્યારે પુરાવા નિષ્ફળ 4.0 કૉલબૅક બતાવે ત્યારે જાહેર સરનામું મહત્ત્વનું બને છે, સર્વરના પરત માર્ગ, ક્લાયન્ટ બાજુના શ્રોતા અને તેમની વચ્ચેના કોઈપણ ગાળણ સાથે. માઉન્ટ વિકલ્પમાં આંકડો બદલવાથી એ માર્ગો બની શકતા નથી; તે ફક્ત પહેલેથી હયાત માર્ગ તરફ ઇશારો કરી શકે છે. એ ચારમાંથી કયો તમે ચકાસ્યો તે લખો, કારણ કે આગલો અહેવાલ તેમાંના એક પણ વગર આવશે.
વહેલા બૂટ વખતનું NFS રૂટ પોતાની પૂર્વશરતો ધરાવતું અલગ પર્યાવરણ છે: માઉન્ટ થઈ શકે તે પહેલાં initramfs ને સાધનો અને નેટવર્કની જરૂર છે. લૉગિન પછી કામ કરતું માઉન્ટ એ ક્રમ વિશે કંઈ સાબિત કરતું નથી, અને બૂટ વખતની નિષ્ફળતા ભાગ્યે જ initramfs કે નેટવર્કનો ઉલ્લેખ કરે છે.