Google क्लाउड तकनीकी सहायता से गायब DNS पैकेट के बारे में एक कहानी

Google ब्लॉग संपादक से: क्या आपने कभी सोचा है कि Google क्लाउड टेक्निकल सॉल्यूशंस (टीएसई) इंजीनियर आपके समर्थन अनुरोधों को कैसे संभालते हैं? टीएसई तकनीकी सहायता इंजीनियर उपयोगकर्ता द्वारा बताई गई समस्याओं के स्रोतों की पहचान करने और उन्हें ठीक करने के लिए जिम्मेदार हैं। इनमें से कुछ समस्याएं काफी सरल हैं, लेकिन कभी-कभी आपके सामने एक ऐसा टिकट आ जाता है जिस पर एक साथ कई इंजीनियरों के ध्यान की आवश्यकता होती है। इस लेख में, टीएसई कर्मचारियों में से एक हमें अपने हालिया अभ्यास से एक बहुत ही जटिल समस्या के बारे में बताएगा - डीएनएस पैकेट गुम होने का मामला. इस कहानी में, हम देखेंगे कि इंजीनियरों ने स्थिति को कैसे हल किया, और त्रुटि को ठीक करते समय उन्होंने क्या नई चीजें सीखीं। हमें उम्मीद है कि यह कहानी आपको न केवल गहरे बैठे बग के बारे में शिक्षित करेगी, बल्कि आपको Google क्लाउड के साथ समर्थन टिकट दाखिल करने की प्रक्रियाओं के बारे में भी जानकारी देगी।

समस्या निवारण एक विज्ञान और कला दोनों है। यह सब सिस्टम के गैर-मानक व्यवहार के कारण के बारे में एक परिकल्पना के निर्माण से शुरू होता है, जिसके बाद इसकी ताकत का परीक्षण किया जाता है। हालाँकि, इससे पहले कि हम एक परिकल्पना तैयार करें, हमें समस्या को स्पष्ट रूप से परिभाषित और सटीक रूप से तैयार करना होगा। यदि प्रश्न बहुत अस्पष्ट लगता है, तो आपको हर चीज़ का सावधानीपूर्वक विश्लेषण करना होगा; यह समस्या निवारण की "कला" है.

Google क्लाउड के तहत, ऐसी प्रक्रियाएं तेजी से अधिक जटिल हो जाती हैं, क्योंकि Google क्लाउड अपने उपयोगकर्ताओं की गोपनीयता की गारंटी देने की पूरी कोशिश करता है। इस वजह से, टीएसई इंजीनियरों के पास आपके सिस्टम को संपादित करने की पहुंच नहीं है, न ही उपयोगकर्ताओं की तरह कॉन्फ़िगरेशन को व्यापक रूप से देखने की क्षमता है। इसलिए, अपनी किसी भी परिकल्पना का परीक्षण करने के लिए, हम (इंजीनियर) सिस्टम को तुरंत संशोधित नहीं कर सकते हैं।

कुछ उपयोगकर्ताओं का मानना ​​है कि हम कार सेवा में मैकेनिकों की तरह सब कुछ ठीक कर देंगे, और बस हमें एक वर्चुअल मशीन की आईडी भेज देंगे, जबकि वास्तव में यह प्रक्रिया एक वार्तालाप प्रारूप में होती है: जानकारी एकत्र करना, परिकल्पना बनाना और पुष्टि करना (या खंडन करना), और, अंत में, निर्णय की समस्याएं ग्राहक के साथ संचार पर आधारित होती हैं।

प्रश्नगत समस्या

आज हमारे पास एक अच्छी समाप्ति वाली कहानी है। प्रस्तावित मामले के सफल समाधान का एक कारण समस्या का बहुत विस्तृत और सटीक विवरण है। नीचे आप पहले टिकट की एक प्रति देख सकते हैं (गोपनीय जानकारी छिपाने के लिए संपादित):

इस संदेश में हमारे लिए बहुत सारी उपयोगी जानकारी है:

• विशिष्ट वीएम निर्दिष्ट
• समस्या स्वयं ही इंगित की गई है - DNS काम नहीं करता है
• यह इंगित किया गया है कि समस्या कहाँ प्रकट होती है - वीएम और कंटेनर
• समस्या की पहचान करने के लिए उपयोगकर्ता द्वारा उठाए गए कदम बताए गए हैं।

अनुरोध को "P1: गंभीर प्रभाव - उत्पादन में अनुपयोगी सेवा" के रूप में पंजीकृत किया गया था, जिसका अर्थ है "फॉलो द सन" योजना के अनुसार स्थिति की 24/7 निरंतर निगरानी (आप इसके बारे में अधिक पढ़ सकते हैं) उपयोगकर्ता अनुरोधों की प्राथमिकताएँ), प्रत्येक समय क्षेत्र बदलाव के साथ एक तकनीकी सहायता टीम से दूसरे में स्थानांतरण के साथ। दरअसल, जब तक समस्या ज्यूरिख में हमारी टीम तक पहुंची, तब तक यह दुनिया का चक्कर लगा चुकी थी। इस समय तक, उपयोगकर्ता ने शमन उपाय कर लिए थे, लेकिन उत्पादन में स्थिति की पुनरावृत्ति का डर था, क्योंकि मूल कारण अभी तक खोजा नहीं गया था।

जब तक टिकट ज्यूरिख पहुंचा, हमारे पास निम्नलिखित जानकारी पहले से ही उपलब्ध थी:

• अंतर्वस्तु /etc/hosts
• अंतर्वस्तु /etc/resolv.conf
• उत्पादन iptables-save
• टीम द्वारा एकत्रित किया गया ngrep pcap फ़ाइल

इस डेटा के साथ, हम "जांच" और समस्या निवारण चरण शुरू करने के लिए तैयार थे।

हमारा पहला कदम

सबसे पहले, हमने मेटाडेटा सर्वर के लॉग और स्थिति की जाँच की और सुनिश्चित किया कि यह सही ढंग से काम कर रहा है। मेटाडेटा सर्वर आईपी पते 169.254.169.254 पर प्रतिक्रिया करता है और, अन्य बातों के अलावा, डोमेन नामों को नियंत्रित करने के लिए जिम्मेदार है। हमने यह भी दोबारा जांचा कि फ़ायरवॉल वीएम के साथ सही ढंग से काम करता है और पैकेट को ब्लॉक नहीं करता है।

यह किसी प्रकार की अजीब समस्या थी: एनएमएपी जांच ने यूडीपी पैकेट के नुकसान के बारे में हमारी मुख्य परिकल्पना का खंडन किया, इसलिए हम मानसिक रूप से उन्हें जांचने के लिए कई और विकल्प और तरीके लेकर आए:

• क्या पैकेट चुन-चुनकर गिराए जाते हैं? => iptables नियमों की जाँच करें
• क्या यह बहुत छोटा नहीं है? एमटीयू? => आउटपुट जांचें ip a show
• क्या समस्या केवल यूडीपी पैकेट या टीसीपी को भी प्रभावित करती है? => दूर चला जाओ dig +tcp
• क्या खुदाई से उत्पन्न पैकेट लौटाए जाते हैं? => दूर चला जाओ tcpdump
• क्या libdns सही ढंग से काम कर रहा है? => दूर चलाओ strace दोनों दिशाओं में पैकेटों के प्रसारण की जाँच करने के लिए

यहां हम समस्याओं के निवारण के लिए उपयोगकर्ता को लाइव कॉल करने का निर्णय लेते हैं।

कॉल के दौरान हम कई चीज़ें जांचने में सक्षम हैं:

• कई जाँचों के बाद हम iptables नियमों को कारणों की सूची से बाहर कर देते हैं
• हम नेटवर्क इंटरफेस और राउटिंग टेबल की जांच करते हैं, और दोबारा जांचते हैं कि एमटीयू सही है
• हमने इसका पता लगाया dig +tcp google.com (टीसीपी) वैसे ही काम करता है जैसे उसे करना चाहिए, लेकिन dig google.com (यूडीपी) काम नहीं करता
• भगा दिया tcpdump काम करते समय dig, हमने पाया कि यूडीपी पैकेट वापस किये जा रहे हैं
• हम भगा देते हैं strace dig google.com और हम देखते हैं कि कैसे dig सही ढंग से कॉल करता है 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: सिस्टम में स्ट्रेस चलाएँ, जाँचें कि dig सही सिस्टम कॉल करता है
• परिणाम: सही सिस्टम कॉल बुलाए जाते हैं
• परीक्षण 2: यह जाँचने के लिए srapy का उपयोग करना कि क्या हम सिस्टम लाइब्रेरीज़ को दरकिनार कर नाम निर्धारित कर सकते हैं
• परिणाम: हम कर सकते हैं
• परीक्षण 3: libdns पैकेज और md5sum लाइब्रेरी फ़ाइलों पर rpm –V चलाएँ
• परिणाम: लाइब्रेरी कोड पूरी तरह से कार्यशील ऑपरेटिंग सिस्टम के कोड के समान है
• परीक्षण 4: इस व्यवहार के बिना उपयोगकर्ता की रूट सिस्टम छवि को वीएम पर माउंट करें, क्रोट चलाएं, देखें कि क्या डीएनएस काम करता है
• परिणाम: DNS सही ढंग से काम करता है

परीक्षणों के आधार पर निष्कर्ष: समस्या पुस्तकालयों में नहीं है

परिकल्पना: DNS सेटिंग्स में कोई त्रुटि है

• परीक्षण 1: tcpdump की जाँच करें और देखें कि क्या DNS पैकेट भेजे गए हैं और dig चलाने के बाद सही तरीके से लौटाए गए हैं
• परिणाम: पैकेट सही ढंग से प्रसारित होते हैं
• परीक्षण 2: सर्वर पर दोबारा जांच करें /etc/nsswitch.conf и /etc/resolv.conf
• नतीजा: सब कुछ सही है

परीक्षणों के आधार पर निष्कर्ष: समस्या DNS कॉन्फ़िगरेशन के साथ नहीं है

परिकल्पना: कोर क्षतिग्रस्त

• परीक्षण: नया कर्नेल स्थापित करें, हस्ताक्षर जांचें, पुनरारंभ करें
• परिणाम: समान व्यवहार

परीक्षणों के आधार पर निष्कर्ष: कर्नेल क्षतिग्रस्त नहीं है

परिकल्पना: उपयोगकर्ता नेटवर्क (या हाइपरवाइज़र नेटवर्क इंटरफ़ेस) का गलत व्यवहार

• परीक्षण 1: अपनी फ़ायरवॉल सेटिंग जांचें
• परिणाम: फ़ायरवॉल होस्ट और GCP दोनों पर DNS पैकेट पास करता है
• परीक्षण 2: ट्रैफ़िक को रोकना और DNS अनुरोधों के प्रसारण और वापसी की शुद्धता की निगरानी करना
• परिणाम: tcpdump पुष्टि करता है कि होस्ट को रिटर्न पैकेट प्राप्त हुए हैं

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

परिकल्पना: मेटाडेटा सर्वर काम नहीं कर रहा है

• परीक्षण 1: विसंगतियों के लिए मेटाडेटा सर्वर लॉग की जाँच करें
• परिणाम: लॉग में कोई विसंगतियाँ नहीं हैं
• परीक्षण 2: मेटाडेटा सर्वर को बायपास करें 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 पर सेट किया गया है, तो कर्नेल "अमान्य तर्क" लौटाएगा)।

अचानक मुझे एहसास हुआ कि एनएमएपी और स्कैपी ने सही तरीके से काम क्यों किया: वे कच्चे सॉकेट का उपयोग कर रहे थे! कच्चे सॉकेट नियमित सॉकेट से भिन्न होते हैं: वे iptables को बायपास करते हैं, और वे बफ़र नहीं होते हैं!

लेकिन "बफर बहुत बड़ा" समस्याएँ क्यों पैदा करता है? यह स्पष्ट रूप से इच्छानुसार काम नहीं करता है।

इस बिंदु पर मैं एकाधिक कर्नेल और एकाधिक वितरणों पर समस्या को पुन: उत्पन्न कर सकता हूं। समस्या पहले से ही 3.x कर्नेल पर दिखाई दे रही थी और अब यह 5.x कर्नेल पर भी दिखाई दे रही है।

दरअसल, स्टार्टअप पर

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

डीएनएस ने काम करना बंद कर दिया.

मैंने एक सरल बाइनरी सर्च एल्गोरिदम के माध्यम से कामकाजी मूल्यों की तलाश शुरू की और पाया कि सिस्टम 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 प्रकार का है और बफ़र आकार को संग्रहीत करता है, जो परिभाषा के अनुसार, in मान के बराबर है net.core.rmem_default

जब sk_rcvbuf 231 तक पहुंचता है, पैकेट आकार का योग परिणामित हो सकता है पूर्णांक अतिप्रवाह. और चूँकि यह एक इंट है, इसका मान नकारात्मक हो जाता है, इसलिए स्थिति तब सत्य हो जाती है जब इसे गलत होना चाहिए (आप इसके बारे में अधिक पढ़ सकते हैं लिंक).

त्रुटि को एक साधारण तरीके से ठीक किया जा सकता है: कास्टिंग द्वारा unsigned int. मैंने सुधार लागू किया और सिस्टम को पुनरारंभ किया और DNS ने फिर से काम किया।

जीत का स्वाद

मैंने अपने निष्कर्ष ग्राहक को भेज दिए LKML कर्नेल पैच. मुझे खुशी है: पहेली का हर टुकड़ा एक साथ फिट बैठता है, मैं सटीक रूप से समझा सकता हूं कि हमने जो देखा उसे हमने क्यों देखा, और सबसे महत्वपूर्ण बात यह है कि हम अपनी टीम वर्क की बदौलत समस्या का समाधान ढूंढने में सक्षम हुए!

यह पहचानने योग्य है कि मामला दुर्लभ निकला, और सौभाग्य से हमें उपयोगकर्ताओं से ऐसे जटिल अनुरोध शायद ही कभी प्राप्त होते हैं।

स्रोत: www.habr.com