ამბავი Google Cloud ტექნიკური მხარდაჭერის DNS პაკეტების გამოტოვების შესახებ

Google ბლოგის რედაქტორიდან: ოდესმე გიფიქრიათ, როგორ უმკლავდებიან Google Cloud Technical Solutions (TSE) ინჟინრები თქვენს მხარდაჭერის მოთხოვნებს? TSE ტექნიკური მხარდაჭერის ინჟინრები პასუხისმგებელნი არიან მომხმარებლის მიერ მოხსენებული პრობლემების წყაროების იდენტიფიცირებასა და გამოსწორებაზე. ზოგიერთი პრობლემა საკმაოდ მარტივია, მაგრამ ხანდახან შეხვდებით ბილეთს, რომელიც ერთდროულად რამდენიმე ინჟინრის ყურადღებას მოითხოვს. ამ სტატიაში თსე-ის ერთ-ერთი თანამშრომელი მოგვითხრობს ერთ ძალიან სახიფათო პრობლემაზე მისი ბოლოდროინდელი პრაქტიკიდან - DNS პაკეტების დაკარგული შემთხვევა. ამ ისტორიაში ჩვენ ვნახავთ, როგორ მოახერხეს ინჟინერებმა სიტუაციის მოგვარება და რა ახალი რამ ისწავლეს შეცდომის გამოსწორებისას. ვიმედოვნებთ, რომ ეს ამბავი არა მხოლოდ გაგაცნობთ ღრმად დაფუძნებულ შეცდომის შესახებ, არამედ გაგაცნობთ პროცესებს, რომლებიც მიდის მხარდაჭერის ბილეთის შეტანაში Google Cloud-ში.

პრობლემების მოგვარება მეცნიერებაცაა და ხელოვნებაც. ყველაფერი იწყება ჰიპოთეზის აგებით სისტემის არასტანდარტული ქცევის მიზეზის შესახებ, რის შემდეგაც ხდება მისი სიძლიერის ტესტირება. თუმცა, სანამ ჰიპოთეზას ჩამოვაყალიბებთ, მკაფიოდ უნდა განვსაზღვროთ და ზუსტად ჩამოვაყალიბოთ პრობლემა. თუ კითხვა ძალიან ბუნდოვნად ჟღერს, მაშინ მოგიწევთ ყველაფრის გულდასმით გაანალიზება; ეს არის პრობლემების მოგვარების "ხელოვნება".

Google Cloud-ის პირობებში, ასეთი პროცესები ექსპონენტურად უფრო რთული ხდება, რადგან Google Cloud მაქსიმალურად ცდილობს უზრუნველყოს თავისი მომხმარებლების კონფიდენციალურობა. ამის გამო, TSE ინჟინრებს არ აქვთ წვდომა თქვენი სისტემების რედაქტირებაზე და არც კონფიგურაციების ნახვის შესაძლებლობა ისე ფართოდ, როგორც მომხმარებლებს. ამიტომ, ჩვენი რომელიმე ჰიპოთეზის შესამოწმებლად, ჩვენ (ინჟინრები) არ შეგვიძლია სწრაფად შევცვალოთ სისტემა.

ზოგიერთი მომხმარებელი თვლის, რომ ჩვენ გავასწორებთ ყველაფერს, როგორც მექანიკას მანქანის სერვისში და უბრალოდ გამოგვიგზავნით ვირტუალური მანქანის id-ს, მაშინ როცა სინამდვილეში პროცესი მიმდინარეობს სასაუბრო ფორმატში: ინფორმაციის შეგროვება, ჰიპოთეზების ფორმირება და დადასტურება (ან უარყოფა). და, საბოლოო ჯამში, გადაწყვეტილების მიღების პრობლემები ეფუძნება კლიენტთან კომუნიკაციას.

პრობლემა სადავოა

დღეს ჩვენ გვაქვს ამბავი კარგი დასასრულით. შემოთავაზებული საქმის წარმატებით გადაწყვეტის ერთ-ერთი მიზეზი პრობლემის ძალიან დეტალური და ზუსტი აღწერაა. ქვემოთ შეგიძლიათ იხილოთ პირველი ბილეთის ასლი (რედაქტირებულია კონფიდენციალური ინფორმაციის დასამალად):

ეს შეტყობინება შეიცავს ბევრ სასარგებლო ინფორმაციას ჩვენთვის:

• მითითებულია კონკრეტული VM
• თავად პრობლემა მითითებულია - DNS არ მუშაობს
• მითითებულია, სადაც პრობლემა იჩენს თავს - VM და კონტეინერი
• მითითებულია ის ნაბიჯები, რომლებიც მომხმარებელმა გადადგა პრობლემის იდენტიფიცირებისთვის.

მოთხოვნა დარეგისტრირდა როგორც „P1: კრიტიკული ზემოქმედება - წარმოებაში გამოუსადეგარი სერვისი“, რაც გულისხმობს სიტუაციის მუდმივ მონიტორინგს 24/7 რეჟიმში „მიჰყევით მზეს“ სქემის მიხედვით (დაწვრილებით შეგიძლიათ წაიკითხოთ მომხმარებლის მოთხოვნების პრიორიტეტები), მისი გადაცემით ერთი ტექნიკური მხარდაჭერის ჯგუფიდან მეორეზე დროის ზონის ყოველი ცვლის დროს. ფაქტობრივად, იმ დროისთვის, როცა პრობლემა ჩვენს გუნდს ციურიხში მიაღწია, მან უკვე შემოიარა მსოფლიო. ამ დროისთვის მომხმარებელმა მიიღო შემარბილებელი ზომები, მაგრამ ეშინოდა წარმოებაში სიტუაციის განმეორების, რადგან ძირეული მიზეზი ჯერ კიდევ არ იყო აღმოჩენილი.

იმ დროისთვის, როცა ბილეთი ციურიხამდე მივიდა, ჩვენ უკვე ხელთ გვქონდა შემდეგი ინფორმაცია:

• შინაარსი /etc/hosts
• შინაარსი /etc/resolv.conf
• გამოყვანის iptables-save
• გუნდის მიერ შეკრებილი ngrep pcap ფაილი

ამ მონაცემებით ჩვენ მზად ვიყავით „გამოძიების“ და პრობლემების აღმოფხვრის ეტაპის დასაწყებად.

ჩვენი პირველი ნაბიჯები

უპირველეს ყოვლისა, ჩვენ გადავამოწმეთ მეტამონაცემების სერვერის ჟურნალები და სტატუსი და დავრწმუნდით, რომ ის სწორად მუშაობდა. მეტამონაცემების სერვერი პასუხობს IP მისამართს 169.254.169.254 და, სხვა საკითხებთან ერთად, პასუხისმგებელია დომენური სახელების კონტროლზე. ჩვენ ასევე გადავამოწმეთ, რომ Firewall სწორად მუშაობს 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 პაკეტის შექმნას scrapy Python მოდულის გამოყენებით.

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 იყენებს სისტემურ ზარებს UDP სოკეტის შესაქმნელად (SOKET_DGRAM) და გაგზავნის UDP პაკეტებს DNS მოთხოვნით ორივე მიმართულებით
4. sysctl ინტერფეისის საშუალებით შეგიძლიათ დააკონფიგურიროთ UDP სტეკი ბირთვის დონეზე
5. ბირთვი ურთიერთქმედებს აპარატურასთან, რათა გადასცეს პაკეტები ქსელში ქსელის ინტერფეისის საშუალებით
6. ჰიპერვიზორი იჭერს და გადასცემს პაკეტს მეტამონაცემების სერვერზე მასთან შეხებისას
7. მეტამონაცემების სერვერი თავისი მაგიით განსაზღვრავს DNS სახელს და აბრუნებს პასუხს იმავე მეთოდის გამოყენებით

შეგახსენებთ, რა ჰიპოთეზები უკვე განვიხილეთ:

ჰიპოთეზა: გატეხილი ბიბლიოთეკები

• ტესტი 1: გაუშვით strace სისტემაში, შეამოწმეთ, რომ dig მოუწოდებს სწორი სისტემის ზარებს
• შედეგი: გამოძახებულია სწორი სისტემური ზარები
• ტესტი 2: srapy-ის გამოყენებით შევამოწმოთ, შეგვიძლია თუ არა სისტემის ბიბლიოთეკების გვერდის ავლით სახელების დადგენა
• შედეგი: ჩვენ შეგვიძლია
• ტესტი 3: გაუშვით rpm –V libdns პაკეტზე და md5sum ბიბლიოთეკის ფაილებზე
• შედეგი: ბიბლიოთეკის კოდი სრულიად იდენტურია მოქმედ ოპერაციულ სისტემაში არსებულ კოდთან
• ტესტი 4: დააინსტალირეთ მომხმარებლის root სისტემის სურათი VM-ზე ამ ქცევის გარეშე, გაუშვით chroot, ნახეთ თუ მუშაობს DNS
• შედეგი: DNS მუშაობს სწორად

დასკვნა ტესტებზე დაყრდნობით: პრობლემა ბიბლიოთეკებში არ არის

ჰიპოთეზა: არის შეცდომა DNS პარამეტრებში

• ტესტი 1: შეამოწმეთ tcpdump და ნახეთ, თუ DNS პაკეტები იგზავნება და დაბრუნდება სწორად გათხრების გაშვების შემდეგ
• შედეგი: პაკეტები სწორად არის გადაცემული
• ტესტი 2: ორმაგი შემოწმება სერვერზე /etc/nsswitch.conf и /etc/resolv.conf
• შედეგი: ყველაფერი სწორია

დასკვნა ტესტებზე დაყრდნობით: პრობლემა არ არის DNS კონფიგურაციაში

ჰიპოთეზა: ბირთვი დაზიანებულია

• ტესტი: დააინსტალირეთ ახალი ბირთვი, შეამოწმეთ ხელმოწერა, გადატვირთეთ
• შედეგი: მსგავსი ქცევა

დასკვნა ტესტებზე დაყრდნობით: ბირთვი არ არის დაზიანებული

ჰიპოთეზა: მომხმარებლის ქსელის (ან ჰიპერვიზორის ქსელის ინტერფეისის) არასწორი ქცევა

• ტესტი 1: შეამოწმეთ თქვენი firewall პარამეტრები
• შედეგი: firewall გადასცემს DNS პაკეტებს როგორც ჰოსტზე, ასევე GCP-ზე
• ტესტი 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. ტიპიური მნიშვნელობა არის დაახლოებით 200 KiB, მაგრამ თუ თქვენი სერვერი იღებს უამრავ DNS პაკეტს, შეიძლება დაგჭირდეთ ბუფერის ზომის გაზრდა. თუ ახალი პაკეტის ჩამოსვლისას ბუფერი სავსეა, მაგალითად, რადგან აპლიკაცია საკმარისად სწრაფად არ ამუშავებს მას, მაშინ დაიწყებთ პაკეტების დაკარგვას. ჩვენმა კლიენტმა სწორად გაზარდა ბუფერის ზომა, რადგან მას ეშინოდა მონაცემთა დაკარგვის, რადგან ის იყენებდა აპლიკაციას DNS პაკეტების საშუალებით მეტრიკის შესაგროვებლად. მის მიერ დაყენებული მნიშვნელობა იყო მაქსიმალური შესაძლო: 231-1 (თუ დაყენებულია 231-ზე, ბირთვი დააბრუნებს „INVALID ARGUMENT“).

უცებ მივხვდი, რატომ მუშაობდა nmap და scapy სწორად: ისინი იყენებდნენ ნედლეულ სოკეტებს! Raw სოკეტები განსხვავდება ჩვეულებრივი სოკეტებისგან: ისინი გვერდს უვლიან iptable-ებს და არ არის ბუფერული!

მაგრამ რატომ იწვევს „ძალიან დიდი ბუფერი“ პრობლემებს? აშკარად არ მუშაობს ისე, როგორც დაგეგმილი იყო.

ამ ეტაპზე მე შემეძლო პრობლემის რეპროდუცირება მრავალ ბირთვზე და მრავალ დისტრიბუციაზე. პრობლემა უკვე გაჩნდა 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 (ხელმოუწერელი თექვსმეტი ბიტიანი int) და ინახავს პაკეტის ზომას
• sk->sk_rcybuf არის int ტიპის და ინახავს ბუფერის ზომას, რომელიც, განსაზღვრებით, უდრის მნიშვნელობას net.core.rmem_default

როდესაც sk_rcvbuf უახლოვდება 231-ს, პაკეტის ზომის შეჯამებამ შეიძლება გამოიწვიოს მთელი რიცხვის გადინება. და რადგან ეს არის int, მისი მნიშვნელობა ხდება უარყოფითი, ასე რომ, პირობა ხდება ჭეშმარიტი, როდესაც ის უნდა იყოს false (შეგიძლიათ მეტი წაიკითხოთ ამის შესახებ აქ ლინკები).

შეცდომის გამოსწორება შესაძლებელია ტრივიალური გზით: ქასთინგით unsigned int. გამოვიყენე შესწორება და გადატვირთე სისტემა და DNS-მა ისევ იმუშავა.

გამარჯვების გემო

ჩემი დასკვნები გადავუგზავნე კლიენტს და გავგზავნე LKML ბირთვის პაჩი. კმაყოფილი ვარ: თავსატეხის ყველა ნაწილი ერთმანეთში ჯდება, შემიძლია ზუსტად ავხსნა, რატომ ვაკვირდებოდით იმას, რასაც ვაკვირდებოდით და რაც მთავარია, გუნდური მუშაობის გზით შევძელით პრობლემის გადაწყვეტის პოვნა!

აღსანიშნავია, რომ შემთხვევა იშვიათი აღმოჩნდა და, საბედნიეროდ, მომხმარებლებისგან იშვიათად ვიღებთ ასეთ რთულ მოთხოვნებს.

წყარო: www.habr.com