حمل بسته درونی ثابت 1,500 بایتی از یک VPN

شما الزامی دارید که قابل خم شدن نیست: طرف دور باید همان بسته IP با اندازه 1,500 بایت را که فرستنده ارسال می‌کند دریافت کند، همراه با سرآیندها. یک تونل نمی‌تواند آن بسته را همراه با قالب‌بندی خودش داخل یک بسته IP دوم با اندازه 1,500 بایت بپیچد، بنابراین چیزی در طراحی باید کوتاه بیاید. ترتیب زیر همان چیزی است که در پنجره تغییر استفاده می‌کنم: بودجه بایت را بنویسید، اثبات کنید که شبکه زیرین واقعاً چه چیزی را می‌تواند حمل کند، سپس دقیقاً یک مکانیزم حمل انتخاب کنید و بسته درونی را در طرف دور تأیید کنید.

پیش از ویرایش پروفایل، بودجه بایت را بنویسید

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

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

شبکه زیرین را با pingهای ممنوعیت قطعه‌بندی آزمایش کنید

مسیر را اندازه بگیرید نه اینکه به MTU رابط اعتماد کنید، زیرا کوچک‌ترین حلقه در مسیر بیرونی همان است که اهمیت دارد. در Linux، -M do بیت ممنوعیت قطعه‌بندی را تنظیم می‌کند و -s بار ICMP را می‌گیرد، بنابراین یک فریم 1,500 بایتی پس از کسر سرآیند 20 بایتی IP و سرآیند 8 بایتی ICMP، با 1,472 بایت بار پاسخ می‌دهد. بار را بالا ببرید تا آزمون شکست بخورد، سپس به اندازه jumbo بپرید تا ببینید مسیر اصلاً آن را حمل می‌کند یا نه.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

مسیری که 1,472 را عبور می‌دهد و در 8,972 شکست می‌خورد نمی‌تواند یک بسته درونی 1,500 بایتی به‌همراه سرباز را در یک بسته بیرونی حمل کند. این همان پاسخی است که پیش از باز کردن پیکربندی VPN لازم داشتید. همچنین تعیین می‌کند کدام یک از دو بخش بعدی به شما مربوط است، پس دو نتیجه آزمون را کنار تیکت نگه دارید. حدس زدن در اینجا یک پنجره نگهداری هزینه دارد، زیرا تونلی که خود را فعال اعلام می‌کند چیزی درباره بزرگ‌ترین بسته‌ای که مسیر می‌پذیرد نمی‌گوید.

MTU مسیر را فقط جایی بالا ببرید که هر گام موافق است

فریم‌های jumbo ویژگی سرتاسری هستند، نه تنظیمی که روی دو نقطه پایانی که اتفاقاً کنترل می‌کنید فعال کنید. هر سوئیچ، مسیریاب و نقطه تحویل ارائه‌دهنده در مسیر بیرونی باید با اندازه بزرگ‌تر موافق باشد، و یک گام 1,500 بایتی بسته‌ای را که همین حالا بزرگ‌تر کردید بی‌صدا دور می‌ریزد. بالا بردن تنها رابط محلی همان تغییر نیمه کلاسیک است که تونل را خراب نشان می‌دهد در حالی که شبکه زیرین بی‌صدا کنار می‌گذارد.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

رابط را تغییر دهید، سپس پیش از تغییر هر چیز دیگری همان مسیر را دوباره آزمایش کنید. اگر آزمون هنوز شکست می‌خورد، با ip link set dev eth1 mtu 1500 برگردانید و به جای بحث با ارائه‌دهنده درباره حلقه‌ای که مالک آن نیستید، به قطعه‌بندی بروید.

وقتی شبکه زیرین نمی‌تواند رشد کند از قطعه‌بندی تونل استفاده کنید

یک مکانیزم قطعه‌بندی پشتیبانی‌شده در زیر بسته درونی اجازه می‌دهد چند بسته بیرونی یک بسته درونی را حمل کنند، و نقطه پایانی دور تونل پیش از تحویل نسخه اصلی به پشته، آن‌ها را دوباره کنار هم می‌گذارد. گزینه قطعه‌بندی UDP در Community OpenVPN یکی از پیاده‌سازی‌های این ایده است و با قطعه‌بندی IP معمولی بسته بیرونی یکی نیست. هر دو طرف باید نسخه‌ای را اجرا کنند که این قالب را پشتیبانی می‌کند، و مسیر داده باید همانی باشد که فکر می‌کنید: کلاینت‌های OpenVPN 3 و کانال‌های داده شتاب‌یافته در هسته محدودیت‌های متفاوتی دارند، بنابراین پروفایلی که روی یک کلاینت کار می‌کند ممکن است روی دیگری شکست بخورد.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

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

حامل بیرونی مبتنی بر جریان با قطعه‌بندی جریان بایت خودش از مسئله اندازه دور می‌زند، و بسته درونی بازسازی‌شده همچنان می‌تواند 1,500 بایت باشد. این تصمیم انتقالی هزینه خودش را دارد، از جمله رفتار شناخته‌شده TCP درون TCP، پس آن را آگاهانه بگیرید نه به‌عنوان اثر جانبی بحث MTU.

تأیید کنید که بسته درونی بدون تغییر می‌رسد

تأیید، یک دست‌دادن موفق نیست. در هر دو انتها روی رابط تونل ضبط کنید و اندازه و محتوای بسته‌ای را که برنامه واقعاً فرستاده با آنچه طرف دور دریافت کرده مقایسه کنید.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

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

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