ضبط MSS لبروتوكول TCP على بوابة IPsec بنظام Linux: ما الذي يصلحه

يعمل Ping، ويعمل SSH، وتُحمَّل صفحة صغيرة، ثم يتعطل كل رد كبير حتى تنتهي مهلته. النمط الكلاسيكي يشير إلى حجم الحزمة لا إلى إمكانية الوصول: المسار يحمل المصافحة وأول بضعة كيلوبايت، ثم تختفي حزمة كاملة الحجم. على بوابة IPsec تعمل بنظام Linux، غالبًا ما تكون قاعدة MSS في TCP هي الإصلاح، لكن فقط إذا فهمت ما الذي تغيّره وأين توجد الحزمة التي تلمسها فعليًا. الترتيب أدناه يتبع الحزمة من العَرَض إلى موضع القاعدة، حتى تتمكن من التوقف بمجرد أن يتوقف الشرح عن الملاءمة.

العَرَض الذي يشير إلى MSS

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

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

ما تفعله قاعدة TCPMSS وما لا تفعله

تعيد القاعدة كتابة خيار MSS في حزم مصافحة TCP أثناء مرورها. وهي لا تضبط MTU لواجهة النفق، ولا تغيّر سياسة IPsec، وعلى النوى الحالية تخفض فقط قيمة معلنة بدلًا من رفع قيمة أصغر بالفعل. كما أنها تلمس TCP فقط؛ حمولات UDP وسلوك DNS ومحددات حركة المرور المتفاوض عليها كلها خارج نطاقها.

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

ضع القاعدة على مسار TCP الداخلي

على بوابة Linux قائمة على السياسات، لا تزال الحزمة المُمرَّرة تبدو كـ TCP عادي عندما يراها جدار الحماية. سياسة IPsec تقرر أن الحزمة ستُحمى؛ ولا يرى جدار الحماية ترويسة ESP للتدفق الداخلي، لذا فإن المطابقة على ESP هنا تصف حزمة مختلفة تمامًا. هذا التعارض هو سبب أن بعض القواعد تبدو صحيحة ولا تطابق أبدًا.

بمصطلحات iptables، تنتمي القاعدة إلى جدول mangle على مسار التمرير، مقصورة على حزم المصافحة: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. الرقم مثال وليس ثابتًا عالميًا؛ استنتجه من عبء التغليف ومن MTU الحقيقي للمسار. مكافئ nftables يضبط أقصى حجم للحزمة في سلسلة forward أو postrouting.

أبقِ قواعد المستمع الخارجية لـ IKE وESP منفصلة عن قواعد التمرير الداخلية. القاعدة الواحدة التي تحاول تخويل تدفق التطبيق والبروتوكول الخارجي معًا تنتهي بعدم مطابقة أي منهما بشكل موثوق.

احترم مالك جدار الحماية وترتيب NAT

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

ترجمة المصدر قرار منفصل يتفاعل غالبًا مع هذا القرار. الاستثناء الموضوع قبل قاعدة masquerade عامة يمنع حركة المرور المحمية من فقدان المصدر الذي تتطلبه سياستها؛ وهو لا يصلح مشكلة حجم، وقاعدة الحجم لا تصلح مشكلة ترجمة.

تحقّق بدقة، ثم توقف

افتح اتصالًا جديدًا بالخدمة الفاشلة وراقب كلا من التطبيق وعدّادات القاعدة. إذا اختفى التعطل، فلديك دليل على مسار TCP ذلك بذلك التغليف. وليس لديك دليل على أن كل بروتوكول VPN يناسب، أو أن كل تطبيق UDP أُصلح، أو أن خدمة معينة في المنبع كانت السبب الأصلي.

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