कैसे हम महान चीनी फ़ायरवॉल (1 भाग) छेदा

सभी को नमस्कार!

स्पर्श में निकिता सेमरश से सिस्टम इंजीनियर हैं। आज मैं आपको बताऊंगा कि कैसे हमने चीन में अपनी semrush.com सेवा की स्थिरता सुनिश्चित करने के कार्य का सामना किया, और इसके कार्यान्वयन के दौरान हमें क्या समस्याएं आईं (अमरीका के पूर्वी तट पर हमारे डेटा केंद्र का स्थान दिया गया)।

यह एक बेहतरीन कहानी होगी, जिसे कई लेखों में विभाजित किया गया है। मैं आपको बताता हूं कि यह सब हमारे साथ कैसे हुआ: चीन से पूरी तरह से काम न करने वाली सेवा से लेकर अमेरिकियों के लिए इसके अमेरिकी संस्करण के स्तर पर सेवा का प्रदर्शन। मैं वादा करता हूं कि यह दिलचस्प और उपयोगी होगा। तो चलिए चलते हैं।

चीनी इंटरनेट मुद्दे

यहां तक ​​कि नेटवर्क प्रशासन की बारीकियों से सबसे दूर के व्यक्ति ने कम से कम एक बार महान चीनी फ़ायरवॉल के बारे में सुना। उह, यह अच्छा लग रहा है, हुह? लेकिन यह क्या है, यह वास्तव में कैसे काम करता है यह एक जटिल प्रश्न है। इंटरनेट पर आप इस पर कई लेख पा सकते हैं, लेकिन तकनीकी दृष्टिकोण से इस फ़ायरवॉल का उपकरण कहीं भी वर्णित नहीं है। हालांकि, यह आश्चर्यजनक नहीं है। मैं तुरंत स्वीकार करता हूं कि काम के वर्ष के परिणामों के आधार पर, मैं बिल्कुल नहीं कह सकता कि यह कैसे काम करता है, लेकिन मैं अपनी टिप्पणियों और व्यावहारिक निष्कर्षों के बारे में बता सकता हूं। और हम इस फ़ायरवॉल के बारे में अफवाहों से शुरू करेंगे।

इस बहुत फ़ायरवॉल के बारे में कई अफवाहें हैं। आइए उनमें से मुख्य और सबसे दिलचस्प चीजों को एक सूची में इकट्ठा करें:

• Google, फेसबुक, ट्विटर और अन्य समान सेवाएं अवरुद्ध हैं और चीन में काम नहीं करती हैं।
• चीन और चीन के बाहर जाने वाले किसी भी ट्रैफ़िक को मशीन लर्निंग (संदिग्ध ट्रैफ़िक के मामले में) द्वारा पार्स और सीमित किया जाता है, जो सीमा से गुजरने वाले इसे (ट्रैफ़िक) को बहुत धीमा कर देता है।
• चीनी खुफिया एजेंसियां ​​अपने फ़ायरवॉल के माध्यम से जाने वाले किसी भी एन्क्रिप्टेड ट्रैफ़िक को क्रैक करती हैं।
• वीपीएन सुरंग, IPSEC सुरंग अस्थिर हैं, गिरती हैं और लगातार अवरुद्ध होती हैं।
• एन्क्रिप्शन जितना सरल होगा, प्रमाणीकरण / ट्रैफ़िक सिफर के लिए उपयोग किया जाने वाला पास वाक्यांश उतना ही सरल होगा, जितनी तेज़ी से यह चीनी फ़ायरवॉल को पार करेगा।

यहाँ हम इन अफवाहों के बारे में पता लगाने में कामयाब रहे:

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

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832 time_namelookup: 0.004500 time_connect: 0.169342 time_appconnect: 0.723189 time_pretransfer: 0.723499 time_redirect: 0.000000 time_starttransfer: 1.532912 ---------- time_total: 5.443407 ---------- size_download: 390968 Bytes speed_download: 71824.000B/s nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k time_namelookup: 0.029366 time_connect: 0.030742 time_appconnect: 0.047310 time_pretransfer: 0.047388 time_redirect: 0.000000 time_starttransfer: 0.120793 ---------- time_total: 0.124871 ---------- size_download: 326755 Bytes speed_download: 2616740.000B/s 

Time_connect पर ध्यान दें । और सामान्य तौर पर, आप परिणाम देखते हैं: फ़ायरवॉल 4 अतिरिक्त सेकंड जोड़ता है, जो राक्षसी रूप से लंबा है।

• वीपीएन और आईपीएसईसी सुरंग अक्सर गिरते हैं। मैं इस बारे में थोड़ी देर और अधिक विस्तार से बात करूंगा। उपयोगकर्ताओं द्वारा उपयोग किए जाने वाले वीपीएन सर्वर समय के साथ अवरुद्ध हो जाते हैं (आमतौर पर उपयोग शुरू होने के बाद एक दिन के भीतर)।
• चीन में रहने वाले लोगों से प्राप्त एक राय है कि यातायात का एन्क्रिप्शन जितना आसान है, उतनी ही तेज़ी से यह सीमा से गुजरता है, क्योंकि यह समझना आसान है कि इसमें कुछ भी अवैध नहीं है। और जिस तरह "स्वच्छ" ट्रैफ़िक को अधिक बैंडविड्थ और गति मिलती है, और "गंदे" ट्रैफ़िक, जो कुछ भी नहीं बनाता है, इसके विपरीत धीमी गति से पास हो जाता है। एक उदाहरण के लिए, मैं HTTPS और HTTP प्रोटोकॉल का उपयोग करके ifconfig.co में कर्ल लाऊंगा।

 curl -o /dev/null -w@curl_time "https://ifconfig.co/" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3 time_namelookup: 0.004305 time_connect: 0.397465 time_appconnect: 5.149305 time_pretransfer: 5.149393 time_redirect: 0.000000 time_starttransfer: 5.568847 ---------- time_total: 5.568893 ---------- size_download: 13 Bytes speed_download: 2.000B/s curl -o /dev/null -w@curl_time "http://ifconfig.co/" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28 time_namelookup: 0.004282 time_connect: 0.212457 time_appconnect: 0.000000 time_pretransfer: 0.212484 time_redirect: 0.000000 time_starttransfer: 0.450565 ---------- time_total: 0.450620 ---------- size_download: 13 Bytes speed_download: 28.000B/s 

अंतर 13 बाइट्स के कुल लोड समय के लिए 5 सेकंड है। इस परीक्षण को कई बार करते हुए, आप देख सकते हैं कि एचटीटी पर जीईटी सामान्य रूप से हर बार एक ही समय में पूरा होता है, एचटीटीपीएस का उपयोग करते हुए, साइट कभी-कभी 3, 5, 10 और यहां तक ​​कि 17 सेकंड में जवाब देती है। एसएसएल त्रुटियाँ कभी-कभी होती हैं:

Unknown SSL protocol error in connection to ifconfig.co:443.

तो हमारे पास क्या है:

• ऊपर वर्णित चीनी फ़ायरवॉल द्वारा बनाई गई समस्याएं।
• बाहरी संसाधनों और सुरंगों के अंदर समय-समय पर गायब हो जाते हैं।
• दो बिंदुओं के बीच विलंबता लगातार बदल रही है, और अक्सर यह अप्रत्याशित है। विभिन्न शहरों / क्षेत्रों को जोड़कर, आप उम्मीद करते हैं कि क्षेत्रों की भौगोलिक स्थिति के आधार पर, देरी कम होगी, और आप बिल्कुल विपरीत स्थिति प्राप्त करेंगे।
• इंटरनेट और संचार चैनल या तो तेज़ या धीमे हैं। सप्ताह के दिन और दिन के समय पर थोड़ी निर्भरता होती है, लेकिन हमेशा नहीं।
• चीन से बाहरी दुनिया के लिए DNS क्वेरी कभी-कभी अनुमत समय से अधिक होती है।

चित्र बस "उत्कृष्ट" करघे।

डेटा सेंटर, जैसा कि मैंने पहले ही कहा था, संयुक्त राज्य अमेरिका के पूर्व में है, और पूरे SEMrush में दर्जनों परस्पर जुड़े उत्पाद, बैकएंड, फ्रंटेंड, डेटाबेस और डेटा सेंटर और बादलों में यह सब शामिल है। सिस्टम प्रशासकों की एक टीम के रूप में, हमें चीन में जल्दी काम शुरू करने के लिए एक छोटे से प्रयास का काम सौंपा गया था।

हमें एक महत्वपूर्ण प्रश्न का उत्तर देना था: क्या हम थोड़े से रक्त से प्राप्त कर सकते हैं और नेटवर्क / क्लाउड / सर्वर स्तर पर चीनी इंटरनेट और फ़ायरवॉल से जुड़ी सभी समस्याओं को हल कर सकते हैं?

हमने एक आईसीपी लाइसेंस प्राप्त करके शुरुआत की।

आईसीपी लाइसेंस

चीन (मुख्यभूमि चीन) के भीतर अपनी सेवा देने में सक्षम होने और परीक्षण करने के लिए, आपको सबसे पहले एक आईसीपी डोमेन लाइसेंस प्राप्त करना होगा।

यदि आपकी साइट का उपयोगकर्ता ट्रैफ़िक मुख्यभूमि चीन के भीतर समाप्त हो गया है, और यदि आपके डोमेन में ICP लाइसेंस नहीं है, तो आपका ट्रैफ़िक प्रदाता / होस्टिंग पक्ष पर अवरुद्ध हो जाएगा। दिलचस्प है, एक विशिष्ट प्रदाता आईसीपी लाइसेंस में फिट बैठता है, चाहे वह क्लाउडफेयर या अलीबाबा क्लाउड हो। इसलिए, यदि आपको Cloudflare के लिए ICP लाइसेंस प्राप्त हुआ है और आपने अपनी साइट को उनके साथ होस्ट किया है, तो आप अलीबाबा क्लाउड में "मूल" नहीं जा पाएंगे। इस लाइसेंस में एक और होस्टिंग जोड़ना आवश्यक होगा।

ICP- डोमेन लाइसेंस प्राप्त करने के बाद, हम विशिष्ट तकनीकी विचारों और समाधानों के साथ आने और लागू करने में सक्षम थे।

परीक्षण समाधान

लेकिन इससे पहले कि आप सीधे मंचन के लिए विकल्प बनाएं, नॉब्स को घुमाएं, साइट और उसकी गति को अनुकूलित करें, आपको यह देखने के लिए एक उपकरण चुनने की आवश्यकता है कि यह देखने के लिए कि हमारे कार्यों में सुधार होता है या साइट का काम बिगड़ता है।

हमारे परीक्षण उपकरण को दो मुख्य आवश्यकताओं को पूरा करना था:

• वह चीन से परीक्षण चलाने में सक्षम होना चाहिए,
• इसके ब्राउजर टेस्ट होने चाहिए।

तो हमने कैचपॉइंट पाया! उनके पास दुनिया भर में परीक्षण बिंदुओं के साथ उत्कृष्ट कवरेज है। चीन में, इस उपकरण के माध्यम से, आप 100,500 प्रांतों से परीक्षण भी चला सकते हैं। प्रत्येक में, कई अलग-अलग प्रदाता + बैकबोन परीक्षण करने की क्षमता (डेटा सेंटर में एक वर्चुअल मशीन की तरह कुछ) और लास्टइमाइल परीक्षण (उपयोगकर्ता की स्थिति, उर्फ ​​वर्कस्टेशन के जितना करीब हो)। बाद के प्रकार का परीक्षण अधिक महंगा है।

एक साल के अनुबंध (आप कम नहीं कर सकते) के समापन के बाद, हमने उपकरण का अध्ययन शुरू किया। सच कहूँ तो, हम इसकी कार्यक्षमता से सुखद आश्चर्यचकित थे। आप चला सकते हैं:

• डीएनएस परीक्षण
• वेब परीक्षण (ब्राउज़र, सरल GET / POST, मोबाइल ग्राहक का अनुकरण आदि),
• लेन-देन की जाँच (जैसे लॉगिन),
• एपीआई परीक्षण
• पिंग, ट्रेसरआउट, NTP, आदि।

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

• कनेक्ट, प्रतीक्षा, लोड, एसएसएल, डीएनएस समय,
• TTFB, TTLB, दस्तावेज़ पूर्ण, रेंडर समय, DOM लोड,
• प्रतिक्रिया (पहली बाइट के लिए समय के करीब कुछ), वेबपेज रिस्पांस (टाइम टू लास्ट बाइट के करीब),
• किसी भी प्रतिशत, औसत, औसत समय
• आदि

तदनुसार, ये सभी मैट्रिक्स आपको परिवर्तनों को देखने और समझने में मदद करते हैं कि क्या यह बेहतर हो गया है। हमने मुख्य रूप से रिस्पॉन्स, वेबपेज रिस्पॉन्स, मेडियन, 75 और 95 पर्सेंटाइल को देखा ।

एक महत्वपूर्ण सवाल जो शुरू से ही हवा में रहा है: क्या कैचपॉइंट पर विश्वास करना संभव है ? क्या यह उपकरण विभिन्न शहरों से चीन में वास्तविक साइट लोडिंग गति को दर्शाता है या क्या यह वैक्यूम में किसी प्रकार का परीक्षण है जिसका वास्तविक उपयोगकर्ता अनुभव से कोई लेना-देना नहीं है?
यह एक बड़ी समस्या है, क्योंकि रूस में होने के कारण यह पता लगाना लगभग असंभव है कि चीन की साइट कैसे काम करती है। एक वर्चुअल मशीन के माध्यम से मोज़े-प्रॉक्सी करने से, आपको अंत में कुछ मिनटों में एक वेबसाइट लोड होती है, जो केवल परीक्षणों के लिए अस्वीकार्य है, इसलिए समय माप के साथ कंसोल से कर्ल और सरल GETs मैन्युअल परीक्षण के लिए एकमात्र विकल्प बने हुए हैं। यह मदद करता है, क्योंकि यह परीक्षण नेटवर्क समाधान की गति को दर्शाता है, और यदि ब्राउज़र परीक्षण हैं, तो यह बहुत अच्छा है।

बाद में, हम खुद चीन गए और सुनिश्चित किया कि कैचपॉइंट पर भरोसा किया जा सकता है, यह काफी सटीक गति के वास्तविक संकेतकों को दर्शाता है।

Cloudflare China नेटवर्क

चूंकि हम मुख्य semrush.com डोमेन के लिए क्लाउडफेयर का सफलतापूर्वक उपयोग करते हैं, इसलिए हमने तुरंत चीन नेटवर्क नामक उनकी सुविधा का प्रयास करने का फैसला किया। यह विकल्प केवल एंटरप्राइज़ साइटों के अनुरोध पर और शुल्क के लिए सक्षम है। यह केवल उन साइटों के लिए भी उपलब्ध है जिनके पास उपयुक्त ICP लाइसेंस है, जिसमें प्रदाता के रूप में Cloudflare निर्दिष्ट है। इसके चालू होने के बाद, क्लाउडफ़ेयर से एक "चीनी सीडीएन" साइट के लिए उपलब्ध हो जाता है - अगले PoP (उपस्थिति के अंक) CF में चीनी क्षेत्रों की भूमि से ट्रैफ़िक, और फिर प्रदाताओं / भागीदारों के नेटवर्क या नेटवर्कों के माध्यम से मूल में पहुंचाया जाता है।

इस परीक्षण पीठ की योजना नीचे प्रस्तुत की गई है।

यह हमारे लिए एक बेहतरीन विकल्प है। यह पता चला है कि दूसरा डोमेन सीएफ के लिए भी होगा, जो कंपनी में उपयोग किए जाने वाले समाधानों की संख्या को नहीं जोड़ता है, और व्यावहारिक रूप से बुनियादी ढांचे को जटिल नहीं करता है।

हमने ब्राउज़र परीक्षण चलाए, और यही हुआ:

लाल हीरे परीक्षण फाइलें हैं। नीचे दी गई फाइलें DNS एरर हैं (टाइमआउट हल करें)। उपरोक्त विफलताएं टाइमआउट हैं।

अपटाइम: 86.6
मेडियन: 18 एस
75 प्रतिशत: 29.3 एस
95 प्रतिशत: 60 एस

माध्यिका, reCaptcha डाउनलोड (चीन में अवरुद्ध एक Google सेवा) को हटाने के बाद, 28 से 18 सेकंड तक कम हो गई। लेकिन फिर भी, ये भयानक संकेतक हैं, यह देखते हुए कि semrush.com (यूएसए से) के लिए एक ही परीक्षण ने 95% उपयोगकर्ताओं (यूएसए से) को एक ही पृष्ठ (स्टेटिक्स + डायनेमिक्स) के लिए 10 सेकंड से कम समय दिया।

प्रत्येक परीक्षण में, आप झरना और अन्य अधिक विस्तृत पैरामीटर देख सकते हैं और देख सकते हैं। हमने त्रुटियों के कारणों की जांच करना शुरू किया, और यदि समय-समय पर सब कुछ कम या अधिक स्पष्ट है: चीन में इंटरनेट "नीचे जा रहा है, तो दूर जा रहा है", इस वजह से विदेशों से संसाधनों को जोड़ने और लोड करने की गति अस्थिर और असमान है, फिर DNS त्रुटियों ने हमें बहुत आश्चर्यचकित किया । हमने पाया कि क्लाउडफ्लेयर के PoPs वास्तव में चीन में स्थित हैं, साइट का पता एक एकल आईपीकास्ट के साथ है, लेकिन DNS सर्वर का उपयोग अमेरिका द्वारा किया जाता है, यही कारण है कि DNS प्रश्नों को सीमा से गुजरने के लिए मजबूर किया जाता है, इसलिए कभी-कभी वे विफल हो जाते हैं।

सीएफ के साथ इस प्रश्न को स्पष्ट करने के बाद, यह पता चला कि उनके पास चीन में अपने स्वयं के DNS सर्वर नहीं हैं , और यह अभी भी अज्ञात है कि यह कब होगा।

इसलिए, हमने केवल Cloudflare DNS का परीक्षण करने का निर्णय लिया और हमारी साइट के लिए Cloudflare तंत्र को " DNS Only " मोड में बदल दिया। यह एक ऐसी विधा है जब Cloudflare स्वयं के माध्यम से प्रॉक्सी ट्रैफ़िक नहीं करता है, जिसका अर्थ है कि यह DDoS सुरक्षा, CDN और अन्य सुविधाएँ प्रदान नहीं करता है, और सामान्य DNS सर्वर के मोड में काम करता है।

यह स्टैंड निम्न आकृति में योजनाबद्ध रूप से दिखाया गया है। यह आंकड़ा उभरते ज्ञान को ध्यान में रखता है कि फ़ायरवॉल के पीछे Cloudflare DNS सर्वर है।

कैचपॉइंट पर, हमने सरल GET परीक्षण (गैर-ब्राउज़र) चलाया, जिसमें बहुत सारी विफलताएँ दिखाई दीं। उनके लिए कारण सभी एक ही DNS त्रुटियों थे।

हमने खुदाई का उपयोग करके इन त्रुटियों को डिबग करना शुरू कर दिया और पाया कि पता पहले अनुरोध पर सही ढंग से निर्धारित किया गया है, और बार-बार अनुरोध पर हमें SERVFAIL मिलता है और हर बार नहीं मिलता है। यह अचानक क्या है?

 root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn semrushchina.cn has address 220.170.186.192 Host semrushchina.cn not found: 2(SERVFAIL) root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn semrushchina.cn has address 220.170.186.192 Host semrushchina.cn not found: 2(SERVFAIL) root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn semrushchina.cn has address 220.170.186.192 Host semrushchina.cn not found: 2(SERVFAIL) root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn semrushchina.cn has address 220.170.186.192 Host semrushchina.cn not found: 2(SERVFAIL) 

Cloudflare NS सर्वर से सीधे अनुरोध करते समय, ऐसी त्रुटियां नहीं होती हैं:

 root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done Using domain server: Name: ray.ns.cloudflare.com. Address: 173.245.59.138#53 Aliases: semrushchina.cn has address 220.170.186.192 semrushchina.cn has address 220.170.186.192 Using domain server: Name: ray.ns.cloudflare.com. Address: 173.245.59.138#53 Aliases: semrushchina.cn has address 220.170.186.192 semrushchina.cn has address 220.170.186.192 

इसका मतलब है कि समस्या "स्थानीय" DNS सर्वर या प्रदाता सर्वर की तरफ है।
आगे की जांच से पता चला कि हमें AAAA रिकॉर्ड के रिज़ॉल्यूशन पर SERVFAIL मिलता है।

यह पता चला कि जब Cloudflare ने AAAA रिकॉर्ड का अनुरोध किया था जो डोमेन में नहीं था, तो Cloudflare ने A रिकॉर्ड के साथ उत्तर दिया, जो कि RFC त्रुटि और बेमेल है। जिसके कारण स्थानीय रिसॉल्वर ( xxxx ) को यह पसंद नहीं आया, और इसने SERVFAIL को जवाब दिया । नीचे दिए गए लॉग में यह व्यवहार स्पष्ट रूप से दिखाई देता है:

 root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @xxxx ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @xxxx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;semrushchina.cn. IN AAAA ;; Query time: 334 msec ;; SERVER: xxxx#53(xxxx) ;; WHEN: Tue Aug 14 23:38:50 CST 2018 ;; MSG SIZE rcvd: 44 root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;semrushchina.cn. IN AAAA ;; ANSWER SECTION: semrushchina.cn. 300 IN A 220.170.186.192 ;; Query time: 185 msec ;; SERVER: 173.245.58.105#53(173.245.58.105) ;; WHEN: Tue Aug 14 23:43:03 CST 2018 ;; MSG SIZE rcvd: 60 

हमने क्लाउडफ़ेयर बग रिपोर्ट भेजी, और उन्होंने थोड़ी देर बाद इसे ठीक कर दिया। यह दिलचस्प निकला: वर्तमान में, चीन में अभी भी कोई आईपीवी 6 समर्थन नहीं है, इसलिए क्लाउडएफ़एएएए रिकॉर्ड के अनुरोध के जवाब में अपना आईपीवी 6 पता नहीं दे सका। अंत में, सब कुछ तय किया गया था ताकि चीन के लिए Cloudflare NODATA को ऐसे अनुरोधों का जवाब देना शुरू कर दे।

इसलिए, कैचपॉइंट परीक्षणों में DNS त्रुटियां तेजी से कम हुईं, लेकिन अंत तक नहीं। टाइमआउट भी गायब नहीं हुआ:

और हमने दूसरा उपाय ढूंढना शुरू किया।

अगले भाग में मैं बताऊंगा कि कैसे हमने चीनी अलीबाबा क्लाउड का परीक्षण किया, कैसे थोड़े "जादू" नग्नेक्स की मदद से हम जल्दी से PoC (प्रूफ ऑफ कॉन्सेप्ट) समाधान बना पाए, हमने मल्टी-क्लाउड समाधान कैसे बनाए, जिनमें से एक ने अंततः बहुत मदद की। चीन से सेवा को गति।

देखते रहो!

सभी भागों

भाग २
भाग 3