سیاه‌چاله MTU: چرا درخواست‌های کوچک کار می‌کنند اما بارگذاری‌ها متوقف می‌شوند
درخواست‌های کوچک تمام می‌شوند در حالی که یک بارگذاری بزرگ تا ابد معلق می‌ماند، و فرستنده هرگز نمی‌فهمد که مسیر باریک‌تر است. اندازه دقیقی را که در آن میشکند اندازه بگیرید.
یک صفحه بارگذاری می‌شود، یک فراخوانی کوچک API برمی‌گردد، و سپس بارگذاری یک فایل معلق می‌ماند تا کلاینت تسلیم شود. هیچ چیز در گزارش سرور این را توضیح نمی‌دهد، چون بسته‌ها در میانه مسیر دور انداخته شده‌اند بدون اینکه پاسخ مفیدی برگردانده شود. این الگو یک سیاه‌چاله MTU است: پیوندی باریک‌تر از آنچه فرستنده فرض می‌کند، به‌همراه امتناعی خاموش از گفتن آن. اندازه‌ای که شکست می‌خورد تکرارشدنی است، و همین آن را قابل تشخیص می‌کند.
چه چیزی چاله را سیاه می‌کند
هر پیوند یک واحد انتقال بیشینه دارد، و بسته‌ای بزرگ‌تر از حد پرش بعدی باید یا تکه‌تکه شود یا با پیام ICMP که این را می‌گوید رد شود. کشف MTU مسیر به رسیدن و رعایت شدن آن پیام بستگی دارد. فیلتر کردن یا نادیده گرفتن آن، فرستنده را به تکرار بسته‌ای وا می‌گذارد که هرگز جا نمی‌شود.
کپسوله‌سازی این را پیرامون VPNها رایج می‌کند، چون تونل یک سرآیند بیرونی به بسته‌ای اضافه می‌کند که از پیش برای پیوند فیزیکی اندازه‌گیری شده بود. بسته درونی در 1500 بایت مجاز است و بسته کپسوله‌شده نیست، پس در مرز می‌میرد در حالی که بسته‌های کوچک عبور می‌کنند. دست‌دادن کامل‌شده و صفحه ورود کارآمد فقط ثابت می‌کنند که بسته‌های کوچک کار می‌کنند. بزرگ‌ترین بسته‌ای که برنامه می‌کوشد بفرستد همان است که اهمیت دارد.
اندازه‌ای را که در آن میشکند پیدا کنید
اندازه بار را با آزمون بدون تکه‌تکه‌سازی به‌صورت دودویی جست‌وجو کنید، از میزبان یک سوی تونل به میزبان سوی دیگر. بزرگ‌ترین باری که موفق می‌شود، MTU مسیر قابل استفاده شما منهای سربار سرآیند است.
ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20باری از 1472 بایت روی یک مسیر تمیز Ethernet با 1500 بایت موفق می‌شود وقتی 28 بایت سرآیندهای IPv4 و ICMP افزوده شود. وقتی همان آزمون پس از بالا آمدن تونل فقط با بار کوچک‌تری موفق می‌شود، تفاوت همان سربار کپسوله‌سازی است، و مرز تونل جایی است که پیام رد باید تولید می‌شد. هر دو عدد را، پیش و پس از اتصال، ثبت کنید، چون همان جفت دلیل است. آزمون را برای IPv6 وقتی برنامه از آن استفاده می‌کند تکرار کنید، چون سرآیند بزرگ‌تر است و آستانه شکست جابه‌جا می‌شود.
پیش از سرزنش تونل، شواهد را بخوانید
خطاهای برنامه‌های راه‌دور، ازدحام و افت معمولی هم بارگذاری‌ها را متوقف می‌کنند، پس یک انتقال ناموفق سیاه‌چاله را مشخص نمی‌کند. آنچه آنها را جدا می‌کند رابطه اندازه است: موفقیت تکرارشدنی در 1200 بایت و توقف تکرارشدنی در 1400 بایت، در همان جهت، از همان نقطه پایانی.
یک ضبط در دو سر نشان می‌دهد بسته‌های بزرگ بیرون می‌روند و هرگز نمی‌رسند، بدون ردی در میان. آن لحظه، لحظه نگاه کردن به دستگاه مرز است نه سرور، که به هر درخواستی که واقعاً دریافت می‌کند پاسخ می‌دهد. ازدحام هم متوقف می‌کند، اما اندازه‌های مختلف را در زمان‌های مختلف متوقف می‌کند، و این امضای دیگری است.
تعمیر را روی هر دو انتقال بررسی کنید
تعمیر پشتیبانی‌شده این است که بگذارید مرز حد واقعی را گزارش کند، یا اندازه بیشینه قطعه TCP را همان‌جا مهار کنید تا هیچ قطعه بیش‌ازحدی آزمایش نشود. پایین آوردن هر MTU در شبکه، یا خاموش کردن دیوار آتش، نشانه را پنهان می‌کند و پیکربندی‌ای باقی می‌گذارد که بعداً هیچ‌کس نمی‌تواند درباره‌اش استدلال کند.
ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20با همان آزمون اندازه بررسی کنید، سپس با برنامه‌ای که شکست خورد، و پروتکل دومی را هم بررسی کنید، چون برنامه‌های UDP هرگز تصحیح اندازه قطعه TCP را دریافت نمی‌کنند. مقادیر اصلی را در تیکت نگه دارید، چون تعمیری که برگشت‌پذیر نیست یک مشکل دوم است که در انتظار رخ دادن است. اگر آزمون اندازه قبول شود و بارگذاری همچنان متوقف بماند، سیاه‌چاله علت نبوده، و بررسی باید ادامه یابد نه اینکه تغییر گسترده‌تر شود.