जुना 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 |
आवश्यकता यादीच्या विरुद्ध निवडा
कोणताही आकार सरळ जिंकत नाही। कार्यरत बोगद्यासह व्यवस्थापित लॅपटॉपवरील कर्मचाऱ्यांना स्थानिक क्लायंटकडून अधिक मिळते, कारण पुनर्प्राप्ती आणि परवानग्या पुनर्रचनेतून नव्हे तर प्लॅटफॉर्ममधून येतात। कंत्राटदार आणि वैयक्तिक उपकरणांची मिश्र लोकसंख्या प्रॉक्सीला न्याय देऊ शकते, जर ओळखीची पाइपलाइन खरी असेल आणि सामायिक सेवा खाते नसेल।
चार क्रिया आणि पुनर्प्राप्तीच्या उत्तरासमोर तुलना लिहा, मग नव्या मार्गाने एक पुनर्संचयन झाल्यानंतरच जुने पोर्टल निवृत्त करा। ती चाचणी रचनेचे ते भाग चालवते ज्यांना यशस्वी लॉगिन कधीही स्पर्श करत नाही।