هيلو سڀ! منهنجو نالو دمتري سامسونوف آهي، مان Odnoklassniki ۾ هڪ معروف سسٽم ايڊمنسٽريٽر طور ڪم ڪريان ٿو. اسان وٽ 7 هزار کان وڌيڪ فزيڪل سرور، 11 هزار ڪنٽينر اسان جي ڪلائوڊ ۾ ۽ 200 ايپليڪيشنون آهن، جيڪي مختلف ترتيبن ۾ 700 مختلف ڪلسٽرز ٺاهين ٿيون. سرورز جي وڏي اڪثريت هلندي آهي CentOS 7.
آگسٽ 14، 2018 تي، معلومات شايع ڪئي وئي FragmentSmack vulnerability بابت
() ۽ SegmentSmack (). اهي خطرات آهن نيٽ ورڪ جي حملي جي ویکٹر سان ۽ هڪ انتهائي اعلي اسڪور (7.5)، جيڪي خطري جي خدمت (DoS) کان انڪار ڪري رهيا آهن وسيلن جي ختم ٿيڻ (CPU) جي ڪري. FragmentSmack لاءِ هڪ ڪرنل فيڪس ان وقت تجويز نه ڪيو ويو هو؛ ان کان علاوه، اهو نقصان جي باري ۾ معلومات جي اشاعت کان گهڻو پوء ٻاهر آيو. SegmentSmack کي ختم ڪرڻ لاءِ، اها تجويز ڪئي وئي ته ڪنيل کي اپڊيٽ ڪيو وڃي. اپڊيٽ پيڪيج پاڻ کي ساڳئي ڏينهن تي جاري ڪيو ويو، باقي اهو سڀ ڪجهه ان کي انسٽال ڪرڻ هو.
نه، اسان ڪتن کي تازه ڪاري ڪرڻ جي خلاف نه آهيون! تنهن هوندي به، اتي nuances آهن ...
اسان پيداوار تي ڪتن کي ڪيئن تازه ڪاري ڪندا آهيون
عام طور تي، ڪجھ به پيچيده ناهي:
- ڊائون لوڊ پيڪيجز؛
- انهن کي ڪيترن ئي سرورن تي انسٽال ڪريو (بشمول اسان جي ڪلائوڊ کي ميزباني ڪندڙ سرور)؛
- پڪ ڪريو ته ڪجھ به ڀڄي نه آهي؛
- پڪ ڪريو ته سڀئي معياري ڪنييل سيٽنگون بغير غلطين جي لاڳو ٿين ٿيون؛
- ڪجهه ڏينهن انتظار ڪريو؛
- سرور جي ڪارڪردگي چيڪ ڪريو؛
- نون سرورن جي مقرري کي نئين ڪنييل ۾ تبديل ڪريو؛
- ڊيٽا سينٽر ذريعي سڀني سرورز کي اپڊيٽ ڪريو (هڪ وقت ۾ هڪ ڊيٽا سينٽر مسئلن جي صورت ۾ صارفين تي اثر کي گهٽائڻ لاء)؛
- سڀني سرورن کي ريبوٽ ڪريو.
اسان وٽ موجود ڪيلن جي سڀني شاخن لاء ورجائي. هن وقت اهو آهي:
- اسٽاڪ CentOS 7 3.10 - اڪثر باقاعده سرورز لاءِ؛
- وينلا 4.19 - اسان جي لاء ، ڇاڪاڻ ته اسان کي BFQ، BBR، وغيره جي ضرورت آهي.
- ايلريپو ڪرنل-ايم ايل 5.2 - لاءِ ، ڇاڪاڻ ته 4.19 استعمال ڪيو ويو غير مستحڪم، پر ساڳئي خاصيتون گهربل آهن.
جئين توهان اندازو ڪيو هوندو، هزارين سرورن کي ريبوٽ ڪرڻ تمام ڊگهو وقت وٺندو آهي. جيئن ته سڀئي نقصان سڀني سرورن لاءِ نازڪ نه هوندا آهن، اسان صرف انهن کي ريبوٽ ڪندا آهيون جيڪي سڌو سنئون انٽرنيٽ تان پهچن ٿيون. بادل ۾، لچڪ کي محدود نه ڪرڻ جي لاءِ، اسان ٻاهرئين طور تي پهچندڙ ڪنٽينرز کي انفرادي سرورن سان نئين ڪنيل سان نه ڳنڍيندا آهيون، پر سڀني ميزبانن کي بغير ڪنهن استثنا جي ريبوٽ ڪندا آهيون. خوشقسمتيء سان، اتي جو طريقو آسان آهي باقاعده سرورن جي ڀيٽ ۾. مثال طور، بي رياست ڪنٽينر صرف ريبوٽ دوران ٻئي سرور ڏانهن منتقل ڪري سگھن ٿا.
تنهن هوندي، اڃا به تمام گهڻو ڪم آهي، ۽ اهو ڪيترن ئي هفتا وٺي سگهي ٿو، ۽ جيڪڏهن نئين نسخي سان ڪو مسئلو آهي، ڪيترن ئي مهينن تائين. حملو ڪندڙ هن کي چڱي طرح سمجهندا آهن، تنهنڪري انهن کي هڪ پلان بي جي ضرورت آهي.
FragmentSmack/SegmentSmack. ڪم ڪار
خوشقسمتيءَ سان، ڪجهه ڪمزورين لاءِ اهڙو منصوبو بي موجود آهي، ۽ ان کي سڏيو ويندو آهي Workaround. گهڻو ڪري، هي ڪرنل / ايپليڪيشن سيٽنگن ۾ تبديلي آهي جيڪا ممڪن اثر کي گھٽائي سگھي ٿي يا مڪمل طور تي نقصان جي استحصال کي ختم ڪري سگھي ٿي.
FragmentSmack/SegmentSmack جي صورت ۾ هي حل:
«توھان net.ipv4.ipfrag_high_thresh ۽ net.ipv3.ipfrag_low_thresh ۾ 4MB ۽ 4MB جي ڊفالٽ قدرن کي تبديل ڪري سگھو ٿا (۽ انھن جي هم منصبن لاءِ ipv6 net.ipv6.ipfrag_high_thresh ۽ net.ipv6.ipfrag_low_thresh ۽ net.ipv256.ipfrag_low_thresh لاءِ) هيٺيون. ٽيسٽون هارڊويئر، سيٽنگون ۽ حالتن جي لحاظ کان حملي دوران سي پي يو جي استعمال ۾ ننڍڙن کان اهم ڦڙا ڏيکارين ٿيون. جڏهن ته، ipfrag_high_thresh=192 بائيٽ جي ڪري ڪجهه ڪارڪردگي اثر ٿي سگهي ٿي، ڇاڪاڻ ته صرف ٻه 262144K ٽڪرا هڪ وقت ۾ ٻيهر گڏ ڪرڻ واري قطار ۾ فٽ ٿي سگهن ٿا. مثال طور، هڪ خطرو آهي ته ايپليڪيشنون جيڪي ڪم ڪن ٿيون وڏي 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.
اسان وٽ پيداوار جي خدمتن تي وڏيون UDPs نه آهن. LAN تي ڪا به ٽڪرا ٽڪرا ٽرئفڪ نه آهي؛ WAN تي ٽڪرا ٽڪرا ٽرئفڪ آهي، پر اهم نه آهي. ڪي به نشانيون نه آهن - توهان ڪم ڪري سگهو ٿا!
FragmentSmack/SegmentSmack. پهريون رت
اسان جو پهريون مسئلو اهو هو ته ڪلائوڊ ڪنٽينر ڪڏهن ڪڏهن نيون سيٽنگون لاڳو ڪندا آهن صرف جزوي طور (صرف ipfrag_low_thresh)، ۽ ڪڏهن ڪڏهن انهن کي لاڳو نه ڪندا هئا - اهي صرف شروعات ۾ تباهه ٿي ويا. اهو مسئلو ٻيهر پيدا ڪرڻ ممڪن نه هو (سڀني سيٽنگون بغير ڪنهن مشڪلات جي دستي طور تي لاڳو ڪيون ويون آهن). سمجھڻ ڇو شروع ۾ ڪنٽينر حادثو پڻ ايترو آسان ناهي: ڪا به غلطي نه ملي. ھڪڙي شيء يقيني ھئي: سيٽنگون واپس ڪرڻ واري مسئلي کي حل ڪري ٿو ڪنٽينر حادثن سان.
ميزبان تي Sysctl لاڳو ڪرڻ ڪافي ڇو نه آهي؟ ڪنٽينر پنهنجي وقف ڪيل نيٽ ورڪ جي نالي واري جاءِ ۾ رهي ٿو، تنهنڪري گهٽ ۾ گهٽ ڪنٽينر ۾ ميزبان کان مختلف ٿي سگھي ٿو.
ڪنٽينر ۾ Sysctl سيٽنگون ڪيئن لاڳو ٿين ٿيون؟ جيئن ته اسان جا ڪنٽينر غير استحقاق وارا آهن، توهان ڪنٽينر ۾ وڃڻ سان ڪنهن به Sysctl سيٽنگ کي تبديل ڪرڻ جي قابل نه هوندا - توهان وٽ ڪافي حق نه آهن. ڪنٽينر هلائڻ لاءِ، اسان جو بادل ان وقت ڊڪر استعمال ڪندو هو (هاڻي ). نئين ڪنٽينر جا پيرا ميٽرز ڊاڪر کي 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.
پيٽرولر جو قدر صحيح ناهي. پر ڇو؟ ۽ اهو صرف ڪڏهن ڪڏهن صحيح ڇو نه آهي؟ اهو ظاهر ٿيو ته ڊڪر ان حڪم جي ضمانت نٿو ڏئي جنهن ۾ Sysctl پيٽرولر لاڳو ڪيا ويا آهن (تازو آزمائشي نسخو 1.13.1 آهي)، تنهن ڪري ڪڏهن ڪڏهن ipfrag_high_thresh کي 256K تي سيٽ ڪرڻ جي ڪوشش ڪئي وئي جڏهن ipfrag_low_thresh اڃا 3M هئي، يعني، مٿين حد گهٽ هئي. هيٺين حد کان، جنهن جي نتيجي ۾ غلطي.
ان وقت، اسان اڳ ۾ ئي اسان جو پنهنجو ميڪانيزم استعمال ڪيو آهي ڪنٽينر کي ٻيهر ترتيب ڏيڻ لاءِ شروع کان پوءِ (ڪنٽينر کي منجمد ڪرڻ کان پوءِ ۽ ڪنٽينر جي نالي واري جاءِ ۾ حڪمن تي عمل ڪرڻ )، ۽ اسان پڻ شامل ڪيو Sysctl parameters لکڻ جي ھن حصي ۾. مسئلو حل ٿي ويو.
FragmentSmack/SegmentSmack. پهريون رت 2
ان کان اڳ جو اسان وٽ بادل ۾ ڪم ڪار جي استعمال کي سمجهڻ جو وقت هجي، صارفين کان پهرين نادر شڪايتون اچڻ شروع ٿيون. ان وقت، پهرين سرورز تي ڪم ڪار جي استعمال جي شروعات کان وٺي ڪيترائي هفتا گذري چڪا هئا. ابتدائي تحقيق ڏيکاري ٿي ته شڪايتون انفرادي خدمتن جي خلاف مليون آهن، ۽ نه انهن خدمتن جي سڀني سرورن جي. مسئلو وري انتهائي غير يقيني بڻجي ويو آهي.
سڀ کان پهريان، اسان، يقينا، Sysctl سيٽنگون واپس آڻڻ جي ڪوشش ڪئي، پر ان جو ڪو به اثر نه ٿيو. سرور ۽ ايپليڪيشن سيٽنگن سان گڏ مختلف ترتيبن جي مدد نه ڪئي وئي. ريبوٽ مدد ڪئي. لينڪس کي ريبوٽ ڪرڻ غير فطري آهي جيئن پراڻي ڏينهن ۾ ونڊوز لاءِ عام هو. بهرحال، ان جي مدد ڪئي، ۽ اسان ان کي "ڪنيل گليچ" تائين پهچايو جڏهن Sysctl ۾ نئين سيٽنگون لاڳو ڪيون ويون آهن. ڪيڏي بيوقوف هئي...
ٽن هفتن کان پوء، مسئلو ٻيهر ورجائي ٿو. انهن سرورن جي تشڪيل بلڪل سادو هئي: نينگڪس پراکسي / بيلنسر موڊ ۾. گهڻو ٽرئفڪ نه. نئون تعارفي نوٽ: ڪلائنٽ تي 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" هن شيڊولر جي سڀني ڊاپ ٿيل پيڪٽس جو مجموعو آهي. قطار جي ڊيگهه 1 هزار تائين وڌائڻ ۽ ڪنٽينرز کي ٻيهر شروع ڪرڻ کانپوءِ مسئلو ٿيڻ بند ٿي ويو. توهان واپس ويٺي ۽ هڪ smoothie پيئڻ ڪري سگهو ٿا.
FragmentSmack/SegmentSmack. آخري رت
پهرين، ڪيترن ئي مهينن کان پوءِ ڪرنل ۾ ڪمزورين جي اعلان کان پوءِ، فريگمينٽ سميڪ لاءِ هڪ فڪس آخرڪار ظاهر ٿيو (مون کي توهان کي ياد ڏيارڻ ڏي ته آگسٽ ۾ اعلان سان گڏ، هڪ فيڪس صرف SegmentSmack لاءِ جاري ڪيو ويو هو)، جنهن اسان کي هڪ موقعو ڏنو ته ڪم ڪار کي ختم ڪرڻ جو، جنهن ڪري اسان کي تمام گهڻي تڪليف پهتي. ان دوران، اسان اڳ ۾ ئي ڪجهه سرورن کي نئين ڪنيل ڏانهن منتقل ڪرڻ جو انتظام ڪيو هو، ۽ هاڻي اسان کي شروع کان شروع ڪرڻو پوندو. اسان FragmentSmack فڪس جو انتظار ڪرڻ کانسواءِ ڪرنل کي اپڊيٽ ڇو ڪيو؟ حقيقت اها آهي ته انهن خطرن جي خلاف تحفظ جو عمل پاڻ ۾ CentOS کي اپڊيٽ ڪرڻ جي عمل سان ٺهڪندڙ (۽ ملائي ويو) (جيڪو صرف ڪرنل کي اپڊيٽ ڪرڻ کان به وڌيڪ وقت وٺندو آهي). اضافي طور تي، SegmentSmack هڪ وڌيڪ خطرناڪ نقصان آهي، ۽ ان لاء هڪ حل فوري طور تي ظاهر ٿيو، تنهن ڪري اهو ڪنهن به طرح احساس ڪيو. تنهن هوندي، اسان صرف CentOS تي ڪرنل کي اپڊيٽ نه ڪري سگهيا ڇاڪاڻ ته FragmentSmack نقصان، جيڪو CentOS 7.5 دوران ظاهر ٿيو، صرف نسخو 7.6 ۾ مقرر ڪيو ويو، تنهنڪري اسان کي 7.5 تائين اپڊيٽ کي روڪڻو پوندو ۽ 7.6 تائين اپڊيٽ سان ٻيهر شروع ڪرڻو پوندو. ۽ اهو پڻ ٿئي ٿو.
ٻيو، مسئلن بابت نادر صارف شڪايتون اسان ڏانهن واپس آيون آهن. هاڻي اسان پهريان ئي پڪ ڄاڻون ٿا ته اهي سڀئي لاڳاپيل آهن فائلن جي اپلوڊ ڪلائنٽ کان اسان جي ڪجهه سرورن تي. ان کان علاوه، مجموعي ڪاميٽي مان اپلوڊ جو تمام ننڍڙو تعداد انهن سرورز ذريعي ويا.
جيئن ته اسان مٿي ڄاڻايل ڪهاڻي کان ياد رکون ٿا، واپس رولنگ Sysctl مدد نه ڪئي. ريبوٽ مدد ڪئي، پر عارضي طور تي.
Sysctl جي حوالي سان شڪ کي دور نه ڪيو ويو، پر هن ڀيري جيتري معلومات گڏ ڪرڻ ضروري هو. ڪلائنٽ تي اپلوڊ جي مسئلي کي ٻيهر پيدا ڪرڻ جي صلاحيت جي وڏي کوٽ پڻ هئي ته جيئن وڌيڪ واضح طور تي مطالعو ڪيو وڃي ته ڇا ٿي رهيو آهي.
سڀني موجود انگن اکرن ۽ لاگن جو تجزيو اسان کي سمجھڻ جي ويجھو نه آندو آھي ته ڇا ٿي رھيو آھي. ڪنهن خاص ڪنيڪشن کي ”محسوس“ ڪرڻ لاءِ مسئلي کي ٻيهر پيدا ڪرڻ جي صلاحيت جي شديد کوٽ هئي. آخرڪار، ڊولپرز، ايپليڪيشن جو هڪ خاص نسخو استعمال ڪندي، وائي فائي ذريعي ڳنڍڻ دوران ٽيسٽ ڊوائيس تي مسئلن جي مستحڪم پيداوار حاصل ڪرڻ ۾ مدد ڪئي. اها تحقيق ۾ هڪ پيش رفت هئي. ڪلائنٽ Nginx سان ڳنڍيل آهي، جيڪو پس منظر ڏانهن پراکسي ڪيو ويو، جيڪو اسان جي جاوا ايپليڪيشن هئي.
مسئلن لاءِ ڳالهه ٻولهه هن طرح هئي (نينگڪس پراکسي پاسي تي مقرر ٿيل):
- ڪلائنٽ: فائل ڊائون لوڊ ڪرڻ بابت معلومات حاصل ڪرڻ جي درخواست.
- جاوا سرور: جواب.
- ڪلائنٽ: فائل سان پوسٽ ڪريو.
- جاوا سرور: غلطي.
ساڳئي وقت، جاوا سرور لاگ ڏانهن لکي ٿو ته ڪلائنٽ کان ڊيٽا جا 0 بائيٽ وصول ڪيا ويا، ۽ نينڪس پراکسي لکي ٿو ته درخواست 30 سيڪنڊن کان وڌيڪ ورتي (30 سيڪنڊ ڪلائنٽ ايپليڪيشن جو وقت ختم آهي). ڇو وقت ختم ۽ ڇو 0 بائيٽ؟ هڪ HTTP نقطه نظر کان، هر شي ڪم ڪري ٿو جيئن اهو گهرجي، پر فائل سان پوسٽ نيٽ ورڪ کان غائب ٿيڻ لڳي. ان کان علاوه، اهو ڪلائنٽ ۽ نينڪسڪس جي وچ ۾ غائب ٿي ويو آهي. اهو وقت آهي پاڻ کي هٿ ڪرڻ جو Tcpdump سان! پر پهرين توهان کي سمجهڻ جي ضرورت آهي نيٽ ورڪ جي ٺاھ جوڙ. Nginx پراکسي L3 بيلنس جي پويان آهي . سرنگنگ L3 بيلنس کان سرور تائين پيڪيٽس پهچائڻ لاءِ استعمال ڪيو ويندو آهي، جيڪو ان جي هيڊرن کي پيڪن ۾ شامل ڪري ٿو:
انهي صورت ۾، نيٽ ورڪ هن سرور تي Vlan-ٽيگ ٿيل ٽرئفڪ جي صورت ۾ اچي ٿو، جيڪو پڻ شامل ڪري ٿو پنهنجا پنهنجا فيلڊ پيڪٽس ۾:
۽ هي ٽريفڪ پڻ ٽڪرا ٿي سگهي ٿو (آڻندڙ ٽڪرا ٽڪرا ٽرئفڪ جو تمام ننڍڙو سيڪڙو جنهن جي باري ۾ اسان ڳالهايون ٿا جڏهن ڪم ڪار جي خطرن جو جائزو وٺون ٿا)، جيڪو پڻ هيڊر جي مواد کي تبديل ڪري ٿو:
هڪ ڀيرو ٻيهر: پيڪٽس هڪ Vlan ٽيگ سان ڍڪيل آهن، هڪ سرنگ سان ڍڪيل، ٽڪرا ٽڪرا. بهتر سمجهڻ لاءِ ته اهو ڪيئن ٿئي ٿو، اچو ته پيڪٽ جي رستي کي ڪلائنٽ کان نينڪس پراکسي ڏانهن ڇڪيون.
- پيڪٽ L3 بيلنس تائين پهچي ٿو. ڊيٽا سينٽر جي اندر صحيح رستي لاء، پيڪٽ هڪ سرنگ ۾ ڍڪيل آهي ۽ نيٽ ورڪ ڪارڊ ڏانهن موڪليو ويو آهي.
- جيئن ته پيڪٽ + سرنگ هيڊر MTU ۾ نه ٿا اچن، پيڪٽ کي ٽڪرن ۾ ڪٽيو ويو آهي ۽ نيٽ ورڪ ڏانهن موڪليو ويو آهي.
- L3 بيلنس کان پوءِ سوئچ، جڏهن هڪ پيڪٽ حاصل ڪري، ان تي هڪ Vlan ٽيگ شامل ڪري ٿو ۽ ان کي موڪلي ٿو.
- Nginx پراکسي جي سامهون سوئچ ڏسي ٿو (پورٽ سيٽنگن جي بنياد تي) ته سرور هڪ Vlan-encapsulated packet جي توقع ڪري رهيو آهي، تنهنڪري اهو ان کي موڪلي ٿو، بغير Vlan ٽيگ کي هٽائڻ کان سواء.
- لينڪس انفرادي پيڪيجز جا ٽڪرا وٺي ٿو ۽ انهن کي هڪ وڏي پئڪيج ۾ ملائي ٿو.
- اڳيون، پيڪٽ Vlan انٽرفيس تائين پهچندو آهي، جتي پهرين پرت ان مان هٽايو ويندو آهي - Vlan encapsulation.
- لينڪس ان کان پوء ان کي سرنگ انٽرفيس ڏانهن موڪلي ٿو، جتي هڪ ٻيو پرت ان مان هٽايو ويو آهي - Tunnel encapsulation.
مشڪل اهو آهي ته هي سڀ ڪجهه پاس ڪرڻ لاءِ پيٽرولر طور tcpdump.
اچو ته آخر کان شروع ڪريون: ڇا هتي صاف آهن (غير ضروري هيڊر کان سواءِ) ڪلائنٽ مان IP پيڪيٽ، ويلان ۽ سرنگ انڪپسوليشن سان هٽايو ويو آهي؟
tcpdump host <ip клиента>
نه، سرور تي اهڙا پيڪيجز نه هئا. تنهنڪري مسئلو اتي اڳ ۾ ئي هجڻ گهرجي. ڇا صرف Vlan encapsulation سان ڪي پيڪٽس ھٽايا ويا آھن؟
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx ڪلائنٽ IP پتو هيڪس فارميٽ ۾ آهي.
32:4 — فيلڊ جو پتو ۽ ڊگھائي جنهن ۾ SCR IP Tunnel packet ۾ لکيل آهي.
فيلڊ ايڊريس کي برٽ فورس سان چونڊڻو پوندو، ڇو ته انٽرنيٽ تي اهي 40، 44، 50، 54 بابت لکندا آهن، پر اتي ڪو IP پتو نه هو. توھان ھيڪس ۾ ھڪڙو پيڪيٽ پڻ ڏسي سگھو ٿا (tcpdump ۾ -xx يا -XX پيٽرول) ۽ حساب ڪريو IP پتو جيڪو توھان ڄاڻو ٿا.
ڇا Vlan ۽ Tunnel encapsulation کان سواءِ پيڪٽ جا ٽڪرا هٽايا ويا آهن؟
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 [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 ..............
هي هڪ پيڪيج جا ٻه ٽڪرا آهن (ساڳي ID 53652) هڪ تصوير سان (لفظ Exif پهرين پيڪيج ۾ نظر اچي ٿو). انهي حقيقت جي ڪري ته هن سطح تي پيڪيجز موجود آهن، پر ڊمپ ۾ ضم ٿيل فارم ۾ نه، مسئلو واضح طور تي اسيمبليء سان آهي. آخرڪار ان جو دستاويزي ثبوت موجود آهي!
پيڪٽ ڊيڪوڊر ڪو به مسئلو ظاهر نه ڪيو جيڪو تعمير کي روڪيندو. هتي ڪوشش ڪئي: . پهرين ۾، جڏهن توهان اتي ڪجهه سامان ڪرڻ جي ڪوشش ڪندا آهيو، ڊيڪوڊر پيڪٽ فارميٽ کي پسند نٿو ڪري. اهو ظاهر ٿيو ته Srcmac ۽ Ethertype جي وچ ۾ ڪجهه اضافي ٻه آڪٽيٽ هئا (جنهن جو تعلق ٽڪرن جي معلومات سان ناهي). انهن کي هٽائڻ کان پوء، ڊيڪوڊر ڪم ڪرڻ شروع ڪيو. بهرحال، اهو ڪو مسئلو نه ڏيکاريو.
جيڪو ڪجهه به چئجي، سو سواءِ انهن سِيسڪلن جي ٻيو ڪجهه به نه مليو. اهو سڀ ڪجهه رهيو هو ته مسئلي جي سرور کي سڃاڻڻ جو رستو ڳولڻ لاءِ پيماني کي سمجهڻ ۽ وڌيڪ ڪارناما تي فيصلو ڪرڻ لاءِ. گهربل ڪائونٽر ڪافي جلدي ملي ويو:
netstat -s | grep "packet reassembles failed”
اهو snmpd ۾ OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"IP ري-اسمبلي الگورٿم پاران معلوم ڪيل ناڪامين جو تعداد (ڪنهن به سبب لاءِ: وقت ختم، غلطيون، وغيره)."
سرورز جي گروپ جي وچ ۾، جنهن تي مسئلو اڀياس ڪيو ويو، هي ڪائونٽر ٻن تي تيز، ٻن تي سست، ۽ ٻن تي بلڪل نه وڌو. جاوا سرور تي ايڇ ٽي ٽي پي جي غلطين جي متحرڪ سان هن انسداد جي متحرڪ جي مقابلي ۾ هڪ باهمي تعلق ظاهر ڪيو. اهو آهي، ميٽر مانيٽر ٿي سگهي ٿو.
مسئلن جو هڪ قابل اعتماد اشارو هجڻ تمام ضروري آهي ته جيئن توهان صحيح طور تي اندازو لڳائي سگهو ته ڇا واپس رولنگ Sysctl مدد ڪري ٿي، ڇاڪاڻ ته پوئين ڪهاڻي مان اسان ڄاڻون ٿا ته اهو فوري طور تي ايپليڪيشن مان سمجهي نه ٿو سگهجي. هي اشارو اسان کي اجازت ڏيندو ته صارفين کي دريافت ڪرڻ کان اڳ پيداوار ۾ سڀني مسئلن جي علائقن کي سڃاڻڻ لاء.
Sysctl کي واپس ڪرڻ کان پوء، مانيٽرنگ غلطيون بند ٿي ويون، اهڙيء طرح مسئلن جو سبب ثابت ٿيو، انهي سان گڏ حقيقت اها آهي ته رول بيڪ مدد ڪري ٿي.
اسان ٻين سرورن تي فريگمينٽيشن سيٽنگون واپس ڪيون، جتي نئين مانيٽرنگ عمل ۾ آئي، ۽ ڪٿي ڪٿي اسان ٽڪڙن لاءِ اڃا به وڌيڪ ميموري مختص ڪئي جيڪا اڳي ڊفالٽ هئي (هي UDP شماريات هو، جنهن جو جزوي نقصان عام پس منظر جي خلاف قابل ذڪر نه هو) .
سڀ کان اهم سوال
اسان جي L3 بيلنس تي پيڪيٽس ڇو ورهايل آهن؟ اڪثر پيڪيٽ جيڪي صارفين کان بيلنسرز تائين پهچندا آهن SYN ۽ ACK آهن. انهن پيڪيجز جون سائيزون ننڍيون آهن. پر جيئن ته اهڙن پيڪن جو حصو تمام وڏو آهي، انهن جي پس منظر جي خلاف اسان انهن وڏن پيڪن جي موجودگي کي نوٽيس نه ڪيو جيڪي ٽڪرا ٿيڻ شروع ٿيا.
ان جو سبب هڪ ٽٽل ترتيب واري اسڪرپٽ هئي Vlan انٽرفيس سان سرورز تي (انهي وقت پيداوار ۾ ٽيگ ٿيل ٽرئفڪ سان تمام ٿورا سرور هئا). Advmss اسان کي ڪلائنٽ کي معلومات پهچائڻ جي اجازت ڏئي ٿو ته اسان جي هدايت ۾ پيڪيٽس سائيز ۾ ننڍا هجن ته جيئن سرنگ جي هيڊرز کي ڳنڍڻ کان پوء انهن کي ٽڪرا نه ٿيڻ گهرجي.
ڇو Sysctl rollback مدد نه ڪئي، پر ريبوٽ ڪيو؟ واپس رولنگ Sysctl ضم ڪرڻ واري پيڪيجز لاءِ موجود ميموري جي مقدار کي تبديل ڪيو. ساڳي ئي وقت، بظاهر ميموري اوور فلو جي بلڪل حقيقت ٽڪرن لاءِ ڪنيڪشن سست ٿيڻ جو سبب بڻيو، جنهن جي ڪري ٽڪرا قطار ۾ گهڻي دير تائين بيهي رهيا. اهو آهي، اهو عمل چڪر ۾ ويو.
ريبوٽ ميموري کي صاف ڪيو ۽ هر شيء کي ترتيب ڏيڻ لاء واپس آيو.
ڇا اهو ممڪن هو ته بغير ڪنهن ڪم ڪرڻ جي؟ ها، پر حملي جي صورت ۾ صارفين کي بغير سروس جي ڇڏڻ جو هڪ وڏو خطرو آهي. يقينن، ڪم ڪار جي استعمال جي نتيجي ۾ مختلف مسئلن جي نتيجي ۾، صارفين لاء خدمتن مان هڪ جي سستي سميت، پر ان جي باوجود اسان يقين رکون ٿا ته ڪارناما صحيح هئا.
ڪيتريون ئي مهربانيون Andrey Timofeev () تحقيق ڪرڻ ۾ مدد لاء، گڏوگڏ Alexey Krenev () - سرورز تي Centos ۽ kernels کي اپڊيٽ ڪرڻ جي ٽائيٽينڪ ڪم لاءِ. اهڙو عمل جيڪو ان معاملي ۾ شروع کان ئي ڪيترائي ڀيرا شروع ڪرڻو پيو، جنهن ڪري اهو ڪيترن ئي مهينن تائين جاري رهيو.
جو ذريعو: www.habr.com