VPN સરનામા સાથે બંધાયેલ NFS એક્સપોર્ટ: તે શું સાબિત કરતું નથી
એક્સપોર્ટ નિયમ તપાસે છે કે પેકેટ ક્યાંથી આવ્યું; AUTH_SYS સ્થાનિક UID દાવો કરે છે અને Kerberos વપરાશકર્તાને પ્રમાણિત કરે છે. તમારી ફાઇલ સેવાને કઈ જોઈએ છે તે નક્કી કરો.
એક હોસ્ટ ડિરેક્ટરીને VPN સરનામા પર એક્સપોર્ટ કરે છે, માઉન્ટ સફળ થાય છે, અને ડિઝાઇન પ્રમાણિત તરીકે લખાઈ જાય છે. એ નિયમ ખરેખર જે મર્યાદિત કરે છે તે એ છે કે પેકેટ ક્યાંથી આવતા દેખાય છે. ફાઇલ કામગીરી ચલાવનાર વ્યક્તિ પોતાને જે કહે છે તે જ છે કે નહીં તે NFS સુરક્ષા ફ્લેવર પર આધાર રાખે છે, અને આ પ્રકારના મોટાભાગના એક્સપોર્ટમાં કોઈએ તેને ડિફોલ્ટથી બદલ્યું નથી.
એક વિનંતીમાં ત્રણ ઓળખ દેખાઈ શકે છે
VPN પીઅર નોંધાયેલી ઓળખ રાખે છે, જેમ કે ક્લાયન્ટ સર્ટિફિકેટ અથવા પીઅર કી. અંદરનું IP પેકેટ સ્રોત સરનામું રાખે છે. ફાઇલ કામગીરી તેની NFS પદ્ધતિ જે વપરાશકર્તા ઓળખપત્ર આપે તે રાખે છે. જે ડિઝાઇન સરનામાને ત્રણેયનો વિકલ્પ ગણે છે તેણે ચૂપચાપ એ જ ભાગ ધારી લીધો છે જે ચકાસવાનો હતો.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
એ ત્રણ પંક્તિઓ લખવી એ જ આખો અભ્યાસ છે. એક્સપોર્ટ સુરક્ષિત છે કે નહીં તે અંગેની મોટાભાગની ચર્ચા ત્યારે પડી જાય છે જ્યારે સ્પષ્ટ થાય કે દરેક નિયંત્રણ કઈ પંક્તિમાં રહે છે.
સરનામાની માલિકી અમલીકરણની વિગત છે
એક ગેટવે સ્વીકૃત પીઅરને ટનલ સરનામું આપી શકે છે, અથવા તેના માટે રૂટેડ સબનેટને અધિકૃત કરી શકે છે. પછી અમલીકરણ એવા પેકેટને નકારે છે કે નહીં જેનો અંદરનો સ્રોત બીજા ક્લાયન્ટનો છે, તે એ અમલીકરણની લાક્ષણિકતા છે, અને ધારી લેવાને બદલે તે ચકાસવા યોગ્ય છે.
પરંપરાગત Community OpenVPN વપરાશકર્તા-જગત સર્વર કોડ, ઉદાહરણ તરીકે, TUN ઉપકરણ દ્વારા પેકેટ પહોંચાડ્યા પહેલાં બીજા ક્લાયન્ટ સાથે સંકળાયેલા સ્રોતને નકારી શકે છે. તે વાસ્તવિક મૂલ્ય ધરાવતી સરનામા-માલિકી ચકાસણી છે, અને તે હજી પણ NFS વપરાશકર્તા પ્રમાણીકરણ નથી, કારણ કે તે કહેતું નથી કે કયું ખાતું આ કામગીરી કરે છે.
સ્રોત અનુવાદ તેને પણ ઘસી નાખે છે. NAT ગેટવે દરેક ક્લાયન્ટને એક જ સરનામા તરીકે રજૂ કરી શકે છે, અને પછી એક્સપોર્ટ નિયમ તેની પાછળના લોકોમાં ભેદ પાડી શકતો નથી. નિયમની દેખીતી ચોકસાઈ પછી આકૃતિ દ્વારા ટકાવેલી કલ્પના બની જાય છે. જો એક્સપોર્ટ મહત્વનું હોય, તો સરનામાંકન સ્પષ્ટ રાખો, અનુવાદકને કોણ કોના બદલે ગણાય તે નક્કી કરવા ન દો.
એક્સપોર્ટ પર ભરોસો કરતાં પહેલાં સુરક્ષા ફ્લેવર વાંચો
Red Hat નું NFS માર્ગદર્શન sec=sys, જે AUTH_SYS દ્વારા સ્થાનિક UNIX UID અને GID વાપરે છે, તેને Kerberos મોડથી અલગ કરે છે. krb5 વપરાશકર્તા પ્રમાણીકરણ ઉમેરે છે, krb5i અખંડિતતા સુરક્ષા ઉમેરે છે, અને krb5p ટ્રાફિક માટે ગોપનીયતા સુરક્ષા ઉમેરે છે.
AUTH_SYS ઓળખપત્રમાં કૉલરનું UID અને જૂથ ઓળખકર્તા જેવા ક્ષેત્રો હોય છે, અને RFC 5531 સ્પષ્ટ ચેતવે છે કે આ ફ્લેવર પોતે કોઈ સુરક્ષા આપતું નથી અને બાહ્ય સુરક્ષા પર આધારિત છે. તેને VPN ની અંદર ચલાવવાથી પરિવહન માટે સુરક્ષા મળે છે અને પેકેટની અંદરના દાવામાં કંઈ બદલાતું નથી.
exportfs -v
showmount -e nfs.example.internalક્લાયન્ટ યાદી વાંચતાં પહેલાં તે આઉટપુટમાં ફ્લેવર વાંચો. મર્યાદિત દેખાતું એક્સપોર્ટ ફક્ત સરનામાથી મર્યાદિત હોઈ શકે છે જ્યારે દરેક કૉલર હજી પણ ગમે તે UID દાવો કરે છે.
મોડલ પસંદ કરો, પછી પરવાનગીઓ રાખો
તમે ખરેખર સંચાલિત કરો છો તે ક્લાયન્ટ માટે યોગ્ય ફાઇલ-સેવા પ્રમાણીકરણ મોડલ પસંદ કરો. Kerberos ને પાછળ ઓળખ અને સેવા જમાવટ જોઈએ છે, તેથી એક માઉન્ટ વિકલ્પ બદલવો તે સ્થળાંતર નથી અને Kerberos ડોમેન, પ્રિન્સિપાલ અને keytab ન હોય ત્યાં સુધી તે ફક્ત નિષ્ફળ જશે.
બંને મોડલમાં, એક્સપોર્ટ પરવાનગીઓ અને ફાઇલસિસ્ટમ અધિકૃતિ રાખો જે પ્રમાણિત પ્રિન્સિપાલ શું કરી શકે તે મર્યાદિત કરે છે. પ્રમાણીકરણ તમને કહે છે કોણ પૂછે છે; અધિકૃતિ નક્કી કરે છે કે જવાબ હા હોવો જોઈએ કે નહીં. આ બંનેને એક સેટિંગમાં ભેગા કરવાથી સ્થળાંતર જૂની ગોઠવણી કરતાં વધુ અધિકાર આપવા લાગે છે.
સરનામા નિયમનો તેના ખરા હેતુ માટે ઉપયોગ કરો
સેવાને મંજૂર માર્ગ અને સ્રોત સુધી મર્યાદિત રાખવી હજી યોગ્ય છે, જેમાં હોસ્ટ ઇનપુટ નીતિનો સમાવેશ થાય છે જ્યારે VPN એન્ડપોઇન્ટ અને NFS સર્વર એક જ મશીન વહેંચે છે. ટ્રાફિક ફોરવર્ડ કરતા નિયમો તે વિનંતીઓને સંચાલિત કરતા નથી જે એ જ હોસ્ટ પર સ્થાનિક રીતે ચાલતી સેવા તરફ નિર્દેશિત હોય. આ અંતર અચાનક ઘણા એક્સપોર્ટ સમજાવે છે જે ખાનગી હોવાના હતા. ટનલ નિયમો તેને આવરી લે છે એમ ધારવાને બદલે સ્થાનિક ઇનપુટ નીતિ સ્પષ્ટ રીતે ચકાસો.
ચકાસો કે બીજું ઇન્ટરફેસ કે સ્રોત-અનુવાદ કરતું ગેટવે અણધારી રીતે નિયમ પૂરો કરી શકતું નથી, અને તેને સરનામું બનાવટી કરવાથી કાર્યક્ષમ માઉન્ટની ખાતરી થાય છે એવા દાવા તરીકે નહીં, પણ ઉત્પત્તિ સ્થાપિત કરવાના કારણ તરીકે ગણો.
એકને બદલે ત્રણ સ્વીકૃતિ કેસ ચલાવો. મંજૂર ક્લાયન્ટ સાથે મંજૂર વપરાશકર્તા તરીકે શરૂ કરો, પછી જે પીઅર ક્યારેય મંજૂર થયું નથી તેનાથી પુનરાવર્તન કરો, પછી એવું કંઈક કરવાનો પ્રયાસ કરો જે મંજૂર વપરાશકર્તાને હજી કરવાની પરવાનગી નથી. પછી પૂછો કે અધિકૃત ક્લાયન્ટ સાથે ચેડાં થાય તો શું બદલાય છે, કારણ કે પરિવહન પ્રમાણીકરણ તે મશીન પરની દરેક પ્રક્રિયાને વિશ્વસનીય બનાવતું નથી. ચોરાયેલું સર્ટિફિકેટ અને જિજ્ઞાસુ સ્થાનિક ખાતું જુદા જુદા નિયંત્રણો સાથે જુદી જુદી સમસ્યાઓ છે.