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

این عدد از تونل دیگری آمده است

سرباری در معنای انتزاعی ویژگی IPsec نیست. ویژگی بسته‌ای است که واقعاً ساخته می‌شود: حالت توافق‌شده، سرآیند بیرونی، سرآیند حفاظت، پرشدگی، یک فیلد یکپارچگی و شاید یک پوشش UDP اضافی.

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

لایه‌هایی را که واقعاً وجود دارند جمع بزنید

از سرآیند بیرونی IP شروع کنید و به سمت داخل بروید. در حالت تونل بسته اصلی در داخل است، پس سرآیند بیرونی یک افزوده است نه جایگزین. RFC 4303 سرآیند ESP، پرشدگی و داده‌های یکپارچگی پس از آن را توصیف می‌کند.

LayerWhat it addsWhen it applies
Outer IP header20 bytes for IPv4, 40 for IPv6Always, and 40 rather than 20 if the outer path is v6
ESP header8 bytes of SPI and sequence numberAlways
Block cipher IV8 to 16 bytes depending on the transformWhen the negotiated cipher uses one
Padding and trailerPadding to the block size, plus two trailer bytesAlways, and the amount varies with payload length
Integrity data12 to 16 bytes for common authenticated ciphersWhen integrity protection is negotiated
UDP encapsulation8 bytesNAT traversal on port 4500, which is common for clients behind NAT

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

دو سایت می‌توانند درباره یک تونل اختلاف داشته باشند

بسته محافظت‌شده هنوز باید مسیر بیرونی را طی کند، و مسیر بیرونی همه‌جا یکسان نیست. یک لینک دسترسی PPPoE کمتر از یک سگمنت تمیز Ethernet حمل می‌کند. شبکه موبایل ممکن است بیشتر کوچک شود، و ارائه‌دهنده‌ای که ترافیک خودش را تونل می‌کند کپسوله‌سازی دیگری اضافه می‌کند که کسی به آن اشاره نکرده است. تونلی که روی یک لینک کار می‌کند و روی دیگری شکست می‌خورد، دارد لینک دوم را توصیف می‌کند، نه پروتکل را.

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

اندازه بگیرید، نه کم کنید

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

ip link show eth0 | grep -o 'mtu [0-9]*'
ip xfrm state list
ping -M do -s 1400 198.51.100.7
ping -M do -s 1372 198.51.100.7
tcpdump -ni any -c 20 'esp or udp port 4500'

اندازه ping را پایین بیاورید تا پاسخ‌ها برسند، و بزرگ‌ترین مقدار کارآمد را بودجه آن مسیر بدانید. خروجی xfrm می‌گوید کدام حالت و کدام الگوریتم‌ها توافق شده‌اند، و همین ورودی هر محاسبه صادقانه است. ضبط بسته تأیید می‌کند که روی سیم ESP است یا ESP کپسوله‌شده در UDP، و این پرسش NAT را بدون حدس زدن حل می‌کند.

یک مقدار هم برای لایه کنترل کنار بگذارید. بسته‌های دست‌دادن IKE ساختاری متفاوت از بسته‌های داده دارند، پس اندازه‌ای که از ضبط یک دست‌دادن به دست می‌آید MTU لایه داده نیست.

عدد را جایی بگذارید که تعلق دارد

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

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

مقالات مرتبط