آیا نشست کاربر باید مالک اتصال SSHFS روی VPN باشد؟

اتصال یک پوشه اشتراکی پس از بالا آمدن VPN دو هویت را درگیر می‌کند که به‌راحتی اشتباه گرفته می‌شوند: مؤلفه‌ای که اجازه پیکربندی شبکه را دارد و حسابی که اجازه ورود به سرور فایل را دارد. به‌ندرت یکی هستند. هوک VPN متعلق به root جای بدی برای شروع اتصال SSHFS یک کاربر میزکار است، زیرا نه عامل کاربر را دارد و نه مالکیت موردنظر اتصال را. درست کردن مالکیت در ابتدا محرک را ساده می‌کند.

دو هویت، دو مجوز جداگانه

کلاینت VPN برای تغییر مسیرها و رابط‌ها به امتیاز نیاز دارد. اتصال SSHFS به هویتی SSH نیاز دارد که سرور فایل بپذیرد و به اتصال FUSE متعلق به حسابی که فایل‌ها را می‌خواند. یک اسکریپت که با root اجرا می‌شود شرط اول را برآورده می‌کند و دومی را بی‌صدا می‌شکند.

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

پیش از نوشتن هرگونه خودکارسازی تصمیم بگیرید کدام حساب مالک اتصال است، زیرا این انتخاب تعیین می‌کند محرک کجا زندگی می‌کند و به کدام اعتبارنامه‌ها می‌رسد.

ابتدا به‌صورت دستی اتصالی متعلق به کاربر برقرار کنید

از کاربری واردشده با نقطه اتصال خالی، حساب SSH مجاز و مسیری کارا به سرور از طریق تونل شروع کنید. اتصال دستی پایه‌ای را ایجاد می‌کند که هر خودکارسازی باید بازتولید کند.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

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

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

بگذارید محرک در همان بافت نشست عمل کند

بگذارید یکپارچه‌سازی رویداد VPN پشتیبانی‌شده از یک اقدام نشست کاربر بخواهد اجرا شود، به‌جای فرض اینکه یک callback ممتاز می‌تواند اعتبارنامه میزکار را قرض بگیرد. محرک را به شناسه اتصال موردنظر محدود کنید نه به هر رابطی که تصادفاً tun0 نامیده می‌شود. قاعده توزیع‌کننده‌ای که با چیز اشتباه مطابقت دارد در هر تغییر شبکه فعال می‌شود، از جمله مواردی که هیچ ارتباطی با این اتصال ندارند.

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

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

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

یک سرویس بدون نظارت به اعتبارنامه تأییدشده خود و ترتیب تأیید میزبان خود در بافت اجرای خود نیاز دارد. نمی‌تواند فرض کند عامل گرافیکی باز است و نباید تلاش کند یکی را باز کند.

پیش از اجبار پاکسازی، قطع اتصال را برنامه‌ریزی کنید

برای قطع اتصال برنامه‌ریزی‌شده، عملیات فایل را تمام کنید و از جریان کاری خود کاربر متصل‌کننده جدا شوید. نقطه اتصال را هدف بگیرید نه فرایند را و پیش از گزارش موفقیت نتیجه را تأیید کنید.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

فقط اتصالی را جدا کنید که این جریان کاری ایجاد کرده است. اگر مشغول است، این تصمیم برنامه است: جداسازی اجباری که برای موفقیت بازگشتی یک هوک وجود دارد، از دست رفتن داده را پنهان می‌کند نه اینکه از آن جلوگیری کند.

از دست رفتن غیرمنتظره رفتار متفاوتی دارد. SSHFS مستند می‌کند که قطع شبکه می‌تواند یک عملیات سیستم فایل را مسدود کند و گزینه reconnect انتقال را بدون بازیابی دستگیره‌ها برمی‌گرداند: فایلی که پیش از اتصال مجدد باز شده ممکن است در نوشتن بعدی شکست بخورد و نوشتن قطع‌شده حفظ نمی‌شود. این تفاوت برای ویرایشگرهایی که یک فایل را ساعت‌ها باز نگه می‌دارند بیشترین اهمیت را دارد. به‌جای فرض بازیابی، مرحله بازگشایی را برنامه‌ریزی کنید.

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