🥇हमने चीन की महान फ़ायरवॉल को कैसे तोड़ा (भाग 1)

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

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

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

चीनी इंटरनेट की समस्याएं

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

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

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

इन अफवाहों के बारे में हम निम्नलिखित बातें जान पाए:

गूगल, फेसबुक, ट्विटर और अन्य समान सेवाएं वास्तव में अवरुद्ध हैं (आपका KO), लेकिन गूगल के कई तकनीकी डोमेन, उदाहरण के लिए, प्रतिबंधित नहीं हैं और काम करते हैं (वही gstatic.com)। इससे निष्कर्ष यह निकलता है: आपको गूगल और अन्य अवरुद्ध संसाधनों को बिना सोचे-समझे समाप्त नहीं कर देना चाहिए।
सीमा पार करने वाला कोई भी यातायात वास्तव में समय में गंभीर देरी जोड़ता है। दोनों परिणाम देखिये। एक साइट, एक पेज, सरल GET कर्लॐ. पहला माप चीन से ही लिया गया (सुंदर शहर शेन्ज़ेन से)। दूसरा माप हांगकांग के बाहर से है (इसके पास संप्रभुता है और इसके और दुनिया के बीच कोई फ़ायरवॉल नहीं है)। सीधी रेखा में शहरों के बीच की दूरी लगभग 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

पर ध्यान दें समय_कनेक्ट. और कुल मिलाकर, आप परिणाम देख सकते हैं: फ़ायरवॉल 4 अतिरिक्त सेकंड जोड़ता है, जो बहुत लंबा है।

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

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

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

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

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

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

जो तस्वीर उभर कर आती है वह सचमुच “उत्कृष्ट” है।

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

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

हमने इसकी शुरुआत की ICP-लाइसेंस.

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

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

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

डोमेन के लिए आईसीपी लाइसेंस प्राप्त करने के बाद, हम विशिष्ट तकनीकी विचारों और समाधानों को लाने और उन्हें क्रियान्वित करने में सक्षम हुए।

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

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

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

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

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

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

डीएनएस परीक्षण,
वेब परीक्षण (ब्राउज़र, सरल GET/POST, मोबाइल क्लाइंट इम्यूलेशन, आदि),
लेन-देन संबंधी जाँच (जैसे लॉगिन),
एपीआई परीक्षण,
पिंग, ट्रेसरूट, एनटीपी, आदि.

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

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

तदनुसार, ये सभी मीट्रिक आपको परिवर्तन देखने और यह समझने में मदद करने के लिए बहुत अच्छे हैं कि क्या चीजें बेहतर हुई हैं। हम मुख्य रूप से देख रहे थे प्रतिक्रिया, वेबपेज प्रतिक्रिया, माध्यिका, 75 और 95 प्रतिशतक.

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

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

क्लाउडफ्लेयर चाइना नेटवर्क

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

इस परीक्षण बेंच का आरेख नीचे प्रस्तुत किया गया है।

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

हमने ब्राउज़र परीक्षण चलाये और हमें यह मिला:

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

अपटाइम: 86.6
माध्यिका: 18s
75वाँ प्रतिशतक: 29.3s
95वाँ प्रतिशतक: 60s

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

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

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

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

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

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

हमने इन त्रुटियों को डीबग करना शुरू किया खुदाई और पाया कि पहली बार पता सही ढंग से निर्धारित किया गया है, लेकिन जब हम दूसरी बार अनुरोध करते हैं तो हमें हर बार पता सही मिलता है सर्वफेल и नहीं मिला. यह अचानक क्यों हुआ?

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)

क्लाउडफ्लेयर के 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-रिकॉर्डिंग.

यह पता चला कि क्लाउडफ्लेयर का अनुरोध करते समय АААА- एक रिकॉर्ड जो डोमेन में मौजूद नहीं है, क्लाउडफ्लेयर ने जवाब दिया А-रिकॉर्ड, जो एक त्रुटि है और RFC के अनुरूप नहीं है। स्थानीय रिज़ॉल्वर (XXX) उसे यह पसंद नहीं आया, और उसने जवाब दिया सर्वफेल. यह व्यवहार नीचे दिए गए लॉग में स्पष्ट रूप से दिखाई देता है:

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; 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: x.x.x.x#53(x.x.x.x)
;; 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

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

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

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

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

बने रहें!