Příjemci, kteří nemohou otevřít nahraný soubor, často slýchají, že ho VPN poškodila. To je hypotéza, ne pozorování, a je testovatelná. Než se dotknete tunelu, zjistěte, zda se objekt nyní uložený v cíli liší od objektu, který měl být odeslán. Všechno ostatní z té odpovědi vyplývá.

Začněte zamýšlenými bajty, ne stížností

Vyberte neškodný soubor, který problém reprodukuje, nebo skutečný soubor, pokud zásady dovolují, aby opustil zdrojové prostředí. Před přenosem si poznamenejte dvě věci: přesnou velikost v bajtech a moderní hash obsahu. Názvy souborů, časová razítka a náhledy jsou metadata a žádné z nich obsah neidentifikuje.

Vypočítejte hash algoritmem, který zvládnou obě strany, a zapište, který jste použili. Srovnání mezi SHA-256 a MD5 není srovnání a srovnání mezi dvěma různými soubory, které náhodou sdílejí název, také ne.

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

Referenční dokumentace Microsoftu k Get-FileHash popisuje příkaz a jeho parametr algoritmu, přesně tu část, kterou lidé vynechávají, když srovnání vyprodukuje nesmyslnou neshodu.

Jeden hash na fázi, stejný algoritmus

Nyní vypočítejte stejný algoritmus na uloženém objektu tam, kde nakonec žije, autorizovanou metodou, ne na kopii, která prošla jiným nástrojem. Uložení přijatého souboru lokálně a hashování této kopie přidává krok, který jste netestovali.

Pokud služba zveřejňuje vlastní hodnotu integrity, berte ji jako samostatné pozorování. Kontrolní součet, který poskytovatel uvádí, vám může říct, co si poskytovatel myslí, že uložil, a to není stejné tvrzení jako to, co odeslal váš klient.

Možné jsou tři výsledky a ukazují různými směry. Stejné hashe znamenají, že bajty dorazily nezměněné. Různé hashe se známou konverzí znamenají, že služba záměrně vytvořila nový objekt. Různé hashe bez konverze znamenají, že něco mezi oběma body obsah změnilo, a dalším krokem je najít nejčasnější hranici, kde se to stalo.

Oddělte selhání přenosu od transformace

Částečné nahrání a poškozené nahrání vypadají v prohlížeči souborů stejně a jsou to různé závady. Zkontrolujte, zda se přenos dokončil: log aplikace ukazující přerušený požadavek, uložený soubor, jehož velikost je prefixem zdroje, nebo objekt, který je ve skutečnosti chybovou stránkou uloženou pod očekávanou příponou, to všechno ukazuje na neúplný přenos, ne na změněné bajty.

Transformace je druhé běžné vysvětlení. Služba, která znovu komprimuje obrázky, přepisuje konce řádků CSV nebo konvertuje dokument, oprávněně vytvoří hash odlišný od zdroje, a to není poškození. Porovnávejte fázi, která tvrdí, že je věrnou kopií, ne konečný prezentační formát.

Zpoždění a ztráta patří do třetí kategorie. Mohou způsobit, že klient vyprší, zkusí to znovu nebo to vzdá, a nic z toho neznamená, že bajty přijaté serverem byly tiše změněny. Podívejte se na výsledek přenosu, než něco přisoudíte tunelu.

Zkuste druhou cestu, aniž byste měnili všechno

Pokud se hashe opravdu liší a žádná konverze neprobíhá, zopakujte stejný soubor, klienta, protokol a cíl po jiné podporované cestě, třeba přes místní síť místo VPN. Změňte jednu proměnnou. Změna klienta, koncového bodu a nástroje najednou vám dá výsledek, který nemůžete ničemu přisoudit.

Udržujte srovnání poctivé v obou směrech. Hash vám říká, že dva body se o obsahu rozcházejí nebo shodují; neříká, která strana je důvěryhodná, proto držte očekávanou hodnotu a ověření uvnitř modelu důvěry, na který skutečně spoléháte.

Skončete konkrétní větou v tiketu: přenos se zastavil brzy, aplikace objekt transformovala, úložiště ho změnilo, nebo se bajty shodují a jejich čtení je ta závada. Každá z těch možností má jiného vlastníka a žádná z nich není ve výchozím nastavení VPN.

Související články