دریافت یک فایل به 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 را در معرض مشتریان دلخواه اینترنت بگذاریم. راهنمایی مایکروسافت مسدود کردن ترافیک مستقیم SMB در مرز است، و به دلیلی خوب: پروتکل برای رویارویی با شبکه‌های غیرقابل‌اعتماد ساخته نشده است. SMB روی QUIC و طرح‌های مشابه وجود دارند، با نیازهای پلتفرمی مشخص در هر دو سر، و آن‌ها کلید جهانی برای هر سرور Samba دلخواه نیستند. اگر هیچ‌کدام مصداق ندارد، کار فراهم کردن یک مسیر دسترسی پشتیبانی‌شده به جای یک پورت ارسال‌شده است.

گزینه مبتنی بر مرورگر سومین پاسخ مشروع است وقتی کار با آن جور باشد. تصمیم‌های خودش را می‌آورد: حساب‌ها، پیوندهای اشتراک، انقضا، نسخه‌های نگه‌داشته‌شده و اینکه کدام نسخه معتبر است. پیوندی که هر کسی می‌تواند باز کند و فضای کاری که ورود می‌خواهد سیاست‌های دسترسی متفاوتی را نشان می‌دهند، و هیچ‌کدام نباید تصادفی انتخاب شوند.

پیش از تحویل دسترسی چه چیزهایی را بررسی کنید

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

هر طرحی که انتخاب کنید، آن را به داده‌های موردنظر و عملیات موردنظر محدود کنید. فرمان اول باید موفق شود و دومی باید رد شود؛ اگر هر دو موفق شوند، حساب گسترده‌تر از وظیفه است. سپس حساب را حذف کنید و اولی را تکرار کنید، که اکنون باید شکست بخورد. مالک فایل‌های مبدأ را قابل شناسایی نگه دارید تا پرسش بعدی درباره نسخه معتبر پاسخی داشته باشد. نتیجه‌ای که ارزش ثبت دارد یک گردش کار فایل قابل استفاده و قابل لغو است، نه یک نماد اتصال گمشده.

بنویسید که برنامه کاربر در واقع به کدام پروتکل نیاز دارد و کدام سه آزمون را اجرا کردید. آن دو خط بیشترین دوباره‌کاری را جلوگیری می‌کنند.