اندروید نمی‌تواند فایل‌های اشتراک فایل VPN را باز کند

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

پیش از سرزنش تونل، سرویس را بررسی کنید

پاسخ ping یا صفحه وب NAS فقط مسیریابی را ثابت می‌کند و بس. سرویسی که واقعاً لازم دارید، SMB روی 445، SFTP روی 22 یا WebDAV روی 443، ممکن است غیرفعال، پشت فایروال، یا مقید به رابطی باشد که زیرشبکه VPN به آن نمی‌رسد. از گوشی، همان درگاه مشخص را با کلاینتی آزمایش کنید که خطای واقعی را نشان می‌دهد نه پیام کلی شبکه. اگر درگاه فیلتر شده است، سرویس یا قاعده فایروال را درست کنید، چون هیچ برنامه فایلی نمی‌تواند درگاه بسته را دور بزند.

همچنین بررسی کنید سرور چه نشانی مبدأیی می‌بیند. تونل تقسیم‌شده‌ای که زیرشبکه اشتراک را مستثنا می‌کند، یا تونل به‌ازای هر برنامه که برنامه فایل را بیرون VPN می‌گذارد، دقیقاً همان نشانه متصل اما دسترس‌ناپذیر را می‌سازد.

در برابر این میان‌بر که چون یک کلاینت نمی‌تواند احراز هویت کند دسترسی مهمان یا SMB1 را فعال کنیم مقاومت کنید. این تغییرها دامنه پذیرش سرور را برای هر دستگاه روی شبکه گسترده می‌کنند و اگر مشکل اصلی مسیریابی یا حل نام باشد هیچ‌چیز را درست نمی‌کنند. اگر اشتراک به حساب مشخصی نیاز دارد، از همان استفاده کنید، همراه با پیشوند دامنه یا workgroup که سرور انتظار دارد.

از برنامه فایلی استفاده کنید که خودش پروتکل را می‌فهمد

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

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

بدانید به برنامه گیرنده چه چیزی سپرده می‌شود: یک URI، نه یک مسیر

اگر برنامه فایل شما DocumentsProvider را پیاده‌سازی می‌کند، چارچوب Storage Access Framework اندروید می‌تواند محتویات آن را در انتخابگر سیستمی نشان دهد، و برنامه‌ای که از آن انتخاب می‌کنید یک content:// URI به‌همراه اجازه دسترسی دریافت می‌کند. این اجازه یک مسیر فایل‌سیستمی نیست، و به همین دلیل ویرایشگری که بر نام مسیر خام پافشاری می‌کند نمی‌تواند سند را باز کند، هرچند انتخابگر آن را فهرست کرده باشد. راهنمای دسترسی به اسناد در اندروید این مدل را توضیح می‌دهد: ارائه‌دهنده مالک بایت‌هاست و مصرف‌کننده آن‌ها را از طریق سیستم می‌خواند. برنامه‌هایی که URI را می‌پذیرند کار می‌کنند، و برنامه‌هایی که open() را روی یک مسیر صدا می‌زنند کار نمی‌کنند. این رایج‌ترین دلیل آن است که یک اشتراک در برنامه فایل کار می‌کند و در هر جای دیگری شکست می‌خورد.

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

سیاست VPN به‌ازای هر برنامه هم در اینجا ارزش نگاه کردن دارد. بسته‌ای که خواندن شبکه را انجام می‌دهد اغلب برنامه ارائه‌دهنده است نه ویرایشگر، پس بسته درست را در تونل بگنجانید به‌جای آنکه بر اساس نمادی که لمس کرده‌اید قضاوت کنید.

خواندن، نوشتن و ماندگاری اجازه را جداگانه آزمایش کنید

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

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

اجازه URI اندروید را از مجوز سرور جدا نگه دارید. اینکه اجازه دارید سندی را باز کنید هیچ چیزی درباره حساب SMB پشت آن نمی‌گوید.

اشتراک‌های سوارشده را برای مواردی نگه دارید که به آن‌ها نیاز دارند

سوارکردن‌های CIFS در سطح root و ماژول‌های فایل‌سیستم هسته هنوز وجود دارند و به هر برنامه توهم یک پوشه محلی را می‌دهند. آن‌ها همچنین به root نیاز دارند، با تغییر هسته می‌شکنند، و خرابی‌های شبکه را درون لایه فایل‌سیستم پنهان می‌کنند، جایی که تشخیصشان سخت‌تر است. برای ویرایش سند روی گوشی، جریان کاری ارائه‌دهنده یا کپی بیشتر آنچه مردم واقعاً لازم دارند را پوشش می‌دهد.

پیش از آنکه جریان کاری‌ای بر سوارکردن بنا کنید، بررسی کنید آیا آن سوارکردن از تغییر شبکه جان سالم به در می‌برد. اشتراکی که از یک لپ‌تاپ روی میز سوار شده رفتار متفاوتی از گوشی‌ای دارد که میان Wi-Fi و شبکه همراه جابه‌جا می‌شود، و یک سوارکردن کهنه می‌تواند باعث شود برنامه به‌جای شکست تمیز، معلق بماند.

اگر هنوز گیر کرده‌اید، فهرست را به ترتیب دنبال کنید و در نخستین گامی که شکست می‌خورد بایستید: درگاه دسترس‌پذیر، کلاینت پروتکل نصب‌شده، اشتراک احراز هویت‌شده، انتخابگر فایل را نشان می‌دهد، ویرایشگر URI را می‌پذیرد، ذخیره روی سرور می‌نشیند. آن گام می‌گوید کدام مؤلفه را باید درست کنید، و به‌ندرت خود تونل است.