بسته IPv6 خیلی بزرگ: چرا انتقال‌های بزرگ VPN متوقف می‌شود

پینگ کار می‌کند، مرورگر یک صفحه کوچک را بارگذاری می‌کند و انتقال فایل گیر می‌کند، همه روی IPv6 از طریق همان تونل. این الگو معمولاً یعنی فرستنده هرگز اندازه واقعی مسیر را یاد نگرفته است، نه اینکه تونل کند باشد. IPv6 انتظار دارد روترها مشکل را با پیام Packet Too Big گزارش دهند، و کپسوله‌سازی پیش از آنکه بسته به شبکه بیرونی برسد سرباری اضافه می‌کند. اگر آن پیام فیلتر شود، فرستنده همچنان اندازه‌ای را تکرار می‌کند که نمی‌تواند عبور کند.

درخواست‌های کوچک، توقف‌های بزرگ

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

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

Packet Too Big بازخورد است، نه ترافیک

پیام ICMPv6 Packet Too Big اندازه‌ای را حمل می‌کند که گام بعدی می‌تواند بپذیرد، و فرستنده از آن برای کاهش برآورد خود استفاده می‌کند. فیلتر کردن آن مانند برداشتن یک تابلوی جاده و سپس سرزنش رانندگان است. قاعده‌ای که همه ICMPv6 را دور می‌ریزد سخت‌گیر به نظر می‌رسد اما کشف مسیر را روی هر پیوندی که به آن نیاز دارد می‌شکند. این پیام اطلاعات کنترلی درباره مسیر است، نه بار داده برنامه.

فیلتر کردن گزینشی هنوز منطقی است. درخواست‌های پژواک و کشف همسایه نقش متفاوتی از پیام‌های خطا دارند و یک سیاست می‌تواند با آنها متفاوت رفتار کند. راهنمای مستند فیلتر کردن سکو را دنبال کنید، نه اینکه کل پروتکل را بپذیرید یا دور بریزید، زیرا RFC 8201 تعیین می‌کند که آن بازخورد چگونه کشف را هدایت می‌کند.

هر دو خانواده نشانی را جداگانه بررسی کنید

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

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

کاوشگر بسته‌ای با بیت do-not-fragment روشن می‌فرستد و اندازه‌ای را گزارش می‌کند که در آن شکست می‌خورد، همان عددی که تونل باید جا دهد. پرس‌وجوی مسیر رابطی را نام می‌برد که مقصد را حمل می‌کرد، تا بدانید کدام MTU پیوند اعمال می‌شود. ثبت، ICMPv6 نوع 2 یعنی پیام Packet Too Big را فیلتر می‌کند و نشان می‌دهد آیا اصلاً به این میزبان می‌رسد. اگر پیام در ثبت دیده شود و انتقال هنوز گیر کند، فرستنده آن را نادیده می‌گیرد، که بررسی را به پشته به‌جای شبکه منتقل می‌کند.

اندازه تونل را فقط پس از شواهد تنظیم کنید

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

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