Hoe't wy troch de Grutte Sineeske firewall bruts (diel 2)

Hallo!

Nikita is wer by dy, in systeemingenieur fan it bedriuw SEMrush. En mei dit artikel gean ik troch mei it ferhaal oer hoe't wy mei in oplossingsoplossing kamen Sineeske Firewall foar ús tsjinst semrush.com.

В foarige diel ik sei:

• hokker problemen ûntsteane neidat it beslút is makke "Wy moatte ús tsjinst yn Sina meitsje moatte"
• Hokker problemen hat it Sineeske ynternet?
• wêrom hawwe jo in ICP-lisinsje nedich?
• hoe en wêrom wy besletten om te testen ús testbêden mei Catchpoint
• wat wie it resultaat fan ús earste oplossing basearre op Cloudflare China Network
• Hoe't wy in brek fûn hawwe yn Cloudflare DNS

Dit diel is it meast nijsgjirrich, nei myn miening, om't it rjochtet op spesifike technyske ymplemintaasjes fan staging. En wy sille begjinne, of leaver trochgean, mei Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud is in frij grutte wolk provider, dy't hat alle tsjinsten dy't it mooglik meitsje om earlik neame himsels in wolk provider. It is goed dat se hawwe de mooglikheid om te registrearjen foar bûtenlânske brûkers, en dat it grutste part fan de side wurdt oerset yn it Ingelsk (foar Sina is dit in lúkse). Yn dizze wolk kinne jo wurkje mei in protte regio's fan 'e wrâld, fêstelân Sina, lykas Oseaanyske Azië (Hong Kong, Taiwan, ensfh.).

IPSEC

Wy begûnen mei geografy. Sûnt ús testside op Google Cloud lei, moasten wy Alibaba Cloud "keppelje" mei GCP, sadat wy in list mei lokaasjes iepene wêryn Google oanwêzich is. Op dat stuit hiene se noch gjin eigen datasintrum yn Hong Kong.
De tichtstbye regio blykte te wêzen Azië-east 1 (Taiwan). Ali die bliken de regio fan it fêstelân fan Sina it tichtst by Taiwan te wêzen cn-shenzhen (Shenzhen).

Mei help fan terraform beskreaun en ferhege de hiele ynfrastruktuer yn GCP en Ali. In 100 Mbit/s tunnel tusken de wolken gie hast fuort omheech. Oan 'e kant fan Shenzhen en Taiwan waarden proxying firtuele masines opbrocht. Yn Shenzhen wurdt brûkersferkear beëinige, proxed troch in tunnel nei Taiwan, en dêrwei giet it direkt nei it eksterne IP fan ús tsjinst yn wy-east (USA East Coast). Ping tusken firtuele masines fia tunnel 24ms, dat is net sa slim.

Tagelyk pleatsten wy in testgebiet yn Alibaba Cloud DNS. Nei't delegearre de sône oan NS Ali, resolúsje tiid fermindere fan 470 ms nei 50 ms. Dêrfoar wie de sône ek op Cloudlfare.

Parallel mei de tunnel oan Azië-east 1 ferhege in oare tunnel út Shenzhen direkt nei wy east4. Dêr makken se mear proxy-firtuele masines en begûnen beide oplossingen te testen, testferkear troch te stjoeren mei Cookies as DNS. De testbank wurdt skematysk beskreaun yn 'e folgjende figuer:

De latency foar tunnels die bliken as folget:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint-blêdertests rapporteare poerbêste ferbettering.

Fergelykje testresultaten foar twa oplossingen:

beslút
Uptime
Median
75 Persintyl
95 Persintyl

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Dit is gegevens fan in oplossing dy't brûkt in IPSEC tunnel fia Azië-east 1. Troch us-east4 wiene de resultaten slimmer, en d'r wiene mear flaters, dus ik sil de resultaten net jaan.

Op grûn fan 'e resultaten fan dizze test fan twa tunnels, wêrfan ien wurdt beëinige yn' e tichtstbye regio nei Sina, en de oare op 'e einbestimming, waard dúdlik dat it wichtich is om sa gau te "ûntkommen" ûnder de Sineeske brânmuorre as mooglik, en brûk dan flugge netwurken (CDN-oanbieders, wolkproviders, ensfh.). D'r is gjin need om te besykjen om troch de firewall te kommen en yn ien klap nei jo bestimming te kommen. Dit is net de fluchste manier.

Yn it algemien, de resultaten binne net min, lykwols, semrush.com hat in mediaan fan 8.8s, en 75 Percentile 9.4s (op deselde test).
En foardat ik fierder gean, wol ik in koarte lyryske ôfwiking meitsje.

Lyryske ôfwiking

Neidat de brûker komt de side www.semrushchina.cn, dy't oplost fia "snelle" Sineeske DNS-tsjinners, giet it HTTP-fersyk troch ús snelle oplossing. It antwurd wurdt op itselde paad weromjûn, mar it domein is spesifisearre yn alle JS-skripts, HTML-siden en oare eleminten fan 'e webside semrush.com foar ekstra boarnen dy't moatte wurde laden as de side wurdt werjûn. Dat is, de kliïnt oplost it "haad" A-record www.semrushchina.cn en giet yn 'e snelle tunnel, krijt fluch in antwurd - in HTML-side dy't stelt:

• download sa en sa js fan sso.semrush.com,
• Krij de CSS-bestannen fan cdn.semrush.com,
• en nim ek wat foto's fan dab.semrush.com
• ensafuorthinne.

De browser begjint nei it "eksterne" ynternet te gean foar dizze boarnen, elke kear troch in firewall troch te gean dy't de reaksjetiid opvreet.

Mar de foarige test lit de resultaten sjen as d'r gjin boarnen binne op 'e side semrush.comallinnich semrushchina.cn, en *.semrushchina.cn oplost nei it adres fan 'e firtuele masine yn Shenzhen om dan yn' e tunnel te kommen.

Allinich op dizze manier kinne jo akseptabele snelheden en yndikatoaren foar beskikberens fan webside krije, lykas earlike resultaten fan oplossingstests, troch alle mooglike ferkear nei it maksimum troch jo oplossing te drukken foar it fluch trochjaan fan 'e Sineeske firewall.
Wy diene dit sûnder ien inkelde koade-bewurking oan 'e produktkant fan it team.

Subfilter

De oplossing waard berne hast fuortendaliks nei dit probleem boppe. Wy hienen nedich PoC (Proof of Concept) dat ús oplossings foar firewallpenetraasje echt goed wurkje. Om dit te dwaan, moatte jo al it sideferkear safolle mooglik yn dizze oplossing ynpakke. En wy hawwe oanfrege subfilter yn ngx.

Subfilter is in frij ienfâldige module yn nginx wêrmei jo ien rigel yn it antwurd lichem te feroarjen nei in oare rigel. Sa hawwe wy alle foarfallen feroare semrush.com op semrushchina.cn yn alle antwurden.

En ... it wurke net om't wy komprimearre ynhâld krigen fan 'e efterkanten, dus subfilter fûn de fereaske line net. Ik moast in oare lokale tsjinner taheakje oan nginx, dy't it antwurd dekomprimearre en trochjûn oan de folgjende lokale tsjinner, dy't al dwaande wie om de tekenrige te ferfangen, te komprimearjen en it nei de folgjende proxy-tsjinner yn 'e keten te stjoeren.

As gefolch, wêr soe de kliïnt ûntfange .semrush.com, hy krige .semrushchina.cn en hearrich rûn troch ús beslút.

It is lykwols net genôch om it domein gewoan op ien manier te feroarjen, om't de backends noch semrush.com ferwachtsje yn folgjende oanfragen fan 'e kliïnt. Dêrtroch krije wy op deselde tsjinner wêr't de ien-wei ferfanging wurdt dien, mei in ienfâldige reguliere útdrukking it subdomein fan it fersyk, en dan dogge wy proxy_pass mei fariabele $host, tentoansteld yn $subdomain.semrush.com. It kin lykje betiizjend, mar it wurket. En it wurket goed. Foar yndividuele domeinen dy't ferskillende logika nedich binne, meitsje gewoan jo eigen serverblokken en meitsje in aparte konfiguraasje. Hjirûnder binne ynkoarte nginx-konfiguraasjes foar dúdlikens en demonstraasje fan dit skema.

De folgjende konfiguraasje ferwurket alle oanfragen fan Sina nei .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;
    }
}

Dizze konfiguraasje proxies nei localhost nei poarte 83, en de folgjende konfiguraasje wachtet dêr:

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

Ik werhelje, dit binne bysnijde konfiguraasjes.

Fyn dat leuk. It kin lykje yngewikkeld, mar it is yn wurden. Yn feite is alles ienfâldiger dan gestoomde raap :)

Ein fan digression

In skoft wiene wy ​​bliid om't de myte oer fallende IPSEC-tunnels net befêstige waard. Mar doe begûnen de tunnels te fallen. Ferskate kearen deis foar in pear minuten. In bytsje, mar dat paste ús net. Om't beide tunnels oan 'e Ali-kant op deselde router waarden beëinige, hawwe wy besletten dat dit miskien in regionaal probleem wie en wy moasten de reservekopyregio ferheegje.

Se pakten it op. De tunnels begûnen op ferskate tiden te mislearjen, mar de failover wurke goed foar ús op streamopnivo yn nginx. Mar doe begûnen de tunnels sawat op deselde tiid te fallen 🙂 En 502 en 504 begûnen wer. Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - dit is de ferbining fan twa VPC's út ferskate regio's binnen Alibaba Cloud, dat is, jo kinne privee netwurken fan elke regio yn 'e wolk mei elkoar ferbine. En it wichtichste: dit kanaal hat in frij strang SLA. It is heul stabyl sawol yn snelheid as uptime. Mar it is noait sa ienfâldich:

• it is heul lestich te krijen as jo gjin Sineeske boargers binne of in juridyske entiteit,
• Jo moatte betelje foar elke megabit fan kanaalbânbreedte.

De kâns hawwe om te ferbinen Mainland China и Overseas, hawwe wy in CEN makke tusken twa Ali-regio's: cn-shenzhen и us-east-1 (dichtste punt nei us-east4). Yn Ali us-east-1 in oare firtuele masine opbrocht sadat der ien mear is hop.

It kaam sa út:

De resultaten fan de browsertest binne hjirûnder:

beslút
Uptime
Median
75 Persintyl
95 Persintyl

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

De prestaasje is wat better as IPSEC. Mar fia IPSEC kinne jo mooglik downloade mei in snelheid fan 100 Mbit / s, en fia CEN allinich mei in snelheid fan 5 Mbit / s en mear.

Klinkt as in hybride, krekt? Kombinearje IPSEC-snelheid en CEN-stabiliteit.

Dit is wat wy dien hawwe, wêrtroch ferkear fia sawol IPSEC as CEN yn gefal fan in mislearring fan 'e IPSEC-tunnel. Uptime is folle heger wurden, mar de snelheid fan it laden fan 'e side lit noch folle te winskjen oer. Doe tekene ik alle circuits dy't wy al brûkt en hifke hiene, en besleat om te besykjen in bytsje mear GCP ta te foegjen oan dit circuit, nammentlik hoed.

hoed

hoed Is Global Load Balancer (of Google Cloud Load Balancer). It hat in wichtich foardiel foar ús: yn 'e kontekst fan in CDN hat it anycast IP, wêrmei jo ferkear nei it datasintrum it tichtst by de klant kinne routerje, sadat ferkear fluch yn it rappe netwurk fan Google komt en minder troch it "gewoane" ynternet giet.

Sûnder twa kear nei te tinken hawwe wy grutbrocht HTTP/HTTPS LB Wy ynstalleare ús firtuele masines mei subfilter yn GCP en as backend.

D'r wiene ferskate regelingen:

• Brûke Cloudflare China Network, mar dizze kear moat Origin global oantsjutte IP GLB.
• Beëinigje kliïnten by cn-shenzhen, en dêrwei proxy it ferkear direkt nei hoed.
• Gean direkt út Sina nei hoed.
• Beëinigje kliïnten by cn-shenzhen, fan dêr proxy nei Azië-east 1 fia IPSEC (yn wy east4 fia CEN), gean dêrwei nei GLB (rêstich, d'r sil in foto en útlis hjirûnder wêze)

Wy testen al dizze opsjes en ferskate mear hybride:

• Cloudflare + GLB

Dit skema paste ús net fanwegen uptime en DNS-flaters. Mar de test waard útfierd foardat de brek waard reparearre oan 'e CF-kant, miskien is it no better (dit slút HTTP-timeouts lykwols net út).

• Ali + GLB

Dit skema paste ús ek net yn termen fan uptime, om't GLB faak út 'e streamop foel troch de ûnmooglikheid om te ferbinen yn in akseptabele tiid of time-out, om't foar in server yn Sina it GLB-adres bûten bliuwt, en dus efter de Sineeske firewall. De magy barde net.

• Allinnich GLB

In opsje fergelykber mei de foarige, allinich brûkte it gjin servers yn Sina sels: it ferkear gie direkt nei GLB (de DNS-records waarden feroare). Dêrtroch wiene de resultaten net befredigjend, om't gewoane Sineeske kliïnten dy't de tsjinsten brûke fan gewoane ynternetproviders in folle slimmer situaasje hawwe mei it trochjaan fan de firewall dan Ali Cloud.

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

Hjir hawwe wy besletten om de bêste fan alle oplossingen te brûken:

• stabiliteit en garandearre SLA út CEN
• hege snelheid fan IPSEC
• Google's "snelle" netwurk en syn anycast.

It skema sjocht der sa út: brûkersferkear wurdt beëinige op in firtuele masine yn ch-shenzhen. Nginx-upstreams wurde dêr konfigureare, wêrfan guon ferwize nei privee IP-tsjinners dy't oan it oare ein fan 'e IPSEC-tunnel lizze, en guon upstreams wize op priveeadressen fan servers oan' e oare kant fan 'e CEN. IPSEC konfigurearre foar regio Azië-east 1 yn GCP (wie de regio it tichtst by Sina op it momint dat de oplossing makke waard. GCP hat no ek in oanwêzigens yn Hong Kong). CEN - nei regio wy east1 yn Ali Cloud.

Doe waard ferkear fan beide úteinen rjochte anycast IP GLB, dat is, nei it tichtste punt fan oanwêzigens fan Google, en gie troch syn netwurken nei de regio wy east4 yn GCP, wêryn d'r ferfangende firtuele masines wiene (mei subfilter yn nginx).

Dizze hybride oplossing, lykas wy ferwachte, profitearre fan 'e foardielen fan elke technology. Yn it algemien, ferkear giet troch flugge IPSEC, mar as problemen begjinne, wy fluch en foar in pear minuten traapje dizze tsjinners út de streamop en stjoere ferkear allinnich fia CEN oant de tunnel stabilisearret.

Troch de 4e oplossing út 'e boppesteande list te ymplementearjen, hawwe wy berikt wat wy woenen en wat it bedriuw op dat stuit fan ús easke.

Browsertestresultaten foar de nije oplossing yn ferliking mei eardere:

beslút
Uptime
Median
75 Persintyl
95 Persintyl

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

Alles is goed yn 'e oplossing dy't wy ynfierd hawwe, mar d'r is gjin CDN dy't it ferkear op regionaal en sels stedsnivo koe fersnelle. Yn teory moat dit de side foar ein brûkers fersnelle troch de snelle kommunikaasjekanalen fan 'e CDN-provider te brûken. En wy tochten der de hiele tiid oer. En no is de tiid kommen foar de folgjende iteraasje fan it projekt: sykjen en testen fan CDN-providers yn Sina.

En ik sil jo hjiroer fertelle yn it folgjende, lêste diel :)

Boarne: www.habr.com