Android non pode abrir ficheiros no recurso compartido por VPN

O teléfono está na VPN, o servidor de ficheiros responde a un ping, e a aplicación de ficheiros segue dicindo que non pode conectar; ou conecta e ningún editor do dispositivo abre o que lista. Son dous fallos distintos e ningún significa que o túnel estea roto. Unha VPN só achega unha ruta cara á rede privada; explorar un recurso, autenticarse nel e entregar un documento a outra aplicación son pasos separados con xeitos de fallar separados. Abaixo está a orde na que os comprobo e o punto no que me deteño en lugar de adiviñar.

Comprobe o servizo antes de culpar o túnel

Unha resposta a un ping ou a páxina web do NAS demostran o encamiñamento e nada máis. O servizo que realmente necesita, SMB no 445, SFTP no 22 ou WebDAV no 443, pode estar desactivado, bloqueado pola devasa ou ligado a unha interface que a subrede da VPN non acada. Desde o teléfono probe ese porto concreto cun cliente que mostre o erro real e non un aviso xenérico de rede. Se o porto está filtrado, arranxe o servizo ou a regra da devasa, porque ningunha aplicación pode sortear un porto pechado.

Comprobe tamén que enderezo de orixe ve o servidor. Un túnel dividido que exclúe a subrede do recurso, ou un túnel por aplicación que deixa a aplicación de ficheiros fóra da VPN, produce exactamente o síntoma de conectado pero inaccesible.

Non tome o atallo de activar o acceso de convidados ou SMB1 porque un cliente non pode autenticarse. Eses cambios amplían o que o servidor acepta para cada dispositivo da rede e non arranxan nada se o problema de fondo é o encamiñamento ou a resolución de nomes.

Use unha aplicación de ficheiros que fale o protocolo por si mesma

Android non ten un navegador integrado para recursos de rede, así que a aplicación cliente é unha dependencia real e non un detalle. Escolla unha que implemente o protocolo que realmente usa e siga mantida, porque un cliente feito para unha versión de Android que xa non usa falla de xeitos que parecen avarías de rede.

Probe o servidor por IP unha vez para separar o DNS do encamiñamento. Se o IP funciona e o nome non, o teléfono resolve mediante un servidor DNS que non ve a súa zona privada.

Que recibe a aplicación que abre: unha URI, non unha ruta

Se a súa aplicación de ficheiros implementa un DocumentsProvider, o Storage Access Framework de Android pode mostrar o seu contido no selector do sistema, e a aplicación que escolla recibe unha URI content:// xunto cun permiso. Ese permiso non é unha ruta do sistema de ficheiros, por iso un editor que esixe unha ruta cru non pode abrir o documento. A guía de acceso a documentos de Android describe o modelo: o provedor posúe os bytes e o consumidor léelos a través do sistema.

A alternativa é unha copia deliberada: levar o ficheiro ao almacenamento propio do editor, editalo e volver subilo. É un bo fluxo de traballo, pero crea unha segunda copia e unha cuestión de conflito, así que decida que lado gaña antes de comezar a editar nun tren.

A política de VPN por aplicación tamén merece unha ollada. O paquete que fai a lectura de rede adoita ser a aplicación provedora e non o editor, así que inclúa o paquete correcto no túnel en lugar de xulgar pola icona.

Probe lectura, escritura e persistencia do permiso por separado

Unha listaxe de directorio só demostra a ruta de lectura. Use un ficheiro de proba inofensivo e percorra toda a secuencia: listar, abrir, editar, gardar e volver abrir o mesmo ficheiro desde un cliente de escritorio.

Vixíe se o permiso persiste tras un reinicio. Os permisos de almacenamento son temporais salvo que a aplicación os faga persistentes, e algúns editores volven pedilos en cada arranque mentres outros fallan en silencio e móstranlle unha copia vella. Se un gardado parece correcto, confírmelo no servidor mirando a hora de modificación.

Manteña o permiso de URI de Android separado da autorización do servidor. Que se lle permita abrir un documento non di nada da conta SMB que hai detrás.

Reserve os recursos montados para os casos que os necesitan

As montaxes CIFS a nivel de raíz e os módulos de sistema de ficheiros do núcleo aínda existen e dan a cada aplicación a ilusión dun directorio local. Tamén esixen root, rompen cos cambios de núcleo e agochan os fallos de rede na capa do sistema de ficheiros, onde son máis difíciles de diagnosticar.

Comprobe se a montaxe sobrevive a un cambio de rede antes de construír un fluxo de traballo sobre ela. Un recurso montado desde un portátil nunha mesa compórtase distinto dun teléfono que salta entre Wi-Fi e móbil, e unha montaxe antiga pode colgar unha aplicación.

Se segue atascado, percorra a lista en orde e detéñase no primeiro paso que falle: porto accesible, cliente do protocolo instalado, recurso autenticado, selector mostra o ficheiro, editor acepta a URI, gardado chega ao servidor. Ese paso dille que compoñente arranxar, e raramente é o túnel.