Android no puede abrir archivos en el recurso compartido por VPN

El teléfono está en la VPN, el servidor de archivos responde a un ping, y la aplicación de archivos sigue diciendo que no puede conectar; o conecta y ningún editor del dispositivo abre lo que lista. Son dos fallos distintos y ninguno significa que el túnel esté roto. Una VPN solo aporta una ruta hacia la red privada; explorar un recurso, autenticarse en él y entregar un documento a otra aplicación son pasos separados con formas de fallar separadas. Abajo está el orden en que los compruebo y el punto en que me detengo en lugar de adivinar.

Compruebe el servicio antes de culpar al túnel

Una respuesta a un ping o la página web del NAS demuestran el enrutamiento y nada más. El servicio que realmente necesita, SMB en el 445, SFTP en el 22 o WebDAV en el 443, puede estar desactivado, bloqueado por el cortafuegos o ligado a una interfaz que la subred de la VPN no alcanza. Desde el teléfono pruebe ese puerto concreto con un cliente que muestre el error real y no un aviso genérico de red. Si el puerto está filtrado, arregle el servicio o la regla del cortafuegos, porque ninguna aplicación puede sortear un puerto cerrado.

Compruebe también qué dirección de origen ve el servidor. Un túnel dividido que excluye la subred del recurso, o un túnel por aplicación que deja la aplicación de archivos fuera de la VPN, produce exactamente el síntoma de conectado pero inaccesible.

No tome el atajo de habilitar el acceso de invitado o SMB1 porque un cliente no puede autenticarse. Esos cambios amplían lo que el servidor acepta para cada dispositivo de la red y no arreglan nada si el problema de fondo es el enrutamiento o la resolución de nombres.

Use una aplicación de archivos que hable el protocolo por sí misma

Android no tiene un navegador integrado para recursos de red, así que la aplicación cliente es una dependencia real y no un detalle. Elija una que implemente el protocolo que realmente usa y siga mantenida, porque un cliente hecho para una versión de Android que ya no usa falla de formas que parecen averías de red.

Pruebe el servidor por IP una vez para separar el DNS del enrutamiento. Si la IP funciona y el nombre no, el teléfono resuelve mediante un servidor DNS que no ve su zona privada.

Qué recibe la aplicación que abre: una URI, no una ruta

Si su aplicación de archivos implementa un DocumentsProvider, el Storage Access Framework de Android puede mostrar su contenido en el selector del sistema, y la aplicación que elija recibe una URI content:// junto con un permiso. Ese permiso no es una ruta del sistema de archivos, por eso un editor que exige una ruta cruda no puede abrir el documento. La guía de acceso a documentos de Android describe el modelo: el proveedor posee los bytes y el consumidor los lee a través del sistema.

La alternativa es una copia deliberada: llevar el archivo al almacenamiento propio del editor, editarlo y volver a subirlo. Es un buen flujo de trabajo, pero crea una segunda copia y una cuestión de conflicto, así que decida qué lado gana antes de empezar a editar en un tren.

La política de VPN por aplicación también merece una mirada. El paquete que hace la lectura de red suele ser la aplicación proveedora y no el editor, así que incluya el paquete correcto en el túnel en lugar de juzgar por el icono.

Pruebe lectura, escritura y persistencia del permiso por separado

Un listado de directorio solo demuestra la ruta de lectura. Use un archivo de prueba inofensivo y recorra toda la secuencia: listar, abrir, editar, guardar y volver a abrir el mismo archivo desde un cliente de escritorio.

Vigile si el permiso persiste tras un reinicio. Los permisos de almacenamiento son temporales salvo que la aplicación los haga persistentes, y algunos editores los vuelven a pedir en cada arranque mientras otros fallan en silencio y le muestran una copia antigua. Si un guardado parece correcto, confírmelo en el servidor mirando la hora de modificación.

Mantenga el permiso de URI de Android separado de la autorización del servidor. Que se le permita abrir un documento no dice nada de la cuenta SMB que hay detrás.

Reserve los recursos montados para los casos que los necesitan

Los montajes CIFS a nivel de raíz y los módulos de sistema de archivos del núcleo todavía existen y dan a cada aplicación la ilusión de un directorio local. También exigen root, se rompen con los cambios de núcleo y esconden los fallos de red en la capa del sistema de archivos, donde son más difíciles de diagnosticar.

Compruebe si el montaje sobrevive a un cambio de red antes de construir un flujo de trabajo sobre él. Un recurso montado desde un portátil en una mesa se comporta distinto de un teléfono que salta entre Wi-Fi y móvil, y un montaje antiguo puede colgar una aplicación.

Si sigue atascado, recorra la lista en orden y deténgase en el primer paso que falle: puerto accesible, cliente del protocolo instalado, recurso autenticado, selector muestra el archivo, editor acepta la URI, guardado llega al servidor. Ese paso le dice qué componente arreglar, y rara vez es el túnel.