فناوری / تحلیل و راهنمای کاربردی

VPN وصل است، اما فایل بزرگ رد نمی‌شود؛ MTU را بسنجیم

وقتی اتصال کوچک موفق و انتقال بزرگ متوقف می‌شود، چطور فرضیه MTU را با شاهد بررسی کنیم و از تغییر تصادفی کل شبکه دور بمانیم؟

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

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

یک آزمایش قابل‌تکرار انتخاب کنیم

همان فایل و همان مقصد را با و بدون تونل مقایسه کنید. زمان، نوع اتصال و نتیجه را ثبت کنید. هدف آزمون این نیست که با عوض‌کردن هم‌زمان چند تنظیم، تصادفاً سرویس بالا بیاید؛ باید یک تفاوت مشخص باقی بماند که بتوانیم آن را دوباره بسنجیم.

بررسی اولیه روی Windows و IPv4

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

ping /4 /n 2 /f /l 1472 192.0.2.10
ping /4 /n 2 /f /l 1400 192.0.2.10
netsh interface ipv4 show subinterfaces

در IPv4 بدون گزینه‌های اضافی، برای تبدیل اندازه داده Ping به اندازه بسته IP، معمولاً 28 بایت سربار IP و ICMP اضافه می‌شود. بنابراین داده 1472 بایتی با بسته 1500 بایتی متناظر است؛ خود عدد 1472، مقدار MTU نیست.

اگر پیام صریحِ نیاز به Fragmentation می‌گیرید و اندازه کوچک‌تر پاسخ دارد، فرضیه محدودیت اندازه قوی‌تر می‌شود. Timeout به‌تنهایی چنین اثباتی نیست؛ ممکن است ICMP در مسیر یا مقصد فیلتر شود. پاسخ Ping کوچک نیز سلامت تمام انتقال‌های TCP را تأیید نمی‌کند.

اصلاح را به همان مسیر محدود کنیم

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

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

معیار نجات، تکرار انتقال واقعی است

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

تصمیم نجات‌دهنده: اندازه بسته را اندازه بگیریم؛ صرف دیدن اتصال VPN، سالم‌بودن مسیر داده را فرض نکنیم.

منابع: پارامترهای Ping در Windows، سازوکار Path MTU Discovery.

تحلیل فناوری برای تصمیم‌های آگاهانه‌تر.همه نوشته‌ها →