كن حذرا من نقاط الضعف التي تجلب الحلول. الجزء 1: FragmentSmack / SegmentSmack

مرحبا بالجميع! اسمي ديمتري سامسونوف ، أعمل كمسؤول نظام رائد في Odnoklassniki. لدينا أكثر من 7 آلاف خادم فعلي ، و 11 ألف حاوية في السحابة لدينا و 200 تطبيق ، والتي تشكل بتكوينات مختلفة 700 مجموعة مختلفة. الغالبية العظمى من الخوادم تعمل بنظام CentOS 7.
معلومات الضعف FragmentSmack تم إصدارها في 14 أغسطس 2018
( CVE-2018-5391 ) و SegmentSmack ( CVE-2018-5390 ). هذه ثغرات أمنية مع ناقل الهجوم على الشبكة وتصنيف مرتفع إلى حد ما (7.5) ، مما يهدد برفض الخدمة (DoS) بسبب استنفاد الموارد (CPU). لم يتم اقتراح إصلاح في kernel لـ FragmentSmack في ذلك الوقت ، علاوة على ذلك ، فقد جاء بعد وقت طويل من نشر المعلومات حول مشكلة عدم الحصانة. للقضاء على SegmentSmack ، تم اقتراح تحديث النواة. تم إصدار حزمة التحديث نفسها في نفس اليوم ، وكان كل ما تبقى هو تثبيته.
لا ، نحن لسنا على الإطلاق ضد تحديث النواة! ومع ذلك ، هناك فروق دقيقة ...

كيف يمكننا تحديث الأساسية على همز

بشكل عام ، لا شيء معقد:

1. تحميل الحزم
2. تثبيتها على عدد من الخوادم (بما في ذلك الخوادم التي تستضيف السحابة الخاصة بنا) ؛
3. تأكد من عدم كسر أي شيء ؛
4. تأكد من تطبيق جميع إعدادات kernel القياسية دون أخطاء ؛
5. انتظر بضعة ايام
6. تحقق أداء الخادم ؛
7. تبديل نشر خوادم جديدة إلى نواة جديدة ؛
8. تحديث جميع الخوادم بواسطة مراكز البيانات (مركز بيانات واحد في كل مرة لتقليل التأثير للمستخدمين في حالة حدوث مشكلات) ؛
9. إعادة تشغيل جميع الخوادم.

كرر جميع فروع النوى لدينا. في هذه اللحظة هذا:

• Stock CentOS 7 3.10 - لمعظم الخوادم العادية ؛
• الفانيليا 4.19 مخصصة لسحابة واحدة لأننا نحتاج إلى BFQ ، BBR ، إلخ ؛
• Elrepo kernel-ml 5.2 مخصص للموزعين ذوي التحميل العالي ، لأن 4.19 كان يتصرف بشكل غير مستقر ، والميزات تحتاج إلى نفس العناصر.

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

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

FragmentSmack / SegmentSmack. الحل

لحسن الحظ ، بالنسبة لبعض نقاط الضعف ، توجد مثل هذه الخطة "B" ، ويسمى Workaround. غالبًا ما يكون هذا تغييرًا في إعدادات kernel / application ، مما يمكن أن يقلل من التأثير المحتمل أو يزيل استغلال الثغرات بالكامل.

في حالة FragmentSmack / SegmentSmack ، تم اقتراح الحل البديل التالي:

" يمكنك تغيير القيم الافتراضية وهي 4 ميجابايت و 3 ميجابايت في net.ipv4.ipfrag_high_thresh و net.ipv4.ipfrag_low_thresh (ونظائرها الخاصة بـ ipv6 net.ipv6.ipfrag_high_thresh و net.ipv6.ipfrag_low_thresh) إلى 256 كيلو بايت و 192 كيلو بايت على التوالي. تُظهر الاختبارات انخفاضًا بسيطًا إلى انخفاض كبير في استخدام وحدة المعالجة المركزية أثناء الهجوم ، اعتمادًا على المعدات والإعدادات والظروف. ومع ذلك ، قد يكون هناك بعض التأثير في الأداء بسبب ipfrag_high_thresh = 262144 بايت ، نظرًا لأن شظايا 64 كيلو فقط فقط يمكن أن تندرج في قائمة انتظار إعادة البناء في كل مرة. على سبيل المثال ، هناك خطر من تعطل التطبيقات التي تعمل مع حزم UDP الكبيرة . "

يتم وصف المعلمات نفسها في وثائق kernel كما يلي:

ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.

ليس لدينا UDP كبيرة على خدمات الإنتاج. لا توجد حركة مرور مجزأة على شبكة LAN ؛ فهناك ، ولكن ليس ، حركة مرور كبيرة على شبكة WAN. لا شيء bodes - يمكنك لفة Workaround!

FragmentSmack / SegmentSmack. الدم الأول

المشكلة الأولى التي واجهناها هي أن الحاويات السحابية كانت تطبق جزئيًا الإعدادات الجديدة في بعض الأحيان فقط (ipfrag_low_thresh فقط) ، وأحيانًا لم تستخدمها على الإطلاق - لقد تعطلت فقط في البداية. لم يكن من الممكن إعادة إنتاج المشكلة بثبات (يدوياً تم تطبيق كافة الإعدادات دون أي صعوبات). كما أن فهم سبب سقوط الحاوية في البداية ليس بهذه البساطة: لم يتم العثور على أخطاء. كان هناك شيء واحد مؤكد: التراجع عن الإعدادات يحل مشكلة إسقاط الحاويات.

لماذا لا يكفي استخدام Sysctl على المضيف؟ تعيش الحاوية في Namespace الخاصة بشبكتها ، لذلك قد يختلف جزء من معلمات Sysctl الموجودة في الحاوية على الأقل عن المضيف.

كيف بالضبط إعدادات Sysctl في الحاوية تنطبق؟ نظرًا لوجود حاويات غير منقسمة ، فإن تغيير أي إعداد Sysctl من خلال الدخول إلى الحاوية نفسها سوف يفشل - ببساطة لن تكون هناك حقوق كافية. في ذلك الوقت ، استخدمت السحابة الخاصة بنا Docker (الآن Podman ) لإطلاق الحاويات. تجاوز عامل النقل عبر واجهة برمجة التطبيقات (API) معلمات الحاوية الجديدة ، بما في ذلك إعدادات Sysctl اللازمة.
أثناء تعداد الإصدارات ، اتضح أن واجهة Docker API لم ترمي كل الأخطاء (على الأقل في الإصدار 1.10). عند محاولة بدء تشغيل الحاوية من خلال "تشغيل عامل الإرساء" ، رأينا أخيرًا شيئًا على الأقل:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

قيمة المعلمة غير صالحة. لكن لماذا؟ ولماذا لا يصلح فقط في بعض الأحيان؟ اتضح أن Docker لم يضمن تطبيق معلمات Sysctl (أحدث إصدار تم اختباره كان 1.13.1) ، لذلك في بعض الأحيان حاول ipfrag_high_thresh تعيين نفسه على 256 كيلو بايت عندما كان ipfrag_low_thresh لا يزال 3M ، أي أن الحد العلوي كان أقل من الحد الأدنى ، مما أدى إلى حدوث خطأ.

في ذلك الوقت ، استخدمنا بالفعل آليتنا الخاصة لإعادة تكوين الحاوية بعد البدء (تجميد الحاوية من خلال المجمد cgroup وتنفيذ الأوامر في مساحة اسم الحاوية عبر شبكات IP ) ، وأضفنا أيضًا معلمات Sysctl إلى هذا الجزء. تم حل المشكلة.

FragmentSmack / SegmentSmack. الدم الأول 2

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

أولاً وقبل كل شيء ، بالطبع ، حاولنا استعادة إعدادات Sysctl ، لكن هذا لم يعطي أي تأثير. لم يساعد التلاعب المختلفة مع إعدادات الخادم والتطبيق. ساعد إعادة التشغيل. يعد إعادة التشغيل لنظام التشغيل Linux أمرًا غير طبيعي بقدر ما كان حالة عادية للعمل مع Windows في الأيام الخوالي. ومع ذلك ، فقد ساعدنا ، وكنا شطبنا كل شيء إلى "خلل في النواة" عند تطبيق الإعدادات الجديدة في Sysctl. كم كانت تافهة ...

بعد ثلاثة أسابيع ، تكررت المشكلة. كان تكوين هذه الخوادم بسيطًا جدًا: Nginx في وضع الوكيل / الموازن. حركة المرور قليلا. تمهيدي جديد: عدد الأخطاء 504 ( عبّارة المهلة ) يتزايد كل يوم على العملاء. يوضح الرسم البياني عدد الأخطاء 504 يوميًا لهذه الخدمة:



جميع الأخطاء تدور حول نفس الخلفية - عن الخطأ الموجود في السحابة. كان الرسم البياني لاستهلاك الذاكرة لشظايا الحزمة في هذه الخلفية كما يلي:



يعد هذا أحد أكثر مظاهر المشكلة بروزًا على رسومات نظام التشغيل. في السحابة ، في نفس الوقت ، تم إصلاح مشكلة أخرى في الشبكة باستخدام إعدادات جودة الخدمة (التحكم في حركة المرور). في الرسم البياني لاستهلاك الذاكرة لشظايا الحزمة ، بدا الأمر كما هو:



كان الافتراض بسيطًا: إذا كانت تبدو متشابهة في الرسوم البيانية ، عندها يكون لها نفس السبب. علاوة على ذلك ، فإن أي مشاكل مع هذا النوع من الذاكرة نادرة للغاية.

كان جوهر المشكلة الثابتة هو أننا استخدمنا sheduler حزمة fq مع الإعدادات الافتراضية في جودة الخدمة. افتراضيًا ، بالنسبة لاتصال واحد ، يسمح لك بإضافة 100 حزمة إلى قائمة الانتظار ، وبدأت بعض الاتصالات في حالة نقص القناة تسد قائمة الانتظار إلى الفشل. في هذه الحالة ، تنخفض الحزم. في إحصائيات tc (tc -s qdisc) ، يمكن ملاحظة ذلك على النحو التالي:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

"464545 flow_plimit" هي الحزم التي تم إسقاطها بسبب تجاوز حد قائمة الانتظار لاتصال واحد ، و "التي تم إسقاطها 464545" هي مجموع كل الحزم التي تم إسقاطها من وحدة الحماية هذه. بعد زيادة طول قائمة الانتظار إلى 1000 وإعادة تشغيل الحاويات ، توقفت المشكلة عن الظهور. يمكنك الجلوس على كرسي والحصول على عصير.

FragmentSmack / SegmentSmack. الدم الماضي

أولاً ، بعد أشهر قليلة من إعلان الثغرات الأمنية في النواة ، ظهر أخيرًا إصلاح لـ FragmentSmack (أذكر أنه مع الإعلان في أغسطس تم إصدار إصلاح فقط لـ SegmentSmack) ، مما أعطانا فرصة للتخلي عن Workaround ، مما تسبب لنا في الكثير من المتاعب. لقد تمكنا بالفعل من نقل بعض الخوادم خلال هذا الوقت إلى نواة جديدة ، والآن يجب أن نبدأ من البداية. لماذا قمنا بتحديث kernel دون انتظار إصلاح FragmentSmack؟ والحقيقة هي أن عملية الحماية من نقاط الضعف هذه تزامنت (ودمجت) مع عملية تحديث CentOS نفسها (والتي تستغرق وقتًا أطول من تحديث النواة فقط). بالإضافة إلى ذلك ، تعتبر SegmentSmack مشكلة عدم حصانة أكثر خطورة ، وقد ظهر إصلاح لها على الفور ، لذلك كانت النقطة في أي حال. ومع ذلك ، لا يمكننا ببساطة تحديث النواة على CentOS ، لأن ثغرة FragmentSmack ، التي ظهرت خلال CentOS 7.5 ، تم إصلاحها فقط في الإصدار 7.6 ، لذلك اضطررنا إلى إيقاف الترقية إلى 7.5 والبدء من جديد مرة أخرى مع الترقية إلى 7.6. وهذا هو الحال كذلك.

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

كما نتذكر من القصة أعلاه ، لم يساعد تراجع Sysctl. ساعد إعادة التشغيل ، ولكن مؤقتا.
لم يتم رفع الشكوك حول Sysctl ، ولكن هذه المرة كان مطلوبًا جمع أكبر قدر ممكن من المعلومات. كذلك ، كان هناك نقص شديد في القدرة على إعادة إنتاج المشكلة مع تحميل العميل من أجل فحص ما كان يحدث بدقة أكبر.

تحليل جميع الإحصاءات والسجلات المتاحة لم تقربنا من فهم ما كان يحدث. كان هناك نقص حاد في القدرة على إعادة إنتاج المشكلة من أجل "الشعور" باتصال معين. أخيرًا ، تمكن المطورين على الإصدار الخاص للتطبيق من تحقيق استنساخ مستقر للمشاكل على جهاز الاختبار عند الاتصال عبر Wi-Fi. كان هذا طفرة في التحقيق. العميل المتصل بـ Nginx ، لقد تقريبًا إلى الواجهة الخلفية ، وهو تطبيق Java الخاص بنا.



كان مربع الحوار مع المشكلات كما يلي (ثابت على جانب وكيل Nginx):

1. العميل: طلب للحصول على معلومات حول تنزيل ملف.
2. خادم جافا: الجواب.
3. العميل: POST مع الملف.
4. خادم جافا: خطأ.

في الوقت نفسه ، يكتب خادم Java إلى السجل أنه تم استلام 0 بايت من البيانات من العميل ، وأن وكيل Nginx الذي استغرق الطلب أكثر من 30 ثانية (30 ثانية هي مهلة تطبيق العميل). لماذا المهلة ولماذا 0 بايت؟ من وجهة نظر HTTP ، كل شيء يعمل كما يجب ، ولكن يبدو أن POST مع الملف يختفي من الشبكة. ويختفي بين العميل و Nginx. حان الوقت لتسليح نفسك مع Tcpdump! ولكن أولاً تحتاج إلى فهم تكوين الشبكة. الوكيل nginx هو وراء موازن N3ware L3. يستخدم النفق لتسليم الحزم من موازن L3 إلى الخادم ، مما يضيف رؤوسه إلى الحزم:



في الوقت نفسه ، تأتي الشبكة إلى هذا الخادم في شكل حركة مرور على شبكة محلية ظاهرية ، والتي تضيف أيضًا حقولها إلى حزم:



ويمكن تجزئة حركة المرور هذه (النسبة المئوية الصغيرة جدًا لحركة المرور المجزأة الواردة التي تحدثنا عنها عند تقييم المخاطر من Workaround) ، مما يؤدي أيضًا إلى تغيير محتوى الرؤوس:



مرة أخرى: يتم تغليف الحزم بواسطة علامة شبكة محلية ظاهرية (Vlan tag) ، مغلفة بواسطة نفق ، مجزأ. لفهم كيفية حدوث ذلك بشكل أفضل ، دعنا نتتبع مسار الحزمة من العميل إلى وكيل Nginx.

1. تصل الحزمة إلى L3-balancer. للتوجيه الصحيح داخل مركز البيانات ، يتم تغليف الحزمة في النفق وإرسالها إلى بطاقة الشبكة.
2. نظرًا لعدم احتواء رؤوس الحزمة + النفق على وحدة الإرسال الكبرى ، يتم قطع الحزمة إلى أجزاء وإرسالها إلى الشبكة.
3. يضيف المفتاح بعد L3-balancer عند استلام الحزمة علامة Vlan إليها ويرسلها أكثر.
4. رمز التبديل قبل وكيل Nginx يرى (وفقًا لإعدادات المنفذ) أن الخادم يتوقع حزمة مغلفة بالشبكة المحلية الظاهرية ، لذلك يرسلها كما هي ، دون إزالة علامة Vlan.
5. يتلقى Linux أجزاء من الحزم الفردية ويصقها في حزمة واحدة كبيرة.
6. ثم تصل الحزمة إلى واجهة شبكة محلية ظاهرية ، حيث تتم إزالة الطبقة الأولى منها - غلاف شبكة محلية ظاهرية.
7. يرسل Linux بعد ذلك إلى واجهة Tunnel ، حيث تتم إزالة طبقة أخرى منه - تغليف Tunnel.

الصعوبة تكمن في تمرير كل هذا كمعلمات إلى tcpdump.
لنبدأ من النهاية: هل هناك أي حزم IP نظيفة (بدون رؤوس إضافية) من عملاء مع إزالة شبكة محلية ظاهرية وتغليف النفق؟

tcpdump host <ip >

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

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx هو عنوان IP للعميل بتنسيق ست عشري.
32: 4 - عنوان وطول الحقل الذي كتب فيه SCR IP في حزمة Tunnel.

كان يجب تحديد عنوان الحقل عن طريق القوة الغاشمة ، حيث أن الإنترنت يكتب حوالي 40 ، 44 ، 50 ، 54 ، ولكن لم يكن هناك عنوان IP. يمكنك أيضًا إلقاء نظرة على إحدى الحزم في ست عشري (المعلمة -xx أو -XX في tcpdump) وحساب عنوان IP المعروف.

هل هناك أي شظايا حزمة دون تغليف Vlan و Tunnel؟

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

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

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0 , flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 .faEE.....@.2.m.
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.\......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....j Ex
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if ..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480 , flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

هذه شظايا حزمة واحدة (معرف متطابق 53652) مع صورة (كلمة Exif في الحزمة الأولى مرئية). نظرًا لحقيقة وجود حزم على هذا المستوى ، ولكن لا يتم لصقها في مقالب ، فإن المشكلة تكمن بوضوح في التجميع. أخيرًا ، هناك دليل وثائقي على هذا!

وحدة فك ترميز الحزمة لم تكشف عن أي مشكلات تمنع التجميع. حاول هنا: hpd.gasmi.net . في البداية ، عند محاولة حشر شيء هناك ، لا يحب وحدة فك الترميز تنسيق الحزمة. اتضح أن هناك بعض الثمانينات الإضافية بين Srcmac و Ethertype (لا علاقة لها بمعلومات الأجزاء). بعد إزالتها ، عملت وحدة فك الترميز. ومع ذلك ، وقال انه لم تظهر أي مشاكل.
قل ما تريد ، باستثناء أولئك الذين اكتشفوا Sysctl جدًا. بقي لإيجاد طريقة لتحديد الخوادم ذات المشاكل من أجل فهم النطاق واتخاذ قرار بشأن المزيد من الإجراءات. بسرعة كافية وجدت العداد الصحيح:

netstat -s | grep "packet reassembles failed”

في snmpd تحت OID = 1.3.6.1.2.1.4.31.1.1.16.1 ( ipSystemStatsReasmFails ).

"عدد حالات الفشل التي اكتشفتها خوارزمية إعادة تجميع IP (لأي سبب كان: مهلة ، أخطاء ، إلخ)."

من بين مجموعة الخوادم التي تمت دراسة المشكلة عليها ، زاد هذا العداد على اثنين بشكل أسرع ، وعلى اثنين أبطأ ، ولم يزداد على اثنين على الإطلاق. كشفت مقارنة بين ديناميات هذا العداد وديناميكيات أخطاء HTTP على خادم Java عن وجود علاقة. وهذا هو ، يمكن تعيين العداد للمراقبة.

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

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

أهم الأسئلة

لماذا حزم جزء على موازن L3 لدينا؟ معظم الحزم التي تصل من المستخدمين إلى الموازنات هي SYN و ACK. أحجام هذه الحقائب صغيرة. ولكن نظرًا لأن حصة هذه الحزم كبيرة جدًا ، لم نلاحظ وجود حزم كبيرة بدأت تتفتت على خلفية هذه الخلفية.

والسبب في ذلك هو أنه تم تعطيل البرنامج النصي لتكوين advmss على الخوادم المزودة بواجهات شبكة محلية ظاهرية (كان هناك عدد قليل جدًا من الخوادم ذات حركة المرور الموسومة في الإنتاج في ذلك الوقت). تتيح لك Advmss أن تنقل إلى معلومات العميل أن الحزم في اتجاهنا يجب أن تكون أصغر بحيث أنه بعد لصق رؤوس النفق عليها ، لا يجب تجزئتها.

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

هل يمكن أن تفعل دون Workaround؟ نعم ، ولكن هناك خطر كبير في ترك المستخدمين دون مراقبة في حالة حدوث هجوم. بالطبع ، أدى استخدام Workaround كنتيجة إلى العديد من المشكلات ، بما في ذلك تثبيط إحدى الخدمات من قِبل المستخدمين ، ولكن مع ذلك ، نعتقد أن الإجراءات قد تم تبريرها.

شكراً جزيلاً لأندريه تيموفيف ( atimofeyev ) على المساعدة في التحقيق ، وإلى Alexei Krenev ( devicex ) على العمل الضخم المتمثل في تحديث Centos والنواة على الخوادم. هذه العملية ، والتي في هذه الحالة يجب أن تبدأ عدة مرات من البداية ، والتي استمرت بسببها لعدة أشهر.