🥇我们如何突破中国防火墙（第一部分）| ProHoster

您好！

Nikita 正在联系 - 公司的系统工程师 SEMrush。今天我给大家讲讲我们是如何面对保障semrush.com服务在中国稳定的任务的，以及我们在实施过程中遇到了哪些问题（考虑到我们的数据中心位于美国东海岸）。

这将是一个大故事，分为几篇文章。我将告诉你这一切是如何发生在我们身上的：从来自中国的完全不起作用的服务，到为美国人提供的服务性能指标达到美国版本的水平。我保证这会很有趣而且很有用。那么，我们走吧。

中国互联网的问题

即使是距离网络管理细节最远的人也听说过 中国防火墙。哇，听起来很酷，对吧？但它是什么以及它实际上如何运作是一个相当复杂的问题。您可以在互联网上找到许多专门讨论此问题的文章，但从技术角度来看，没有任何地方描述此防火墙的结构。然而，这并不奇怪。我马上承认，根据一年的工作结果，我无法确切地说出它是如何运作的，但我可以告诉你我的评论和实际结论。我们将从有关此防火墙的谣言开始。

关于这个防火墙有很多谣言。让我们将其中主要和最有趣的内容收集到一个列表中：

谷歌、Facebook、Twitter 和其他类似服务在中国被屏蔽且无法使用。
任何进入中国境外和进入中国的流量都会使用机器学习进行解析和限制（在可疑流量的情况下），这大大减慢了通过边境的流量（流量）。
中国情报机构将破解任何通过其防火墙的加密流量。
VPN隧道、IPSEC隧道不稳定、崩溃、经常被阻塞。
加密越简单，用于验证/加密流量的密码短语越简单，通过中国防火墙的速度就越快。

以下是我们对这些谣言的发现：

谷歌、Facebook、Twitter 和其他类似的服务确实被屏蔽了（你的 KO），但许多技术性的谷歌域名，例如，没有被禁止并且可以工作（同样的 gstatic.com）。结论由此而来：你不应该鲁莽地删除所有似乎被屏蔽的谷歌和其他资源。
任何经过边境的交通都会严重延误时间。看看这两个结果。一个站点，一页，简单的GET 卷曲嗯。第一个测量是在中国本土（美丽的深圳）进行的。第二个是从香港外部衡量的（香港有主权，与世界之间没有防火墙）。城市之间的直线距离约为30-40公里。

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832
time_namelookup:  0.004500
time_connect:  0.169342
time_appconnect:  0.723189
time_pretransfer:  0.723499
time_redirect:  0.000000
time_starttransfer:  1.532912
----------
time_total:  5.443407
----------
size_download:  390968 Bytes
speed_download:  71824.000B/s

nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup:  0.029366
time_connect:  0.030742
time_appconnect:  0.047310
time_pretransfer:  0.047388
time_redirect:  0.000000
time_starttransfer:  0.120793
----------
time_total:  0.124871
----------
size_download:  326755 Bytes
speed_download:  2616740.000B/s

注意 时间连接。一般来说，您会看到结果：防火墙额外增加了 4 秒，这是非常长的。

VPN 和 IPSEC 隧道确实经常失败。我稍后会更详细地讨论这个问题。用户使用的 VPN 服务器会随着时间的推移（通常在开始使用后的一天内）被阻止。
居住在中国的人们认为，流量加密越简单，通过边境的速度就越快，因为很容易理解，这并不违法。同样，“干净”的流量会获得更多的带宽和通行速度，而“脏”的流量则无法理解任何内容，相反，会获得较慢的通行速度。例如我将使用curl来 ifconfig.co 通过 HTTPS 和 HTTP 协议。

curl -o /dev/null -w@curl_time "https://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3
time_namelookup:  0.004305
time_connect:  0.397465
time_appconnect:  5.149305
time_pretransfer:  5.149393
time_redirect:  0.000000
time_starttransfer:  5.568847
----------
time_total:  5.568893
----------
size_download:  13 Bytes
speed_download:  2.000B/s

curl -o /dev/null -w@curl_time "http://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28
time_namelookup:  0.004282
time_connect:  0.212457
time_appconnect:  0.000000
time_pretransfer:  0.212484
time_redirect:  0.000000
time_starttransfer:  0.450565
----------
time_total:  0.450620
----------
size_download:  13 Bytes
speed_download:  28.000B/s

总下载时间为 5 个字节，相差 13 秒。而且，当多次进行这样的测试时，您可以注意到，HTTP 上的 GET 每次基本上都是在相同的时间内完成的，而在 HTTPS 上，站点有时会在 3、5、10 甚至 17 秒内响应。有时会发生 SSL 错误：

Unknown SSL protocol error in connection to ifconfig.co:443.

那么我们有什么：

上面描述了中国防火墙造成的问题。
对外部资源和隧道内部的 ping 操作会定期消失。
两点之间的延迟不断变化，而且通常是不可预测的。当连接不同的城市/地区时，您期望根据地区的地理位置，延迟会更少，但您得到的情况恰恰相反。
互联网和通信渠道或快或慢。对一天中的时间和一周中的某一天有轻微的依赖性，但并非总是如此。
从中国向外界发出的 DNS 请求有时会超出允许的超时时间。

出现的画面简直就是“太棒了”。

正如我已经说过的，数据中心位于美国东部，整个 SEMrush 由数十个互连的产品、后端、前端、数据库组成，所有这些都在 DC 和云中。我们作为一个系统管理员团队，被赋予了不费吹灰之力快速开始在中国工作的任务。

我们必须回答一个重要的问题：是否有可能以很少的花费，在网络/云/服务器层面解决与中国互联网和防火墙相关的所有问题？

我们从接收开始 ICP- 许可证.

ICP许可证

为了能够在中国（中国大陆）托管您的服务并进行测试，您必须首先获得该域名的ICP许可证。

如果您网站的用户流量在中国大陆境内被终止，并且您的域名没有ICP许可证，那么您的流量将在ISP/托管端被阻止。有趣的是，ICP许可证包括特定的提供商，无论是Cloudflare还是阿里云。因此，如果您获得了Cloudflare的ICP许可证并用其托管您的网站，您将无法“无缝”迁移到阿里云。您将需要向此许可证添加另一个托管。

获得该领域的 ICP 许可证后，我们能够提出并实施具体的技术想法和解决方案。

测试解决方案

但在您直接创建暂存选项、转动旋钮、优化网站的性能及其速度之前，您需要选择一个工具来测试它，以便了解我们的哪些操作可以提高网站的性能，或者相反，会降低网站的性能。

我们的测试工具必须满足两个主要要求：

它应该能够从中国进行测试，
它必须有浏览器测试。

所以我们发现捕获点！他们对世界各地的测试地点都有很好的覆盖。在中国，还可以通过该工具在100500个省份进行测试。每个都有几个不同的提供商+做的能力骨干-测试（类似于数据中心中的虚拟机）和 最后一英里-测试（尽可能接近用户条件，又称工作站）。后一种类型的测试更昂贵。

签订年度合同后（不可能少于此合同），我们开始研究该仪器。坦率地说，我们对其功能感到惊喜。你可以运行：

DNS 测试，
Web 测试（浏览器测试、简单的 GET/POST、移动客户端模拟等），
事务检查（例如登录），
API测试，
Ping、traceroute、NTP 等

你无法列出所有内容。最重要的是，每个测试都可以通过添加一堆标头和其他参数来很好地定制。输出是大量信息，完整描述了您的测试。如果我们谈论对我们来说最有趣的事情（浏览器测试），结果包括：

连接、等待、加载、SSL、DNS 时间、
TTFB、TTLB、文档完成、渲染时间、DOM 加载、
响应（接近第一个字节的时间）、网页响应（接近最后一个字节的时间）、
任意百分位数、平均时间、中值时间
等等。

因此，所有这些指标都非常适合查看变化并了解情况是否有所改善。我们主要看了 响应、网页响应、中位数、75 和 95 百分位数.

从一开始就存在一个重要的问题： 你能相信 Catchpoint 吗？？这个工具是否反映了中国不同城市的真实网站加载速度，或者只是某种与真实用户体验无关的真空测试？
这是一个大问题，因为在俄罗斯几乎不可能可靠地了解中国网站的运作方式。通过虚拟机进行袜子代理，最终结果是站点在几分钟内加载，这对于测试来说是根本不可接受的，因此手动测试的唯一选择是curl和带有计时器的从控制台的简单GET 。这很有帮助，因为这个测试很好地反映了网络解决方案的速度，如果还有浏览器测试，那就非常好。

后来我们自己去了中国并确信 您可以相信 Catchpoint；它相当准确地反映了真实的绩效指标。

Cloudflare中国网

由于我们成功地将 Cloudflare 用于主域 semrush.com，我们决定立即尝试他们的功能，称为中国网。此选项仅在单独请求并支付额外费用的情况下针对企业站点启用。它也仅适用于拥有相应 ICP 许可证且将 Cloudflare 列为提供商的站点。启用后，Cloudflare 的“中国 CDN”即可用于该站点 - 来自中国地区的流量到达最近的 PoP（存在点）CF，然后通过其网络或提供商/合作伙伴的网络传送到源站。

该测试台的示意图如下所示。

这对我们来说是一个很好的选择。事实证明，第二个域也将用于 CF，这不会增加公司使用的解决方案的数量，而且实际上也不会使基础设施变得复杂。

我们运行了浏览器测试，结果是这样的：

红色钻石是测试失败。以下文件是 DNS 错误（解决超时）。顶部的失败是超时。

正常运行时间：86.6
中位数：18秒
75 百分位数：29.3 秒
95 百分位数：60 秒

移除负载后的中值 验证码 （谷歌服务在中国被屏蔽）从28秒减少到18秒。但考虑到对 semrush.com（来自美国）的相同测试，10% 的用户（来自美国）在同一页面上（静态 + 动态）的时间不到 95 秒，这些结果仍然很糟糕。

您可以进入每个测试并查看瀑布以及其他更详细的参数。我们开始调查错误的原因，如果超时的话，一切都或多或少清楚了：中国的互联网“进进出出”，因此从国外连接和加载资源的速度不稳定且不均匀，然后DNS错误让我们大吃一惊。我们发现 的PoP Cloudflare实际上位于中国，站点地址解析为一个任播IP，但DNS服务器是美国的，这就是为什么DNS请求被迫跨境，所以有时会失败。

跟CF澄清了这个问题，结果是 他们在中国没有自己的DNS服务器，而何时到来仍是未知数。

因此，我们决定仅测试 Cloudflare DNS，并将我们网站的 Cloudflare 运行机制更改为“仅 DNS” 这是Cloudflare不通过自身代理流量的模式，这意味着它不提供DDoS防护、CDN等功能，并以常规DNS服务器的模式运行。

下图示意性地显示了该支架。该图考虑了 Cloudflare 的 DNS 服务器位于防火墙后面的新知识。

在 Catchpoint，我们运行了简单的 GET 测试（不是浏览器测试），结果显示出很多失败。它们是由相同的 DNS 错误引起的。

我们开始使用以下方法调试这些错误挖并发现在第一次请求时地址被正确确定，并且在重复请求后我们每次都会收到 服务失败 и 未找到。为什么突然发生这种事？

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

直接查询Cloudflare NS服务器没有出现这样的错误：

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192

这意味着问题出在“本地”DNS 服务器或提供商的服务器一侧。
进一步调查发现 服务失败 我们下定决心 AAAA-记录。

事实证明，当向Cloudflare请求时 AAAA- 域中不存在的记录，Cloudflare 响应 А- 错误且不符合 RFC 的条目。为什么本地解析器（xxx）我不喜欢，他回答说 服务失败。此行为在下面的日志中清晰可见：

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE  rcvd: 44

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; ANSWER SECTION:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE  rcvd: 60

我们向 Cloudflare 提交了错误报告，他们在一段时间后修复了该问题。有趣的是：目前中国仍然不支持 IPv6，因此 Cloudflare 无法根据请求在中国发布其 IPv6 地址 AAAA-记录。最终一切都以这样的方式解决，Cloudflare开始为中国负责 没有数据 对于这样的要求。

因此，Catchpoint 测试中的 DNS 错误急剧减少，但并未完全减少。超时仍然在这里：

我们开始寻找另一种解决方案。

下一部分我会告诉你我们是如何测试中国云的 阿里巴巴云，如何借助 Nginx 的一点“魔力”，我们能够快速创建 PoC（概念验证）解决方案，我们如何创建多云解决方案，其中之一最终极大地帮助加快了服务的工作速度来自中国。

敬请关注！

下一部分

Часть2

来源： habr.com

我们如何突破中国防火墙（第 1 部分）

中国互联网的问题

ICP许可证

测试解决方案

Cloudflare中国网

下一部分