{"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\/es\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","title":{"rendered":"C\u00f3mo superamos el Gran Cortafuegos Chino (parte 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>\u00a1Hola a todos!<\/p>\n<p><\/p>\n<p>En contacto, Nikita \u2014 ingeniero de sistemas de la empresa <strong>SEMrush<\/strong>. Hoy les contar\u00e9 sobre c\u00f3mo enfrentamos la tarea de garantizar la estabilidad de nuestro servicio semrush.com en China y los problemas con los que nos enfrentamos durante su ejecuci\u00f3n (considerando la ubicaci\u00f3n de nuestro centro de datos en la costa este de EE. UU.).<\/p>\n<p><\/p>\n<p>Esta ser\u00e1 una gran historia, dividida en varios art\u00edculos. Les contar\u00e9 c\u00f3mo todo fue para nosotros: desde un servicio que no funcionaba en absoluto desde China hasta indicadores de rendimiento del servicio a nivel de su versi\u00f3n estadounidense para estadounidenses. Prometo que ser\u00e1 interesante y \u00fatil. As\u00ed que, \u00a1vamos!<\/p>\n<p><\/p>\n<h2 id=\"problemy-kitayskogo-interneta\">Problemas de internet en China<\/h2>\n<p><\/p>\n<p>Incluso la persona m\u00e1s alejada de la especificidad de la administraci\u00f3n de redes ha o\u00eddo hablar al menos una vez de <strong>El Gran Firewall Chino<\/strong>. Uuuu, suena genial, \u00bfverdad? Pero \u00bfqu\u00e9 es, c\u00f3mo funciona realmente? \u2014 es una pregunta bastante compleja. En Internet, se pueden encontrar muchos art\u00edculos dedicados a esto, pero desde una perspectiva t\u00e9cnica, la estructura de este firewall no se describe en ninguna parte. Lo cual, por supuesto, no es sorprendente. Debo admitir que, despu\u00e9s de un a\u00f1o de trabajo, no podr\u00e9 decir exactamente c\u00f3mo funciona, pero puedo compartir mis observaciones y conclusiones pr\u00e1cticas. Y empezaremos con los rumores sobre este firewall.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Hay muchos rumores sobre este mismo firewall. Vamos a recopilar los principales y m\u00e1s interesantes en una lista:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter y otros servicios similares est\u00e1n bloqueados y no funcionan en China.<\/li>\n<li>Cualquier tr\u00e1fico que va FUERA de China y A China es analizado y restringido mediante aprendizaje autom\u00e1tico (en caso de tr\u00e1fico sospechoso), lo que lo ralentiza notablemente (el tr\u00e1fico) al pasar por la frontera.<\/li>\n<li>Los servicios de inteligencia chinos pueden romper cualquier tr\u00e1fico encriptado que pase por su firewall.<\/li>\n<li>Los t\u00faneles VPN, los t\u00faneles IPSEC son inestables, se caen y se bloquean constantemente.<\/li>\n<li>Cuanto m\u00e1s simple sea la encriptaci\u00f3n, cuanto m\u00e1s simple sea la frase de acceso utilizada para la autenticaci\u00f3n\/encriptaci\u00f3n del tr\u00e1fico, m\u00e1s r\u00e1pido pasar\u00e1 por el firewall chino.<\/li>\n<\/ul>\n<p><\/p>\n<p>Esto es lo que hemos logrado descubrir sobre estos rumores:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter y otros servicios similares est\u00e1n realmente bloqueados (su K.O.), pero muchos dominios t\u00e9cnicos de Google, por ejemplo, no est\u00e1n bloqueados y funcionan (como gstatic.com). De aqu\u00ed se deduce que no se debe eliminar sin pensar todos los recursos de Google y otros que parecen estar bloqueados.<\/li>\n<li>Cualquier tr\u00e1fico que cruce la frontera realmente a\u00f1ade un retardo considerable a su tiempo. Observa dos resultados. Un sitio, una p\u00e1gina, simple GET <em>curl<\/em>\u2019om. La primera medici\u00f3n es desde China (la hermosa ciudad de Shenzhen). La segunda medici\u00f3n es desde fuera, en Hong Kong (que tiene soberan\u00eda, y entre \u00e9l y el mundo no hay firewall). La distancia entre las ciudades es 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    % Recibido % Transferido  Velocidad Media   Tiempo    Tiempo     Tiempo  Actual\n                                 Dload  Upload   Total   Gastado    Queda  Velocidad\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    % Recibido % Transferido  Velocidad Media   Tiempo    Tiempo     Tiempo  Actual\n                                 Dload  Upload   Total   Gastado    Queda  Velocidad\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>Presta atenci\u00f3n a <strong>time_connect<\/strong>. En general, ves el resultado: el firewall a\u00f1ade 4 segundos extra, lo cual es extremadamente largo.<\/p>\n<p><\/p>\n<ul>\n<li>Los t\u00faneles VPN e IPSEC realmente caen con frecuencia. De esto hablar\u00e9 m\u00e1s adelante y con m\u00e1s detalle. Los servidores VPN que utilizan los usuarios son bloqueados con el tiempo (normalmente dentro de un d\u00eda despu\u00e9s de que comienzan a usarse). <\/li>\n<li>Hay una opini\u00f3n de personas que viven en China que dice que cuanto m\u00e1s simple es la encriptaci\u00f3n del tr\u00e1fico, m\u00e1s r\u00e1pido pasa por la frontera, porque es f\u00e1cil entender que no hay nada ilegal en \u00e9l. Y de igual manera, el tr\u00e1fico \u201climpio\u201d recibe m\u00e1s ancho de banda y velocidad de paso, mientras que el tr\u00e1fico \u201csucio\u201d, en el que no se puede distinguir nada, obtiene un paso m\u00e1s lento. Como ejemplo, citar\u00e9 curl hacia <em>ifconfig.co<\/em> a trav\u00e9s del protocolo HTTPS y 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>La diferencia de 5 segundos en el tiempo total de carga de 13 bytes. Al realizar esta prueba varias veces, se puede observar que la solicitud GET por HTTP se completa en un tiempo bastante constante, mientras que en HTTPS el sitio a veces responde en 3, 5, 10 e incluso 17 segundos. A veces se producen errores de SSL:<\/p>\n<p><\/p>\n<p><code>Error desconocido de protocolo SSL en la conexi\u00f3n a ifconfig.co:443.<\/code><\/p>\n<p><\/p>\n<p>Entonces, \u00bfqu\u00e9 tenemos:<\/p>\n<p><\/p>\n<ul>\n<li>Los problemas causados por el firewall chino, como se describi\u00f3 anteriormente.<\/li>\n<li>Los pings a recursos externos y dentro de t\u00faneles se pierden peri\u00f3dicamente.<\/li>\n<li>La latencia entre dos puntos cambia constantemente y a menudo es simplemente impredecible. Al conectar distintas ciudades\/regiones, esperas que, dadas las ubicaciones geogr\u00e1ficas de las regiones, la latencia sea menor, pero obtienes exactamente lo contrario. <\/li>\n<li>Internet y las conexiones funcionan de forma r\u00e1pida a veces y de forma lenta en otras. Hay una peque\u00f1a dependencia del momento del d\u00eda y del d\u00eda de la semana, pero no siempre.<\/li>\n<li>Las consultas DNS al exterior desde China a veces superan el tiempo de espera permitido.<\/li>\n<\/ul>\n<p><\/p>\n<p>El panorama que se dibuja es simplemente \"excelente\". <\/p>\n<p><\/p>\n<p>El centro de datos, como mencion\u00e9, est\u00e1 en el este de EE. UU., y todo SEMrush consiste en decenas de productos interconectados, backend, frontend, bases de datos, y todo esto en el centro de datos y en la nube. Como equipo de administradores de sistemas, se nos plante\u00f3 el desaf\u00edo de comenzar a trabajar r\u00e1pidamente en China con un esfuerzo m\u00ednimo.<\/p>\n<p><\/p>\n<p>Ten\u00edamos que responder a una pregunta importante: \u00bfpodemos resolver todos los problemas asociados con Internet chino y el firewall a nivel de red\/nube\/servidores de manera eficiente?<\/p>\n<p><\/p>\n<p>Comenzamos con la obtenci\u00f3n de <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>-licencia<\/a><\/noindex>.<\/p>\n<p><\/p>\n<h2 id=\"icp-licenziya\">Licencia ICP<\/h2>\n<p><\/p>\n<p>Para poder alojar nuestro servicio en China continental y realizar pruebas, primero es necesario obtener la licencia ICP para el dominio.<\/p>\n<p><\/p>\n<p>Si el tr\u00e1fico de los usuarios de su sitio web se termina dentro de China continental y su dominio no tiene licencia ICP, su tr\u00e1fico ser\u00e1 bloqueado por el proveedor\/host. Es interesante que la licencia ICP especifique un proveedor concreto, ya sea Cloudflare o Alibaba Cloud. Por lo tanto, si obtuvo una licencia ICP para Cloudflare y aloj\u00f3 su sitio con ellos, posteriormente no podr\u00e1 migrar \"sin problemas\" a Alibaba Cloud. Tendr\u00e1 que a\u00f1adir otro hosting a esta licencia.<\/p>\n<p><\/p>\n<p>Al obtener la licencia ICP para el dominio, pudimos concebir e implementar ideas y soluciones t\u00e9cnicas espec\u00edficas.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie-resheniy\">Pruebas de soluciones<\/h2>\n<p><\/p>\n<p>Pero antes de crear variaciones de staging, ajustar configuraciones, optimizar el rendimiento del sitio y su velocidad, es necesario elegir una herramienta para su prueba, con el fin de ver qu\u00e9 acciones mejoran o, por el contrario, perjudican el funcionamiento del sitio.<\/p>\n<p><\/p>\n<p>Nuestra herramienta para pruebas deb\u00eda cumplir con dos requisitos principales:<\/p>\n<p><\/p>\n<ul>\n<li>debe poder realizar pruebas desde China,<\/li>\n<li>debe tener pruebas basadas en navegador.<\/li>\n<\/ul>\n<p><\/p>\n<p>As\u00ed encontramos <noindex><a rel=\"nofollow\" href=\"https:\/\/www.catchpoint.com\/\">Catchpoint<\/a><\/noindex>! Tienen una excelente cobertura de puntos de prueba en todo el mundo. A trav\u00e9s de esta herramienta, tambi\u00e9n se pueden realizar pruebas desde 100500 provincias en China. En cada una, varios proveedores diferentes + la posibilidad de hacer <strong>pruebas Backbone (algo similar a una virtualizaci\u00f3n en el centro de datos) y<\/strong>pruebas Lastmile (maximizada en condiciones de usuario, tambi\u00e9n conocida como estaci\u00f3n de trabajo). El \u00faltimo tipo de pruebas es m\u00e1s costoso. <strong>Al firmar un contrato anual (no se puede hacer por menos), comenzamos a estudiar la herramienta. Debo admitir que nos sorprendi\u00f3 gratamente su funcionalidad. Se pueden realizar:<\/strong>Pruebas DNS,<\/p>\n<p><\/p>\n<p>Pruebas web (basadas en navegador, simple GET\/POST, emulaci\u00f3n de cliente m\u00f3vil, etc.),<\/p>\n<p><\/p>\n<ul>\n<li>Verificaciones transaccionales (por ejemplo, inicio de sesi\u00f3n),<\/li>\n<li>Pruebas API,<\/li>\n<li>Ping, traceroute, NTP, etc.<\/li>\n<li>No se puede enumerar todo. Y lo m\u00e1s importante, cada prueba se puede personalizar bastante bien, a\u00f1adiendo varios encabezados y otros par\u00e1metros. El resultado es una gran cantidad de informaci\u00f3n que describe completamente su prueba. En lo que respecta a lo m\u00e1s interesante para nosotros (pruebas basadas en navegador), los resultados incluyen:<\/li>\n<li>Conexi\u00f3n, Espera, Carga, SSL, tiempo DNS,<\/li>\n<\/ul>\n<p><\/p>\n<p>TTFB, TTLB, Documento completo, Tiempo de renderizado, carga del DOM,<\/p>\n<p><\/p>\n<ul>\n<li>Respuesta (algo cercano al Tiempo hasta el primer byte), Respuesta de p\u00e1gina web (algo cercano al Tiempo hasta el \u00faltimo byte),<\/li>\n<li>Cualquier percentil, promedio, tiempo medio<\/li>\n<li>Y dem\u00e1s.<\/li>\n<li>Cualquier percentil, promedio, tiempo mediano<\/li>\n<li>Etc.<\/li>\n<\/ul>\n<p><\/p>\n<p>Por lo tanto, todas estas m\u00e9tricas ayudan a ver los cambios y entender si ha mejorado. Principalmente, nos enfocamos en <strong>Response, Webpage Response, Median, Percentiles 75 y 95<\/strong>. <\/p>\n<p><\/p>\n<p>Una pregunta importante que ha estado en el aire desde el principio: <strong>\u00bfse puede confiar en 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 \/>\nEste es un gran problema, porque estando en Rusia es pr\u00e1cticamente imposible averiguar con precisi\u00f3n c\u00f3mo funciona un sitio web de China. Al hacer un socks-proxy a trav\u00e9s de una m\u00e1quina virtual, el resultado es que la carga del sitio se toma un par de minutos, lo que es inaceptable para las pruebas; por lo tanto, la \u00fanica opci\u00f3n para la prueba manual son curl y simples GET desde la consola con medici\u00f3n de tiempo. Esto ayuda, porque esta prueba refleja bien la velocidad de la soluci\u00f3n de red, y si tambi\u00e9n hay pruebas de navegador, a\u00fan mejor.<\/p>\n<p><\/p>\n<p>M\u00e1s tarde, nosotros mismos viajamos a China y nos aseguramos de que <strong>se puede confiar en Catchpoint, ya que refleja con bastante precisi\u00f3n las m\u00e9tricas reales de velocidad.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"cloudflare-china-network\">Red de Cloudflare China<\/h2>\n<p><\/p>\n<p>Dado que para el dominio principal semrush.com usamos con \u00e9xito Cloudflare, decidimos probar de inmediato su funci\u00f3n llamada <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloudflare.com\/network\/china\/\">China Network<\/a><\/noindex>. Esta opci\u00f3n se activa solo para sitios de Enterprise mediante una solicitud separada y por un costo adicional. Tambi\u00e9n est\u00e1 disponible solo para sitios que tienen la licencia ICP correspondiente, donde Cloudflare est\u00e1 indicado como proveedor. Una vez activada, el sitio tiene acceso a la \"CDN china\" de Cloudflare: el tr\u00e1fico de las regiones chinas aterriza en el PoP (Puntos de Presencia) m\u00e1s cercano de CF y luego se entrega a trav\u00e9s de sus redes o las de los proveedores\/colaboradores hasta el origen. <\/p>\n<p><\/p>\n<p>El esquema de este banco de pruebas se presenta a continuaci\u00f3n.<\/p>\n<p><\/p>\n<p>Para nosotros, esta es una excelente opci\u00f3n. Resulta que el segundo dominio tambi\u00e9n estar\u00e1 bajo CF, lo que no aumenta la cantidad de soluciones utilizadas en la empresa y casi no complica la infraestructura.<\/p>\n<p><\/p>\n<p>Hicimos pruebas de navegador y esto es lo que obtuvimos:<\/p>\n<p><\/p>\n<p>Los rombos rojos son falls de las pruebas. Las falls de abajo son errores de DNS (timeout de resoluci\u00f3n). Las falls de arriba son 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>La mediana, despu\u00e9s de eliminar la carga de <em>reCaptcha<\/em> (un servicio de Google bloqueado en China) baj\u00f3 de 28 a 18 segundos. Pero aun as\u00ed, son m\u00e9tricas horribles, teniendo en cuenta que la misma prueba para semrush.com (desde EE.UU.) daba menos de 10 segundos para el 95% de los usuarios (desde EE.UU.) en la misma p\u00e1gina (est\u00e1tica + din\u00e1mica).<\/p>\n<p><\/p>\n<p>Se puede acceder a cada prueba y ver <em>Waterfall<\/em> y otros par\u00e1metros m\u00e1s detallados. Comenzamos a investigar las causas de los errores, y aunque para los tiempos de espera todo est\u00e1 m\u00e1s o menos claro: internet en China \"a veces se conecta, a veces se desconecta\", por lo que la velocidad de conexi\u00f3n y la carga de recursos del extranjero son inestables y desiguales, los errores de DNS nos sorprendieron mucho. Descubrimos que <em>PoP<\/em> en realidad est\u00e1n en China, la direcci\u00f3n del sitio se resuelve en una IP anycast, pero los servidores DNS utilizados son estadounidenses, lo que obliga a las consultas DNS a cruzar la frontera, por lo que a veces fallan.<\/p>\n<p><\/p>\n<p>Aclarando esta cuesti\u00f3n con CF, se supo que <strong>no tienen sus propios servidores DNS en China<\/strong>, y cu\u00e1ndo los tendr\u00e1n \u2014 a\u00fan es desconocido.<\/p>\n<p><\/p>\n<p>Por lo tanto, decidimos probar solo el DNS de Cloudflare y cambiamos el mecanismo de funcionamiento de Cloudflare para nuestro sitio a modo de \"<strong>Solo DNS<\/strong>\". Este es un modo en el que Cloudflare no proxy el tr\u00e1fico, lo que significa que no proporciona protecci\u00f3n contra DDoS, CDN y otras caracter\u00edsticas, y opera en modo de servidor DNS normal. <\/p>\n<p><\/p>\n<p>Este stand se presenta esquem\u00e1ticamente en la siguiente imagen. La imagen tiene en cuenta el nuevo conocimiento de que los servidores DNS de Cloudflare est\u00e1n detr\u00e1s del firewall.<\/p>\n<p><\/p>\n<p>En Catchpoint ejecutamos pruebas GET simples (no browser-based), que mostraron muchos fallos. La causa de estos fueron los mismos errores de DNS.<\/p>\n<p><\/p>\n<p>Empezamos a depurar estos errores con ayuda de <em>dig<\/em> y descubrimos que en la primera consulta la direcci\u00f3n se determina correctamente, pero en las consultas subsiguientes obtenemos cada vez <em>SERVFAIL<\/em> y <em>no encontrado<\/em>. \u00bfDe d\u00f3nde viene esto?<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192\nHost semrushchina.cn no encontrado: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192\nHost semrushchina.cn no encontrado: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192\nHost semrushchina.cn no encontrado: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192\nHost semrushchina.cn no encontrado: 2(SERVFAIL)<\/code><\/pre>\n<p><\/p>\n<p>Al consultar los servidores NS de Cloudflare directamente, no hay tales errores:<\/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\nUtilizando el servidor de dominio:\nNombre: ray.ns.cloudflare.com.\nDirecci\u00f3n: 173.245.59.138#53\nAlias: \n\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192\nUtilizando el servidor de dominio:\nNombre: ray.ns.cloudflare.com.\nDirecci\u00f3n: 173.245.59.138#53\nAlias: \n\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192\nsemrushchina.cn tiene direcci\u00f3n 220.170.186.192<\/code><\/pre>\n<p><\/p>\n<p>As\u00ed que el problema est\u00e1 del lado del servidor DNS \"local\" o del servidor del proveedor.<br \/>\nInvestigaciones posteriores mostraron que <em>SERVFAIL<\/em> recibimos en la resoluci\u00f3n <em>registros<\/em>AAAA. <\/p>\n<p><\/p>\n<p>Result\u00f3 que al consultar a Cloudflare <em>AAAA<\/em>-registro que no existe en el dominio, Cloudflare respondi\u00f3 <em>A<\/em>-con un registro, lo cual es un error y una discrepancia con el RFC. Por lo que al resolvedor local (<em>x.x.x.x<\/em>) no le gust\u00f3 y respondi\u00f3 <em>SERVFAIL<\/em>. En el registro a continuaci\u00f3n, este comportamiento se observa claramente:<\/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;; opciones globales: +cmd\n;; Se obtuvo respuesta:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, estado: SERVFAIL, id: 55467\n;; flags: qr rd ra; QUERY: 1, RESPUESTA: 0, AUTORIDAD: 0, ADICIONAL: 1\n\n;; SECCI\u00d3N PSEUDOOPT:\n; EDNS: versi\u00f3n: 0, flags:; udp: 4096\n;; SECCI\u00d3N DE PREGUNTAS:\n;semrushchina.cn.               IN      AAAA\n\n;; Tiempo de consulta: 334 mseg\n;; SERVIDOR: x.x.x.x#53(x.x.x.x)\n;; CUANDO: Mar Ago 14 23:38:50 CST 2018\n;; TAMA\u00d1O MSG recibido: 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;; opciones globales: +cmd\n;; Se obtuvo respuesta:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, estado: NOERROR, id: 63944\n;; flags: qr aa rd; QUERY: 1, RESPUESTA: 1, AUTORIDAD: 0, ADICIONAL: 1\n;; ADVERTENCIA: se solicit\u00f3 recursi\u00f3n pero no est\u00e1 disponible\n\n;; SECCI\u00d3N PSEUDOOPT:\n; EDNS: versi\u00f3n: 0, flags:; udp: 512\n;; SECCI\u00d3N DE PREGUNTAS:\n;semrushchina.cn.               IN      AAAA\n\n;; SECCI\u00d3N DE RESPUESTAS:\nsemrushchina.cn.        300     IN      A       220.170.186.192\n\n;; Tiempo de consulta: 185 mseg\n;; SERVIDOR: 173.245.58.105#53(173.245.58.105)\n;; CUANDO: Mar Ago 14 23:43:03 CST 2018\n;; TAMA\u00d1O MSG recibido: 60\n<\/code><\/pre>\n<p><\/p>\n<p>Enviamos un informe de error a Cloudflare, y lo corrigieron despu\u00e9s de un tiempo. Result\u00f3 interesante: actualmente en China a\u00fan no hay soporte para IPv6, por lo que Cloudflare no pod\u00eda proporcionar su direcci\u00f3n IPv6 en la respuesta a la consulta <em>AAAA<\/em>-registro. Al final, todo se resolvi\u00f3 de tal manera que para China Cloudflare comenz\u00f3 a responder <em>NODATA<\/em> a tales consultas.<\/p>\n<p><\/p>\n<p>As\u00ed que los errores de DNS en las pruebas de Catchpoint disminuyeron dr\u00e1sticamente, pero no del todo. Los timeouts tampoco desaparecieron:<\/p>\n<p><\/p>\n<p>Y comenzamos a buscar otra soluci\u00f3n. <\/p>\n<p><\/p>\n<p>En la pr\u00f3xima parte contar\u00e9 c\u00f3mo probamos la nube china <strong>Alibaba Cloud<\/strong>, c\u00f3mo con un poco de &#171;magia&#187; de Nginx pudimos crear r\u00e1pidamente PoC (Prueba de Concepto) de soluciones, como creamos soluciones Multi-Cloud, una de las cuales al final ayud\u00f3 enormemente a acelerar el funcionamiento del servicio desde China.<\/p>\n<p><\/p>\n<p><strong>\u00a1Est\u00e9n atentos!<\/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>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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\udd47C\u00f3mo superamos el Gran Cortafuegos de China (parte 1) | ProHoster","description":"\u00a1Hola a todos! Soy Nikita, ingeniero de sistemas de la empresa SEMrush.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/35939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=35939"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/35939\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=35939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=35939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=35939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}