Hallo!
Nikita ist wieder bei Ihnen - ein Systemingenieur von SEMrush . Und mit diesem Artikel setze ich die Geschichte fort, wie wir eine Lösung zur Umgehung der chinesischen Firewall für unseren Dienst semrush.com gefunden haben.
Im vorherigen Teil habe ich gesagt:
- Welche Probleme treten auf, nachdem eine Entscheidung getroffen wurde? „Wir müssen dafür sorgen, dass unser Service in China funktioniert.“
- Welche Probleme hat das chinesische Internet?
- Warum brauche ich eine ICP-Lizenz?
- wie und warum wir uns entschieden haben, unsere Prüfstände mit catchpoint zu testen
- Was war das Ergebnis unserer ersten Lösung, die auf Cloudflare China Network basiert?
- wie wir einen Fehler in DNS Cloudflare gefunden haben
Dieser Teil ist meiner Meinung nach der interessanteste, da er sich auf bestimmte technische Implementierungen der Inszenierung konzentriert. Und wir werden mit Alibaba Cloud beginnen oder vielmehr fortfahren.
Alibaba Wolke
Alibaba Cloud 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 bei ausländischen Nutzern zu registrieren, und dass der größte Teil der Website ins Englische übersetzt wurde (für China ist dies ein Luxus). In dieser Cloud können Sie mit vielen Regionen der Welt, dem chinesischen Festland sowie Ozeanien (Hongkong, Taiwan usw.) arbeiten.
IPSEC
Begonnen mit Geographie. Da sich unsere Testseite in Google Cloud befand, mussten wir Alibaba Cloud mit GCP „verknüpfen“, sodass wir eine Liste der Standorte öffneten, an denen Google präsent ist. Zu diesem Zeitpunkt hatten sie noch kein eigenes Rechenzentrum in Hongkong.
Die nächstgelegene Region war Asien-Ost1 (Taiwan). Ali hatte cn-shenzhen (Shenzhen) als die Taiwan am nächsten gelegene Region des chinesischen Festlandes.
Mithilfe von Terraform haben sie die gesamte Infrastruktur in GCP und Ali beschrieben und erhöht. Der 100-Mbit / s-Tunnel zwischen den Wolken stieg fast augenblicklich an. Auf der Seite von Shenzhen und Taiwan haben sie virtuelle Proxy-Maschinen aufgestellt. In Shenzhen wird der Benutzerverkehr beendet, durch einen Tunnel nach Taiwan geleitet und von dort direkt an das externe IP unseres Dienstes in den USA (Ostküste der USA) weitergeleitet. Pingen Sie zwischen Virtuals im 24-ms- Tunnel, was nicht so schlimm ist.
Gleichzeitig haben wir eine Testzone in Alibaba Cloud DNS platziert . Nach dem Delegieren 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 nach Asien-Ost1 wurde ein weiterer Tunnel von Shenzhen direkt nach USA -Ost4 errichtet . Dort erstellten sie mehr virtuelle Proxy-Maschinen und begannen, beide Lösungen zu messen und den Testverkehr mithilfe von Cookies oder DNS weiterzuleiten. Der Prüfstand ist in der folgenden Abbildung schematisch beschrieben:
Die Latenz für Tunnel ist wie folgt:
Ali cn-shenzhen <-> GCP Asien-Ost1 - 24ms
Ali cn-shenzhen <-> GCP us-east4 - 200ms
Catchpoint-Browsertests haben hervorragende Leistungsverbesserungen gemeldet.
Vergleichen Sie die Testergebnisse für die beiden Lösungen:
Dies sind die Lösungsdaten, die den IPSEC-Tunnel durch Asien-Ost1 verwenden . Durch us-east4 waren die Ergebnisse schlechter und es gab mehr Fehler, daher werde ich die Ergebnisse nicht angeben.
Nach den Ergebnissen dieses Tests, zwei Tunneln, von denen einer in der nächstgelegenen Region zu China und der andere am endgültigen Ziel endet, wurde klar, dass es wichtig ist, so schnell wie möglich unter der chinesischen Firewall hervorzukommen und dann schnelle Netzwerke (CDN-Anbieter) zu verwenden. , Cloud-Anbieter usw.). Sie müssen nicht auf einen Schlag versuchen, durch die Firewall zum Ziel zu gelangen. Dies ist nicht der schnellste Weg.
Im Allgemeinen sind die Ergebnisse nicht schlecht, jedoch hat semrush.com einen Median von 8,8 s und ein 75-Perzentil von 9,4 s (im selben Test).
Und bevor ich weitermache, möchte ich einen Exkurs machen.
Lyrischer Exkurs
Nachdem der Benutzer die Website www.semrushchina.cn besucht hat , die über die „schnellen“ chinesischen DNS-Server aufgelöst wird, durchläuft die HTTP-Anfrage unsere schnelle Lösung. Die Antwort wird auf die gleiche Weise zurückgegeben, aber in allen JS-Skripten, HTML-Seiten und anderen Elementen der Webseite wird die Domain semrush.com für zusätzliche Ressourcen angegeben, die beim Rendern der Seite geladen werden müssen. Das heißt, der Client löst den "Haupt" -Aufsatz von www.semrushchina.c n auf und geht in den schnellen Tunnel, erhält schnell eine Antwort - eine HTML-Seite, die besagt:
- Laden Sie diese und js von sso.semrush.com herunter.
- Nehmen Sie CSS-Dateien von cdn.semrush.com,
- und machen Sie mehr Bilder von dab.semrush.com
- usw.
Der Browser beginnt für diese Ressourcen, auf das „externe“ Internet zuzugreifen, und durchläuft jedes Mal eine Firewall, die die Antwortzeit verschlingt.
Im vorherigen Test werden die Ergebnisse jedoch angezeigt , wenn auf der Seite keine semrush.com- Ressourcen vorhanden sind, sondern nur semrushchina.cn und * .semrushchina.cn an die Adresse der virtuellen Maschine in Shenzhen aufgelöst werden, um später in den Tunnel zu gelangen.
Nur auf diese Weise können Sie akzeptable Geschwindigkeiten und Indikatoren für die Verfügbarkeit von Websites sowie ehrliche Ergebnisse von Testlösungen erhalten, indem Sie so viel Datenverkehr wie möglich durch Ihre Entscheidung, schnell durch die chinesische Firewall zu gelangen, werfen.
Wir haben dies ohne eine einzige Code-Bearbeitung auf der Seite der Team-Produkte getan.
Unterfilter
Die Lösung wurde fast unmittelbar nach dem Auftauchen dieses Problems geboren. Wir brauchten PoC (Proof of Concept), damit unsere Firewall-Pass-Lösungen wirklich gut funktionieren. Dazu müssen Sie den gesamten Datenverkehr zur Site in dieser Lösung maximieren. Und wir haben Subfilter in Nginx angewendet.
Subfilter ist ein ziemlich einfaches Modul in Nginx, mit dem Sie eine Zeile im Hauptteil einer Antwort auf eine andere Zeile ändern können. Deshalb haben wir alle Vorkommen von semrush.com in allen Antworten in semrushchina.cn geändert.
Und ... das hat nicht funktioniert, weil wir komprimierten Inhalt von den Backends erhalten haben, sodass der Subfilter die erforderliche Zeile nicht finden konnte. Ich musste nginx einen weiteren lokalen Server hinzufügen, der die Antwort erweiterte und an den nächsten lokalen Server weiterleitete, der bereits mit dem Ersetzen, Komprimieren und Übermitteln von Leitungen an den nächsten Proxy in der Kette befasst war.
Wenn der Kunde <subdomain> .semrush.com erhalten würde, würde er folglich <subdomain> .semrushchina.cn erhalten und unsere Entscheidung gehorsam durchgehen.
Es reicht jedoch nicht aus, nur die Domain in eine Richtung zu ändern, da die Backends bei nachfolgenden Anforderungen des Clients immer noch semrush.com erwarten. Dementsprechend erhalten wir auf demselben Server, auf dem das Ersetzen in eine Richtung erfolgt, mithilfe eines einfachen regulären Ausdrucks die Subdomain aus der Anforderung und führen dann proxy_pass mit der in $ subdomain.semrush.com festgelegten $ host- Variablen aus. Es mag verwirrend erscheinen, aber es funktioniert. Und es funktioniert gut. Für einzelne Domänen, die unterschiedliche Logik erfordern, erstellen sie einfach ihre Serverblöcke und nehmen eine separate Konfiguration vor. Nachfolgend finden Sie verkürzte Nginx-Konfigurationen, um dieses Schema zu verdeutlichen und zu demonstrieren.
Die folgende Konfiguration verarbeitet alle Anfragen von 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 an Port 83 an localhost weitergeleitet und wartet dort auf 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; } }
Auch dies sind zugeschnittene Konfigurationen.
Ungefähr so. Es mag kompliziert aussehen, aber es ist in Worten. In der Tat ist alles einfacher als gedämpfte Rübe :)
Das Ende des lyrischen Exkurses
Für eine Weile waren wir glücklich, weil der Mythos von fallenden IPSEC-Tunneln nicht bestätigt wurde. Aber dann begannen die Tunnel zu fallen. Mehrmals täglich für einige Minuten. Ein bisschen, aber es passte nicht zu uns. Da beide Tunnel auf der Ali-Seite auf demselben Router terminiert wurden, haben wir entschieden, dass dies möglicherweise ein regionales Problem ist und wir die Sicherungsregion erhöhen müssen.
Aufgenommen. Die Tunnel begannen zu unterschiedlichen Zeiten zu fallen, aber wir hatten ein fein abgestimmtes Failover auf der Upstream-Ebene in Nginx. Aber dann begannen die Tunnel ungefähr zur gleichen Zeit zu fallen :) Und wieder 502 und 504. Die Betriebszeit begann sich zu verschlechtern, also begannen wir, die Option mit Alibaba CEN (Cloud Enterprise Network) auszuarbeiten.
Cen
CEN ist die Konnektivität von zwei VPCs aus verschiedenen Regionen innerhalb der Alibaba Cloud, dh Sie können private Netzwerke aller Regionen innerhalb der Cloud miteinander verbinden. Und vor allem: Dieser Kanal hat eine ziemlich strenge SLA . Es ist sowohl in der Geschwindigkeit als auch in der Betriebszeit sehr stabil. Aber es ist noch nie so einfach:
- Es ist SEHR schwer zu bekommen, wenn Sie keine chinesischen Staatsbürger oder juristische Personen sind.
- Sie müssen für jedes Megabit Bandbreite bezahlen.
Mit der Möglichkeit, Festlandchina und Übersee zu verbinden, haben wir ein CEN zwischen zwei Ali-Regionen geschaffen: cn-shenzhen und us-east-1 (der nächstgelegene Punkt zu us-east4). In Ali us-east-1 haben sie eine weitere virtuelle Maschine angehoben, um einen weiteren Hop zu erhalten .
Es stellte sich so heraus:
Browser-Testergebnisse unten:
Die Leistung ist etwas besser als bei IPSEC. Über IPSEC können Sie jedoch möglicherweise mit einer Geschwindigkeit von 100 Mbit / s und über CEN nur mit einer Geschwindigkeit von 5 Mbit / s und teurer herunterladen.
Hybrid bittet, richtig? Kombinieren Sie IPSEC-Geschwindigkeit und CEN-Stabilität.
Dies haben wir getan, indem wir im Falle eines IPSEC-Tunnelabsturzes Verkehr durch IPSEC und CEN gelassen haben. Die Betriebszeit ist viel höher geworden, aber die Ladegeschwindigkeit der Site ist schlecht. Dann habe ich alle Schemata gezeichnet, die wir bereits verwendet und getestet haben, und beschlossen, diesem Schema etwas mehr GCP hinzuzufügen, nämlich GLB .
GLB
GLB ist der Global Load Balancer (oder Google Cloud Load Balancer). Für uns hat dies einen wichtigen Vorteil: Im Zusammenhang mit CDN verfügt es über eine Anycast-IP , mit der Sie den Datenverkehr zum Rechenzentrum weiterleiten können, das dem Client am nächsten liegt. Dadurch gelangt der Datenverkehr schneller und weniger über das „normale“ Internet zum schnellen Google-Netzwerk.
Ohne nachzudenken, haben wir HTTP / HTTPS LB auf GCP umgestellt und unsere virtuellen Maschinen mit Subfilter-Backend ausgestattet.
Es gab mehrere Schemata:
- Verwenden Sie Cloudflare China Network , aber dieses Mal gibt Origin die globale GLB-IP an .
- Beenden Sie Clients in cn-shenzhen und von dort aus den Proxy-Verkehr sofort an GLB .
- Fahren Sie direkt von China zum GLB .
- Beenden Sie Clients in cn-shenzhen , von dort über IPSEC nach Asien-Ost1 (in US -Ost4 über CEN), von dort zu GLB (ruhig, es wird unten ein Bild und eine Erklärung geben).
Wir haben alle diese und einige weitere Hybridoptionen getestet:
Dieses Schema war nicht für Verfügbarkeits- und DNS-Fehler geeignet. Der Test wurde jedoch durchgeführt, bevor der Fehler von CF behoben wurde. Vielleicht ist er jetzt besser (dies schließt jedoch HTTP-Zeitüberschreitungen nicht aus).
Dieses Schema war auch für die Verfügbarkeit nicht geeignet, da GLB häufig aus dem Upstream ausfiel, da keine Verbindung zu einem akzeptablen Zeitpunkt oder Zeitlimit hergestellt werden konnte, da für einen Server innerhalb Chinas die GLB-Adresse außerhalb und daher hinter der chinesischen Firewall verbleibt. Die Magie ist nicht passiert.
Eine Variante ähnlich der vorherigen, nur dass in China selbst keine Server verwendet wurden: Der Datenverkehr ging sofort an GLB (geänderte DNS-Einträge). Dementsprechend waren die Ergebnisse nicht zufriedenstellend, da gewöhnliche chinesische Kunden, die die Dienste gewöhnlicher Internetanbieter nutzen, eine viel schlimmere Situation beim Durchlaufen der Firewall haben als Ali Cloud.
- Shenzhen -> (CEN / IPSEC) -> Proxy -> GLB
Hier haben wir uns entschieden, die beste aller Lösungen zu verwenden:
- Stabilität und garantierte SLA von CEN
- hohe Geschwindigkeit von IPSEC
- Googles "schnelles" Netzwerk und sein Anycast.
Das Schema sieht ungefähr so aus: Der Benutzerverkehr wird auf einer virtuellen Maschine in ch-shenzhen beendet . Dort werden Nginx-Upstream-Einstellungen konfiguriert, von denen sich einige auf private IP-Server am anderen Ende des IPSEC-Tunnels und einige Upstream-Verbindungen zu privaten Serveradressen auf der anderen Seite des CEN beziehen. IPSEC wurde in GCP für die Region Asien-Ost1 konfiguriert (es war zum Zeitpunkt der Erstellung der Lösung die Region, die China am nächsten lag. Jetzt ist GCP auch in Hongkong präsent). CEN - in die Region us-east1 in Ali Cloud.
Darüber hinaus wurde der Datenverkehr von beiden Seiten an anycast IP GLB , dh an den nächstgelegenen Punkt der Google-Präsenz, geleitet und über seine Netzwerke in die Region us-east4 in GCP geleitet, in der virtuelle Ersatzmaschinen (mit Subfilter in nginx) vorhanden waren.
Diese Hybridlösung ermöglichte es uns erwartungsgemäß, jede Technologie zu nutzen. Im Allgemeinen wird der Datenverkehr schnell durch IPSEC geleitet. Wenn jedoch Probleme auftreten, werfen wir diese Server schnell und für einige Minuten aus dem Upstream und senden den Datenverkehr nur über CEN, bis sich der Tunnel stabilisiert hat.
Nachdem wir die vierte Lösung aus der obigen Liste implementiert hatten, erreichten wir, was wir wollten und was das Geschäft zu diesem Zeitpunkt von uns verlangte.
Browser-Testergebnisse für die neue Lösung im Vergleich zu den vorherigen:
Cdn
In der von uns implementierten Lösung ist alles in Ordnung, aber es gibt kein CDN, das den Verkehr auf der Ebene von Regionen und sogar Städten beschleunigen könnte. Theoretisch sollte dies die Site für Endbenutzer durch die Verwendung schneller Kommunikationskanäle des CDN-Anbieters beschleunigen. Und wir haben die ganze Zeit darüber nachgedacht. Und jetzt ist die Zeit für die nächste Iteration des Projekts gekommen: Suchen und Testen von CDN-Anbietern in China.
Und ich werde dir im nächsten, letzten Teil davon erzählen :)
Alle Teile
Teil 1
Teil 3