چرا صفحه‌های OpenConnect تا زمانی که MTU تونل را کم نکنید گیر می‌کنند

ورود موفق می‌شود، صفحهٔ اصلی پورتال رسم می‌شود و سپس یک ویجت داشبورد یا یک گزارش در waiting for host می‌ماند تا مرورگر تسلیم شود. سایت‌های عمومی در تمام این مدت عادی بارگذاری می‌شوند و هیچ اعتبارنامه‌ای تغییر نکرده است. رسیدن پاسخ‌های کوچک در حالی که پاسخ‌های بزرگ گیر می‌کنند، نشانهٔ سقف اندازهٔ بسته است نه قاعدهٔ دسترسی. پیش از تغییر هر چیز دیگری در پروفایل، این برداشت را تأیید کنید.

مشکل اندازه را از مشکل سیاست جدا کنید

با رد کردن احتمال رد شدن شروع کنید. اگر دروازه شما را رد کرده بود، اتصال بی‌درنگ شکست می‌خورد نه اینکه صفحه را نیمه بار کند. تونلی که بالا می‌آید و بعد فقط در انتقال‌های بزرگ‌تر گیر می‌کند به شما می‌گوید مسیر بیرونی نمی‌تواند بستهٔ درونی را حمل کند.

سازوکار، کپسوله‌سازی است. هر بستهٔ درونی سرآیندهای تونل می‌گیرد، بنابراین بار مفیدی که در پیوند فیزیکی جا می‌شد به بستهٔ بیرونی تبدیل می‌شود که دیگر جا نمی‌شود، و هر چیزی که بیت do-not-fragment را حمل کند بدون پاسخی که مرورگر بتواند تفسیر کند دور ریخته می‌شود.

سقف را با کاوش‌های do-not-fragment اندازه بگیرید

سقف را اندازه بگیرید نه اینکه حدس بزنید. کاوش‌هایی بفرستید که قطعه‌بندی را رد می‌کنند و بار را پله‌پله کم کنید تا پاسخی برگردد، با فرمانی مانند ping -M do -s 1472 host شروع کنید. پاسخی که شکایت می‌کند در حالی که DF تنظیم شده قطعه‌بندی لازم است یعنی مقدار هنوز زیاد است. در 1462 و سپس 1452 تکرار کنید و در نخستین اندازه‌ای که پاسخ می‌دهد بایستید. عدد را همراه با میزبانی که کاوش کردید ثبت کنید، چون پاسخ به همان مسیر تعلق دارد نه به پروتکل به‌طور کلی.

نشانی‌ای را کاوش کنید که تونل واقعاً ترافیک را به آن می‌فرستد. کاوش بیرونی در برابر نام عمومی دروازه و کاوش درونی در برابر یک سرور داخلی گام‌های متفاوتی را اندازه می‌گیرند و فیلتر ICMP روی هر یک از آن‌ها می‌تواند مسیر سالمی را خراب نشان دهد.

مقدار را روی دستگاه تونل اعمال کنید

نتیجه را روی رابطی اعمال کنید که کارخواه ساخته است، نه روی مبدل Wi-Fi. در کارخواه لینوکس این ip link set dev tun0 mtu 1300 و سپس ip link show tun0 است تا تأیید شود مقدار پذیرفته شده است. هر نام دستگاهی را که کارخواه گزارش می‌کند به کار ببرید، چون بسته به پیاده‌سازی و به نحوهٔ ساخت تونل تغییر می‌کند.

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

ابتدا از درخواست‌های MTU خود کارخواه استفاده کنید

وقتی فراخوانی را شما کنترل می‌کنید، کارخواه می‌تواند اندازه‌ای بخواهد به‌جای اینکه بعداً وصله شود. --mtu از سرور MTU تونل می‌خواهد و --base-mtu MTU مسیر زیرین را اعلام می‌کند تا دروازه بتواند عدد تونل را استخراج کند. هر دو درخواست هستند و راهنمای کارخواه تضمین نمی‌کند که دروازه هیچ‌کدام را رعایت کند.

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

با همان انتقالی که شکست خورد بررسی کنید و سپس آن را پایدار کنید

یک تغییر محلی ip link تا زمانی دوام می‌آورد که کارخواه تونل را دوباره بسازد، که در اتصال دوباره یا ازسرگیری بعدی رخ می‌دهد. مقدار را جایی بگذارید که اتصال آغاز می‌شود: پوشانه‌ای که کارخواه را اجرا و سپس دستگاه را تنظیم می‌کند، یک واحد systemd با گام ExecStartPost، یا گزینهٔ کارخواه وقتی دروازه آن را می‌پذیرد. آن را کنار پروفایل در کنترل نسخه نگه دارید تا نفر بعدی ببیند چرا عدد آنجاست.

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

اگر همان انتقال در همان نقطه گیر کند، نظریهٔ MTU اثبات‌نشده است. ترافیک را روی تونل ثبت کنید و پیش از تغییر دوبارهٔ عدد بررسی کنید کدام سمت فرستادن را متوقف می‌کند، و مقدار پیشین را ثبت‌شده نگه دارید تا بازگردانی یک فرمان باقی بماند.