گوگل ڪلائوڊ ٽيڪنيڪل سپورٽ مان غائب DNS پيڪٽس بابت هڪ ڪهاڻي

گوگل بلاگ ايڊيٽر کان: ڇا توهان ڪڏهن حيران ڪيو آهي ته گوگل ڪلائوڊ ٽيڪنيڪل حل (TSE) انجنيئر توهان جي مدد جي درخواستن کي ڪيئن سنڀاليندا آهن؟ TSE ٽيڪنيڪل سپورٽ انجنيئرز مسئلن جي صارف جي رپورٽ ڪيل ذريعن کي سڃاڻڻ ۽ درست ڪرڻ جا ذميوار آهن. انهن مان ڪجهه مسئلا بلڪل سادو آهن، پر ڪڏهن ڪڏهن توهان وٽ هڪ ٽڪيٽ اچي ٿي جيڪا هڪ ڀيرو ڪيترن ئي انجنيئرن جي توجه جي ضرورت آهي. هن آرٽيڪل ۾، TSE ملازمن مان هڪ اسان کي پنهنجي تازي مشق مان هڪ تمام مشڪل مسئلي بابت ٻڌائيندو. غائب DNS پيڪٽس جي صورت. هن ڪهاڻي ۾، ​​اسان ڏسنداسين ته ڪيئن انجنيئر صورتحال کي حل ڪرڻ ۾ مدد ڪئي، ۽ غلطي کي درست ڪرڻ دوران انهن ڪهڙيون شيون سکيون. اسان کي اميد آهي ته هي ڪهاڻي نه صرف توهان کي هڪ گہرے بيٺا بگ جي باري ۾ تعليم ڏئي ٿي، پر توهان کي انهن عملن جي باري ۾ بصيرت پڻ ڏئي ٿي جيڪي گوگل ڪلائوڊ سان سپورٽ ٽڪيٽ فائل ڪرڻ ۾ ويندا آهن.

مسئلا حل ڪرڻ هڪ سائنس ۽ هڪ فن آهي. اهو سڀ ڪجهه سسٽم جي غير معياري رويي جي سبب بابت هڪ مفروضي جي تعمير سان شروع ٿئي ٿو، جنهن کان پوء ان کي طاقت لاء آزمائشي آهي. تنهن هوندي، ان کان اڳ جو اسين هڪ مفروضو ٺاهي سگهون، اسان کي واضح طور تي وضاحت ڪرڻ گهرجي ۽ واضح طور تي مسئلي کي ترتيب ڏيو. جيڪڏهن سوال تمام مبهم آواز آهي، ته پوء توهان کي هر شي کي احتياط سان تجزيو ڪرڻو پوندو؛ اهو مسئلو حل ڪرڻ جو "فن" آهي.

گوگل ڪلائوڊ جي تحت، اهڙا عمل تيزيءَ سان وڌيڪ پيچيده ٿي ويندا آهن، جيئن گوگل ڪلائوڊ پنهنجي استعمال ڪندڙن جي رازداري جي ضمانت ڏيڻ جي ڀرپور ڪوشش ڪري ٿو. انهي جي ڪري، TSE انجنيئرن کي توهان جي سسٽم کي ايڊٽ ڪرڻ جي رسائي نه آهي، ۽ نه ئي انهن جي ترتيبن کي ڏسڻ جي صلاحيت جيتري وسيع طور تي صارف ڪندا آهن. تنهن ڪري، اسان جي ڪنهن به مفروضي کي جانچڻ لاء، اسان (انجنيئرز) جلدي سسٽم کي تبديل نٿا ڪري سگهون.

ڪجهه استعمال ڪندڙ سمجهن ٿا ته اسان ڪار جي سروس ۾ ميڪنڪس وانگر هر شيءِ کي درست ڪنداسين، ۽ اسان کي صرف هڪ ورچوئل مشين جي آئي ڊي موڪلينداسين، جڏهن ته حقيقت ۾ اهو عمل گفتگو واري شڪل ۾ ٿئي ٿو: معلومات گڏ ڪرڻ، ٺهڻ ۽ تصديق ڪرڻ (يا رد ڪرڻ) فرضن، ۽، آخر ۾، فيصلو مسئلا ڪلائنٽ سان رابطي تي ٻڌل آهن.

سوال ۾ مسئلو

اڄ اسان وٽ سٺي پڄاڻيءَ سان هڪ ڪهاڻي آهي. تجويز ڪيل ڪيس جي ڪامياب حل جي سببن مان هڪ مسئلو جو هڪ تمام تفصيلي ۽ صحيح بيان آهي. هيٺ توهان پهرين ٽڪيٽ جي ڪاپي ڏسي سگهو ٿا (خفيه معلومات لڪائڻ لاءِ ايڊٽ ڪيو ويو):

هي پيغام اسان لاءِ ڪافي مفيد معلومات تي مشتمل آهي:

• مخصوص VM بيان ڪيل
• مسئلو پاڻ ظاهر ڪيو ويو آهي - DNS ڪم نٿو ڪري
• اهو ظاهر ڪيو ويو آهي جتي مسئلو پاڻ کي ظاهر ڪري ٿو - VM ۽ ڪنٽينر
• صارف جيڪي قدم کنيا آھن تن کي مسئلي جي سڃاڻپ ڪرڻ لاء اشارو ڪيو ويو آھي.

درخواست "P1: Critical Impact - Service Unusable in Production" جي طور تي رجسٽرڊ ڪئي وئي، جنهن جو مطلب آهي صورتحال جي مسلسل نگراني 24/7 مطابق "Follow the Sun" اسڪيم (توهان وڌيڪ پڙهي سگهو ٿا. صارف جي درخواستن جي ترجيحات)، ان جي منتقلي سان هڪ ٽيڪنيڪل سپورٽ ٽيم کان ٻئي ڏانهن هر ٽائم زون شفٽ سان. حقيقت ۾، جڏهن مسئلو زيورخ ۾ اسان جي ٽيم تائين پهتو، اهو اڳ ۾ ئي دنيا جي چوڌاري ڦري چڪو هو. هن وقت تائين، صارف گھٽتائي جي قدمن کي ورتو هو، پر پيداوار ۾ صورتحال جي ورهاڱي کان ڊپ هو، ڇاڪاڻ ته بنيادي سبب اڃا تائين دريافت نه ڪيو ويو هو.

جڏهن ٽڪيٽ زيورخ پهچي وئي، اسان وٽ اڳ ۾ ئي هيٺ ڏنل معلومات هئي:

• مواد /etc/hosts
• مواد /etc/resolv.conf
• ٿڪل iptables-save
• ٽيم پاران گڏ ڪيل ngrep pcap فائل

هن ڊيٽا سان، اسان "تحقيق" شروع ڪرڻ لاء تيار هئاسين ۽ مسئلو حل ڪرڻ وارو مرحلو.

اسان جا پهريون قدم

سڀ کان پهريان، اسان ميٽا ڊيٽا سرور جي لاگز ۽ اسٽيٽس کي چيڪ ڪيو ۽ پڪ ڪيو ته اهو صحيح ڪم ڪري رهيو هو. ميٽا ڊيٽا سرور جواب ڏئي ٿو IP پتي 169.254.169.254 ۽، ٻين شين جي وچ ۾، ڊومين نالن کي سنڀالڻ جو ذميوار آهي. اسان پڻ ٻه ڀيرا چيڪ ڪيو ته فائر وال صحيح طور تي VM سان ڪم ڪري ٿو ۽ پيڪيٽس کي بلاڪ نٿو ڪري.

اهو ڪجهه قسم جو عجيب مسئلو هو: nmap چيڪ UDP پيڪٽس جي نقصان بابت اسان جي بنيادي مفروضي کي رد ڪري ڇڏيو، تنهنڪري اسان ذهني طور تي ڪيترن ئي وڌيڪ اختيارن ۽ طريقن سان گڏ آيا آهيون انهن کي جانچڻ لاءِ:

• ڇا پيڪيٽ چونڊيل طور تي ڇڏيا ويا آهن؟ => چيڪ ڪريو iptables ضابطا
• ڇا اهو تمام ننڍڙو ناهي؟ ايم يو يو؟ => ٻاھر چيڪ ڪريو ip a show
• ڇا مسئلو صرف UDP پيڪٽس يا TCP کي متاثر ڪري ٿو؟ => ڀڄڻ dig +tcp
• ڇا ڊيگ ٺاهيل پيڪٽ واپس ڪيا ويا آهن؟ => ڀڄڻ tcpdump
• ڇا libdns صحيح ڪم ڪري رهيو آهي؟ => ڀڄڻ strace ٻنهي طرفن ۾ پيڪيٽ جي منتقلي کي جانچڻ لاء

هتي اسان فيصلو ڪريون ٿا صارف کي ڪال ڪرڻ لاءِ مسئلا حل ڪرڻ لاءِ لائيو.

ڪال دوران اسان ڪيترن ئي شين کي جانچڻ جي قابل آهيون:

• ڪيترن ئي چيڪن کان پوءِ اسان iptables ضابطن کي سببن جي فهرست مان خارج ڪريون ٿا
• اسان چيڪ ڪريون ٿا نيٽ ورڪ انٽرفيس ۽ روٽنگ ٽيبل، ۽ ٻه ڀيرا چيڪ ڪريو ته MTU صحيح آهي
• اسان اهو دريافت ڪيو dig +tcp google.com (TCP) ڪم ڪري ٿو جيئن ان کي گهرجي، پر dig google.com (UDP) ڪم نٿو ڪري
• ڀڄي وڃڻ tcpdump اهو اڃا ڪم ڪري رهيو آهي dig، اسان کي معلوم ٿئي ٿو ته يو ڊي پي پيڪٽس واپس ٿي رهيا آهن
• اسان ڊوڙون ٿا strace dig google.com ۽ اسان ڏسون ٿا ته ڪھڙيءَ ريت صحيح ڪال ڪري ٿي sendmsg() и recvms()، جڏهن ته ٻيو هڪ وقت ختم ٿيڻ کان روڪيو ويو آهي

بدقسمتي سان، شفٽ جي پڄاڻي اچي ٿي ۽ اسان کي ايندڙ وقت واري علائقي ڏانهن مسئلو وڌائڻ تي مجبور ڪيو وڃي. درخواست، جيتوڻيڪ، اسان جي ٽيم ۾ دلچسپي پيدا ڪئي، ۽ هڪ ساٿي مشورو ڏئي ٿو شروعاتي DNS پيڪيج استعمال ڪندي اسڪراپي پٿون ماڊل.

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

هي ٽڪرو هڪ DNS پيڪٽ ٺاهي ٿو ۽ ميٽا ڊيٽا سرور ڏانهن درخواست موڪلي ٿو.

صارف ڪوڊ هلائي ٿو، DNS جواب واپس آيو آهي، ۽ ايپليڪيشن ان کي وصول ڪري ٿي، تصديق ڪري ٿو ته نيٽ ورڪ سطح تي ڪو مسئلو ناهي.

هڪ ٻئي ”دنيا جي سفر“ کان پوءِ، درخواست اسان جي ٽيم ڏانهن واپس اچي ٿي، ۽ مان ان کي مڪمل طور تي پاڻ ڏانهن منتقل ڪريان ٿو، اهو سوچي ته اهو صارف لاءِ وڌيڪ آسان ٿيندو جيڪڏهن درخواست هڪ هنڌ کان ٻئي هنڌ گردش ڪرڻ بند ڪري.

ساڳئي وقت ۾، صارف مهربان طور تي سسٽم جي تصوير جو هڪ سنيپ شاٽ مهيا ڪرڻ تي راضي آهي. اها تمام سٺي خبر آهي: سسٽم کي جانچڻ جي صلاحيت پاڻ کي وڌيڪ تيزيءَ سان حل ڪري ٿي، ڇاڪاڻ ته مون کي هاڻي صارف کان حڪم هلائڻ لاءِ پڇڻ جي ضرورت ناهي، مون کي نتيجا موڪليو ۽ انهن جو تجزيو ڪيو، مان سڀ ڪجهه پاڻ ڪري سگهان ٿو!

منهنجا ساٿي مون کي ٿورو حسد ڪرڻ شروع ڪري رهيا آهن. لنچ تي اسان تبديليءَ تي بحث ڪندا آهيون، پر ڪنهن کي به خبر ناهي ته ڇا ٿي رهيو آهي. خوشقسمتيء سان، صارف پاڻ اڳ ۾ ئي نتيجن کي گھٽائڻ لاء اپاء وٺي چڪو آهي ۽ جلدي ۾ ناهي، تنهنڪري اسان وٽ وقت آهي مسئلو کي ختم ڪرڻ لاء. ۽ جيئن ته اسان وٽ هڪ تصوير آهي، اسان ڪنهن به ٽيسٽ کي هلائي سگهون ٿا جيڪو اسان جي دلچسپي رکي ٿو. زبردست!

هڪ قدم پوئتي هٽڻ

سسٽم انجنيئر جي پوزيشن لاء سڀ کان وڌيڪ مشهور انٽرويو سوالن مان هڪ آهي: "جڏهن توهان پنگ ڪندا آهيو ته ڇا ٿيندو www.google.com؟ سوال وڏو آهي، ڇو ته اميدوار کي هر شي کي بيان ڪرڻ جي ضرورت آهي شيل کان صارف جي جاء تي، سسٽم ڪنييل ۽ پوء نيٽ ورڪ ڏانهن. مان مسڪرائي رهيو آهيان: ڪڏهن ڪڏهن انٽرويو سوال حقيقي زندگي ۾ مفيد ثابت ٿيندا آهن ...

مون هن HR سوال کي موجوده مسئلي تي لاڳو ڪرڻ جو فيصلو ڪيو. عام طور تي ڳالهائڻ، جڏهن توهان DNS جو نالو طئي ڪرڻ جي ڪوشش ڪندا، هيٺيان ٿئي ٿو:

1. ايپليڪيشن هڪ سسٽم لائبريري کي سڏيندو آهي جهڙوڪ libdns
2. libdns سسٽم جي ترتيب جي جانچ ڪري ٿو جنهن سان DNS سرور سان رابطو ڪرڻ گهرجي (ڊاگرام ۾ هي آهي 169.254.169.254، ميٽا ڊيٽا سرور)
3. libdns يو ڊي پي ساکٽ (SOKET_DGRAM) ٺاهڻ لاءِ سسٽم ڪال استعمال ڪري ٿو ۽ ٻنهي طرفن ۾ DNS سوال سان UDP پيڪٽ موڪلي ٿو
4. sysctl انٽرفيس ذريعي توهان ڪريل سطح تي UDP اسٽيڪ ترتيب ڏئي سگهو ٿا
5. ڪرنل نيٽ ورڪ انٽرفيس ذريعي نيٽ ورڪ تي پيڪيٽ منتقل ڪرڻ لاءِ هارڊويئر سان رابطو ڪري ٿو
6. هائپرائزر ان سان رابطي تي پيڪٽ کي ميٽا ڊيٽا سرور ڏانهن پڪڙي ٿو ۽ منتقل ڪري ٿو
7. ميٽاداٽ سرور، ان جي جادوءَ سان، ڊي اين ايس جو نالو طئي ڪري ٿو ۽ ساڳئي طريقي سان جواب ڏئي ٿو

اچو ته مان توهان کي ياد ڏياريان ته اسان اڳ ۾ ئي ڪهڙي مفروضن تي غور ڪيو آهي:

مفروضو: ٽوڙيل لائبريريون

• ٽيسٽ 1: سسٽم ۾ اسٽريس رن، چيڪ ڪريو ته ڊگ صحيح سسٽم ڪالز کي سڏي ٿو
• نتيجو: درست سسٽم کي سڏيندا آهن
• ٽيسٽ 2: srapy استعمال ڪندي چيڪ ڪرڻ لاءِ ته ڇا اسان سسٽم لائبريرين کي پاس ڪري نالا مقرر ڪري سگھون ٿا
• نتيجو: اسان ڪري سگهون ٿا
• ٽيسٽ 3: rpm –V کي libdns پيڪيج ۽ md5sum لائبريري فائلن تي هلايو
• نتيجو: لائبريري ڪوڊ مڪمل طور تي ڪم ڪندڙ آپريٽنگ سسٽم ۾ ڪوڊ سان هڪجهڙائي آهي
• ٽيسٽ 4: صارف جي روٽ سسٽم جي تصوير کي وي ايم تي نصب ڪريو بغير ھن رويي جي، ھلايو ڪروٽ، ڏسو ته ڇا DNS ڪم ڪري ٿو
• نتيجو: DNS صحيح ڪم ڪري ٿو

نتيجن تي ٻڌل ٽيسٽ: مسئلو لائبريرين ۾ نه آهي

مفروضو: DNS سيٽنگن ۾ هڪ غلطي آهي

• ٽيسٽ 1: چيڪ ڪريو tcpdump ۽ ڏسو ته ڇا ڊي اين ايس پيڪٽس موڪليا ويا آهن ۽ صحيح طور تي ڊيگ هلائڻ کان پوء واپس آيا آهن
• نتيجو: پيڪيٽ صحيح طور تي منتقل ڪيا ويا آهن
• ٽيسٽ 2: سرور تي ٻه ڀيرا چيڪ ڪريو /etc/nsswitch.conf и /etc/resolv.conf
• نتيجو: سڀ ڪجهه صحيح آهي

نتيجن تي ٻڌل ٽيسٽ: مسئلو DNS ترتيب سان نه آهي

مفروضو: بنيادي نقصان

• ٽيسٽ: نئين ڪرنل انسٽال ڪريو، دستخط چيڪ ڪريو، ٻيهر شروع ڪريو
• نتيجو: ساڳيو رويو

نتيجن تي ٻڌل ٽيسٽ: دٻي کي نقصان نه آهي

مفروضو: صارف نيٽ ورڪ جو غلط رويو (يا هائپر ويزر نيٽ ورڪ انٽرفيس)

• ٽيسٽ 1: پنھنجي فائر وال سيٽنگون چيڪ ڪريو
• نتيجو: فائر وال DNS پيڪٽس ٻنهي ميزبان ۽ GCP تي گذري ٿو
• ٽيسٽ 2: ٽريفڪ کي روڪيو ۽ ٽرانسميشن جي درستگي جي نگراني ڪريو ۽ DNS درخواستن جي واپسي
• نتيجو: tcpdump تصديق ڪري ٿو ته ميزبان کي واپسي پيڪٽس مليا آهن

نتيجن تي ٻڌل ٽيسٽ: مسئلو نيٽ ورڪ ۾ نه آهي

مفروضو: ميٽاداٽا سرور ڪم نه ڪري رهيو آهي

• ٽيسٽ 1: چيڪ ڪريو ميٽاڊيٽا سرور لاگز لاءِ بي ضابطگيون
• نتيجو: لاگن ۾ ڪو به تضاد نه آهي
• ٽيسٽ 2: ميٽا ڊيٽا سرور ذريعي بائي پاس ڪريو dig @8.8.8.8
• نتيجو: ميٽاداٽا سرور استعمال ڪرڻ کان سواءِ به ريزوليوشن ٽوڙيو ويو آهي

نتيجن تي ٻڌل ٽيسٽ: مسئلو ميٽا ڊيٽا سرور سان نه آهي

تري ليڪ: اسان سڀني سب سسٽم کي آزمايو سواءِ رن ٽائم سيٽنگون!

ڪرنل رن ٽائم سيٽنگن ۾ ڊائيونگ

ڪرنل جي عمل جي ماحول کي ترتيب ڏيڻ لاء، توھان استعمال ڪري سگھو ٿا ڪمان لائن آپشنز (گروب) يا sysctl انٽرفيس. مون اندر ڏٺو /etc/sysctl.conf ۽ صرف سوچيو، مون ڪيترن ئي ڪسٽم سيٽنگون دريافت ڪيون. محسوس ڪندي ڄڻ مون ڪنهن شيءِ تي قبضو ڪيو هجي، مون سڀ غير نيٽ ورڪ يا غير tcp سيٽنگون رد ڪري ڇڏيون، باقي جبل جي سيٽنگن سان net.core. پوءِ مان اتي ويس جتي ميزبان جي اجازتون VM ۾ هيون ۽ هڪ هڪ ڪري سيٽنگون لاڳو ڪرڻ شروع ڪيون، هڪ ٻئي پٺيان، ٽوڙيل VM سان، جيستائين مون کي مجرم نه مليو:

net.core.rmem_default = 2147483647

هتي اهو آهي، هڪ DNS ٽوڙڻ واري ترتيب! مون کي قتل جو هٿيار مليو. پر ائين ڇو ٿي رهيو آهي؟ مون کي اڃا به هڪ مقصد جي ضرورت آهي.

بنيادي DNS پيڪٽ بفر سائيز ذريعي ترتيب ڏنل آهي net.core.rmem_default. هڪ عام قيمت 200KiB جي چوڌاري ڪٿي آهي، پر جيڪڏهن توهان جو سرور تمام گهڻو DNS پيڪيٽس وصول ڪري ٿو، توهان شايد بفر جي سائيز کي وڌائڻ چاهيندا. جيڪڏهن بفر مڪمل آهي جڏهن هڪ نئون پيڪٽ اچي ٿو، مثال طور ڇو ته ايپليڪيشن ان کي تيزيءَ سان پروسيس نه ڪري رهي آهي، ته پوءِ توهان پيڪيٽ وڃائڻ شروع ڪندا. اسان جي ڪلائنٽ صحيح طور تي بفر جي سائيز کي وڌايو ڇاڪاڻ ته هو ڊيٽا جي نقصان کان ڊڄندو هو، ڇاڪاڻ ته هو ڊي اين ايس پيڪٽ ذريعي ميٽرڪ گڏ ڪرڻ لاء هڪ ايپليڪيشن استعمال ڪري رهيو هو. هن جي مقرر ڪيل قيمت وڌ ۾ وڌ ممڪن هئي: 231-1 (جيڪڏهن 231 تي سيٽ ڪيو ويو، ته ڪنييل واپس ڪندو "غلط دليل").

اوچتو مون محسوس ڪيو ته ڇو nmap ۽ scapy صحيح ڪم ڪيو: اهي خام ساکٽ استعمال ڪري رهيا هئا! خام ساکٽ باقاعده ساکٽ کان مختلف آهن: اهي iptables کان پاسو ڪن ٿا، ۽ اهي بفر نه آهن!

پر ڇو "بفر تمام وڏو" مسئلا پيدا ڪري ٿو؟ اهو واضح طور تي ڪم نٿو ڪري جيئن ارادو ڪيو ويو آهي.

هن نقطي تي آئون ڪيترن ئي ڪنلن ۽ ڪيترن ئي تقسيم تي مسئلو ٻيهر پيدا ڪري سگهان ٿو. مسئلو اڳ ۾ ئي 3.x ڪنيل تي ظاهر ٿيو ۽ هاڻي اهو پڻ 5.x ڪنيل تي ظاهر ٿيو.

درحقيقت، شروعاتي تي

sysctl -w net.core.rmem_default=$((2**31-1))

DNS ڪم ڪرڻ بند ڪيو.

مون هڪ سادي بائنري ڳولا الگورتھم ذريعي ڪم ڪندڙ قدر ڳولڻ شروع ڪيو ۽ ڏٺم ته سسٽم 2147481343 سان ڪم ڪيو، پر اهو نمبر مون لاء انگن جو هڪ بي معني سيٽ هو. مون ڪلائنٽ کي صلاح ڏني ته هن نمبر کي آزمائي، ۽ هن جواب ڏنو ته سسٽم google.com سان ڪم ڪيو، پر اڃا تائين ٻين ڊومينز سان غلطي ڏني، تنهنڪري مون پنهنجي تحقيق جاري رکي.

مون انسٽال ڪيو آهي ڊراپ واچ, هڪ اوزار جيڪو اڳ ۾ استعمال ڪيو وڃي ها: اهو ظاهر ڪري ٿو ته ڪتن ۾ هڪ پيٽ ڪٿي ختم ٿئي ٿو. ڏوڪريءَ جو فنڪشن هو udp_queue_rcv_skb. مون ڪرنل ذريعن کي ڊائون لوڊ ڪيو ۽ ڪجھ شامل ڪيو ڪم ڪار printk ٽريڪ ڪرڻ لاءِ ته پيڪٽ ڪٿي ختم ٿئي ٿو. مون کي جلدي صحيح حالت ملي if، ۽ صرف ڪجهه وقت لاءِ ان ڏانهن نهاريو ، ڇاڪاڻ ته اهو تڏهن هو ته آخرڪار سڀ ڪجهه هڪ مڪمل تصوير ۾ اچي ويو: 231-1، هڪ بي معنيٰ نمبر، هڪ غير ڪم ڪندڙ ڊومين... اهو ڪوڊ جو هڪ ٽڪرو هو. __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

نوٽ ڪريو:

• rmem int قسم جو آهي
• size u16 قسم جو آهي (غير دستخط ٿيل سولين-بٽ انٽ) ۽ پيڪٽ جي سائيز کي محفوظ ڪري ٿو
• sk->sk_rcybuf قسم int جو آھي ۽ بفر جي سائيز کي ذخيرو ڪري ٿو، جيڪو، تعريف سان، قيمت جي برابر آھي net.core.rmem_default

جڏهن sk_rcvbuf 231 تائين پهچندي، پيڪٽ جي سائيز جو خلاصو نتيجو ٿي سگھي ٿو integer overflow. ۽ جيئن ته اهو هڪ int آهي، ان جي قيمت منفي ٿي ويندي آهي، تنهنڪري شرط صحيح ٿي ويندي آهي جڏهن اهو غلط هجڻ گهرجي (توهان هن بابت وڌيڪ پڙهي سگهو ٿا. لنڪ).

غلطي کي معمولي طريقي سان درست ڪري سگھجي ٿو: ڪاسٽ ڪندي unsigned int. مون فيڪس لاڳو ڪيو ۽ سسٽم کي ٻيهر شروع ڪيو ۽ DNS ٻيهر ڪم ڪيو.

فتح جو ذائقو

مون پنهنجي نتيجن کي ڪلائنٽ ڏانهن موڪليو ۽ موڪليو ايل ايل ايم داڻا پيچ. مان خوش آهيان: پزل جو هر ٽڪرو گڏجي گڏ ٿئي ٿو، مان وضاحت ڪري سگهان ٿو ته اسان ڇو ڏٺو جيڪو اسان ڏٺو، ۽ سڀ کان اهم، اسان جي ٽيم ورڪ جي مهرباني، اسان مسئلي جو حل ڳولڻ جي قابل ٿي ويا آهيون!

اهو تسليم ڪرڻ جي قابل آهي ته ڪيس نادر ٿي ويو، ۽ خوش قسمتي سان اسان کي گهٽ ۾ گهٽ صارفين کان اهڙي پيچيده درخواستون مليون آهن.

جو ذريعو: www.habr.com