જૂનું VPN ફાઇલ પોર્ટલ બદલવું: નિયંત્રણો જાળવી રાખો
એક મૂળ ફાઇલ ક્લાયન્ટ અને એક પ્રોક્સી પોર્ટલ અલગ અલગ જગ્યાએ પરવાનગીઓ, પુનઃપ્રાપ્તિ અને ઓળખ લાગુ કરે છે. વપરાશકર્તાઓને જરૂરી ચાર ક્રિયાઓ પર તેમની સરખામણી કરો.
જૂના ક્લાયન્ટ વગરના પોર્ટલમાં ડિલીટ બટન, મનપસંદ તારો અને ઈમેલમાં પેસ્ટ કરેલો શેર પાથ હતો. તેમાંથી ફક્ત એક જ નિયંત્રણ છે. પોર્ટલ બદલવાનો અર્થ એ નક્કી કરવો છે કે દૂરના વપરાશકર્તાઓને હજી કઈ ક્રિયાઓની જરૂર છે અને દરેક ક્યાં લાગુ થાય છે, એવા પૃષ્ઠનું લેઆઉટ ફરી બનાવવું નહીં જે સંજોગવશાત કામ કરતું હતું. બે બદલીના સ્વરૂપો મોટાભાગના કિસ્સાઓ આવરી લે છે, અને તે અલગ અલગ જગ્યાએ નિષ્ફળ જાય છે.
બટન પરવાનગી નથી
ક્રિયાઓની યાદી સાથે શરૂ કરો: વાંચન, અપલોડ, નામ બદલવું, ડિલીટ. કઈ ભૂમિકાઓને કઈ મળે તે નક્કી કરો, પછી તે નિર્ણય ઈન્ટરફેસમાં નહીં પણ ફાઇલ સેવામાં લાગુ કરો. નવા પોર્ટલમાં ડિલીટ નિયંત્રણ છુપાવવાથી બેકએન્ડની પરવાનગી અકબંધ રહે છે, અને મૂળ ક્લાયન્ટ અને એ જ ખાતું ધરાવતું કોઈપણ વ્યક્તિ હજી પણ ફાઇલ દૂર કરી શકે છે.
ડિલીટને અલગ નિર્ણય મળવો જોઈએ કારણ કે તે જ એ ક્રિયા છે જેનો વપરાશકર્તાઓને પસ્તાવો થાય છે. પૂછો કે ડિલીટ કરેલી વસ્તુ ખરેખર ક્યાંથી પુનઃપ્રાપ્ત થઈ શકે છે, અને એવું ન માનો કે જવાબ લેપટોપની રિસાયકલ બિન કે પોર્ટલની પોતાની ટ્રેશ છે. નેટવર્ક શેર સામાન્ય રીતે ડિલીટને સ્થાનિક રિસાયકલ બિનમાંથી પસાર કરતું નથી.
Windows દ્વારા સમર્થિત શેર પર, Volume Shadow Copy સ્નેપશોટ મિકેનિઝમ અને બેકઅપ સોફ્ટવેર વાપરે છે તે સંકલન પૂરું પાડે છે, પરંતુ તેની હાજરી એ વિશે કંઈ કહેતી નથી કે આ શેર તમે પુનઃસ્થાપિત કરી શકો તેવી આવૃત્તિઓ રાખે છે કે નહીં. ફાઇલ સેવાના માલિકે આવૃત્તિ નીતિની પુષ્ટિ કરવી પડશે અને પોર્ટલ નિવૃત્ત થાય તે પહેલાં એક પુનઃસ્થાપન દર્શાવવું પડશે.
વિકલ્પ A: ટનલ પર મૂળ ફાઇલ ક્લાયન્ટ
મેપ કરેલી ડ્રાઇવ કે SMB ક્લાયન્ટ વપરાશકર્તાઓ પહેલેથી જાણતા હોય તેવી ક્રિયાઓ જાળવી રાખે છે, અને દરેક વિનંતી પર ફાઇલ સર્વર પરવાનગીઓ લાગુ કરે છે. મહત્વની ઓળખ ફાઇલ સેવાની ઓળખ છે, તેથી VPN ઉત્પાદન બદલાય તો પણ પ્રવેશ ટકી રહે છે, જ્યાં સુધી ટનલ હજી ટ્રાફિક વહન કરે છે અને ખાતું હજી અસ્તિત્વમાં છે.
ખર્ચ એ છે કે ક્લાયન્ટે સેવા સુધી સીધું પહોંચવું પડે. નામ ઉકેલ, પોર્ટ પહોંચતા અને પ્રમાણીકરણ પદ્ધતિ બધા દૂરસ્થ પ્રવેશની રચનાનો ભાગ બને છે, અને પહેલાં જોડાણને પ્રોક્સી કરતું પોર્ટલ આ દરેક જરૂરિયાત છુપાવતું હતું. અસંચાલિત ઉપકરણોના વપરાશકર્તાઓને તેમના ફાઇલ મેનેજરમાં માઉન્ટ કરેલું શેર પણ મળે છે, જે બ્રાઉઝર ટૅબ કરતાં વધુ પહોળી સપાટી છે. સ્થળાંતર પહેલાં તે સહાયક ભાર માટે બજેટ રાખો, કારણ કે તે પ્રથમ દિવસે આવે છે, ગ્રેસ અવધિ પછી નહીં.
પુનઃપ્રાપ્તિ આ સ્વરૂપ માટે સૌથી મજબૂત દલીલ છે: અગાઉની આવૃત્તિઓ અને પુનઃસ્થાપન પરવાનગીઓ પ્લેટફોર્મમાં મૂળ છે, અને હેલ્પ ડેસ્ક સ્થળ પર વાપરે છે તે જ પ્રક્રિયા વાપરી શકે છે.
વિકલ્પ B: પ્રોક્સી કે એપ્લિકેશન ગેટવે
ફાઇલ લઈને બ્રાઉઝરમાં સ્ટ્રીમ કરતું પોર્ટલ ફાઇલ સેવાને વપરાશકર્તાના નેટવર્ક માર્ગની બહાર રાખે છે. જ્યારે ઉપકરણ ટનલમાં જોડાઈ શકતું નથી અથવા જ્યારે સંસ્થા ઈચ્છે છે કે દરેક વિનંતી એક જ અડચણ બિંદુ પર નોંધાય, ત્યારે તે ઉપયોગી છે. વેપાર એ છે કે પ્રોક્સી દરેક ક્રિયામાં ભાગીદાર બને છે, અને બધા માટે પોતાનું સેવા ખાતું વાપરવાને બદલે વપરાશકર્તાની ઓળખ ફાઇલ સેવા સુધી પહોંચાડવી પડે છે.
ડિલીટ અને નામ બદલવાનું વર્તન વારસામાં નહીં પણ અમલમાં મૂકવું પડે. જો પ્રોક્સી ડિલીટ ક્રિયા બતાવે છે, તો તે ક્રિયા અમુક ઓળખ સાથે બેકએન્ડને બોલાવે છે, અને ઓડિટ ટ્રેલમાં ગેટવે નહીં પણ વપરાશકર્તાનું નામ હોવું જોઈએ. જો પ્રોક્સી નામ બદલી શકતું નથી, તો વપરાશકર્તાઓ પ્રોજેક્ટની વચ્ચે શોધે તે પહેલાં કહી દો.
લિંક ફરી લખવી એ જગ્યા છે જ્યાં આ સ્વરૂપ શાંતિથી અર્થ બદલે છે. પોર્ટલ જે URL પ્રોક્સી કરે છે તે બ્રાઉઝર સીધું ખોલે તે URL જેવી જ વસ્તુ નથી, અને એકને બીજામાં બદલવાથી તે પ્રમાણીકરણ સંદર્ભ દૂર થઈ શકે છે જે તેને કામ કરતું રાખતો હતો.
નામ, ઓળખ અને તેમની વચ્ચેની લિંક
મંજૂર કરેલું સર્વર અને શેર પાથ વિતરિત કરો, ડોમેન બ્રાઉઝિંગ યાદી નહીં. બ્રાઉઝિંગ શોધ સેવાઓ પર આધાર રાખે છે જે ટનલ પાર ન કરે, અને જે પાથ કામ કરે છે કારણ કે વપરાશકર્તાનું લેપટોપ ડોમેનની ગણતરી કરી શકે છે તે પાથ આગલા અસંચાલિત ઉપકરણ પર તૂટી જાય છે.
સિંગલ સાઇન-ઓનની એપ્લિકેશન દીઠ સમીક્ષા કરો. પોર્ટલ માટે જારી કરેલું ટોકન એવી ફાઇલ સેવામાં ફરી વગાડવું ન જોઈએ જેણે તેને ક્યારેય માન્ય કર્યું નથી, અને ઓળખકર્તા ધરાવતા ક્વેરી પેરામીટર ફક્ત એટલા માટે જાહેર લિંકમાં કોપી ન કરવા જોઈએ કે તેઓ જૂના બુકમાર્કમાં દેખાયા હતા. દરેક મંજૂર એપ્લિકેશનને તેની પોતાની વિશ્વાસ સીમા તરીકે ગણો.
| Requirement | Native client | Proxy portal |
|---|---|---|
| Permission enforcement | File service, per request | Proxy identity, then file service |
| Restore path | Platform versions and backups | Proxy trash plus backend restore |
| Device requirements | Tunnel and client | Browser only |
| Audit identity | File server logs | Proxy logs, if it forwards the user |
આવશ્યકતાઓની યાદી સામે પસંદ કરો
બંનેમાંથી કોઈ પણ સ્વરૂપ સંપૂર્ણ જીતતું નથી. સંચાલિત લેપટોપ અને કાર્યક્ષમ ટનલ ધરાવતું કાર્યબળ મૂળ ક્લાયન્ટમાંથી વધુ મેળવે છે, કારણ કે પુનઃપ્રાપ્તિ અને પરવાનગીઓ ફરી અમલીકરણમાંથી નહીં પણ પ્લેટફોર્મમાંથી આવે છે. કોન્ટ્રાક્ટરો અને વ્યક્તિગત ઉપકરણોની મિશ્ર વસ્તી પ્રોક્સીને ન્યાયી ઠેરવી શકે છે, જો ઓળખ માળખું વાસ્તવિક હોય અને વહેંચાયેલું સેવા ખાતું ન હોય.
ચાર ક્રિયાઓ અને પુનઃપ્રાપ્તિના જવાબ સામે સરખામણી લખો, પછી નવા માર્ગ દ્વારા એક પુનઃસ્થાપન પૂર્ણ થયા પછી જ જૂનું પોર્ટલ નિવૃત્ત કરો. તે પરીક્ષણ રચનાના તે ભાગોનો અભ્યાસ કરે છે જેને સફળ લોગિન ક્યારેય સ્પર્શતું નથી.