একটি ফাইল আনা পূর্ণ নেটওয়ার্ক 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"

যে নকশাই বেছে নিন, তা উদ্দিষ্ট ডেটা ও উদ্দিষ্ট কাজে সীমিত রাখুন। প্রথম কমান্ড সফল হওয়া উচিত আর দ্বিতীয়টি প্রত্যাখ্যাত; দুটোই সফল হলে অ্যাকাউন্টটি কাজের চেয়ে প্রশস্ত। তারপর অ্যাকাউন্ট সরিয়ে প্রথমটি আবার চালান, যা এখন ব্যর্থ হওয়া উচিত। উৎস ফাইলের মালিককে শনাক্তযোগ্য রাখুন, যাতে প্রামাণ্য কপি নিয়ে পরের প্রশ্নের উত্তর থাকে। যে ফলাফল লিপিবদ্ধ করার যোগ্য তা হল ব্যবহারযোগ্য ও প্রত্যাহারযোগ্য ফাইল কর্মপ্রবাহ, অনুপস্থিত সংযোগ আইকন নয়।

ব্যবহারকারীর অ্যাপ্লিকেশনের আসলে কোন প্রোটোকল দরকার এবং আপনি কোন তিনটি পরীক্ষা চালিয়েছেন তা লিখে রাখুন। এই দুই লাইন বেশিরভাগ পুনর্কাজ আটকায়।