Google क्लाउड तांत्रिक समर्थनाकडील DNS पॅकेट गहाळ झाल्याबद्दल एक कथा

Google ब्लॉग संपादकाकडून: Google क्लाउड टेक्निकल सोल्युशन्स (TSE) अभियंते तुमच्या समर्थन विनंत्या कशा हाताळतात याचा तुम्ही कधी विचार केला आहे का? TSE तांत्रिक सहाय्य अभियंते समस्यांचे वापरकर्ता-अहवाल स्रोत ओळखण्यासाठी आणि दुरुस्त करण्यासाठी जबाबदार आहेत. यापैकी काही समस्या अगदी सोप्या आहेत, परंतु काहीवेळा तुम्हाला असे तिकीट येते ज्यासाठी एकाच वेळी अनेक अभियंत्यांचे लक्ष आवश्यक असते. या लेखात, TSE कर्मचाऱ्यांपैकी एक आम्हाला त्याच्या अलीकडील सरावातील एका अतिशय अवघड समस्येबद्दल सांगेल - गहाळ DNS पॅकेट केस. या कथेत, अभियंत्यांनी परिस्थिती कशी सोडवली आणि त्रुटी दूर करताना त्यांनी कोणत्या नवीन गोष्टी शिकल्या हे आपण पाहू. आम्हाला आशा आहे की ही कथा तुम्हाला केवळ खोलवर बसलेल्या बगबद्दल शिक्षित करणार नाही, तर Google Cloud सह सपोर्ट तिकीट भरण्याच्या प्रक्रियेची अंतर्दृष्टी देखील देईल.

समस्यानिवारण हे शास्त्र आणि कला दोन्ही आहे. हे सर्व सिस्टमच्या गैर-मानक वर्तनाच्या कारणाविषयी एक गृहितक तयार करण्यापासून सुरू होते, त्यानंतर ते सामर्थ्यासाठी तपासले जाते. तथापि, आम्ही एक गृहितक तयार करण्यापूर्वी, आम्ही स्पष्टपणे परिभाषित केले पाहिजे आणि समस्या निश्चितपणे तयार केली पाहिजे. जर प्रश्न खूप अस्पष्ट वाटत असेल तर आपल्याला प्रत्येक गोष्टीचे काळजीपूर्वक विश्लेषण करावे लागेल; ही समस्यानिवारणाची "कला" आहे.

Google Cloud अंतर्गत, अशा प्रक्रिया वेगाने अधिक जटिल बनतात, कारण Google Cloud त्याच्या वापरकर्त्यांच्या गोपनीयतेची हमी देण्याचा सर्वोत्तम प्रयत्न करते. यामुळे, TSE अभियंत्यांना तुमची प्रणाली संपादित करण्यासाठी प्रवेश नाही, किंवा वापरकर्त्यांप्रमाणे कॉन्फिगरेशन पाहण्याची क्षमता नाही. म्हणून, आमच्या कोणत्याही गृहीतकाची चाचणी घेण्यासाठी, आम्ही (अभियंते) प्रणालीमध्ये त्वरीत बदल करू शकत नाही.

काही वापरकर्त्यांचा असा विश्वास आहे की आम्ही कार सेवेतील मेकॅनिक्सप्रमाणे सर्वकाही ठीक करू आणि आम्हाला फक्त व्हर्च्युअल मशीनचा आयडी पाठवू, तर प्रत्यक्षात ही प्रक्रिया संभाषणात्मक स्वरूपात होते: माहिती गोळा करणे, तयार करणे आणि पुष्टी करणे (किंवा खंडन करणे) गृहीतके, आणि शेवटी, निर्णय समस्या क्लायंटशी संवादावर आधारित असतात.

प्रश्नातील समस्या

आज आपल्याकडे एक चांगला शेवट असलेली कथा आहे. प्रस्तावित प्रकरणाच्या यशस्वी निराकरणाचे एक कारण म्हणजे समस्येचे अतिशय तपशीलवार आणि अचूक वर्णन. खाली तुम्ही पहिल्या तिकिटाची प्रत पाहू शकता (गोपनीय माहिती लपवण्यासाठी संपादित):

या संदेशामध्ये आमच्यासाठी बरीच उपयुक्त माहिती आहे:

• विशिष्ट VM निर्दिष्ट
• समस्या स्वतः दर्शविली आहे - DNS कार्य करत नाही
• हे सूचित केले आहे की समस्या कोठे प्रकट होते - VM आणि कंटेनर
• वापरकर्त्याने समस्या ओळखण्यासाठी घेतलेली पावले दर्शविली आहेत.

विनंती “P1: क्रिटिकल इम्पॅक्ट - सेवा उत्पादनात अनुपयोगी” म्हणून नोंदवण्यात आली होती, याचा अर्थ “फॉलो द सन” योजनेनुसार परिस्थितीचे 24/7 सतत निरीक्षण करणे (आपण याबद्दल अधिक वाचू शकता वापरकर्ता विनंत्यांचे प्राधान्यक्रम), प्रत्येक टाइम झोन शिफ्टसह एका तांत्रिक सहाय्य संघाकडून दुसऱ्याकडे हस्तांतरणासह. खरं तर, समस्या झुरिचमध्ये आमच्या टीमपर्यंत पोहोचली तोपर्यंत ती जगभर फिरली होती. यावेळेपर्यंत, वापरकर्त्याने कमी करण्याचे उपाय केले होते, परंतु उत्पादनातील परिस्थितीची पुनरावृत्ती होण्याची भीती होती, कारण अद्याप मूळ कारण शोधले गेले नव्हते.

तिकीट झुरिचला पोहोचेपर्यंत, आमच्याकडे आधीच खालील माहिती होती:

• सामग्री /etc/hosts
• सामग्री /etc/resolv.conf
• निष्कर्ष iptables-save
• संघाने जमवले ngrep pcap फाइल

या डेटासह, आम्ही "तपास" आणि समस्यानिवारण टप्पा सुरू करण्यास तयार होतो.

आमची पहिली पायरी

सर्व प्रथम, आम्ही मेटाडेटा सर्व्हरचे लॉग आणि स्थिती तपासली आणि ते योग्यरित्या कार्य करत असल्याची खात्री केली. मेटाडेटा सर्व्हर आयपी ॲड्रेस 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, आम्हाला आढळले की 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 वर माउंट करा, chroot चालवा, DNS कार्य करते का ते पहा
• परिणाम: DNS योग्यरित्या कार्य करते

चाचण्यांवर आधारित निष्कर्ष: समस्या ग्रंथालयांमध्ये नाही

गृहीतक: DNS सेटिंग्जमध्ये त्रुटी आहे

• चाचणी 1: tcpdump तपासा आणि डीएनएस पॅकेट पाठवल्या गेल्या आहेत का ते पहा
• परिणाम: पॅकेट योग्यरित्या प्रसारित केले जातात
• चाचणी 2: सर्व्हरवर दोनदा तपासा /etc/nsswitch.conf и /etc/resolv.conf
• परिणाम: सर्वकाही बरोबर आहे

चाचण्यांवर आधारित निष्कर्ष: समस्या DNS कॉन्फिगरेशनमध्ये नाही

गृहीतक: कोर नुकसान

• चाचणी: नवीन कर्नल स्थापित करा, स्वाक्षरी तपासा, रीस्टार्ट करा
• परिणाम: समान वर्तन

चाचण्यांवर आधारित निष्कर्ष: कर्नल खराब झालेले नाही

गृहीतक: वापरकर्ता नेटवर्कचे चुकीचे वर्तन (किंवा हायपरवाइजर नेटवर्क इंटरफेस)

• चाचणी 1: तुमची फायरवॉल सेटिंग्ज तपासा
• परिणाम: फायरवॉल होस्ट आणि GCP दोन्हीवर DNS पॅकेट पास करते
• चाचणी २: ट्रॅफिकमध्ये अडथळा आणा आणि DNS विनंत्यांच्या ट्रान्समिशन आणि रिटर्नच्या अचूकतेचे निरीक्षण करा
• परिणाम: tcpdump पुष्टी करतो की होस्टने परतीची पॅकेट्स प्राप्त केली आहेत

चाचण्यांवर आधारित निष्कर्ष: समस्या नेटवर्कमध्ये नाही

गृहीतक: मेटाडेटा सर्व्हर काम करत नाही

• चाचणी 1: विसंगतींसाठी मेटाडेटा सर्व्हर लॉग तपासा
• परिणाम: नोंदींमध्ये कोणतीही विसंगती नाहीत
• चाचणी २: मेटाडेटा सर्व्हर द्वारे बायपास करा dig @8.8.8.8
• परिणाम: मेटाडेटा सर्व्हर न वापरताही रिझोल्यूशन खंडित झाले आहे

चाचण्यांवर आधारित निष्कर्ष: समस्या मेटाडेटा सर्व्हरमध्ये नाही

निष्कर्ष: आम्ही वगळता सर्व उपप्रणालींची चाचणी केली रनटाइम सेटिंग्ज!

कर्नल रनटाइम सेटिंग्जमध्ये जाणे

कर्नल एक्झिक्युशन वातावरण कॉन्फिगर करण्यासाठी, तुम्ही कमांड लाइन पर्याय (ग्रब) किंवा sysctl इंटरफेस वापरू शकता. मी आत पाहिले /etc/sysctl.conf आणि फक्त विचार करा, मला अनेक सानुकूल सेटिंग्ज सापडल्या आहेत. मी काहीतरी पकडले आहे असे वाटून, मी सर्व नॉन-नेटवर्क किंवा नॉन-टीसीपी सेटिंग्ज टाकून दिल्या, बाकीच्या माउंटन सेटिंग्जसह net.core. मग मी व्हीएममध्ये जिथे होस्ट परवानग्या होत्या तिथे गेलो आणि तुटलेल्या व्हीएमसह एकामागून एक सेटिंग्ज लागू करू लागलो, जोपर्यंत मला दोषी सापडत नाही:

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 पुन्हा कार्य केले.

विजयाची चव चाखली

मी माझे निष्कर्ष क्लायंटला पाठवले आणि पाठवले एलकेएमएल कर्नल पॅच. मला आनंद झाला: कोडेचा प्रत्येक भाग एकत्र बसतो, आम्ही जे निरीक्षण केले ते आम्ही का पाहिले हे मी स्पष्ट करू शकतो आणि सर्वात महत्त्वाचे म्हणजे आमच्या टीमवर्कमुळे आम्ही समस्येचे निराकरण करण्यात सक्षम झालो!

हे प्रकरण दुर्मिळ असल्याचे ओळखणे योग्य आहे आणि सुदैवाने आम्हाला वापरकर्त्यांकडून अशा जटिल विनंत्या क्वचितच प्राप्त होतात.

स्त्रोत: www.habr.com