کشف MTU مسیر از طریق VPN: اندازه‌گذاری و شکاف ICMP
تونل بسته‌ای را که مسیر می‌تواند حمل کند کوچک می‌کند، و کشف تنها وقتی کار می‌کند که بازخورد برسد. مسیر را اندازه بگیرید، آزمایش کنید و تأیید کنید، نه اینکه حدس بزنید.
یک تونل دست‌دادن خود را کامل می‌کند، درخواست‌های کوچک برمی‌گردند، و نخستین انتقال بزرگ متوقف می‌شود. این الگو بسیار پیش‌تر از آنکه به توان عملیاتی اشاره کند، به MTU مسیر اشاره می‌کند. هر پیوند در طول مسیر اندازه بسته را محدود می‌کند، و کپسوله‌سازی بخشی از این سهم را صرف سرآیندهای بیرونی می‌کند، بنابراین بسته درونی باید کوچک‌تر از آن باشد که مسیر خام نشان می‌دهد. شکست بی‌صداست، و همین تشخیص آن را گران می‌کند.
MTU مسیر در واقع چه چیزی را می‌سنجد
MTU مسیر کوچک‌ترین MTU پیوند در مسیر میان دو میزبان است، نه MTU چاپ‌شده روی رابط محلی شما. مقدار محلی نقطه آغاز برآورد است، و مسیر تعیین می‌کند که کجا باید پایان یابد. به همین دلیل یک تونل یکسان می‌تواند در یک شبکه دسترسی کار کند و در شبکه‌ای دیگر متوقف شود: مسیر تغییر کرده است، نه پیکربندی. یک بار اندازه‌گیری و فرض کردن آن در همه‌جا همان اشتباهی است که این مشکل را زنده نگه می‌دارد.
برای یک تونل، عددی که اهمیت دارد MTU درونی است، یعنی سهم مسیر بیرونی منهای هر چیزی که کپسوله‌سازی مصرف می‌کند. WireGuard یک سرآیند IP بیرونی و یک سرآیند UDP اضافه می‌کند؛ حامل‌های دیگر سرآیندهای خود را اضافه می‌کنند. اندازه درونی را بیش از حد بالا بگذارید و هر بسته با اندازه کامل به قطعه‌بندی نیاز پیدا می‌کند که شاید هرگز رخ ندهد.
چرا تونل بسته قابل استفاده را کوچک می‌کند
اگر رابط تونل MTU پیوند فیزیکی را حفظ کند، هر بسته بزرگ به این بستگی دارد که کسی در پایین‌دست حاضر به قطعه‌بندی آن باشد. IPv4 در اصل این را مجاز می‌داند، اما مسیریابی که به آن گفته شده قطعه‌بندی نکند، به جای آن خطا برمی‌گرداند. مسیریاب‌های IPv6 هرگز در گذر قطعه‌بندی نمی‌کنند، بنابراین همان تنظیم بسته به خانواده نشانی رفتار متفاوتی دارد. در هر دو حالت فرستنده هیچ چیزی نمی‌آموزد تا وقتی چیزی بازخورد بدهد.
پیامد عملی اندازه‌ای است که با دست‌دادن جور است و با بار مفید نه. یک TLS ClientHello یا یک پرس‌وجوی DNS به اندازه‌ای کوچک است که مسیر کوچک‌شده را دست‌نخورده بگذراند، در حالی که انتقال انبوه چنین نیست. بنابراین نشانه‌ها گرد عملیات مشخص جمع می‌شوند، نه میزبان‌های مشخص.
کشف تنها وقتی کار می‌کند که بازخورد برسد
کشف IPv4 بر بیت ممنوعیت قطعه‌بندی تکیه دارد: مسیریابی که نمی‌تواند بسته را هدایت کند، ICMP fragmentation-needed را با MTU گام بعدی برمی‌گرداند و فرستنده برآورد خود را پایین می‌آورد. IPv6 به جای آن از پیام‌های Packet Too Big استفاده می‌کند، چون مسیریاب‌ها در گذر قطعه‌بندی نمی‌کنند. هر دو سازوکار فرض می‌کنند که پیام راه بازگشت به فرستنده را پیدا می‌کند، از میان تونل و از کنار هر دیوار آتش در مسیر بازگشت. وقتی این فرض شکست می‌خورد، فرستنده همچنان اندازه‌ای را که مسیر نمی‌تواند حمل کند دوباره امتحان می‌کند.
دیوار آتشی که echo request و echo reply را مجاز می‌کند، لزوماً آن انواع خطا را مجاز نکرده است. ICMP یک خانواده است، و اعضایی که اینجا اهمیت دارند خطاها هستند، نه جفت echo. خط‌مشی ترافیک کنترل را در دو انتهای تونل و در مسیر میان آن‌ها بررسی کنید، و به راهنمایی پشتیبانی‌شده سکو پایبند باشید نه اینکه هر نوع ICMP را در همه‌جا مجاز کنید.
همان پالایش می‌تواند درون تونل باشد. اگر مسیر درونی خطا را بیندازد اما مسیر بیرونی آن را حمل کند، فرستنده ممکن است با محدودیتی سازگار شود که ترافیک کپسوله‌شده در واقع هرگز آن را نمی‌بیند.
مسیر را آزمایش کنید نه اینکه عددی را حدس بزنید
مقصد، شبکه دسترسی و تونل را ثابت نگه دارید و فقط اندازه بسته را تغییر دهید. آزمون ممنوعیت قطعه‌بندی که با اشاره MTU شکست می‌خورد حد گام بعدی را به شما می‌دهد؛ تکرار کنید تا اندازه‌ای عبور کند، و هم اندازه و هم خانواده نشانی را ثبت کنید.
ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10یک ping که جا می‌شود ثابت نمی‌کند که قطعه‌های اندازه کامل یک برنامه واقعی جا می‌شوند، پس آزمون را با همان انتقالی که واقعاً شکست خورد تکرار کنید. بزرگ‌ترین آزمون کارآمد را با MTU تونلی که پیکربندی کرده‌اید مقایسه کنید و دو عدد را در یادداشت‌هایتان جدا نگه دارید. اگر تقریباً به اندازه یک سرآیند تفاوت داشته باشند، سرباری کپسوله‌سازی را یافته‌اید نه یک نقص.
PLPMTUD که در RFC 4821 توصیف شده، رو به بالا آزمون می‌کند و به جای اعتماد به خطاهای تحویل‌شده از تأییدهای لایه انتقال استفاده می‌کند. در مسیرهایی که ICMP را پالایش می‌کنند کمک می‌کند، اما پشتیبانی بسته به پشته و برنامه متفاوت است. یک جریان TCP ممکن است خودبه‌خود بازیابی شود در حالی که برنامه‌ای UDP با اندازه دیتاگرام ثابت همچنان شکست می‌خورد.
یک مقدار انتخاب کنید و استدلال را ثبت کنید
پایین آوردن MTU تونل هم تشخیص است و هم اصلاحی مشروع وقتی مسیر را می‌دانید. جای دانستن اینکه کدام مسیر و کدام سازوکار بازخورد دخیل بوده‌اند را نمی‌گیرد، زیرا مقداری که برای پیوند سیار تنظیم شده روی اتصال فیبر بی‌جهت کوچک خواهد بود. اندازه انتخاب‌شده، آزمونی که آن را توجیه کرد و گام بازگشت را ثبت کنید.
سازوکار IPv4 در RFC 1191 توصیف شده و راهنمای بسته‌بندی IPv6 در RFC 8201؛ نام بردن هر دو مانع می‌شود مهندس بعدی فرض را دوباره استخراج کند. اگر انتقال همچنان در اندازه‌ای که انتخاب کرده‌اید متوقف شود، پایین آوردن عدد را متوقف کنید و به لایه بعد نگاه کنید. مسیری که در هر اندازه‌ای شکست می‌خورد مشکل MTU نیست.