{"id":35939,"date":"2019-10-31T22:07:41","date_gmt":"2019-10-31T19:07:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\/"},"modified":"2019-10-31T22:07:41","modified_gmt":"2019-10-31T19:07:41","slug":"kak-my-probivali-velikij-kitajskij-faervol-ch-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","title":{"rendered":"Wie wir die Gro\u00dfe Firewall von China \u00fcberwunden haben (Teil 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hallo zusammen!<\/p>\n<p><\/p>\n<p>Hier ist Nikita \u2013 Systemingenieur bei <strong>SEMrush<\/strong>. Heute erz\u00e4hle ich Ihnen, wie wir die Aufgabe bekamen, die Stabilit\u00e4t unseres Dienstes semrush.com in China zu gew\u00e4hrleisten und mit welchen Problemen wir w\u00e4hrend der Umsetzung konfrontiert waren (unter Ber\u00fccksichtigung des Standorts unseres Rechenzentrums an der Ostk\u00fcste der USA).<\/p>\n<p><\/p>\n<p>Das wird eine gro\u00dfe Geschichte, aufgeteilt in mehrere Artikel. Ich werde Ihnen erz\u00e4hlen, wie alles bei uns war: vom v\u00f6llig nicht funktionierenden Dienst aus China bis hin zu den Leistungskennzahlen des Dienstes auf dem Niveau seiner amerikanischen Version f\u00fcr Amerikaner. Ich verspreche, es wird interessant und n\u00fctzlich sein. Also, los geht's.<\/p>\n<p><\/p>\n<h2 id=\"problemy-kitayskogo-interneta\">Probleme des chinesischen Internets<\/h2>\n<p><\/p>\n<p>Selbst der entfernteste Mensch von den Besonderheiten der Netzwerkadministration hat zumindest einmal von <strong>der Gro\u00dfen Firewall von China<\/strong>geh\u00f6rt. Uuu, das klingt cool, oder? Aber was ist das, und wie funktioniert es wirklich \u2013 die Frage ist ziemlich kompliziert. Im Internet gibt es viele Artikel dar\u00fcber, aber aus technischer Sicht wurde die Funktionsweise dieser Firewall nirgendwo beschrieben. Was jedoch nicht verwunderlich ist. Ich gebe sofort zu, dass ich nach einem Jahr Arbeit nicht genau sagen kann, wie sie funktioniert, aber ich kann \u00fcber meine Beobachtungen und praktischen Schlussfolgerungen berichten. Und wir beginnen mit den Ger\u00fcchten \u00fcber diese Firewall.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Es gibt viele Ger\u00fcchte \u00fcber diese Firewall. Lassen Sie uns die wichtigsten und interessantesten von ihnen in einer Liste zusammenfassen:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter und \u00e4hnliche Dienste sind in China blockiert und funktionieren nicht.<\/li>\n<li>Der gesamte Datenverkehr, der aus China hinaus und in China hinein flie\u00dft, wird analysiert und bei verd\u00e4chtigem Datenverkehr mithilfe von maschinellem Lernen eingeschr\u00e4nkt, was ihn erheblich verlangsamt, wenn er die Grenze \u00fcberquert.<\/li>\n<li>Die chinesischen Geheimdienste knacken jeden verschl\u00fcsselten Datenverkehr, der durch ihre Firewall flie\u00dft.<\/li>\n<li>VPN-Tunnel und IPSEC-Tunnel sind instabil, fallen aus und werden st\u00e4ndig blockiert.<\/li>\n<li>Je einfacher die Verschl\u00fcsselung, desto einfacher die Passphrase, die zur Authentifizierung\/encryption des Datenverkehrs verwendet wird, desto schneller passiert sie die chinesische Firewall.<\/li>\n<\/ul>\n<p><\/p>\n<p>Das konnten wir \u00fcber diese Ger\u00fcchte herausfinden:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter und \u00e4hnliche Dienste sind tats\u00e4chlich blockiert (Ihre K.O.), aber viele technische Domains von Google, wie gstatic.com, sind nicht gesperrt und funktionieren. Daraus folgt, dass man nicht einfach alle scheinbar blockierten Google-Ressourcen wahllos entfernen sollte.<\/li>\n<li>Jeder Verkehr, der die Grenze passiert, f\u00fcgt seiner Zeit einen erheblichen Delay hinzu. Schauen Sie sich die beiden Ergebnisse an. Eine Website, eine Seite, einfacher GET <em>curl<\/em>\u2019m. Die erste Messung stammt aus China selbst (die sch\u00f6ne Stadt Shenzhen). Die zweite Messung kam von au\u00dferhalb aus Hongkong (hat Souver\u00e4nit\u00e4t, und zwischen ihm und der Au\u00dfenwelt gibt es keine Firewall). Die Entfernung zwischen den St\u00e4dten betr\u00e4gt in gerader Linie etwa 30-40 km.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"bash\">nikita@china-shenzhen:~# curl -o \/dev\/null -w@curl_time \"https:\/\/www.semrush.com\/info\/ebay.com\"\n  % Total    % Received % Xferd  Durchschnittsgeschwindigkeit   Zeit    Zeit     Zeit  Aktuell\n                                 Dload  Upload   Total   Verbraucht   Verbleibend  Geschwindigkeit\n100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832\ntime_namelookup:  0.004500\ntime_connect:  0.169342\ntime_appconnect:  0.723189\ntime_pretransfer:  0.723499\ntime_redirect:  0.000000\ntime_starttransfer:  1.532912\n----------\ntime_total:  5.443407\n----------\nsize_download:  390968 Bytes\nspeed_download:  71824.000B\/s\n\nnikita@china-hongkong:~# curl -o \/dev\/null -w@curl_time \"https:\/\/www.semrush.com\/info\/ebay.com\"\n  % Total    % Received % Xferd  Durchschnittsgeschwindigkeit   Zeit    Zeit     Zeit  Aktuell\n                                 Dload  Upload   Total   Verbraucht   Verbleibend  Geschwindigkeit\n100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k\ntime_namelookup:  0.029366\ntime_connect:  0.030742\ntime_appconnect:  0.047310\ntime_pretransfer:  0.047388\ntime_redirect:  0.000000\ntime_starttransfer:  0.120793\n----------\ntime_total:  0.124871\n----------\nsize_download:  326755 Bytes\nspeed_download:  2616740.000B\/s<\/code><\/pre>\n<p><\/p>\n<p>Achten Sie darauf, dass <strong>time_connect<\/strong>. Und insgesamt sehen Sie das Ergebnis: Die Firewall f\u00fcgt 4 zus\u00e4tzliche Sekunden hinzu, was monstr\u00f6s lange ist.<\/p>\n<p><\/p>\n<ul>\n<li>VPNs und IPSEC-Tunnel fallen tats\u00e4chlich oft aus. Dar\u00fcber werde ich sp\u00e4ter und ausf\u00fchrlicher sprechen. Die von Benutzern verwendeten VPN-Server werden im Laufe der Zeit blockiert (in der Regel innerhalb eines Tages nach Beginn der Nutzung). <\/li>\n<li>Es gibt die Meinung von Menschen, die in China leben, dass je einfacher die Verschl\u00fcsselung des Verkehrs ist, desto schneller passiert er die Grenze, weil es leicht zu erkennen ist, dass darin nichts Illegales enthalten ist. Ebenso erh\u00e4lt \"sauberer\" Verkehr mehr Bandbreite und Geschwindigkeit, w\u00e4hrend \"schmutziger\" Verkehr, der schwer verst\u00e4ndlich ist, im Gegenteil langsamer durchgef\u00fchrt wird. Zum Beispiel gebe ich curl bis <em>ifconfig.co<\/em> \u00fcber das Protokoll HTTPS und HTTP. <\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"bash\">curl -o \/dev\/null -w@curl_time \"https:\/\/ifconfig.co\/\"\n  % Gesamt  % Empfangen % \u00dcbertragen  Durchschnittliche Geschwindigkeit   Zeit    Zeit     Zeit  Aktuell\n                                 Herunterladen  Hochladen   Gesamt   Verbracht    Verbleibend  Geschwindigkeit\n100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3\ntime_namelookup:  0.004305\ntime_connect:  0.397465\ntime_appconnect:  5.149305\ntime_pretransfer:  5.149393\ntime_redirect:  0.000000\ntime_starttransfer:  5.568847\n----------\ntime_total:  5.568893\n----------\nGr\u00f6\u00dfe_download:  13 Bytes\nGeschwindigkeit_download:  2.000B\/s\n\ncurl -o \/dev\/null -w@curl_time \"http:\/\/ifconfig.co\/\"\n  % Gesamt  % Empfangen % \u00dcbertragen  Durchschnittliche Geschwindigkeit   Zeit    Zeit     Zeit  Aktuell\n                                 Herunterladen  Hochladen   Gesamt   Verbracht    Verbleibend  Geschwindigkeit\n100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28\ntime_namelookup:  0.004282\ntime_connect:  0.212457\ntime_appconnect:  0.000000\ntime_pretransfer:  0.212484\ntime_redirect:  0.000000\ntime_starttransfer:  0.450565\n----------\ntime_total:  0.450620\n----------\nGr\u00f6\u00dfe_download:  13 Bytes\nGeschwindigkeit_download:  28.000B\/s<\/code><\/pre>\n<p><\/p>\n<p>Der Unterschied von 5 Sekunden in der Gesamtdauer f\u00fcr den Download von 13 Bytes. Wenn man diesen Test mehrere Male durchf\u00fchrt, kann man feststellen, dass der GET-Befehl \u00fcber HTTP jedes Mal insgesamt in \u00e4hnlicher Zeit abgeschlossen wird, w\u00e4hrend die Antwortzeit bei HTTPS manchmal 3, 5, 10 und sogar 17 Sekunden betr\u00e4gt. Manchmal treten SSL-Fehler auf:<\/p>\n<p><\/p>\n<p><code>Unbekannter SSL-Protokollfehler bei der Verbindung zu ifconfig.co:443.<\/code><\/p>\n<p><\/p>\n<p>Also, was haben wir:<\/p>\n<p><\/p>\n<ul>\n<li>Die oben beschriebenen Probleme, die durch die chinesische Firewall verursacht werden.<\/li>\n<li>Pings zu externen Ressourcen und innerhalb von Tunneln fallen gelegentlich aus.<\/li>\n<li>Die Latenz zwischen zwei Punkten variiert st\u00e4ndig und ist oft einfach unvorhersehbar. Wenn man verschiedene St\u00e4dte\/Regionen verbindet, erwartet man aufgrund der geografischen Lage der Regionen, dass die Verz\u00f6gerung geringer ist, erh\u00e4lt jedoch genau das Gegenteil. <\/li>\n<li>Das Internet und die Kommunikationskan\u00e4le funktionieren mal schnell, mal langsam. Hier gibt es einen gewissen Einfluss von Tageszeit und Wochentag, aber nicht immer.<\/li>\n<li>DNS-Anfragen aus China ins Ausland \u00fcberschreiten manchmal das erlaubte Timeout.<\/li>\n<\/ul>\n<p><\/p>\n<p>Das Bild ist einfach \u201egro\u00dfartig\u201d. <\/p>\n<p><\/p>\n<p>Wie ich bereits erw\u00e4hnt habe, befindet sich unser Rechenzentrum im Osten der USA, und SEMrush besteht aus Dutzenden von miteinander verbundenen Produkten, Backends, Frontends, Datenbanken, und all dies im Rechenzentrum und in der Cloud. Die Aufgabe f\u00fcr uns als Systemadministratoren war es, mit minimalem Aufwand schnell in China arbeiten zu k\u00f6nnen.<\/p>\n<p><\/p>\n<p>Wir mussten die wichtige Frage beantworten: Kann man mit minimalem Aufwand alle Probleme, die mit dem chinesischen Internet und der Firewall verbunden sind, auf Netzwerk-\/Cloud-\/Serverebene l\u00f6sen?<\/p>\n<p><\/p>\n<p>Wir haben mit dem Erhalt <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_ICP\"><strong>ICP<\/strong>-Lizenz<\/a><\/noindex>.<\/p>\n<p><\/p>\n<h2 id=\"icp-licenziya\">ICP-Lizenz<\/h2>\n<p><\/p>\n<p>Um unseren Service innerhalb Chinas (Festlandchina) hosten und Tests durchf\u00fchren zu k\u00f6nnen, muss man zuerst eine ICP-Lizenz f\u00fcr die Domain erhalten.<\/p>\n<p><\/p>\n<p>Wenn der Benutzertraffic Ihrer Website innerhalb von Festlandchina terminiert und Ihre Domain keine ICP-Lizenz hat, wird Ihr Traffic vom Anbieter\/Hosting blockiert. Interessanterweise wird in die ICP-Lizenz ein spezifischer Anbieter eingetragen, egal ob Cloudflare oder Alibaba Cloud. Daher k\u00f6nnen Sie, wenn Sie eine ICP-Lizenz f\u00fcr Cloudflare erhalten haben und Ihre Website dort hosten, nicht nahtlos zu Alibaba Cloud wechseln. Es m\u00fcssen zus\u00e4tzliche Hosting-Anbieter in diese Lizenz aufgenommen werden.<\/p>\n<p><\/p>\n<p>Nachdem wir die ICP-Lizenz f\u00fcr die Domain erhalten hatten, konnten wir spezifische technische Ideen und L\u00f6sungen entwickeln und umsetzen.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie-resheniy\">L\u00f6sungen testen<\/h2>\n<p><\/p>\n<p>Doch bevor wir direkt mit der Erstellung von Staging-Varianten beginnen, Drehregler drehen, die Leistung der Website und ihre Geschwindigkeit optimieren, m\u00fcssen wir ein Werkzeug f\u00fcr deren Tests ausw\u00e4hlen, um zu sehen, welche Ma\u00dfnahmen unsere Arbeit an der Website verbessern oder im Gegenteil verschlechtern.<\/p>\n<p><\/p>\n<p>Unser Testwerkzeug sollte zwei Hauptanforderungen erf\u00fcllen:<\/p>\n<p><\/p>\n<ul>\n<li>es sollte in der Lage sein, Tests aus China durchzuf\u00fchren,<\/li>\n<li>es sollte Browsertests durchf\u00fchren k\u00f6nnen.<\/li>\n<\/ul>\n<p><\/p>\n<p>So fanden wir <noindex><a rel=\"nofollow\" href=\"https:\/\/www.catchpoint.com\/\">Catchpoint<\/a><\/noindex>! Sie haben eine hervorragende Abdeckung von Testpunkten weltweit. In China k\u00f6nnen wir mit diesem Werkzeug auch Tests aus 100500 Provinzen durchf\u00fchren. In jeder Provinz gibt es mehrere verschiedene Anbieter + die M\u00f6glichkeit, <strong>Backbone<\/strong>-Tests (etwas wie eine virtuelle Maschine im Rechenzentrum) und <strong>Lastmile<\/strong>-Tests (so nah wie m\u00f6glich an den Nutzerbedingungen, auch bekannt als Arbeitsplatz). Die letzte Testart ist teurer.<\/p>\n<p><\/p>\n<p>Nachdem wir einen Jahresvertrag abgeschlossen hatten (weniger war nicht m\u00f6glich), begannen wir mit dem Studium des Werkzeugs. Offen gesagt waren wir angenehm \u00fcberrascht von seiner Funktionalit\u00e4t. Man kann starten:<\/p>\n<p><\/p>\n<ul>\n<li>DNS-Tests,<\/li>\n<li>Web-Tests (Browser, einfacher GET\/POST, Emulation eines mobilen Clients usw.),<\/li>\n<li>Transaktionspr\u00fcfungen (z.B. Login),<\/li>\n<li>API-Tests,<\/li>\n<li>Ping, Traceroute, NTP usw.<\/li>\n<\/ul>\n<p><\/p>\n<p>Man kann nicht alles aufz\u00e4hlen. Und das Wichtigste ist, dass jeder Test ziemlich gut angepasst werden kann, indem man eine Reihe von Headern und anderen Parametern hinzuf\u00fcgt. Am Ende erh\u00e4lt man eine riesige Menge an Informationen, die Ihren Test vollst\u00e4ndig beschreiben. Wenn wir \u00fcber das f\u00fcr uns Interessanteste sprechen (Browser-Tests), beinhaltet das Ergebnis:<\/p>\n<p><\/p>\n<ul>\n<li>Connect, Wait, Load, SSL, DNS-Zeit,<\/li>\n<li>TTFB, TTLB, Dokument vollst\u00e4ndig, Renderzeit, DOM-Ladung,<\/li>\n<li>Antwort (\u00e4hnlich der Zeit bis zum ersten Byte), Webseitenausgabe (\u00e4hnlich der Zeit bis zum letzten Byte),<\/li>\n<li>Alle Perzentile, Durchschnitt, Medianzeit<\/li>\n<li>usw.<\/li>\n<\/ul>\n<p><\/p>\n<p>Daher helfen alle diese Metriken hervorragend dabei, Ver\u00e4nderungen zu sehen und zu verstehen, ob es besser geworden ist. Wir haben haupts\u00e4chlich auf <strong>Response, Webpage Response, Median, 75 und 95 Perzentile<\/strong>. <\/p>\n<p><\/p>\n<p>Eine wichtige Frage, die von Anfang an in der Luft schwebte: <strong>Kann man Catchpoint vertrauen?<\/strong>? \u041e\u0442\u0440\u0430\u0436\u0430\u0435\u0442 \u043b\u0438 \u044d\u0442\u043e\u0442 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0440\u0435\u0430\u043b\u044c\u043d\u0443\u044e \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c \u0437\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u0441\u0430\u0439\u0442\u0430 \u0432 \u041a\u0438\u0442\u0430\u0435 \u0438\u0437 \u0440\u0430\u0437\u043d\u044b\u0445 \u0433\u043e\u0440\u043e\u0434\u043e\u0432 \u0438\u043b\u0438 \u0436\u0435 \u044d\u0442\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u043a\u0430\u043a\u043e\u0439-\u0442\u043e \u0442\u0435\u0441\u0442 \u0432 \u0432\u0430\u043a\u0443\u0443\u043c\u0435, \u043d\u0435 \u0438\u043c\u0435\u044e\u0449\u0438\u0439 \u043d\u0438\u0447\u0435\u0433\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 real user experience?<br \/>\nDas ist ein gro\u00dfes Problem, denn es ist in Russland fast unm\u00f6glich, zuverl\u00e4ssig zu erfahren, wie eine Website aus China funktioniert. Wenn man \u00fcber einen virtuellen Proxy zugreift, dauert das Laden der Website mehrere Minuten, was f\u00fcr Tests einfach inakzeptabel ist, deshalb bleibt als einzige manuelle Testm\u00f6glichkeit curl und einfache GET-Anfragen aus der Konsole mit Zeitmessung. Das hilft, weil dieser Test die Geschwindigkeit der Netzwerkl\u00f6sung gut widerspiegelt, und wenn es auch noch Browser-Tests gibt, ist es umso besser.<\/p>\n<p><\/p>\n<p>Sp\u00e4ter sind wir selbst nach China gereist und haben uns \u00fcberzeugt, dass <strong>man Catchpoint vertrauen kann, er spiegelt die tats\u00e4chlichen Geschwindigkeitswerte ziemlich genau wider.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"cloudflare-china-network\">Cloudflare China Network<\/h2>\n<p><\/p>\n<p>Da wir f\u00fcr die Hauptdomain semrush.com erfolgreich Cloudflare verwenden, haben wir uns entschieden, sofort ihre Funktion namens <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloudflare.com\/network\/china\/\">China Network<\/a><\/noindex>auszuprobieren. Diese Option wird nur f\u00fcr Enterprise-Websites auf gesonderte Anfrage und gegen zus\u00e4tzliche Geb\u00fchr aktiviert. Sie ist auch nur f\u00fcr Websites verf\u00fcgbar, die \u00fcber die entsprechende ICP-Lizenz verf\u00fcgen, in der Cloudflare als Anbieter aufgef\u00fchrt ist. Nach der Aktivierung steht dem Website-Betreiber das \"chinesische CDN\" von Cloudflare zur Verf\u00fcgung \u2013 der Datenverkehr aus den chinesischen Regionen wird am n\u00e4chstgelegenen PoP (Points of Presence) von CF abgewickelt und anschlie\u00dfend \u00fcber dessen Netzwerke oder die Netzwerke von Providern\/Partnern zum Ursprung weitergeleitet. <\/p>\n<p><\/p>\n<p>Das Schema dieser Testumgebung ist unten dargestellt.<\/p>\n<p><\/p>\n<p>F\u00fcr uns ist das eine wunderbare Option. Das bedeutet, dass die zweite Domain ebenfalls \u00fcber CF l\u00e4uft, was die Anzahl der in der Firma verwendeten L\u00f6sungen nicht erh\u00f6ht und auch die Infrastruktur kaum kompliziert.<\/p>\n<p><\/p>\n<p>Wir haben Browser-Tests durchgef\u00fchrt, und das ist dabei herausgekommen:<\/p>\n<p><\/p>\n<p>Die roten Rauten sind Testfehler. Die Fehler unten sind DNS-Fehler (resolve timeout). Die Fehler oben sind Timeouts.<\/p>\n<p><\/p>\n<p><em>Uptime: 86,6<br \/>\nMedian: 18s<br \/>\n75 Perzentil: 29,3s<br \/>\n95 Perzentil: 60s<\/em><\/p>\n<p><\/p>\n<p>Die Medianzeit, nachdem die Last von <em>reCaptcha<\/em> (ein Google-Dienst, der in China blockiert ist), sank von 28 auf 18 Sekunden. Dennoch sind das schreckliche Werte, wenn man ber\u00fccksichtigt, dass derselbe Test f\u00fcr semrush.com (aus den USA) f\u00fcr 95% der Nutzer (aus den USA) auf derselben Seite (statisch + dynamisch) weniger als 10 Sekunden ergab.<\/p>\n<p><\/p>\n<p>In jeden Test kann man hineingehen und schauen <em>Waterfall<\/em> und weitere detaillierte Parameter. Wir haben angefangen, die Ursachen der Fehler zu untersuchen, und w\u00e4hrend die Zeit\u00fcberschreitungen mehr oder weniger nachvollziehbar sind: Das Internet in China \u201espringt hin und her\u201c, weshalb die Geschwindigkeit der Verbindung und das Laden von Ressourcen aus dem Ausland instabil und unterschiedlich sind, hat uns die DNS-Fehler sehr \u00fcberrascht. Wir haben festgestellt, dass <em>PoP<\/em> bei Cloudflare tats\u00e4chlich in China sind, die Website-Adresse wird auf eine Anycast-IP aufgel\u00f6st, aber es werden amerikanische DNS-Server verwendet, weshalb die DNS-Anfragen gezwungen sind, die Grenze zu \u00fcberqueren, was manchmal zu Fehlern f\u00fchrt.<\/p>\n<p><\/p>\n<p>Nach Kl\u00e4rung dieser Frage mit CF stellte sich heraus, dass <strong>sie keine eigenen DNS-Server in China haben<\/strong>, und wann sie diese haben werden, ist noch unbekannt.<\/p>\n<p><\/p>\n<p>Daher haben wir beschlossen, nur die DNS von Cloudflare zu testen und die Betriebsweise von Cloudflare f\u00fcr unsere Website auf den Modus \u201e<strong>Nur DNS<\/strong>\u201c zu \u00e4ndern. Dies ist ein Modus, in dem Cloudflare den Traffic nicht durch sich selbst proxiert, was bedeutet, dass es keinen DDoS-Schutz, CDN und andere Funktionen bietet und im Modus eines normalen DNS-Servers arbeitet. <\/p>\n<p><\/p>\n<p>Dieser Stand ist schematisch im n\u00e4chsten Bild dargestellt. Im Bild sind die neu gewonnenen Erkenntnisse bez\u00fcglich der DNS-Server von Cloudflare hinter der Firewall ber\u00fccksichtigt.<\/p>\n<p><\/p>\n<p>Bei Catchpoint haben wir einfache GET-Tests (nicht browserbasiert) gestartet, die sehr viele Fehler zeigten. Der Grund daf\u00fcr waren die gleichen DNS-Fehler.<\/p>\n<p><\/p>\n<p>Wir haben damit begonnen, diese Fehler mit Hilfe von <em>dig<\/em> zu debuggen und festgestellt, dass bei der ersten Anfrage die Adresse korrekt bestimmt wird, aber bei wiederholten Anfragen erhalten wir immer wieder <em>SERVFAIL<\/em> und <em>nicht gefunden<\/em>. Warum pl\u00f6tzlich?<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn hat die Adresse 220.170.186.192\nHost semrushchina.cn nicht gefunden: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn hat die Adresse 220.170.186.192\nHost semrushchina.cn nicht gefunden: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn hat die Adresse 220.170.186.192\nHost semrushchina.cn nicht gefunden: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn hat die Adresse 220.170.186.192\nHost semrushchina.cn nicht gefunden: 2(SERVFAIL)<\/code><\/pre>\n<p><\/p>\n<p>Bei der direkten Anfrage an die NS-Server von Cloudflare gibt es diese Fehler nicht:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done\nVerwende Domain-Server:\nName: ray.ns.cloudflare.com.\nAdresse: 173.245.59.138#53\nAliase: \n\nsemrushchina.cn hat die Adresse 220.170.186.192\nsemrushchina.cn hat die Adresse 220.170.186.192\nVerwende Domain-Server:\nName: ray.ns.cloudflare.com.\nAdresse: 173.245.59.138#53\nAliase: \n\nsemrushchina.cn hat die Adresse 220.170.186.192\nsemrushchina.cn hat die Adresse 220.170.186.192<\/code><\/pre>\n<p><\/p>\n<p>Das bedeutet, das Problem liegt auf der Seite des \u201elokalen\u201c DNS-Servers oder des Anbieterservers.<br \/>\nEine weitere Untersuchung ergab, dass <em>SERVFAIL<\/em> wir bei der Aufl\u00f6sung <em>AAAA<\/em>-Eintr\u00e4ge erhalten. <\/p>\n<p><\/p>\n<p>Es stellte sich heraus, dass bei der Anfrage an Cloudflare <em>AAAA<\/em>-Eintrag, der nicht im Domain vorhanden ist, antwortete Cloudflare <em>A<\/em>-mit einer Fehlermeldung, die nicht den RFC entspricht. Deshalb gefiel das dem lokalen Resolver (<em>x.x.x.x<\/em>) nicht, und er antwortete <em>SERVFAIL<\/em>. In dem untenstehenden Protokoll ist dieses Verhalten deutlich zu sehen:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x\n\n; &lt;&gt; DiG 9.10.3-P4-Ubuntu &lt;&gt; -t AAAA semrushchina.cn @x.x.x.x\n;; globale Optionen: +cmd\n;; Antwort erhalten:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: SERVFAIL, id: 55467\n;; flags: qr rd ra; QUERY: 1, ANTWORT: 0, AUTHORITY: 0, ADDITIONAL: 1\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n;; FRAGE ABSCHNITT:\n;semrushchina.cn.               IN      AAAA\n\n;; Abfragezeit: 334 ms\n;; SERVER: x.x.x.x#53(x.x.x.x)\n;; WANN: Di. Aug 14 23:38:50 CST 2018\n;; MSG GR\u00d6SSE  empfangen: 44\n\nroot@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.\n\n; &lt;&gt; DiG 9.10.3-P4-Ubuntu &lt;&gt; -t AAAA semrushchina.cn @dana.ns.cloudflare.com.\n;; globale Optionen: +cmd\n;; Antwort erhalten:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 63944\n;; flags: qr aa rd; QUERY: 1, ANTWORT: 1, AUTHORITY: 0, ADDITIONAL: 1\n;; WARNUNG: Rekursion angefordert, aber nicht verf\u00fcgbar\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 512\n;; FRAGE ABSCHNITT:\n;semrushchina.cn.               IN      AAAA\n\n;; ANTWORT ABSCHNITT:\nsemrushchina.cn.        300     IN      A       220.170.186.192\n\n;; Abfragezeit: 185 ms\n;; SERVER: 173.245.58.105#53(173.245.58.105)\n;; WANN: Di. Aug 14 23:43:03 CST 2018\n;; MSG GR\u00d6SSE  empfangen: 60\n<\/code><\/pre>\n<p><\/p>\n<p>Wir haben einen Bug-Report an Cloudflare gesendet, und sie haben das nach einer Weile behoben. Es stellte sich als interessant heraus: Momentan gibt es in China immer noch keine Unterst\u00fctzung f\u00fcr IPv6, weshalb Cloudflare dort seine IPv6-Adresse nicht in der Antwort auf die Anfrage ausgeben konnte <em>AAAA<\/em>-Eintr\u00e4ge. Letztendlich wurde alles so gel\u00f6st, dass Cloudflare f\u00fcr China <em>NODATA<\/em> auf solche Anfragen antwortete.<\/p>\n<p><\/p>\n<p>So haben die DNS-Fehler in den Catchpoint-Tests deutlich abgenommen, aber nicht vollst\u00e4ndig. Auch die Timeouts sind nicht verschwunden:<\/p>\n<p><\/p>\n<p>Und wir begannen, nach einer anderen L\u00f6sung zu suchen. <\/p>\n<p><\/p>\n<p>Im n\u00e4chsten Teil erz\u00e4hle ich, wie wir die chinesische Cloud getestet haben <strong>Alibaba Cloud<\/strong>, wie wir mit ein wenig &#171;Magie&#187; von Nginx schnell PoC (Proof of Concept) L\u00f6sungen erstellen konnten, wie wir Multi-Cloud-L\u00f6sungen schufen, von denen eine letztendlich sehr geholfen hat, den Betrieb des Dienstes aus China zu beschleunigen.<\/p>\n<p><\/p>\n<p><strong>Bleiben Sie dran!<\/strong><\/p>\n<p><\/p>\n<h3 id=\"sleduyuschie-chasti\">N\u00e4chste Teile<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/semrush\/blog\/458840\/\">Teil 2<\/a><\/noindex><\/p>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/semrush\/blog\/458602\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0435\u0440\u0435\u0434 \u043d\u0430\u043c\u0438 \u0432\u0441\u0442\u0430\u043b\u0430 \u0437\u0430\u0434\u0430\u0447\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0438\u0441\u0430 semrush.com \u0432 \u041a\u0438\u0442\u0430\u0435, \u0438 \u0441 \u043a\u0430\u043a\u0438\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u043c\u044b \u0441\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0438\u0441\u044c \u0432 \u0445\u043e\u0434\u0435 \u0435\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f (\u0443\u0447\u0438\u0442\u044b\u0432\u0430\u044f \u043c\u0435\u0441\u0442\u043e\u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u043d\u0430\u0448\u0435\u0433\u043e \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0430 \u043d\u0430 \u0432\u043e\u0441\u0442\u043e\u0447\u043d\u043e\u043c \u043f\u043e\u0431\u0435\u0440\u0435\u0436\u044c\u0435 \u0421\u0428\u0410). \u042d\u0442\u043e \u0431\u0443\u0434\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f, \u0440\u0430\u0437\u0431\u0438\u0442\u0430\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35939","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u043f\u0440\u043e\u0431\u0438\u0432\u0430\u043b\u0438 \u0412\u0435\u043b\u0438\u043a\u0438\u0439 \u041a\u0438\u0442\u0430\u0439\u0441\u043a\u0438\u0439 \u0424\u0430\u0435\u0440\u0432\u043e\u043b (\u0447.1) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Wie wir die Gro\u00dfe Chinesische Firewall umgingen (Teil 1) | ProHoster","description":"Hallo zusammen! Hier ist Nikita - Systemingenieur bei SEMrush.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u043f\u0440\u043e\u0431\u0438\u0432\u0430\u043b\u0438 \u0412\u0435\u043b\u0438\u043a\u0438\u0439 \u041a\u0438\u0442\u0430\u0439\u0441\u043a\u0438\u0439 \u0424\u0430\u0435\u0440\u0432\u043e\u043b (\u0447.1) | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:07:41+00:00","article:modified_time":"2019-10-31T19:07:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35939","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:21:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:31","updated":"2026-01-22 01:21:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=35939"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35939\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=35939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=35939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=35939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}