{"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\/fr\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","title":{"rendered":"Comment nous avons contourn\u00e9 le Grand Pare-feu Chinois (partie 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Bonjour \u00e0 tous !<\/p>\n<p><\/p>\n<p>En ligne, Nikita \u2014 ing\u00e9nieur syst\u00e8me de l'entreprise <strong>SEMrush<\/strong>. Aujourd'hui, je vais vous parler de la mani\u00e8re dont nous avons \u00e9t\u00e9 confront\u00e9s \u00e0 la t\u00e2che d'assurer la stabilit\u00e9 de notre service semrush.com en Chine, et des probl\u00e8mes que nous avons rencontr\u00e9s lors de sa r\u00e9alisation (\u00e9tant donn\u00e9 l'emplacement de notre centre de donn\u00e9es sur la c\u00f4te est des \u00c9tats-Unis).<\/p>\n<p><\/p>\n<p>Ce sera une longue histoire, divis\u00e9e en plusieurs articles. Je vais vous raconter comment tout cela s'est pass\u00e9 pour nous : d'un service compl\u00e8tement non fonctionnel en Chine \u00e0 des performances de service \u00e9quivalentes \u00e0 celles de sa version am\u00e9ricaine pour les Am\u00e9ricains. Je vous promets que cela sera int\u00e9ressant et utile. Alors, c'est parti.<\/p>\n<p><\/p>\n<h2 id=\"problemy-kitayskogo-interneta\">Les probl\u00e8mes d'Internet en Chine<\/h2>\n<p><\/p>\n<p>M\u00eame la personne la plus \u00e9loign\u00e9e des subtilit\u00e9s de l'administration r\u00e9seau a au moins entendu parler <strong>du Grand Firewall de Chine<\/strong>. Ouh, \u00e7a sonne bien, n'est-ce pas ? Mais qu'est-ce que c'est, comment cela fonctionne r\u00e9ellement \u2014 c'est une question assez complexe. On peut trouver de nombreux articles \u00e0 ce sujet sur Internet, mais du point de vue technique, le fonctionnement de ce pare-feu n'est d\u00e9crit nulle part. Ce qui n'est d'ailleurs pas surprenant. Je l'admets, au terme d'une ann\u00e9e de travail, je ne pourrai pas dire exactement comment cela fonctionne, mais je pourrai parler de mes observations et conclusions pratiques. Commen\u00e7ons donc par les rumeurs \u00e0 propos de ce pare-feu.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Il existe de nombreuses rumeurs \u00e0 propos de ce pare-feu. Regroupons les principales et les plus int\u00e9ressantes dans une liste :<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter et d'autres services similaires sont bloqu\u00e9s et ne fonctionnent pas en Chine.<\/li>\n<li>Tout le trafic entrant et sortant de la Chine est analys\u00e9 et restreint gr\u00e2ce \u00e0 l'apprentissage machine (en cas de trafic suspect), ce qui ralentit consid\u00e9rablement celui passant par la fronti\u00e8re.<\/li>\n<li>Les services de renseignement chinois piratent tout trafic chiffr\u00e9 passant par leur pare-feu.<\/li>\n<li>Les tunnels VPN et les tunnels IPSEC sont instables, tombent et sont constamment bloqu\u00e9s.<\/li>\n<li>Plus le chiffrement est simple, plus la phrase de passe utilis\u00e9e pour l'authentification\/chiffrement du trafic est simple, plus elle passe rapidement le pare-feu chinois.<\/li>\n<\/ul>\n<p><\/p>\n<p>Voici ce que nous avons pu d\u00e9terminer sur ces rumeurs :<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter et d'autres services similaires sont effectivement bloqu\u00e9s (votre K.O.), mais de nombreux domaines techniques de Google, par exemple, ne sont pas bloqu\u00e9s et fonctionnent (comme gstatic.com). Cela signifie qu'il ne faut pas supprimer sans discernement tous les ressources Google et autres qui semblent bloqu\u00e9es.<\/li>\n<li>Tout le trafic qui traverse la fronti\u00e8re ajoute en effet un temps de latence consid\u00e9rable. Regardez les deux r\u00e9sultats. Un site, une page, simple GET <em>curl<\/em>\u2019. La premi\u00e8re mesure vient directement de Chine (la magnifique ville de Shenzhen). La deuxi\u00e8me mesure provient de l'ext\u00e9rieur, de Hong Kong (qui a sa souverainet\u00e9, et il n'y a pas de pare-feu entre lui et le monde). La distance entre les villes est d'environ 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  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\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  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\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>Veuillez noter que <strong>time_connect<\/strong>. Et dans l'ensemble, vous voyez le r\u00e9sultat : le pare-feu ajoute 4 secondes suppl\u00e9mentaires, ce qui est incroyablement long.<\/p>\n<p><\/p>\n<ul>\n<li>Les VPN et les tunnels IPSEC tombent effectivement souvent. J'en parlerai plus en d\u00e9tail tout \u00e0 l'heure. Les serveurs VPN utilis\u00e9s par les utilisateurs se font bloquer avec le temps (g\u00e9n\u00e9ralement dans les 24 heures suivant le d\u00e9but de leur utilisation). <\/li>\n<li>Il y a une opinion formul\u00e9e par des personnes vivant en Chine, selon laquelle plus le chiffrement du trafic est simple, plus il traverse rapidement la fronti\u00e8re, car il est facile de comprendre qu'il n'y a rien d'ill\u00e9gal. De m\u00eame, le trafic 'propre' obtient plus de bande passante et de vitesse, tandis que le trafic 'sale', difficile \u00e0 interpr\u00e9ter, est plut\u00f4t ralenti. Par exemple, je vais faire un curl vers <em>ifconfig.co<\/em> via le protocole HTTPS et HTTP. <\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"bash\">curl -o \/dev\/null -w@curl_time \"https:\/\/ifconfig.co\/\"\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\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----------\nsize_download:  13 Bytes\nspeed_download:  2.000B\/s\n\ncurl -o \/dev\/null -w@curl_time \"http:\/\/ifconfig.co\/\"\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\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----------\nsize_download:  13 Bytes\nspeed_download:  28.000B\/s<\/code><\/pre>\n<p><\/p>\n<p>Une diff\u00e9rence de 5 secondes sur le temps total de t\u00e9l\u00e9chargement de 13 octets. En effet, en effectuant ce test plusieurs fois, on peut constater que le GET sur HTTP se termine toujours en un temps relativement constant, tandis que sur HTTPS, le site r\u00e9pond parfois en 3, 5, 10 et m\u00eame 17 secondes. Parfois, des erreurs SSL se produisent :<\/p>\n<p><\/p>\n<p><code>Erreur de protocole SSL inconnue lors de la connexion \u00e0 ifconfig.co:443.<\/code><\/p>\n<p><\/p>\n<p>Alors, que pouvons-nous conclure :<\/p>\n<p><\/p>\n<ul>\n<li>Les probl\u00e8mes caus\u00e9s par le pare-feu chinois, comme mentionn\u00e9 ci-dessus.<\/li>\n<li>Les pings vers des ressources externes et au sein des tunnels disparaissent de temps en temps.<\/li>\n<li>La latence entre deux points change constamment et est souvent impr\u00e9visible. En connectant diff\u00e9rentes villes\/r\u00e9gions, vous vous attendez \u00e0 ce que la latence soit plus faible en fonction de la disposition g\u00e9ographique des r\u00e9gions, mais vous obtenez exactement le r\u00e9sultat inverse. <\/li>\n<li>Internet et les canaux de communication fonctionnent parfois rapidement, parfois lentement. Il existe une l\u00e9g\u00e8re d\u00e9pendance \u00e0 l'heure de la journ\u00e9e et au jour de la semaine, mais ce n'est pas syst\u00e9matique.<\/li>\n<li>Les requ\u00eates DNS vers l'ext\u00e9rieur depuis la Chine d\u00e9passent parfois le d\u00e9lai d'attente autoris\u00e9.<\/li>\n<\/ul>\n<p><\/p>\n<p>Le tableau se dessine simplement \"excellent\". <\/p>\n<p><\/p>\n<p>Le centre de donn\u00e9es, comme je l'ai d\u00e9j\u00e0 dit, est situ\u00e9 dans l'est des \u00c9tats-Unis, et l'ensemble de SEMrush est compos\u00e9 de dizaines de produits interconnect\u00e9s, de back-ends, de front-ends, de bases de donn\u00e9es, le tout dans le DC et dans le cloud. Notre \u00e9quipe de syst\u00e9maticiens a re\u00e7u pour mission, avec un minimum d'efforts, de commencer rapidement \u00e0 travailler en Chine.<\/p>\n<p><\/p>\n<p>Nous devions r\u00e9pondre \u00e0 une question importante : pouvons-nous nous en sortir avec peu d'efforts et r\u00e9soudre tous les probl\u00e8mes li\u00e9s \u00e0 Internet et au pare-feu chinois au niveau des r\u00e9seaux\/des nuages\/des serveurs ?<\/p>\n<p><\/p>\n<p>Nous avons commenc\u00e9 par obtenir <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>une licence ICP<\/strong>-licence<\/a><\/noindex>.<\/p>\n<p><\/p>\n<h2 id=\"icp-licenziya\">Licence ICP<\/h2>\n<p><\/p>\n<p>Pour pouvoir h\u00e9berger votre service en Chine continentale et effectuer des tests, vous devez d'abord obtenir une licence ICP pour votre domaine.<\/p>\n<p><\/p>\n<p>Si le trafic utilisateur de votre site est interrompu dans le territoire de la Chine continentale et si votre domaine n'a pas de licence ICP, votre trafic sera bloqu\u00e9 par le fournisseur\/ h\u00e9bergeur. Il est int\u00e9ressant de noter que la licence ICP est li\u00e9e \u00e0 un fournisseur sp\u00e9cifique, qu'il s'agisse de Cloudflare ou d'Alibaba Cloud. Ainsi, si vous avez obtenu une licence ICP pour Cloudflare et h\u00e9berg\u00e9 votre site chez eux, il ne sera pas possible de migrer \u00ab sans solution \u00bb vers Alibaba Cloud par la suite. Il faudra ajouter un autre h\u00e9bergement \u00e0 cette licence.<\/p>\n<p><\/p>\n<p>Apr\u00e8s avoir obtenu la licence ICP pour le domaine, nous avons pu concevoir et mettre en \u0153uvre des id\u00e9es et des solutions techniques sp\u00e9cifiques.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie-resheniy\">Test des solutions<\/h2>\n<p><\/p>\n<p>Mais avant de commencer \u00e0 cr\u00e9er des variantes de staging, \u00e0 faire des ajustements, \u00e0 optimiser les performances et la vitesse du site, nous devons choisir un outil pour les tests afin de voir quelles actions am\u00e9liorent ou, au contraire, d\u00e9t\u00e9riorent les performances du site.<\/p>\n<p><\/p>\n<p>Notre outil de test devait r\u00e9pondre \u00e0 deux exigences principales:<\/p>\n<p><\/p>\n<ul>\n<li>il doit \u00eatre capable de lancer des tests depuis la Chine,<\/li>\n<li>il doit avoir des tests bas\u00e9s sur un navigateur.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ainsi, nous avons trouv\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.catchpoint.com\/\">Catchpoint<\/a><\/noindex>! Ils ont une excellente couverture des points de test \u00e0 travers le monde. Avec cet outil, il est \u00e9galement possible de lancer des tests depuis de nombreuses provinces en Chine. Dans chaque province, plusieurs fournisseurs diff\u00e9rents + possibilit\u00e9 de faire <strong>des tests Backbone (comme une sorte de machine virtuelle dans un centre de donn\u00e9es) et<\/strong>des tests Lastmile (au plus pr\u00e8s des conditions utilisateur, c'est-\u00e0-dire une station de travail). Ce dernier type de test co\u00fbte plus cher. <strong>Apr\u00e8s avoir sign\u00e9 un contrat d'un an (pas de contrat plus court), nous avons commenc\u00e9 \u00e0 \u00e9tudier l'outil. Il faut avouer que nous avons \u00e9t\u00e9 agr\u00e9ablement surpris par ses fonctionnalit\u00e9s. Il est possible de lancer:<\/strong>des tests DNS,<\/p>\n<p><\/p>\n<p>des tests Web (bas\u00e9s sur un navigateur, simple GET\/POST, \u00e9mulation d'un client mobile, etc.),<\/p>\n<p><\/p>\n<ul>\n<li>des v\u00e9rifications transactionnelles (par exemple, la connexion),<\/li>\n<li>des tests API,<\/li>\n<li>Ping, traceroute, NTP, etc.<\/li>\n<li>Il y a beaucoup de tests. Et surtout, chaque test peut \u00eatre assez bien personnalis\u00e9 en ajoutant une s\u00e9rie d'en-t\u00eates et d'autres param\u00e8tres. Le r\u00e9sultat est une \u00e9norme quantit\u00e9 d'informations d\u00e9crivant enti\u00e8rement votre test. En ce qui concerne ce qui nous int\u00e9resse le plus (tests bas\u00e9s sur le navigateur), le r\u00e9sultat comprend:<\/li>\n<li>Connect, Wait, Load, SSL, Temps DNS,<\/li>\n<\/ul>\n<p><\/p>\n<p>TTFB, TTLB, Document complet, Temps de rendu, Chargement DOM,<\/p>\n<p><\/p>\n<ul>\n<li>R\u00e9ponse (proche du Time To First Byte), R\u00e9ponse de page Web (proche du Time To Last Byte),<\/li>\n<li>Tous les percentiles, Temps moyen, M\u00e9diane<\/li>\n<li>Etc.<\/li>\n<li>Tous les percentiles, Moyenne, Temps m\u00e9dian<\/li>\n<li>Et cetera.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ainsi, toutes ces m\u00e9triques aident parfaitement \u00e0 voir les changements et \u00e0 comprendre si c'est mieux. Nous avons principalement examin\u00e9 <strong>Response, Webpage Response, M\u00e9diane, 75 et 95 Percentiles<\/strong>. <\/p>\n<p><\/p>\n<p>Une question importante qui a flott\u00e9 dans l'air depuis le d\u00e9but : <strong>Peut-on faire confiance \u00e0 Catchpoint ?<\/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 \/>\nC'est un gros probl\u00e8me, car en \u00e9tant en Russie, il est pratiquement impossible de savoir avec pr\u00e9cision comment un site fonctionne depuis la Chine. En utilisant des socks-proxy via une machine virtuelle, vous obtenez un chargement du site pendant plusieurs minutes, ce qui est inacceptable pour les tests, donc la seule option pour des tests manuels reste curl et de simples GET depuis la console avec mesure du temps. Cela aide car ce test refl\u00e8te bien la vitesse de la solution r\u00e9seau, et si des tests de navigateur sont \u00e9galement faits, c'est encore mieux.<\/p>\n<p><\/p>\n<p>Plus tard, nous sommes all\u00e9s en Chine et nous avons constat\u00e9 que <strong>On peut faire confiance \u00e0 Catchpoint, car il refl\u00e8te assez pr\u00e9cis\u00e9ment les indicateurs r\u00e9els de vitesse de fonctionnement.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"cloudflare-china-network\">Cloudflare China Network<\/h2>\n<p><\/p>\n<p>Puisque pour le domaine principal semrush.com, nous utilisons avec succ\u00e8s Cloudflare, nous avons d\u00e9cid\u00e9 d'essayer tout de suite leur fonctionnalit\u00e9 appel\u00e9e <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloudflare.com\/network\/china\/\">China Network<\/a><\/noindex>. Cette option n'est activ\u00e9e que pour les sites Enterprise sur demande distincte et moyennant des frais suppl\u00e9mentaires. Elle n'est \u00e9galement disponible que pour les sites ayant la licence ICP correspondante, o\u00f9 Cloudflare est indiqu\u00e9 comme prestataire. Apr\u00e8s activation, le site dispose du \u00ab CDN chinois \u00bb de Cloudflare \u2014 le trafic provenant des r\u00e9gions chinoises est dirig\u00e9 vers le PoP (Points of Presence) CF le plus proche, puis est transmis \u00e0 l'origine \u00e0 travers ses r\u00e9seaux ou ceux des fournisseurs\/partenaires. <\/p>\n<p><\/p>\n<p>Le sch\u00e9ma de ce banc d'essai est pr\u00e9sent\u00e9 ci-dessous.<\/p>\n<p><\/p>\n<p>Pour nous, c'est une excellente option. Cela signifie que le second domaine sera \u00e9galement pris en charge par CF, ce qui n'augmente pas le nombre de solutions utilis\u00e9es dans l'entreprise et n'alourdit pratiquement pas l'infrastructure.<\/p>\n<p><\/p>\n<p>Nous avons lanc\u00e9 des tests de navigateur et voici ce que nous avons obtenu :<\/p>\n<p><\/p>\n<p>Les losanges rouges repr\u00e9sentent des \u00e9checs de tests. Les \u00e9checs en bas sont des erreurs DNS (d\u00e9lai d'expiration de r\u00e9solution). Les \u00e9checs en haut sont des d\u00e9lais d'attente.<\/p>\n<p><\/p>\n<p><em>Uptime : 86,6<br \/>\nM\u00e9diane : 18s<br \/>\n75e percentile : 29,3s<br \/>\n95e percentile : 60s<\/em><\/p>\n<p><\/p>\n<p>La m\u00e9diane, apr\u00e8s avoir retir\u00e9 le chargement <em>reCaptcha<\/em> (service de Google, bloqu\u00e9 en Chine), est pass\u00e9e de 28 \u00e0 18 secondes. Mais cela reste des r\u00e9sultats d\u00e9sastreux si l'on consid\u00e8re qu'un test similaire pour semrush.com (depuis les \u00c9tats-Unis) donnait moins de 10 secondes pour 95 % des utilisateurs (depuis les \u00c9tats-Unis) sur la m\u00eame page (statique + dynamique).<\/p>\n<p><\/p>\n<p>Vous pouvez entrer dans chaque test et voir <em>Waterfall<\/em> et d'autres param\u00e8tres plus d\u00e9taill\u00e9s. Nous avons commenc\u00e9 \u00e0 examiner les raisons des erreurs, et si pour les d\u00e9lais d'attente tout est plus ou moins clair : Internet en Chine se \"connecte et se d\u00e9connecte\", ce qui rend la vitesse de connexion et le chargement des ressources \u00e9trang\u00e8res instables et in\u00e9gales, alors les erreurs DNS nous ont beaucoup surpris. Nous avons d\u00e9couvert que <em>PoP<\/em> de Cloudflare se trouvent effectivement en Chine, l'adresse du site se r\u00e9sout en un IP anycast, mais les serveurs DNS utilis\u00e9s sont am\u00e9ricains, ce qui oblige les requ\u00eates DNS \u00e0 traverser la fronti\u00e8re, donc parfois elles \u00e9chouent.<\/p>\n<p><\/p>\n<p>Apr\u00e8s avoir \u00e9clairci cette question avec CF, il s'est av\u00e9r\u00e9 que <strong>ils n'ont pas de serveurs DNS en Chine<\/strong>, et quand ils en auront, c'est encore inconnu.<\/p>\n<p><\/p>\n<p>C'est pourquoi nous avons d\u00e9cid\u00e9 de tester uniquement les DNS de Cloudflare et avons modifi\u00e9 le m\u00e9canisme de fonctionnement de Cloudflare pour notre site en mode \"<strong>DNS seulement<\/strong>\". C'est un mode o\u00f9 Cloudflare ne passe pas le trafic par lui-m\u00eame, ce qui signifie qu'il ne fournit pas de protection DDoS, CDN et autres fonctionnalit\u00e9s, et fonctionne en tant que serveur DNS classique. <\/p>\n<p><\/p>\n<p>Ce stand est sch\u00e9matiquement pr\u00e9sent\u00e9 sur l'image suivante. L'image prend en compte les nouvelles connaissances sur le fait que les serveurs DNS de Cloudflare sont derri\u00e8re un pare-feu.<\/p>\n<p><\/p>\n<p>Chez Catchpoint, nous avons lanc\u00e9 des tests GET simples (non bas\u00e9s sur un navigateur), qui ont montr\u00e9 beaucoup d'\u00e9checs. La cause en \u00e9tait les m\u00eames erreurs DNS.<\/p>\n<p><\/p>\n<p>Nous avons commenc\u00e9 \u00e0 d\u00e9boguer ces erreurs avec <em>dig<\/em> et avons d\u00e9couvert qu'\u00e0 la premi\u00e8re requ\u00eate, l'adresse est d\u00e9termin\u00e9e correctement, mais \u00e0 chaque requ\u00eate r\u00e9p\u00e9t\u00e9e, nous recevons toujours <em>SERVFAIL<\/em> et <em>introuvable<\/em>. D'o\u00f9 cela vient-il ?<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn a l'adresse 220.170.186.192\nH\u00f4te semrushchina.cn introuvable : 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn a l'adresse 220.170.186.192\nH\u00f4te semrushchina.cn introuvable : 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn a l'adresse 220.170.186.192\nH\u00f4te semrushchina.cn introuvable : 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn a l'adresse 220.170.186.192\nH\u00f4te semrushchina.cn introuvable : 2(SERVFAIL)<\/code><\/pre>\n<p><\/p>\n<p>Lors de la requ\u00eate des serveurs NS de Cloudflare directement, il n'y a pas de telles erreurs :<\/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\nUtilisation du serveur de domaine :\nNom : ray.ns.cloudflare.com.\nAdresse : 173.245.59.138#53\nAlias : \n\nsemrushchina.cn a l'adresse 220.170.186.192\nsemrushchina.cn a l'adresse 220.170.186.192\nUtilisation du serveur de domaine :\nNom : ray.ns.cloudflare.com.\nAdresse : 173.245.59.138#53\nAlias : \n\nsemrushchina.cn a l'adresse 220.170.186.192\nsemrushchina.cn a l'adresse 220.170.186.192<\/code><\/pre>\n<p><\/p>\n<p>Donc, le probl\u00e8me vient du \"serveur DNS local\" ou du serveur du fournisseur.<br \/>\nUne enqu\u00eate plus approfondie a montr\u00e9 que <em>SERVFAIL<\/em> nous recevons le r\u00e9solveur <em>AAAA<\/em>-enregistrements. <\/p>\n<p><\/p>\n<p>Il s'est av\u00e9r\u00e9 qu'\u00e0 la demande aupr\u00e8s de Cloudflare <em>AAAA<\/em>-enregistrement, qui n'existe pas dans le domaine, Cloudflare a r\u00e9pondu <em>Un<\/em>-par un message d'erreur, ce qui constitue une erreur et un non-respect des RFC. Pour cette raison, le r\u00e9solveur local (<em>x.x.x.x<\/em>) n'a pas appr\u00e9ci\u00e9 cela et a r\u00e9pondu <em>SERVFAIL<\/em>. Dans le journal ci-dessous, ce comportement est clairement visible :<\/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;; options globales : +cmd\n;; R\u00e9ponse re\u00e7ue :\n;; -&gt;&gt;HEADER&lt;&lt;- opcode : QUERY, status : SERVFAIL, id : 55467\n;; flags : qr rd ra ; QUERY : 1, ANSWER : 0, AUTHORITY : 0, ADDITIONAL : 1\n\n;; OPT PSEUDOSECTION :\n; EDNS : version : 0, flags : ; udp : 4096\n;; SECTION DE LA QUESTION :\n;semrushchina.cn.               IN      AAAA\n\n;; Temps de requ\u00eate : 334 msec\n;; SERVEUR : x.x.x.x#53(x.x.x.x)\n;; QUAND : Mar Ao\u00fb 14 23:38:50 CST 2018\n;; TAILLE MSG  re\u00e7ue : 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;; options globales : +cmd\n;; R\u00e9ponse re\u00e7ue :\n;; -&gt;&gt;HEADER&lt;&lt;- opcode : QUERY, status : NOERROR, id : 63944\n;; flags : qr aa rd ; QUERY : 1, ANSWER : 1, AUTHORITY : 0, ADDITIONAL : 1\n;; AVERTISSEMENT : r\u00e9cursion demand\u00e9e mais non disponible\n\n;; OPT PSEUDOSECTION :\n; EDNS : version : 0, flags : ; udp : 512\n;; SECTION DE LA QUESTION :\n;semrushchina.cn.               IN      AAAA\n\n;; SECTION DE LA R\u00c9PONSE :\nsemrushchina.cn.        300     IN      A       220.170.186.192\n\n;; Temps de requ\u00eate : 185 msec\n;; SERVEUR : 173.245.58.105#53(173.245.58.105)\n;; QUAND : Mar Ao\u00fb 14 23:43:03 CST 2018\n;; TAILLE MSG  re\u00e7ue : 60\n<\/code><\/pre>\n<p><\/p>\n<p>Nous avons envoy\u00e9 un bug report \u00e0 Cloudflare, et ils l'ont corrig\u00e9 apr\u00e8s un certain temps. Ce qui s'est av\u00e9r\u00e9 int\u00e9ressant : \u00e0 l'heure actuelle, il n'y a toujours pas de support IPv6 en Chine, donc Cloudflare ne pouvait pas fournir son adresse IPv6 dans la r\u00e9ponse \u00e0 la demande <em>AAAA<\/em>-d'enregistrements. Au final, tout a \u00e9t\u00e9 r\u00e9solu de sorte que pour la Chine, Cloudflare a commenc\u00e9 \u00e0 r\u00e9pondre <em>NODATA<\/em> \u00e0 de telles requ\u00eates.<\/p>\n<p><\/p>\n<p>Ainsi, les erreurs DNS dans les tests Catchpoint ont consid\u00e9rablement diminu\u00e9, mais pas compl\u00e8tement. Les timeouts n'ont \u00e9galement pas disparu :<\/p>\n<p><\/p>\n<p>Et nous avons commenc\u00e9 \u00e0 chercher une autre solution. <\/p>\n<p><\/p>\n<p>Dans la prochaine partie, je vais raconter comment nous avons test\u00e9 le cloud chinois <strong>Alibaba Cloud<\/strong>, comment gr\u00e2ce \u00e0 une petite &#171;magie&#187; de Nginx, nous avons pu cr\u00e9er rapidement des PoC (Proof of Concept) de solutions, notamment des solutions Multi-Cloud, dont l'une a finalement beaucoup aid\u00e9 \u00e0 acc\u00e9l\u00e9rer le fonctionnement du service depuis la Chine.<\/p>\n<p><\/p>\n<p><strong>Restez \u00e0 l'\u00e9coute !<\/strong><\/p>\n<p><\/p>\n<h3 id=\"sleduyuschie-chasti\">Les parties suivantes<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/semrush\/blog\/458840\/\">Partie 2<\/a><\/noindex><\/p>\n<p>Source : <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.2 - 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\/fr\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\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\/fr\/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\udd47Comment nous avons franchi le Grand Firewall de Chine (partie 1) | ProHoster","description":"Bonjour \u00e0 tous ! Ici Nikita \u2014 ing\u00e9nieur syst\u00e8me chez SEMrush.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/35939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=35939"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/35939\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=35939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=35939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=35939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}