{"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\/da\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","title":{"rendered":"Hvordan vi kn\u00e6kkede Den Store Kinesiske Firewall (del 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hej alle sammen!<\/p>\n<p><\/p>\n<p>M\u00f8dt! Nikita her \u2013 systemingeni\u00f8r fra virksomheden <strong>SEMrush<\/strong>. I dag vil jeg fort\u00e6lle om, hvordan vi stod over for opgaven med at sikre stabilitet i vores service semrush.com i Kina, og hvilke udfordringer vi st\u00f8dte p\u00e5 undervejs (taget vores datacenter beliggenhed p\u00e5 \u00d8stkysten af USA i betragtning).<\/p>\n<p><\/p>\n<p>Dette vil blive en stor historie, opdelt i flere artikler. Jeg vil fort\u00e6lle om, hvordan det hele foregik for os: fra en service, der slet ikke fungerede fra Kina, til serviceydelser p\u00e5 niveau med den amerikanske version for amerikanerne. Jeg lover, det bliver interessant og nyttigt. S\u00e5 lad os komme i gang.<\/p>\n<p><\/p>\n<h2 id=\"problemy-kitayskogo-interneta\">Kinas internetproblemer<\/h2>\n<p><\/p>\n<p>Selv den, der er mest fremmed for netv\u00e6rksadministration, har h\u00f8rt om <strong>Den Store Kinesiske Brandmur<\/strong>. Uuh, det lyder sejt, ikke? Men hvad er det, og hvordan fungerer det i virkeligheden \u2013 det er et ret komplekst sp\u00f8rgsm\u00e5l. Der findes mange artikler om dette p\u00e5 internettet, men fra et teknisk synspunkt er apparatet bag denne brandmur ikke beskrevet noget sted. Hvilket, ikke overraskende, giver mening. Jeg m\u00e5 indr\u00f8mme, at efter et \u00e5rs arbejde kan jeg ikke pr\u00e6cist sige, hvordan det fungerer, men jeg kan dele nogle observationer og praktiske konklusioner. Lad os starte med rygterne om denne brandmur.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Der er mange rygter om denne brandmur. Lad os samle de vigtigste og mest interessante af dem i \u00e9n liste:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter og andre lignende tjenester er blokeret og fungerer ikke i Kina.<\/li>\n<li>Al trafik, der g\u00e5r UD af Kina og TIL Kina, analyseres og begr\u00e6nses via maskinl\u00e6ring (i tilf\u00e6lde af mist\u00e6nkelig trafik), hvilket forsinker den (trafik), der passerer over gr\u00e6nsen, betydeligt.<\/li>\n<li>Kinesiske efterretningstjenester kan bryde enhver krypteret trafik, der passerer gennem deres brandmur.<\/li>\n<li>VPN-tunneler og IPSEC-tunneler er ustabile, falder og bliver konstant blokeret.<\/li>\n<li>Jo simplere krypteringen er, jo simplere er adgangskoden, der bruges til autentificering\/kryptering af trafikken, jo hurtigere passerer den kinesiske brandmur.<\/li>\n<\/ul>\n<p><\/p>\n<p>Her er, hvad vi har fundet ud af om disse rygter:<\/p>\n<p><\/p>\n<ul>\n<li>Google, Facebook, Twitter og andre lignende tjenester er faktisk blokerede (din KO), men mange tekniske dom\u00e6ner fra Google, for eksempel, er ikke blokerede og fungerer (det samme g\u00e6lder gstatic.com). Derfor: det er ikke klogt at blindt fjerne alle Google- og andre ressourcer, der synes at v\u00e6re blokerede.<\/li>\n<li>Al trafik, der krydser gr\u00e6nsen, tilf\u00f8jer virkelig en betydelig forsinkelse til sin tid. Se p\u00e5 to resultater. \u00c9n hjemmeside, \u00e9n side, simpel GET <em>curl<\/em>fra. Den f\u00f8rste m\u00e5ling er fra Kina (den sk\u00f8nne by Shenzhen). Den anden m\u00e5ling er udenfor fra Hongkong (har suver\u00e6nitet, og der er ikke nogen firewall mellem den og verden). Afstanden mellem byerne er ca. 30-40 km i fugleflugt.<\/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>Bem\u00e6rk venligst <strong>time_connect<\/strong>. Og generelt ser du resultatet: firewallen tilf\u00f8jer 4 ekstra sekunder, hvilket er forf\u00e6rdeligt lang tid.<\/p>\n<p><\/p>\n<ul>\n<li>VPN og IPSEC tunneler falder ofte ud. Det vil jeg fort\u00e6lle mere om senere. VPN-servere, der bruges af brugere, bliver over tid blokeret (som regel inden for en dag efter brugens start). <\/li>\n<li>Der er en opfattelse, som kommer fra folk, der bor i Kina, om at jo simplere krypteringen af trafikken er, jo hurtigere passerer den gr\u00e6nsen, fordi det er let at forst\u00e5, at der ikke er noget ulovligt i den. Og ligeledes f\u00e5r \"ren\" trafik mere b\u00e5ndbredde og hastighed, mens \"beskidt\" trafik, hvor der ikke er noget, der kan analyseres, f\u00e5r en langsommere passage. Som eksempel vil jeg n\u00e6vne curl til <em>ifconfig.co<\/em> over HTTPS og 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>Forskellen p\u00e5 5 sekunder i den samlede downloads tid for 13 bytes. N\u00e5r man k\u00f8rer testen flere gange, bem\u00e6rker man, at GET-anmodninger p\u00e5 HTTP generelt afsluttes p\u00e5 omtrent den samme tid hver gang, mens HTTPS-svarene nogle gange tager 3, 5, 10 og endda 17 sekunder. Der opst\u00e5r nogle gange SSL-fejl:<\/p>\n<p><\/p>\n<p><code>Ukendt SSL-protokolfejl i forbindelsen til ifconfig.co:443.<\/code><\/p>\n<p><\/p>\n<p>S\u00e5 hvad har vi:<\/p>\n<p><\/p>\n<ul>\n<li>Problemerne for\u00e5rsaget af den kinesiske firewall, som beskrevet ovenfor.<\/li>\n<li>Ping til eksterne ressourcer og inde i tunneler forsvinder periodisk.<\/li>\n<li>Latency mellem to punkter \u00e6ndrer sig konstant, og ofte er den helt uforudsigelig. N\u00e5r man forbinder forskellige byer\/regioner, forventer man, at latency baseret p\u00e5 geografisk placering skal v\u00e6re lavere, men man f\u00e5r ofte det stik modsatte. <\/li>\n<li>Internettet og kommunikationskanalerne arbejder nogle gange hurtigt, nogle gange langsomt. Der er en lille afh\u00e6ngighed af tid p\u00e5 dagen og ugen, men ikke altid.<\/li>\n<li>DNS-foresp\u00f8rgsler til den eksterne verden fra Kina overskrider nogle gange den tilladte timeout.<\/li>\n<\/ul>\n<p><\/p>\n<p>Billedet ser ganske \"fremragende\" ud. <\/p>\n<p><\/p>\n<p>Datacenteret, som jeg allerede har n\u00e6vnt, er i \u00d8stasien, og hele SEMrush best\u00e5r af dusinvis af sammenkoblede produkter, backend-systemer, frontend-systemer, databaser, og det hele er i datacenteret og i skyen. Som systemadministratorer har vi f\u00e5et til opgave hurtigt at begynde at arbejde i Kina med minimalt af vores ressourcer.<\/p>\n<p><\/p>\n<p>Vi skulle besvare et vigtigt sp\u00f8rgsm\u00e5l: Kan vi finde en l\u00f8sning med lidt indsats for at h\u00e5ndtere alle problemerne relateret til det kinesiske internet og firewall p\u00e5 netv\u00e6rks-\/cloud-\/serverniveau?<\/p>\n<p><\/p>\n<p>Vi begyndte med at f\u00e5 <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>-licensen<\/a><\/noindex>.<\/p>\n<p><\/p>\n<h2 id=\"icp-licenziya\">ICP-licens<\/h2>\n<p><\/p>\n<p>For at kunne hoste din service inden for Kina (Mainland China) og udf\u00f8re tests, skal man f\u00f8rst have en ICP-licens til dom\u00e6net.<\/p>\n<p><\/p>\n<p>Hvis din hjemmesides brugertrafik termineres i fastlandet Kina, og hvis din dom\u00e6ne ikke har en ICP-licens, vil din trafik blive blokeret hos udbyderen\/hosten. Det er interessant, at ICP-licensen inkluderer en specifik udbyder, hvad enten det er Cloudflare eller Alibaba Cloud. Derfor, hvis du har f\u00e5et en ICP-licens til Cloudflare og hostet din hjemmeside hos dem, vil du ikke kunne \"s\u00f8ml\u00f8st\" flytte til Alibaba Cloud senere. Det vil v\u00e6re n\u00f8dvendigt at tilf\u00f8je endnu en hosting til denne licens.<\/p>\n<p><\/p>\n<p>Efter at have modtaget en ICP-licens til dom\u00e6net, kunne vi t\u00e6nke p\u00e5 og implementere specifikke tekniske id\u00e9er og l\u00f8sninger.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie-resheniy\">Test af l\u00f8sninger<\/h2>\n<p><\/p>\n<p>Men f\u00f8r vi direkte opretter staging-muligheder, drejer knapper, optimerer hjemmesideens funktion og hastighed, skal vi v\u00e6lge et v\u00e6rkt\u00f8j til at teste det, s\u00e5 vi kan se, hvilke af vores handlinger der forbedrer eller omvendt forringer hjemmesidefunktionaliteten.<\/p>\n<p><\/p>\n<p>Vores testv\u00e6rkt\u00f8j skulle opfylde to hovedkrav:<\/p>\n<p><\/p>\n<ul>\n<li>det skal have mulighed for at k\u00f8re tests fra Kina,<\/li>\n<li>det skal have browser-tests.<\/li>\n<\/ul>\n<p><\/p>\n<p>S\u00e5 vi fandt <noindex><a rel=\"nofollow\" href=\"https:\/\/www.catchpoint.com\/\">Catchpoint<\/a><\/noindex>! De har fremragende d\u00e6kning med testpunkter over hele verden. I Kina kan tests ogs\u00e5 k\u00f8res gennem dette v\u00e6rkt\u00f8j fra et stort antal provinser. I hver af dem flere forskellige udbydere + mulighed for at lave <strong>Backbone<\/strong>-tests (noget der ligner en virtuel maskine i datacenteret) og <strong>Lastmile<\/strong>-tests (maksimalt t\u00e6t p\u00e5 brugerforholdene, aka arbejdsstation). Den sidste type tests er dyrere.<\/p>\n<p><\/p>\n<p>Efter at have indg\u00e5et en \u00e5rlig kontrakt (mindre kan ikke lade sig g\u00f8re), begyndte vi at l\u00e6re v\u00e6rkt\u00f8jet at kende. \u00c6rligt talt, vi var positivt overraskede over dets funktionalitet. Man kan k\u00f8re:<\/p>\n<p><\/p>\n<ul>\n<li>DNS-tests,<\/li>\n<li>Web-tests (browser, simpel GET\/POST, emulering af mobilklient osv.),<\/li>\n<li>Transaktionskontroller (f.eks. login),<\/li>\n<li>API-tests,<\/li>\n<li>Ping, traceroute, NTP osv.<\/li>\n<\/ul>\n<p><\/p>\n<p>Man kan ikke n\u00e6vne alt. Og det vigtigste er, at hver test kan tilpasses ganske godt ved at tilf\u00f8je en r\u00e6kke overskrifter og andre parametre. Resultatet giver en enorm m\u00e6ngde information, der fuldt ud beskriver din test. Hvis vi taler om det mest interessante for os (browser tests), inkluderer resultatet:<\/p>\n<p><\/p>\n<ul>\n<li>Connect, Wait, Load, SSL, DNS tid,<\/li>\n<li>TTFB, TTLB, Dokument f\u00e6rdig, Render tid, DOM load,<\/li>\n<li>Respons (noget der ligner Time To First Byte), Webpage Respons (noget der ligner Time To Last Byte),<\/li>\n<li>Enhver percentil, Gennemsnit, Median tid<\/li>\n<li>Og s\u00e5 videre.<\/li>\n<\/ul>\n<p><\/p>\n<p>Disse m\u00e5linger hj\u00e6lper os med at se \u00e6ndringer og forst\u00e5, om tingene er blevet bedre. Vi har prim\u00e6rt set p\u00e5 <strong>Response, Webpage Response, Median, 75 og 95 Percentiles<\/strong>. <\/p>\n<p><\/p>\n<p>Et vigtigt sp\u00f8rgsm\u00e5l, der har v\u00e6ret i luften fra starten: <strong>Kan man stole p\u00e5 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 \/>\nDet er et stort problem, fordi det i Rusland n\u00e6sten er umuligt at f\u00e5 p\u00e5lidelige oplysninger om, hvordan en hjemmeside fungerer fra Kina. Ved at lave en socks-proxy gennem en virtuel maskine f\u00e5r man lastingstiden til hjemmesiden over et par minutter, hvilket er uacceptabelt til tests, s\u00e5 den eneste mulighed for manuel testning er at bruge curl og simple GET-kommandoer fra konsollen med tidsm\u00e5linger. Dette hj\u00e6lper, da denne test godt afspejler hastigheden af netv\u00e6rksl\u00f8sningen, og hvis der er browser tests, er det endnu bedre.<\/p>\n<p><\/p>\n<p>Senere rejste vi selv til Kina og bekr\u00e6ftede, at <strong>Catchpoint kan man stole p\u00e5, det afspejler ret pr\u00e6cist de faktiske hastighedsdata.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"cloudflare-china-network\">Cloudflare China Network<\/h2>\n<p><\/p>\n<p>Da vi med succes bruger Cloudflare til hoveddom\u00e6net semrush.com, besluttede vi at pr\u00f8ve deres funktion kaldet <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloudflare.com\/network\/china\/\">China Network<\/a><\/noindex>. Denne mulighed aktiveres kun for Enterprise-websteder p\u00e5 en separat anmodning og til en separat betaling. Den er ogs\u00e5 kun tilg\u00e6ngelig for websteder, der har en passende ICP-licens, hvor Cloudflare er angivet som udbyder. N\u00e5r den er aktiveret, bliver \"kinesisk CDN\" fra Cloudflare tilg\u00e6ngeligt for webstedet \u2014 trafik fra kinesiske regioner ledes til n\u00e6rmeste PoP (Points of Presence) CF, og derfra leveres det videre gennem deres netv\u00e6rk eller netv\u00e6rk fra udbydere\/partnere til origin. <\/p>\n<p><\/p>\n<p>Skemaet for dette testopstilling er vist nedenfor.<\/p>\n<p><\/p>\n<p>For os er det en fantastisk mulighed. Det betyder, at det andet dom\u00e6ne ogs\u00e5 vil v\u00e6re bag CF, hvilket ikke \u00f8ger antallet af l\u00f8sninger, der bruges i virksomheden, og heller ikke komplicerer infrastrukturen n\u00e6vnev\u00e6rdigt.<\/p>\n<p><\/p>\n<p>Vi har k\u00f8rt browser tests, og her er resultatet:<\/p>\n<p><\/p>\n<p>De r\u00f8de romber er testfejl. Fejlene nederst er DNS fejl (resolve timeout). Fejlene \u00f8verst er timeouts.<\/p>\n<p><\/p>\n<p><em>Uptime: 86.6<br \/>\nMedian: 18s<br \/>\n75 Percentile: 29.3s<br \/>\n95 Percentile: 60s<\/em><\/p>\n<p><\/p>\n<p>Medianen, efter at belastningen fra <em>reCaptcha<\/em> (en Google-tjeneste, der er blokeret i Kina), faldt fra 28 til 18 sek. Men det er stadig uacceptable tal, n\u00e5r man tager i betragtning, at den samme test for semrush.com (fra USA) gav mindre end 10 sekunder for 95% af brugerne (fra USA) p\u00e5 den samme side (statisk + dynamisk).<\/p>\n<p><\/p>\n<p>I hver test kan man g\u00e5 ind og se <em>Waterfall<\/em> og andere mere detaljerede parametre. Vi begyndte at unders\u00f8ge \u00e5rsagerne til fejlene, og hvis det er mere eller mindre klart med timeoutene: internettet i Kina \"samler sig og skiller sig igen\", hvilket g\u00f8r forbindelseshastigheden og indl\u00e6sningen af ressourcer fra udlandet ustabil og varierende, s\u00e5 blev DNS-fejlene os en stor overraskelse. Vi opdagede, at <em>PoP<\/em> hos Cloudflare faktisk findes i Kina, webadressen resolvedes til en anycast IP, men der bruges amerikanske DNS-servere, hvilket tvinger DNS-foresp\u00f8rgsler til at passere gr\u00e6nsen, og derfor fejler de nogle gange.<\/p>\n<p><\/p>\n<p>Ved at pr\u00e6cisere dette sp\u00f8rgsm\u00e5l til CF fandt vi ud af, at <strong>de ikke har deres egne DNS-servere i Kina<\/strong>, og hvorn\u00e5r de f\u00e5r det \u2014 er stadig ukendt.<\/p>\n<p><\/p>\n<p>Derfor besluttede vi kun at teste DNS fra Cloudflare og \u00e6ndrede Cloudflare's driftsmekanisme for vores website til \"<strong>Kun DNS<\/strong>\". Det er en tilstand, hvor Cloudflare ikke proxyer trafikken gennem sig selv, hvilket betyder, at de ikke tilbyder DDoS-beskyttelse, CDN og andre funktioner, og fungerer som en almindelig DNS-server. <\/p>\n<p><\/p>\n<p>Denne ops\u00e6tning er skematisk pr\u00e6senteret i den f\u00f8lgende illustration. Illustrationen tager h\u00f8jde for den nye viden om, at Cloudflare's DNS-servere ligger bag en firewall.<\/p>\n<p><\/p>\n<p>I Catchpoint k\u00f8rte vi enkle GET-tests (ikke browser-baserede), som viste mange fejl. \u00c5rsagen til dem var de samme DNS-fejl.<\/p>\n<p><\/p>\n<p>Vi begyndte at debugge disse fejl med hj\u00e6lp fra <em>dig<\/em> og opdagede, at ved den f\u00f8rste foresp\u00f8rgsel bliver adressen korrekt bestemt, men ved gentagne foresp\u00f8rgsler f\u00e5r vi hver gang <em>SERVFAIL<\/em> og <em>not found<\/em>. Hvordan kan det pludselig ske?<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn har adresse 220.170.186.192\nHost semrushchina.cn ikke fundet: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn har adresse 220.170.186.192\nHost semrushchina.cn ikke fundet: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn har adresse 220.170.186.192\nHost semrushchina.cn ikke fundet: 2(SERVFAIL)\nroot@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn\nsemrushchina.cn har adresse 220.170.186.192\nHost semrushchina.cn ikke fundet: 2(SERVFAIL)<\/code><\/pre>\n<p><\/p>\n<p>Ved direkte foresp\u00f8rgsel til Cloudflare's NS-servere er der ingen s\u00e5danne fejl:<\/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\nBruger dom\u00e6neserver:\nNavn: ray.ns.cloudflare.com.\nAdresse: 173.245.59.138#53\nAlias:\n\nsemrushchina.cn har adresse 220.170.186.192\nsemrushchina.cn har adresse 220.170.186.192\nBruger dom\u00e6neserver:\nNavn: ray.ns.cloudflare.com.\nAdresse: 173.245.59.138#53\nAlias:\n\nsemrushchina.cn har adresse 220.170.186.192\nsemrushchina.cn har adresse 220.170.186.192<\/code><\/pre>\n<p><\/p>\n<p>S\u00e5 problemet ligger hos den \"lokale\" DNS-server eller udbyderens server.<br \/>\nYderligere unders\u00f8gelser viste, at <em>SERVFAIL<\/em> vi f\u00e5r p\u00e5 resolutionen <em>AAAA<\/em>-poster. <\/p>\n<p><\/p>\n<p>Det viste sig, at n\u00e5r der blev foretaget en foresp\u00f8rgsel hos Cloudflare <em>AAAA<\/em>-post, som ikke eksisterer p\u00e5 dom\u00e6net, Cloudflare svarede <em>A<\/em>-post, som er en fejl og ikke overholder RFC. Dette gjorde, at den lokale resolver (<em>x.x.x.x<\/em>) ikke br\u00f8d sig om det og svarede <em>SERVFAIL<\/em>. I loggen nedenfor kan denne adf\u00e6rd tydeligt ses:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x\n\n; &lt;&gt; DiG 9.10.3-P4-Ubuntu &lt;&gt; -t AAAA semrushchina.cn @x.x.x.x\n;; globale indstillinger: +cmd\n;; Fik svar:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: SERVFAIL, id: 55467\n;; flags: qr rd ra; QUERY: 1, SVAR: 0, AUTORITET: 0, YDERLIGERE: 1\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n;; SP\u00d8RGSM\u00c5L SECTION:\n;semrushchina.cn. IN AAAA\n\n;; Sp\u00f8rgetid: 334 msec\n;; SERVER: x.x.x.x#53(x.x.x.x)\n;; HVORN\u00c5R: Tue Aug 14 23:38:50 CST 2018\n;; MSG ST\u00d8RRELSE rcvd: 44\n\nroot@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.\n\n; &lt;&gt; DiG 9.10.3-P4-Ubuntu &lt;&gt; -t AAAA semrushchina.cn @dana.ns.cloudflare.com.\n;; globale indstillinger: +cmd\n;; Fik svar:\n;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 63944\n;; flags: qr aa rd; QUERY: 1, SVAR: 1, AUTORITET: 0, YDERLIGERE: 1\n;; ADVARSEL: rekursion anmodet, men ikke tilg\u00e6ngelig\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 512\n;; SP\u00d8RGSM\u00c5L SECTION:\n;semrushchina.cn. IN AAAA\n\n;; SVAR SECTION:\nsemrushchina.cn. 300 IN A 220.170.186.192\n\n;; Sp\u00f8rgetid: 185 msec\n;; SERVER: 173.245.58.105#53(173.245.58.105)\n;; HVORN\u00c5R: Tue Aug 14 23:43:03 CST 2018\n;; MSG ST\u00d8RRELSE rcvd: 60\n<\/code><\/pre>\n<p><\/p>\n<p>Vi sendte en bug-rapport til Cloudflare, og de rettede det efter noget tid. Det viste sig at v\u00e6re interessant: lige nu er der stadig ikke st\u00f8tte for IPv6 i Kina, s\u00e5 Cloudflare kunne ikke returnere sin IPv6-adresse i svaret p\u00e5 anmodningen <em>AAAA<\/em>-poster. I sidste ende blev det l\u00f8st, s\u00e5 for Kina begyndte Cloudflare at svare <em>NODATA<\/em> p\u00e5 s\u00e5danne anmodninger.<\/p>\n<p><\/p>\n<p>S\u00e5, DNS-fejlene i Catchpoint-testene faldt dramatisk, men ikke helt. Timeouts forsvandt heller ikke:<\/p>\n<p><\/p>\n<p>Og vi begyndte at lede efter en anden l\u00f8sning. <\/p>\n<p><\/p>\n<p>I n\u00e6ste del vil jeg fort\u00e6lle, hvordan vi testede det kinesiske sky <strong>Alibaba Cloud<\/strong>, hvordan vi med lidt &#171;magi&#187; fra Nginx hurtigt kunne skabe PoC (Proof of Concept) l\u00f8sninger, samt hvordan vi udviklede Multi-Cloud l\u00f8sninger, hvoraf en af dem i sidste ende meget kraftigt hjalp med at accelerere tjenesten fra Kina.<\/p>\n<p><\/p>\n<p><strong>Hold dig opdateret!<\/strong><\/p>\n<p><\/p>\n<h3 id=\"sleduyuschie-chasti\">De n\u00e6ste dele<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/semrush\/blog\/458840\/\">Del 2<\/a><\/noindex><\/p>\n<p>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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\udd47Hvordan vi br\u00f8d gennem Den Store Kinesiske Firewall (del 1) | ProHoster","description":"Hej alle! Nikita her \u2014 systemingeni\u00f8r fra SEMrush.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-probivali-velikij-kitajskij-faervol-ch-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/35939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=35939"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/35939\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=35939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=35939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=35939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}