Quomodo perrupimus Magnus Firewall Sinarum (Part 2)

Salvete!

Nikita iterum tecum est, fectum systematis societatis SEMrush. Et in hoc articulo pergo fabulam quomodo ascendimus cum solutione quae habemus Seres Firewall pro nostro servitio semrush.com.

В prior pars Dixi:

• quae problemata oriuntur postquam decisio "Nos operam nostram navare opus est in Sinis".
• Quid Seres Internet difficultates habet?
• cur licentia ICP opus est?
• quomodo et quare decrevimus testbeds nostras probare cum Catchpoint?
• quis effectus primae solutionis nostrae in Cloudflare Sinis Network
• Quomodo invenimus cimex in Cloudflare DNS

Haec pars maxime interesting, mea sententia, est, quia ad specificas technicas scenas tendit. Et incipiemus vel potius permanebimus Cloud Alibaba.

Cloud Alibaba

Cloud Alibaba quaa est nubes provisor, qui habet omnia servitia quae sinit honeste vocari se nubem provisorem. Bonum est quod facultatem habent pro exteris utentibus subcriptio, et maxime situs in English translatum est (in Sinis haec luxuria est). In hac nube operari potes multis regionibus mundi, continenti Sinis, ac Asia Oceanica (Hong Kong, Taiwan, etc.).

IPSE

Cum geographia coepimus. Cum situs noster testatus in Google Cloud situs sit, necesse erat "link" Alibaba Cloud cum GCP, ideo indicem locorum in quo Google praesens est aperuimus. Eo momento in Hong Kong centrum suum nondum habebant.
Artissimum regionem conversus ad esse asia-east1 (Taiwan). Ali evasit proximam regionem continentis Sinis ad Taiwan cn-shenzhen (Shenzhen).

cum terraform totam infrastructuram GCP et Ali descripsit et erexit. C Mbit/s cuniculum inter nubes paene statim ascendit. In latere Shenzhen et Taiwan procurans machinas virtuales excitavit. In Shenzhen, commercium usoris terminatur, per cuniculum ad Taiwan proximatum, et inde directe ad IP nostrae servitutis externum accedit. us-orientis (USA East Coast). Ping inter virtualis machinis per cuniculum 24msquod non est ita malum.

Eodem tempore in area experimentum posuimus Alibaba Cloud DNS. Postquam zonam ad NS Ali delegavit, resolutio temporis decrevit ex 470 ms to . MS 50. Ante hoc etiam in Cloudlfare zona fuit.

Parallel ad cuniculum to asia-east1 alium cuniculum a Shenzhen directe to nos-east4. Ibi plus procuratorem virtualem machinis creaverunt et utramque solutionem probare coeperunt, examinibus negotiationum crustulas vel DNS excitandas. Probatorium scamnum schematically describitur in sequenti figura:

Cuniculorum latency hoc modo evasit;
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP nobis east4 — 200ms

Captura navigatoris probat emendationem optimam retulit.

Compare test eventus duabus solutionibus:

arbitrium
uptime
Medium
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Haec est notitia ex solutione quae per IPSEC cuniculum utitur asia-east1. Per nos-orientales eventus deteriores erant, et plures errores erant, ideo eventus non dabo.

Ex eventus huius probationis duorum cuniculorum, quorum alterum in proxima regione ad Sinas, alterum in ultima destinatione terminatur, clarum est magni momenti esse e sub firewall Sinensi quam celerrime emergere. fieri potest, et tunc retiacula ieiunium (CDN provisores, nubes provisores, etc.). Non opus est ut per firewall conetur et in uno lapsu ad destinatum tuum pervenias. Non hoc modo celerrime.

In genere, eventus non sunt mali, sed semrush.com mediana 8.8s habet, et 75 Percentile 9.4s (in eodem test).
Ac antequam progrediar, brevem lyrici digressionem facere velim.

digressus

Post user intrat locum www.semrushchina.cnquae per "celeriter" DNS servientes Sinenses resolvit, postulatio HTTP per solutionem ieiunium nostram percurrit. Responsum redditur per eandem viam, sed in omnibus scriptoribus JS, HTML paginis aliisque elementis interretialis specificatur regio semrush.com pro additis facultatibus, quae pagina reddita onerari debent. Id est, cliens solvit "main" A-recordum www.semrushchina.cn et in cuniculum celeriter it, celeriter responsionem accipit - pagina HTML quae asserit:

• download talis et talis js ex sso.semrush.com,
• Accipere files CSS ex cdn.semrush.com,
• et etiam imagines quasdam ex dab.semrush.com sumo
• et ita in.

Navigatorium ad "externum" interretialem has facultates ire incipit, quoties per firewall quod tempus responsionis devorat transiens.

Sed prior probatio eventus ostendit quando nullae sunt facultates in pagina semrush.comtantum semrushchina.cnet *.semrushchina.cn inscriptioni machinae virtualis in Shenzhen resolvit ut tunc in cuniculum ingrediaris.

Tantum hoc modo, omnia negotia possibilia ad maximum impellendo per solutionem tuam ut cito firewall Sinensem transeat, gratum celeritates et indices disponibilitates website obtinere potes, sicut et probatus solutionis eventus.
Hoc sine uno codice recensere fecimus in parte producti quadrigis.

Subfilter

Solutio fere statim nata est postquam hoc problema exsurrexerunt. Non opus est Poc (Probatio Conceptus) quod solutiones penetrationis nostrae fire bene operantur. Ad hoc faciendum, necesse est omnem locum negotiationis in hanc solutionem quam maxime involvere. Et applicavimus subfilter in nginx.

Subfilter satis simplex modulus est in nginx qui permittit ut lineam unam mutes in corpore responsionis ad lineam aliam. Ita mutavimus omnia semrush.com on semrushchina.cn in omnibus responsa.

Et... non operabatur quia compressum contentum a posterioribus recipiebamus, ideo subfilter lineam inquisitam non invenit. Habui alium servo locali nginx addere, quae responsionem decompressit et transmisit in proximum loci cultorem, qui chorda iam occupatus reponens, comprimens eam et ad proximum procuratorem in catena mittens.

Quam ob rem ubi client accipere .semrush.com, accepit .semrushchina.cn et obedienter per nostrum arbitrium ambulavimus.

Nihilominus, non satis est uno modo simpliciter mutare dominium, quia backends adhuc exspectant semrush.com in petitionibus subsequentibus clientis. Itaque in eodem servo, ubi unus modus subrogatur, adhibito simplici expressione regulari subdomain petito obtinemus, ac deinde facimus. proxy_pass cum variabilis $ hostexhibitum in $subdomain.semrush.com. Videri potest confundere, sed agit. Et bene operatur. Singulae ditiones quae logicam diversam requirunt, solum tuum servo cuneos crea et configurationem separatum. Infra minuuntur nginx confis ad claritatem et demonstrationem huius schematis.

Sequenti aboutconfig processus omnes petitiones ex Sinis to .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;
    }
}

Hoc aboutconfig proxies to localhost ad portum 83, and the following config ibi moratur;

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

Haec, inquam, decerpta sunt confis.

Sicut quod. Sit vide voluptua at, sit in vocibus. Omnia enim simpliciora rapa vapore :)

Finis digressionis

Aliquamdiu laeti eramus quod fabula de cuniculis IPSE lapsis non confirmata est. Sed tunc cuniculos incidere coeperunt. Aliquoties die paulisper. Paulo minus, sed nobis non convenit. Cum ambo cuniculi in Ali parte in eodem itinere terminarentur, decrevimus fortasse hanc quaestionem regionalem esse et ad tergum regionis levandum opus esse.

Et sustulerunt eam. Cuniculi diversis temporibus deficere coeperunt, sed fallax bene nobis in flumine nginx laboravit. Sed tunc cuniculis inceperunt eodem fere tempore Et 502 et 504 iterum inceperunt. Uptime degenerare incepimus, sic in optione cum operari coepimus Alibaba CEN (Nubis Enterprise Network).

CEN

CEN - haec est nexus duorum VPCsorum e diversis regionibus in Alibaba Cloud, id est, retia privata cuiuslibet regionum intra nubem inter se coniungere potes. Maximeque: hic canalis satis stricte habet SLA. Valde stabilis est tam in celeritate quam in uptime. Sed nunquam illud simplex est;

• Difficillimum est obtinere, si cives Sinenses aut legales non sint;
• Sed pretium varius megabit eget.

Habens facultatem ad coniungere continenti Sinis и Marecreavimus CEN inter duas regiones Ali; cn-shenzhen и us-orientis 1 (proxima punctum ad nos east4). in Ali us-orientis 1 aliam virtualem machinam ut sit unum hop.

Contigit sic:

Proventus explorationis navigatri infra sunt:

arbitrium
uptime
Medium
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Paulo melius quam IPSE perficientur. Sed per IPEC potentialiter ad celeritatem 100 Mbit/s detrahi potes, et per CEN tantum ad celeritatem 5 Mbit/s et plus.

Hybrid sonat, vox? IPSE CERTA celeritatem et CEN firmitatem.

Hoc est quod fecimus, commercium tam IPEC quam CEN praebens in casu defectus ipsEC cuniculi. Uptime facta est multo altior, sed situs loading celeritatis adhuc multum desideratum relinquit. Tunc omnes circuitus quos iam usi sumus et expertos duxi, et paulo plura GCP huic ambitu addere conari decrevi, nempe. GLB.

GLB

GLB - eam Global Load Balancer (vel Google Cloud Load Balancer). Magnum nobis commodum habet: in contextu CDN habet anycast IP, quae te permittit ut negotiatio ad centrum datorum proxime clientium perveniat, ut celeriter negotiatio in retiacula Google velociter inveniat et minus per "ordinarium" Internet percurrat.

Sine bis cogitando, ereximus HTTP/HTTPS LB Machinationes virtuales nostras constituimus cum subfilter in GCP et quasi backend.

Consilia varia fuerunt;

• ad usum Cloudflare Sina Network, sed hoc tempore Originem denotare debet globalem IP GLB.
• Terminate ad clients cn-shenzhen, et inde procuratorem negocii directe ad GLB.
• Protinus ex Sinis ad GLB.
• Terminate ad clients cn-shenzhen, inde procuratorem asia-east1 per IPEC (in* nos-east4 per CEN), inde ad GLB (placide, imago et explicatio infra erit)

Haec omnia bene temptavimus et plura hybrida;

• Cloudflare + GLB

Quae res nobis non convenit propter errores uptime et DNS. Sed probatio ante cimex fixa in CF parte facta est, fortasse nunc melius est (tamen hoc HTTP timeouts non excludit).

• Ali + GLB

Hoc schema etiam nobis in terminis uptime non convenit, cum GLB saepe e flumine decidit ob impossibilitatem connectendi in tempore accepto vel de tempore, quod pro servo intra Sinas, oratio GLB foris manet, et ideo post. Seres firewall. Magica non fuit.

• GLB solum

Optionem similem priori, modo non utebatur ministris in ipsa Sinis: commercium directe ad GLB perrexit (in DNS monumenta mutata sunt). Ideo eventus non satisfecit, cum clientes ordinarii Sinenses utentes servitiis provisoribus ordinariis interretialibus multo graviorem condicionem habent cum firewall transeundo quam Ali Cloud.

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

Hic optimas solutiones omnium uti decrevimus;

• stabilitatem et praestationem SLA a CEN .
• princeps celeritate ab IPEC
• Google reticulum "celeriter" et eius anycast.

Consilium aliquid spectat simile hoc: usor negotiationis terminatur super machinam virtualem ch-shenzhen. Fluvii Nginx ibi configurantur, quarum aliquae designant servientibus privatis IP in altero cuniculi IPSEC fine sito, et nonnulli rivi ad inscriptiones privatas ministrantium trans CEN. IPEC figuram habet ad regionem asia-east1 in GCP (erat proxima regio Sinae tempore solutionis creata. GCP nunc etiam praesentiam in Hong Kong habet). CEN - ad regionem nos-east1 in Ali Cloud.

Tum negotiatio utrinque directa est anycast IP GLB, id est in proxima praesentiae Google , et per retiacula in regionem nos-east4 in GCP, in quo substitutio machinae virtualis (cum subfilter in nginx).

Haec solutio hybrida, ut exspectavimus, utilitatum cuiusque technologiae usus est. In genere, negotiatio per IPSEC celeriter percurrit, sed si problemata committitur, celeriter et per aliquot minutas ministros e flumine calcitrare et mercaturam tantum per CEN mittis donec cuniculum stabiliat.

4 solutionem ex indice supra exsequendo, quid vellemus, et quid in illo puncto temporis a nobis requireret, confecimus.

Proventus exploratorii de navigatro ad solutionem novae solutionis cum prioribus comparatae:

arbitrium
uptime
Medium
75 Percentile
95 Percentile

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

£

Omnia bona sunt in solutione quam perficimus, sed nulla est CDN quae negotiatio accelerare potuit in regione regionali et etiam in gradu civitatis. In doctrina, hoc locum accelerare debet pro fine usorum utendo canales communicationis rapidi provisoris CDN. Et de hoc omni tempore duximus. Nunc, tempus venit ad proximam iterationem propositi: quaerendi et probandi CDN provisores in Sinis.

Et hoc tibi dicam in sequenti, ultima parte :)

Source: www.habr.com