توقف HTTPS داخل حاوية على شبكة VPN للشركات؟ اختبر مسار DTLS

داخل حاوية خلف VPN للشركات، يُحل DNS وتُحمَّل صفحة تسجيل الدخول وتستجيب نقطة نهاية للفحص الصحي، ثم يتوقف طلب HTTPS حتى تنتهي مهلته. إعادة بناء الصورة وتغيير متغيرات الوسيط لا يغيّران شيئًا، لأن الجزء المعطّل ليس داخل الصورة. يُصادق العميل عبر ناقل واحد وينقل البيانات الكبيرة عبر ناقل آخر، والثاني وحده هو المعطّل.

ناقلان وعرض واحد محيّر

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

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

قرّر بالتجربة لا بالحدس

أرخص تجربة تعطّل قناة بيانات UDP وتعيد الطلب. استخدم عميل سطر الأوامر بدل غلاف سطح المكتب، حتى تُطبَّق العلامة فعليًا: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. إذا اكتمل الطلب الذي كان متوقفًا الآن، فمسار DTLS كان المشكلة والباقي ضجيج.

أكّد النتيجة في الاتجاهين من الحاوية نفسها، طلب كمي واحد مع العلامة وآخر بدونها. تغيّر السلوك الذي يتبع العلامة دليل؛ أما صفحة تُحمَّل في النهاية فليست دليلًا.

إذا أصلحتها العلامة، فقرّر السبب

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

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

تحقق من حجم الحزمة قبل الإبقاء على الحل البديل

إذا كان الحجم هو السبب، فإن واجهة النفق تقبل حزمًا لا يستطيع المسار حملها، وتعود المشكلة على أي ناقل بمجرد أن تكبر الحمولات. قارن الواجهتين: ip link show tun0 على المضيف، ثم docker network inspect bridge لقراءة MTU المسجل في خيارات الشبكة. جسر حاوية لا يزال على 1500 بايت تحت نفق يحمل أقل هو النتيجة المعتادة.

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

قرّر ما أنت مستعد للتضحية به

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

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