افسانه‌های MTU در VPN: چرا بسته‌های شما کوچک می‌شوند و فضا کجا می‌رود

کسی به شما می‌گوید VPN «به‌خاطر MTU بسته گم می‌کند»، شما تونل را روی 1400 می‌گذارید و انتقال دوباره کار می‌کند. این نتیجه شبیه یک تشخیص به نظر می‌رسد. معمولاً یک تصادف حسابی است: عددی انتخاب کرده‌اید که به‌اندازه کافی کوچک است تا زیر محدودیتی جا شود که هرگز آن را شناسایی نکردید، و در شبکه بعدی با بودجه‌ای متفاوت دوباره به همان محدودیت برمی‌خورید.

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

افسانه اول: MTU تونل همان MTU مسیر است

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

کشف MTU مسیر برای آشتی دادن این دو وجود دارد و به بازخورد وابسته است. در IPv4، مسیریابی که نمی‌تواند بسته تمام‌اندازه را ارسال کند باید پیام ICMP «fragmentation needed» بفرستد و فرستنده برآوردش را پایین می‌آورد. در IPv6 معادل آن پیام Packet Too Big است و مسیریاب‌ها در مسیر اصلاً قطعه‌بندی نمی‌کنند. وقتی این بازخورد فیلتر شود، فرستنده همچنان بسته‌هایی تولید می‌کند که مسیر نمی‌تواند حمل کند و هیچ چیز دلیلش را به او نمی‌گوید.

افسانه دوم: کپسوله‌سازی یک سرآیند هزینه دارد

لایه‌های بیرونی را صادقانه بشمارید. سرآیند بیرونی IP در IPv4 برابر 20 بایت است یا در IPv6 برابر 40 بایت. کپسوله‌سازی UDP برای عبور از NAT مقدار 8 بایت اضافه می‌کند. پروتکل تونل سرآیند خودش را اضافه می‌کند، یک بردار آغازین یا nonce، پرکردن تا مرز بلوک یا هم‌ترازی رمز، یک بخش پایانی و یک مقدار بررسی یکپارچگی. بسته به پروتکل و رمز، جمع به راحتی در ده‌ها بایت است، پیش از آنکه بسته درونی حتی آغاز شود.

سپس دوباره سرآیندهای خود بسته درونی را کم کنید. یک بخش TCP درون تونل سرآیند IP 20 بایتی و سرآیند TCP 20 بایتی خودش را حمل می‌کند و MSS در TCP از MTU مشتق می‌شود، نه از بار مفید اسمی تونل. برای همین ping با بار کوچک‌تر می‌تواند موفق شود در حالی که انتقال یک فایل متوقف می‌شود: ابزارها چیزهای متفاوتی را آزمایش می‌کنند و تنها یکی از آن‌ها یک بخش TCP تمام‌اندازه را به کار می‌گیرد.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

افسانه سوم: PPPoE هنوز 1500 تمیز به شما می‌دهد

یک پیوند دسترسی معمولی PPPoE بسته IP با 1500 بایت را حمل نمی‌کند. سرآیند PPPoE به‌همراه فیلد پروتکل PPP مقدار 8 بایت داخل قاب Ethernet مصرف می‌کنند که برای بسته IP 1492 باقی می‌گذارد. این همان محدودیت سنتی است که در RFC 2516 توصیف شده است. اگر VPN را روی چنین پیوندی اجرا کنید، هزینه اضافی تونل از همان 1492 بیرون می‌آید، نه از 1500.

RFC 4638 روشی را تعریف می‌کند برای مذاکره بر سر بار PPP بزرگ‌تر وقتی هم متمرکزکننده دسترسی و هم تجهیزات مشتری از آن پشتیبانی می‌کنند، به همین دلیل جمله «این اتصال از PPPoE استفاده می‌کند» به‌تنهایی عدد مشخصی را اثبات نمی‌کند. یک تنظیم محلی نمی‌تواند دستگاه میانی را وادار کند بسته‌ای را بپذیرد که هرگز برایش پیکربندی نشده است، پس پرسش مفید این است که پیوند واقعاً بر چه چیزی توافق کرده، نه اینکه برچسب چه می‌گوید.

چرا خرابی گزینشی به نظر می‌رسد

موفق شدن درخواست‌های کوچک و متوقف شدن انتقال‌های بزرگ، امضای کلاسیک یک سیاه‌چاله MTU مسیر است. دست‌دادن، پرسش DNS و فراخوان API همه جا می‌شوند؛ انتقال انبوه بخش‌های تمام‌اندازه تولید می‌کند که در یک پیوند می‌میرند و پیام ICMP که باید مشکل را گزارش می‌کرد هرگز نمی‌رسد. اتصال سالم به نظر می‌رسد و دانلود معلق می‌ماند و این مردم را به‌جای مسیر به سراغ سرور می‌فرستد.

اشتباه دوم و مرتبط، قاطی کردن سه عدد است: MTU رابط، MSS در TCP و تنظیم قطعه‌بندی یا پرکردن خود پروتکل. فشردن MSS روی یک مسیریاب، MSS اعلام‌شده را بازنویسی می‌کند تا فرستنده بخش‌های کوچک‌تر بسازد؛ MTU تونل را عوض نمی‌کند و به ترافیک UDP کمکی نمی‌کند. دادن یک عدد یکسان به هر سه چون مرتبط به نظر می‌رسند، همان راهی است که یک تغییر خوش‌نیت یک پیکربندی کارکننده را خراب می‌کند.

چه چیزی را به چه ترتیبی تغییر دهیم

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

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