როგორ გავარღვიეთ დიდი ჩინური Firewall (ნაწილი 2)

Hi!

ნიკიტა ისევ თქვენთანაა, კომპანიის სისტემის ინჟინერი SEMrush. და ამ სტატიით ვაგრძელებ ისტორიას იმის შესახებ, თუ როგორ მივიღეთ გამოსავალი ჩინური Firewall ჩვენი სერვისისთვის semrush.com.

В წინა ნაწილი Მე ვთქვი:

• რა პრობლემები წარმოიქმნება გადაწყვეტილების მიღების შემდეგ "ჩვენ უნდა ვამოქმედოთ ჩვენი სერვისი ჩინეთში"
• რა პრობლემები აქვს ჩინურ ინტერნეტს?
• რატომ გჭირდებათ ICP ლიცენზია?
• როგორ და რატომ გადავწყვიტეთ გამოცდა ჩვენი საცდელი საწოლები Catchpoint-ით
• რა იყო ჩვენი პირველი გადაწყვეტის შედეგი, რომელიც დაფუძნებულია Cloudflare China Network-ზე
• როგორ აღმოვაჩინეთ შეცდომა Cloudflare DNS-ში

ეს ნაწილი, ჩემი აზრით, ყველაზე საინტერესოა, რადგან აქცენტი კეთდება დადგმის კონკრეტულ ტექნიკურ განხორციელებაზე. და ჩვენ დავიწყებთ, უფრო სწორად გავაგრძელებთ ალიბბა ღრუბელი.

ალიბბა ღრუბელი

ალიბბა ღრუბელი არის საკმაოდ დიდი ღრუბლოვანი პროვაიდერი, რომელსაც აქვს ყველა სერვისი, რაც საშუალებას აძლევს მას გულწრფელად უწოდოს თავს ღრუბლოვანი პროვაიდერი. კარგია, რომ მათ აქვთ შესაძლებლობა დარეგისტრირდნენ უცხოელ მომხმარებლებზე და რომ საიტის უმეტესობა ითარგმნა ინგლისურად (ჩინეთისთვის ეს ფუფუნებაა). ამ ღრუბელში შეგიძლიათ იმუშაოთ მსოფლიოს მრავალ რეგიონთან, მატერიკულ ჩინეთთან, ასევე ოკეანეურ აზიასთან (ჰონკონგი, ტაივანი და ა.შ.).

IPSEC

დავიწყეთ გეოგრაფიით. ვინაიდან ჩვენი სატესტო საიტი მდებარეობდა Google Cloud-ზე, დაგვჭირდა Alibaba Cloud-ის „დაკავშირება“ GCP-თან, ამიტომ გავხსენით იმ ადგილების სია, რომლებშიც Google იმყოფება. იმ მომენტში მათ ჯერ არ ჰქონდათ საკუთარი მონაცემთა ცენტრი ჰონგ კონგში.
უახლოესი რეგიონი აღმოჩნდა აზია-აღმოსავლეთი 1 (ტაივანი). ალი აღმოჩნდა მატერიკზე ჩინეთის უახლოესი რეგიონი ტაივანთან cn-შენჟენი (შენჟენი).

ერთად terraform აღწერა და აამაღლა მთელი ინფრასტრუქტურა GCP-სა და Ali-ში. ღრუბლებს შორის 100 Mbit/s გვირაბი თითქმის მყისიერად ავიდა. შენჟენისა და ტაივანის მხარეზე გაჩნდა პროქსი-ვირტუალური მანქანები. შენჟენში მომხმარებლის ტრაფიკი წყდება, გვირაბის გავლით ტაივანში გადადის და იქიდან პირდაპირ ჩვენი სერვისის გარე IP-ზე გადადის ჩვენ-აღმოსავლეთი (აშშ აღმოსავლეთ სანაპირო). პინგი ვირტუალურ მანქანებს შორის გვირაბის საშუალებით 24ms, რაც არც ისე ცუდია.

ამავდროულად, ჩვენ მოვათავსეთ სატესტო ზონა Alibaba Cloud DNS. ზონის NS Ali-ზე დელეგირების შემდეგ, გარჩევადობის დრო შემცირდა 470 ms-დან 50 ms. მანამდე ზონა ასევე Cloudlfare-ზე იყო.

გვირაბის პარალელურად აზია-აღმოსავლეთი 1 აიღო სხვა გვირაბი შენჟენიდან პირდაპირ ჩვენ-აღმოსავლეთი4. იქ მათ შექმნეს მეტი მარიონეტული ვირტუალური მანქანა და დაიწყეს ორივე გადაწყვეტის ტესტირება, სატესტო ტრაფიკის მარშრუტირება Cookies ან DNS გამოყენებით. ტესტის სკამი სქემატურად არის აღწერილი შემდეგ ფიგურაში:

გვირაბების შეყოვნება შემდეგი იყო:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint ბრაუზერის ტესტებმა აჩვენა შესანიშნავი გაუმჯობესება.

შეადარეთ ტესტის შედეგები ორი გამოსავლისთვის:

გადაწყვეტილება
Uptime
მედიანი
75 პროცენტული
95 პროცენტული

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

ეს არის მონაცემები ხსნარიდან, რომელიც იყენებს IPSEC გვირაბს აზია-აღმოსავლეთი 1. us-east4-ის მეშვეობით შედეგები უარესი იყო და მეტი შეცდომა იყო, ამიტომ შედეგებს არ მოგცემთ.

ორი გვირაბის ამ ტესტის შედეგებზე დაყრდნობით, რომელთაგან ერთი მთავრდება ჩინეთთან უახლოეს რეგიონში, ხოლო მეორე საბოლოო დანიშნულების ადგილზე, ცხადი გახდა, რომ მნიშვნელოვანია ჩინეთის ფარის კედლიდან „გამოსვლა“ რაც შეიძლება სწრაფად. შესაძლებელია და შემდეგ გამოიყენეთ სწრაფი ქსელები (CDN პროვაიდერები, ღრუბლოვანი პროვაიდერები და ა.შ.). არ არის საჭირო, რომ შეეცადოთ გაიაროთ firewall და მიხვიდეთ თქვენს დანიშნულებამდე ერთი დარტყმით. ეს არ არის ყველაზე სწრაფი გზა.

ზოგადად, შედეგები არ არის ცუდი, თუმცა, semrush.com-ს აქვს მედიანა 8.8s და 75 პროცენტული 9.4s (იმავე ტესტზე).
და სანამ გადავიდოდე, მინდა გავაკეთო მოკლე ლირიკული გადახრა.

ლირიკული გადახრა

მომხმარებლის საიტზე შესვლის შემდეგ www.semrushchina.cn, რომელიც წყვეტს „სწრაფი“ ჩინური DNS სერვერების მეშვეობით, HTTP მოთხოვნა გადის ჩვენს სწრაფ გადაწყვეტას. პასუხი ბრუნდება იმავე გზაზე, მაგრამ დომენი მითითებულია ყველა JS სკრიპტში, HTML გვერდსა და ვებ გვერდის სხვა ელემენტებში. semrush.com დამატებითი რესურსებისთვის, რომლებიც უნდა ჩაიტვირთოს გვერდის გაფორმებისას. ანუ კლიენტი წყვეტს "მთავარ" A- ჩანაწერს www.semrushchina.cn და გადადის სწრაფ გვირაბში, სწრაფად იღებს პასუხს - HTML გვერდი, რომელშიც ნათქვამია:

• ჩამოტვირთეთ ასეთი და ასეთი js sso.semrush.com-დან,
• მიიღეთ CSS ფაილები cdn.semrush.com-დან,
• და ასევე გადაიღეთ რამდენიმე სურათი dab.semrush.com-დან
• და ასე შემდეგ.

ბრაუზერი იწყებს ამ რესურსების "გარე" ინტერნეტში გადასვლას, ყოველ ჯერზე გადის ბუხარში, რომელიც ჭამს რეაგირების დროს.

მაგრამ წინა ტესტი აჩვენებს შედეგებს, როდესაც არ არის რესურსები გვერდზე semrush.comმხოლოდ სემრუშჩინა.cn, და *.semrushchina.cn გადაწყვეტს ვირტუალური მანქანის მისამართს შენჟენში, რათა შემდეგ შევიდეს გვირაბში.

მხოლოდ ამ გზით, ყველა შესაძლო ტრაფიკის მაქსიმუმამდე მიყვანით თქვენი გადაწყვეტილების მეშვეობით, რათა სწრაფად გაიაროთ ჩინური firewall, შეგიძლიათ მიიღოთ მისაღები სიჩქარე და ვებსაიტების ხელმისაწვდომობის ინდიკატორები, ასევე გადაწყვეტის ტესტების გულწრფელი შედეგები.
ჩვენ ეს გავაკეთეთ გუნდის პროდუქტის ერთი კოდის შესწორების გარეშე.

ქვეფილტრი

გამოსავალი გაჩნდა ამ პრობლემის გამოჩენისთანავე. Ჩვენ გვჭირდებოდა PoC (კონცეფციის მტკიცებულება), რომ ჩვენი firewall-ის შეღწევის გადაწყვეტილებები ნამდვილად კარგად მუშაობს. ამისათვის თქვენ უნდა შეფუთოთ საიტის მთელი ტრაფიკი ამ გადაწყვეტაში რაც შეიძლება მეტი. და მივმართეთ ქვეფილტრი ნგინქსში.

ქვეფილტრი არის საკმაოდ მარტივი მოდული nginx-ში, რომელიც საშუალებას გაძლევთ შეცვალოთ ერთი ხაზი საპასუხო სხეულში მეორე ხაზზე. ასე რომ, ჩვენ შევცვალეთ ყველა მოვლენა semrush.com on სემრუშჩინა.cn ყველა პასუხში.

და... ეს არ მუშაობდა, რადგან ჩვენ მივიღეთ შეკუმშული შინაარსი ბექენდებიდან, ამიტომ ქვეფილტრმა ვერ იპოვა საჭირო ხაზი. nginx-ს უნდა დავამატო სხვა ლოკალური სერვერი, რომელმაც მოახდინა პასუხის დეკომპრესია და გადასცა შემდეგ ლოკალურ სერვერზე, რომელიც უკვე დაკავებული იყო სტრიქონის ჩანაცვლებით, შეკუმშვით და ჯაჭვის შემდეგ პროქსი სერვერზე გაგზავნით.

შედეგად, სად მიიღებდა კლიენტი .semrush.com, მან მიიღო .სემრუშჩინა.გნ და მორჩილად მივიღეთ ჩვენი გადაწყვეტილება.

თუმცა, საკმარისი არ არის უბრალოდ დომენის ერთი გზით შეცვლა, რადგან ბექენდები მაინც ელიან 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 გვირაბების დაცემის შესახებ არ დადასტურდა. მაგრამ შემდეგ გვირაბებმა ვარდნა დაიწყეს. დღეში რამდენჯერმე რამდენიმე წუთის განმავლობაში. ცოტა, მაგრამ ეს არ გვიწყობდა. მას შემდეგ, რაც ორივე გვირაბი წყდებოდა ალის მხარეს ერთსა და იმავე როუტერზე, ჩვენ გადავწყვიტეთ, რომ შესაძლოა ეს იყო რეგიონალური პრობლემა და გვჭირდებოდა სარეზერვო რეგიონის გაზრდა.

აიღეს. გვირაბებმა სხვადასხვა დროს დაიწყეს მარცხი, მაგრამ ფაილოვერი ჩვენთვის კარგად მუშაობდა ნგინქსის ზედა დინების დონეზე. მაგრამ შემდეგ გვირაბებმა დაიწყეს ვარდნა დაახლოებით ერთსა და იმავე დროს 🙂 და ისევ დაიწყეს 502 და 504. Uptime დაიწყო გაუარესება, ამიტომ დავიწყეთ მუშაობა ვარიანტზე Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - ეს არის ორი VPC-ის დაკავშირება სხვადასხვა რეგიონიდან Alibaba Cloud-ში, ანუ შეგიძლიათ ერთმანეთთან დააკავშიროთ ღრუბელში არსებული ნებისმიერი რეგიონის კერძო ქსელები. და რაც მთავარია: ამ არხს აქვს საკმაოდ მკაცრი SLA. ის ძალიან სტაბილურია როგორც სიჩქარეში, ასევე დროში. მაგრამ ეს არასოდეს არ არის ასე მარტივი:

• ძალიან რთულია მისი მიღება, თუ არ ხართ ჩინეთის მოქალაქე ან იურიდიული პირი,
• თქვენ უნდა გადაიხადოთ არხის ტევადობის თითოეული მეგაბიტი.

დაკავშირების შესაძლებლობა ჩინეთი и უცხოურიჩვენ შევქმენით CEN ორ ალი რეგიონს შორის: cn-შენჟენი и us-აღმოსავლეთი-1 (ჩვენთან უახლოესი წერტილი-აღმოსავლეთი4). ალიში us-აღმოსავლეთი-1 აამაღლა კიდევ ერთი ვირტუალური მანქანა ისე, რომ კიდევ ერთი იყოს hop.

ასე აღმოჩნდა:

ბრაუზერის ტესტის შედეგები ქვემოთ მოცემულია:

გადაწყვეტილება
Uptime
მედიანი
75 პროცენტული
95 პროცენტული

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

შესრულება ოდნავ უკეთესია ვიდრე IPSEC. მაგრამ IPSEC-ის საშუალებით შეგიძლიათ ჩამოტვირთოთ პოტენციურად 100 მბიტ/წმ სიჩქარით, ხოლო CEN-ის მეშვეობით მხოლოდ 5 მბიტ/წმ და მეტი სიჩქარით.

ჰიბრიდს ჰგავს, არა? შეუთავსეთ IPSEC სიჩქარე და CEN სტაბილურობა.

ეს არის ის, რაც ჩვენ გავაკეთეთ, რომ მივცეთ მოძრაობა როგორც IPSEC-ის, ასევე CEN-ის გავლით IPSEC გვირაბის გაუმართაობის შემთხვევაში. Uptime გახდა ბევრად უფრო მაღალი, მაგრამ საიტის ჩატვირთვის სიჩქარე მაინც ბევრს ტოვებს სასურველს. შემდეგ დავხატე ყველა სქემები, რომლებიც უკვე გამოვიყენეთ და გამოვცადეთ და გადავწყვიტე ამ წრეში ცოტა მეტი GCP-ის დამატება, კერძოდ ქუდი.

ქუდი

ქუდი - რამდენად გლობალური დატვირთვის ბალანსერი (ან Google Cloud Load Balancer). მას აქვს მნიშვნელოვანი უპირატესობა ჩვენთვის: CDN-ის კონტექსტში მას აქვს anycast IP, რომელიც საშუალებას გაძლევთ გადაიყვანოთ ტრაფიკი კლიენტთან ყველაზე ახლოს მონაცემთა ცენტრში, რათა ტრაფიკი სწრაფად მოხვდეს Google-ის სწრაფ ქსელში და ნაკლები გაიაროს „რეგულარულ“ ინტერნეტში.

ორჯერ დაუფიქრებლად გავზარდეთ HTTP/HTTPS LB ჩვენ დავაყენეთ ჩვენი ვირტუალური მანქანები ქვეფილტრით GCP-ში და როგორც backend.

იყო რამდენიმე სქემა:

• გამოიყენეთ Cloudflare China Network, მაგრამ ამჯერად Origin-მა უნდა მიუთითოს გლობალური IP GLB.
• კლიენტების შეწყვეტა cn-შენჟენი, და იქიდან მარიონეტული მოძრაობა პირდაპირ ქუდი.
• პირდაპირ ჩინეთიდან წადით ქუდი.
• კლიენტების შეწყვეტა cn-შენჟენი, იქიდან პროქსი აზია-აღმოსავლეთი 1 IPSEC-ის საშუალებით (ში ჩვენ-აღმოსავლეთი4 CEN-ის საშუალებით), იქიდან გადადით GLB-ზე (მშვიდად, ქვემოთ იქნება სურათი და ახსნა)

ჩვენ გამოვცადეთ ყველა ეს ვარიანტი და კიდევ რამდენიმე ჰიბრიდული:

• Cloudflare + GLB

ეს სქემა არ შეგვეფერა დროების და DNS შეცდომების გამო. მაგრამ ტესტი ჩატარდა მანამ, სანამ შეცდომა დაფიქსირდა CF მხარეს, ალბათ ახლა უკეთესია (თუმცა, ეს არ გამორიცხავს HTTP ვადებს).

• ალი + GLB

ეს სქემა ასევე არ ჯდება ჩვენთან მუშაობის დროის თვალსაზრისით, რადგან GLB ხშირად ცვივა ზემოდან, მისაღებ დროში დაკავშირების შეუძლებლობის გამო, რადგან ჩინეთის შიგნით სერვერისთვის, GLB მისამართი რჩება გარეთ და, შესაბამისად, უკან. ჩინური firewall. ჯადოქრობა არ მომხდარა.

• მხოლოდ GLB

წინა მსგავსი ვარიანტი, მხოლოდ ის არ იყენებდა სერვერებს თავად ჩინეთში: ტრაფიკი პირდაპირ GLB-ზე მიდიოდა (DNS ჩანაწერები შეიცვალა). შესაბამისად, შედეგები არ იყო დამაკმაყოფილებელი, რადგან რიგითი ჩინელი კლიენტები, რომლებიც იყენებენ ჩვეულებრივი ინტერნეტ პროვაიდერების სერვისებს, აქვთ ბევრად უარესი მდგომარეობა Firewall-ის გავლისას, ვიდრე Ali Cloud.

• Shenzhen -> (CEN/IPSEC) -> პროქსი -> GLB

აქ ჩვენ გადავწყვიტეთ გამოვიყენოთ საუკეთესო გადაწყვეტილებები:

• სტაბილურობა და გარანტირებული SLA CEN-ისგან
• მაღალი სიჩქარე IPSEC-ისგან
• Google-ის "სწრაფი" ქსელი და მისი ნებისმიერი კასტი.

სქემა ასე გამოიყურება: მომხმარებლის ტრაფიკი წყდება ვირტუალურ მანქანაში ჩ-შენჟენი. Nginx upstreams კონფიგურირებულია იქ, რომელთაგან ზოგიერთი მიუთითებს IPSEC გვირაბის მეორე ბოლოში განლაგებულ კერძო IP სერვერებზე, ხოლო ზოგიერთი ზემო დინება მიუთითებს სერვერების პირად მისამართებზე CEN-ის მეორე მხარეს. IPSEC კონფიგურირებულია რეგიონში აზია-აღმოსავლეთი 1 GCP-ში (იყო ჩინეთთან უახლოესი რეგიონი იმ დროს, როდესაც გადაწყვეტა შეიქმნა. GCP ახლა ასევე იმყოფება ჰონგ კონგში). CEN - რეგიონში ჩვენ-აღმოსავლეთი1 ალი ღრუბელში.

შემდეგ მოძრაობა ორივე ბოლოდან მიმართული იყო anycast IP GLB, ანუ Google-ის ყოფნის უახლოეს წერტილამდე და მისი ქსელებით რეგიონში გავიდა ჩვენ-აღმოსავლეთი4 GCP-ში, რომელშიც იყო ჩანაცვლებული ვირტუალური მანქანები (სუბფილტრით nginx-ში).

ამ ჰიბრიდულმა გადაწყვეტამ, როგორც ველოდით, ისარგებლა თითოეული ტექნოლოგიის უპირატესობებით. ზოგადად, ტრაფიკი გადის სწრაფი IPSEC-ით, მაგრამ თუ პრობლემები იწყება, ჩვენ სწრაფად და რამდენიმე წუთის განმავლობაში ვტოვებთ ამ სერვერებს ზემოთ ნაკადიდან და ვაგზავნით ტრაფიკს მხოლოდ CEN-ის მეშვეობით, სანამ გვირაბი არ დასტაბილურდება.

ზემოაღნიშნული სიიდან მე-4 გადაწყვეტის განხორციელებით ჩვენ მივაღწიეთ იმას, რაც გვინდოდა და რასაც ბიზნესი მოითხოვდა ჩვენგან დროის იმ მომენტში.

ბრაუზერის ტესტის შედეგები ახალი გადაწყვეტისთვის წინასთან შედარებით:

გადაწყვეტილება
Uptime
მედიანი
75 პროცენტული
95 პროცენტული

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