گیرندگانی که نمی‌توانند فایل بارگذاری‌شده را باز کنند اغلب می‌شنوند که VPN آن را خراب کرده است. این یک فرضیه است نه مشاهده، و قابل آزمون است. پیش از دست زدن به تونل، مشخص کنید آیا شیئی که اکنون در مقصد ذخیره شده با شیئی که قرار بود فرستاده شود تفاوت دارد. هر چیز دیگری از همان پاسخ پیروی می‌کند.

با بایت‌های موردنظر شروع کنید، نه با شکایت

یک فایل بی‌خطر که مشکل را بازتولید می‌کند انتخاب کنید، یا اگر سیاست اجازه می‌دهد فایل واقعی را که محیط مبدأ را ترک کند. پیش از انتقال دو چیز را ثبت کنید: اندازه دقیق به بایت و یک هش محتوای مدرن. نام فایل‌ها، برچسب‌های زمانی و پیش‌نمایش‌ها فراداده هستند و هیچ‌کدام محتوا را شناسایی نمی‌کنند.

هش را با الگوریتمی محاسبه کنید که هر دو سر بتوانند اجرا کنند و بنویسید کدام را استفاده کردید. مقایسه میان SHA-256 و MD5 مقایسه نیست، و مقایسه میان دو فایل متفاوت که تصادفاً نام یکسان دارند هم مقایسه نیست.

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

مرجع Get-FileHash مایکروسافت دستور و پارامتر الگوریتم آن را مستند می‌کند، دقیقاً همان بخشی که مردم وقتی مقایسه اختلافی بی‌معنا تولید می‌کند از آن می‌گذرند.

یک هش برای هر مرحله، همان الگوریتم

اکنون همان الگوریتم را روی شیء ذخیره‌شده در جایی که در نهایت زندگی می‌کند محاسبه کنید، با روشی مجاز نه با نسخه‌ای که از ابزار دیگری گذشته است. ذخیره محلی فایل دریافت‌شده و هش کردن آن نسخه مرحله‌ای را اضافه می‌کند که آزمایش نکرده‌اید.

اگر سرویس مقدار یکپارچگی خودش را ارائه می‌دهد، آن را مشاهده‌ای جداگانه بدانید. جمع کنترلی که ارائه‌دهنده گزارش می‌کند می‌تواند بگوید ارائه‌دهنده گمان می‌کند چه چیزی ذخیره کرده، و این همان ادعای آنچه کارخواه شما فرستاده نیست.

سه نتیجه ممکن است و به جهت‌های مختلف اشاره می‌کنند. هش‌های برابر یعنی بایت‌ها بدون تغییر رسیده‌اند. هش‌های متفاوت با تبدیل شناخته‌شده یعنی سرویس آگاهانه شیء تازه‌ای تولید کرده است. هش‌های متفاوت بدون تبدیل یعنی چیزی میان دو نقطه محتوا را تغییر داده، و گام بعدی یافتن زودهنگام‌ترین مرزی است که این اتفاق در آن رخ داده.

شکست انتقال را از تبدیل جدا کنید

بارگذاری ناقص و بارگذاری خراب در مرورگر فایل یکسان به نظر می‌رسند و خطاهای متفاوتی هستند. بررسی کنید آیا انتقال کامل شده است: گزارش برنامه‌ای که درخواست قطع‌شده را نشان می‌دهد، فایل ذخیره‌شده‌ای که اندازه‌اش پیشوند مبدأ است، یا شیئی که در واقع صفحه خطایی است که با پسوند موردانتظار ذخیره شده، همه نشان‌دهنده انتقال ناقص‌اند نه بایت‌های تغییر‌یافته.

تبدیل دیگر توضیح رایج است. سرویسی که تصاویر را دوباره فشرده می‌کند، پایان خطوط CSV را بازنویسی می‌کند یا سندی را تبدیل می‌کند به‌طور مشروع هشی تولید می‌کند که با مبدأ تفاوت دارد، و این خرابی نیست. مرحله‌ای را مقایسه کنید که ادعا می‌کند نسخه وفادار است، نه قالب ارائه نهایی.

تأخیر و افت به دسته سوم تعلق دارند. می‌توانند باعث شوند کارخواه زمان‌بندی تمام کند، دوباره تلاش کند یا رها کند، و هیچ‌یک از این‌ها به معنای تغییر خاموش بایت‌هایی نیست که سرور پذیرفته است. پیش از نسبت دادن چیزی به تونل، به نتیجه انتقال نگاه کنید.

مسیر دومی را بدون تغییر همه‌چیز امتحان کنید

اگر هش‌ها واقعاً متفاوت‌اند و تبدیلی در کار نیست، همان فایل، کارخواه، پروتکل و مقصد را از مسیر پشتیبانی‌شده دیگری تکرار کنید، مانند شبکه محلی به جای VPN. یک متغیر را تغییر دهید. تغییر همزمان کارخواه، نقطه پایانی و ابزار نتیجه‌ای می‌دهد که نمی‌توانید به چیزی نسبت دهید.

مقایسه را در هر دو جهت صادق نگه دارید. هش به شما می‌گوید دو نقطه درباره محتوا اختلاف یا توافق دارند؛ نمی‌گوید کدام سو قابل اعتماد است، پس مقدار موردانتظار و راستی‌آزمایی را درون مدل اعتمادی نگه دارید که واقعاً بر آن تکیه می‌کنید.

با جمله‌ای مشخص در تیکت تمام کنید: انتقال زود متوقف شد، برنامه شیء را تبدیل کرد، انبار آن را تغییر داد، یا بایت‌ها یکسان‌اند و خواندنشان شکست است. هر یک از این‌ها مالک متفاوتی دارد و هیچ‌یک از آن‌ها به‌طور پیش‌فرض VPN نیست.

مقالات مرتبط