אנדרואיד לא פותח קבצים בשיתוף הרשת عبر VPN

הטלפון מחובר ל-VPN, שרת הקבצים עונה לפינג, ואפליקציית הקבצים עדיין מדווחת שאינה מצליחה להתחבר, או שהיא מתחברת ואף עורך במכשיר לא פותח את מה שהיא מציגה. אלו שני כשלים שונים, ואף אחד מהם אינו אומר שהמנהרה שבורה. VPN מספק רק מסלול אל הרשת הפרטית; גלישה בשיתוף, אימות מולו והעברת מסמך לאפליקציה אחרת הם שלבים נפרדים עם דרכי כשל נפרדות. להלן הסדר שבו אני בודק אותם, והנקודה שבה אני עוצר במקום לנחש.

בדקו את השירות לפני שאתם מאשימים את המנהרה

תשובת פינג או דף האינטרנט של ה-NAS מוכיחים ניתוב ולא יותר מזה. השירות שאתם באמת צריכים, SMB בפורט 445, SFTP בפורט 22 או WebDAV בפורט 443, עשוי להיות מושבת, חסום בחומת אש, או קשור לממשק שאליו תת-הרשת של ה-VPN לא מגיעה. מהטלפון, בדקו את הפורט הספציפי עם לקוח שמציג את השגיאה האמיתית ולא באנר רשת גנרי. אם הפורט מסונן, תקנו את השירות או את כלל חומת האש, כי אף אפליקציית קבצים לא יכולה לעקוף פורט סגור.

בדקו גם איזו כתובת מקור השרת רואה. מנהרה מפוצלת שמחריגה את תת-הרשת של השיתוף, או מנהרה לפי אפליקציה שמשאירה את אפליקציית הקבצים מחוץ ל-VPN, יוצרות בדיוק את התסמין של מחובר אך לא נגיש.

התנגדו לקיצור הדרך של הפעלת גישת אורחים או SMB1 משום שלקוח אחד לא מצליח לאמת. השינויים האלה מרחיבים את מה שהשרת מקבל מכל מכשיר ברשת, והם לא מתקנים דבר אם הבעיה הבסיסית היא ניתוב או פתרון שמות. אם השיתוף דורש חשבון ספציפי, השתמשו בו, כולל קידומת הדומיין או קבוצת העבודה שהשרת מצפה לה.

השתמשו באפליקציית קבצים שמדברת את הפרוטוקול בעצמה

לאנדרואיד אין דפדפן מובנה לשיתופי רשת, ולכן אפליקציית הלקוח היא תלות אמיתית ולא פרט שולי. בחרו אחת שמיישמת את הפרוטוקול שאתם באמת מריצים ועדיין מתוחזקת, כי לקוח שנבנה למהדורת אנדרואיד שאינכם משתמשים בה יותר נכשל בדרכים שנראות כמו תקלות רשת. כשאיתור אוטומטי לא חוצה תת-רשתות, הקלידו את המארח במפורש במקום לחכות שהאפליקציה תמצא אותו.

נסו את השרת לפי IP פעם אחת כדי להפריד בין DNS לניתוב. אם ה-IP עובד והשם לא, הטלפון מפענח דרך שרת DNS שאינו רואה את האזור הפרטי שלכם.

דעו מה מקבלת האפליקציה המקבלת: URI, לא נתיב

אם אפליקציית הקבצים שלכם מיישמת DocumentsProvider, מסגרת הגישה לאחסון של אנדרואיד (Storage Access Framework) יכולה להציג את תוכנה בבורר המערכת, והאפליקציה שאתם בוחרים ממנה מקבלת URI מסוג content:// בתוספת הרשאת גישה. ההרשאה הזו אינה נתיב במערכת הקבצים, ולכן עורך שמתעקש על שם נתיב גולמי לא יכול לפתוח את המסמך למרות שהבורר הציג אותו. מדריך הגישה למסמכים של אנדרואיד מתאר את המודל: הספק מחזיק את הבייטים והצרכן קורא אותם דרך המערכת. אפליקציות שמקבלות את ה-URI עובדות, ואפליקציות שקוראות open() על נתיב לא. זו הסיבה הנפוצה ביותר לכך ששיתוף עובד באפליקציית הקבצים ונכשל בכל מקום אחר.

החלופה היא העתקה מכוונת: משכו את הקובץ לאחסון של העורך עצמו, ערכו אותו, ואז העלו אותו בחזרה. זה זרם עבודה סביר, אבל הוא יוצר עותק שני ושאלת התנגשות, אז החליטו איזה צד מנצח לפני שתתחילו לערוך ברכבת.

גם למדיניות VPN לפי אפליקציה מגיע מבט כאן. החבילה שמבצעת את קריאת הרשת היא לרוב אפליקציית הספק ולא העורך, אז כללו את החבילה הנכונה במנהרה במקום לשפוט לפי הסמל שהקלקתם עליו.

בדקו קריאה, כתיבה והתמדת הרשאות בנפרד

רשימת ספרייה מוכיחה רק את מסלול הקריאה. השתמשו בקובץ בדיקה לא מזיק ועברו את כל הרצף: הצגה, פתיחה, עריכה, שמירה, ואז פתיחה מחדש של אותו קובץ מלקוח שולחני.

שימו לב להתמדת ההרשאות אחרי אתחול מחדש. הרשאות אחסון הן זמניות אלא אם האפליקציה מקבלת אותן באופן מתמשך, וכמה עורכים מבקשים אותן מחדש בכל הפעלה בעוד אחרים נכשלים בשקט ומציגים לכם עותק מיושן. אם שמירה נראית מוצלחת, אמתו אותה בצד השרת על ידי בדיקת זמן השינוי או פתיחה ממכונה אחרת. בדקו גם ניתוק באמצע השמירה, כי נפילת VPN בזמן העלאה היא בדיוק הרגע שבו לקוח עלול להשאיר קובץ חלקי או שינוי מקומי שלעולם לא מסתנכרן.

הפרידו בין הרשאת ה-URI של אנדרואיד לבין ההרשאה של השרת. ההרשאה לפתוח מסמך אינה אומרת דבר על חשבון ה-SMB שמאחוריו.

שמרו שיתופים מעוגנים למקרים שצריכים אותם

עיגוני CIFS ברמת השורש ומודולי מערכת קבצים בקרנל עדיין קיימים, והם נותנים לכל אפליקציה אשליה של ספרייה מקומית. הם גם דורשים הרשאות שורש, נשברים בשינויי קרנל, ומסתירים כשלי רשת בתוך שכבת מערכת הקבצים שבה קשה יותר לאבחן אותם. לעריכת מסמכים בטלפון, זרם העבודה של ספק או העתקה מכסה את רוב מה שאנשים באמת צריכים.

בדקו אם העיגון שורד שינוי רשת לפני שאתם בונים עליה זרם עבודה. שיתוף שמעוגן ממחשב נייד על שולחן מתנהג אחרת מטלפון שמדלג בין Wi-Fi לסלולר, ועיגון מיושן יכולה לגרום לאפליקציה להיתקע במקום להיכשל בצורה נקייה.

אם אתם עדיין תקועים, עברו על הרשימה לפי הסדר ועצרו בשלב הראשון שנכשל: הפורט נגיש, לקוח הפרוטוקול מותקן, השיתוף מאומת, הבורר מציג את הקובץ, העורך מקבל את ה-URI, השמירה נוחתת בשרת. השלב הזה אומר לכם איזה רכיב לתקן, והוא כמעט אף פעם לא המנהרה.