Android non apre i file nella condivisione VPN

Il telefono è sulla VPN, il server file risponde a un ping, e l’app file continua a dire che non riesce a connettersi; oppure si connette e nessun editor del dispositivo apre ciò che elenca. Sono due guasti diversi e nessuno dei due significa che il tunnel sia rotto. Una VPN fornisce solo una rotta verso la rete privata; sfogliare una condivisione, autenticarsi su di essa e consegnare un documento a un’altra app sono passaggi separati con modi di fallire separati. Qui sotto l’ordine in cui li controllo e il punto in cui mi fermo invece di tirare a indovinare.

Controllate il servizio prima di dare la colpa al tunnel

Una risposta a un ping o la pagina web del NAS dimostrano solo l’instradamento e nulla più. Il servizio che vi serve davvero, SMB sulla 445, SFTP sulla 22 o WebDAV sulla 443, può essere disattivato, bloccato dal firewall o legato a un’interfaccia che la sottorete della VPN non raggiunge. Dal telefono provate proprio quella porta con un client che mostra l’errore reale invece di un generico avviso di rete. Se la porta è filtrata, sistemate il servizio o la regola del firewall, perché nessuna app file aggira una porta chiusa.

Controllate anche quale indirizzo sorgente vede il server. Un tunnel diviso che esclude la sottorete della condivisione, o un tunnel per app che lascia l’app file fuori dalla VPN, produce esattamente il sintomo connesso ma irraggiungibile.

Non prendete la scorciatoia di abilitare l’accesso ospite o SMB1 perché un client non riesce ad autenticarsi. Questi cambiamenti ampliano ciò che il server accetta per ogni dispositivo della rete e non risolvono nulla se il problema di fondo è l’instradamento o la risoluzione dei nomi.

Usate un’app file che parla il protocollo da sola

Android non ha un browser integrato per le condivisioni di rete, quindi l’app client è una dipendenza reale e non un dettaglio. Sceglietene una che implementi il protocollo che usate davvero e sia ancora mantenuta, perché un client costruito per una versione di Android che non usate più fallisce in modi che sembrano guasti di rete.

Provate il server per IP una volta per separare il DNS dall’instradamento. Se l’IP funziona e il nome no, il telefono risolve tramite un server DNS che non vede la vostra zona privata.

Cosa riceve l’app che apre: un URI, non un percorso

Se la vostra app file implementa un DocumentsProvider, lo Storage Access Framework di Android può mostrarne il contenuto nel selettore di sistema, e l’app che scegliete riceve un URI content:// con un’autorizzazione. Quell’autorizzazione non è un percorso del file system, per questo un editor che esige un percorso grezzo non può aprire il documento. La guida Android all’accesso ai documenti descrive il modello: il provider possiede i byte e il consumatore li legge tramite il sistema.

L’alternativa è una copia deliberata: trascinare il file nello spazio dell’editor, modificarlo e ricaricarlo. È un buon flusso di lavoro, ma crea una seconda copia e una questione di conflitto, quindi decidete quale lato vince prima di iniziare a modificare in treno.

Anche la policy VPN per app merita uno sguardo. Il pacchetto che esegue la lettura di rete è spesso l’app provider e non l’editor, quindi includete il pacchetto giusto nel tunnel invece di giudicare dall’icona.

Provate lettura, scrittura e persistenza dell’autorizzazione separatamente

Un elenco di cartella prova solo il percorso di lettura. Usate un file di prova innocuo e percorrete tutta la sequenza: elencare, aprire, modificare, salvare, poi riaprire lo stesso file da un client desktop.

Controllate se l’autorizzazione sopravvive a un riavvio. Le autorizzazioni di archiviazione sono temporanee se l’app non le rende permanenti, e alcuni editor le richiedono a ogni avvio mentre altri falliscono in silenzio e vi mostrano una copia vecchia. Se un salvataggio sembra riuscito, confermatelo sul server guardando l’ora di modifica.

Tenete l’autorizzazione URI di Android separata dall’autorizzazione del server. Il permesso di aprire un documento non dice nulla sull’account SMB che c’è dietro.

Riservate le condivisioni montate ai casi che ne hanno bisogno

I mount CIFS a livello di root e i moduli del file system del kernel esistono ancora e danno a ogni app l’illusione di una cartella locale. Richiedono però root, si rompono con i cambi di kernel e nascondono i guasti di rete nello strato del file system, dove sono più difficili da diagnosticare.

Verificate se il mount sopravvive a un cambio di rete prima di costruirci un flusso di lavoro. Una condivisione montata da un portatile su una scrivania si comporta diversamente da un telefono che salta tra Wi-Fi e rete mobile, e un mount vecchio può bloccare un’app.

Se siete ancora bloccati, percorrete la lista in ordine e fermatevi al primo passo che fallisce: porta raggiungibile, client del protocollo installato, condivisione autenticata, selettore mostra il file, editor accetta l’URI, salvataggio arriva al server. Quel passo vi dice quale componente sistemare, e raramente è il tunnel.