🥇उन कमजोरियों से सावधान रहें जो काम में रुकावट लाती हैं। भाग 1: फ्रैगमेंटस्मैक/सेगमेंटस्मैक

नमस्ते! मेरा नाम दिमित्री सैमसनोव है, मैं ओडनोक्लास्निकी में एक अग्रणी सिस्टम प्रशासक के रूप में काम करता हूं। हमारे पास 7 हजार से अधिक भौतिक सर्वर, हमारे क्लाउड में 11 हजार कंटेनर और 200 एप्लिकेशन हैं, जो विभिन्न कॉन्फ़िगरेशन में 700 अलग-अलग क्लस्टर बनाते हैं। अधिकांश सर्वर CentOS 7 चलाते हैं।
14 अगस्त, 2018 को फ्रैगमेंटस्मैक भेद्यता के बारे में जानकारी प्रकाशित की गई थी
(CVE-2018-5391) और सेगमेंटस्मैक (CVE-2018-5390). ये नेटवर्क अटैक वेक्टर और काफी उच्च स्कोर (7.5) के साथ कमजोरियां हैं, जो संसाधन समाप्ति (सीपीयू) के कारण सेवा से इनकार (डीओएस) का खतरा है। उस समय FragmentSmack के लिए कर्नेल फिक्स प्रस्तावित नहीं किया गया था; इसके अलावा, यह भेद्यता के बारे में जानकारी के प्रकाशन की तुलना में बहुत बाद में सामने आया। सेगमेंटस्मैक को खत्म करने के लिए कर्नेल को अपडेट करने का सुझाव दिया गया था। अपडेट पैकेज उसी दिन जारी किया गया था, जो कुछ बचा था उसे इंस्टॉल करना था।
नहीं, हम कर्नेल को अपडेट करने के बिल्कुल भी ख़िलाफ़ नहीं हैं! हालाँकि, कुछ बारीकियाँ हैं...

हम उत्पादन पर कर्नेल को कैसे अद्यतन करते हैं

सामान्य तौर पर, कुछ भी जटिल नहीं:

पैकेज डाउनलोड करें;
उन्हें कई सर्वरों पर स्थापित करें (हमारे क्लाउड को होस्ट करने वाले सर्वर सहित);
सुनिश्चित करें कि कुछ भी टूटा हुआ न हो;
सुनिश्चित करें कि सभी मानक कर्नेल सेटिंग्स त्रुटियों के बिना लागू की गई हैं;
कुछ दिन रुको;
सर्वर प्रदर्शन की जाँच करें;
नए सर्वर की तैनाती को नए कर्नेल पर स्विच करें;
डेटा सेंटर द्वारा सभी सर्वरों को अपडेट करें (समस्याओं की स्थिति में उपयोगकर्ताओं पर प्रभाव को कम करने के लिए एक समय में एक डेटा सेंटर);
सभी सर्वरों को रीबूट करें।

हमारे पास मौजूद गुठली की सभी शाखाओं के लिए दोहराएँ। फिलहाल यह है:

स्टॉक सेंटओएस 7 3.10 - अधिकांश नियमित सर्वर के लिए;
वेनिला 4.19 - हमारे लिए एक बादल वाले बादल, क्योंकि हमें बीएफक्यू, बीबीआर, आदि की आवश्यकता है;
एलरेपो कर्नेल-एमएल 5.2 - के लिए अत्यधिक भरे हुए वितरक, क्योंकि 4.19 अस्थिर व्यवहार करता था, लेकिन समान सुविधाओं की आवश्यकता है।

जैसा कि आपने अनुमान लगाया होगा, हजारों सर्वरों को रीबूट करने में सबसे लंबा समय लगता है। चूँकि सभी कमजोरियाँ सभी सर्वरों के लिए महत्वपूर्ण नहीं हैं, हम केवल उन्हें ही रीबूट करते हैं जो सीधे इंटरनेट से पहुंच योग्य हैं। क्लाउड में, लचीलेपन को सीमित न करने के लिए, हम बाहरी रूप से सुलभ कंटेनरों को एक नए कर्नेल के साथ अलग-अलग सर्वर से नहीं जोड़ते हैं, लेकिन बिना किसी अपवाद के सभी होस्ट को रिबूट करते हैं। सौभाग्य से, वहां की प्रक्रिया नियमित सर्वर की तुलना में सरल है। उदाहरण के लिए, रिबूट के दौरान स्टेटलेस कंटेनर आसानी से दूसरे सर्वर पर जा सकते हैं।

हालाँकि, अभी भी बहुत काम बाकी है, और इसमें कई सप्ताह लग सकते हैं, और यदि नए संस्करण में कोई समस्या है, तो कई महीने भी लग सकते हैं। हमलावर इसे अच्छी तरह समझते हैं, इसलिए उन्हें प्लान बी की ज़रूरत है।

फ्रैगमेंटस्मैक/सेगमेंटस्मैक। वैकल्पिक हल

सौभाग्य से, कुछ कमजोरियों के लिए ऐसी योजना बी मौजूद है, और इसे वर्कअराउंड कहा जाता है। अक्सर, यह कर्नेल/एप्लिकेशन सेटिंग्स में बदलाव होता है जो संभावित प्रभाव को कम कर सकता है या कमजोरियों के शोषण को पूरी तरह से समाप्त कर सकता है।

फ्रैगमेंटस्मैक/सेगमेंटस्मैक के मामले में प्रस्तावित किया गया था यह समाधान:

«आप Net.ipv4.ipfrag_high_thresh और Net.ipv3.ipfrag_low_thresh (और ipv4 Net.ipv4.ipfrag_high_thresh औरnet.ipv6.ipfrag_low_thresh के लिए उनके समकक्ष) में 6MB और 6MB के डिफ़ॉल्ट मानों को क्रमशः 256 kB और 192 kB में बदल सकते हैं या निचला। परीक्षण हार्डवेयर, सेटिंग्स और स्थितियों के आधार पर किसी हमले के दौरान सीपीयू उपयोग में छोटी से लेकर महत्वपूर्ण गिरावट दिखाते हैं। हालाँकि, ipfrag_high_thresh=262144 बाइट्स के कारण कुछ प्रदर्शन प्रभाव पड़ सकता है, क्योंकि एक समय में केवल दो 64K टुकड़े पुन: संयोजन कतार में फिट हो सकते हैं। उदाहरण के लिए, एक जोखिम है कि बड़े यूडीपी पैकेट के साथ काम करने वाले एप्लिकेशन टूट जाएंगे'.

पैरामीटर स्वयं कर्नेल दस्तावेज़ में इस प्रकार वर्णित है:

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.

हमारे पास उत्पादन सेवाओं पर बड़े यूडीपी नहीं हैं। LAN पर कोई खंडित ट्रैफ़िक नहीं है; WAN पर खंडित ट्रैफ़िक है, लेकिन महत्वपूर्ण नहीं है। कोई संकेत नहीं हैं - आप वर्कअराउंड लागू कर सकते हैं!

फ्रैगमेंटस्मैक/सेगमेंटस्मैक। फर्स्ट ब्लड

हमारे सामने पहली समस्या यह थी कि क्लाउड कंटेनर कभी-कभी नई सेटिंग्स को केवल आंशिक रूप से (केवल ipfrag_low_thresh) लागू करते थे, और कभी-कभी उन्हें बिल्कुल भी लागू नहीं करते थे - वे बस शुरुआत में ही क्रैश हो जाते थे। समस्या को स्थिर रूप से पुन: उत्पन्न करना संभव नहीं था (सभी सेटिंग्स बिना किसी कठिनाई के मैन्युअल रूप से लागू की गईं)। यह समझना भी इतना आसान नहीं है कि शुरुआत में कंटेनर क्रैश क्यों होता है: कोई त्रुटि नहीं पाई गई। एक बात निश्चित थी: सेटिंग्स को वापस लाने से कंटेनर क्रैश की समस्या हल हो जाती है।

होस्ट पर Sysctl लागू करना पर्याप्त क्यों नहीं है? कंटेनर अपने स्वयं के समर्पित नेटवर्क नेमस्पेस में रहता है, इसलिए कम से कम नेटवर्क Sysctl पैरामीटर का हिस्सा कंटेनर में होस्ट से भिन्न हो सकता है।

कंटेनर में Sysctl सेटिंग्स वास्तव में कैसे लागू की जाती हैं? चूँकि हमारे कंटेनर विशेषाधिकार रहित हैं, आप स्वयं कंटेनर में जाकर किसी भी Sysctl सेटिंग को बदलने में सक्षम नहीं होंगे - आपके पास बस पर्याप्त अधिकार नहीं हैं। कंटेनर चलाने के लिए, उस समय हमारा क्लाउड डॉकर (अब) का उपयोग करता था पोडमैन). नए कंटेनर के पैरामीटर आवश्यक Sysctl सेटिंग्स सहित, एपीआई के माध्यम से डॉकर को भेज दिए गए थे।
संस्करणों की खोज करते समय, यह पता चला कि डॉकर एपीआई ने सभी त्रुटियां नहीं लौटाईं (कम से कम संस्करण 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.

पैरामीटर मान मान्य नहीं है. लेकिन क्यों? और यह कभी-कभी ही मान्य क्यों नहीं होता? यह पता चला कि डॉकर उस क्रम की गारंटी नहीं देता है जिसमें Sysctl पैरामीटर लागू होते हैं (नवीनतम परीक्षण किया गया संस्करण 1.13.1 है), इसलिए कभी-कभी ipfrag_high_thresh को 256K पर सेट करने का प्रयास किया जाता है जब ipfrag_low_thresh अभी भी 3M था, यानी, ऊपरी सीमा कम थी निचली सीमा से अधिक, जिसके कारण त्रुटि हुई।

उस समय, हमने शुरुआत के बाद कंटेनर को पुन: कॉन्फ़िगर करने (कंटेनर को फ्रीज करने के बाद) के लिए पहले से ही अपने स्वयं के तंत्र का उपयोग किया था समूह फ्रीजर और कंटेनर के नेमस्पेस में कमांड निष्पादित करना आईपी नेटन्स), और हमने इस भाग में Sysctl पैरामीटर लिखना भी जोड़ा है। इस समस्या को हल किया गया था।

फ्रैगमेंटस्मैक/सेगमेंटस्मैक। प्रथम रक्त 2

इससे पहले कि हमारे पास क्लाउड में वर्कअराउंड के उपयोग को समझने का समय होता, उपयोगकर्ताओं की ओर से पहली दुर्लभ शिकायतें आनी शुरू हो गईं। उस समय, पहले सर्वर पर वर्कअराउंड का उपयोग शुरू हुए कई सप्ताह बीत चुके थे। प्रारंभिक जांच से पता चला कि शिकायतें व्यक्तिगत सेवाओं के खिलाफ प्राप्त हुई थीं, न कि इन सेवाओं के सभी सर्वरों के खिलाफ। समस्या फिर बेहद अनिश्चित हो गई है.

सबसे पहले, हमने, निश्चित रूप से, Sysctl सेटिंग्स को वापस रोल करने का प्रयास किया, लेकिन इसका कोई प्रभाव नहीं पड़ा। सर्वर और एप्लिकेशन सेटिंग्स के साथ विभिन्न हेरफेरों से भी कोई मदद नहीं मिली। रीबूट से मदद मिली. लिनक्स को रीबूट करना उतना ही अप्राकृतिक है जितना पुराने दिनों में विंडोज़ के लिए सामान्य था। हालाँकि, इससे मदद मिली, और Sysctl में नई सेटिंग्स लागू करते समय हमने इसे "कर्नेल गड़बड़" तक बना दिया। यह कितना तुच्छ था...

तीन सप्ताह बाद समस्या फिर से उभर आई। इन सर्वरों का कॉन्फ़िगरेशन काफी सरल था: प्रॉक्सी/बैलेंसर मोड में Nginx। ज्यादा ट्रैफिक नहीं. नया परिचयात्मक नोट: ग्राहकों पर 504 त्रुटियों की संख्या हर दिन बढ़ रही है (गेटवे मध्यांतर). ग्राफ़ इस सेवा के लिए प्रतिदिन 504 त्रुटियों की संख्या दिखाता है:

सभी त्रुटियाँ एक ही बैकएंड के बारे में हैं - जो क्लाउड में है उसके बारे में। इस बैकएंड पर पैकेज फ़्रैगमेंट के लिए मेमोरी खपत ग्राफ़ इस तरह दिखता था:

यह ऑपरेटिंग सिस्टम ग्राफ़ में समस्या की सबसे स्पष्ट अभिव्यक्तियों में से एक है। क्लाउड में, ठीक उसी समय, क्यूओएस (ट्रैफ़िक कंट्रोल) सेटिंग्स के साथ एक और नेटवर्क समस्या को ठीक किया गया था। पैकेट टुकड़ों के लिए मेमोरी खपत के ग्राफ़ पर, यह बिल्कुल वैसा ही दिखता था:

धारणा सरल थी: यदि वे ग्राफ़ पर समान दिखते हैं, तो उनका कारण भी समान है। इसके अलावा, इस प्रकार की स्मृति के साथ कोई भी समस्या अत्यंत दुर्लभ है।

निश्चित समस्या का सार यह था कि हमने QoS में डिफ़ॉल्ट सेटिंग्स के साथ fq पैकेट शेड्यूलर का उपयोग किया था। डिफ़ॉल्ट रूप से, एक कनेक्शन के लिए, यह आपको कतार में 100 पैकेट जोड़ने की अनुमति देता है, और कुछ कनेक्शन, चैनल की कमी की स्थिति में, कतार को क्षमता से अवरुद्ध करना शुरू कर देते हैं। इस स्थिति में, पैकेट गिरा दिए जाते हैं। टीसी सांख्यिकी (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 फ़्लो_प्लिमिट" एक कनेक्शन की कतार सीमा से अधिक होने के कारण गिराए गए पैकेट हैं, और "गिराया गया 464545" इस शेड्यूलर के सभी गिराए गए पैकेटों का योग है। कतार की लंबाई 1 हजार तक बढ़ाने और कंटेनरों को फिर से शुरू करने के बाद समस्या आना बंद हो गई। आप आराम से बैठकर स्मूदी पी सकते हैं।

फ्रैगमेंटस्मैक/सेगमेंटस्मैक। अंतिम रक्त

सबसे पहले, कर्नेल में कमजोरियों की घोषणा के कई महीनों बाद, फ्रैगमेंटस्मैक के लिए एक फिक्स अंततः सामने आया (मैं आपको याद दिला दूं कि अगस्त में घोषणा के साथ, केवल सेगमेंटस्मैक के लिए एक फिक्स जारी किया गया था), जिसने हमें वर्कअराउंड को छोड़ने का मौका दिया, जिससे हमें काफी परेशानी हुई। इस दौरान, हम पहले से ही कुछ सर्वरों को नए कर्नेल में स्थानांतरित करने में कामयाब रहे थे, और अब हमें शुरुआत से शुरुआत करनी थी। हमने फ्रैगमेंटस्मैक फिक्स की प्रतीक्षा किए बिना कर्नेल को अपडेट क्यों किया? तथ्य यह है कि इन कमजोरियों से बचाव की प्रक्रिया CentOS को अपडेट करने की प्रक्रिया के साथ मेल खाती है (और विलय हो गई है) (जिसमें केवल कर्नेल को अपडेट करने से भी अधिक समय लगता है)। इसके अलावा, सेगमेंटस्मैक एक अधिक खतरनाक भेद्यता है, और इसका समाधान तुरंत सामने आ गया, इसलिए यह वैसे भी समझ में आता है। हालाँकि, हम केवल CentOS पर कर्नेल को अपडेट नहीं कर सकते क्योंकि FragmentSmack भेद्यता, जो CentOS 7.5 के दौरान दिखाई दी थी, केवल संस्करण 7.6 में तय की गई थी, इसलिए हमें 7.5 पर अपडेट को रोकना पड़ा और 7.6 पर अपडेट के साथ फिर से शुरू करना पड़ा। और ऐसा होता भी है.

दूसरे, समस्याओं के बारे में दुर्लभ उपयोगकर्ता शिकायतें हमारे पास लौट आई हैं। अब हम पहले से ही निश्चित रूप से जानते हैं कि वे सभी क्लाइंट से हमारे कुछ सर्वरों पर फ़ाइलें अपलोड करने से संबंधित हैं। इसके अलावा, कुल द्रव्यमान से बहुत कम संख्या में अपलोड इन सर्वरों के माध्यम से हुए।

जैसा कि हमें ऊपर की कहानी से याद है, Sysctl को वापस लाने से कोई मदद नहीं मिली। रीबूट से मदद मिली, लेकिन अस्थायी तौर पर।
Sysctl के संबंध में संदेह दूर नहीं हुए, लेकिन इस बार यथासंभव अधिक जानकारी एकत्र करना आवश्यक था। क्या हो रहा था इसका अधिक सटीक अध्ययन करने के लिए क्लाइंट पर अपलोड समस्या को पुन: उत्पन्न करने की क्षमता की भी भारी कमी थी।

सभी उपलब्ध आँकड़ों और लॉग का विश्लेषण हमें यह समझने के करीब नहीं लाया कि क्या हो रहा था। किसी विशिष्ट संबंध को "महसूस" करने के लिए समस्या को पुन: उत्पन्न करने की क्षमता की तीव्र कमी थी। अंत में, डेवलपर्स, एप्लिकेशन के एक विशेष संस्करण का उपयोग करके, वाई-फाई के माध्यम से कनेक्ट होने पर एक परीक्षण डिवाइस पर समस्याओं का स्थिर पुनरुत्पादन प्राप्त करने में कामयाब रहे। यह जांच में एक बड़ी सफलता थी. क्लाइंट Nginx से जुड़ा था, जो बैकएंड पर प्रॉक्सी करता था, जो हमारा जावा एप्लिकेशन था।

समस्याओं के लिए संवाद इस प्रकार था (Nginx प्रॉक्सी पक्ष पर तय):

क्लाइंट: फ़ाइल डाउनलोड करने के बारे में जानकारी प्राप्त करने का अनुरोध।
जावा सर्वर: प्रतिक्रिया.
ग्राहक: फ़ाइल के साथ पोस्ट करें.
जावा सर्वर: त्रुटि.

उसी समय, जावा सर्वर लॉग में लिखता है कि क्लाइंट से 0 बाइट्स डेटा प्राप्त हुआ था, और Nginx प्रॉक्सी लिखता है कि अनुरोध में 30 सेकंड से अधिक समय लगा (30 सेकंड क्लाइंट एप्लिकेशन का टाइमआउट है)। टाइमआउट क्यों और 0 बाइट्स क्यों? HTTP परिप्रेक्ष्य से, सब कुछ वैसे ही काम करता है जैसे उसे करना चाहिए, लेकिन फ़ाइल वाला POST नेटवर्क से गायब हो जाता है। इसके अलावा, यह क्लाइंट और Nginx के बीच गायब हो जाता है। अब खुद को टीसीपीडम्प से लैस करने का समय आ गया है! लेकिन सबसे पहले आपको नेटवर्क कॉन्फ़िगरेशन को समझने की आवश्यकता है। Nginx प्रॉक्सी L3 बैलेंसर के पीछे है एनएफवेयर. टनलिंग का उपयोग L3 बैलेंसर से सर्वर तक पैकेट पहुंचाने के लिए किया जाता है, जो अपने हेडर को पैकेट में जोड़ता है:

इस मामले में, नेटवर्क Vlan-टैग किए गए ट्रैफ़िक के रूप में इस सर्वर पर आता है, जो पैकेट में अपने स्वयं के फ़ील्ड भी जोड़ता है:

और इस ट्रैफ़िक को खंडित भी किया जा सकता है (आने वाले खंडित ट्रैफ़िक का वही छोटा प्रतिशत जिसके बारे में हमने वर्कअराउंड से जोखिमों का आकलन करते समय बात की थी), जो हेडर की सामग्री को भी बदलता है:

एक बार फिर: पैकेटों को Vlan टैग के साथ संपुटित किया जाता है, एक सुरंग के साथ संपुटित किया जाता है, खंडित किया जाता है। यह कैसे होता है इसे बेहतर ढंग से समझने के लिए, आइए क्लाइंट से Nginx प्रॉक्सी तक पैकेट रूट का पता लगाएं।

पैकेट L3 बैलेंसर तक पहुंचता है। डेटा सेंटर के भीतर सही रूटिंग के लिए, पैकेट को एक सुरंग में एनकैप्सुलेट किया जाता है और नेटवर्क कार्ड पर भेजा जाता है।
चूंकि पैकेट + टनल हेडर एमटीयू में फिट नहीं होते हैं, इसलिए पैकेट को टुकड़ों में काट दिया जाता है और नेटवर्क पर भेज दिया जाता है।
L3 बैलेंसर के बाद का स्विच, एक पैकेट प्राप्त करते समय, उसमें एक Vlan टैग जोड़ता है और इसे भेजता है।
Nginx प्रॉक्सी के सामने का स्विच देखता है (पोर्ट सेटिंग्स के आधार पर) कि सर्वर Vlan-एनकैप्सुलेटेड पैकेट की उम्मीद कर रहा है, इसलिए यह Vlan टैग को हटाए बिना इसे वैसे ही भेजता है।
लिनक्स अलग-अलग पैकेजों के टुकड़े लेता है और उन्हें एक बड़े पैकेज में मिला देता है।
इसके बाद, पैकेट Vlan इंटरफ़ेस पर पहुँचता है, जहाँ से पहली परत हटा दी जाती है - Vlan एनकैप्सुलेशन।
लिनक्स फिर इसे टनल इंटरफ़ेस पर भेजता है, जहां से एक और परत हटा दी जाती है - टनल एनकैप्सुलेशन।

कठिनाई यह है कि इन सभी को tcpdump के पैरामीटर के रूप में पास किया जाए।
आइए अंत से शुरू करें: क्या क्लाइंट से वीएलएएन और टनल एनकैप्सुलेशन हटाए गए साफ (अनावश्यक हेडर के बिना) आईपी पैकेट हैं?

tcpdump host <ip клиента>

नहीं, सर्वर पर ऐसे कोई पैकेज नहीं थे। तो समस्या तो पहले से ही रही होगी. क्या ऐसे कोई पैकेट हैं जिनमें केवल व्लान एनकैप्सुलेशन हटा दिया गया है?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx हेक्स प्रारूप में क्लाइंट आईपी पता है।
32:4 - उस फ़ील्ड का पता और लंबाई जिसमें टनल पैकेट में एससीआर आईपी लिखा है।

फ़ील्ड पते को बलपूर्वक चुनना पड़ा, क्योंकि इंटरनेट पर वे 40, 44, 50, 54 के बारे में लिखते हैं, लेकिन वहां कोई आईपी पता नहीं था। आप हेक्स में पैकेटों में से एक (tcpdump में -xx या -XX पैरामीटर) को भी देख सकते हैं और अपने ज्ञात आईपी पते की गणना कर सकते हैं।

क्या व्लान और टनल इनकैप्सुलेशन को हटाए बिना पैकेट के टुकड़े हैं?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
यह जादू हमें अंतिम सहित सभी टुकड़े दिखाएगा। संभवतः, उसी चीज़ को आईपी द्वारा फ़िल्टर किया जा सकता है, लेकिन मैंने कोशिश नहीं की, क्योंकि ऐसे बहुत सारे पैकेट नहीं हैं, और जिनकी मुझे ज़रूरत थी वे सामान्य प्रवाह में आसानी से मिल गए। वे यहाँ हैं:

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 [email protected]. 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.....jEx 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) एक तस्वीर के साथ (एक्सिफ़ शब्द पहले पैकेज में दिखाई देता है)। इस तथ्य के कारण कि इस स्तर पर पैकेज हैं, लेकिन डंप में मर्ज किए गए रूप में नहीं, समस्या स्पष्ट रूप से असेंबली के साथ है। अंततः इसका दस्तावेजी प्रमाण मौजूद है!

पैकेट डिकोडर ने ऐसी कोई समस्या नहीं बताई जो निर्माण को रोक सके। इसे यहां आज़माया: hpd.gasmi.net. सबसे पहले, जब आप वहां कुछ भरने की कोशिश करते हैं, तो डिकोडर को पैकेट प्रारूप पसंद नहीं आता है। यह पता चला कि Srcmac और Ethertype (खंड जानकारी से संबंधित नहीं) के बीच कुछ अतिरिक्त दो ऑक्टेट थे। इन्हें हटाने के बाद डिकोडर ने काम करना शुरू कर दिया. हालाँकि, इसमें कोई समस्या नहीं दिखी।
कोई कुछ भी कहे, उन Sysctl के अलावा और कुछ नहीं मिला। पैमाने को समझने और आगे की कार्रवाइयों पर निर्णय लेने के लिए समस्या सर्वर की पहचान करने का एक तरीका ढूंढना बाकी रह गया था। आवश्यक काउंटर काफी जल्दी मिल गया:

netstat -s | grep "packet reassembles failed”

यह OID=1.3.6.1.2.1.4.31.1.1.16.1 के अंतर्गत snmpd में भी है (ipSystemStatsReasmFairs).

"आईपी री-असेंबली एल्गोरिदम द्वारा पता लगाई गई विफलताओं की संख्या (किसी भी कारण से: समय समाप्त, त्रुटियां, आदि)।"

सर्वरों के जिस समूह पर समस्या का अध्ययन किया गया, उनमें से दो पर यह काउंटर तेजी से बढ़ा, दो पर यह धीरे-धीरे बढ़ा, और दो पर यह बिल्कुल भी नहीं बढ़ा। इस काउंटर की गतिशीलता की तुलना जावा सर्वर पर HTTP त्रुटियों की गतिशीलता से करने पर एक सहसंबंध का पता चला। यानी मीटर पर नजर रखी जा सकेगी.

समस्याओं का एक विश्वसनीय संकेतक होना बहुत महत्वपूर्ण है ताकि आप सटीक रूप से यह निर्धारित कर सकें कि Sysctl को वापस लाने से मदद मिलती है या नहीं, क्योंकि पिछली कहानी से हम जानते हैं कि इसे एप्लिकेशन से तुरंत नहीं समझा जा सकता है। यह संकेतक हमें उपयोगकर्ताओं द्वारा खोजे जाने से पहले उत्पादन में सभी समस्या क्षेत्रों की पहचान करने की अनुमति देगा।
Sysctl को वापस रोल करने के बाद, मॉनिटरिंग त्रुटियाँ बंद हो गईं, इस प्रकार समस्याओं का कारण सिद्ध हो गया, साथ ही यह तथ्य भी सिद्ध हो गया कि रोलबैक से मदद मिलती है।

हमने अन्य सर्वरों पर विखंडन सेटिंग्स को वापस ले लिया, जहां नई निगरानी चलन में आई, और कहीं न कहीं हमने पहले डिफ़ॉल्ट की तुलना में टुकड़ों के लिए और भी अधिक मेमोरी आवंटित की (यह यूडीपी आंकड़े थे, जिसका आंशिक नुकसान सामान्य पृष्ठभूमि के खिलाफ ध्यान देने योग्य नहीं था) .

सबसे महत्वपूर्ण प्रश्न

हमारे L3 बैलेंसर पर पैकेट खंडित क्यों होते हैं? उपयोगकर्ताओं से बैलेंसर्स तक पहुंचने वाले अधिकांश पैकेट SYN और ACK हैं। इन पैकेजों का आकार छोटा है. लेकिन चूंकि ऐसे पैकेटों का हिस्सा बहुत बड़ा है, इसलिए उनकी पृष्ठभूमि के खिलाफ हमने बड़े पैकेटों की उपस्थिति पर ध्यान नहीं दिया जो टुकड़े-टुकड़े होने लगे थे।

इसका कारण टूटी हुई कॉन्फ़िगरेशन स्क्रिप्ट थी advmss Vlan इंटरफ़ेस वाले सर्वर पर (उस समय उत्पादन में टैग किए गए ट्रैफ़िक वाले बहुत कम सर्वर थे)। Advmss हमें क्लाइंट को यह जानकारी देने की अनुमति देता है कि हमारी दिशा में पैकेट आकार में छोटे होने चाहिए ताकि उनमें टनल हेडर जोड़ने के बाद उन्हें खंडित न करना पड़े।

Sysctl रोलबैक से मदद क्यों नहीं मिली, लेकिन रीबूट से मदद मिली? Sysctl को वापस लाने से विलय पैकेजों के लिए उपलब्ध मेमोरी की मात्रा बदल गई। उसी समय, जाहिरा तौर पर टुकड़ों के लिए मेमोरी अतिप्रवाह के तथ्य के कारण कनेक्शन धीमा हो गया, जिसके कारण टुकड़े कतार में लंबे समय तक विलंबित रहे। अर्थात् यह प्रक्रिया चक्रों में चली।
रिबूट ने मेमोरी साफ़ कर दी और सब कुछ व्यवस्थित हो गया।

क्या वर्कअराउंड के बिना ऐसा करना संभव था? हां, लेकिन हमले की स्थिति में उपयोगकर्ताओं को सेवा से वंचित कर दिए जाने का उच्च जोखिम है। बेशक, वर्कअराउंड के उपयोग के परिणामस्वरूप उपयोगकर्ताओं के लिए सेवाओं में से एक की मंदी सहित विभिन्न समस्याएं पैदा हुईं, लेकिन फिर भी हमारा मानना है कि कार्रवाई उचित थी।

एंड्री टिमोफीव को बहुत धन्यवाद (atimofeyev) जांच के संचालन में सहायता के लिए, साथ ही एलेक्सी क्रेनेव (डिवाइसएक्स) - सर्वर पर सेंटोस और कर्नेल को अपडेट करने के टाइटैनिक कार्य के लिए। इस मामले में एक प्रक्रिया को कई बार शुरू से शुरू करना पड़ा, यही कारण है कि यह कई महीनों तक खिंच गई।

स्रोत: www.habr.com

उन कमजोरियों से सावधान रहें जो काम में रुकावट लाती हैं। भाग 1: फ्रैगमेंटस्मैक/सेगमेंटस्मैक