Uppladdningen ser skadad ut: jämför hashar i båda ändar

Mottagare som inte kan öppna en uppladdad fil hör ofta att VPN:en förstörde den. Det är en hypotes, inte en observation, och den går att testa. Innan du rör tunneln, avgör om objektet som nu ligger på destinationen skiljer sig från objektet som skulle skickas. Allt annat följer av det svaret.

Börja med de avsedda byten, inte med klagomålet

Välj en ofarlig fil som återskapar problemet, eller den faktiska filen om policyn tillåter att den lämnar källmiljön. Anteckna två saker före överföringen: den exakta storleken i byte och en modern innehållshash. Filnamn, tidsstämplar och förhandsvisningar är metadata, och ingen av dem identifierar innehållet.

Beräkna hashen med en algoritm som båda ändar kan köra, och skriv ned vilken du använde. En jämförelse mellan SHA-256 och MD5 är ingen jämförelse, och en jämförelse mellan två olika filer som råkar dela namn är det inte heller.

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

Microsofts Get-FileHash-referens dokumenterar kommandot och dess algoritmparameter, just den del folk hoppar över när en jämförelse ger en meningslös avvikelse.

En hash per steg, samma algoritm

Beräkna nu samma algoritm på det lagrade objektet där det till slut ligger, med en auktoriserad metod i stället för en kopia som gått genom ett annat verktyg. Att spara den mottagna filen lokalt och hasha den kopian lägger till ett steg du inte har testat.

Om tjänsten visar ett eget integritetsvärde, behandla det som en separat observation. En kontrollsumma som leverantören rapporterar kan berätta vad leverantören tror att den har lagrat, och det är inte samma påstående som det din klient skickade.

Tre utfall är möjliga, och de pekar i olika riktningar. Lika hashar betyder att byten kom fram oförändrade. Olika hashar med en känd konvertering betyder att tjänsten avsiktligt skapade ett nytt objekt. Olika hashar utan konvertering betyder att något mellan de två punkterna ändrade innehållet, och nästa steg är att hitta den tidigaste gränsen där det hände.

Skilj överföringsfel från transformering

En delvis uppladdning och en skadad uppladdning ser identiska ut i en filbläddrare och är olika fel. Kontrollera om överföringen slutfördes: en applikationslogg som visar en avbruten begäran, en lagrad fil vars storlek är ett prefix av källan, eller ett objekt som faktiskt är en felsida sparad under det förväntade filnamnstillägget, allt tyder på en ofullständig överföring snarare än ändrade byte.

Transformering är den andra vanliga förklaringen. En tjänst som komprimerar om bilder, skriver om CSV-radslut eller konverterar ett dokument kommer med rätta att producera en hash som skiljer sig från källan, och det är inte korruption. Jämför steget som hävdar att det är den trogna kopian, inte det slutliga presentationsformatet.

Fördröjning och förlust hör till en tredje kategori. De kan få en klient att timeouta, försöka igen eller ge upp, och inget av det innebär att byte som servern tog emot ändrades i tysthet. Titta på överföringsresultatet innan du tillskriver tunneln något.

Prova en andra väg utan att ändra allt

Om hasharna verkligen skiljer sig och ingen konvertering är inblandad, upprepa samma fil, klient, protokoll och destination över en annan stödd väg, till exempel ett lokalt nätverk i stället för VPN:en. Ändra en variabel. Att ändra klienten, slutpunkten och verktyget på en gång ger dig ett resultat du inte kan tillskriva.

Håll jämförelsen ärlig i båda riktningarna. En hash berättar att två punkter är oense eller ense om innehållet; den berättar inte vilken sida som är pålitlig, så håll det förväntade värdet och verifieringen inom den tillitsmodell du faktiskt använder.

Avsluta med en konkret mening i ärendet: överföringen stoppade tidigt, applikationen transformerade objektet, lagringen ändrade det, eller byten stämmer och det är läsningen som är felet. Var och en av dessa har en annan ägare, och ingen av dem är VPN:en som standard.