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

دو عدد، دو شیء

MTU به یک پیوند یا یک رابط تعلق دارد: بزرگ‌ترین بسته‌ای است که می‌توان بدون تکه‌تکه شدن تحویل داد. MSS به TCP تعلق دارد: بزرگ‌ترین مقدار بار TCP است که یک بخش می‌تواند حمل کند و هر دو سرآیند TCP و IP را کنار می‌گذارد. روی یک پیوند اترنت معمولی با IPv4، MTU برابر 1500 بایت همان MSS آشنا یعنی 1460 بایت را می‌دهد. این اعداد لایه‌های متفاوتی را توصیف می‌کنند و با سازوکارهای متفاوتی مبادله می‌شوند. اشتباه گرفتنشان آسان است، چون هر دو با بایت سنجیده می‌شوند و هر دو نزدیک 1500 هستند.

یکی به‌صورت تنظیم رابط می‌آید. دیگری به‌صورت گزینه‌ای درون یک بخش SYN می‌آید که میان دو سری که هرگز رابط شما را نمی‌بینند مذاکره می‌شود.

بار اضافی بیرونی کجا می‌نشیند

VPN بسته درونی را درون بسته دیگری می‌گذارد و بسته بیرونی باید در مسیر فیزیکی جا شود. سرآیندهای کپسوله‌سازی، سرآیند IP بیرونی، سرآیند انتقال و هر برچسب احراز هویت همه بایت‌هایی مصرف می‌کنند که بسته درونی نمی‌تواند از آن‌ها استفاده کند. رابط تونل را روی 1500 بگذارید و بسته بیرونی به‌طور مرتب از آنچه مسیر می‌تواند حمل کند فراتر می‌رود. با بیت 'تکه نکن'، مسیریاب آن را دور می‌ریزد و باید خطای ICMP برگرداند؛ اگر آن خطا فیلتر شود، فرستنده هرگز خبردار نمی‌شود.

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

محدود کردن MSS و اینکه کجا اعمال می‌شود

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

اثر فقط روی TCP است. یک برنامه UDP، یک نشست QUIC و هر پروتکلی که داده‌گرام‌های خودش را می‌سازد از آن دست‌نخورده می‌ماند.

با مسیری ثابت عیب‌یابی کنید

هر بار یک متغیر را ثابت نگه دارید. با بسته‌ای که اندازه‌اش را خودتان انتخاب می‌کنید آزمایش کنید و پرچم 'تکه نکن' را بگذارید تا هسته نتیجه را گزارش کند نه پنهانش.

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

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

پایین آوردن MTU رابط MSS نشستی را که از پیش برقرار شده تغییر نمی‌دهد. محدود کردن MSS به یک جریان UDP کمکی نمی‌کند و مسیری را که خطاهای ICMP فقط در یک جهت فیلتر می‌شوند ترمیم نمی‌کند. هر تغییر یک رده از مشکل را درست می‌کند و بقیه را دقیقاً همان‌طور که بودند رها می‌کند.

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

مقالات مرتبط