د ګوګل کلاوډ تخنیکي ملاتړ څخه د ورک شوي DNS پاکټونو په اړه یوه کیسه

د ګوګل بلاګ مدیر څخه: ایا تاسو کله هم فکر کړی چې څنګه د ګوګل کلاوډ تخنیکي حلونه (TSE) انجینران ستاسو د ملاتړ غوښتنې اداره کوي؟ د TSE تخنیکي مالتړ انجینران د کاروونکو لخوا راپور شوي ستونزې د سرچینو پیژندلو او سمولو مسولیت لري. ځینې ​​​​دا ستونزې خورا ساده دي، مګر ځینې وختونه تاسو د ټکټ سره مخ شئ چې په یوځل کې د څو انجنیرانو پام ته اړتیا لري. پدې مقاله کې ، د TSE یو کارمند به موږ ته د هغه وروستي تمرین څخه د یوې خورا پیچلې ستونزې په اړه ووایی - د ورک شوي DNS پاکټونو قضیه. پدې کیسه کې، موږ به وګورو چې انجینرانو څنګه د وضعیت حل کولو توان درلود، او د تېروتنې د حل کولو په وخت کې دوی کوم نوي شیان زده کړل. موږ امید لرو چې دا کیسه نه یوازې تاسو ته د ژور ناست بګ په اړه روزنه درکوي ، بلکه تاسو ته د هغه پروسو په اړه بصیرت درکوي چې د ګوګل کلاوډ سره د ملاتړ ټیکټ ډکولو ته ځي.

د ستونزو حل کول یو ساینس او ​​یو هنر دی. دا ټول د سیسټم د غیر معیاري چلند د دلیل په اړه د فرضیې په جوړولو سره پیل کیږي، وروسته له دې چې دا د ځواک لپاره ازموینه کیږي. په هرصورت، مخکې له دې چې موږ فرضیه جوړه کړو، موږ باید په واضح ډول تعریف او په سمه توګه ستونزه جوړه کړو. که پوښتنه ډیره مبهم ښکاري، نو تاسو باید هرڅه په دقت سره تحلیل کړئ؛ دا د ستونزو د حل کولو "هنر" دی.

د ګوګل کلاوډ لاندې، دا ډول پروسې په چټکۍ سره پیچلې کیږي، ځکه چې ګوګل کلاوډ د خپلو کاروونکو محرمیت تضمین کولو لپاره ترټولو غوره هڅه کوي. د دې له امله، د TSE انجنیران ستاسو سیسټمونو ایډیټ کولو ته لاسرسی نلري، او نه هم د کاروونکو په څیر په پراخه توګه د ترتیبونو لیدلو توان لري. له همدې امله، زموږ د فرضیې ازموینې لپاره، موږ (انجنیران) نشي کولی په چټکۍ سره سیسټم بدل کړو.

ځینې ​​​​کاروونکي پدې باور دي چې موږ به د موټر په خدمت کې د میخانیک په څیر هرڅه سم کړو، او په ساده ډول موږ ته د مجازی ماشین id راولیږو، پداسې حال کې چې په حقیقت کې دا پروسه د خبرو اترو په بڼه ترسره کیږي: د معلوماتو راټولول، جوړول او تایید کول (یا رد کول) فرضیې، او، په پای کې، د پریکړې ستونزې د پیرودونکي سره د اړیکو پر بنسټ دي.

په سوال کې ستونزه

نن ورځ موږ د ښه پای سره یوه کیسه لرو. د وړاندیز شوې قضیې د بریالي حل لپاره یو دلیل د ستونزې خورا مفصل او دقیق توضیحات دي. لاندې تاسو کولی شئ د لومړي ټکټ یوه کاپي وګورئ (د محرم معلوماتو پټولو لپاره ترمیم شوی):

دا پیغام زموږ لپاره ډیر ګټور معلومات لري:

• ځانګړی VM مشخص شوی
• ستونزه پخپله اشاره شوې - DNS کار نه کوي
• دا په ګوته شوي چیرې چې ستونزه پخپله څرګندیږي - VM او کانټینر
• هغه ګامونه چې کارونکي د ستونزې پیژندلو لپاره اخیستي په ګوته شوي.

غوښتنه د "P1: جدي اغیزې - خدمت په تولید کې د کارونې وړ نه دی" په توګه ثبت شوی ، پدې معنی چې د وضعیت دوامداره څارنه 24/7 د "لمر تعقیب" سکیم مطابق (تاسو کولی شئ په اړه نور ولولئ. د کاروونکي غوښتنو لومړیتوبونه)، د هر وخت زون بدلون سره د یو تخنیکي مالتړ ټیم څخه بل ته د لیږد سره. په حقیقت کې، کله چې ستونزه په زوریخ کې زموږ ټیم ته ورسیده، دا لا دمخه د نړۍ ګرده وه. په دې وخت کې، کارونکي د کمولو تدابیر نیولي و، مګر په تولید کې د وضعیت له تکرار څخه ویره درلوده، ځکه چې اصلي لامل یې لا نه و موندل شوی.

کله چې ټکټ زیوریخ ته ورسید، موږ لا دمخه لاندې معلومات په لاس کې درلودل:

• منځپانګې /etc/hosts
• منځپانګې /etc/resolv.conf
• پایلې iptables-save
• د ټیم لخوا راټول شوي ngrep pcap فایل

د دې معلوماتو سره، موږ چمتو یو چې د "تحقیقاتو" او د ستونزو حل کولو پړاو پیل کړو.

زموږ لومړني ګامونه

له هرڅه دمخه ، موږ د میټاډاټا سرور لاګونه او حالت چیک کړ او ډاډ ترلاسه کړ چې دا سم کار کوي. د میټاډاټا سرور IP پته 169.254.169.254 ته ځواب ورکوي او د نورو شیانو په مینځ کې د ډومین نومونو کنټرول مسؤلیت لري. موږ دا هم دوه ځله چیک کړی چې د اور وژنې وال د VM سره سم کار کوي او پاکټونه نه بندوي.

دا یو ډول عجیب ستونزه وه: د nmap چک د UDP پاکټونو له لاسه ورکولو په اړه زموږ اصلي فرضیه رد کړه، نو موږ په ذهني توګه د دوی د چک کولو لپاره ډیری نور اختیارونه او لارې راوړو:

• ایا پاکټونه په انتخابي ډول غورځول شوي؟ => د iptables قواعد چیک کړئ
• ایا دا ډیر کوچنی ندی؟ MTU؟ => محصول وګورئ ip a show
• ایا ستونزه یوازې د UDP کڅوړې یا TCP هم اغیزه کوي؟ => وتښتئ dig +tcp
• ایا د ډیګ تولید شوي پاکټونه بیرته راستانه شوي؟ => وتښتئ tcpdump
• ایا libdns په سمه توګه کار کوي؟ => موټر چلول strace په دواړو لورو کې د پاکټونو لیږد چیک کول

دلته موږ پریکړه کوو چې کارونکي ته زنګ ووهئ ترڅو ستونزې په ژوندۍ توګه حل کړي.

د زنګ وهلو په جریان کې موږ کولی شو څو شیان وګورو:

• د څو چکونو وروسته موږ د دلایلو له لیست څخه د iptables قواعد لرې کوو
• موږ د شبکې انٹرفیسونه او روټینګ میزونه ګورو، او دوه ځله وګورئ چې MTU سم دی
• موږ دا کشف کوو dig +tcp google.com (TCP) لکه څنګه چې باید کار وکړي، مګر dig google.com (UDP) کار نه کوي
• وتښتول tcpdump دا اوس هم کار کوي dig، موږ ګورو چې د UDP کڅوړې بیرته راستنیږي
• موږ وتښتوو 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؟ پوښتنه عالي ده ، ځکه چې کاندید اړتیا لري د شیل څخه د کارونکي ځای ته ، د سیسټم کرنل او بیا شبکې ته هرڅه تشریح کړي. زه وخندل: ځینې وختونه د مرکې پوښتنې په ریښتیني ژوند کې ګټورې وي ...

زه پریکړه کوم چې دا د بشري حقونو پوښتنې په اوسني ستونزې کې پلي کړم. په لنډه توګه، کله چې تاسو د DNS نوم ټاکلو هڅه کوئ، لاندې واقع کیږي:

1. غوښتنلیک د سیسټم کتابتون ته غږ کوي لکه libdns
2. libdns د سیسټم ترتیب چیک کوي کوم DNS سرور ته باید اړیکه ونیسي (په ډیاګرام کې دا 169.254.169.254 دی، د میټاډاټا سرور)
3. libdns د UDP ساکټ (SOKET_DGRAM) جوړولو لپاره د سیسټم زنګونه کاروي او په دواړو لارښوونو کې د DNS پوښتنې سره د UDP کڅوړې لیږئ
4. د sysctl انٹرفیس له لارې تاسو کولی شئ د کرنل په کچه د UDP سټیک تنظیم کړئ
5. کرنل د هارډویر سره اړیکه لري ترڅو د شبکې انٹرفیس له لارې په شبکه کې پاکټونه انتقال کړي
6. هایپروایزر د دې سره په تماس کې د میټاډاټا سرور ته کڅوړه نیسي او لیږدوي
7. د میټاډاټا سرور، د خپل جادو په واسطه، د DNS نوم ټاکي او د ورته میتود په کارولو سره ځواب بیرته راولي

اجازه راکړئ تاسو ته یادونه وکړم چې کوم فرضیې موږ دمخه په پام کې نیولي دي:

فرضیه: مات شوي کتابتونونه

• 1 ازمایښت: په سیسټم کې سټریس چل کړئ، وګورئ چې ډیګ سم سیسټم کالونه کوي
• پایله: سم سیسټم ته ویل کیږي
• 2 ازموینه: د srapy کارول ترڅو وګوري چې ایا موږ کولی شو نومونه د سیسټم کتابتونونو څخه تیرولو سره وټاکو
• پایله: موږ کولی شو
• 3 ازموینه: په libdns کڅوړه او md5sum کتابتون فایلونو کې rpm –V چل کړئ
• پایله: د کتابتون کوډ په بشپړ ډول د کاري عملیاتي سیسټم کوډ سره ورته دی
• 4 ازموینه: د دې چلند پرته په VM کې د کارونکي روټ سیسټم عکس نصب کړئ، کروټ چل کړئ، وګورئ چې DNS کار کوي
• پایله: DNS په سمه توګه کار کوي

د ازموینو پر بنسټ پایله: ستونزه په کتابتونونو کې نه ده

فرضیه: د DNS ترتیباتو کې یوه تېروتنه شتون لري

• ازموینه 1: tcpdump وګورئ او وګورئ چې ایا د DNS پاکټونه لیږل شوي او د کیندنې چلولو وروسته سم بیرته راستانه شوي
• پایله: پاکټونه په سمه توګه لیږدول کیږي
• ازموینه 2: په سرور کې دوه ځله چیک کول /etc/nsswitch.conf и /etc/resolv.conf
• پایله: هرڅه سم دي

د ازموینو پر بنسټ پایله: ستونزه د DNS ترتیب سره نه ده

فرضیه: اصلي زیانمن شوی

• ازموینه: نوی کرنل نصب کړئ، لاسلیک وګورئ، بیا پیل کړئ
• پایله: ورته چلند

د ازموینو پر بنسټ پایله: دانه خرابه شوې نه ده

فرضیه: د کارونکي شبکې غلط چلند (یا د هایپروایسر شبکې انٹرفیس)

• ازموینه 1: خپل د فایروال تنظیمات چیک کړئ
• پایله: فایروال دواړه کوربه او GCP کې د DNS پاکټونه تیریږي
• 2 ازموینه: ټرافيک مداخله کول او د DNS غوښتنو د لیږد او بیرته راستنیدو سمه څارنه
• پایله: tcpdump تاییدوي چې کوربه بیرته پاکټونه ترلاسه کړي

د ازموینو پر بنسټ پایله: ستونزه په شبکه کې نه ده

فرضیه: د میټاډاټا سرور کار نه کوي

• ازموینه 1: د بې نظمیو لپاره د میټاډاټا سرور لاګونه چیک کړئ
• پایله: په لاګونو کې هیڅ ګډوډي شتون نلري
• ازموینه 2: د میټاډاټا سرور له لارې بای پاس کړئ dig @8.8.8.8
• پایله: حل حتی د میټاډاټا سرور کارولو پرته مات شوی

د ازموینو پر بنسټ پایله: ستونزه د میټاډاټا سرور سره نه ده

لاندې نه پاس کرښه: موږ پرته له دې چې ټول فرعي سیسټمونه ازمویل د چلولو ترتیبات!

د کرنل د چلولو ترتیباتو کې ډوب کول

د کرنل د اجرا کولو چاپیریال تنظیمولو لپاره، تاسو کولی شئ د کمانډ لاین اختیارونه (grub) یا د sysctl انٹرفیس وکاروئ. ما دننه وکتل /etc/sysctl.conf او یوازې فکر وکړئ، ما څو دودیز ترتیبات وموندل. داسې احساس کول لکه څنګه چې ما یو څه نیولي وي، ما ټول غیر شبکې یا غیر tcp ترتیبات رد کړل، پاتې د غره ترتیباتو سره net.core. بیا زه هغه ځای ته لاړم چیرې چې د کوربه اجازې په VM کې وې او د مات شوي VM سره یو له بل سره ، یو له بل وروسته تنظیمات پلي کول پیل کړل ، تر هغه چې ما مجرم وموند:

net.core.rmem_default = 2147483647

دلته دا دی، د DNS ماتولو ترتیب! ما د وژنې وسله وموندله. خو ولې داسې کېږي؟ زه لاهم یو انګېزې ته اړتیا لرم.

د لومړني DNS پاکټ بفر اندازه له لارې تنظیم شوې net.core.rmem_default. یو عادي ارزښت د 200KiB شاوخوا دی، مګر که ستاسو سرور ډیری DNS پاکټونه ترلاسه کړي، تاسو ممکن د بفر اندازه زیاته کړئ. که چیرې بفر ډک وي کله چې یو نوی کڅوړه راشي، د بیلګې په توګه ځکه چې غوښتنلیک دا په چټکۍ سره پروسس نه کوي، نو تاسو به د کڅوړو له لاسه ورکول پیل کړئ. زموږ پیرودونکي په سمه توګه د بفر اندازه زیاته کړه ځکه چې هغه د معلوماتو له لاسه ورکولو څخه ویره درلوده، ځکه چې هغه د 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 ته نږدې کیږي، د پیکټ اندازه لنډول ممکن پایله ولري د انټیجر ډیروالی. او څرنګه چې دا یو int دی، نو ارزښت یې منفي کیږي، نو حالت سم کیږي کله چې دا باید غلط وي (تاسو کولی شئ پدې اړه نور ولولئ مخونه).

تېروتنه په وړوکي ډول سمه کېدای شي: د کاسټ کولو له لارې unsigned int. ما فکس پلي کړ او سیسټم یې بیا پیل کړ او DNS بیا کار وکړ.

د بریا مزه

ما خپلې موندنې مراجعینو ته ولیږلې او واستول LKML د کرنل پیچ. زه خوښ یم: د معما هره برخه یوځای سره فټ کیږي، زه کولی شم په سمه توګه تشریح کړم چې ولې موږ هغه څه ولیدل چې موږ ولیدل، او تر ټولو مهم، موږ د دې توان درلود چې زموږ د ټیم کار څخه مننه د ستونزې حل ومومي!

دا د پیژندلو وړ ده چې قضیه نادره وه، او خوشبختانه موږ په ندرت سره د کاروونکو لخوا ورته پیچلې غوښتنې ترلاسه کوو.

سرچینه: www.habr.com