एक फ़ाइल लाने के लिए पूरा नेटवर्क VPN ज़रूरी नहीं

VPN एक्सेस का अनुरोध अक्सर अपने पीछे एक फ़ोल्डर और एक फ़ाइल छिपाता है। पूरे ऑफ़िस नेटवर्क को रूट देना अनुरोध का जवाब देता है और काम की ज़रूरत से कहीं ज़्यादा सौंप देता है। मैप किए गए शेयर को अपलोड पेज से बदलना दूसरी दिशा में भी उतना ही गलत हो सकता है, क्योंकि यह लोगों के काम करने का तरीका बदल देता है। निर्णय इस बात से शुरू होता है कि फ़ाइल के साथ क्या होना चाहिए।

तीन आवश्यकताएँ यहाँ एक जैसी दिखती हैं और बहुत अलग व्यवहार करती हैं: तैयार PDF की प्रतिलिपि बनाना, दस्तावेज़ को उसी जगह संपादित करना, और किसी एप्लिकेशन को साझा डायरेक्टरी के विरुद्ध चलाना।

फ़ोल्डर से नहीं, संपादन से शुरू करें

अगर फ़ाइल तैयार है और सिर्फ़ पढ़ने की ज़रूरत है, तो ट्रांसफ़र खाता काफ़ी है। अगर उसे संपादित किया जाएगा, तो सवाल यह हो जाता है कि और कौन उसे संपादित करता है और टकराव कैसे सुलझते हैं, जो नेटवर्क का नहीं बल्कि वर्कफ़्लो का सवाल है। अगर एप्लिकेशन डायरेक्टरी से सीधे दस्तावेज़ खोलता है, तो स्टोरेज परत की विलंबता और लॉकिंग व्यवहार मायने रखते हैं। पहले इसका जवाब देना ऐसे समाधान को रोकता है जो पूरी तरह जुड़ता है और फिर भी इस्तेमाल नहीं हो सकता।

साझा संपादन ऐसी समस्या लाता है जिसे कोई ट्रांसफ़र हल नहीं कर सकता। उपयोगकर्ता स्प्रेडशीट डाउनलोड करता है, ऑफ़लाइन संपादित करता है और किसी और के मूल बदलने के बाद उसे अपलोड करता है, और एन्क्रिप्टेड कनेक्शन का अधिलेखन पर कोई मत नहीं है। अधिलेखन, टकराव या संस्करण पर सहमति एक्सेस विधि से पहले होनी चाहिए।

SFTP एक ट्रांसफ़र प्रोटोकॉल है, शेयरिंग नहीं

SFTP एन्क्रिप्टेड SSH ट्रांसपोर्ट पर फ़ाइलें ले जाता है, जो प्रतिलिपि को ठीक वही चाहिए और मैप किए गए ड्राइव को नहीं। यह FTP नहीं है, और FTPS देने वाला उत्पाद SFTP के बजाय दूसरा प्रोटोकॉल देता है। SFTP डायरेक्टरी को फ़ाइल सिस्टम परत के ज़रिए माउंट करना मूल शेयर के लॉकिंग, अनुमति या एप्लिकेशन व्यवहार का वादा नहीं करता। इसे सीधा प्रतिस्थापन कहने से पहले क्लाइंट एप्लिकेशन की आवश्यकताएँ जाँचें।

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

तैयार फ़ाइल के लिए पूरा वर्कफ़्लो यही है: जुड़ें, रखें, लाएँ। केवल ट्रांसफ़र वाले खाते को भी सीमित SSH सेवा चाहिए, सिर्फ़ फ़ाइल सिस्टम नहीं। chroot या ForceCommand internal-sftp सीमित करता है कि सत्र क्या चला सकता है, और TCP फ़ॉरवर्डिंग तथा टनलिंग बंद करना उन रास्तों को बंद करता है जो अन्यथा फ़ाइल खाते को नेटवर्क प्रवेश बिंदु बना देते। सिर्फ़ दिखने वाली डायरेक्टरी सीमित करना इस बात का कुछ साबित नहीं करता कि खाता कहाँ तक पहुँच सकता है।

अगर आपको शेयरिंग चाहिए, तो उसे प्रकाशित न करें

कभी-कभी मूल शेयर ही असली आवश्यकता होता है, और जवाब SMB को मनमाने इंटरनेट क्लाइंट के सामने खोलना नहीं है। Microsoft का मार्गदर्शन सीमा पर सीधा SMB ट्रैफ़िक अवरुद्ध करना है, और अच्छे कारण से: प्रोटोकॉल अविश्वसनीय नेटवर्क का सामना करने के लिए नहीं बना था। QUIC पर SMB और समान डिज़ाइन मौजूद हैं, दोनों सिरों पर विशिष्ट प्लेटफ़ॉर्म आवश्यकताओं के साथ, और वे मनमाने Samba सर्वर के लिए सार्वभौमिक स्विच नहीं हैं। अगर कोई भी लागू न हो, तो काम फ़ॉरवर्ड किए गए पोर्ट के बजाय समर्थित एक्सेस पथ देना है।

ब्राउज़र-आधारित विकल्प काम के अनुकूल होने पर वैध तीसरा जवाब है। यह अपने निर्णय लाता है: खाते, शेयरिंग लिंक, समाप्ति, रखे गए संस्करण और कौन-सी प्रतिलिपि प्रामाणिक है। कोई भी खोल सके ऐसा लिंक और साइन-इन माँगने वाला वर्कस्पेस अलग-अलग एक्सेस नीतियाँ दर्शाते हैं, और किसी को भी संयोग से नहीं चुनना चाहिए।

एक्सेस सौंपने से पहले क्या जाँचें

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

आप जो भी डिज़ाइन चुनें, उसे इच्छित डेटा और इच्छित क्रियाओं तक सीमित रखें। पहला आदेश सफल होना चाहिए और दूसरा अस्वीकार; अगर दोनों सफल हों, तो खाता काम से व्यापक है। फिर खाता हटाएँ और पहला दोहराएँ, जो अब विफल होना चाहिए। स्रोत फ़ाइलों के स्वामी को पहचानने योग्य रखें, ताकि प्रामाणिक प्रतिलिपि के बारे में बाद का सवाल का जवाब हो। दर्ज करने योग्य परिणाम एक उपयोगी और रद्द करने योग्य फ़ाइल वर्कफ़्लो है, गायब कनेक्शन आइकन नहीं।

लिखें कि उपयोगकर्ता के एप्लिकेशन को वास्तव में कौन-सा प्रोटोकॉल चाहिए और आपने कौन-से तीन परीक्षण किए। ये दो पंक्तियाँ ज़्यादातर दोबारा काम रोकती हैं।