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

नमस्ते!

निकिता फिर से आपके साथ है - SEMrush का एक सिस्टम इंजीनियर। और इस लेख के साथ, मैं अपनी सेवा semrush.com के लिए चीनी फ़ायरवॉल को दरकिनार करने के समाधान के साथ कैसे आया, इसकी कहानी जारी रखता हूं।

पिछले भाग में मैंने बताया:

• एक निर्णय के बाद क्या समस्याएं आती हैं "हमें चीन में अपनी सेवा कार्य करने की आवश्यकता है"
• चीनी इंटरनेट में क्या समस्याएं हैं
• मुझे ICP लाइसेंस की आवश्यकता क्यों है
• कैसे और क्यों हमने कैचपॉइंट का उपयोग करके अपने परीक्षण बेंचों का परीक्षण करने का निर्णय लिया
• Cloudflare China Network पर आधारित हमारे पहले समाधान का परिणाम क्या था
• डीएनएस क्लाउडफेयर में हमें एक बग कैसे मिला

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

अलीबाबा बादल

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

IPSEC

भूगोल से शुरुआत की। चूंकि हमारी परीक्षण साइट Google क्लाउड पर स्थित थी, इसलिए हमें अलीबाबा क्लाउड को GCP के साथ "लिंक" करना था, इसलिए हमने उन स्थानों की सूची खोली जहां Google मौजूद है। उस समय, उनके पास हांगकांग में अपना स्वयं का डेटा केंद्र नहीं था।
निकटतम क्षेत्र एशिया-पूर्व 1 (ताइवान) था। अली ने मुख्य भूमि चीन के ताइवान के निकटतम क्षेत्र के रूप में cn-shenzhen (शेन्ज़ेन) किया था।

टेराफॉर्म का उपयोग करते हुए , उन्होंने जीसीपी और अली में पूरे बुनियादी ढांचे का वर्णन किया और उठाया। बादलों के बीच 100 एमबीपीएस सुरंग लगभग तुरंत बढ़ी। शेन्ज़ेन और ताइवान की ओर से उन्होंने प्रॉक्सी वर्चुअल मशीनों का निर्माण किया। शेन्ज़ेन में, उपयोगकर्ता ट्रैफ़िक को ताइवान के लिए एक सुरंग के माध्यम से समाप्‍त किया गया है, और वहां से यह सीधे हमारी सेवा के बाहरी आईपी पर जाता है जो हमें-पूर्व (यूएसए के पूर्वी तट) में देता है। 24ms सुरंग पर वर्चुअल के बीच पिंग, जो इतना बुरा नहीं है।

उसी समय, हमने अलीबाबा क्लाउड डीएनएस में एक परीक्षण क्षेत्र रखा। एनएस अली को क्षेत्र सौंपने के बाद, संकल्प समय 470 एमएस से घटकर 50 एमएस हो गया । इससे पहले, यह क्षेत्र क्लाउडफ़ेयर पर भी था।

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

सुरंगों के लिए विलंबता इस प्रकार है:
अली सेन-शेनजेन <-> जीसीपी एशिया-ईस्ट 1 - 24ms
अली cn-shenzhen <-> GCP us-east4 - 200ms

कैचपॉइंट ब्राउज़र परीक्षणों ने उत्कृष्ट प्रदर्शन सुधारों की सूचना दी है।

दो परिणामों के लिए परीक्षण परिणामों की तुलना करें:

यह IPSEC टनल का उपयोग करके asia-east1 के माध्यम से समाधान डेटा है। हमारे माध्यम से East4, परिणाम बदतर थे, और अधिक त्रुटियां थीं, इसलिए मैं परिणाम नहीं दूंगा।

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

सामान्य तौर पर, परिणाम खराब नहीं होते हैं, हालांकि, semrush.com में 8.8 का औसत और 9.4 का 75 प्रतिशत (एक ही परीक्षण पर) है।
और आगे बढ़ने से पहले, मैं एक विषयांतर करना चाहूंगा।

गीतात्मक विषयांतर

उपयोगकर्ता www.semrushchina.cn साइट पर जाता है , जो "डीएनएस" चीनी डीएनएस सर्वर के माध्यम से हल होता है, HTTP अनुरोध हमारे त्वरित समाधान के माध्यम से जाता है। उत्तर को उसी तरह से लौटाया जाता है, लेकिन सभी JS स्क्रिप्ट्स, HTML पेजों और वेब पेज के अन्य तत्वों में, डोमेन semrush.com अतिरिक्त संसाधनों के लिए इंगित किया जाता है जिन्हें पेज को रेंडर करते समय लोड किया जाना चाहिए। यही है, ग्राहक "मुख्य" एक रिकॉर्ड www.semrushchina.c n को हल करता है और तेजी से सुरंग में जाता है, जल्दी से एक प्रतिक्रिया प्राप्त करता है - एक HTML पृष्ठ जो बताता है:

• ऐसे और ऐसे js sso.semrush.com से डाउनलोड करें,
• Cdn.semrush.com से CSS फाइलें लें,
• और dab.semrush.com से अधिक तस्वीरें लें
• और इसी तरह।

ब्राउज़र इन संसाधनों के लिए "बाहरी" इंटरनेट पर जाना शुरू करता है, हर बार प्रतिक्रिया समय को भुनाने वाले फ़ायरवॉल से गुजरता है।

लेकिन पिछले परीक्षण में, परिणाम प्रस्तुत किए जाते हैं जब पृष्ठ पर कोई semrush.com संसाधन नहीं होते हैं, केवल semrushchina.cn , और * .semrushchina.cn को बाद में सुरंग में जाने के लिए शेन्ज़ेन में वर्चुअल मशीन के पते पर हल किया जाता है।

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

Subfilter

इस समस्या के सामने आने के तुरंत बाद समाधान का जन्म हुआ। हमें PoC (प्रूफ ऑफ कॉन्सेप्ट) की जरूरत थी, जो कि हमारे फ़ायरवॉल समाधान वास्तव में अच्छी तरह से काम करते हैं। ऐसा करने के लिए, आपको इस समाधान में साइट के सभी ट्रैफ़िक को अधिकतम करना होगा। और हमने नगनेक्स में सबफ़िल्टर लगाया।

सबफिल्टर नेग्नेक्स में एक काफी सरल मॉड्यूल है जो आपको एक लाइन को दूसरी लाइन के जवाब के शरीर में बदलने की अनुमति देता है। इसलिए हमने सभी उत्तरों में semrush.com की सभी घटनाओं को semrushchina.cn में बदल दिया।

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

नतीजतन, जहां ग्राहक को <subdomain> .semrush.com प्राप्त होगा, उसे <subdomain> .semrushchina.cn प्राप्त होगा और आज्ञाकारी रूप से हमारे निर्णय से गुजरेगा ।

हालाँकि, यह केवल एक दिशा में डोमेन बदलने के लिए पर्याप्त नहीं है, क्योंकि बैकएंड अभी भी क्लाइंट से बाद के अनुरोधों में semrush.com की अपेक्षा करते हैं। तदनुसार, उसी सर्वर पर जहां प्रतिस्थापन एक दिशा में किया जाता है, एक सरल नियमित अभिव्यक्ति का उपयोग करके हम अनुरोध से उपडोमेन प्राप्त करते हैं, और फिर $ subdomain.semrush.com में $ होस्ट चर सेट के साथ प्रॉक्सी_पास करते हैं। यह भ्रामक लग सकता है, लेकिन यह काम करता है। और यह अच्छी तरह से काम करता है। अलग-अलग तर्क के लिए अलग-अलग तर्क की आवश्यकता होती है, वे बस अपने सर्वर ब्लॉक बनाते हैं और एक अलग कॉन्फ़िगरेशन बनाते हैं। नीचे इस योजना की स्पष्टता और प्रदर्शन के लिए छोटे नगीन विन्यास हैं।

निम्नलिखित विन्यास चीन से .semrushchina.cn के लिए सभी अनुरोधों को संसाधित करता है :

listen 80; server_name ~^(?<subdomain>[\w\-]+)\.semrushchina.cn$; sub_filter '.semrush.com' '.semrushchina.cn'; sub_filter_last_modified on; sub_filter_once off; sub_filter_types *; gzip on; gzip_proxied any; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; location / { proxy_pass http://127.0.0.1:8083; proxy_set_header Accept-Encoding ""; proxy_set_header Host $subdomain.semrush.com; proxy_set_header X-Accept-Encoding $http_accept_encoding; } } 

यह कॉन्फिगरेशन पोर्ट 83 पर लोकलहोस्ट को दिया गया है, और वहाँ यह निम्नलिखित कॉन्फिगर का इंतजार करता है:

  listen 127.0.0.1:8083; server_name *.semrush.com; location / { resolver 8.8.8.8 ipv6=off; gunzip on; proxy_pass https://$host; proxy_set_header Accept-Encoding gzip; } } 

फिर से, ये फसली विन्यास हैं।

कुछ इस तरह। यह जटिल लग सकता है, लेकिन यह शब्दों में है। वास्तव में, सब कुछ धमाकेदार शलजम से आसान है :)

गेय विषयांतर का अंत

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

उठा लिया। सुरंग अलग-अलग समय पर गिरना शुरू हुईं, लेकिन हमने नगीनों में ऊपर की तरफ एक ठीक-ठीक विफलता पाई। लेकिन फिर सुरंग लगभग उसी समय गिरना शुरू हुई :) और फिर से, 502 और 504। अपटाइम बिगड़ना शुरू हो गया, इसलिए हमने अलीबाबा सेन (क्लाउड एंटरप्राइज नेटवर्क) के साथ विकल्प पर काम करना शुरू कर दिया।

केंद्र

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

• यह बहुत मुश्किल है अगर आप चीनी नागरिक या कानूनी संस्था नहीं हैं,
• आपको बैंडविड्थ के प्रत्येक मेगाबिट के लिए भुगतान करने की आवश्यकता है।

मेनलैंड चाइना और ओवरसीज को जोड़ने का अवसर मिलने के बाद, हमने दो अली क्षेत्रों के बीच एक CEN बनाया: cn-shenzhen और us-east-1 ( हमारे-ईस्ट 4 का निकटतम बिंदु)। अली us-east-1 में, उन्होंने एक और वर्चुअल मशीन उठाई जिसमें एक और हॉप है ।

यह इस तरह निकला:

नीचे ब्राउज़र परीक्षण के परिणाम:

IPSEC की तुलना में प्रदर्शन थोड़ा बेहतर है। लेकिन IPSEC के माध्यम से आप संभावित रूप से 100 एमबीपीएस की गति से डाउनलोड कर सकते हैं, और सीईएन के माध्यम से केवल 5 एमबीपीएस की गति से और अधिक महंगा हो सकता है।

हाइब्रिड भीख, सही? IPSEC गति और CEN स्थिरता का मिश्रण करें।

IPSEC सुरंग दुर्घटना की स्थिति में IPSEC और CEN दोनों के माध्यम से ट्रैफ़िक की अनुमति देकर हमने यही किया। अपटाइम बहुत अधिक हो गया है, लेकिन साइट की लोडिंग गति खराब है। फिर मैंने उन सभी योजनाओं को आकर्षित किया, जिनका हमने पहले ही उपयोग किया था और परीक्षण किया था, और इस योजना को थोड़ा और GCP जोड़ने का प्रयास करने का निर्णय लिया, अर्थात् GLB ।

GLB

GLB ग्लोबल लोड बैलेंसर (या Google क्लाउड लोड बैलेंसर) है। इसका हमारे लिए एक महत्वपूर्ण लाभ है: सीडीएन के संदर्भ में इसमें कोई भी आईपी ​​है , जो आपको क्लाइंट के निकटतम डेटा सेंटर में ट्रैफ़िक को रूट करने की अनुमति देता है, जिसकी बदौलत "सामान्य" इंटरनेट के माध्यम से ट्रैफ़िक Google नेटवर्क पर तेज़ी से और कम गति से प्राप्त होता है।

दो बार सोचने के बिना, हमने HTTP / HTTPS LB को GCP तक बढ़ाया और अपनी वर्चुअल मशीनों को सबफ़िल्टर बैकेंड के साथ लगाया।

कई योजनाएं थीं:

• Cloudflare China Network का उपयोग करें, लेकिन इस बार उत्पत्ति वैश्विक GLB IP निर्दिष्ट करती है।
• ग्राहकों को cn-shenzhen , और वहां से प्रॉक्सी ट्रैफ़िक को तुरंत GLB में समाप्त करें।
• चीन से सीधे जीएलबी पर जाएं ।
• Cn-shenzhen में क्लाइंट्स को समाप्त करें, प्रॉक्सी से asia-east1 तक IPSEC के माध्यम से ( us-east4 में CEN के माध्यम से), वहां से GLB पर जाएं (शांति से, नीचे एक तस्वीर और स्पष्टीकरण होगा)

हमने इन सभी विकल्पों और कुछ और हाइब्रिड लोगों का परीक्षण किया:

• Cloudflare + GLB

यह योजना हमें अपटाइम और DNS त्रुटियों के लिए उपयुक्त नहीं लगी। लेकिन सीएफ के हिस्से पर बग को ठीक करने से पहले परीक्षण किया गया था, शायद अब यह बेहतर है (हालांकि, यह HTTP टाइमआउट को बाहर नहीं करता है)।

• अली + जीएलबी

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

• केवल जीएलबी

पिछले एक के समान एक संस्करण, केवल यह चीन में ही सर्वर का उपयोग नहीं करता था: यातायात तुरंत जीएलबी (डीएनएस रिकॉर्ड बदल गया) में चला गया। तदनुसार, परिणाम संतोषजनक नहीं थे, क्योंकि सामान्य इंटरनेट प्रदाताओं की सेवाओं का उपयोग करने वाले सामान्य चीनी ग्राहकों के पास अली क्लाउड की तुलना में फ़ायरवॉल से गुजरने के साथ बहुत बदतर स्थिति है।

• शेन्ज़ेन -> (CEN / IPSEC) -> प्रॉक्सी -> GLB

यहां हमने सभी समाधानों में से सर्वश्रेष्ठ का उपयोग करने का निर्णय लिया:

• CEN से स्थिरता और गारंटीकृत SLA
• IPSEC से उच्च गति
• Google का "तेज़" नेटवर्क और उसका कोई भी प्रसारण।

योजना कुछ इस तरह दिखती है: ch-shenzhen में एक वर्चुअल मशीन पर उपयोगकर्ता ट्रैफ़िक को समाप्त किया जाता है। Nginx अपस्ट्रीम सेटिंग्स को कॉन्फ़िगर किया गया है, जिनमें से कुछ IPSEC सुरंग के दूसरे छोर पर स्थित निजी IP सर्वर को संदर्भित करते हैं, और कुछ अपस्ट्रीम कनेक्शन CEN के दूसरी तरफ निजी सर्वर पते पर हैं। IPSEC को GCP में एशिया-ईस्ट 1 क्षेत्र में कॉन्फ़िगर किया गया था (यह समाधान निर्मित होने के समय चीन का निकटतम क्षेत्र था। अब GCP की हांगकांग में भी उपस्थिति है)। CEN - अली क्लाउड में us-east1 क्षेत्र में।

इसके अलावा, दोनों सिरों से ट्रैफ़िक को किसी भी IP उपस्थिति के लिए निर्देशित किया गया था, यानी निकटतम Google उपस्थिति बिंदु पर, और इसके नेटवर्क के माध्यम से GCP में us-east4 क्षेत्र में चला गया, जिसमें स्थानापन्न वर्चुअल मशीन (nginx में सबफ़िल्टर के साथ) थे।

इस हाइब्रिड समाधान, जैसा कि हमने उम्मीद की थी, हमें प्रत्येक तकनीक का लाभ उठाने की अनुमति दी। सामान्य तौर पर, ट्रैफ़िक तेज़ IPSEC से होकर जाता है, लेकिन यदि समस्याएँ शुरू होती हैं, तो हम जल्दी और कई मिनटों के लिए इन सर्वरों को अपस्ट्रीम से बाहर फेंक देते हैं और CEN के माध्यम से ट्रैफ़िक को स्थिर होने तक ही भेजते हैं।

ऊपर दी गई सूची से 4 वें समाधान को लागू करने के बाद, हमने वह हासिल कर लिया जो हम चाहते थे और उस समय हमारे लिए किस व्यवसाय की मांग थी।

पिछले वाले की तुलना में नए समाधान के लिए ब्राउज़र परीक्षण परिणाम:

CDN

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

और मैं आपको इसके बारे में अगले, अंतिम भाग में बताऊंगा :)

सभी भागों

भाग 1
भाग 3