हामीले चीनको ग्रेट फायरवाल कसरी तोड्यौं (भाग १)

नमस्ते!

निकिता फेरि तपाईसँग छ, कम्पनीको सिस्टम इन्जिनियर SEMrush। र यस लेखको साथ म कसरी हामी एक workaround समाधान संग आएका बारे कथा जारी राख्छु चिनियाँ फायरवाल हाम्रो सेवा semrush.com को लागी।

В अघिल्लो भाग मैले भने:

• निर्णय पछि के समस्याहरू उत्पन्न हुन्छन् "हामीले हाम्रो सेवा चीनमा काम गर्न आवश्यक छ"
• चिनियाँ इन्टरनेटमा कस्ता समस्याहरू छन्?
• तपाईलाई ICP लाइसेन्स किन चाहिन्छ?
• कसरी र किन हामीले हाम्रो टेस्टबेडहरू क्याचपोइन्टसँग परीक्षण गर्ने निर्णय गर्यौं
• क्लाउडफ्लेयर चाइना नेटवर्कमा आधारित हाम्रो पहिलो समाधानको नतिजा के थियो
• हामीले क्लाउडफ्लेयर DNS मा बग कसरी फेला पार्‍यौं

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

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

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

IPsec

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

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

एकै समयमा, हामीले एक परीक्षण क्षेत्र राख्यौं अलीबाबा क्लाउड DNS। एनएस अलीलाई क्षेत्र प्रत्यायोजन गरेपछि, रिजोल्युसन समय 470 ms बाट घट्यो 50 सांसद। यसअघि यो जोन क्लाउडल्फेयरमा पनि थियो ।

सुरुङसँग समानान्तर एशिया-पूर्व १ सेन्जेनबाट सिधै अर्को सुरुङ खडा गरियो us-east4। त्यहाँ तिनीहरूले थप प्रोक्सी भर्चुअल मेसिनहरू सिर्जना गरे र कुकीहरू वा DNS प्रयोग गरेर परीक्षण ट्राफिक राउटिंग, दुवै समाधानहरू परीक्षण गर्न थाले। परीक्षण बेंच निम्न चित्रमा योजनाबद्ध रूपमा वर्णन गरिएको छ:

टनेलहरूको लागि विलम्बता निम्न रूपमा बाहिरियो:
अली cn-shenzhen <—> GCP asia-east1 — 24ms
अली cn-shenzhen <—> GCP us-east4 — 200ms

क्याचपोइन्ट ब्राउजर परीक्षणहरूले उत्कृष्ट सुधारको रिपोर्ट गरे।

दुई समाधानहरूको लागि परीक्षण परिणामहरू तुलना गर्नुहोस्:

निर्णय
Uptime
मेडियन
७५ प्रतिशत
७५ प्रतिशत

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

यो एक समाधानबाट डाटा हो जसले IPSEC टनेल मार्फत प्रयोग गर्दछ एशिया-पूर्व १। us-east4 मार्फत नतिजाहरू खराब थिए, र त्यहाँ धेरै त्रुटिहरू थिए, त्यसैले म परिणामहरू दिने छैन।

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

सामान्यतया, नतिजाहरू खराब छैनन्, तथापि, semrush.com मा 8.8 सेकेन्ड, र 75 पर्सेन्टाइल 9.4s (एउटै परीक्षणमा) छ।
र अगाडि बढ्नु अघि, म छोटो गीतात्मक विषयवस्तु बनाउन चाहन्छु।

लिरिकल डिग्रेशन

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

• sso.semrush.com बाट यस्तो र त्यस्ता js डाउनलोड गर्नुहोस्,
• cdn.semrush.com बाट CSS फाइलहरू प्राप्त गर्नुहोस्,
• र dab.semrush.com बाट केही तस्विरहरू पनि लिनुहोस्
• र यति मा।

ब्राउजरले यी स्रोतहरूको लागि "बाह्य" इन्टरनेटमा जान थाल्छ, प्रत्येक पटक फायरवाल मार्फत जान्छ जुन प्रतिक्रिया समय खान्छ।

तर पृष्ठमा कुनै स्रोतहरू नभएको बेला अघिल्लो परीक्षणले परिणामहरू देखाउँछ semrush.comमात्र semrushchina.cn, र *.semrushchina.cn ले शेन्जेनमा भर्चुअल मेसिनको ठेगानामा समाधान गर्छ त्यसपछि सुरुङमा जानको लागि।

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

सबफिल्टर

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

सबफिल्टर nginx मा एकदम सरल मोड्युल हो जसले तपाईंलाई प्रतिक्रिया शरीरको एउटा रेखालाई अर्को रेखामा परिवर्तन गर्न अनुमति दिन्छ। त्यसैले हामीले सबै घटनाहरू परिवर्तन गर्यौं semrush.com मा semrushchina.cn सबै जवाफहरूमा।

र... यसले काम गरेन किनभने हामीले ब्याकएन्डबाट कम्प्रेस गरिएको सामग्री प्राप्त गर्यौं, त्यसैले सबफिल्टरले आवश्यक लाइन फेला पारेन। मैले nginx मा अर्को स्थानीय सर्भर थप्नुपर्‍यो, जसले प्रतिक्रियालाई कम्प्रेस गर्यो र यसलाई अर्को स्थानीय सर्भरमा पास गर्‍यो, जुन पहिले नै स्ट्रिङलाई प्रतिस्थापन गर्न, यसलाई कम्प्रेस गर्न र चेनको अर्को प्रोक्सी सर्भरमा पठाउन व्यस्त थियो।

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

यद्यपि, यो केवल डोमेनलाई एक तरिका परिवर्तन गर्न पर्याप्त छैन, किनभने ब्याकएन्डहरूले अझै पनि ग्राहकबाट पछिका अनुरोधहरूमा semrush.com को अपेक्षा गर्दछ। तदनुसार, एउटै सर्भरमा जहाँ एकतर्फी प्रतिस्थापन गरिन्छ, एक साधारण नियमित अभिव्यक्ति प्रयोग गरेर हामीले अनुरोधबाट सबडोमेन प्राप्त गर्छौं, र त्यसपछि हामी गर्छौं। proxy_pass चर संग $host, मा प्रदर्शन गरिएको छ $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;
    }
}

म दोहोर्याउँछु, यी क्रप गरिएका कन्फिगहरू हुन्।

त्यस्तै। यो जटिल देखिन सक्छ, तर यो शब्दहरूमा छ। वास्तवमा, सबै चीज भाप गरिएको शलजम भन्दा सरल छ :)

विषयवस्तुको अन्त्य

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

तिनीहरूले उठाए। सुरुङहरू विभिन्न समयमा असफल हुन थाले, तर फेलओभरले हाम्रो लागि nginx मा अपस्ट्रीम स्तरमा राम्रो काम गर्यो। तर त्यसपछि सुरुङहरू एकै समयमा खस्न थाले 🙂 र 502 र 504 फेरि सुरु भयो। अपटाइम बिग्रन थाल्यो, त्यसैले हामीले विकल्पमा काम गर्न थाल्यौं। अलिबाबा CEN (क्लाउड इन्टरप्राइज नेटवर्क)।

CEN

CEN - यो Alibaba क्लाउड भित्र विभिन्न क्षेत्रहरु बाट दुई VPCs को जडान हो, त्यो हो, तपाईले क्लाउड भित्र कुनै पनि क्षेत्रहरु को निजी नेटवर्कहरु एक अर्का संग जोड्न सक्नुहुन्छ। र सबैभन्दा महत्त्वपूर्ण: यो च्यानल एकदम कडा छ SLA। यो गति र अपटाइम दुवै मा धेरै स्थिर छ। तर यो कहिल्यै सरल छैन:

• यदि तपाईं चिनियाँ नागरिक वा कानूनी संस्था हुनुहुन्न भने यो प्राप्त गर्न धेरै गाह्रो छ,
• तपाईंले च्यानल क्षमताको प्रत्येक मेगाबिटको लागि तिर्नुपर्छ।

जडान गर्ने अवसर पाएको छ मुख्यभूमि चीन и विदेशी, हामीले दुई अली क्षेत्रहरू बीच एक CEN सिर्जना गर्यौं: cn-शेन्जेन и us-east-1 (हाम्रो नजिकको बिन्दु-पूर्व ४)। अली मा us-east-1 अर्को भर्चुअल मेसिन उठायो ताकि त्यहाँ अर्को छ हप.

यो यस्तो निस्कियो:

ब्राउजर परीक्षण परिणामहरू तल छन्:

निर्णय
Uptime
मेडियन
७५ प्रतिशत
७५ प्रतिशत

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

प्रदर्शन IPSEC भन्दा थोरै राम्रो छ। तर IPSEC मार्फत तपाईले 100 Mbit/s को गतिमा र CEN मार्फत मात्र 5 Mbit/s र अधिकको गतिमा डाउनलोड गर्न सक्नुहुन्छ।

हाइब्रिड जस्तो लाग्छ, हैन? IPSEC गति र CEN स्थिरता जोड्नुहोस्।

यो हामीले IPSEC सुरुङ असफल भएको अवस्थामा IPSEC र CEN दुबै मार्फत ट्राफिकलाई अनुमति दिँदै गरेका छौं। अपटाइम धेरै उच्च भएको छ, तर साइट लोडिङ गतिले अझै धेरै वांछित हुन छोड्छ। त्यसपछि मैले सबै सर्किटहरू कोरें जुन हामीले पहिले नै प्रयोग गरेका थियौं र परीक्षण गरेका थियौं, र यस सर्किटमा अलि बढी GCP थप्ने प्रयास गर्ने निर्णय गरें, अर्थात्। टोपी.

टोपी

टोपी हो ग्लोबल लोड ब्यालेन्सर (वा गुगल क्लाउड लोड ब्यालेन्सर)। यसको हाम्रो लागि महत्त्वपूर्ण फाइदा छ: CDN को सन्दर्भमा यो छ anycast IP, जसले तपाईंलाई ग्राहकको नजिकको डेटा केन्द्रमा ट्राफिकलाई रुट गर्न अनुमति दिन्छ, ताकि ट्राफिक चाँडै गुगलको द्रुत नेटवर्कमा जान्छ र कम "नियमित" इन्टरनेट मार्फत जान्छ।

दुई पटक सोच्नै नदिई उठ्यौं HTTP/HTTPS LB हामीले GCP मा सबफिल्टर र ब्याकइन्डको रूपमा हाम्रा भर्चुअल मेसिनहरू स्थापना गर्यौं।

त्यहाँ धेरै योजनाहरू थिए:

• Использовать Cloudflare चीन नेटवर्क, तर यस पटक उत्पत्तिले विश्वव्यापी निर्दिष्ट गर्नुपर्छ IP GLB.
• मा ग्राहकहरू समाप्त गर्नुहोस् cn-शेन्जेन, र त्यहाँबाट सिधै ट्राफिक प्रोक्सी गर्नुहोस् टोपी.
• चीनबाट सिधै जानुहोस् टोपी.
• मा ग्राहकहरू समाप्त गर्नुहोस् cn-शेन्जेन, त्यहाँबाट प्रोक्सी सम्म एशिया-पूर्व १ IPSEC मार्फत (मा us-east4 CEN मार्फत), त्यहाँबाट GLB मा जानुहोस् (शान्त रूपमा, तल एक तस्वीर र व्याख्या हुनेछ)

हामीले यी सबै विकल्पहरू र धेरै हाइब्रिडहरू परीक्षण गर्यौं:

• Cloudflare + GLB

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

• अली + GLB

यो योजनाले हामीलाई अपटाइमको सन्दर्भमा पनि उपयुक्त बनाएन, किनभने GLB प्रायः स्वीकार्य समय वा टाइमआउटमा जडान हुन नसक्ने कारणले अपस्ट्रीमबाट बाहिर गयो, किनभने चीन भित्रको सर्भरको लागि, GLB ठेगाना बाहिर रहन्छ, र त्यसकारण पछि। चिनियाँ फायरवाल। जादू भएन।

• GLB मात्र

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

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

यहाँ हामीले सबै समाधानहरूको उत्तम प्रयोग गर्ने निर्णय गर्यौं:

• CEN बाट स्थिरता र ग्यारेन्टी SLA
• IPSEC बाट उच्च गति
• गुगलको "द्रुत" नेटवर्क र यसको कुनै पनि कास्ट।

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

त्यसपछि दुबै छेउबाट ट्राफिकलाई निर्देशित गरियो anycast IP GLB, त्यो हो, गुगलको उपस्थितिको नजिकको बिन्दुमा, र यसको नेटवर्कहरू मार्फत क्षेत्रमा गयो us-east4 GCP मा, जसमा प्रतिस्थापन भर्चुअल मेसिनहरू थिए (nginx मा सबफिल्टरको साथ)।

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

माथिको सूचीबाट चौथो समाधान लागू गरेर, हामीले हामीले चाहेको कुरा हासिल गर्यौं र त्यो समयमा व्यवसायले हामीलाई के चाहिन्छ।

अघिल्लोको तुलनामा नयाँ समाधानको लागि ब्राउजर परीक्षण परिणामहरू:

निर्णय
Uptime
मेडियन
७५ प्रतिशत
७५ प्रतिशत

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

CDN

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

र म यस बारे अर्को, अन्तिम भागमा बताउनेछु :)

स्रोत: www.habr.com