{"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\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","title":{"rendered":"Come abbiamo superato il Grande Firewall Cinese (parte 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ciao a tutti!<\/p>\n<p><\/p>\n<p>In collegamento Nikita - ingegnere di sistema dell'azienda <strong>SEMrush<\/strong>. Oggi vi racconter\u00f2 come ci siamo trovati di fronte alla sfida di garantire la stabilit\u00e0 del nostro servizio semrush.com in Cina e quali problemi abbiamo incontrato durante l'esecuzione (considerando la posizione del nostro data center sulla costa orientale degli Stati Uniti).<\/p>\n<p><\/p>\n<p>Saranno molte le storie, suddivise in diversi articoli. Racconter\u00f2 come \u00e8 andata: da un servizio completamente non funzionante in Cina a prestazioni del servizio pari a quelle della versione americana per gli americani. Prometto che sar\u00e0 interessante e utile. Dunque, iniziamo.<\/p>\n<p><\/p>\n<h2 id=\"problemy-kitayskogo-interneta\">Problemi di internet in Cina<\/h2>\n<p><\/p>\n<p>Anche la persona pi\u00f9 lontana dalla specializzazione nell'amministrazione di rete ha almeno sentito parlare <strong>del Grande Firewall Cinese<\/strong>. Uuu, suona bene, vero? Ma che cos'\u00e8, come funziona davvero \u2014 la questione \u00e8 abbastanza complessa. Su internet si possono trovare molti articoli dedicati a questo, ma dal punto di vista tecnico la struttura di questo firewall non \u00e8 descritta da nessuna parte. Il che, in fondo, non sorprende. Ammetto subito che, al termine dell'anno di lavoro, non sar\u00f2 in grado di dire esattamente come funziona, ma posso raccontare le mie osservazioni e conclusioni pratiche. Iniziamo con le voci su questo firewall.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Ci sono molte voci su questo firewall. Diamo un'occhiata alle principali e pi\u00f9 interessanti e raccogliamole in un'unica lista:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter e altri servizi simili sono bloccati e non funzionano in Cina.<\/li>\n<li>Qualsiasi traffico che va oltre i confini della Cina e in Cina viene analizzato e limitato tramite machine learning (in caso di traffico sospetto), il che rallenta notevolmente il (traffico) che attraversa il confine.<\/li>\n<li>I servizi segreti cinesi violeranno qualsiasi traffico crittografato che passa attraverso il loro firewall.<\/li>\n<li>I tunnel VPN e i tunnel IPSEC sono instabili, cadono e vengono costantemente bloccati.<\/li>\n<li>Pi\u00f9 semplice \u00e8 la crittografia, pi\u00f9 semplice \u00e8 la passphrase usata per l'autenticazione\/crittografia del traffico, pi\u00f9 velocemente passa attraverso il firewall cinese.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ecco cosa siamo riusciti a scoprire su queste voci:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter e altri servizi simili sono davvero bloccati (il vostro KO), ma molti domini tecnici di Google, ad esempio, non sono bloccati e funzionano (lo stesso gstatic.com). Da ci\u00f2 si deduce che non si dovrebbe eliminare imprudentemente tutte le risorse google e simili che sembrano bloccate.<\/li>\n<li>Qualsiasi traffico che attraversa il confine aggiunge davvero un ritardo significativo al suo tempo. Guardate i due risultati. Un sito, una pagina, semplice GET <em>curl<\/em>\u2019om. La prima misurazione \u00e8 stata effettuata direttamente dalla Cina (la splendida citt\u00e0 di Shenzhen). La seconda misurazione dall'esterno a Hong Kong (ha sovranit\u00e0, e tra essa e il mondo non ci sono firewall). La distanza tra le citt\u00e0 in linea retta \u00e8 di circa 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  % Totale    % Ricevuto % Transferido  Velocit\u00e0 Media   Tempo    Tempo     Tempo  Attuale\n                                 Dload  Upload   Totale   Trascorso    Rimasto  Velocit\u00e0\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  % Totale    % Ricevuto % Transferido  Velocit\u00e0 Media   Tempo    Tempo     Tempo  Attuale\n                                 Dload  Upload   Totale   Trascorso    Rimasto  Velocit\u00e0\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>Prestare attenzione a <strong>time_connect<\/strong>. E in generale, vedete il risultato: il firewall aggiunge 4 secondi extra, il che \u00e8 terribilmente lungo.<\/p>\n<p><\/p>\n<ul>\n<li>Le VPN e i tunnel IPSEC cadono davvero spesso. Di questo parler\u00f2 pi\u00f9 avanti e in modo pi\u00f9 dettagliato. I server VPN utilizzati dagli utenti vengono bloccati nel tempo (solitamente entro un giorno dall'inizio dell'uso). <\/li>\n<li>C'\u00e8 un'opinione, ottenuta da persone che vivono in Cina, secondo cui pi\u00f9 semplice \u00e8 la crittografia del traffico, pi\u00f9 velocemente esso attraversa il confine, perch\u00e9 \u00e8 facile capire che non c'\u00e8 nulla di illegale. E allo stesso modo, il traffico \"pulito\" riceve pi\u00f9 larghezza di banda e velocit\u00e0 di passaggio, mentre il traffico \"sporca\", in cui non si riesce a decifrare nulla, ha invece un passaggio pi\u00f9 lento. Per esempio, cito curl fino a <em>ifconfig.co<\/em> tramite il protocollo 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  % Totale    % Ricevuto % Xferd  Velocit\u00e0 Media   Tempo    Tempo     Tempo  Corrente\n                                 Dload  Upload   Totale   Speso    Rimasto  Velocit\u00e0\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  % Totale    % Ricevuto % Xferd  Velocit\u00e0 Media   Tempo    Tempo     Tempo  Corrente\n                                 Dload  Upload   Totale   Speso    Rimasto  Velocit\u00e0\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 differenza \u00e8 di 5 secondi sul tempo totale di caricamento di 13 byte. Effettuando questo test pi\u00f9 volte, si pu\u00f2 notare che la richiesta GET su HTTP si completa in media in tempi simili ogni volta, mentre su HTTPS il sito a volte risponde in 3, 5, 10 e anche 17 secondi. A volte ci sono errori SSL:<\/p>\n<p><\/p>\n<p><code>Unknown SSL protocol error in connection to ifconfig.co:443.<\/code><\/p>\n<p><\/p>\n<p>Quindi, cosa abbiamo:<\/p>\n<p><\/p>\n<ul>\n<li>Problemi causati dal firewall cinese, come descritto sopra.<\/li>\n<li>I ping verso risorse esterne e all'interno dei tunnel scompaiono periodicamente.<\/li>\n<li>La latenza tra due punti cambia costantemente e spesso \u00e8 del tutto imprevedibile. Collegando diverse citt\u00e0\/regioni, ti aspetti che, in base alla posizione geografica delle regioni, la latenza sia inferiore, ma ottieni esattamente l'opposto. <\/li>\n<li>Internet e i canali di comunicazione funzionano a volte velocemente, a volte lentamente. C'\u00e8 una piccola dipendenza dall'ora del giorno e dal giorno della settimana, ma non sempre.<\/li>\n<li>Le richieste DNS verso il mondo esterno dalla Cina a volte superano il timeout consentito.<\/li>\n<\/ul>\n<p><\/p>\n<p>Il quadro che emerge \u00e8 semplicemente \"ottimo\". <\/p>\n<p><\/p>\n<p>Il data center, come ho gi\u00e0 detto, si trova nel nostro est degli Stati Uniti, e tutto il SEMrush consiste in decine di prodotti interconnessi, backend, frontend, database, e tutto questo nel data center e nei cloud. Davanti a noi, come squadra di amministratori di sistema, ci \u00e8 stato dato l'incarico di iniziare a lavorare in Cina con sforzi minimi e in tempi brevi.<\/p>\n<p><\/p>\n<p>Abbiamo dovuto rispondere a una domanda importante: si pu\u00f2 gestire tutto il problema legato a Internet e al firewall cinese a livello di rete\/cloud\/server con il minimo sforzo?<\/p>\n<p><\/p>\n<p>Abbiamo iniziato con l'ottenere <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>-licenza<\/a><\/noindex>.<\/p>\n<p><\/p>\n<h2 id=\"icp-licenziya\">Licenza ICP<\/h2>\n<p><\/p>\n<p>Per poter ospitare il proprio servizio in Cina (Mainland China) e effettuare test, \u00e8 necessario prima ottenere una licenza ICP per il dominio.<\/p>\n<p><\/p>\n<p>Se il traffico degli utenti del tuo sito termina all'interno della Cina continentale e se il tuo dominio non ha una licenza ICP, il tuo traffico sar\u00e0 bloccato dal fornitore\/hosting. \u00c8 interessante notare che nella licenza ICP viene specificato un fornitore specifico, sia esso Cloudflare o Alibaba Cloud. Pertanto, se hai ottenuto una licenza ICP per Cloudflare e hai ospitato il tuo sito con loro, successivamente non potrai trasferirti \"senza soluzione di continuit\u00e0\" su Alibaba Cloud. Dovrai aggiungere un altro hosting a questa licenza.<\/p>\n<p><\/p>\n<p>Dopo aver ricevuto la licenza ICP per il dominio, siamo stati in grado di ideare e implementare specifiche idee e soluzioni tecniche.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie-resheniy\">Test delle soluzioni<\/h2>\n<p><\/p>\n<p>Ma prima di iniziare a creare direttamente le varianti di staging, regolare le impostazioni, ottimizzare il funzionamento del sito e la sua velocit\u00e0, \u00e8 necessario scegliere uno strumento per il suo testing, in modo da vedere quali delle nostre azioni migliorano o, al contrario, peggiorano il funzionamento del sito.<\/p>\n<p><\/p>\n<p>Il nostro strumento di testing doveva soddisfare due requisiti principali:<\/p>\n<p><\/p>\n<ul>\n<li>deve avere la possibilit\u00e0 di avviare test dalla Cina,<\/li>\n<li>deve disporre di test browser.<\/li>\n<\/ul>\n<p><\/p>\n<p>Cos\u00ec abbiamo trovato <noindex><a rel=\"nofollow\" href=\"https:\/\/www.catchpoint.com\/\">Catchpoint<\/a><\/noindex>! Hanno una copertura eccellente di punti di test in tutto il mondo. In Cina, tramite questo strumento, \u00e8 possibile eseguire test anche da 100500 province. In ciascuna ci sono diversi fornitori + la possibilit\u00e0 di effettuare <strong>Backbone<\/strong>-test (una sorta di virtualizzazione in data center) e <strong>Lastmile<\/strong>-test (massimo avvicinamento alle condizioni utente, ovvero stazione di lavoro). L'ultimo tipo di test \u00e8 pi\u00f9 costoso.<\/p>\n<p><\/p>\n<p>Firmando un contratto annuale (non si pu\u00f2 fare meno), abbiamo iniziato a esplorare lo strumento. A dire il vero, siamo rimasti piacevolmente colpiti dalle sue funzionalit\u00e0. \u00c8 possibile lanciare:<\/p>\n<p><\/p>\n<ul>\n<li>test DNS,<\/li>\n<li>test web (browser, semplice GET\/POST, emulazione client mobile, ecc.),<\/li>\n<li>verifiche transazionali (ad esempio, accesso),<\/li>\n<li>test API,<\/li>\n<li>Ping, traceroute, NTP, ecc.<\/li>\n<\/ul>\n<p><\/p>\n<p>Non \u00e8 possibile elencare tutto. E cosa pi\u00f9 importante, ogni test pu\u00f2 essere abbastanza personalizzato, aggiungendo una serie di intestazioni e altri parametri. Il risultato \u00e8 una quantit\u00e0 enorme di informazioni che descrivono completamente il tuo test. Se parliamo delle cose pi\u00f9 interessanti per noi (test browser), il risultato comprende:<\/p>\n<p><\/p>\n<ul>\n<li>Connect, Wait, Load, SSL, DNS time,<\/li>\n<li>TTFB, TTLB, Document complete, Render time, DOM load,<\/li>\n<li>Response (qualcosa di simile al Time To First Byte), Webpage Response (qualcosa di simile al Time To Last Byte),<\/li>\n<li>Qualsiasi percentile, Media, Tempo Mediano<\/li>\n<li>E cos\u00ec via.<\/li>\n<\/ul>\n<p><\/p>\n<p>Di conseguenza, tutte queste metriche aiutano a vedere i cambiamenti e a capire se le cose sono migliorate. Abbiamo principalmente esaminato <strong>Response, Webpage Response, Mediana, 75 e 95 Percentili<\/strong>. <\/p>\n<p><\/p>\n<p>Una domanda importante che aleggiava fin dall'inizio: <strong>ci si pu\u00f2 fidare di 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 \/>\n\u00c8 un grosso problema, perch\u00e9 essere in Russia rende praticamente impossibile conoscere in modo veritiero il funzionamento di un sito dalla Cina. Eseguendo un socks-proxy tramite una macchina virtuale, si ottiene un caricamento del sito in pochi minuti, il che \u00e8 inaccettabile per i test, quindi l'unica opzione per i test manuali rimane curl e semplici GET dalla console con misurazione del tempo. Questo aiuta, perch\u00e9 questo test riflette bene la velocit\u00e0 della soluzione di rete e se ci sono anche test browser, va ancora meglio.<\/p>\n<p><\/p>\n<p>In seguito, siamo andati noi stessi in Cina e ci siamo assicurati che <strong>ci si pu\u00f2 fidare di Catchpoint, riflette abbastanza accuratamente i parametri reali di velocit\u00e0 operativa.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"cloudflare-china-network\">Cloudflare China Network<\/h2>\n<p><\/p>\n<p>Poich\u00e9 per il dominio principale semrush.com utilizziamo con successo Cloudflare, abbiamo deciso di provare subito la loro funzionalit\u00e0 chiamata <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloudflare.com\/network\/china\/\">China Network<\/a><\/noindex>. Questa opzione \u00e8 attivabile solo per siti Enterprise su richiesta separata e a pagamento. \u00c8 disponibile anche solo per siti che dispongono di una licenza ICP corrispondente, in cui Cloudflare \u00e8 indicato come fornitore. Dopo l'attivazione, il sito ha accesso al \"CDN cinese\" di Cloudflare: il traffico dalle regioni cinesi viene instradato nei punti di presenza (PoP) pi\u00f9 vicini di CF, e poi viene consegnato all'origine tramite le loro reti o quelle dei provider\/partner. <\/p>\n<p><\/p>\n<p>Lo schema di questo banco di prova \u00e8 mostrato di seguito.<\/p>\n<p><\/p>\n<p>Per noi \u00e8 una soluzione eccellente. Risulta quindi che il secondo dominio sar\u00e0 anch'esso sotto CF, il che non aumenta il numero di soluzioni utilizzate nell'azienda e non complica praticamente l'infrastruttura.<\/p>\n<p><\/p>\n<p>Abbiamo avviato dei test browser e questo \u00e8 il risultato:<\/p>\n<p><\/p>\n<p>I rombi rossi indicano i fallimenti nei test. I fallimenti in basso sono errori DNS (timeout di risoluzione). I fallimenti in alto sono timeout.<\/p>\n<p><\/p>\n<p><em>Uptime: 86.6<br \/>\nMediana: 18s<br \/>\n75 Percentile: 29.3s<br \/>\n95 Percentile: 60s<\/em><\/p>\n<p><\/p>\n<p>La mediana, dopo aver rimosso il caricamento <em>reCaptcha<\/em> (servizio di Google, bloccato in Cina), \u00e8 scesa da 28 a 18 secondi. Ma sono comunque parametri terribili, considerando che lo stesso test per semrush.com (dalla USA) ha dato meno di 10 secondi per il 95% degli utenti (dalla USA) sulla stessa pagina (statica + dinamica).<\/p>\n<p><\/p>\n<p>Puoi accedere a ogni test e vedere <em>Waterfall<\/em> e altri parametri pi\u00f9 dettagliati. Abbiamo iniziato a esplorare le cause degli errori e se per i timeout \u00e8 tutto pi\u00f9 o meno chiaro: internet in Cina \"va e viene\", perci\u00f2 la velocit\u00e0 di connessione e il caricamento di risorse dall'estero \u00e8 instabile e variabile, gli errori DNS ci hanno sorpreso molto. Abbiamo scoperto che <em>PoP<\/em> i server Cloudflare sono effettivamente in Cina, l'indirizzo del sito viene risolto in un IP anycast, ma i server DNS utilizzati sono americani, il che costringe le richieste DNS a passare attraverso il confine, quindi a volte falliscono.<\/p>\n<p><\/p>\n<p>Chiedendo delucidazioni a CF, abbiamo scoperto che <strong>non hanno propri server DNS in Cina<\/strong>, e quando ci saranno - al momento non \u00e8 noto.<\/p>\n<p><\/p>\n<p>Pertanto, abbiamo deciso di testare solo il DNS di Cloudflare e abbiamo cambiato il meccanismo di funzionamento di Cloudflare per il nostro sito nella modalit\u00e0 \"<strong>Solo DNS<\/strong>\". Questa \u00e8 una modalit\u00e0 in cui Cloudflare non instrada il traffico attraverso di s\u00e9, il che significa che non fornisce protezione da DDoS, CDN e altre funzionalit\u00e0, e funziona come un normale server DNS. <\/p>\n<p><\/p>\n<p>Questo stand \u00e8 schematicamente presentato nel disegno seguente. Nel disegno sono state considerate le conoscenze emerse sul fatto che i server DNS di Cloudflare sono dietro un firewall.<\/p>\n<p><\/p>\n<p>In Catchpoint abbiamo avviato semplici test GET (non browser), che hanno mostrato molti fallimenti. La causa era sempre la stessa: errori DNS.<\/p>\n<p><\/p>\n<p>Abbiamo iniziato a debuggare questi errori con l'aiuto di <em>dig<\/em> e abbiamo scoperto che alla prima richiesta l'indirizzo viene determinato correttamente, ma alla richiesta ripetuta otteniamo ogni volta <em>SERVFAIL<\/em> e <em>non trovato<\/em>. Da cosa dipende?<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn ha indirizzo 220.170.186.192\nHost semrushchina.cn non trovato: 2(SERVFAIL)<\/code><\/pre>\n<p><\/p>\n<p>Alla richiesta dei server NS di Cloudflare direttamente non ci sono tali errori:<\/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\nUtilizzando il server di dominio:\nNome: ray.ns.cloudflare.com.\nIndirizzo: 173.245.59.138#53\nAlias: \n\nsemrushchina.cn ha indirizzo 220.170.186.192\nsemrushchina.cn ha indirizzo 220.170.186.192\nUtilizzando il server di dominio:\nNome: ray.ns.cloudflare.com.\nIndirizzo: 173.245.59.138#53\nAlias: \n\nsemrushchina.cn ha indirizzo 220.170.186.192\nsemrushchina.cn ha indirizzo 220.170.186.192<\/code><\/pre>\n<p><\/p>\n<p>Quindi, il problema \u00e8 lato \u201clocale\u201d del server DNS o del server del provider.<br \/>\nUlteriori indagini hanno mostrato che <em>SERVFAIL<\/em> riceviamo nella risoluzione <em>record<\/em>AAAA. <\/p>\n<p><\/p>\n<p>Si \u00e8 scoperto che alla richiesta a Cloudflare <em>AAAA<\/em>-record che non esiste nel dominio, Cloudflare ha risposto <em>A<\/em>-con un errore che rappresenta un errore e una discrepanza rispetto all'RFC. Questo ha creato problemi al risolutore locale (<em>x.x.x.x<\/em>) che non gradiva, e cos\u00ec ha risposto <em>SERVFAIL<\/em>. Nel log qui sotto si vede chiaramente questo comportamento:<\/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;; opzioni globali: +cmd\n;; Risposta ricevuta:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: SERVFAIL, id: 55467\n;; flags: qr rd ra; QUERY: 1, RISPOSTA: 0, AUTORIT\u00c0: 0, AGGIUNTIVA: 1\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n;; SEZIONE DOMANDA:\n;semrushchina.cn.               IN      AAAA\n\n;; Tempo della query: 334 msec\n;; SERVER: x.x.x.x#53(x.x.x.x)\n;; QUANDO: Mar Ago 14 23:38:50 CST 2018\n;; DIMENSIONE MSG ricevuta: 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;; opzioni globali: +cmd\n;; Risposta ricevuta:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 63944\n;; flags: qr aa rd; QUERY: 1, RISPOSTA: 1, AUTORIT\u00c0: 0, AGGIUNTIVA: 1\n;; AVVISO: ricorsione richiesta ma non disponibile\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 512\n;; SEZIONE DOMANDA:\n;semrushchina.cn.               IN      AAAA\n\n;; SEZIONE RISPOSTA:\nsemrushchina.cn.        300     IN      A       220.170.186.192\n\n;; Tempo della query: 185 msec\n;; SERVER: 173.245.58.105#53(173.245.58.105)\n;; QUANDO: Mar Ago 14 23:43:03 CST 2018\n;; DIMENSIONE MSG ricevuta: 60\n<\/code><\/pre>\n<p><\/p>\n<p>Abbiamo inviato un bug report a Cloudflare, e hanno corretto il problema dopo qualche tempo. \u00c8 emerso un fatto interessante: attualmente in Cina non c'\u00e8 ancora supporto per l'IPv6, quindi Cloudflare non poteva restituire il proprio indirizzo IPv6 nella risposta alla richiesta <em>AAAA<\/em>-record. Alla fine, si \u00e8 risolto che per la Cina Cloudflare ha iniziato a rispondere <em>NODATA<\/em> a tali richieste.<\/p>\n<p><\/p>\n<p>Cos\u00ec, gli errori DNS nei test di Catchpoint sono diminuiti drasticamente, ma non del tutto. Anche i timeout non sono scomparsi:<\/p>\n<p><\/p>\n<p>E abbiamo iniziato a cercare un'altra soluzione. <\/p>\n<p><\/p>\n<p>Nella prossima parte parler\u00f2 di come abbiamo testato il cloud cinese <strong>Alibaba Cloud<\/strong>, come grazie a un po' di &#171;magia&#187; di Nginx siamo riusciti a creare rapidamente PoC (Proof of Concept) soluzioni, come abbiamo sviluppato soluzioni Multi-Cloud, una delle quali ha davvero aiutato ad accelerare le operazioni del servizio dalla Cina.<\/p>\n<p><\/p>\n<p><strong>Resta sintonizzato!<\/strong><\/p>\n<p><\/p>\n<h3 id=\"sleduyuschie-chasti\">Le prossime parti<\/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.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u041d\u0438\u043a\u0438\u0442\u0430 \u2014 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 S\u0415Mrush.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47Come abbiamo oltrepassato il Grande Firewall Cinese (parte 1) | ProHoster","description":"Ciao a tutti! Qui \u00e8 Nikita \u2014 ingegnere di sistema della compagnia SEMrush.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/35939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=35939"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35939\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}