پینگ سرور برقرار است اما انتقال فایل گیر می‌کند؛ آیا مشکل از MTU است؟

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

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

تصور کنید برای رسیدن به مقصد باید از چند در عبور کنید. اگر بسته شما از یک در بزرگ‌تر باشد، لازم است روش انتقال با آن مسیر هماهنگ شود. در شبکه، MTU حد اندازه بسته در یک رابط است و Path MTU به محدودیت مسیر بین دو نقطه مربوط می‌شود. کوچک بودن یک بخش از مسیر، مثلاً یک تونل، می‌تواند اندازه مناسب را تغییر دهد.

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

این آموزش آزمایش IPv4 در لینوکس را توضیح می‌دهد. محاسبات و رفتار IPv6 فرق دارند؛ عددهای این مثال را برای IPv6 یا همه تونل‌ها کپی نکنید.

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

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

از طریق کنسول مجاز یا SSH به لینوکس مبدأ وارد شوید. در دستور زیر نشانی 192.0.2.10 فقط برای مثال است؛ آن را با IPv4 واقعی مقصد آزمایشی خودتان جایگزین کنید:

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

اگر در خروجی نام رابط مثلاً tun0 بود، برای دیدن مشخصات همان رابط می‌توانید اجرا کنید:

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

از همان مبدأ و به همان مقصد مجاز، دو آزمایش زیر را انجام دهید. در هر دو دستور، آدرس نمونه را با مقصد واقعی عوض کنید:

گزینه c تعداد درخواست را به سه عدد محدود می‌کند. گزینه s اندازه داده آزمایشی و M do درخواست ارسال IPv4 بدون تکه‌تکه شدن در مسیر را مشخص می‌کند. در حالت معمول بدون سربار اضافی در سربرگ IPv4، ۱۳۷۲ بایت داده به همراه ۲۸ بایت سربرگ IPv4 و ICMP حدود بسته ۱۴۰۰ بایتی می‌شود؛ ۱۴۷۲ نیز حدود ۱۵۰۰ بایت است. این‌ها عدد قطعی برای هر VPN یا نوع بسته نیستند و فقط دو نقطه برای مقایسه‌اند.

در خروجی دنبال پاسخ echo، پیام Frag needed یا Message too long و تعداد بسته‌های ازدست‌رفته باشید. دستور ممکن است بر اساس محدودیت رابط مبدأ بلافاصله پیام بزرگ بودن بدهد؛ آن را با خطای رسیده از مسیر اشتباه نگیرید. اگر برنامه ping سیستم گزینه‌ها را نمی‌شناسد، راهنمای نسخه خودش را ببینید؛ همه پیاده‌سازی‌ها دستور یکسان ندارند.

| نتیجه | تفسیر و قدم بعدی | | --- | --- | | بسته کوچک پاسخ دارد و بزرگ، پیام نیاز به قطعه‌قطعه شدن می‌دهد | مسیر یا رابط برای بسته بزرگ محدودیت دارد. عدد و محل گزارش را ثبت کنید و با تنظیم تونل و مدیر شبکه تطبیق دهید. | | بسته کوچک پاسخ دارد اما بزرگ فقط timeout می‌شود | احتمال محدودیت اندازه یا فیلتر وجود دارد، ولی از این آزمایش نمی‌توان محل یا علت را قطعی دانست. با مسیر دیگر و گزارش شبکه مقایسه کنید. | | هیچ‌کدام پاسخ ندارند | ممکن است ICMP در مبدأ، مسیر یا مقصد مجاز نباشد. این نتیجه به‌تنهایی اندازه MTU را مشخص نمی‌کند. | | هر دو پاسخ دارند ولی انتقال برنامه گیر می‌کند | این آزمایش مشخص، مشکل را ثابت نکرده است؛ سراغ گزارش برنامه، خطا و کیفیت مسیر واقعی آن بروید. |

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

اگر مشکل فقط هنگام استفاده از یک تونل مشخص رخ می‌دهد، ابتدا نوع تونل، سربار آن، تنظیم دو طرف و مقدار پیشنهادی ارائه‌دهنده همان تونل را مشخص کنید. تونل‌های مختلف سربار متفاوت دارند؛ عدد ثابت ۱۴۰۰ یا ۱۴۵۰ برای همه آن‌ها درست نیست. همچنین دریافت درست پیام‌های لازم برای کشف MTU را در فایروال مبدأ، مقصد و مسیر بررسی کنید. مسدود کردن کامل ICMP می‌تواند خود مسئله را بدتر کند.

اگر مدیر شبکه تشخیص داده مقدار یک رابط تونل باید موقتاً کمتر شود، پیش از آزمایش کنسول اضطراری مستقل و مقدار قبلی را آماده کنید. تغییر رابطی که اتصال مدیریتی روی آن است ممکن است SSH را قطع کند. ابتدا در محیط آزمایشی و با هماهنگی دو طرف کار کنید. برای نمونه، فقط اگر رابط واقعی tun0 است و مقدار ۱۴۰۰ برای همان تونل تأیید شده، دستور موقت چنین شکلی دارد:

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

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

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

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