قاعدة MSS تعمل على الموجّه لكنها تُخطئ Squid

يضيف مسؤول النظام تقييد TCPMSS إلى FORWARD. تتحسّن حركة المرور الموجّهة مباشرة، لكن التنزيلات عبر نسخة Squid المحلية تظلّ متوقفة. اتصال الوكيل بموقع الويب ليس مجرد اتصال TCP الخاص بالعميل يمر عبر تلك السلسلة.

في وكيل أمامي عادي يُنهي الاتصال، ينتهي الاتصال المواجه للعميل محليًا. يُنشئ الوكيل اتصال TCP ثانيًا نحو المصدر أو الأصل الأعلى. على Linux، تتبع الحزم المتولدة لذلك الاتصال مسار الخرج المحلي.

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

لا تضع رقم PMTU مباشرة في MSS

MTU المسار هو حجم حزمة IP. أما TCP MSS فيصف حمولة TCP وعليه أن يراعي الترويسات المعنية. وبالمثل، طول حمولة ping ليس طول حزمة IP الكامل. والإضافة المعروفة بمقدار 28 بايت مرتبطة بترتيب ICMP echo أساسي على IPv4، لا بكل عائلة عناوين أو تغليف.

يوثّق هدف TCPMSS قيمًا صريحة وتقييد PMTU. ولا يزال التقييد يعتمد على معلومات MTU الخاصة بالمسار؛ فهو ليس دليلًا على سلامة اكتشاف المسار ولا بديلًا عن السماح برسائل ICMP اللازمة.

طابِق أيضًا العَرَض مع النظرية. مصافحة مكتملة يتبعها توقف في النقلات الأكبر قد يبرّر التحقيق في حجم الحزمة. أما تكرار SYN بلا رد أو reset فوري فيحتاج تفسيرًا أوسع؛ وفشل الحزم الصغيرة لا يثبت وجود مقطع بيانات أكبر من اللازم.

أبقِ الاتصال المباشر العامل واتصال الوكيل الفاشل منفصلين في السجل. فقد يستخدمان مصادر ومسارات وتغليفًا مختلفين، حتى من الجهاز نفسه.