🥇 समाधान ल्याउने कमजोरीहरूबाट सावधान रहनुहोस्। भाग १: टुक्रा टुक्रा टुक्रा/खण्ड टुक्रा टुक्रा

कमजोरीहरूबाट सावधान रहनुहोस् जसले कार्य राउन्डहरू ल्याउँदछ। भाग १: FragmentSmack/SegmentSmack

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

हामी उत्पादनमा कर्नेल कसरी अपडेट गर्छौं

सामान्यतया, केहि जटिल छैन:

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

हामीसँग भएका कर्नेलका सबै शाखाहरूको लागि दोहोर्याउनुहोस्। हाल यो हो:

स्टक CentOS 7 3.10 - धेरै नियमित सर्भरहरूको लागि;
भेनिला 4.19 - हाम्रो लागि एक बादल बादल, किनकि हामीलाई BFQ, BBR, आदि चाहिन्छ।
Elrepo kernel-ml 5.2 - को लागि अत्यधिक लोड वितरकहरू, किनभने 4.19 अस्थिर व्यवहार गर्थे, तर उही सुविधाहरू आवश्यक छ।

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

यद्यपि, त्यहाँ अझै धेरै काम छ, र यसले धेरै हप्ता लिन सक्छ, र यदि नयाँ संस्करणमा कुनै समस्याहरू छन् भने, धेरै महिना सम्म। आक्रमणकारीहरूले यो कुरा राम्ररी बुझ्छन्, त्यसैले उनीहरूलाई योजना B चाहिन्छ।

FragmentSmack/SegmentSmack। समाधान

सौभाग्यवश, केही कमजोरीहरूको लागि यस्तो योजना B अवस्थित छ, र यसलाई Workaround भनिन्छ। प्रायः, यो कर्नेल/एप्लिकेशन सेटिङहरूमा परिवर्तन हो जसले सम्भावित प्रभावलाई कम गर्न वा कमजोरीहरूको शोषणलाई पूर्ण रूपमा हटाउन सक्छ।

FragmentSmack/SegmentSmack को मामला मा प्रस्ताव गरिएको थियो यो समाधान:

«तपाईंले net.ipv4.ipfrag_high_thresh र net.ipv3.ipfrag_low_thresh (र ipv4 net.ipv4.ipfrag_high_thresh र net.ipv6.ipfrag_low_thresh का लागि तिनीहरूका समकक्षहरू) मा 6MB र 6MB को पूर्वनिर्धारित मानहरू परिवर्तन गर्न सक्नुहुन्छ वा kB256 kB192 र तल्लो। परीक्षणहरूले हार्डवेयर, सेटिङहरू, र सर्तहरूमा निर्भर गर्दै आक्रमणको बेला CPU प्रयोगमा सानो देखि महत्त्वपूर्ण गिरावट देखाउँदछ। जे होस्, त्यहाँ ipfrag_high_thresh=262144 बाइट्सको कारणले केही कार्यसम्पादन प्रभाव हुन सक्छ, किनकि केवल दुई 64K टुक्राहरू एक पटकमा पुन: जोड्ने लाममा फिट हुन सक्छन्। उदाहरण को लागी, त्यहाँ एक जोखिम छ कि ठूला UDP प्याकेटहरु संग काम गर्ने अनुप्रयोगहरु तोडिनेछ"।

मापदण्डहरू आफैं कर्नेल कागजातमा निम्नानुसार वर्णन गरिएको छ:

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 मा खण्डित ट्राफिक छ, तर महत्त्वपूर्ण छैन। त्यहाँ कुनै संकेतहरू छैनन् - तपाईं Workaround रोल आउट गर्न सक्नुहुन्छ!

FragmentSmack/SegmentSmack। प्रथम सन्तान

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

होस्टमा Sysctl लागू गर्न किन पर्याप्त छैन? कन्टेनर यसको आफ्नै समर्पित नेटवर्क नेमस्पेसमा रहन्छ, त्यसैले कम्तिमा नेटवर्क Sysctl प्यारामिटरहरूको भाग कन्टेनरमा होस्ट भन्दा फरक हुन सक्छ।

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

प्यारामिटर मान मान्य छैन। तर किन? र किन यो कहिलेकाहीं मात्र मान्य छैन? यसले पत्ता लगायो कि डकरले Sysctl प्यारामिटरहरू लागू हुने क्रमको ग्यारेन्टी गर्दैन (भर्खरको परीक्षण गरिएको संस्करण 1.13.1 हो), त्यसैले कहिलेकाहीँ ipfrag_high_thresh 256K मा सेट गर्न प्रयास गरियो जब ipfrag_low_thresh अझै 3M थियो, अर्थात्, माथिल्लो सीमा कम थियो। तल्लो सीमा भन्दा, जसले त्रुटि निम्त्यायो।

त्यस समयमा, हामीले पहिले नै सुरु गरेपछि कन्टेनर पुन: कन्फिगर गर्नको लागि हाम्रो आफ्नै संयन्त्र प्रयोग गर्‍यौं। समूह फ्रीजर र कन्टेनरको नेमस्पेस मार्फत आदेशहरू कार्यान्वयन गर्दै ip netns), र हामीले यस भागमा Sysctl प्यारामिटरहरू पनि थप्यौं। समस्या हल भयो।

FragmentSmack/SegmentSmack। पहिलो रगत २

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

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

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

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

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

धारणा सरल थियो: यदि तिनीहरू ग्राफहरूमा उस्तै देखिन्छन् भने, तिनीहरूसँग एउटै कारण छ। यसबाहेक, यस प्रकारको मेमोरीसँग कुनै पनि समस्याहरू अत्यन्तै दुर्लभ छन्।

निश्चित समस्याको सार यो थियो कि हामीले QoS मा पूर्वनिर्धारित सेटिङहरूसँग 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 flows_plimit" भनेको एउटा जडानको लाइन सीमा नाघेको कारणले छोडिएको प्याकेट हो, र "ड्रप गरिएको 464545" यो शेड्युलरका सबै छोडिएका प्याकेटहरूको योगफल हो। लामको लम्बाइ १ हजार पुर्‍याएर कन्टेनर पुनः सुरु गरेपछि समस्या आउन छाड्यो । तपाईं पछाडि बसेर स्मूदी पिउन सक्नुहुन्छ।

FragmentSmack/SegmentSmack। अन्तिम रगत

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

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

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

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

समस्याहरूको लागि संवाद यस्तो थियो (Nginx प्रोक्सी पक्षमा निश्चित):

ग्राहक: फाइल डाउनलोड गर्ने बारे जानकारी प्राप्त गर्न अनुरोध।
जाभा सर्भर: प्रतिक्रिया।
ग्राहक: फाइल सहित POST।
जाभा सर्भर: त्रुटि।

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

यस अवस्थामा, नेटवर्क यस सर्भरमा Vlan-ट्याग गरिएको ट्राफिकको रूपमा आउँछ, जसले प्याकेटहरूमा आफ्नै फिल्डहरू पनि थप्छ:

र यो ट्राफिक पनि खण्डित हुन सक्छ (आगमन खण्डित ट्राफिकको त्यही सानो प्रतिशत जुन हामीले Workaround बाट जोखिमहरू मूल्याङ्कन गर्दा कुरा गर्यौं), जसले हेडरहरूको सामग्रीलाई पनि परिवर्तन गर्छ:

एक पटक फेरि: प्याकेटहरू Vlan ट्यागको साथ इनक्याप्सुलेटेड छन्, टनेलको साथ इनक्याप्सुलेटेड, टुक्रा टुक्रा। यो कसरी हुन्छ भनेर राम्रोसँग बुझ्नको लागि, ग्राहकबाट Nginx प्रोक्सीमा प्याकेट मार्ग ट्रेस गरौं।

प्याकेट L3 ब्यालेन्सरमा पुग्छ। डाटा सेन्टर भित्र सही राउटिङको लागि, प्याकेट सुरुङमा इन्क्याप्सुलेटेड हुन्छ र नेटवर्क कार्डमा पठाइन्छ।
प्याकेट + टनेल हेडरहरू MTU मा फिट नहुने भएकोले, प्याकेट टुक्राहरूमा काटिन्छ र नेटवर्कमा पठाइन्छ।
L3 ब्यालेन्सर पछिको स्विच, प्याकेट प्राप्त गर्दा, यसमा Vlan ट्याग थप्छ र यसलाई पठाउँछ।
Nginx प्रोक्सीको अगाडिको स्विचले (पोर्ट सेटिङहरूमा आधारित) देख्छ कि सर्भरले Vlan-encapsulated प्याकेटको अपेक्षा गरिरहेको छ, त्यसैले यसले Vlan ट्याग नहटाईकनै यसलाई पठाउँछ।
लिनक्सले व्यक्तिगत प्याकेजहरूको टुक्राहरू लिन्छ र तिनीहरूलाई एउटा ठूलो प्याकेजमा मर्ज गर्दछ।
अर्को, प्याकेट Vlan इन्टरफेसमा पुग्छ, जहाँ पहिलो लेयर हटाइएको छ - Vlan encapsulation।
लिनक्सले त्यसपछि यसलाई टनेल इन्टरफेसमा पठाउँछ, जहाँ अर्को तहबाट हटाइएको छ - टनेल इनक्याप्सुलेशन।

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

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

होइन, सर्भरमा त्यस्ता प्याकेजहरू थिएनन्। त्यसैले समस्या पहिले नै हुनुपर्छ। के त्यहाँ Vlan encapsulation मात्र हटाइएको कुनै प्याकेटहरू छन्?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx हेक्स ढाँचामा ग्राहक IP ठेगाना हो।
३२:४ — ठेगाना र फिल्डको लम्बाइ जसमा टनेल प्याकेटमा SCR IP लेखिएको छ।

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

के त्यहाँ Vlan र Tunnel encapsulation बिना प्याकेट टुक्राहरू हटाइएका छन्?

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 .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.....jEx 0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

१४:०२:५८.४७११०३ ००:de:ff:१a:९४:११ इथरटाइप IPv४ (०x०८००) मा, लम्बाइ ६२: (tos ०x०, ttl ६३, आईडी ५३६५२, अफसेट १४८०, झण्डा [कुनै पनि होइन], प्रोटो IPIP (४), लम्बाइ ४०)
    ११.११.११.११ > २२.२२.२२.२२: आईपी-प्रोटो-४
        ०x०००: ०००००० ०००१ ०००६ ००de fb0a ९४४१ ०००० ०८०० ..........ए....
        ०x००१०: ४५०० ००२८ d१९४ ००b९ ३f०४ faf६ २x७६ ३८५x ई..(....?....f८}
        ०x००२०: १x७६ ६५४५ xxxx १x११ २d२c ०c२१ ८०१६ ८e४३ .faE...D-,.!...C
        ०x००३०: x९७८ e९१d x९b० d६०८ ०००० ०००० ०००० ७c३१ .x..............|प्रश्न
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 .............

यी तस्बिरसहितको एउटा प्याकेज (एउटै ID 53652) को दुई टुक्राहरू हुन् (पहिलो प्याकेजमा Exif शब्द देखिन्छ)। यस स्तरमा प्याकेजहरू छन्, तर डम्पहरूमा मर्ज गरिएको फारममा होइन भन्ने तथ्यको कारणले, समस्या विधानसभामा स्पष्ट रूपमा छ। अन्ततः यसको दस्तावेजी प्रमाण छ!

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

netstat -s | grep "packet reassembles failed”

यो snmpd मा OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"IP पुन-विधान एल्गोरिदम द्वारा पत्ता लगाइएको विफलताहरूको संख्या (जुनसुकै कारणले: टाइम आउट, त्रुटिहरू, आदि)।"

सर्भरको समूह जसमा समस्या अध्ययन गरिएको थियो, दुईमा यो काउन्टर छिटो बढ्यो, दुईमा बिस्तारै, र दुईमा यो पटक्कै बढेको छैन। जाभा सर्भरमा HTTP त्रुटिहरूको गतिशीलतासँग यस काउन्टरको गतिशीलता तुलना गर्दा एक सम्बन्ध प्रकट भयो। अर्थात्, मिटर अनुगमन गर्न सकिन्छ।

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

हामीले अन्य सर्भरहरूमा खण्डीकरण सेटिङहरू फिर्ता गर्‍यौं, जहाँ नयाँ अनुगमन खेलमा आयो, र कतै हामीले टुक्राहरूका लागि पहिलेको पूर्वनिर्धारित भन्दा बढी मेमोरी आवंटित गर्‍यौं (यो UDP तथ्याङ्क थियो, जसको आंशिक क्षति सामान्य पृष्ठभूमिमा देख्न सकिएन)। ।

सबैभन्दा महत्त्वपूर्ण प्रश्नहरू

किन हाम्रो L3 ब्यालेन्सरमा प्याकेटहरू टुक्रा छन्? प्रयोगकर्ताहरूबाट ब्यालेन्सरहरूमा आउने अधिकांश प्याकेटहरू SYN र ACK हुन्। यी प्याकेजहरूको आकार सानो छ। तर त्यस्ता प्याकेटहरूको सेयर धेरै ठूलो भएकोले, तिनीहरूको पृष्ठभूमिमा हामीले ठूला प्याकेटहरूको उपस्थिति याद गरेनौं जुन टुक्रा हुन थाल्यो।

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

किन Sysctl रोलब्याकले मद्दत गरेन, तर रिबुट गर्यो? Sysctl रोल ब्याक गर्दा प्याकेजहरू मर्ज गर्नका लागि उपलब्ध मेमोरीको मात्रा परिवर्तन भयो। एकै समयमा, स्पष्ट रूपमा टुक्राहरूको लागि मेमोरी ओभरफ्लोको धेरै तथ्यले जडानहरूको ढिलो निम्त्यायो, जसले टुक्राहरूलाई लाममा लामो समयसम्म ढिलाइ गर्यो। अर्थात्, प्रक्रिया चक्रमा गयो।
रिबुटले मेमोरी खाली गर्‍यो र सबै कुरा अर्डरमा फर्कियो।

के यो workaround बिना गर्न सम्भव थियो? हो, तर आक्रमणको घटनामा प्रयोगकर्ताहरूलाई सेवा बिना छोड्ने उच्च जोखिम छ। अवश्य पनि, Workaround को प्रयोगले प्रयोगकर्ताहरूको लागि सेवाहरू मध्ये एकको ढिलो सहित विभिन्न समस्याहरू निम्त्यायो, तर तैपनि हामी विश्वास गर्छौं कि कार्यहरू जायज थिए।

Andrey Timofeev लाई धेरै धेरै धन्यवाद (atimofeyev) अनुसन्धान सञ्चालन गर्न सहयोगको लागि, साथै एलेक्सी क्रेनेभ (devicex) - सर्भरहरूमा Centos र कर्नेलहरू अद्यावधिक गर्ने टाइटानिक कार्यको लागि। यस मामला मा धेरै पटक सुरु देखि सुरु गर्न को लागी एक प्रक्रिया, जसको कारण यो धेरै महिना सम्म तानियो।

स्रोत: www.habr.com