ProHoster > Blog > Pentadbiran > Bagaimana kami menerobos Tembok Api Besar China (Bahagian 2)

Bagaimana kami menerobos Tembok Api Besar China (Bahagian 2)

Hello!

Nikita bersama anda sekali lagi, seorang jurutera sistem daripada syarikat itu SEMrush. Dan dengan artikel ini saya meneruskan cerita tentang cara kami menghasilkan penyelesaian penyelesaian Tembok Api Cina untuk perkhidmatan kami semrush.com.

Π’ bahagian sebelumnya Saya kata:

  • apakah masalah yang timbul selepas keputusan dibuat "Kami perlu membuat perkhidmatan kami berfungsi di China"
  • Apakah masalah yang dihadapi oleh Internet Cina?
  • mengapa anda memerlukan lesen ICP?
  • bagaimana dan mengapa kami memutuskan untuk menguji katil ujian kami dengan Catchpoint
  • apakah hasil daripada penyelesaian pertama kami berdasarkan Rangkaian Cloudflare China
  • Bagaimana kami menemui pepijat dalam Cloudflare DNS

Bahagian ini adalah yang paling menarik, pada pendapat saya, kerana ia memberi tumpuan kepada pelaksanaan teknikal khusus pementasan. Dan kita akan mulakan, atau lebih tepat lagi, dengan Alibaba Awan.

Alibaba Awan

Alibaba Awan ialah penyedia awan yang agak besar, yang mempunyai semua perkhidmatan yang membolehkannya dengan jujur ​​menyebut dirinya sebagai pembekal awan. Adalah baik bahawa mereka mempunyai peluang untuk mendaftar untuk pengguna asing, dan kebanyakan tapak diterjemahkan ke dalam bahasa Inggeris (untuk China ini adalah kemewahan). Dalam awan ini, anda boleh bekerja dengan banyak wilayah di dunia, tanah besar China, serta Asia Lautan (Hong Kong, Taiwan, dll.).

IPSEC

Kami bermula dengan geografi. Memandangkan tapak ujian kami terletak di Google Cloud, kami perlu "memautkan" Alibaba Cloud dengan GCP, jadi kami membuka senarai lokasi tempat Google berada. Pada masa itu mereka belum mempunyai pusat data sendiri di Hong Kong.
Kawasan yang paling dekat ternyata asia-timur1 (Taiwan). Ali ternyata menjadi wilayah paling dekat di tanah besar China dengan Taiwan cn-shenzhen (Shenzhen).

Dengan terraform menerangkan dan meningkatkan keseluruhan infrastruktur dalam GCP dan Ali. Terowong 100 Mbit/s di antara awan naik hampir serta-merta. Di pihak Shenzhen dan Taiwan, mesin maya proksi telah dibangkitkan. Di Shenzhen, trafik pengguna ditamatkan, diproksikan melalui terowong ke Taiwan, dan dari sana ia pergi terus ke IP luaran perkhidmatan kami di kami-timur (Pantai Timur AS). Ping antara mesin maya melalui terowong 24ms, yang tidak begitu teruk.

Pada masa yang sama, kami meletakkan kawasan ujian DNS Cloud Alibaba. Selepas mewakilkan zon kepada NS Ali, masa resolusi berkurangan daripada 470 ms kepada ms 50. Sebelum ini, zon itu juga berada di Cloudlfare.

Selari dengan terowong ke asia-timur1 menaikkan satu lagi terowong dari Shenzhen terus ke kami-timur4. Di sana mereka mencipta lebih banyak mesin maya proksi dan mula menguji kedua-dua penyelesaian, menghalakan trafik ujian menggunakan Kuki atau DNS. Bangku ujian diterangkan secara skematik dalam rajah berikut:

Latensi untuk terowong ternyata seperti berikut:
Ali cn-shenzhen <β€”> GCP asia-east1 β€” 24ms
Ali cn-shenzhen <β€”> GCP us-east4 β€” 200ms

Ujian penyemak imbas Catchpoint melaporkan peningkatan yang sangat baik.

Bandingkan keputusan ujian untuk dua penyelesaian:

keputusan
Uptime
median
75 Peratusan
95 Peratusan

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Ini adalah data daripada penyelesaian yang menggunakan terowong IPSEC melalui asia-timur1. Melalui us-east4 keputusannya lebih teruk, dan terdapat lebih banyak ralat, jadi saya tidak akan memberikan hasilnya.

Berdasarkan keputusan ujian dua terowong ini, satu daripadanya ditamatkan di rantau paling dekat dengan China, dan satu lagi di destinasi terakhir, menjadi jelas bahawa adalah penting untuk "muncul" dari bawah tembok api China secepat mungkin, dan kemudian gunakan rangkaian pantas (penyedia CDN , pembekal awan, dsb.). Tidak perlu mencuba untuk melalui tembok api dan sampai ke destinasi anda dalam satu masa. Ini bukan cara terpantas.

Secara umum, keputusannya tidak buruk, bagaimanapun, semrush.com mempunyai median 8.8s, dan 75 Percentile 9.4s (pada ujian yang sama).
Dan sebelum meneruskan, saya ingin membuat penyimpangan lirik pendek.

Pencerobohan lirik

Selepas pengguna memasuki tapak www.semrushchina.cn, yang menyelesaikan melalui pelayan DNS Cina "pantas", permintaan HTTP melalui penyelesaian pantas kami. Respons dikembalikan di sepanjang laluan yang sama, tetapi domain ditentukan dalam semua skrip JS, halaman HTML dan elemen lain halaman web semrush.com untuk sumber tambahan yang mesti dimuatkan apabila halaman dipaparkan. Iaitu, pelanggan menyelesaikan rekod A "utama". www.semrushchina.cn dan masuk ke terowong pantas, menerima respons dengan cepat - halaman HTML yang menyatakan:

  • muat turun js itu dan itu daripada sso.semrush.com,
  • Dapatkan fail CSS daripada cdn.semrush.com,
  • dan juga mengambil beberapa gambar dari dab.semrush.com
  • dan sebagainya.

Penyemak imbas mula pergi ke Internet "luaran" untuk sumber ini, setiap kali melalui tembok api yang memakan masa tindak balas.

Tetapi ujian sebelumnya menunjukkan keputusan apabila tiada sumber pada halaman semrush.comsahaja semrushchina.cn, dan *.semrushchina.cn menyelesaikan ke alamat mesin maya di Shenzhen untuk kemudian masuk ke terowong.

Hanya dengan cara ini, dengan menolak semua trafik yang mungkin ke tahap maksimum melalui penyelesaian anda untuk melepasi tembok api Cina dengan cepat, anda boleh mendapatkan kelajuan yang boleh diterima dan penunjuk ketersediaan tapak web, serta keputusan ujian penyelesaian yang jujur.
Kami melakukan ini tanpa satu pengeditan kod pada bahagian produk pasukan.

Penapis kecil

Penyelesaian itu dilahirkan hampir serta-merta selepas masalah ini muncul. Kami perlukan PoC (Bukti Konsep) bahawa penyelesaian penembusan tembok api kami benar-benar berfungsi dengan baik. Untuk melakukan ini, anda perlu membungkus semua trafik tapak ke dalam penyelesaian ini sebanyak mungkin. Dan kami memohon penapis kecil dalam nginx.

Penapis kecil ialah modul yang agak mudah dalam nginx yang membolehkan anda menukar satu baris dalam badan tindak balas kepada baris lain. Jadi kami mengubah semua kejadian semrush.com pada semrushchina.cn dalam semua jawapan.

Dan... ia tidak berjaya kerana kami menerima kandungan termampat daripada bahagian belakang, jadi subpenapis tidak menemui baris yang diperlukan. Saya terpaksa menambah pelayan tempatan lain ke nginx, yang menyahmampat respons dan menyampaikannya ke pelayan tempatan seterusnya, yang sudah sibuk menggantikan rentetan, memampatkannya, dan menghantarnya ke pelayan proksi seterusnya dalam rantaian.

Akibatnya, di manakah pelanggan akan menerima .semrush.com, dia menerima .semrushchina.cn dan mematuhi keputusan kami dengan patuh.

Walau bagaimanapun, ia tidak mencukupi untuk menukar domain sehala sahaja, kerana bahagian belakang masih mengharapkan semrush.com dalam permintaan seterusnya daripada pelanggan. Sehubungan itu, pada pelayan yang sama di mana penggantian sehala dilakukan, menggunakan ungkapan biasa yang mudah kami mendapat subdomain daripada permintaan, dan kemudian kami melakukannya laluan proksi dengan pembolehubah $tuan rumah, dipamerkan di $subdomain.semrush.com. Ia mungkin kelihatan mengelirukan, tetapi ia berkesan. Dan ia berfungsi dengan baik. Untuk domain individu yang memerlukan logik berbeza, hanya buat blok pelayan anda sendiri dan buat konfigurasi berasingan. Di bawah adalah konfigurasi nginx yang dipendekkan untuk kejelasan dan demonstrasi skim ini.

Konfigurasi berikut memproses semua permintaan dari China ke .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;
    }
}

Konfigurasi ini proksi kepada localhost ke port 83, dan konfigurasi berikut sedang menunggu di sana:

    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;
    }
}

Saya ulangi, ini adalah konfigurasi yang dipangkas.

Macam itu. Ia mungkin kelihatan rumit, tetapi ia adalah dalam kata-kata. Malah, semuanya lebih mudah daripada lobak kukus :)

Tamat penyelewengan

Untuk seketika kami gembira kerana mitos mengenai terowong IPSEC yang jatuh tidak disahkan. Tetapi kemudian terowong mula jatuh. Beberapa kali sehari selama beberapa minit. Sedikit, tetapi itu tidak sesuai dengan kami. Memandangkan kedua-dua terowong telah ditamatkan di sebelah Ali pada penghala yang sama, kami memutuskan bahawa mungkin ini adalah masalah serantau dan kami perlu meningkatkan wilayah sandaran.

Mereka mengambilnya. Terowong mula gagal pada masa yang berbeza, tetapi failover berfungsi dengan baik untuk kami di peringkat huluan dalam nginx. Tetapi kemudian terowong mula jatuh pada masa yang sama :) Dan 502 dan 504 mula jatuh semula. Masa operasi mula merosot, jadi kami mula mengusahakan pilihan dengan Alibaba CEN (Rangkaian Perusahaan Cloud).

CEN

CEN - ini ialah ketersambungan dua VPC dari wilayah berbeza dalam Alibaba Cloud, iaitu, anda boleh menyambungkan rangkaian peribadi mana-mana wilayah dalam awan antara satu sama lain. Dan yang paling penting: saluran ini mempunyai saluran yang agak ketat SLA. Ia sangat stabil dari segi kelajuan dan masa beroperasi. Tetapi ia tidak pernah semudah itu:

  • AMAT sukar diperoleh jika anda bukan warganegara China atau entiti undang-undang,
  • Anda perlu membayar untuk setiap megabit lebar jalur saluran.

Mempunyai peluang untuk berhubung Tanah Besar China ΠΈ Luar Negara, kami mencipta CEN antara dua wilayah Ali: cn-shenzhen ΠΈ kami-timur-1 (titik terdekat dengan us-timur4). Dalam Ali kami-timur-1 menaikkan satu lagi mesin maya supaya ada satu lagi hop.

Ternyata begini:

Keputusan ujian penyemak imbas adalah di bawah:

keputusan
Uptime
median
75 Peratusan
95 Peratusan

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Prestasinya lebih baik sedikit daripada IPSEC. Tetapi melalui IPSEC anda berpotensi boleh memuat turun pada kelajuan 100 Mbit/s, dan melalui CEN hanya pada kelajuan 5 Mbit/s dan lebih.

Bunyi seperti hibrid, bukan? Gabungkan kelajuan IPSEC dan kestabilan CEN.

Inilah yang kami lakukan, membenarkan trafik melalui IPSEC dan CEN sekiranya berlaku kegagalan terowong IPSEC. Masa aktif telah menjadi lebih tinggi, tetapi kelajuan memuatkan tapak masih meninggalkan banyak perkara yang diingini. Kemudian saya melukis semua litar yang telah kami gunakan dan uji, dan memutuskan untuk cuba menambah sedikit lagi GCP pada litar ini, iaitu GLB.

GLB

GLB - Adakah Pengimbang Beban Global (atau Pengimbang Beban Awan Google). Ia mempunyai kelebihan penting untuk kami: dalam konteks CDN yang dimilikinya IP anycast, yang membolehkan anda menghalakan trafik ke pusat data yang paling hampir dengan pelanggan, supaya trafik cepat masuk ke rangkaian pantas Google dan kurang melalui Internet "biasa".

Tanpa berfikir dua kali, kami bangkitkan HTTP/HTTPS LB Kami memasang mesin maya kami dengan subpenapis dalam GCP dan sebagai bahagian belakang.

Terdapat beberapa skim:

  • Guna Rangkaian Cloudflare China, tetapi kali ini Origin harus menentukan global IP GLB.
  • Menamatkan pelanggan di cn-shenzhen, dan dari situ proksi trafik terus ke GLB.
  • Pergi terus dari China ke GLB.
  • Menamatkan pelanggan di cn-shenzhen, dari sana proksi ke asia-timur1 melalui IPSEC (dalam kami-timur4 melalui CEN), dari sana pergi ke GLB (dengan tenang, akan ada gambar dan penjelasan di bawah)

Kami menguji semua pilihan ini dan beberapa lagi pilihan hibrid:

  • Cloudflare + GLB

Skim ini tidak sesuai dengan kami kerana masa hidup dan ralat DNS. Tetapi ujian telah dijalankan sebelum pepijat ditetapkan pada bahagian CF, mungkin lebih baik sekarang (namun, ini tidak mengecualikan tamat masa HTTP).

  • Ali + GLB

Skim ini juga tidak sesuai dengan kami dari segi masa beroperasi, kerana GLB sering jatuh dari huluan kerana ketidakmungkinan menyambung dalam masa yang boleh diterima atau tamat masa, kerana untuk pelayan di dalam China, alamat GLB kekal di luar, dan oleh itu di belakang Tembok api Cina. Keajaiban itu tidak berlaku.

  • GLB sahaja

Pilihan yang serupa dengan yang sebelumnya, cuma ia tidak menggunakan pelayan di China sendiri: trafik pergi terus ke GLB (rekod DNS telah ditukar). Sehubungan itu, keputusannya tidak memuaskan, kerana pelanggan Cina biasa yang menggunakan perkhidmatan penyedia Internet biasa mempunyai situasi yang lebih teruk dengan melepasi tembok api daripada Ali Cloud.

  • Shenzhen -> (CEN/IPSEC) -> Proksi -> GLB

Di sini kami memutuskan untuk menggunakan yang terbaik daripada semua penyelesaian:

  • kestabilan dan SLA terjamin daripada CEN
  • kelajuan tinggi dari IPSEC
  • Rangkaian "pantas" Google dan anycastnya.

Skim ini kelihatan seperti ini: trafik pengguna ditamatkan pada mesin maya dalam ch-shenzhen. Hulu Nginx dikonfigurasikan di sana, beberapa daripadanya menghala ke pelayan IP peribadi yang terletak di hujung terowong IPSEC yang lain, dan beberapa huluan menghala ke alamat peribadi pelayan di sisi lain CEN. IPSEC dikonfigurasikan ke rantau asia-timur1 dalam GCP (adalah wilayah yang paling hampir dengan China pada masa penyelesaian itu dibuat. GCP kini juga mempunyai kehadiran di Hong Kong). CEN - ke rantau kami-timur1 dalam Ali Cloud.

Kemudian lalu lintas dari kedua-dua hujung diarahkan ke anycast IP GLB, iaitu, ke tempat terdekat kehadiran Google, dan melalui rangkaiannya ke rantau ini kami-timur4 dalam GCP, di mana terdapat penggantian mesin maya (dengan subfilter dalam nginx).

Penyelesaian hibrid ini, seperti yang kami jangkakan, mengambil kesempatan daripada faedah setiap teknologi. Secara umum, trafik melalui IPSEC pantas, tetapi jika masalah bermula, kami dengan cepat dan selama beberapa minit menendang pelayan ini keluar dari huluan dan menghantar trafik hanya melalui CEN sehingga terowong stabil.

Dengan melaksanakan penyelesaian ke-4 daripada senarai di atas, kami mencapai apa yang kami mahukan dan perkara yang diperlukan oleh perniagaan daripada kami pada masa itu.

Keputusan ujian penyemak imbas untuk penyelesaian baharu berbanding yang sebelumnya:

keputusan
Uptime
median
75 Peratusan
95 Peratusan

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

Semuanya baik dalam penyelesaian yang kami laksanakan, tetapi tidak ada CDN yang boleh mempercepatkan trafik di peringkat serantau dan juga bandar. Secara teori, ini sepatutnya mempercepatkan tapak untuk pengguna akhir dengan menggunakan saluran komunikasi pantas penyedia CDN. Dan kami memikirkannya sepanjang masa. Dan kini, masanya telah tiba untuk lelaran projek seterusnya: mencari dan menguji penyedia CDN di China.

Dan saya akan memberitahu anda tentang ini pada bahagian akhir yang seterusnya :)

Sumber: www.habr.com

Tambah komen