{"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\/pt\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","title":{"rendered":"Como ultrapassamos o Grande Firewall da China (parte 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ol\u00e1 a todos!<\/p>\n<p><\/p>\n<p>Aqui \u00e9 o Nikita \u2014 engenheiro de sistemas da empresa <strong>SEMrush<\/strong>. Hoje vou contar como enfrentamos o desafio de garantir a estabilidade do nosso servi\u00e7o semrush.com na China e quais problemas encontramos durante o processo (considerando a localiza\u00e7\u00e3o do nosso data center na costa leste dos Estados Unidos).<\/p>\n<p><\/p>\n<p>Esta ser\u00e1 uma grande hist\u00f3ria, dividida em v\u00e1rias partes. Contarei como tudo isso aconteceu conosco: desde um servi\u00e7o totalmente inoperante na China at\u00e9 a performance do servi\u00e7o compar\u00e1vel \u00e0 vers\u00e3o americana para os americanos. Prometo que ser\u00e1 interessante e \u00fatil. Ent\u00e3o, vamos l\u00e1.<\/p>\n<p><\/p>\n<h2 id=\"problemy-kitayskogo-interneta\">Problemas da internet chinesa<\/h2>\n<p><\/p>\n<p>Mesmo a pessoa mais distante da administra\u00e7\u00e3o de redes j\u00e1 ouviu falar pelo menos uma vez do <strong>Grande Firewall da China<\/strong>. Uau, parece legal, n\u00e3o? Mas o que \u00e9 isso e como realmente funciona \u00e9 uma pergunta bastante complexa. Na internet, \u00e9 poss\u00edvel encontrar muitos artigos sobre isso, mas, do ponto de vista t\u00e9cnico, a estrutura desse firewall n\u00e3o \u00e9 descrita em nenhum lugar. O que, ali\u00e1s, n\u00e3o \u00e9 surpreendente. Posso confessar que, ap\u00f3s um ano de trabalho, n\u00e3o serei capaz de dizer exatamente como ele funciona, mas posso compartilhar minhas observa\u00e7\u00f5es e conclus\u00f5es pr\u00e1ticas. E come\u00e7aremos com os rumores sobre este firewall.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>H\u00e1 muitos rumores sobre esse firewall. Vamos reunir os principais e mais interessantes em uma \u00fanica lista:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter e outros servi\u00e7os semelhantes est\u00e3o bloqueados e n\u00e3o funcionam na China.<\/li>\n<li>Qualquer tr\u00e1fego que v\u00e1 para FORA da China e PARA a China \u00e9 analisado e restrito por meio de aprendizado de m\u00e1quina (em caso de tr\u00e1fego suspeito), o que desacelera muito esse tr\u00e1fego que atravessa a fronteira.<\/li>\n<li>Os servi\u00e7os secretos chineses conseguem hackear qualquer tr\u00e1fego criptografado que passe pelo seu firewall.<\/li>\n<li>T\u00faneis VPN e t\u00faneis IPSEC s\u00e3o inst\u00e1veis, caem e s\u00e3o constantemente bloqueados.<\/li>\n<li>Quanto mais simples for a criptografia, mais simples for a frase secreta usada para autentica\u00e7\u00e3o \/ criptografia do tr\u00e1fego, mais r\u00e1pido ele passa pelo firewall chin\u00eas.<\/li>\n<\/ul>\n<p><\/p>\n<p>Aqui est\u00e1 o que conseguimos descobrir sobre esses rumores:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter e outros servi\u00e7os semelhantes est\u00e3o realmente bloqueados (seu K0), mas muitos dom\u00ednios t\u00e9cnicos do Google, como gstatic.com, n\u00e3o est\u00e3o banidos e funcionam. A conclus\u00e3o \u00e9 que n\u00e3o se deve excluir sem crit\u00e9rio todos os recursos do Google e outros que parecem estar bloqueados.<\/li>\n<li>Qualquer tr\u00e1fego que ultrapassa a fronteira realmente adiciona um atraso significativo ao seu tempo. Veja dois resultados. Um site, uma p\u00e1gina, um simples GET. <em>curl<\/em>O primeiro teste \u00e9 feito diretamente da China (a linda cidade de Shenzhen). O segundo teste \u00e9 feito do lado de fora, de Hong Kong (que tem soberania e n\u00e3o h\u00e1 firewall entre ele e o mundo). A dist\u00e2ncia entre as cidades em linha reta \u00e9 de aproximadamente 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>Preste aten\u00e7\u00e3o em <strong>time_connect<\/strong>. E em geral, voc\u00ea v\u00ea o resultado: o firewall adiciona 4 segundos extras, o que \u00e9 absurdamente longo.<\/p>\n<p><\/p>\n<ul>\n<li>VPNs e t\u00faneis IPSEC realmente costumam cair. Vou falar sobre isso mais adiante e em mais detalhes. Os servidores VPN usados pelos usu\u00e1rios, com o tempo, s\u00e3o bloqueados (geralmente dentro de um dia ap\u00f3s o in\u00edcio do uso). <\/li>\n<li>H\u00e1 uma opini\u00e3o, baseada em depoimentos de pessoas que vivem na China, de que quanto mais simples a criptografia do tr\u00e1fego, mais r\u00e1pido ele passa pela fronteira, pois \u00e9 f\u00e1cil perceber que n\u00e3o h\u00e1 nada ilegal. E o tr\u00e1fego 'limpo' obt\u00e9m mais largura de banda e velocidade, enquanto o tr\u00e1fego 'sujo', que \u00e9 dif\u00edcil de entender, tem um retorno mais lento. Para exemplo, vou citar o CURL at\u00e9 <em>ifconfig.co<\/em> usando os protocolos HTTPS e 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>A diferen\u00e7a de 5 segundos no tempo total de download de 13 bytes. Ao realizar esse teste v\u00e1rias vezes, pode-se notar que o GET em HTTP geralmente conclui em tempos similares, enquanto em HTTPS o site \u00e0s vezes responde em 3, 5, 10 e at\u00e9 17 segundos. \u00c0s vezes ocorrem erros SSL:<\/p>\n<p><\/p>\n<p><code>Erro de protocolo SSL desconhecido na conex\u00e3o com ifconfig.co:443.<\/code><\/p>\n<p><\/p>\n<p>Ent\u00e3o, o que temos:<\/p>\n<p><\/p>\n<ul>\n<li>Os problemas causados pelo firewall chin\u00eas, descritos acima.<\/li>\n<li>Os pings para recursos externos e dentro dos t\u00faneis \u00e0s vezes falham.<\/li>\n<li>A lat\u00eancia entre dois pontos muda constantemente e muitas vezes \u00e9 imprevis\u00edvel. Ao conectar diferentes cidades\/regi\u00f5es, espera-se que a lat\u00eancia seja menor devido \u00e0 localiza\u00e7\u00e3o geogr\u00e1fica, mas se obt\u00e9m o oposto. <\/li>\n<li>A internet e as linhas de comunica\u00e7\u00e3o funcionam tanto r\u00e1pido quanto devagar. H\u00e1 uma leve depend\u00eancia do hor\u00e1rio e do dia da semana, mas n\u00e3o sempre.<\/li>\n<li>As consultas DNS para o mundo exterior a partir da China \u00e0s vezes ultrapassam o limite de tempo permitido.<\/li>\n<\/ul>\n<p><\/p>\n<p>A imagem se revela simplesmente \"excelente\". <\/p>\n<p><\/p>\n<p>O data center, como j\u00e1 mencionei, est\u00e1 na costa leste dos EUA, e todo o SEMrush \u00e9 composto por dezenas de produtos interconectados, back-ends, front-ends, bancos de dados, e tudo isso nos data centers e na nuvem. Nossa equipe de administradores de sistema foi encarregada de come\u00e7ar a trabalhar na China com o m\u00ednimo de esfor\u00e7o.<\/p>\n<p><\/p>\n<p>Precis\u00e1vamos responder a uma pergunta importante: poder\u00edamos resolver todos os problemas relacionados \u00e0 internet e ao firewall chin\u00eas com um m\u00ednimo de esfor\u00e7o, no n\u00edvel da rede\/nuvem\/servidores?<\/p>\n<p><\/p>\n<p>Come\u00e7amos obtendo <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>-licen\u00e7a<\/a><\/noindex>.<\/p>\n<p><\/p>\n<h2 id=\"icp-licenziya\">licen\u00e7a ICP<\/h2>\n<p><\/p>\n<p>Para poder hospedar seu servi\u00e7o dentro da China Continental e realizar testes, primeiro \u00e9 necess\u00e1rio obter uma licen\u00e7a ICP para o dom\u00ednio.<\/p>\n<p><\/p>\n<p>Se o tr\u00e1fego do usu\u00e1rio do seu site for interrompido dentro da China continental, e se o seu dom\u00ednio n\u00e3o tiver uma licen\u00e7a ICP, seu tr\u00e1fego ser\u00e1 bloqueado pelo provedor\/host. Curiosamente, a licen\u00e7a ICP \u00e9 vinculada a um provedor espec\u00edfico, seja Cloudflare ou Alibaba Cloud. Portanto, se voc\u00ea obteve uma licen\u00e7a ICP para Cloudflare e hospedou seu site com eles, n\u00e3o ser\u00e1 poss\u00edvel<\/p>\n<p><\/p>\n<p>Ap\u00f3s obter a licen\u00e7a ICP para o dom\u00ednio, conseguimos idealizar e implementar ideias e solu\u00e7\u00f5es t\u00e9cnicas espec\u00edficas.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie-resheniy\">Testando solu\u00e7\u00f5es<\/h2>\n<p><\/p>\n<p>Mas antes de criar efetivamente as op\u00e7\u00f5es de staging, ajustar as configura\u00e7\u00f5es, otimizar o desempenho do site e sua velocidade, \u00e9 necess\u00e1rio escolher uma ferramenta para testes, para entender quais de nossas a\u00e7\u00f5es melhoram ou, ao contr\u00e1rio, prejudicam o funcionamento do site.<\/p>\n<p><\/p>\n<p>Nossa ferramenta de teste deve cumprir dois requisitos principais:<\/p>\n<p><\/p>\n<ul>\n<li>ela deve ser capaz de executar testes a partir da China,<\/li>\n<li>ela deve suportar testes de navegador.<\/li>\n<\/ul>\n<p><\/p>\n<p>Assim, encontramos <noindex><a rel=\"nofollow\" href=\"https:\/\/www.catchpoint.com\/\">Catchpoint<\/a><\/noindex>! Eles t\u00eam uma excelente cobertura de pontos de teste em todo o mundo. Na China, atrav\u00e9s dessa ferramenta, \u00e9 poss\u00edvel executar testes de 100500 prov\u00edncias. Em cada uma, diferentes provedores + a possibilidade de realizar <strong>Backbone<\/strong>-testes (algo semelhante a uma virtualiza\u00e7\u00e3o em um data center) e <strong>Lastmile<\/strong>-testes (maximamente pr\u00f3ximos \u00e0s condi\u00e7\u00f5es do usu\u00e1rio, ou seja, esta\u00e7\u00f5es de trabalho). Este \u00faltimo tipo de teste custa mais caro.<\/p>\n<p><\/p>\n<p>Ap\u00f3s fechar um contrato anual (n\u00e3o \u00e9 poss\u00edvel menos), come\u00e7amos a explorar a ferramenta. Para ser sincero, ficamos agradavelmente surpresos com sua funcionalidade. \u00c9 poss\u00edvel executar:<\/p>\n<p><\/p>\n<ul>\n<li>Testes de DNS,<\/li>\n<li>Testes Web (navegador, simples GET\/POST, simula\u00e7\u00e3o de cliente m\u00f3vel, etc.),<\/li>\n<li>Verifica\u00e7\u00f5es transacionais (por exemplo, login),<\/li>\n<li>Testes de API,<\/li>\n<li>Ping, traceroute, NTP, etc.<\/li>\n<\/ul>\n<p><\/p>\n<p>\u00c9 imposs\u00edvel enumerar tudo. E o mais importante, cada teste pode ser bastante personalizado, adicionando um conjunto de cabe\u00e7alhos e outros par\u00e2metros. O resultado \u00e9 uma quantidade enorme de informa\u00e7\u00f5es, completamente descrevendo seu teste. Falando do que \u00e9 mais interessante para n\u00f3s (testes de navegador), o resultado inclui:<\/p>\n<p><\/p>\n<ul>\n<li>Conex\u00e3o, Espera, Carregamento, SSL, tempo de DNS,<\/li>\n<li>TTFB, TTLB, Document complete, Render time, DOM load,<\/li>\n<li>Resposta (algo pr\u00f3ximo ao Time To First Byte), Resposta da p\u00e1gina Web (algo pr\u00f3ximo ao Time To Last Byte),<\/li>\n<li>Qualquer percentil, Tempo M\u00e9dio, Mediana<\/li>\n<li>E assim por diante.<\/li>\n<\/ul>\n<p><\/p>\n<p>Assim, todas essas m\u00e9tricas ajudam a ver as mudan\u00e7as e a entender se houve melhora. N\u00f3s, principalmente, observamos <strong>Resposta, Resposta da P\u00e1gina, Mediana, Percentis 75 e 95<\/strong>. <\/p>\n<p><\/p>\n<p>Uma pergunta importante que pairava desde o in\u00edcio: <strong>\u00e9 poss\u00edvel confiar na 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 \/>\nIsso \u00e9 um grande problema, porque estando na R\u00fassia, \u00e9 praticamente imposs\u00edvel saber com precis\u00e3o como um site funciona a partir da China. Usando um socks-proxy atrav\u00e9s de uma m\u00e1quina virtual, o carregamento do site leva alguns minutos, o que \u00e9 inaceit\u00e1vel para testes; portanto, a \u00fanica op\u00e7\u00e3o de teste manual permanece sendo o curl e simples GETs no console com medi\u00e7\u00e3o de tempo. Isso ajuda, pois esse teste reflete bem a velocidade da solu\u00e7\u00e3o de rede, e se houver testes de navegador, melhor ainda.<\/p>\n<p><\/p>\n<p>Mais tarde, fomos \u00e0 China e confirmamos que <strong>\u00e9 poss\u00edvel confiar na Catchpoint, ela reflete com bastante precis\u00e3o os indicadores reais de velocidade.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"cloudflare-china-network\">Rede China da Cloudflare<\/h2>\n<p><\/p>\n<p>Como utilizamos com sucesso a Cloudflare para o dom\u00ednio principal semrush.com, decidimos imediatamente testar sua funcionalidade chamada <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloudflare.com\/network\/china\/\">Rede China<\/a><\/noindex>. Esta op\u00e7\u00e3o \u00e9 ativada apenas para sites Enterprise mediante solicita\u00e7\u00e3o separada e pagamento adicional. Ela tamb\u00e9m est\u00e1 dispon\u00edvel apenas para sites que possuem a licen\u00e7a ICP correspondente, na qual a Cloudflare \u00e9 indicada como provedora. Ap\u00f3s a ativa\u00e7\u00e3o, o site tem acesso ao \"CDN chin\u00eas\" da Cloudflare \u2014 o tr\u00e1fego das regi\u00f5es chinesas \u00e9 direcionado ao PoP (Pontos de Presen\u00e7a) mais pr\u00f3ximo da CF, e ent\u00e3o \u00e9 entregue at\u00e9 a origem atrav\u00e9s de suas redes ou redes de provedores\/parceiros. <\/p>\n<p><\/p>\n<p>O esquema deste ambiente de testes \u00e9 apresentado abaixo.<\/p>\n<p><\/p>\n<p>Para n\u00f3s, essa \u00e9 uma \u00f3tima op\u00e7\u00e3o. Assim, o segundo dom\u00ednio tamb\u00e9m ficar\u00e1 sob a CF, o que n\u00e3o aumenta a quantidade de solu\u00e7\u00f5es utilizadas na empresa, al\u00e9m de praticamente n\u00e3o complicar a infraestrutura.<\/p>\n<p><\/p>\n<p>Realizamos os testes de navegador, e aqui est\u00e3o os resultados:<\/p>\n<p><\/p>\n<p>Os losangos vermelhos representam falhas nos testes. As falhas na parte inferior s\u00e3o erros de DNS (timeout de resolu\u00e7\u00e3o). As falhas na parte superior s\u00e3o timeouts.<\/p>\n<p><\/p>\n<p><em>Uptime: 86,6<br \/>\nMediana: 18s<br \/>\nPercentil 75: 29,3s<br \/>\nPercentil 95: 60s<\/em><\/p>\n<p><\/p>\n<p>A mediana, ap\u00f3s remover a carga <em>reCaptcha<\/em> (servi\u00e7o do Google, bloqueado na China), caiu de 28 para 18 segundos. Mas ainda s\u00e3o indicadores horr\u00edveis, considerando que o mesmo teste para semrush.com (dos EUA) forneceu menos de 10 segundos para 95% dos usu\u00e1rios (dos EUA) na mesma p\u00e1gina (est\u00e1tica + din\u00e2mica).<\/p>\n<p><\/p>\n<p>\u00c9 poss\u00edvel acessar cada teste e visualizar <em>Waterfall<\/em> e outros par\u00e2metros mais detalhados. Come\u00e7amos a investigar as causas dos erros, e se para os timeouts tudo \u00e9 mais ou menos compreens\u00edvel: a internet na China \u201cvai e volta\u201d, o que faz com que a velocidade de conex\u00e3o e o carregamento de recursos do exterior sejam inst\u00e1veis e vari\u00e1veis, as falhas de DNS nos surpreenderam bastante. Descobrimos que <em>PoP<\/em> na Cloudflare realmente est\u00e3o na China, o endere\u00e7o do site resolve em um IP anycast, mas os servidores DNS utilizados s\u00e3o americanos, o que faz com que as consultas DNS tenham que passar pela fronteira, resultando em falhas \u00e0s vezes.<\/p>\n<p><\/p>\n<p>Ao esclarecer essa quest\u00e3o com a CF, descobrimos que <strong>eles n\u00e3o t\u00eam seus pr\u00f3prios servidores DNS na China<\/strong>, e ainda n\u00e3o se sabe quando ter\u00e3o.<\/p>\n<p><\/p>\n<p>Portanto, decidimos testar apenas o DNS da Cloudflare e mudamos o mecanismo de opera\u00e7\u00e3o da Cloudflare para o nosso site para o modo \u201c<strong>Apenas DNS<\/strong>\u201d. Este \u00e9 um modo em que a Cloudflare n\u00e3o proxy o tr\u00e1fego por meio dela, o que significa que n\u00e3o fornece prote\u00e7\u00e3o DDoS, CDN e outras funcionalidades, funcionando como um servidor DNS comum. <\/p>\n<p><\/p>\n<p>Este stand \u00e9 apresentado esquematicamente na pr\u00f3xima figura. Na figura, s\u00e3o consideradas as novas informa\u00e7\u00f5es sobre os servidores DNS da Cloudflare atr\u00e1s do firewall.<\/p>\n<p><\/p>\n<p>Na Catchpoint, executamos testes GET simples (n\u00e3o baseados em navegador), que mostraram muitas falhas. A causa delas eram os mesmos erros de DNS.<\/p>\n<p><\/p>\n<p>Come\u00e7amos a depurar esses erros com o <em>dig<\/em> e descobrimos que, na primeira consulta, o endere\u00e7o \u00e9 determinado corretamente, mas a cada nova consulta recebemos <em>SERVFAIL<\/em> e <em>n\u00e3o encontrado<\/em>. Por que isso?<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192\nHost semrushchina.cn n\u00e3o encontrado: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192\nHost semrushchina.cn n\u00e3o encontrado: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192\nHost semrushchina.cn n\u00e3o encontrado: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192\nHost semrushchina.cn n\u00e3o encontrado: 2(SERVFAIL)<\/code><\/pre>\n<p><\/p>\n<p>Ao consultar diretamente os servidores NS da Cloudflare, tais erros n\u00e3o ocorrem:<\/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\nUsando o servidor de dom\u00ednio:\nNome: ray.ns.cloudflare.com.\nEndere\u00e7o: 173.245.59.138#53\nApelidos: \n\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192\nUsando o servidor de dom\u00ednio:\nNome: ray.ns.cloudflare.com.\nEndere\u00e7o: 173.245.59.138#53\nApelidos: \n\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192\nsemrushchina.cn tem o endere\u00e7o 220.170.186.192<\/code><\/pre>\n<p><\/p>\n<p>Assim, o problema est\u00e1 do lado do servidor DNS \u201clocal\u201d ou do servidor do provedor.<br \/>\nUma investiga\u00e7\u00e3o posterior mostrou que <em>SERVFAIL<\/em> recebemos na resolu\u00e7\u00e3o <em>registros AAAA.<\/em>Descobrimos que ao fazer a consulta na Cloudflare <\/p>\n<p><\/p>\n<p>Descobriu-se que ao fazer um pedido ao Cloudflare <em>AAAA<\/em>-registro que n\u00e3o existe no dom\u00ednio, o Cloudflare respondeu <em>A<\/em>-com um erro que \u00e9 uma inconsist\u00eancia com o RFC. Isso fez com que o resolvedor local (<em>x.x.x.x<\/em>) n\u00e3o gostasse, e ele respondeu <em>SERVFAIL<\/em>. O comportamento est\u00e1 claramente vis\u00edvel no log abaixo:<\/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;; op\u00e7\u00f5es globais: +cmd\n;; Obteve resposta:\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: vers\u00e3o: 0, flags:; udp: 4096\n;; SE\u00c7\u00c3O DE QUEST\u00c3O:\n;semrushchina.cn.               IN      AAAA\n\n;; Tempo de consulta: 334 msec\n;; SERVIDOR: x.x.x.x#53(x.x.x.x)\n;; QUANDO: Ter Aug 14 23:38:50 CST 2018\n;; TAMANHO DA MSG recebida: 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;; op\u00e7\u00f5es globais: +cmd\n;; Obteve resposta:\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;; AVISO: recurs\u00e3o solicitada, mas n\u00e3o dispon\u00edvel\n\n;; OPT PSEUDOSECTION:\n; EDNS: vers\u00e3o: 0, flags:; udp: 512\n;; SE\u00c7\u00c3O DE QUEST\u00c3O:\n;semrushchina.cn.               IN      AAAA\n\n;; SE\u00c7\u00c3O DE RESPOSTA:\nsemrushchina.cn.        300     IN      A       220.170.186.192\n\n;; Tempo de consulta: 185 msec\n;; SERVIDOR: 173.245.58.105#53(173.245.58.105)\n;; QUANDO: Ter Aug 14 23:43:03 CST 2018\n;; TAMANHO DA MSG recebida: 60\n<\/code><\/pre>\n<p><\/p>\n<p>Enviamos um relat\u00f3rio de bug ao Cloudflare, e eles resolveram isso ap\u00f3s algum tempo. Resultou interessante: atualmente, na China ainda n\u00e3o h\u00e1 suporte a IPv6, por isso o Cloudflare n\u00e3o conseguia fornecer seu endere\u00e7o IPv6 na resposta ao pedido <em>AAAA<\/em>-de registros. No final, tudo foi resolvido, de modo que o Cloudflare passou a responder <em>NODATA<\/em> para tais pedidos.<\/p>\n<p><\/p>\n<p>Assim, os erros de DNS nos testes do Catchpoint diminu\u00edram drasticamente, mas n\u00e3o completamente. Os timeouts tamb\u00e9m n\u00e3o desapareceram:<\/p>\n<p><\/p>\n<p>E come\u00e7amos a procurar outra solu\u00e7\u00e3o. <\/p>\n<p><\/p>\n<p>Na pr\u00f3xima parte, contarei como testamos a nuvem chinesa <strong>Alibaba Cloud<\/strong>, como com um pouco de &#171;m\u00e1gica&#187; do Nginx conseguimos rapidamente criar PoCs (Prova de Conceito) de solu\u00e7\u00f5es, como desenvolvemos solu\u00e7\u00f5es Multi-Cloud, uma das quais acabou ajudando muito a acelerar o funcionamento do servi\u00e7o da China.<\/p>\n<p><\/p>\n<p><strong>Fique atento!<\/strong><\/p>\n<p><\/p>\n<h3 id=\"sleduyuschie-chasti\">Pr\u00f3ximas partes<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/semrush\/blog\/458840\/\">Parte 2<\/a><\/noindex><\/p>\n<p>Fonte: <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.3 - 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\/pt\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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\udd47Como superamos o Grande Firewall da China (parte 1) | ProHoster","description":"Ol\u00e1 a todos! Aqui \u00e9 Nikita \u2014 engenheiro de sistemas da empresa SEMrush.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/35939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=35939"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/35939\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=35939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=35939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=35939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}