आम्ही ग्रेट चायनीज फायरवॉल कसे तोडले (भाग 2)

हाय

निकिता पुन्हा तुमच्यासोबत आहे, कंपनीची सिस्टम इंजिनिअर आहे SEMrush. आणि या लेखासह आम्ही एक वर्कअराउंड सोल्यूशन कसे शोधले याबद्दल मी कथा सुरू ठेवतो चीनी फायरवॉल आमच्या सेवेसाठी semrush.com.

В मागील भाग मी बोललो:

• निर्णय घेतल्यानंतर कोणत्या समस्या उद्भवतात "आम्हाला आमची सेवा चीनमध्ये कार्य करण्याची आवश्यकता आहे"
• चीनी इंटरनेटमध्ये कोणत्या समस्या आहेत?
• तुम्हाला ICP परवान्याची गरज का आहे?
• आम्ही आमच्या टेस्टबेड्सची चाचणी कॅचपॉईंटसह कशी आणि का करण्याचा निर्णय घेतला
• क्लाउडफ्लेअर चायना नेटवर्कवर आधारित आमच्या पहिल्या समाधानाचा परिणाम काय होता
• Cloudflare DNS मध्ये आम्हाला बग कसा सापडला

हा भाग माझ्या मते सर्वात मनोरंजक आहे, कारण तो स्टेजिंगच्या विशिष्ट तांत्रिक अंमलबजावणीवर लक्ष केंद्रित करतो. आणि आम्ही सुरू करू, किंवा त्याऐवजी सुरू ठेवू अलिबाबा क्लाउड.

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

अलिबाबा क्लाउड हा बर्‍यापैकी मोठा क्लाउड प्रदाता आहे, ज्यात सर्व सेवा आहेत ज्या त्याला प्रामाणिकपणे स्वतःला क्लाउड प्रदाता म्हणू शकतात. हे चांगले आहे की त्यांना परदेशी वापरकर्त्यांसाठी नोंदणी करण्याची संधी आहे आणि बहुतेक साइटचे इंग्रजीमध्ये भाषांतर केले आहे (चीनसाठी ही लक्झरी आहे). या क्लाउडमध्ये, तुम्ही जगातील अनेक प्रदेश, मुख्य भूप्रदेश चीन, तसेच महासागरीय आशिया (हाँगकाँग, तैवान इ.) सह काम करू शकता.

IPSEC

आम्ही भूगोलापासून सुरुवात केली. आमची चाचणी साइट Google Cloud वर स्थित असल्याने, आम्हाला GCP सह Alibaba Cloud "लिंक" करणे आवश्यक आहे, म्हणून आम्ही Google उपस्थित असलेल्या स्थानांची सूची उघडली. त्या क्षणी त्यांच्याकडे अद्याप हाँगकाँगमध्ये स्वतःचे डेटा सेंटर नव्हते.
जवळचा प्रदेश निघाला asia-east1 (तैवान). अली हा मुख्य भूप्रदेश चीनचा तैवानचा सर्वात जवळचा प्रदेश होता cn-शेन्झेन (शेन्झेन).

च्या मदतीने छत GCP आणि अली मधील संपूर्ण पायाभूत सुविधांचे वर्णन केले आणि वाढवले. ढगांमधील 100 Mbit/s चा बोगदा जवळजवळ झटपट वर गेला. शेन्झेन आणि तैवानच्या बाजूला, प्रॉक्सींग व्हर्च्युअल मशीन्स उभ्या केल्या गेल्या. शेन्झेनमध्ये, वापरकर्ता रहदारी संपुष्टात आणली जाते, एका बोगद्याद्वारे तैवानला प्रॉक्सी केली जाते आणि तेथून ते थेट आमच्या सेवेच्या बाह्य IP वर जाते us-पूर्व (यूएसए ईस्ट कोस्ट). बोगद्याद्वारे आभासी मशीन दरम्यान पिंग 24ms, जे इतके वाईट नाही.

त्याच वेळी, आम्ही एक चाचणी क्षेत्र ठेवले अलीबाबा क्लाउड DNS. एनएस अलीकडे झोन सोपवल्यानंतर, ठराव वेळ 470 एमएस वरून कमी झाला 50 मिसे. यापूर्वी हा झोन क्लाउडफेअरवरही होता.

च्या बोगद्याला समांतर asia-east1 शेन्झेन ते थेट दुसरा बोगदा उभारला us-east4. तेथे त्यांनी अधिक प्रॉक्सी व्हर्च्युअल मशीन्स तयार केल्या आणि कुकीज किंवा डीएनएस वापरून चाचणी ट्रॅफिक राउटिंग, दोन्ही उपायांची चाचणी घेण्यास सुरुवात केली. चाचणी खंडपीठ खालील आकृतीमध्ये योजनाबद्धपणे वर्णन केले आहे:

बोगद्यांसाठी विलंब खालीलप्रमाणे असल्याचे दिसून आले:
अली cn-शेन्झेन <—> GCP asia-east1 — 24ms
अली cn-shenzhen <—> GCP us-east4 — 200ms

कॅचपॉईंट ब्राउझर चाचण्यांनी उत्कृष्ट सुधारणा नोंदवली.

दोन उपायांसाठी चाचणी परिणामांची तुलना करा:

निर्णय
अपटाईम
मध्यक
75 टक्के
95 टक्के

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

हा आयपीएसईसी बोगद्याद्वारे वापरणाऱ्या सोल्यूशनचा डेटा आहे asia-east1. us-east4 द्वारे परिणाम वाईट होते, आणि अधिक त्रुटी होत्या, म्हणून मी निकाल देणार नाही.

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

सर्वसाधारणपणे, परिणाम वाईट नसतात, तथापि, semrush.com ची सरासरी 8.8s आणि 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 बोगद्यात जाण्यासाठी शेन्झेनमधील व्हर्च्युअल मशीनच्या पत्त्यावर निराकरण करते.

केवळ अशा प्रकारे, चायनीज फायरवॉल त्वरीत पार करण्यासाठी तुमच्या सोल्यूशनद्वारे सर्व संभाव्य रहदारी जास्तीत जास्त वाढवून, तुम्ही स्वीकार्य वेग आणि वेबसाइट उपलब्धता निर्देशक तसेच समाधान चाचण्यांचे प्रामाणिक परिणाम मिळवू शकता.
आम्ही हे कार्यसंघाच्या उत्पादनाच्या बाजूने एकाही कोड संपादनाशिवाय केले.

सबफिल्टर

ही समस्या समोर आल्यानंतर लगेचच उपायाचा जन्म झाला. आम्हाला गरज होती पीओसी (कल्पनेचा पुरावा) की आमचे फायरवॉल प्रवेश उपाय खरोखर चांगले कार्य करतात. हे करण्यासाठी, आपल्याला शक्य तितक्या या सोल्यूशनमध्ये सर्व साइट रहदारी लपेटणे आवश्यक आहे. आणि आम्ही अर्ज केला सबफिल्टर nginx मध्ये.

सबफिल्टर nginx मधील एक अगदी सोपे मॉड्यूल आहे जे तुम्हाला प्रतिसादाच्या मुख्य भागातील एक ओळ दुसऱ्या ओळीत बदलण्याची परवानगी देते. म्हणून आम्ही सर्व घटना बदलल्या semrush.com वर semrushchina.cn सर्व उत्तरांमध्ये.

आणि... ते कार्य करत नाही कारण आम्हाला बॅकएंड्समधून संकुचित सामग्री मिळाली, त्यामुळे सबफिल्टरला आवश्यक लाइन सापडली नाही. मला nginx मध्ये दुसरा स्थानिक सर्व्हर जोडावा लागला, ज्याने प्रतिसाद डीकंप्रेस केला आणि तो पुढील स्थानिक सर्व्हरवर पास केला, जो आधीच स्ट्रिंग बदलण्यात, संकुचित करण्यात आणि साखळीतील पुढील प्रॉक्सी सर्व्हरवर पाठवण्यात व्यस्त होता.

परिणामी, क्लायंट कोठे प्राप्त होईल .semrush.com, त्याला मिळाले .semrushchina.cn आणि आज्ञाधारकपणे आमच्या निर्णयावर चालले.

तथापि, केवळ एका मार्गाने डोमेन बदलणे पुरेसे नाही, कारण बॅकएंड्स अजूनही क्लायंटकडून पुढील विनंत्यांमध्ये semrush.com ची अपेक्षा करतात. त्यानुसार, त्याच सर्व्हरवर जिथे एकेरी बदली केली जाते, साध्या रेग्युलर एक्सप्रेशनचा वापर करून आम्हाला विनंतीवरून सबडोमेन मिळतो आणि मग आम्ही करतो proxy_pass व्हेरिएबल सह $होस्ट, मध्ये प्रदर्शित $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;
    }
}

हे कॉन्फिगरेशन प्रॉक्सी करते localhost पोर्ट 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 मधील अपस्ट्रीम स्तरावर फेलओव्हरने आमच्यासाठी चांगले काम केले. पण नंतर त्याच वेळी बोगदे पडू लागले. अलीबाबा CEN (क्लाउड एंटरप्राइझ नेटवर्क).

CEN

CEN - ही Alibaba Cloud मधील वेगवेगळ्या प्रदेशातील दोन VPC ची कनेक्टिव्हिटी आहे, म्हणजेच तुम्ही क्लाउडमधील कोणत्याही प्रदेशातील खाजगी नेटवर्क एकमेकांशी जोडू शकता. आणि सर्वात महत्त्वाचे म्हणजे: या चॅनेलमध्ये बर्‍यापैकी कठोर आहे SLA. हे वेग आणि अपटाइम दोन्हीमध्ये खूप स्थिर आहे. परंतु हे इतके सोपे कधीच नसते:

• तुम्ही चिनी नागरिक किंवा कायदेशीर संस्था नसल्यास ते मिळवणे खूप कठीण आहे,
• तुम्हाला प्रत्येक मेगाबिट चॅनेल बँडविड्थसाठी पैसे द्यावे लागतील.

जोडण्याची संधी आहे मुख्य भूप्रदेश चीन и ओव्हरसीज, आम्ही दोन अली प्रदेशांमध्ये CEN तयार केले: cn-शेन्झेन и us-east-1 (आमच्यासाठी सर्वात जवळचा बिंदू-पूर्व4). अली मध्ये us-east-1 दुसरे व्हर्च्युअल मशीन उभे केले जेणेकरून आणखी एक असेल लंगडी घालणे.

हे असे दिसून आले:

ब्राउझर चाचणीचे निकाल खाली दिले आहेत:

निर्णय
अपटाईम
मध्यक
75 टक्के
95 टक्के

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

CEN
99.75
16
21
27

कामगिरी IPSEC पेक्षा थोडी चांगली आहे. परंतु IPSEC द्वारे तुम्ही 100 Mbit/s च्या वेगाने आणि CEN द्वारे फक्त 5 Mbit/s आणि अधिक वेगाने डाउनलोड करू शकता.

एक संकरित सारखे ध्वनी, बरोबर? IPSEC गती आणि CEN स्थिरता एकत्र करा.

IPSEC बोगद्यात बिघाड झाल्यास IPSEC आणि CEN दोन्ही मार्गे रहदारीला परवानगी देऊन आम्ही हेच केले. अपटाइम खूप जास्त झाला आहे, परंतु साइट लोडिंग गती अद्याप इच्छित होण्यासाठी बरेच काही सोडते. मग आम्ही आधीच वापरलेले आणि तपासलेले सर्व सर्किट्स मी काढले आणि या सर्किटमध्ये थोडे अधिक GCP जोडण्याचा प्रयत्न करण्याचा निर्णय घेतला, म्हणजे जीएलबी.

जीएलबी

जीएलबी - हे आहे ग्लोबल लोड बॅलन्सर (किंवा Google क्लाउड लोड बॅलन्सर). त्याचा आमच्यासाठी एक महत्त्वाचा फायदा आहे: सीडीएनच्या संदर्भात तो आहे anycast IP, जे तुम्हाला क्लायंटच्या सर्वात जवळच्या डेटा सेंटरवर रहदारीला रूट करण्याची परवानगी देते, जेणेकरून ट्रॅफिक त्वरीत Google च्या जलद नेटवर्कमध्ये प्रवेश करेल आणि "नियमित" इंटरनेटद्वारे कमी जाईल.

दोनदा विचार न करता आम्ही उठवले HTTP/HTTPS LB आम्ही आमची व्हर्च्युअल मशीन्स GCP मध्ये सबफिल्टरसह आणि बॅकएंड म्हणून स्थापित केली.

अनेक योजना होत्या:

• वापरा क्लाउडफ्लेअर चायना नेटवर्क, परंतु यावेळी Origin ने जागतिक निर्दिष्ट केले पाहिजे IP GLB.
• येथे क्लायंट समाप्त करा cn-शेन्झेन, आणि तेथून थेट रहदारीला प्रॉक्सी करा जीएलबी.
• चीनहून थेट जा जीएलबी.
• येथे क्लायंट समाप्त करा cn-शेन्झेन, तेथून प्रॉक्सी पर्यंत asia-east1 IPSEC द्वारे (मध्ये us-east4 CEN मार्गे), तेथून GLB वर जा (शांतपणे, खाली एक चित्र आणि स्पष्टीकरण असेल)

आम्ही या सर्व पर्यायांची आणि अनेक संकरितांची चाचणी केली:

• क्लाउडफ्लेअर + GLB

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

• अली + GLB

ही योजना आम्हाला अपटाइमच्या बाबतीतही शोभत नाही, कारण GLB अनेकदा स्वीकारार्ह वेळेत किंवा टाइमआउटमध्ये कनेक्ट होण्याच्या अशक्यतेमुळे अपस्ट्रीममधून बाहेर पडतो, कारण चीनमधील सर्व्हरसाठी, GLB पत्ता बाहेरच राहतो आणि म्हणूनच चीनी फायरवॉल. जादू झाली नाही.

• फक्त GLB

मागील पर्यायासारखाच एक पर्याय, केवळ तो चीनमध्येच सर्व्हर वापरत नाही: रहदारी थेट GLB वर गेली (DNS रेकॉर्ड बदलले होते). त्यानुसार, परिणाम समाधानकारक नव्हते, कारण सामान्य इंटरनेट प्रदात्यांच्या सेवा वापरणार्‍या सामान्य चीनी क्लायंटमध्ये अली क्लाउडपेक्षा फायरवॉल पार करणे खूपच वाईट आहे.

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

येथे आम्ही सर्व सर्वोत्तम उपाय वापरण्याचे ठरविले:

• CEN कडून स्थिरता आणि हमी SLA
• IPSEC कडून उच्च गती
• Google चे "वेगवान" नेटवर्क आणि त्याचे कोणतेही कास्ट.

योजना यासारखे काहीतरी दिसते: वापरकर्ता रहदारी वर्च्युअल मशीनवर समाप्त केली जाते ch-शेन्झेन. Nginx अपस्ट्रीम तेथे कॉन्फिगर केले आहेत, त्यापैकी काही IPSEC बोगद्याच्या दुसऱ्या टोकाला असलेल्या खाजगी IP सर्व्हरकडे निर्देश करतात आणि काही अपस्ट्रीम CEN च्या दुसऱ्या बाजूला असलेल्या सर्व्हरच्या खाजगी पत्त्यांकडे निर्देश करतात. IPSEC प्रदेशासाठी कॉन्फिगर केले asia-east1 GCP मध्ये (समाधान तयार केले तेव्हा चीनच्या सर्वात जवळचा प्रदेश होता. GCP आता हाँगकाँगमध्ये देखील आहे). CEN - प्रदेशासाठी us-east1 अली क्लाउड मध्ये.

त्यानंतर दोन्ही बाजूची वाहतूक वळविण्यात आली anycast IP GLB, म्हणजे, Google च्या उपस्थितीच्या सर्वात जवळच्या बिंदूपर्यंत, आणि त्याच्या नेटवर्कद्वारे प्रदेशात गेले us-east4 GCP मध्ये, ज्यामध्ये व्हर्च्युअल मशीन्स बदलल्या होत्या (nginx मधील सबफिल्टरसह).

या संकरित समाधानाने, आम्ही अपेक्षेप्रमाणे, प्रत्येक तंत्रज्ञानाच्या फायद्यांचा फायदा घेतला. सर्वसाधारणपणे, ट्रॅफिक जलद IPSEC मधून जाते, परंतु समस्या सुरू झाल्यास, आम्ही त्वरीत आणि काही मिनिटांसाठी या सर्व्हरला अपस्ट्रीममधून बाहेर काढतो आणि बोगदा स्थिर होईपर्यंत फक्त CEN द्वारे वाहतूक पाठवतो.

वरील यादीतील चौथ्या उपायाची अंमलबजावणी करून, त्या वेळी आम्हाला काय हवे होते आणि व्यवसायाला काय हवे होते ते आम्ही साध्य केले.

मागील सोल्यूशनच्या तुलनेत नवीन सोल्यूशनसाठी ब्राउझर चाचणी परिणाम:

निर्णय
अपटाईम
मध्यक
75 टक्के
95 टक्के

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

CEN
99.75
16
21
27

CEN/IPsec + GLB
99.79
13
16
25

जागा

आम्ही अंमलात आणलेल्या सोल्यूशनमध्ये सर्व काही चांगले आहे, परंतु प्रादेशिक आणि अगदी शहर स्तरावर रहदारीला गती देणारा कोणताही CDN नाही. सिद्धांततः, यामुळे CDN प्रदात्याच्या जलद संप्रेषण चॅनेलचा वापर करून अंतिम वापरकर्त्यांसाठी साइटची गती वाढली पाहिजे. आणि आम्ही सर्व वेळ याबद्दल विचार केला. आणि आता, प्रकल्पाच्या पुढील पुनरावृत्तीची वेळ आली आहे: चीनमधील CDN प्रदात्यांचा शोध आणि चाचणी.

आणि मी तुम्हाला पुढील, शेवटच्या भागात याबद्दल सांगेन :)

स्त्रोत: www.habr.com