Wie wir die Große Chinesische Firewall durchbrachen (Teil 2)

Hallo!

Nikita ist wieder bei Ihnen, ein Systemingenieur des Unternehmens SEMrush. Und mit diesem Artikel führe ich die Geschichte darüber fort, wie wir zu einer Workaround-Lösung gekommen sind Chinesische Firewall für unseren Service semrush.com.

В vorherigen Abschnitt Ich sagte:

• welche Probleme entstehen, nachdem die Entscheidung getroffen wurde: „Wir müssen dafür sorgen, dass unser Service in China funktioniert“
• Welche Probleme hat das chinesische Internet?
• Warum benötigen Sie eine ICP-Lizenz?
• wie und warum wir uns entschieden haben, unsere Testumgebungen mit Catchpoint zu testen
• Was war das Ergebnis unserer ersten Lösung auf Basis des Cloudflare China Network?
• Wie wir einen Fehler im Cloudflare-DNS gefunden haben

Dieser Teil ist meiner Meinung nach der interessanteste, da er sich auf spezifische technische Umsetzungen der Inszenierung konzentriert. Und wir werden damit beginnen, oder vielmehr fortfahren Alibaba-Wolke.

Alibaba-Wolke

Alibaba-Wolke ist ein ziemlich großer Cloud-Anbieter, der über alle Dienste verfügt, die es ihm ermöglichen, sich ehrlich als Cloud-Anbieter zu bezeichnen. Es ist gut, dass sie die Möglichkeit haben, sich für ausländische Benutzer zu registrieren, und dass der größte Teil der Website ins Englische übersetzt ist (für China ist das ein Luxus). In dieser Cloud können Sie mit vielen Regionen der Welt, dem chinesischen Festland sowie dem ozeanischen Asien (Hongkong, Taiwan usw.) arbeiten.

IPsec

Wir begannen mit Geographie. Da sich unsere Testseite in Google Cloud befand, mussten wir Alibaba Cloud mit GCP „verknüpfen“ und haben daher eine Liste der Standorte geöffnet, an denen Google präsent ist. Zu diesem Zeitpunkt verfügten sie noch nicht über ein eigenes Rechenzentrum in Hongkong.
Es stellte sich heraus, dass die nächstgelegene Region war asien-ost1 (Taiwan). Es stellte sich heraus, dass Ali die Region auf dem chinesischen Festland war, die Taiwan am nächsten lag cn-shenzhen (Shenzhen).

Mit Terraform beschrieben und die gesamte Infrastruktur in GCP und Ali angehoben. Fast augenblicklich entstand ein 100-Mbit/s-Tunnel zwischen den Wolken. Auf der Seite von Shenzhen und Taiwan wurden virtuelle Proxy-Maschinen eingeführt. In Shenzhen wird der Benutzerverkehr beendet, über einen Tunnel nach Taiwan weitergeleitet und von dort direkt zur externen IP unseres Dienstes weitergeleitet uns-osten (Ostküste der USA). Ping zwischen virtuellen Maschinen über Tunnel 24ms, was nicht so schlimm ist.

Gleichzeitig haben wir einen Testbereich angelegt Alibaba Cloud-DNS. Nach der Delegierung der Zone an NS Ali verringerte sich die Auflösungszeit von 470 ms auf 50 ms. Zuvor befand sich die Zone auch auf Cloudlfare.

Parallel zum Tunnel zu asien-ost1 baute einen weiteren Tunnel direkt von Shenzhen aus auf us-ost4. Dort erstellten sie weitere virtuelle Proxy-Maschinen und begannen, beide Lösungen zu testen, indem sie den Testverkehr mithilfe von Cookies oder DNS weiterleiteten. Der Prüfstand ist in der folgenden Abbildung schematisch beschrieben:

Es stellte sich heraus, dass die Latenz für Tunnel wie folgt war:
Ali cn-shenzhen <-> GCP asia-east1 – 24 ms
Ali cn-shenzhen <-> GCP us-east4 – 200 ms

Bei Catchpoint-Browsertests wurde eine hervorragende Verbesserung festgestellt.

Vergleichen Sie die Testergebnisse für zwei Lösungen:

Lösung
Betriebszeit
Median
75. Perzentil
95. Perzentil

Cloudflare
86.6
18er-Jahre
30er-Jahre
60er-Jahre

IPsec
99.79
18er-Jahre
21er-Jahre
30er-Jahre

Hierbei handelt es sich um Daten einer Lösung, die einen IPSEC-Tunnel über verwendet asien-ost1. Durch us-east4 waren die Ergebnisse schlechter und es gab mehr Fehler, daher werde ich die Ergebnisse nicht angeben.

Basierend auf den Ergebnissen dieses Tests zweier Tunnel, von denen einer in der nächstgelegenen Region zu China und der andere am Endziel endet, wurde deutlich, dass es wichtig ist, so schnell wie möglich unter der chinesischen Firewall „herauszukommen“. möglich, und nutzen Sie dann schnelle Netzwerke (CDN-Anbieter, Cloud-Anbieter usw.). Sie müssen nicht versuchen, die Firewall zu durchbrechen und auf einen Schlag an Ihr Ziel zu gelangen. Dies ist nicht der schnellste Weg.

Im Allgemeinen sind die Ergebnisse nicht schlecht, semrush.com hat jedoch einen Median von 8.8 Sekunden und das 75. Perzentil von 9.4 Sekunden (beim gleichen Test).
Und bevor ich weitermache, möchte ich noch einen kurzen lyrischen Exkurs machen.

Abschweifung

Nachdem der Benutzer die Site betritt www.semrushchina.cn, die über „schnelle“ chinesische DNS-Server aufgelöst wird, durchläuft die HTTP-Anfrage unsere schnelle Lösung. Die Antwort wird über denselben Pfad zurückgegeben, die Domäne wird jedoch in allen JS-Skripten, HTML-Seiten und anderen Elementen der Webseite angegeben semrush.com für zusätzliche Ressourcen, die beim Rendern der Seite geladen werden müssen. Das heißt, der Client löst den „Haupt“-A-Datensatz auf www.semrushchina.cn und geht in den Fast Tunnel, erhält schnell eine Antwort – eine HTML-Seite, die besagt:

• Laden Sie diese und jene js von sso.semrush.com herunter.
• Holen Sie sich die CSS-Dateien von cdn.semrush.com.
• und machen Sie auch ein paar Bilder von dab.semrush.com
• und so weiter.

Der Browser beginnt, für diese Ressourcen ins „externe“ Internet zu gehen, wobei er jedes Mal eine Firewall passiert, die Antwortzeit verschlingt.

Der vorherige Test zeigt jedoch die Ergebnisse, wenn auf der Seite keine Ressourcen vorhanden sind semrush.com, только semrushchina.cn, und *.semrushchina.cn löst sich in die Adresse der virtuellen Maschine in Shenzhen auf, um dann in den Tunnel zu gelangen.

Nur so können Sie akzeptable Geschwindigkeiten und Website-Verfügbarkeitsindikatoren sowie ehrliche Ergebnisse von Lösungstests erhalten, indem Sie den gesamten möglichen Datenverkehr maximal durch Ihre Lösung leiten, um die chinesische Firewall schnell zu passieren.
Wir haben dies ohne eine einzige Code-Änderung auf der Produktseite des Teams erreicht.

Unterfilter

Die Lösung wurde fast unmittelbar nach dem Auftauchen dieses Problems geboren. Wir brauchten PoC (Proof of Concept), dass unsere Firewall-Penetrationslösungen wirklich gut funktionieren. Dazu müssen Sie den gesamten Site-Verkehr so ​​weit wie möglich in diese Lösung einbinden. Und wir haben uns beworben Unterfilter in Nginx.

Unterfilter ist ein ziemlich einfaches Modul in Nginx, mit dem Sie eine Zeile im Antworttext in eine andere Zeile ändern können. Also haben wir alle Vorkommnisse geändert semrush.com auf semrushchina.cn in allen Antworten.

Und ... es hat nicht funktioniert, weil wir komprimierte Inhalte von den Backends erhalten haben, sodass der Unterfilter die erforderliche Zeile nicht gefunden hat. Ich musste einen weiteren lokalen Server zu nginx hinzufügen, der die Antwort dekomprimierte und an den nächsten lokalen Server weiterleitete, der bereits damit beschäftigt war, die Zeichenfolge zu ersetzen, zu komprimieren und an den nächsten Proxyserver in der Kette zu senden.

Als Ergebnis, wo würde der Kunde erhalten? semrush.com, er erhielt .semrushchina.cn und folgte gehorsam unserer Entscheidung.

Allerdings reicht es nicht aus, die Domain einfach nur in eine Richtung zu ändern, da die Backends bei nachfolgenden Anfragen des Clients immer noch semrush.com erwarten. Dementsprechend erhalten wir auf demselben Server, auf dem die unidirektionale Ersetzung erfolgt, mithilfe eines einfachen regulären Ausdrucks die Subdomäne aus der Anfrage und tun dies dann Proxy_pass mit Variable $ Gastgeber, ausgestellt in $subdomain.semrush.com. Es mag verwirrend erscheinen, aber es funktioniert. Und es funktioniert gut. Für einzelne Domänen, die eine andere Logik erfordern, erstellen Sie einfach Ihre eigenen Serverblöcke und nehmen Sie eine separate Konfiguration vor. Nachfolgend finden Sie zur Verdeutlichung und Demonstration dieses Schemas verkürzte Nginx-Konfigurationen.

Die folgende Konfiguration verarbeitet alle Anfragen aus China an .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;
    }
}

Diese Konfiguration wird als Proxy verwendet localhost auf Port 83, und dort wartet die folgende Konfiguration:

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

Ich wiederhole, das sind beschnittene Konfigurationen.

Ungefähr so. Es mag kompliziert aussehen, aber es ist in Worten. Tatsächlich ist alles einfacher als gedämpfte Rüben :)

Ende des Exkurses

Eine Zeit lang waren wir froh, weil sich der Mythos über einstürzende IPSEC-Tunnel nicht bestätigte. Doch dann begannen die Tunnel einzustürzen. Mehrmals täglich für ein paar Minuten. Ein bisschen, aber das hat uns nicht gepasst. Da beide Tunnel auf der Ali-Seite am selben Router endeten, kamen wir zu dem Schluss, dass es sich möglicherweise um ein regionales Problem handelte und wir die Backup-Region erhöhen mussten.

Sie haben es abgeholt. Die Tunnel begannen zu unterschiedlichen Zeiten auszufallen, aber das Failover funktionierte für uns auf der Upstream-Ebene in Nginx einwandfrei. Aber dann begannen die Tunnel ungefähr zur gleichen Zeit einzustürzen 🙂 Und 502 und 504 begannen erneut. Die Betriebszeit begann sich zu verschlechtern, also begannen wir, an der Option zu arbeiten Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - Dies ist die Konnektivität von zwei VPCs aus verschiedenen Regionen innerhalb der Alibaba Cloud, d. h. Sie können private Netzwerke beliebiger Regionen innerhalb der Cloud miteinander verbinden. Und das Wichtigste: Dieser Kanal ist ziemlich streng SLA. Es ist sowohl in der Geschwindigkeit als auch in der Betriebszeit sehr stabil. Aber so einfach ist es nie:

• Es ist SEHR schwierig, es zu bekommen, wenn Sie kein chinesischer Staatsbürger oder eine juristische Person sind.
• Sie müssen für jedes Megabit Kanalbandbreite bezahlen.

Die Möglichkeit haben, Kontakte zu knüpfen Festland China и Übersee, wir haben ein CEN zwischen zwei Ali-Regionen erstellt: cn-shenzhen и us-east-1 (nächster Punkt zu uns-ost4). Bei Ali us-east-1 eine weitere virtuelle Maschine angehoben, sodass noch eine vorhanden ist Hopfen.

Es stellte sich so heraus:

Nachfolgend finden Sie die Ergebnisse des Browsertests:

Lösung
Betriebszeit
Median
75. Perzentil
95. Perzentil

Cloudflare
86.6
18er-Jahre
30er-Jahre
60er-Jahre

IPsec
99.79
18er-Jahre
21er-Jahre
30er-Jahre

CEN
99.75
16er-Jahre
21er-Jahre
27er-Jahre

Die Leistung ist etwas besser als IPSEC. Über IPSEC können Sie jedoch möglicherweise mit einer Geschwindigkeit von 100 Mbit/s herunterladen, über CEN nur mit einer Geschwindigkeit von 5 Mbit/s und mehr.

Klingt nach einem Hybrid, oder? Kombinieren Sie IPSEC-Geschwindigkeit und CEN-Stabilität.

Dies haben wir getan, indem wir im Falle eines Ausfalls des IPSEC-Tunnels den Datenverkehr sowohl über IPSEC als auch über CEN zugelassen haben. Die Betriebszeit ist viel höher geworden, aber die Ladegeschwindigkeit der Website lässt immer noch zu wünschen übrig. Dann habe ich alle Schaltkreise gezeichnet, die wir bereits verwendet und getestet hatten, und beschlossen, zu versuchen, diesem Schaltkreis noch etwas mehr GCP hinzuzufügen, nämlich Deckel.

Deckel

Deckel - Das Globaler Load Balancer (oder Google Cloud Load Balancer). Für uns hat es einen wichtigen Vorteil: Im Kontext eines CDN schon Anycast-IP, wodurch Sie den Datenverkehr an das Rechenzentrum weiterleiten können, das dem Kunden am nächsten liegt, sodass der Datenverkehr schnell in das schnelle Netzwerk von Google gelangt und weniger über das „normale“ Internet geleitet wird.

Ohne lange nachzudenken, haben wir erhöht HTTP/HTTPS-LB Wir haben unsere virtuellen Maschinen mit Unterfilter in GCP und als Backend installiert.

Es gab mehrere Schemata:

• Zu verwenden Cloudflare China-Netzwerk, aber dieses Mal sollte Origin global angeben IP GLB.
• Kunden beenden um cn-shenzhenund von dort aus den Datenverkehr direkt weiterleiten Deckel.
• Gehen Sie direkt von China nach Deckel.
• Kunden beenden um cn-shenzhen, von dort Proxy zu asien-ost1 über IPSEC (in us-ost4 über CEN), von dort gehen Sie zu GLB (ruhig, es wird unten ein Bild und eine Erklärung geben)

Wir haben alle diese Optionen und einige weitere Hybridoptionen getestet:

• Cloudflare + GLB

Dieses Schema passte für uns aufgrund von Verfügbarkeits- und DNS-Fehlern nicht. Aber der Test wurde durchgeführt, bevor der Fehler auf der CF-Seite behoben wurde, vielleicht ist es jetzt besser (dies schließt jedoch HTTP-Timeouts nicht aus).

• Ali + GLB

Dieses Schema passte auch hinsichtlich der Betriebszeit nicht zu uns, da GLB oft aus dem Upstream herausfiel, weil es unmöglich war, in akzeptabler Zeit eine Verbindung herzustellen, oder aufgrund einer Zeitüberschreitung, da bei einem Server in China die GLB-Adresse außerhalb und daher hinter dem bleibt Chinesische Firewall. Die Magie ist nicht geschehen.

• Nur GLB

Eine ähnliche Option wie die vorherige, nur dass keine Server in China selbst verwendet wurden: Der Datenverkehr ging direkt an GLB (die DNS-Einträge wurden geändert). Dementsprechend waren die Ergebnisse nicht zufriedenstellend, da normale chinesische Kunden, die die Dienste gewöhnlicher Internetanbieter nutzen, eine viel schlechtere Situation beim Passieren der Firewall haben als Ali Cloud.

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

Hier haben wir uns für die beste aller Lösungen entschieden:

• Stabilität und garantiertes SLA von CEN
• hohe Geschwindigkeit durch IPSEC
• Das „schnelle“ Netzwerk von Google und sein Anycast.

Das Schema sieht in etwa so aus: Der Benutzerverkehr wird auf einer virtuellen Maschine beendet ch-shenzhen. Dort werden Nginx-Upstreams konfiguriert, von denen einige auf private IP-Server verweisen, die sich am anderen Ende des IPSEC-Tunnels befinden, und einige Upstreams verweisen auf private Adressen von Servern auf der anderen Seite des CEN. IPSEC für die Region konfiguriert asien-ost1 in GCP (war zum Zeitpunkt der Entwicklung der Lösung die Region, die China am nächsten lag. GCP ist jetzt auch in Hongkong vertreten). CEN - zur Region us-ost1 in Ali Cloud.

Dann wurde der Verkehr von beiden Enden dorthin geleitet Anycast IP GLB, also zum nächstgelegenen Präsenzpunkt von Google, und ging über seine Netzwerke in die Region us-ost4 in GCP, in dem es virtuelle Ersatzmaschinen gab (mit Unterfilter in Nginx).

Diese Hybridlösung nutzte erwartungsgemäß die Vorteile beider Technologien. Im Allgemeinen läuft der Datenverkehr über schnelles IPSEC, aber wenn es zu Problemen kommt, werfen wir diese Server schnell und für ein paar Minuten aus dem Upstream und senden den Datenverkehr nur über CEN, bis sich der Tunnel stabilisiert.

Durch die Implementierung der vierten Lösung aus der obigen Liste haben wir erreicht, was wir wollten und was das Unternehmen zu diesem Zeitpunkt von uns verlangte.

Browser-Testergebnisse der neuen Lösung im Vergleich zu den Vorgängern:

Lösung
Betriebszeit
Median
75. Perzentil
95. Perzentil

Cloudflare
86.6
18er-Jahre
30er-Jahre
60er-Jahre

IPsec
99.79
18er-Jahre
21er-Jahre
30er-Jahre

CEN
99.75
16er-Jahre
21er-Jahre
27er-Jahre

CEN/IPsec + GLB
99.79
13er-Jahre
16er-Jahre
25er-Jahre

CDN

Bei der von uns implementierten Lösung ist alles gut, aber es gibt kein CDN, das den Verkehr auf regionaler und sogar städtischer Ebene beschleunigen könnte. Theoretisch sollte dies die Website für Endbenutzer beschleunigen, indem die schnellen Kommunikationskanäle des CDN-Anbieters genutzt werden. Und wir haben die ganze Zeit darüber nachgedacht. Und jetzt ist die Zeit für die nächste Iteration des Projekts gekommen: die Suche und Prüfung von CDN-Anbietern in China.

Und davon werde ich euch im nächsten, letzten Teil erzählen :)

Source: habr.com