O envio parece corrompido: compare os hashes nas duas pontas

Quem não consegue abrir um ficheiro enviado ouve muitas vezes que a VPN o corrompeu. Isso é uma hipótese, não uma observação, e é testável. Antes de tocar no túnel, estabeleça se o objeto agora armazenado no destino difere do objeto que devia ser enviado. Tudo o resto decorre dessa resposta.

Comece pelos bytes previstos, não pela queixa

Escolha um ficheiro inofensivo que reproduza o problema, ou o ficheiro real se a política permitir que saia do ambiente de origem. Anote duas coisas antes da transferência: o tamanho exato em bytes e um hash de conteúdo moderno. Nomes de ficheiros, marcas temporais e pré-visualizações são metadados, e nenhum deles identifica o conteúdo.

Calcule o hash com um algoritmo que ambas as pontas possam executar e anote qual usou. Uma comparação entre SHA-256 e MD5 não é uma comparação, e também não o é uma comparação entre dois ficheiros diferentes que partilham nome por acaso.

PS> Get-FileHash -LiteralPath "C:\uploads\report.csv" -Algorithm SHA256
Hash                                                        Path
----                                                        ----
9F2C...                                                      C:\uploads\report.csv

A referência Get-FileHash da Microsoft documenta o comando e o seu parâmetro de algoritmo, precisamente a parte que as pessoas saltam quando uma comparação produz uma discrepância sem sentido.

Um hash por etapa, o mesmo algoritmo

Agora calcule o mesmo algoritmo sobre o objeto armazenado onde ele finalmente vive, com um método autorizado e não com uma cópia que passou por outra ferramenta. Guardar o ficheiro recebido localmente e aplicar o hash a essa cópia acrescenta um passo que não testou.

Se o serviço expõe um valor de integridade próprio, trate-o como uma observação separada. A soma de verificação comunicada pelo fornecedor pode dizer-lhe o que o fornecedor pensa ter armazenado, e não é a mesma afirmação que a do que o seu cliente enviou.

São possíveis três resultados, e apontam em direções diferentes. Hashes iguais significam que os bytes chegaram sem alterações. Hashes diferentes com uma conversão conhecida significam que o serviço produziu intencionalmente um objeto novo. Hashes diferentes sem conversão significam que algo entre os dois pontos alterou o conteúdo, e o passo seguinte é encontrar a fronteira mais precoce onde isso aconteceu.

Separe a falha de transferência da transformação

Um envio parcial e um envio corrompido parecem idênticos num navegador de ficheiros e são falhas diferentes. Verifique se a transferência terminou: um registo da aplicação que mostra um pedido abortado, um ficheiro armazenado cujo tamanho é um prefixo da origem, ou um objeto que na realidade é uma página de erro guardada com a extensão esperada, todos indicam uma transferência incompleta e não bytes alterados.

A transformação é a outra explicação comum. Um serviço que recomprime imagens, reescreve os fins de linha de um CSV ou converte um documento produzirá legitimamente um hash diferente do da origem, e isso não é corrupção. Compare a etapa que afirma ser a cópia fiel, não o formato de apresentação final.

O atraso e a perda pertencem a uma terceira categoria. Podem fazer um cliente exceder o tempo, tentar de novo ou desistir, e nada disso implica que os bytes aceites pelo servidor tenham sido alterados em silêncio. Olhe para o resultado da transferência antes de atribuir algo ao túnel.

Experimente um segundo caminho sem mudar tudo

Se os hashes realmente diferem e não há conversão, repita o mesmo ficheiro, cliente, protocolo e destino por outro caminho suportado, como uma rede local em vez da VPN. Mude uma variável. Mudar o cliente, o ponto final e a ferramenta ao mesmo tempo dá-lhe um resultado que não pode atribuir.

Mantenha a comparação honesta nos dois sentidos. Um hash diz-lhe que dois pontos discordam ou concordam quanto ao conteúdo; não lhe diz qual lado é fidedigno, por isso mantenha o valor esperado e a verificação dentro do modelo de confiança em que realmente confia.

Termine com uma frase concreta no ticket: a transferência parou cedo, a aplicação transformou o objeto, o armazenamento alterou-o, ou os bytes coincidem e lê-los é a falha. Cada uma dessas tem um responsável diferente, e nenhuma delas é a VPN por omissão.