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, сохранение доходит до сервера. Этот шаг говорит, какой компонент чинить, и это редко туннель.