صفحه‌ها بارگذاری می‌شوند اما آپلودها روی VPN گیر می‌کنند: کدام علت برنده است
گیر کردن وابسته به اندازه با نقص MTU مسیر می‌خواند و همچنین با DNS، محدودیت برنامه یا تونل ناپایدار. چهار مشاهده تعیین می‌کند کدام یک.
صفحه‌ها بارگذاری می‌شوند، VPN اتصال را گزارش می‌دهد و آپلود فایل هر بار در همان نقطه متوقف می‌شود. چهار توضیح با این توصیف می‌خواند: مشکل اندازه بسته، مشکل حل نام، محدودیت برنامه و تونلی که مدام بازنشانی می‌شود. هر یک را می‌توان با مشاهده‌ای متفاوت تأیید یا رد کرد، پس تصمیم به انتخاب آزمون درست است، نه حدس زدن علت.
چهار نامزد و یک شکل
با شکل خرابی شروع کنید، زیرا پیش از باز شدن هر ابزاری بیشتر فهرست را حذف می‌کند. گیر کردن در اندازه‌ای ثابت مشکل اندازه است تا خلافش ثابت شود. گیر کردن در نقاط تصادفی مشکل افت یا پایداری است. خرابی پیش از باز شدن اتصال مشکل نام است.
نامزد چهارم خود برنامه است. محدودیت‌های آپلود، مهلت درخواست‌ها و سقف اندازه بدنه در پروکسی خرابی‌هایی می‌سازند که از دید مرورگر شبیه نقص شبکه‌اند و معمولاً به شکل رد شدن می‌رسند، نه گیر کردن.
پیش از هر آزمایشی شکل مشاهده‌شده را بنویسید. «در حدود همان تعداد بایت، هر بار، با تونل برپا متوقف می‌شود» نقطه شروعی بسیار قوی‌تر از «آپلودها کار نمی‌کنند» است.
سپس هنگام آزمایش مسیر را ثابت نگه دارید. تغییر همزمان خروجی، پروتکل و سرور نتیجه‌ای می‌دهد که نمی‌توانید به هیچ‌یک نسبت دهید. در هر اجرا یک متغیر، و آن را بنویسید.
پیش از دست زدن به سیاست، اندازه را نصف کنید
ارزان‌ترین تمایزدهنده کاوشی است که یک عدد را تغییر می‌دهد. پینگ‌های بدون قطعه‌بندی با اندازه فزاینده به مقصد بفرستید، فایلی را که کنترل می‌کنید به همان سرویس آپلود کنید و سپس مقایسه کنید هر کدام کجا متوقف می‌شود.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadدستور اول گزارش می‌دهد آیا بسته‌ای با اندازه کامل اصلاً از مسیر عبور می‌کند. در MTU 1500 بایتی، بزرگ‌ترین بار مفید ICMP که قطعه‌بندی نمی‌شود 1472 بایت است و تونل پیش از آغاز بسته درونی بیش از این از آن بودجه برمی‌دارد. دومی به شما اندازه و مدتی برای انتقال در سطح برنامه می‌دهد و همان عددی است که واقعاً مهم است.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
این جفت را با هم بخوانید. کاوش‌هایی که بالای آستانه شکست می‌خورند و آپلودی که نزدیک همان آستانه متوقف می‌شود داستانی منسجم‌اند. کاوش‌هایی که همه موفق‌اند در حالی که آپلود در تعداد بایتی گیر می‌کند که مسیر آشکارا حمل می‌کند، به برنامه یا سرور اشاره دارد و هیچ کار MTU آن را تغییر نمی‌دهد. آن نتیجه منفی به اندازه یک نتیجه مثبت ارزش دارد. گران‌ترین شاخه بررسی را حذف می‌کند.
سپس پایداری را در طول انتقال بررسی کنید، زیرا تونلی که در میانه آپلودی بزرگ کلید را تازه می‌کند خرابی‌ای می‌سازد که وابسته به اندازه به نظر می‌رسد بی‌آنکه باشد. خواندن زمان کار ارزان‌ترین راه برای تأیید آن است.
بین تعمیر و راه‌حل موقت یکی را انتخاب کنید
اگر شواهد به اندازه اشاره کند، دو پاسخ صادقانه و یک پاسخ ناصادقانه وجود دارد. صادقانه‌ها عبارت‌اند از بازگرداندن کشف MTU مسیر با اجازه دادن به بازخورد ICMP لازم، یا محدود کردن اندازه قطعه اعلام‌شده تا همتاها قطعه‌های کوچک‌تر بفرستند. ناصادقانه آن است که MTU یک رابط را به مقداری کپی‌شده از یک انجمن کاهش دهید و هرگز بررسی نکنید چه چیزی را تغییر داد.
انتخاب به آنچه کنترل می‌کنید بستگی دارد. در شبکه‌ای که اداره می‌کنید، اجازه دادن به پیام‌های ICMP تعمیر پاک‌تری است زیرا سازوکار را برای هر پروتکل فعال نگه می‌دارد. در مسیری که کنترل نمی‌کنید، محدودسازی گزینه عملی است و باید به‌صورت باریک اعمال شود، نه در سراسر سرور.
اگر شواهد به برنامه اشاره کند، برنامه یا پیکربندی پروکسی آن را درست کنید. پاسخ 413 و اتصال معلق خرابی‌های متفاوتی هستند و دومی معمولاً مهلتی در جایی از زنجیره‌ای است که پروکسی با محدودیت‌های خودش را در بر می‌گیرد.
در هر حال، مقادیر اصلی را نگه دارید و پس از بازگرداندن دوباره آزمایش کنید. تغییری که با انتقالی موفق همزمان می‌شود دلیل بر آن نیست که آن را ایجاد کرده و توانایی بازگرداندن همان چیزی است که تشخیص را از تصادف جدا می‌کند.
تصمیم را ثبت کنید تا از حادثه بعدی جان سالم به در ببرد
چهار واقعیت کافی است: شکل مشاهده‌شده خرابی، نتایج کاوش‌ها، تغییری که دادید و نتیجه آزمون دوباره. با آنها نفر بعدی می‌تواند بگوید مشکل همان است یا مشکلی تازه با همان نشانه.
زمینه مسیر را هم یادداشت کنید، زیرا یافته MTU مخصوص یک پیوند است. لپ‌تاپی که در خانه کار می‌کند و در هتل شکست می‌خورد دو مسیر دارد و اصلاحی که روی یکی اعمال شود درباره دیگری چیزی نمی‌گوید.
سرانجام، در برابر این جمع‌بندی مقاومت کنید که «VPN آپلودها را خراب کرد». تونل هم در حالت کارکرد و هم در حالت خرابی حاضر بود؛ آنچه تغییر کرد اندازه بسته‌ای بود که مسیر باید حمل می‌کرد، یا جایی که انتقال متوقف شد. نام بردن سازوکار واقعی همان چیزی است که یادداشت را سودمند می‌کند.