Giunsa namo paglusot ang Great Chinese Firewall (Bahin 2)

Hello!

Si Nikita kauban nimo pag-usab, usa ka system engineer gikan sa kompanya SEMrush. Ug sa kini nga artikulo gipadayon nako ang istorya kung giunsa namon nahimo ang usa ka solusyon sa solusyon Intsik nga Firewall para sa among serbisyo semrush.com.

В miaging bahin Miingon ko:

• unsa nga mga problema ang mitungha pagkahuman sa desisyon nga "Kinahanglan namon nga buhaton ang among serbisyo sa China"
• Unsang mga problema ang naa sa Chinese Internet?
• nganong kinahanglan nimo ang lisensya sa ICP?
• giunsa ug ngano nga nakahukom kami nga sulayan ang among mga higdaanan sa Catchpoint
• unsa ang resulta sa among unang solusyon base sa Cloudflare China Network
• Giunsa namo nakit-an ang usa ka bug sa Cloudflare DNS

Kini nga bahin mao ang labing makapaikag, sa akong opinyon, tungod kay kini nagpunting sa piho nga teknikal nga pagpatuman sa dula. Ug kita magsugod, o hinoon magpadayon, uban sa Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud usa ka medyo dako nga cloud provider, nga adunay tanan nga mga serbisyo nga nagtugot niini sa matinud-anon nga pagtawag sa iyang kaugalingon nga cloud provider. Maayo nga sila adunay oportunidad nga magparehistro alang sa mga langyaw nga tiggamit, ug nga kadaghanan sa site gihubad ngadto sa Iningles (alang sa China kini usa ka kaluho). Niini nga panganod, mahimo kang magtrabaho sa daghang mga rehiyon sa kalibutan, mainland China, ingon man sa Oceanic Asia (Hong Kong, Taiwan, ug uban pa).

IPSEC

Nagsugod kami sa geograpiya. Tungod kay ang among site sa pagsulay nahimutang sa Google Cloud, kinahanglan namon nga "i-link" ang Alibaba Cloud sa GCP, mao nga giablihan namon ang usa ka lista sa mga lokasyon kung diin naa ang Google. Niadtong higayuna, wala pa silay kaugalingong data center sa Hong Kong.
Ang labing duol nga rehiyon nahimo nga asya-sidlangan1 (Taiwan). Si Ali nahimo nga labing duol nga rehiyon sa mainland China sa Taiwan cn-shenzhen (Shenzhen).

Uban sa tabang sa terraform gihulagway ug gipataas ang tibuok nga imprastraktura sa GCP ug Ali. Usa ka 100 Mbit/s tunnel sa taliwala sa mga panganod mitaas hapit diha-diha dayon. Sa kilid sa Shenzhen ug Taiwan, gipataas ang mga proxy nga virtual machine. Sa Shenzhen, ang trapiko sa mga tiggamit gitapos, gi-proxy pinaagi sa usa ka tunel sa Taiwan, ug gikan didto kini direkta nga moadto sa gawas nga IP sa among serbisyo sa us-sidlangan (USA East Coast). Ping tali sa mga virtual machine pinaagi sa tunnel 24ms, nga dili kaayo daotan.

Sa parehas nga oras, nagbutang kami usa ka lugar sa pagsulay Alibaba Cloud DNS. Human sa pagdelegar sa sona ngadto sa NS Ali, ang oras sa resolusyon mikunhod gikan sa 470 ms ngadto sa 50 ms. Sa wala pa kini, ang sona naa usab sa Cloudlfare.

Parallel sa tunnel sa asya-sidlangan1 nagpataas sa laing tunel gikan sa Shenzhen direkta ngadto sa us-sidlangan4. Didto naghimo sila og daghang mga proxy virtual machine ug nagsugod sa pagsulay sa duha nga mga solusyon, pag-ruta sa pagsulay sa trapiko gamit ang Cookies o DNS. Ang test bench gihulagway nga eskematiko sa mosunod nga numero:

Ang latency alang sa mga tunnel nahimong ingon sa mosunod:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Ang mga pagsulay sa browser sa Catchpoint nagreport nga maayo kaayo nga pag-uswag.

Itandi ang mga resulta sa pagsulay alang sa duha ka solusyon:

desisyon
Uptime
Median
75 Porsiyento
95 Porsiyento

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Kini ang datos gikan sa usa ka solusyon nga naggamit sa usa ka IPSEC tunnel pinaagi sa asya-sidlangan1. Pinaagi sa us-east4 ang mga sangputanan mas grabe, ug adunay daghang mga sayup, mao nga dili nako ihatag ang mga resulta.

Base sa mga resulta niini nga pagsulay sa duha ka tunnels, ang usa niini natapos sa labing duol nga rehiyon sa China, ug ang usa sa katapusan nga destinasyon, kini nahimong tin-aw nga kini mao ang importante nga "mogawas" gikan sa ilalum sa Chinese firewall sa labing madali. posible, ug dayon gamita ang paspas nga mga network (mga CDN providers, cloud providers, ug uban pa). Dili kinahanglan nga sulayan nga makalusot sa firewall ug makaabut sa imong padulngan sa usa ka pagdagan. Dili kini ang pinakapaspas nga paagi.

Sa kinatibuk-an, ang mga resulta dili daotan, bisan pa, ang semrush.com adunay median nga 8.8s, ug 75 Percentile 9.4s (sa parehas nga pagsulay).
Ug sa dili pa magpadayon, gusto ko nga maghimo usa ka mubo nga lyrical digression.

Ang lyrical digression

Human makasulod ang user sa site www.semrushchina.cn, nga nagsulbad pinaagi sa "paspas" nga mga Chinese DNS server, ang HTTP nga hangyo moagi sa among paspas nga solusyon. Ang tubag gibalik sa parehas nga agianan, apan ang domain gitino sa tanan nga mga script sa JS, mga panid sa HTML ug uban pang mga elemento sa panid sa web semrush.com alang sa dugang nga mga kahinguhaan nga kinahanglang ikarga kon ang panid mahubad. Sa ato pa, gisulbad sa kliyente ang "main" nga A-record www.semrushchina.cn ug moadto sa paspas nga tunel, dali nga makadawat usa ka tubag - usa ka panid sa HTML nga nag-ingon:

• i-download ang ingon ug ingon niana nga js gikan sa sso.semrush.com,
• Kuhaa ang CSS files gikan sa cdn.semrush.com,
• ug pagkuha usab og pipila ka mga hulagway gikan sa dab.semrush.com
• ug sa ingon sa.

Ang browser nagsugod sa pag-adto sa "gawas" nga Internet alang niini nga mga kapanguhaan, sa matag higayon nga moagi sa usa ka firewall nga mokaon sa oras sa pagtubag.

Apan ang miaging pagsulay nagpakita sa mga resulta kung walay mga kapanguhaan sa panid semrush.comnganung semrushchina.cn, ug *.semrushchina.cn nagsulbad sa adres sa virtual machine sa Shenzhen aron makasulod dayon sa tunnel.

Niini lamang nga paagi, pinaagi sa pagduso sa tanan nga posible nga trapiko hangtod sa labing kadaghan pinaagi sa imong solusyon alang sa dali nga pagpasa sa firewall sa China, mahimo nimong makuha ang madawat nga katulin ug mga timailhan sa pagkaanaa sa website, ingon man ang matinud-anon nga mga sangputanan sa mga pagsulay sa solusyon.
Gihimo namo kini nga walay bisan usa ka pag-edit sa code sa bahin sa produkto sa team.

Subfilter

Ang solusyon natawo hapit diha-diha dayon human kini nga problema mitumaw. Nagkinahanglan kami Ang PoC (Proof of Concept) nga ang among firewall penetration solutions nagtrabaho gyud og maayo. Aron mahimo kini, kinahanglan nimo nga ibalot ang tanan nga trapiko sa site sa kini nga solusyon kutob sa mahimo. Ug nag apply mi subfilter sa nginx.

Subfilter mao ang usa ka medyo yano nga module sa nginx nga nagtugot kanimo sa pag-usab sa usa ka linya sa tubag nga lawas ngadto sa laing linya. Busa giusab namo ang tanang panghitabo semrush.com sa semrushchina.cn sa tanang tubag.

Ug ... wala kini nagtrabaho tungod kay nakadawat kami og compressed content gikan sa backends, mao nga ang subfilter wala makakita sa gikinahanglan nga linya. Kinahanglan nakong idugang ang laing lokal nga server sa nginx, nga nag-decompress sa tubag ug gipasa kini sa sunod nga lokal nga server, nga nagkapuliki na sa pag-ilis sa string, pag-compress niini, ug gipadala kini sa sunod nga proxy server sa kadena.

Ingon usa ka sangputanan, asa makadawat ang kliyente .semrush.com, nakadawat siya .semrushchina.cn ug masinugtanong miagi sa among desisyon.

Bisan pa, dili igo nga usbon lang ang domain sa usa ka paagi, tungod kay ang mga backend nagpaabut gihapon sa semrush.com sa sunod nga mga hangyo gikan sa kliyente. Tungod niini, sa parehas nga server kung diin gihimo ang usa ka paagi nga pagpuli, gamit ang usa ka yano nga regular nga ekspresyon makuha namon ang subdomain gikan sa hangyo, ug dayon among buhaton proxy_pass uban sa variable $host, gipakita sa $subdomain.semrush.com. Kini daw makalibog, apan kini molihok. Ug kini molihok nga maayo. Para sa tagsa-tagsa nga mga dominyo nga nanginahanglan ug lain-laing lohika, paghimo lang sa imong kaugalingon nga mga bloke sa server ug paghimo og bulag nga configuration. Sa ubos gipamubu ang nginx configs alang sa katin-awan ug pagpakita niini nga laraw.

Ang mosunud nga config nagproseso sa tanan nga mga hangyo gikan sa China hangtod .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;
    }
}

Kini nga config proxy sa localhost sa port 83, ug ang mosunod nga config naghulat didto:

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

Akong balikon, kini mga giputol nga mga config.

Ingon niana. Mahimong komplikado kini tan-awon, apan kini sa mga pulong. Sa tinuud, ang tanan mas simple kaysa sa steamed turnips :)

Katapusan sa digression

Sa makadiyot nalipay kami tungod kay ang tumotumo bahin sa pagkahulog sa mga tunel sa IPSEC wala gikumpirma. Apan unya ang mga tunel nagsugod sa pagkahulog. Daghang beses sa usa ka adlaw sulod sa pipila ka minuto. Gamay ra, apan dili kana angay kanamo. Tungod kay ang duha ka tunnel gitapos sa Ali nga bahin sa parehas nga router, nakahukom kami nga tingali kini usa ka problema sa rehiyon ug kinahanglan namon nga ipataas ang backup nga rehiyon.

Gipunit nila kini. Ang mga tunnel nagsugod sa pagkapakyas sa lainlaing mga panahon, apan ang failover nagtrabaho og maayo alang kanamo sa taas nga lebel sa nginx. Apan ang mga tunnel nagsugod sa pagkahulog sa parehas nga oras 🙂 Ug ang 502 ug 504 nagsugod na usab. Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - kini ang koneksyon sa duha ka mga VPC gikan sa lainlaing mga rehiyon sa sulod sa Alibaba Cloud, nga mao, mahimo nimong ikonekta ang mga pribadong network sa bisan unsang mga rehiyon sa sulod sa panganod sa usag usa. Ug ang labing hinungdanon: kini nga channel adunay medyo estrikto SLA. Kini mao ang kaayo lig-on sa duha sa katulin ug sa uptime. Apan dili kini ingon ka yano:

• lisod kaayo makuha kung dili ka Chinese citizen o legal entity,
• Kinahanglan nimo nga bayran ang matag megabit sa bandwidth sa channel.

Adunay higayon nga makonektar Mainland China и sa gawas sa nasud, naghimo kami ug CEN tali sa duha ka rehiyon sa Ali: cn-shenzhen и us-sidlangan-1 (labing duol nga punto sa us-silangan4). Sa Ali us-sidlangan-1 gipataas ang laing virtual machine aron adunay usa pa hop.

Kini nahimong ingon niini:

Ang mga resulta sa pagsulay sa browser anaa sa ubos:

desisyon
Uptime
Median
75 Porsiyento
95 Porsiyento

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Ang pasundayag mas maayo kaysa IPSEC. Apan pinaagi sa IPSEC mahimo ka nga maka-download sa gikusgon nga 100 Mbit/s, ug pinaagi sa CEN lamang sa gikusgon nga 5 Mbit/s ug daghan pa.

Morag hybrid, di ba? Paghiusa sa katulin sa IPSEC ug kalig-on sa CEN.

Mao kini ang among gibuhat, nga gitugotan ang trapiko pinaagi sa IPSEC ug CEN kung adunay kapakyasan sa tunel sa IPSEC. Ang oras sa pag-abut nahimong labi ka taas, apan ang katulin sa pag-load sa site labi pa nga gitinguha. Dayon akong gidrowing ang tanang mga sirkito nga nagamit na namo ug nasulayan, ug nakahukom nga sulayan nga magdugang ug gamay pa nga GCP niini nga sirkito, nga mao takup.

takup

takup Mao ba Global Load Balancer (o Google Cloud Load Balancer). Kini adunay usa ka importante nga bentaha alang kanato: sa konteksto sa usa ka CDN kini adunay anycast IP, nga nagtugot kanimo sa pagruta sa trapiko sa data center nga labing duol sa kliyente, aron ang trapiko dali nga makasulod sa paspas nga network sa Google ug dili kaayo moagi sa "regular" nga Internet.

Sa walay paghunahuna sa makaduha, mibangon kami HTTP/HTTPS LB Gi-install namo ang among mga virtual machine nga adunay subfilter sa GCP ug isip backend.

Adunay daghang mga laraw:

• Paggamit Cloudflare China Network, apan niining higayona ang Origin kinahanglang maghisgot sa tibuok kalibotan IP GLB.
• Tapuson ang mga kliyente sa cn-shenzhen, ug gikan didto proxy ang trapiko direkta ngadto sa takup.
• Diretso gikan sa China paingon takup.
• Tapuson ang mga kliyente sa cn-shenzhen, gikan didto proxy ngadto sa asya-sidlangan1 pinaagi sa IPSEC (sa us-sidlangan4 pinaagi sa CEN), gikan didto moadto sa GLB (kalma, adunay usa ka litrato ug katin-awan sa ubos)

Gisulayan namon ang tanan niini nga mga kapilian ug daghan pa nga mga hybrid:

• Cloudflare + GLB

Kini nga laraw dili angay kanamo tungod sa oras sa oras ug mga sayup sa DNS. Apan ang pagsulay gihimo sa wala pa ang bug naayo sa CF nga bahin, tingali kini mas maayo karon (bisan pa, kini wala iapil ang HTTP timeouts).

• Ali + GLB

Kini nga laraw wala usab mohaum kanamo sa mga termino sa oras sa pag-up, tungod kay ang GLB kanunay nga nahulog gikan sa agos tungod sa imposible nga magkonektar sa usa ka madawat nga oras o oras, tungod kay alang sa usa ka server sa sulod sa China, ang adres sa GLB nagpabilin sa gawas, ug busa luyo sa Intsik nga firewall. Ang salamangka wala mahitabo.

• GLB lang

Usa ka kapilian nga susama sa nauna, wala lang kini gigamit ang mga server sa China mismo: ang trapiko diretso sa GLB (gibag-o ang mga rekord sa DNS). Tungod niini, ang mga resulta dili makatagbaw, tungod kay ang ordinaryong mga kliyente sa China nga naggamit sa mga serbisyo sa ordinaryo nga mga provider sa Internet adunay mas grabe nga sitwasyon sa pagpasa sa firewall kay sa Ali Cloud.

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

Dinhi nakahukom kami nga gamiton ang labing kaayo sa tanan nga mga solusyon:

• kalig-on ug garantiya nga SLA gikan sa CEN
• taas nga tulin gikan sa IPSEC
• Ang "paspas" nga network sa Google ug ang anycast niini.

Ang laraw ingon niini: ang trapiko sa gumagamit gitapos sa virtual machine sa ch-shenzhen. Ang Nginx upstreams gi-configure didto, ang pipila niini nagpunting sa mga pribadong IP server nga nahimutang sa pikas tumoy sa IPSEC tunnel, ug ang pipila ka upstreams nagpunting sa pribadong mga adres sa mga server sa pikas bahin sa CEN. Gi-configure ang IPSEC sa rehiyon asya-sidlangan1 sa GCP (mao ang labing duol nga rehiyon sa China sa panahon nga gihimo ang solusyon. Ang GCP karon adunay presensya usab sa Hong Kong). CEN - ngadto sa rehiyon us-sidlangan1 sa Ali Cloud.

Unya ang trapiko gikan sa duha ka tumoy gitumong ngadto sa anycast IP GLB, nga mao, ngadto sa labing duol nga punto sa presensya sa Google, ug miagi sa iyang mga network ngadto sa rehiyon us-sidlangan4 sa GCP, diin adunay mga kapuli nga virtual machine (nga adunay subfilter sa nginx).

Kini nga hybrid nga solusyon, sama sa among gipaabut, nagpahimulos sa mga benepisyo sa matag teknolohiya. Sa kinatibuk-an, ang trapiko moagi sa paspas nga IPSEC, apan kung ang mga problema magsugod, kami sa madali ug sa pipila ka mga minuto sipa kini nga mga server gikan sa upstream ug ipadala ang trapiko pinaagi lamang sa CEN hangtud nga ang tunnel mo-stabilize.

Pinaagi sa pagpatuman sa ika-4 nga solusyon gikan sa lista sa ibabaw, nakab-ot namo ang among gusto ug unsa ang gikinahanglan sa negosyo kanamo nianang puntoha sa panahon.

Mga resulta sa pagsulay sa browser alang sa bag-ong solusyon kumpara sa mga nauna:

desisyon
Uptime
Median
75 Porsiyento
95 Porsiyento

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

Maayo ang tanan sa solusyon nga atong gipatuman, apan walay CDN nga makapapaspas sa trapiko sa rehiyonal ug bisan sa lebel sa siyudad. Sa teorya, kinahanglan nga mapadali niini ang site para sa mga end user pinaagi sa paggamit sa paspas nga mga channel sa komunikasyon sa CDN provider. Ug kami naghunahuna mahitungod niini sa tanang panahon. Ug karon, miabot na ang panahon alang sa sunod nga pag-uli sa proyekto: pagpangita ug pagsulay sa mga tagahatag sa CDN sa China.

Ug isulti ko kanimo ang bahin niini sa sunod, katapusang bahin :)

Source: www.habr.com