Wéi mir duerch d'Grouss Firewall vu China gebrach hunn (Deel 2)

Hallo!

Nikita ass erëm mat Iech, e Systemingenieur vun der Firma SEMrush. A mat dësem Artikel fuere ech d'Geschicht weider iwwer wéi mir mat enger Léisung komm sinn Chinesesch Firewall fir eise Service semrush.com.

В virdrun Deel Ech soot:

• wéi eng Problemer entstinn nodeems d'Entscheedung getraff gëtt "Mir mussen eise Service a China maachen"
• Wéi eng Problemer huet de chinesesche Internet?
• firwat braucht Dir eng ICP Lizenz?
• wéi a firwat hu mir decidéiert eis Testbetter mat Catchpoint ze testen
• wat war d'Resultat vun eiser éischter Léisung baséiert op Cloudflare China Network
• Wéi mir e Feeler an Cloudflare DNS fonnt hunn

Dësen Deel ass déi interessantst, menger Meenung no, well et sech op spezifesch technesch Implementatioune vun der Inszenéierung konzentréiert. A mir fänken, oder éischter weider, mat Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud ass e relativ grousse Cloud Provider, deen all d'Servicer huet, déi et erlaben, sech éierlech e Cloud Provider ze nennen. Et ass gutt datt se d'Méiglechkeet hunn fir auslännesch Benotzer ze registréieren, an datt de gréissten Deel vum Site op Englesch iwwersat ass (fir China ass dëst e Luxus). An dëser Wollek kënnt Dir mat ville Regioune vun der Welt, Festland China, souwéi Oceanic Asien (Hong Kong, Taiwan, etc.) schaffen.

IPSEC

Mir hunn ugefaang mat Geographie. Zënter datt eisen Test Site op Google Cloud läit, musse mir Alibaba Cloud mat GCP "verlinken", also hu mir eng Lëscht vu Plazen opgemaach an deenen Google präsent ass. Dee Moment haten se nach keen eegenen Rechenzentrum zu Hong Kong.
Déi nootste Regioun huet sech erausgestallt Asien-Osten 1 (Taiwan). Den Ali huet sech als déi nootste Regioun vum Festland China zu Taiwan erausgestallt cn-Shenzhen (Shenzhen).

Mat der Hëllef vun Terraform beschriwwen an opgewuess déi ganz Infrastruktur am GCP an Ali. En 100 Mbit/s Tunnel tëscht de Wolleke goung bal direkt erop. Op der Säit vu Shenzhen an Taiwan goufen proxying virtuelle Maschinnen opgeworf. Zu Shenzhen gëtt de Benotzerverkéier ofgeschloss, duerch en Tunnel op Taiwan geschéckt, a vun do geet et direkt op déi extern IP vun eisem Service an eis-Osten (USA Ostküst). Ping tëscht virtuelle Maschinnen iwwer Tunnel 24ms, wat net esou schlecht ass.

Zur selwechter Zäit hu mir en Testberäich gesat Alibaba Cloud DNS. Nodeems d'Zone op NS Ali delegéiert gouf, ass d'Resolutiounszäit vun 470 ms op 50 ms. Virdru war d'Zon och op Cloudlfare.

Parallel zum Tunnel zu Asien-Osten 1 opgewuess aneren Tunnel aus Shenzhen direkt un eis-ost4. Do hunn se méi virtuelle Proxy Maschinnen erstallt an ugefaang béid Léisungen ze testen, Testverkéier mat Cookien oder DNS ze routeren. D'Testbänk gëtt schematesch an der folgender Figur beschriwwen:

Latency fir Tunnelen huet sech wéi follegt erausgestallt:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint Browser Tester hunn eng exzellent Verbesserung gemellt.

Vergläicht Testresultater fir zwou Léisungen:

Decisioun
Uptime
Median
75 Prozent
95 Prozent

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

Dëst sinn Daten vun enger Léisung déi en IPSEC Tunnel benotzt Asien-Osten 1. Duerch us-east4 waren d'Resultater méi schlëmm, an et goufe méi Feeler, also wäert ech d'Resultater net ginn.

Baséierend op d'Resultater vun dësem Test vun zwee Tunnelen, vun deenen een an der nooste Regioun zu China ofgeschloss ass, an deen aneren op der definitiver Destinatioun, gouf kloer datt et wichteg ass aus der chinesescher Firewall sou séier wéi méiglech ze "entstoen". méiglech, a benotzt dann séier Netzwierker (CDN Provider, Cloud Provider, etc.). Et ass net néideg ze probéieren duerch d'Firewall ze kommen an an engem Schlag op Är Destinatioun ze kommen. Dëst ass net de schnellsten Wee.

Am Allgemengen sinn d'Resultater net schlecht, awer semrush.com huet e Median vun 8.8s, an 75 Percentile 9.4s (am selwechten Test).
A ier ech weidergoen, wëll ech e kuerzen lyreschen Ausdrock maachen.

Lyresch Diffusioun

Nodeems de Benotzer de Site erakënnt www.semrushchina.cn, déi duerch "schnell" chinesesch DNS-Server léist, geet d'HTTP-Ufro duerch eis séier Léisung. D'Äntwert gëtt um selwechte Wee zréckginn, awer d'Domain gëtt an all JS Scripten, HTML Säiten an aner Elementer vun der Websäit spezifizéiert. semrush.com fir zousätzlech Ressourcen déi musse gelueden ginn wann d'Säit rendert gëtt. Dat ass, de Client léist den "Haapt" A-Rekord www.semrushchina.cn a geet an de séieren Tunnel, kritt séier eng Äntwert - eng HTML Säit déi seet:

• download esou an esou js vun sso.semrush.com,
• Kritt d'CSS Dateien vun cdn.semrush.com,
• an och e puer Biller vun dab.semrush.com
• an sou op.

De Browser fänkt un op den "externen" Internet fir dës Ressourcen ze goen, all Kéier duerch eng Firewall déi d'Äntwertzäit ësst.

Awer de fréiere Test weist d'Resultater wann et keng Ressourcen op der Säit sinn semrush.comnëmmen semrushchina.cn, an *.semrushchina.cn léist op d'Adress vun der virtueller Maschinn zu Shenzhen fir dann an den Tunnel ze kommen.

Nëmmen op dës Manéier, andeems Dir all méigleche Traffic op de Maximum duerch Är Léisung dréckt fir séier d'chinesesch Firewall ze passéieren, kënnt Dir akzeptabel Geschwindegkeeten a Websäit Disponibilitéitsindikatoren kréien, souwéi éierlech Resultater vu Léisungstester.
Mir hunn dëst ouni eng eenzeg Code Ännerung op der Produktsäit vum Team gemaach.

Subfilter

D'Léisung gouf bal direkt gebuer nodeems dëse Problem opgetaucht ass. Mir hunn gebraucht PoC (Proof of Concept) datt eis Firewall Penetratiounsléisungen wierklech gutt funktionnéieren. Fir dëst ze maachen, musst Dir de ganze Siteverkéier an dës Léisung sou vill wéi méiglech wéckelen. A mir hunn ugemellt subfilter an nginx.

Subfilter ass e relativ einfache Modul am nginx deen Iech erlaabt eng Zeil am Äntwertkierper op eng aner Linn z'änneren. Also hu mir all Optriede geännert semrush.com op semrushchina.cn an all Äntwerten.

An ... et huet net geschafft well mir kompriméiert Inhalter vun de Backends kruten, sou datt de Subfilter déi erfuerderlech Linn net fonnt huet. Ech hu missen en anere lokale Server op nginx addéieren, deen d'Äntwert dekompriméiert an op den nächste lokale Server weiderginn, dee scho beschäftegt war d'String ze ersetzen, ze kompriméieren an op den nächste Proxy-Server an der Kette ze schécken.

Als Resultat, wou géif de Client kréien semrush.com, krut hien .semrushchina.cn an ass gehorsam duerch eis Entscheedung gaangen.

Wéi och ëmmer, et ass net genuch fir den Domain einfach op eng Manéier z'änneren, well d'Backends ëmmer nach Semrush.com an de spéideren Ufroe vum Client erwaarden. Deementspriechend, um selwechte Server wou den Een-Wee Ersatz gemaach gëtt, mat engem einfachen reguläre Ausdrock kréien mir den Ënnerdomain vun der Ufro, an da maache mir proxy_pass mat variabelen $host, ausgestallt an $subdomain.semrush.com. Et kann duerchernee schéngen, mee et Wierker. An et funktionnéiert gutt. Fir eenzel Domainen déi aner Logik erfuerderen, erstellt einfach Är eege Serverblocken a maacht eng separat Konfiguratioun. Drënner sinn verkierzt nginx Konfiguratiounen fir Kloerheet an Demonstratioun vun dësem Schema.

Déi folgend Configuratioun veraarbecht all Ufroe vu China op .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;
    }
}

Dës Configuratioun proxéiert op localhost op den Hafen 83, an déi folgend Configuratioun waart do:

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

Ech widderhuelen, dëst sinn gekierzt Konfiguratiounen.

Esou. Et kann komplizéiert ausgesinn, awer et ass a Wierder. Tatsächlech ass alles méi einfach wéi gedämpfte Rüben :)

Enn vun der Digression

Eng Zäit laang ware mir frou, well de Mythos iwwer falen IPSEC-Tunnel net bestätegt gouf. Awer dunn hunn d'Tunnelen ugefaang ze falen. E puer Mol am Dag fir e puer Minutten. E bëssen, mä dat huet eis net gepasst. Well béid Tunnelen op der Ali Säit um selwechte Router ofgeschloss goufen, hu mir décidéiert datt dëst vläicht e regionale Problem war a mir mussen d'Backupregioun erhéijen.

Si hunn et opgeholl. D'Tunnel hunn ugefaang zu verschiddenen Zäiten ze versoen, awer de Failover huet gutt fir eis um Upstream Niveau an nginx geschafft. Awer dunn hunn d'Tunnel ongeféier zur selwechter Zäit ugefaang ze falen 🙂 An 502 an 504 hunn erëm ugefaang.D'Uptime huet ugefaang ze verschlechteren, also hu mir ugefaang un der Optioun ze schaffen Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - dëst ass d'Konnektivitéit vun zwee VPCs aus verschiddene Regioune bannent Alibaba Cloud, dat heescht, Dir kënnt privat Netzwierker vun all Regioun an der Wollek matenee verbannen. A virun allem: Dëse Kanal huet eng zimlech strikt SLA. Et ass ganz stabil souwuel a Geschwindegkeet wéi Uptime. Awer et ass ni sou einfach:

• et ass ganz schwéier ze kréien wann Dir keng chinesesch Bierger oder eng legal Entitéit sidd,
• Dir musst fir all Megabit Kanalkapazitéit bezuelen.

D'Méiglechkeet ze verbannen Festland China и iwwerséiesch, hu mir e CEN tëscht zwee Ali Regiounen erstallt: cn-Shenzhen и eis-Osten-1 (noosten Punkt un eis-Osten4). An Ali eis-Osten-1 eng aner virtuell Maschinn opgehuewe sou datt et eng méi ass hop.

Et huet sech esou erausgestallt:

D'Browser Testresultater sinn ënnendrënner:

Decisioun
Uptime
Median
75 Prozent
95 Prozent

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

CEN
99.75
16
21
27

D'Performance ass liicht besser wéi IPSEC. Awer duerch IPSEC kënnt Dir potenziell mat enger Geschwindegkeet vun 100 Mbit / s eroflueden, an duerch CEN nëmme mat enger Geschwindegkeet vu 5 Mbit / s a ​​méi.

Kléngt wéi en Hybrid, richteg? Kombinéiert IPSEC Geschwindegkeet an CEN Stabilitéit.

Dëst ass wat mir gemaach hunn, de Verkéier duerch souwuel IPSEC wéi CEN erlaabt am Fall vun engem Ausfall vum IPSEC Tunnel. Uptime ass vill méi héich ginn, awer d'Site Luedegeschwindegkeet léisst nach ëmmer vill ze wënschen. Dunn hunn ech all Circuiten gezeechent, déi mir scho benotzt a getest hunn, an hunn decidéiert, e bësse méi GCP zu dësem Circuit ze addéieren, nämlech Kap.

Kap

Kap Ass Global Load Balancer (oder Google Cloud Load Balancer). Et huet e wichtege Virdeel fir eis: am Kontext vun engem CDN huet et anycast IP, wat Iech erlaabt den Traffic an den Datenzenter am nootste vum Client ze routen, sou datt de Verkéier séier an de schnelle Netz vu Google kënnt a manner duerch de "reguläre" Internet geet.

Ouni zweemol ze denken, hu mir opgehuewen HTTP/HTTPS LB Mir hunn eis virtuell Maschinnen mat Ënnerfilter am GCP an als Backend installéiert.

Et waren e puer Schemaen:

• Ze benotzen Cloudflare China Network, mä dës Kéier Origin soll global uginn IP GLB.
• Ofschléissen Clienten um cn-Shenzhen, a vun do Proxy Verkéier direkt un Kap.
• Gitt direkt aus China op Kap.
• Ofschléissen Clienten um cn-Shenzhen, vun do Proxy zu Asien-Osten 1 iwwer IPSEC (eng eis-ost4 iwwer CEN), vun do aus op GLB (roueg, et gëtt eng Foto an Erklärung ënnert)

Mir hunn all dës Optiounen a verschidde méi Hybrid getest:

• Cloudflare + GLB

Dëse Schema huet eis net gepasst wéinst Uptime an DNS Feeler. Awer den Test gouf duerchgefouert ier de Feeler op der CF Säit fixéiert gouf, vläicht ass et elo besser (awer dëst schléisst HTTP-Timeouts net aus).

• Ali + GLB

Dëse Schema huet eis och net ugepasst wat d'Uptime ugeet, well GLB dacks aus dem Upstream gefall ass wéinst der Onméiglechkeet an enger akzeptabel Zäit oder Timeout ze verbannen, well fir e Server a China bleift d'GLB Adress dobaussen, an dofir hannert der Chinesesch Firewall. D'Magie ass net geschitt.

• Nëmmen GLB

Eng Optioun ähnlech wéi déi virdrun, nëmmen et huet keng Serveren a China selwer benotzt: de Traffic ass direkt op GLB gaangen (d'DNS records goufen geännert). Deementspriechend waren d'Resultater net zefriddestellend, well normale chinesesche Clienten, déi d'Servicer vun gewéinleche Internetprovider benotzen, eng vill méi schlëmm Situatioun hunn mam Passage vun der Firewall wéi Ali Cloud.

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

Hei hu mir beschloss déi bescht vun alle Léisungen ze benotzen:

• Stabilitéit a garantéiert SLA aus CEN
• héich Vitesse vun IPSEC
• Dem Google säi "schnell" Netzwierk a seng Anycast.

De Schema gesäit esou aus: de Benotzerverkéier gëtt op enger virtueller Maschinn ofgeschloss ch-Shenzhen. Nginx Upstreams sinn do konfiguréiert, vun deenen e puer op privat IP Serveren um aneren Enn vum IPSEC Tunnel weisen, an e puer Upstreams weisen op privat Adresse vu Serveren op der anerer Säit vum CEN. IPSEC zu Regioun konfiguréiert Asien-Osten 1 am GCP (war déi noosten Regioun zu China an der Zäit wou d'Léisung geschaf gouf. GCP huet elo och eng Präsenz zu Hong Kong). CEN - zu Regioun eis-ost1 an Ali Cloud.

Dunn gouf de Verkéier vu béide Säite geleet anycast IP GLB, dat ass, op den nootste Punkt vun Präsenz vu Google, an duerch seng Netzwierker an d'Regioun gaangen eis-ost4 am GCP, an deem et virtuelle Maschinnen ersat goufen (mat Ënnerfilter am nginx).

Dës Hybridléisung, wéi mir erwaart hunn, profitéiert vun de Virdeeler vun all Technologie. Am Allgemengen geet de Verkéier duerch séier IPSEC, awer wann d'Problemer ufänken, gi mir séier a fir e puer Minutten dës Serveren aus dem Upstream a schécken de Verkéier nëmmen duerch CEN bis den Tunnel stabiliséiert.

Duerch d'Ëmsetzung vun der Léisung 4 aus der Lëscht hei uewen hu mir erreecht wat mir wollten a wat d'Geschäft vun eis zu deem Zäitpunkt verlaangt huet.

Browser Testresultater fir déi nei Léisung am Verglach zu virdrun:

Decisioun
Uptime
Median
75 Prozent
95 Prozent

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

Alles ass gutt an der Léisung déi mir ëmgesat hunn, awer et gëtt keen CDN deen den Traffic um regionalen a souguer Stadniveau kéint beschleunegen. An Theorie soll dëst de Site fir Endbenotzer beschleunegen andeems Dir déi séier Kommunikatiounskanäle vum CDN Provider benotzt. A mir hunn déi ganzen Zäit driwwer geduecht. An elo ass d'Zäit komm fir déi nächst Iteratioun vum Projet: Sichen an testen CDN Ubidder a China.

An ech wäert Iech doriwwer am nächsten, leschten Deel soen :)

Source: will.com