لماذا تتوقف صفحات OpenConnect حتى تخفض MTU النفق

ينجح تسجيل الدخول، وتُعرض الصفحة الرئيسية للبوابة، ثم تبقى إحدى أدوات لوحة المعلومات أو أحد التقارير عند waiting for host حتى يستسلم المتصفح. المواقع العامة تُحمّل بشكل طبيعي طوال الوقت، ولم تتغير أي بيانات اعتماد. وصول الردود الصغيرة بينما تتعطل الكبيرة هو بصمة سقف لحجم الحزمة وليس قاعدة وصول. تأكد من هذا الاستنتاج قبل أن تعدّل أي شيء آخر في الملف الشخصي.

افصل مشكلة الحجم عن مشكلة السياسة

ابدأ باستبعاد الرفض. لو رفضك البوابة، لفشل الاتصال فورًا بدلًا من تحميل صفحة نصف تحميل. النفق الذي يبدأ ثم يتعطل فقط عند النقل الأكبر يخبرك أن المسار الخارجي لا يستطيع حمل الحزمة الداخلية.

الآلية هي التغليف. كل حزمة داخلية تكتسب رؤوس النفق، فيصبح الحمل الذي يتسع للرابط الفيزيائي حزمة خارجية لم تعد تتسع، وكل ما يحمل بت do-not-fragment يُسقط دون رد يستطيع المتصفح تفسيره.

قِس السقف بفحوص do-not-fragment

قِس السقف بدلًا من تخمينه. أرسل فحوصًا ترفض التجزئة وأنزل الحمل درجة درجة حتى يعود رد، بدءًا من أمر مثل ping -M do -s 1472 host. الرد الذي يشكو من الحاجة إلى التجزئة مع ضبط DF يعني أن القيمة لا تزال مرتفعة جدًا. أعد عند 1462، ثم 1452، وتوقف عند أول حجم يعود. سجّل الرقم مع المضيف الذي فحصته، لأن الجواب يخص ذلك المسار وليس البروتوكول عمومًا.

افحص العنوان الذي يرسل النفق حركة المرور إليه فعليًا. الفحص الخارجي ضد الاسم العام للبوابة والفحص الداخلي ضد خادم داخلي يقيسان قفزتين مختلفتين، ويمكن لتصفية ICMP على أي منهما أن تجعل مسارًا سليمًا يبدو معطلًا.

طبّق القيمة على جهاز النفق

طبّق النتيجة على الواجهة التي أنشأها العميل، لا على محول Wi-Fi. على عميل Linux يكون ذلك ip link set dev tun0 mtu 1300 يتبعه ip link show tun0 لتأكيد أن القيمة أُخذت. استخدم أي اسم جهاز يبلغ عنه العميل، لأنه يتغير بحسب التنفيذ وبحسب طريقة بناء النفق.

خفض MTU النفق يقلّص الحمل الذي تحمله كل حزمة، لذا ينخفض الإنتاج الإجمالي قليلًا، وهذا ثمن عدم إسقاط الردود الكبيرة في ثقب أسود. الرقم الأصغر ليس أكثر أمانًا تلقائيًا. تغيير المحول الفيزيائي بدلًا من ذلك ينشر الضرر على كل اتصال على ذلك الرابط بينما تبقى الحزم الداخلية المفرطة الحجم مفرطة الحجم كما هي.

استخدم طلبات MTU الخاصة بالعميل أولًا

عندما تتحكم في الاستدعاء، يمكن للعميل أن يطلب حجمًا بدلًا من ترقيعه لاحقًا. --mtu يطلب MTU للنفق من الخادم، و --base-mtu يعلن MTU المسار الأساسي حتى تستطيع البوابة استنتاج رقم النفق. كلاهما طلبان، و دليل العميل لا يعد بأن البوابة ستحترم أيًا منهما.

هذا التمييز يحدد ترتيب عملك. جرّب الطلب أولًا وافحص الواجهة التي ينتجها، ثم ارجع إلى ضبط الجهاز محليًا إذا كانت القيمة التي اختارتها البوابة لا تزال تتعطل.

تحقق بالنقل الذي فشل، ثم اجعله دائمًا

تغيير ip link المحلي يدوم حتى يعيد العميل بناء النفق، وهو ما يحدث عند إعادة الاتصال أو الاستئناف التالية. ضع القيمة حيث يبدأ الاتصال: غلاف يشغّل العميل ثم يضبط الجهاز، أو وحدة systemd بخطوة ExecStartPost، أو خيار العميل عندما تقبله البوابة. أبقِه بجانب الملف الشخصي في نظام التحكم بالإصدارات حتى يرى الشخص التالي لماذا الرقم موجود.

اختبر بالطلب الذي فشل، لا بالصفحة الرئيسية. افتح التقرير، أو اسحب المرفق، أو نفّذ جلب المستودع الذي تعطل، ولاحظ بالضبط أين يتوقف إن كان لا يزال يتوقف. الصفحة التي تُعرض بعد التغيير لا تثبت الكثير، لأنها كانت تُعرض قبل ذلك أيضًا.

إذا تعطل النقل نفسه عند النقطة نفسها، فنظرية MTU غير مثبتة. التقط حركة المرور على النفق وافحص أي جانب يتوقف عن الإرسال قبل أن تغيّر الرقم مرة أخرى، وأبقِ القيمة السابقة مسجلة حتى يبقى التراجع أمرًا واحدًا.