ایک فائل لانا مکمل نیٹ ورک 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"

آپ کوئی بھی ڈیزائن چنیں، اسے مطلوبہ ڈیٹا اور مطلوبہ کارروائیوں تک محدود رکھیں۔ پہلا حکم کامیاب ہونا چاہیے اور دوسرا مسترد؛ اگر دونوں کامیاب ہوں تو اکاؤنٹ کام سے وسیع تر ہے۔ پھر اکاؤنٹ ہٹائیں اور پہلا دہرائیں، جو اب ناکام ہونا چاہیے۔ ماخذ فائلوں کے مالک کو قابل شناخت رکھیں، تاکہ مستند نقل کے بارے میں بعد کا سوال جواب پا سکے۔ ریکارڈ کرنے کے قابل نتیجہ قابل استعمال اور منسوخ ہونے والا فائل ورک فلو ہے، غائب کنکشن آئیکن نہیں۔

لکھیں کہ صارف کی ایپلیکیشن کو واقعی کون سا پروٹوکول درکار ہے اور آپ نے کون سے تین ٹیسٹ کیے۔ وہ دو سطریں زیادہ تر دوبارہ کام روکتی ہیں۔