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

हाय!

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

В पिछला हिस्सा मैंने कहा था:

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

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

अलीबाबा क्लाउड

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

आईपीएसईसी

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

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

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

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

सुरंगों के लिए विलंबता इस प्रकार निकली:
अली सीएन-शेन्ज़ेन <-> जीसीपी एशिया-पूर्व 1 - 24 एमएस
अली सीएन-शेन्ज़ेन <-> जीसीपी यूएस-ईस्ट4 - 200 एमएस

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

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

समाधान
उपरिकाल
मंझला
75 प्रतिशत
95 प्रतिशत

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

यह एक समाधान से प्राप्त डेटा है जो आईपीएसईसी सुरंग का उपयोग करता है एशिया-पूर्व1. us-east4 के माध्यम से परिणाम बदतर थे, और अधिक त्रुटियां थीं, इसलिए मैं परिणाम नहीं दूंगा।

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

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

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

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

• sso.semrush.com से ऐसे और ऐसे js डाउनलोड करें,
• Cdn.semrush.com से सीएसएस फ़ाइलें प्राप्त करें,
• और dab.semrush.com से कुछ तस्वीरें भी लें
• और इतने पर.

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

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

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

सबफ़िल्टर

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

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

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

परिणामस्वरूप, ग्राहक को कहां से प्राप्त होगा .semrush.com, उसने प्राप्त किया .semrushchina.cn और आज्ञाकारी ढंग से हमारे निर्णय पर चले।

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

निम्नलिखित कॉन्फ़िगरेशन चीन से सभी अनुरोधों को संसाधित करता है .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;
    }
}

मैं दोहराता हूं, ये क्रॉप किए गए कॉन्फ़िगरेशन हैं।

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

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

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

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

CEN

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

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

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

यह इस प्रकार निकला:

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

समाधान
उपरिकाल
मंझला
75 प्रतिशत
95 प्रतिशत

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

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

एक संकर की तरह लगता है, है ना? आईपीएसईसी गति और सीईएन स्थिरता को मिलाएं।

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

जीएलबी

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

बिना कुछ सोचे-समझे हमने उठा लिया HTTP/HTTPS एलबी हमने अपनी वर्चुअल मशीनें GCP में सबफ़िल्टर के साथ और बैकएंड के रूप में स्थापित कीं।

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

• उपयोग करने के लिए क्लाउडफ्लेयर चाइना नेटवर्क, लेकिन इस बार ओरिजिन को वैश्विक निर्दिष्ट करना चाहिए आईपी ​​जीएलबी.
• ग्राहकों को यहां समाप्त करें सीएन-शेन्ज़ेन, और वहां से ट्रैफ़िक को सीधे प्रॉक्सी करें जीएलबी.
• चीन से सीधे जाएं जीएलबी.
• ग्राहकों को यहां समाप्त करें सीएन-शेन्ज़ेन, वहां से प्रॉक्सी तक एशिया-पूर्व1 आईपीएसईसी के माध्यम से (में) हमें-पूर्व4 सीईएन के माध्यम से), वहां से जीएलबी पर जाएं (शांति से, नीचे एक तस्वीर और स्पष्टीकरण होगा)

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

• क्लाउडफ्लेयर + जीएलबी

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

• अली + जीएलबी

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

• केवल जीएलबी

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

• शेन्ज़ेन -> (सीईएन/आईपीएसईसी) -> प्रॉक्सी -> जीएलबी

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

• सीईएन से स्थिरता और गारंटीकृत एसएलए
• आईपीएसईसी से उच्च गति
• Google का "तेज" नेटवर्क और इसका एनीकास्ट।

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

फिर दोनों छोर से यातायात को निर्देशित किया गया एनीकास्ट आईपी जीएलबी, यानी, Google की उपस्थिति के निकटतम बिंदु तक, और अपने नेटवर्क के माध्यम से इस क्षेत्र में चला गया हमें-पूर्व4 GCP में, जिसमें प्रतिस्थापन वर्चुअल मशीनें थीं (nginx में सबफ़िल्टर के साथ)।

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

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

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

समाधान
उपरिकाल
मंझला
75 प्रतिशत
95 प्रतिशत

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

सीईएन/आईपीसेक + जीएलबी
99.79
13s
16s
25s

CDN

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

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

स्रोत: www.habr.com