آزمودن مشکل مشکوک MTU در VPN بدون حدس زدن مقدارها

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

پیش از تغییر یک عدد، مسیر را ثابت کنید

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

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

با اندازه‌ای که کنترل می‌کنید کاوش کنید

در Linux کاوش شبیه ping -M do -s 1400 host است، و در Windows شبیه ping -f -l 1400 host. در هر دو حالت بار مفید را تنظیم می‌کنید نه اندازه بسته را، چون سرآیندهای IP و ICMP روی آن افزوده می‌شوند.

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

کاوش ناموفق اثبات محدودیت MTU نیست

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

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

یک پارامتری را تنظیم کنید که کارخواه از پیش پشتیبانی می‌کند

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

اگر هر دو را منتشر می‌کنید هر دو خانواده را بیازمایید، چون نتیجه از یکی هیچ چیزی درباره دیگری نمی‌گوید. مقداری که امشب در این مسیر کار کرد یک داده است، نه MTU برای کل VPN. آن را به اتکای یک انتقال موفق به تنظیم سراسری ارتقا ندهید. مقدار را کنار همان مسیری بنویسید که از آن آمده است.

برگرداندن، بررسی و نوشتن

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

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