O Android não abre arquivos no compartilhamento de arquivos da VPN

O telefone está na VPN, o servidor de arquivos responde a um ping, e ainda assim o aplicativo de arquivos informa que não consegue conectar, ou conecta e nenhum editor no aparelho abre o que ele lista. São duas falhas diferentes, e nenhuma delas significa que o túnel está quebrado. Uma VPN fornece apenas uma rota para a rede privada; navegar por um compartilhamento, autenticar-se nele e entregar um documento a outro aplicativo são etapas separadas, com maneiras separadas de falhar. A seguir está a ordem em que eu as verifico, e o ponto em que paro em vez de adivinhar.

Verifique o serviço antes de culpar o túnel

Uma resposta de ping ou a página web do NAS prova apenas o roteamento e nada mais. O serviço de que você realmente precisa, SMB na 445, SFTP na 22 ou WebDAV na 443, pode estar desativado, bloqueado pelo firewall ou vinculado a uma interface que a sub-rede da VPN não alcança. No telefone, teste essa porta específica com um cliente que mostre o erro real em vez de um aviso genérico de rede. Se a porta estiver filtrada, corrija o serviço ou a regra do firewall, porque nenhum aplicativo de arquivos contorna uma porta fechada.

Verifique também qual endereço de origem o servidor vê. Um túnel dividido que exclui a sub-rede do compartilhamento, ou um túnel por aplicativo que deixa o aplicativo de arquivos fora da VPN, produz exatamente o sintoma de conectado mas inacessível.

Resista ao atalho de habilitar acesso de convidado ou SMB1 porque um cliente não consegue autenticar. Essas mudanças ampliam o que o servidor aceita de cada dispositivo da rede, e não corrigem nada se o problema de fundo for roteamento ou resolução de nomes. Se o compartilhamento exige uma conta específica, use-a, incluindo o prefixo de domínio ou grupo de trabalho que o servidor espera.

Use um aplicativo de arquivos que fale o protocolo por conta própria

O Android não tem navegador embutido para compartilhamentos de rede, então o aplicativo cliente é uma dependência real, não um detalhe. Escolha um que implemente o protocolo que você realmente usa e que ainda seja mantido, porque um cliente feito para uma versão do Android que você não usa mais falha de maneiras que parecem defeitos de rede. Quando a descoberta não atravessa sub-redes, digite o host explicitamente em vez de esperar que o aplicativo o encontre.

Experimente o servidor por IP uma vez para separar DNS de roteamento. Se o IP funciona e o nome não, o telefone está resolvendo por um servidor DNS que não enxerga sua zona privada.

Saiba o que o aplicativo receptor recebe: um URI, não um caminho

Se o seu aplicativo de arquivos implementa um DocumentsProvider, o Storage Access Framework do Android pode mostrar o conteúdo no seletor do sistema, e o aplicativo que você escolhe recebe um URI content:// mais uma concessão de permissão. Essa concessão não é um caminho de sistema de arquivos, e é por isso que um editor que exige um nome de caminho bruto não abre o documento, embora o seletor o tenha listado. O guia de acesso a documentos do Android descreve o modelo: o provedor é dono dos bytes e o consumidor os lê pelo sistema. Aplicativos que aceitam o URI funcionam, e aplicativos que chamam open() em um caminho não. Esta é a razão mais comum de um compartilhamento funcionar no aplicativo de arquivos e falhar em todo o resto.

A alternativa é uma cópia deliberada: trazer o arquivo para o armazenamento do próprio editor, editá-lo e enviá-lo de volta. É um fluxo de trabalho perfeitamente bom, mas cria uma segunda cópia e uma questão de conflito, então decida qual lado vence antes de começar a editar no trem.

A política de VPN por aplicativo também merece atenção aqui. O pacote que faz a leitura de rede costuma ser o aplicativo provedor, e não o editor, então inclua o pacote certo no túnel em vez de julgar pelo ícone que você tocou.

Teste leitura, escrita e persistência de permissão separadamente

Uma listagem de diretório prova apenas o caminho de leitura. Use um arquivo de teste inofensivo e percorra a sequência inteira: listar, abrir, editar, salvar e depois reabrir o mesmo arquivo em um cliente de desktop.

Observe a persistência da permissão após uma reinicialização. Concessões de armazenamento são temporárias a menos que o aplicativo as adote de forma persistente, e alguns editores pedem de novo a cada inicialização enquanto outros falham em silêncio e mostram uma cópia desatualizada. Se um salvamento parecer bem-sucedido, confirme no lado do servidor verificando o horário de modificação ou reabrindo de outra máquina. Teste também uma desconexão no meio do salvamento, porque uma queda da VPN durante um envio é exatamente o momento em que um cliente tem mais chance de deixar um arquivo parcial ou uma alteração local que nunca sincroniza.

Mantenha a permissão de URI do Android separada da autorização no servidor. Poder abrir um documento não diz nada sobre a conta SMB por trás dele.

Reserve compartilhamentos montados para os casos que precisam deles

Montagens CIFS no nível de root e módulos de sistema de arquivos do kernel ainda existem, e dão a todo aplicativo a ilusão de um diretório local. Também exigem root, quebram com mudanças no kernel e escondem falhas de rede dentro da camada de sistema de arquivos, onde são mais difíceis de diagnosticar. Para editar documentos em um telefone, o fluxo de provedor ou de cópia cobre a maior parte do que as pessoas realmente precisam.

Verifique se a montagem sobrevive a uma mudança de rede antes de construir um fluxo de trabalho sobre ela. Um compartilhamento montado a partir de um notebook em uma mesa se comporta de forma diferente de um telefone que alterna entre Wi-Fi e rede móvel, e uma montagem obsoleta pode travar um aplicativo em vez de falhar de forma limpa.

Se você ainda estiver travado, percorra a lista em ordem e pare no primeiro passo que falhar: porta alcançável, cliente de protocolo instalado, compartilhamento autenticado, seletor mostra o arquivo, editor aceita o URI, salvamento chega ao servidor. Esse passo diz qual componente corrigir, e raramente é o túnel.