Android не відкриває файли на файловому ресурсі через VPN

Телефон підключений до VPN, файловий сервер відповідає на ping, а застосунок для файлів усе одно повідомляє, що підключитися не вдається, або підключення є, але жоден редактор на пристрої не відкриває те, що він показує. Це дві різні несправності, і жодна з них не означає, що тунель зламано. VPN дає лише маршрут до приватної мережі; перегляд спільного ресурсу, автентифікація на ньому й передавання документа іншому застосунку це окремі кроки з окремими способами збою. Нижче порядок, у якому я їх перевіряю, і точка, де я зупиняюся замість того, щоб гадати.

Перевірте службу, перш ніж звинувачувати тунель

Відповідь на ping або вебсторінка NAS доводять лише маршрутизацію і більше нічого. Потрібна вам служба, SMB на 445, SFTP на 22 або WebDAV на 443, може бути вимкнена, заблокована міжмережевим екраном або прив'язана до інтерфейсу, до якого підмережа VPN не дістає. З телефона перевірте саме цей порт клієнтом, який показує справжню помилку, а не загальне мережеве повідомлення. Якщо порт фільтрується, виправте службу або правило міжмережевого екрана, бо жоден файловий застосунок не обійде закритий порт.

Перевірте також, яку адресу джерела бачить сервер. Роздільне тунелювання, що виключає підмережу ресурсу, або тунель на рівні застосунку, який залишає файловий застосунок поза VPN, дають рівно симптом підключено-але-недоступно.

Не піддавайтеся спокусі ввімкнути гостьовий доступ або SMB1 через те, що один клієнт не може автентифікуватися. Такі зміни розширюють те, що сервер приймає від кожного пристрою в мережі, і нічого не виправляють, якщо справжня причина це маршрутизація або розв'язання імен. Якщо ресурсу потрібен конкретний обліковий запис, використайте його, включно з префіксом домену або робочої групи, якого очікує сервер.

Використовуйте файловий застосунок, який сам говорить протоколом

В Android немає вбудованого переглядача мережевих ресурсів, тому клієнтський застосунок це справжня залежність, а не дрібниця. Виберіть той, що реалізує протокол, який ви справді використовуєте, і ще підтримується, бо клієнт, зібраний для версії Android, якою ви більше не користуєтеся, збоїть так, що це схоже на мережеві неполадки. Коли виявлення не проходить між підмережами, впишіть вузол явно, замість чекати, поки застосунок його знайде.

Один раз спробуйте сервер за IP, щоб відокремити DNS від маршрутизації. Якщо IP працює, а ім'я ні, телефон розв'язує імена через DNS-сервер, який не бачить вашої приватної зони.

Знайте, що отримує застосунок-одержувач: URI, а не шлях

Якщо ваш файловий застосунок реалізує DocumentsProvider, Storage Access Framework в Android може показати його вміст у системному засобі вибору, а застосунок, з якого ви вибираєте, отримує URI content:// і надання дозволу. Це надання не є шляхом у файловій системі, тому редактор, який вимагає сире ім'я шляху, не може відкрити документ, хоча засіб вибору його показав. Посібник Android з доступу до документів описує модель: постачальник володіє байтами, а споживач читає їх через систему. Застосунки, що приймають URI, працюють, а ті, що викликають open() на шляху, ні. Це найпоширеніша причина, чому ресурс працює у файловому застосунку і збоїть усюди інде.

Альтернатива це усвідомлене копіювання: затягніть файл у власне сховище редактора, відредагуйте його, а потім завантажте назад. Це цілком робочий процес, але він створює другу копію і питання конфлікту, тому вирішіть, чия сторона переможе, перш ніж почати редагувати в потязі.

Політика VPN для окремих застосунків теж заслуговує на увагу. Пакет, який виконує мережеве читання, часто є застосунком-постачальником, а не редактором, тому включіть у тунель правильний пакет, а не судіть за значком, якого торкнулися.

Перевіряйте читання, запис і збереження дозволів окремо

Перелік каталогу доводить лише шлях читання. Візьміть безпечний тестовий файл і пройдіть усю послідовність: перелік, відкриття, редагування, збереження, а потім повторне відкриття того самого файлу з настільного клієнта.

Стежте за збереженням дозволів після перезавантаження. Дозволи на сховище тимчасові, якщо застосунок не отримує їх постійно, і деякі редактори запитують їх щоразу під час запуску, тоді як інші тихо збоїть і показують застарілу копію. Якщо збереження виглядає успішним, підтвердьте його на боці сервера, перевіривши час зміни або відкривши файл з іншої машини. Перевірте й обрив посеред збереження, бо падіння VPN під час вивантаження це саме той момент, коли клієнт найчастіше залишає частковий файл або локальну зміну, яка ніколи не синхронізується.

Тримайте дозвіл URI в Android окремо від авторизації на сервері. Право відкрити документ нічого не говорить про обліковий запис SMB за ним.

Залиште змонтовані ресурси для випадків, яким вони потрібні

Монтування CIFS на рівні root і модулі файлових систем ядра все ще існують і дають кожному застосунку ілюзію локального каталогу. Вони також вимагають root, ламаються при змінах ядра і ховають мережеві збої всередині шару файлової системи, де їх важче діагностувати. Для редагування документів на телефоні процес із постачальником або копіюванням покриває більшу частину того, що людям справді потрібно.

Перевірте, чи переживає монтування зміну мережі, перш ніж будувати на ньому робочий процес. Ресурс, змонтований з ноутбука на столі, поводиться інакше, ніж телефон, що перемикається між Wi-Fi і стільниковою мережею, а застаріле монтування може підвісити застосунок замість чистого збою.

Якщо ви досі застрягли, пройдіть список по черзі й зупиніться на першому кроці, який збоїть: порт доступний, клієнт протоколу встановлений, ресурс автентифікований, засіб вибору показує файл, редактор приймає URI, збереження доходить до сервера. Цей крок каже, який компонент виправляти, і це рідко тунель.