我之前写过一篇介绍 Keybase 加密网络服务体验 的文章，里面提到 Keybase 对于用户的公共目录提供了 Keybase.pub 这个静态文件托管网站，方便其它用户访问 Keybase KBFS 里保存的公共文件。

所以之前我都会把我的 MDwiki 知识库 也同步更新到我的 Keybase 下的 wiki 公共目录，这样就可以把我的 nocwat.keybase.pub 作为一个备用的 Wiki 网站，如果我的 VPS 服务器无法访问，也可以通过 Keybase.pub 访问 Wiki 知识库。

然而最近我才后知后觉地发现原来 Keybase 从今年 3 月份开始就已经关闭了 Keybase.pub 静态文件托管服务，理由则是使用这项服务的用户数量太少，因此也就需要考虑新的 Keybase 静态文件托管方案了。

kbpbot

我稍微看了一下 Keybase Book 中关于 Kebyase Sites 的介绍文章，里面关于 Keybase.pub 的介绍还没有更新，不过还好目前 Keybase 提供的 kbpbot 机器人还是可以正常使用的。

kbpbot 机器人原本是为了支持用户使用自定义域名发布网站而开发的，为自定义域名配置正确的 CNAME 和 TXT 记录之后，访问域名时 kbpbot 就可以读取指定的 Keybase 目录中的文件，然后将静态文件内容返回给访问者。

由此也可以看出，kbpbot 也必须有访问对应的 Keybase 目录的权限，自定义域名静态文件托管才能正常工作。得益于 Keybase KBFS 文件系统的设计，公共目录、私有目录、团队目录都可以给 kbpbot 赋予访问权限：

提示

KBFS 文件系统中的所有文件都会自动签名加密，如果需要了解更多关于 KBFS 的使用方式，可以参考 Keybase 官方的 Introducing the Keybase Filesystem 这篇文章。

• 公共目录：

  kbpbot 默认就可以访问用户的所有公共目录，不需要专门配置，例如我的 Wiki 知识库的 KBFS 路径就是：/keybase/public/nocwat/wiki；

• 私有目录：

  用户只需要在私有目录下建立一个自己和 kbpbot 能访问的子目录，这里多个 Keybase 用户名使用逗号隔开即可，例如：/keybase/private/yourname,kbpbot/XXX；

• 团队目录：

  团队目录则更加简单，将 kbpbot 作为读者加入你的团队，然后使用团队目录路径，例如：/keybase/team/yourteam/XXX。

然后是最重要的自定义域名配置，按照 Keybase Sites 文章里介绍的方式添加对应的 DNS 记录即可。例如我的 MDwiki 知识库使用的是 wiki.vp8.win 自定义域名，为 kbpbot 添加如下 DNS 记录：

• CNAME 记录：

  名称为 wiki，记录值为：kbp.keybaseapi.com；

• TXT 记录：

  名称为 _keybase_pages.wiki，记录值为：kbp=/keybase/public/nocwat/wiki。

其中比较关键的就是 TXT 记录了，kbp=XXX 记录值就是用来告诉 kbpbot 机器人，用户访问此域名时需要访问什么 KBFS 目录。如果你用的是私有目录，把 TXT 记录值换成类似于 kbp=/keybase/private/yourname,kbpbot/XXX 就可以了。

域名配置完成生效之后，就可以通过自定义域名访问你的静态站点了。由于 kbpbot 还支持自动申请和更新 Let’s Encrypt HTTPS 证书，用户访问站点时将会自动使用 HTTPS 访问，完全不需要维护 HTTPS 证书之类的，这一点还是非常方便的。

另外 kbpbot 甚至还支持使用 Keybase Git 代码仓库来访问静态文件，只是不支持私有代码仓库（只有自己才能访问私有 Git 仓库），需要使用团队仓库，同样也要将 kbpbot 作为读者加入你的团队。

例如团队名称还是上面的 yourteam，如果建立一个 teamwiki 仓库，就可以使用 keybase://team/yourteam/teamwiki.git 这种地址来 clone 仓库了，然后存放一些静态文件内容并提交。

最后我们把 Git 仓库对应的域名 TXT 记录值修改为：kbp=git@keybase:team/yourteam/teamwiki，用户就可以通过域名 HTTPS 访问静态站点了。

同步 KBFS

我的 Wiki 主站是放在目前博客的 VPS 服务器上运行的，整个 Wiki 知识库目录通过 Resilio Sync 与本地的 Windows / Linux 电脑进行同步，本地使用 Markdown 编辑器修改 Wiki 内容后就可以自动更新到 VPS 服务器上。

Keybase KBFS 对应的 Wiki 目录，我则是直接在 Linux 上使用 rsync 命令将同步过的本地 Wiki 目录更新到 Keybase，好处就是可以基于 rsync 的同步机制自动只更新差异的文件，这里需要先启动 Keybase 应用程序哦：

~# rsync -ruv --exclude=notes.sqlite --exclude=.sync ~/Documents/wiki/ /run/user/$(id -u)/keybase/kbfs/public/nocwat/wiki/

rsync 的 --exclude 参数可以忽略不需要同步的文件，这里我指定 notes.sqlite 忽略 Markdown 编辑器使用的数据库文件，并指定 .sync 忽略 Resilio Sync 使用的内部同步目录。

Linux 系统上 rsync 的目标目录是：/run/user/$(id -u)/keybase/kbfs，与当前本地用户的用户 ID 有关；Windows 系统如果 Keybase 客户端启用了在资源管理器中显示 KBFS 盘符，rsync 的目标目录可能就是这样：K:\（实际的 KBFS 盘符可能并不是 K 盘）。

总结

我的 MDwiki 知识库在 Keybase 上的备用网站 wiki.vp8.win 目前已经正常运行一段时间了，而且 Keybase 的静态文件托管服务在国内访问也很正常，并没有出现被墙之类的问题。

由于 kbpbot 除了 Keybase 公共、私有和团队 KBFS 目录，还支持使用 Git 仓库，我们也可以将类似 Hexo 这种静态博客通过 Keybase Git 来管理，本地修改构建之后提交到仓库更新，这样小伙伴们通过 Keybase 来托管静态博客也还是比较省事的。

虽然 Keybase 被 Zoom 收购之后发展势头不太好，更新节奏也变慢了，但还是希望 kbpbot 的静态文件托管服务能继续维持下去，毕竟 Keybase 提供的各项加密网络服务还是非常出色的，祝大家玩的开心哦。

体验之前需要先了解 Keybase 到底是啥，维基百科上对 Keybase 的定义是基于 PGP 技术的社交网络平台，可以将用户的身份映射到公钥，反之亦然。最常见的用法就是 Keybase 做为公共的 PGP key server。Keybase 可以对用户的 Twitter、GitHub、Reddit 等社交网络账户提供身份验证功能。

做为开源项目，Keybase 提供的服务已经远不止这些了，除了在社交网络身份验证之外增加了域名、网站管理员以及比特币和 Zcash 加密货币地址的验证功能，目前还提供了不少扩展功能：

• 端对端加密聊天通讯；
• 类似 Slack 的加密团队聊天和协作；
• KBFS 加密文件存储服务，支持公共文件和私有文件，公共文件支持静态文件托管服务；
• 集成 Stellar（XLM）钱包（恒星币）功能，支持创建和导入 Stellar 账户，可以通过 Keybase 发送 XLM 给其它用户；
• 加密 Git 代码仓库托管服务，用户可以创建自己的私有仓库。

PGP 加密

还是从最基本的 PGP 加密说起，在 Keybase 官网注册账户并安装客户端之后，用户可以把自己的 PGP 公钥上传到 Keybase。Linux 下我一般使用系统自带的 gpg（GnuPG）来管理密钥，gpg 的知识网上有很多这里就不做详细介绍了，Keybase 做为公共 PGP key server 还是比较好用的。

例如，我的 Keybase 用户名是 nocwat，欢迎大家添加好友，我已经把自己的 PGP 公钥上传到 Keybase 了，如果你需要在 Linux 系统里导入我的公钥就很简单：

~$ curl https://keybase.io/nocwat/pgp_keys.asc | gpg --import

如果你已经安装了 Keybase 客户端，也可以这样导入：

~$ keybase pgp pull nocwat

导入公钥之后，就可以用 gpg 再做加密、解密、签名、验证之类的操作了。

当然 Keybase 客户端也是直接支持 PGP 的这些操作了，例如：

~$ keybase encrypt -i input -o output user

注意

Keybase 可能觉得用户直接使用 PGP 的门槛太高太复杂，又自己搞了一套新的认证机制，可以参考这里：

Keybase’s New Key Model

新的认证机制使用 Keybase 设备密钥（device key）和 paper key（非常重要，可以更方便地认证 Keybase 设备），至于新的密钥系统则是基于 NaCl 新开发出来的 SaltPack，具体可以看看 Keybase Crypto Documents。

对于 Keybase 这套新的认证机制，我不太好评价其优劣点。Keybase 用户的设备列表是所有用户都可见的，例如我的 Keybase devices，这里包含了所有已认证的设备和 paper key。

在 Keybase graph 里甚至还能看到 PGP key、device key、paper key 及其它已认证项目的对应关系图。从 graph 图里就能看到目前我还是最信赖自己的 PGP 密钥的。

提示

Keybase 也提供 PGP 私钥托管保存功能，Keybase 声称 PGP 私钥必须通过用户的 passphrase 才能解密，解密是通过浏览器客户端本地完成，服务器并不会保存 passphrase。这个托管功能并不是强制的，上传与否要看你是否足够信任 Keybase 了。

另外 Keybase 网页版也有一个 PGP Encrypt 页面提供 PGP 加解密等功能：

PGP 私钥托管之后确实会方便不少，如果你的 PGP 私钥跟我一样没有上传到 Keybase 上托管，那这个页面只能使用 Encrypt 加密发送消息和 Verify 功能，Decrypt 和 Sign 功能必须通过 PGP 或 Keybase 客户端来完成。

加密聊天通讯

Keybase 端对端的加密聊天功能需要安装客户端才能使用，与其它聊天软件不同，即使其他人只有 Twitter、GitHub 等社交网络账户还没有注册 Keybase，你也可以通过 Keybase 发送消息给他们（直接指定社交网络账户名，而不需要知道 Keybase 账户名），待他们通过 Keybase 认证这些账户之后就能收到之前的消息。

你甚至可以直接通过 Keybase 发送消息给 PGP 公钥所有者，如果对方的 Keybase 账户添加验证了此 PGP 公钥就能收到消息。

Keybase 聊天的消息目前是基于 device key 和 paper key 进行加密的，而不是 PGP 密钥，Keybase 给出的解释是无需单独管理 PGP 密钥更有利于非技术人员使用。

Keybase 命令行 keybase chat 也可以进行简单的聊天，而且聊天功能还支持 JSON API 接口，可以很方便地实现聊天机器人之类的功能。

另外 Keybase 团队聊天同样也是端对端加密的，具体可以看看 Teams Crypto 的介绍。由于 Keybase 代码是开源的，因此总体看起来 Keybase 似乎是一个比 Telegram 安全性更高的即时通讯软件。

KBFS 文件存储

KBFS（Keybase 文件系统）的介绍可以参考 Introducing the Keybase filesystem，用户存入的所有文件都会自动签名加密。与聊天功能类似，所有 KBFS 数据都是基于 device key 和 paper key 进行加密的，而不是 PGP 密钥，因此 paper key 特别需要注意备份不能丢失。

KBFS 需要安装 Keybase 客户端才可以使用，Linux 下是基于 FUSE 实现的，Windows 则是基于常见的 Dokan 用户态文件系统了：

Keybase 客户端的 Files 里可以直接看到 private、public 和 team 三个顶层目录，分别对应用户私有、用户公共和团队文件：

我的私有文件在 Linux 上的访问路径是类似这样：/keybase/private/nocwat，Windows 上则是：k:\private\nocwat，公共目录则是：/keybase/public/nocwat。

你也可以创建一个只有几个特定用户能访问的私有目录，类似这样：

/keybase/private/nocwat,xxx,yyy

对于公共目录，Keybase 还提供了 Keybase.pub 网站方便其它用户访问使用，例如我的公共目录地址就是：https://keybase.pub/nocwat/。

Keybase.pub 还提供了静态文件托管网站功能，例如你可以直接访问下面的地址查看我放到公共目录的 Wiki 知识库：https://nocwat.keybase.pub/wiki/。其实这个地址就相当于访问我的 /keybase/public/nocwat/wiki 公共目录。

目前 Keybase 给每个用户提供了 250 GB 的 KBFS 存储空间，目前 KBFS 用户量还不是很多可能存在不稳定的问题，最好注意备份数据。

KBFS 文件系统可以直接看到空间使用情况：

Stellar 钱包

Stellar 是基于 Ripple 修改而来的支付网络系统，用户使用 Lumen（XLM）作为基础货币，可以通过 XLM 转账任意一种货币（可以是各国法定货币或者其它加密货币），其交易确认速度也非常快，有关恒星币的详细内容还请自行了解哦。

Stellar Lumens 加密货币（恒星币）的钱包功能同样必须安装客户端才能使用，目前所有 Keybase 用户都可以使用：

Keybase 将聊天功能和钱包功能进行整合，你可以直接通过 Keybase 用户名而不是很长的 Stellar 钱包地址进行转账操作，当然也可以通过 Keybase 客户端转账给其它未使用 Keybase 的 Stellar 钱包地址。

目前 Keybase 正在搞 Stellar 空投活动，一共会发送 20 亿个 Lumens，只要 Keybase 账户的条件合格就可以每个月领到 Lumens，详情请参考 The Big Stellar Space Drop 页面的介绍。

Git 代码仓库

不得不说 Keybase 新推出的 Git 私有仓库托管服务才是我使用的原因，你可以通过 Keybase 客户端建立自己的私有仓库，也可以为团队建立代码仓库。Keybase 为每个用户和团队提供了 100 GB 的仓库存储空间，实际已经足够用了。Git 代码仓库同样是端对端加密的，只有自己或团队的密钥才能解密。

Keybase 的仓库托管服务是基于 Git 的 remote helpers 功能来实现的，因此仓库地址和常见的 GitHub 不太一样。例如下面是我建立的一个名为 ssicd 的私有代码仓库：

使用 Keybase Git 仓库的机器上必须安装 Keybase 客户端（通过 git-remote-keybase 程序来实现），我就可以通过命令行来 clone 仓库：

~$ git clone keybase://private/nocwat/ssicd.git

接下来的使用方法就和其它 Git 仓库没什么区别了，只是 push 等操作时需要使 Keybase 客户端保持运行状态。

另外还有一个小窍门就是 Keybase Git 代码仓库中的文件是可以直接通过 KBFS 进行访问的，这样无需 clone 整个仓库就能下载其中的某个文件，例如上面我的私有仓库目录路径就是：

/keybase/private/nocwat/.kbfs_autogit/ssicd

路径中的 .kbfs_autogit 是表示 Git 仓库的特殊目录名，不过需要注意直接列举 /keybase/private/{user} 并不能看到这个目录，需要在目录路径中特别指定。

你甚至可以通过 KBFS 直接访问仓库的某个分支，路径形式如下：

/keybase/private/nocwat/.kbfs_autogit/ssicd/.kbfs_autogit_branch_develop

路径中的 .kbfs_autogit_branch_ 后面跟 Git 分支名称即可。

你如果想直接访问具体某个 commit 的数据，也可以指定 KBFS 路径：

/keybase/private/nocwat/.kbfs_autogit/ssicd/.kbfs_autogit_commit_XXXXXX

路径中的 .kbfs_autogit_commit_ 后面跟 commit 的完整 hash 值。

总结

Keybase 做为一个开源项目，基于 PGP 技术做了很多身份验证之外的扩展和改进，增加了很多加密相关的服务，例如端对端加密的聊天、协作、存储、钱包、Git 仓库等功能确实降低了用户使用门槛。我这段时间用下来还是比较方便的，不过国内某些网络下 Keybase 可能访问速度很慢或者干脆被墙了。

不过 Keybase 设计了新的认证机制而不是直接使用成熟的 PGP 可能会引起一些争议，另外可能由于集成了太多功能导致 Keybase 客户端稍显臃肿，现在 Windows 客户端安装包体积就已经有 180 多 MB 了。其实我倒希望 Keybase 能发布一个体积更小的纯命令行版本，或者能可选安装图形程序（我可能也只需要图形界面的聊天功能）。

目前 Keybase 我使用最多的场景就是 PGP key server、KBFS 文件存储和私有 Git 代码仓库功能了，由于基本没有添加好友，端对端加密聊天功能基本没有用到。

最后我写这篇文章时 Stellar（XLM）价格为 $0.06（0.000006 BTC）还非常低廉，哈哈，欢迎大家通过 Keybase 用户名 nocwat 或者 Stellar 钱包地址 给我打币。

此时如果在别的 Linux 客户机系统上又是可以正常访问 NFS 共享的，而 NFS 服务器端考虑到有多个客户机正在使用不方便直接重启服务，一般只能等待 NFS 挂载连接恢复正常或者重启客户端系统，这样还是很麻烦的，为此我专门找了个使用 tcpkill 命令重置 NFS 连接的方法分享给大家。

tcpkill 命令属于 Dsniff 嗅探工具包，Dsniff 本身是一个高级的网络嗅探器，Dsniff 可以将制造的数据包注入到网络，一般 Linux 系统中可以找到对应的 dsniff 软件包进行安装，我测试使用的 CentOS 6.1 64 位系统使用的下面的 RPM 安装包：

http://rpm.repo.onapp.com/ramdisk-hv/centos6/dsniff/

tcpkill 的工作原理是利用 libpcap 库监控符合过滤条件的 TCP 连接并等待，当该 TCP 连接上有数据传输时就会被 tcpkill 感知到，不过作为应用程序的 tcpkill 当然不能直接关闭 TCP 连接，此时就会构造一条 RST 报文发回去直接导致 TCP 连接异常关闭（其实 TCP RST 就是 GFW 对敏感网页进行屏蔽的老手段之一哈）。

对于 NFS 共享使用的 TCP 连接而言，通过 tcpkill 发送 RST 报文导致连接异常关闭之后，NFS 客户端就能知道原有的连接不可用，会自动重新开启新的 TCP 连接，这样就能达到我们需要的重置 NFS 连接的效果。

下面具体实验看看，首先在 NFS 服务器上使用 netstat 命令确认所有 TCP 方式挂载的 NFS 连接，这里使用 NFS 服务的 2049 端口进行过滤：

~ # netstat -anp 2>/dev/null | grep 2049
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.1.56:2049       192.168.1.52:953        ESTABLISHED -
tcp        0      0 192.168.1.56:2049       192.168.1.129:824       ESTABLISHED -
udp        0      0 0.0.0.0:2049            0.0.0.0:*                           -

可以看到 NFS 服务器上有 192.168.1.52 和 192.168.1.129 这两个客户端正在连接，看看 tcpkill 命令的用法：

~ # tcpkill [-i interface] [-1...9] expression

tcpkill 的 -i 参数指定绑定哪个网卡，expression 就是 tcpdump 的过滤表达式参数，具体如何使用可以参考 tcpdump 的帮助信息：

http://www.tcpdump.org/tcpdump_man.html

我们就以关闭上面的 192.168.1.52 客户端使用的 NFS 连接为例：

~ # tcpkill -i eth0 host 192.168.1.52 and port 2049
tcpkill: listening on eth0 [host 192.168.1.52 and port 2049]

tcpkill 命令启动之后会一直等待新的数据传输，我们就可以在 NFS 客户端上随便运行 ls 或者 df 等命令查看 NFS 共享文件夹就可以让系统发送新的 NFS 数据（仍然是有问题的 NFS 连接所以可能会卡住），此时服务器端的 tcpkill 命令就有反应了：

~ # tcpkill -i eth0 host 192.168.1.52 and port 2049
tcpkill: listening on eth0 [host 192.168.1.52 and port 2049]
192.168.1.52:953 > 192.168.1.56:2049: R 1715581713:1715581713(0) win 0
192.168.1.52:953 > 192.168.1.56:2049: R 1715581896:1715581896(0) win 0
192.168.1.52:953 > 192.168.1.56:2049: R 1715582262:1715582262(0) win 0
192.168.1.56:2049 > 192.168.1.52:953: R 624540755:624540755(0) win 0
192.168.1.56:2049 > 192.168.1.52:953: R 624540919:624540919(0) win 0
192.168.1.56:2049 > 192.168.1.52:953: R 624541247:624541247(0) win 0
192.168.1.52:953 > 192.168.1.56:2049: R 1715581801:1715581801(0) win 0
192.168.1.52:953 > 192.168.1.56:2049: R 1715581984:1715581984(0) win 0
192.168.1.52:953 > 192.168.1.56:2049: R 1715582350:1715582350(0) win 0

可以看到 tcpkill 已经发送了 RST 包导致 NFS 客户端重新连接，如果客户端的 NFS 共享操作已经恢复正常了，就可以退出 tcpkill 命令了。

从上面的例子我们也会发现 tcpkill 默认是只能“关闭”活跃有数据传输的 TCP 连接的；对于非活跃的连接我们可能需要主动发送 SYN 包，并根据返回的 TCP 序列号构造新的 RST 包再次发送以达到关闭连接的效果，看起来已经有网友实现了一个支持关闭非活跃连接的 tcpkill 程序，有兴趣的朋友也可以关注看看哦。最后祝大家中秋佳节玩的开心 ^_^。

P2P VPN 和我们平常使用的 PPTP、OpenVPN 等 VPN 的不同之处在于其只负责将两个或多个主机通过点对点的方式进行连接，不需要中心服务器支持，多个主机之间通过 STUN 打洞或者 TURN 中继等方式进行连接，比较适合不同网络间的多个主机进行直接连接，不像 PPTP 这种在国内用的最多的就是拿来爬墙的。

目前使用的比较多的包括 n2n、tinc 和本文要介绍的 ZeroTier 等几种免费开源的 P2P VPN 软件。

n2n 由于已经没人继续开发支持了所以不予考虑，我在对比了 tinc 和 ZeroTier 之后发现 ZeroTier 虽然看起来性能比 tinc 略差一点，但其客户端配置步骤非常简单，不需要像 tinc 那样要在多个主机分别手工生成配置文件，而且 ZeroTier 自己也自带了几个不同国家区域的中继服务器方便普通用户使用，另外一点就是本文要介绍的 ZeroTier 支持在 Linux 容器中使用，因此平时我主要使用 ZeroTier，tinc 用作辅助。

ZeroTier 的虚拟网络可以包含多个处于相同或不同物理网络里的主机，每个虚拟网络都有一个唯一的网络 ID，多个运行 ZeroTier 服务的主机加入同一个 ZeroTier 网络 ID 就可以构成一个虚拟网络。虚拟网络都是由 ZeroTier Controller 控制器来管理的，默认可以使用 ZeroTier 提供的控制器来管理，用户也可以自行搭建控制器来实现完全自己管理 ZeroTier 网络。

另外 ZeroTier 有一个特殊的 8056c2e21c000001 网络 ID 表示全球公共 ZeroTier 网络，如果只是想测试连接网络的话也可以加入这个公共网络；但实际使用中为了安全性考虑建议最好在 ZeroTier 网站上注册一个账户并新建你自己的 P2P VPN 网络用于管理。

有关 ZeroTier P2P VPN 的详细介绍可以参考其官网：

https://www.zerotier.com/

容器中使用 ZeroTier 的问题

简单了解 ZeroTier P2P VPN 主机端的工作机制之后我就发现一个问题，其依赖的 TUN/TAP 驱动（n2n 和 tinc VPN 也同样依赖）在很多 Linux 容器系统中是无法使用的。

我使用的 OpenVZ VPS 容器还好还可以在控制面板里开启 TUN/TAP 支持，而对于现在非常流行的 Docker 容器（例如之前我用到的 IBM Bluemix 容器）就比较麻烦了，Docker 容器在运行时必须包含 SYS_NET_ADMIN 特权才能正常执行 TUN/TAP 虚拟网卡设备的创建操作（Docker 容器中同样也不能使用 OpenVPN、OpenConnect 等依赖 TUN/TAP 驱动的程序），但目前的容器服务厂商基本上不会以特权方式运行容器。

ZeroTier 为此提出的解决方案就是 Network Containers 模式，通过实现一个轻量级的应用层 TCP/IP API 来 hook 现有应用程序的 Socket API，这样可以使现有的程序也能使用 ZeroTier 技术连接其它主机。

最近 ZeroTier 已经将 Network Containers 模式更名为 ZeroTier SDK 并使用了单独的版本库，开发者也可以选择将 ZeroTier SDK 直接编译进自己的应用程序以方便直接使用。有关容器模式的详细介绍可以参考官方介绍文章：ZeroTier Network Containers。

关于 Codeanywhere 容器

这里我使用 Codeanywhere 虚拟机来测试 ZeroTier Network Containers，Codeanywhere 作为一个云端 IDE 平台还是比较好用的，其提供的免费版本的容器支持：

• 2GB 磁盘空间；
• 256MB RAM (+ 512 MB 交换空间)；
• sudo 支持；
• 支持 SSH 登录（免费版本的容器每次启动时 SSH 端口不固定）；
• 支持访问所有 HTTP 和 Websocket 端口（默认 1024 - 9999）。

问题是 Codeanywhere 免费版本的虚拟机不支持固定 IP 地址，也不支持域名绑定或者固定子域名，每次虚拟机启动之后分配到的都是一个超长的子域名，例如你看到的子域名可能就是下面的形式：

preview.7reszf59tfv18aor9x7odheaio340a4ih8tcn8fvndzvkj4i.box.codeanywhere.com

这样实际开发测试起来还是有点不太方便。

当然 Codeanywhere 也是不提供 TUN/TAP 支持的，这样如果 ZeroTier 的容器模式可以在 Codeanywhere 虚拟机内正常使用，我就可以直接在自己的电脑上直接使用虚拟的 P2P VPN 节点 IP 地址来访问 Codeanywhere 虚拟机了，可以省掉那一长串恶心的子域名了。

使用 ZeroTier Network Containers

编译安装 ZeroTier Network Containers

首先创建一个新的 Codeanywhere 虚拟机，建议使用 C/C++ Development Stack 类型方便后续编译安装 ZeroTier 程序，另外操作系统最好选择 Centos 6.5 64 位，如果使用 Ubuntu 系统可能存在连接不上 P2P VPN 网络的问题。

在 Codeanywhere 虚拟机中使用 git 命令检出 ZeroTier 官方版本库，检出之后运行 make netcon 命令就可以编译出 ZeroTier Network Containers 模式需要的文件了：

[cabox@box-codeanywhere ZeroTierOne]$ ls                                           
AUTHORS.md   examples                 netcon        ui
LICENSE.txt  ext                      node          version.h
Makefile     include                  objects.mk    windows
README.md    java                     one.cpp       world
artwork      libzerotierintercept.so  osdep         zerotier-cli
attic        make-freebsd.mk          selftest.cpp  zerotier-idtool
cluster-geo  make-linux.mk            service       zerotier-netcon-service
controller   make-mac.mk              tcp-proxy

其中最重要的就是 zerotier-netcon-service 服务和 libzerotierintercept.so 以及 netcon 目录中的 liblwip.so 应用层 Socket API 库文件了，接着可以先将 ZeroTier Network Container 模式程序和有关库文件安装到 /var/lib/zerotier-one 目录中：

[cabox@box-codeanywhere ZeroTierOne]$ mkdir -m /var/lib/zerotier-one
[cabox@box-codeanywhere ZeroTierOne]$ cp -ra zerotier-* /var/lib/zerotier-one
[cabox@box-codeanywhere ZeroTierOne]$ cp libzerotierintercept.so netcon/liblwip.so /var/lib/zerotier-one

将容器主机加入 ZeroTier 虚拟网络

下面就可以在 Codeanywhere 虚拟机中进行测试了，首先启动 Network Container 模式下的 ZeroTier 主服务程序：

[cabox@box-codeanywhere workspace]$ /var/lib/zerotier-one/zerotier-netcon-service -d

服务启动成功之后稍等片刻，运行 zerotier-cli 命令加入现有的 ZeroTier 虚拟网络，下面命令行中的 565799d8f61077e9 就是我在 ZeroTier 网站上新创建的虚拟网络 ID：

[cabox@box-codeanywhere workspace]$ /var/lib/zerotier-one/zerotier-cli join 565799d8f61077e9

提示

如果你加入的是 8056c2e21c000001 这个全球公共 ZeroTier 虚拟网络那就可以省掉下面这一段落的配置步骤了。

join 操作完成之后需要在 ZeroTier 网站后台虚拟网络管理界面中先允许新的主机加入此网络，接着可以为此主机配置虚拟网络上的 IP 地址、子网掩码之类的，具体配置操作步骤还算比较简单基本都可以在 ZeroTier Central 网站后台中完成。

配置完成之后就可以在容器中继续运行 zerotier-cli 命令查询该主机上 ZeroTier 虚拟网络状态：

[cabox@box-codeanywhere workspace]$ /var/lib/zerotier-one/zerotier-cli listnetworks
200 listnetworks <nwid> <name> <mac> <status> <type> <dev> <ZT assigned ips>
200 listnetworks 565799d8f61077e9 zohead-network fa:d9:cf:a8:b2:40 OK PRIVATE /var/lib/zerotier-one/nc_565799d8f61077e9 10.10.8.4/24

可以看到该容器中已经正确连接到我建立的私有 ZeroTier 虚拟网络了，而且分配到了一个 10.10.8.4 的 IP 地址，子网掩码为 255.255.255.0（对应 24）。

通过虚拟网络访问容器主机

此时需要特别注意的是容器中运行的程序还不能直接使用 ZeroTier 虚拟网络与其它主机进行连接，必须通过预加载 Network Container 库文件的方式运行程序才可以在容器系统中正确访问 ZeroTier 虚拟网络，这里我们以 SSH 服务器为例，首先可以新运行一个 sshd 服务程序：

[cabox@box-codeanywhere workspace]$ sudo ZT_NC_NETWORK=/var/lib/zerotier-one/nc_565799d8f61077e9 LD_PRELOAD=/var/lib/zerotier-one/libzerotierintercept.so /usr/sbin/sshd -p 27001

这样可以新运行一个 sshd 服务程序，并绑定新的端口（例如上面例子中的 27001 端口）防止和系统默认的 22 端口冲突，ZT_NC_NETWORK 变量指定需要使用的 ZeroTier 虚拟网络路径（默认为：/var/lib/zerotier-one/nc_网络ID），LD_PRELOAD 是必须指定的，否则新运行的 sshd 程序将无法访问 ZeroTier 虚拟网络。

新的 sshd 服务启动成功之后，我们就可以在测试的 Windows、Linux 等主机上运行 ZeroTier 客户端，加入同样的虚拟网络并配置虚拟网络 IP 地址（例如我的 Windows 机器 ZeroTier 网络 IP 地址是 10.10.8.3）及子网掩码。

最后我们可以在 Windows 主机上 ping 测试 Codeanywhere 容器的虚拟网络 IP 地址了，如果通讯正常的话就可以通过 ssh 客户端工具直接连接登录 Codeanywhere 容器系统了，这样就顺利绕过了 Codeanywhere 的随机子域名限制。

后记

如果需要在 Codeanywhere 容器系统启动时自动连接 ZeroTier 虚拟网络并开启独立的 sshd 服务程序，那可以将类似下面的两句命令加到 /etc/rc.local 文件末尾：

/var/lib/zerotier-one/zerotier-netcon-service -d
echo "ZT_NC_NETWORK=/var/lib/zerotier-one/nc_565799d8f61077e9 LD_PRELOAD=/var/lib/zerotier-one/libzerotierintercept.so /usr/sbin/sshd -p 27001" | at now + 2 minutes

第二句命令表示在 ZeroTier Network Container 服务程序启动两分钟之后再启动单独的 sshd 服务程序，以使 ZeroTier 服务程序在等待的时间内能正确连接虚拟网络。

本文主要介绍 ZeroTier 程序里不太常见的 Network Container 容器模式，这对于越来越多的 Docker 容器系统而言能绕过 TUN/TAP 限制还是有点用处的，如果读者发现了有关 ZeroTier P2P VPN 的更多好玩法，欢迎提出交流哦，祝大家玩的开心～～～。

由于我确定博客 VPS 后台并没有被入侵，因此初步估计是网页被万恶的运营商给劫持了，但又一想我的博客已经启用了全站 HTTPS，按说不会轻易遇到这种问题了。马上看看 Chrome 浏览器上的地址栏标志，果然没有小绿锁了，浏览器控制台里也有 Mixed Content 报错：

可以看到浏览器拒绝加载 HTTP 的 JavaScript 文件，接着看看七牛 HTTPS 地址返回的数据是否正确：

这下立马发现返回的 JavaScript 代码不对了，开头是插入了 HTTP 形式的 JavaScript 文件地址，后面则看起来明显是广告一类的程序代码了。

难道是运营商做了 DNS 劫持导致我使用的七牛 CDN HTTPS 域名 dn-zohead.qbox.me 解析到了不正确的地址？如果是这样按说应该会出现 SSL 证书错误的，而且运营商只是为了插入广告代码而去搞 TLS 中间人攻击之类的感觉也不太合理。

考虑到另一种可能就是七牛 CDN 在从我的博客 VPS 地址回源的时候由于 DNS 污染之类的问题请求到了错误的数据，导致 HTTPS CDN 返回的数据也不对，这样还是登录到七牛后台管理，查看被劫持的 main.js 文件内容是否正确，下载下来对比却发现和我的博客源站内容是一致的，并没有被污染。

多次测试之后我发现如果再刷新页面七牛 HTTPS 劫持的问题可能又没了，而且在新标签页中打开被劫持的 HTTPS JavaScript 路径又能返回正确的数据了，这个时候通过 Chrome 调试工具看到的 HTTP 请求响应结果是这样的：

而被劫持的 HTTP 请求响应结果则是：

可以看到返回的 HTTP 头信息完全不同，而且多次刷新之后发现被劫持的 HTTPS 数据基本都来自 211.142.22.13 这台七牛的 CDN 服务器。查询之后发现这个 IP 地址是山西移动的（刚好我使用的是移动宽带），看起来只要浏览器是从 211.142.22.13 这台 CDN 服务器请求数据很可能得到的是被劫持的 JavaScript 代码，而如果七牛的 qbox.me 域名解析到的是其它 CDN 服务器地址则数据可能是正常的。

为了更好的重现这个问题，我们可以在 Linux 下先修改系统 hosts 文件使七牛的 qbox.me HTTPS 域名使用进行劫持操作的服务器，然后使用 wget 命令伪装 Android 移动设备以 HTTPS 地址从这台服务器请求 JavaScript 数据：

(trusty)zzm@localhost:~$ wget --referer="https://zohead.com/" --user-agent="Mozilla/5.0 (Linux; Android 4.4.2; Nexus 4 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.114 Mobile Safari/537.36" https://dn-zohead.qbox.me/test.js
--2016-05-27 00:30:37--  https://dn-zohead.qbox.me/test.js
Resolving dn-zohead.qbox.me (dn-zohead.qbox.me)... 211.142.22.13
Connecting to dn-zohead.qbox.me (dn-zohead.qbox.me)|211.142.22.13|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2391 (2.3K) 1
Saving to: ‘test.js’

100%[===========================================================================================================>] 2,391       --.-K/s   in 0.002s  

2016-05-27 00:30:38 (1.18 MB/s) - ‘test.js’ saved [2391/2391]

上面使用 wget 的 --user-agent 参数伪装 Android Chrome 浏览器，使用 --referer 参数伪装从我的博客源站发起请求，而 test.js 同样是一个实际不存在的 JavaScript 地址，我们可以看看返回的数据：

(trusty)zzm@localhost:~$ head test.js 
var osrc ="http://dn-zohead.qbox.me/test.js";osrc+=(osrc.indexOf('?')>0?'&':'?')+'_t='+(new Date().getTime());document.write('<script type="text/javascript" src="'+osrc+'"></'+'script>');function withjQuery(callback){if(typeof(jQuery)=="undefined"){var script=document.createElement("script");scrip ......

很明显这下又得到了被篡改的数据，我们可以试试把 HTTPS 地址改成一个实际存在的 JavaScript 文件并多次运行，你会发现会有一定的概率返回被篡改的数据，有的时候也能返回正确的数据。

另外如果你去掉 --user-agent 参数或者 --referer 参数可能也能得到正确的数据或者正确的 404 报错（对于不存在的 JavaScript 地址），因此我想到可能是劫持方为了不让自己这种龌龊的行径被很容易的发现，而对劫持做了一些限制，如果是直接请求地址（不通过源站 referer 请求）或者通过 PC 端浏览器请求地址则基本上都返回正确的数据。

这下我就可以单独确认 211.142.22.13 这个地址到底是不是真正的七牛服务器了，我们可以修改系统 hosts 文件，例如将我的七牛 HTTPS 域名 dn-zohead.qbox.me 直接改为 211.142.22.13 ，然后通过 Chrome 浏览器访问一个七牛服务器上不存在的 JavaScript 地址，确认 HTTPS 证书是否正确。

提示

从上面 wget 命令的测试结果来看，劫持方可能做了 User Agent 和 Referer 的限制，因此直接访问地址可能并不能看到劫持效果。
这就需要将 Chrome 浏览器 User Agent 改为 Android Chrome，另外可以考虑在控制台中输入命令在网页上创建一个链接，并点击链接实现 Referer 跳转的效果，例如：

var aaa = document.createElement('a');
aaa.innerHTML = 'testlink';
aaa.href = 'https://dn-zohead.qbox.me/ccc8.js'; document.body.appendChild(aaa);

先看看进行劫持操作的 211.142.22.13 CDN 服务器的 HTTPS 证书：

看起来 SSL 服务器证书是正确的，而且从截图的内容也可以看到返回的 JavaScript 代码也明显是被篡改过的。

然后再修改 hosts 文件去掉添加的域名地址条目，重新访问同样不存在的 JavaScript 地址，以确认正确的七牛 CDN 服务器的 HTTPS 证书：

可以发现正常的七牛 CDN 服务器对于不存在的文件是可以正确返回 Document not found 错误的，而进行劫持操作的 CDN 服务器则可能会返回篡改过的 JavaScript 代码，而最要命的是这两个服务器的 HTTPS 证书是完全一致的。

而我使用 HTTPS 访问博客时由于 Mixed Content 问题会导致博客页面时有些功能不正常，而且本该被篡改插入的广告反倒没显示出来，用 Android Chrome 浏览器以 HTTP 方式访问博客多次刷新之后可以看到被劫持插入页面的广告，按说也可以根据 CNZZ 统计代码追踪看看，不过这个就没太大兴趣了：

至此七牛 CDN HTTPS 劫持的问题基本可以明确了：

• 重点针对 JavaScript 文件；
• 并不是七牛 CDN 上 DNS 污染而回源数据不正确导致；
• 并不是所有七牛 CDN 地址都会返回篡改的数据；
• 重点针对移动浏览器，移动网络环境下更加明显；
• 对劫持做了一定的限制，防止被轻易发现；
• 进行劫持操作的服务器使用的是正确的七牛 HTTPS 证书。

至于这种恶意 CDN HTTPS 劫持到底是七牛内部人士所为，还是七牛的 HTTPS 证书泄漏被运营商利用，还需要进一步的确认。提交工单之后七牛客服人员的初步解释是：

• qbox.me 域名被大量客户使用比较不稳定，建议迁移到 HTTPS 自定义域名，而 HTTPS 自定义域名是收费的；
• 使用 qnssl.com HTTPS 自定义域名的话则有做回源的验证，并且节点相对较多，应该不会有劫持情况的发生。

然而我查看了七牛 CDN 后台数据之后还是基本可以确认并没有回源数据被污染的情况，因此七牛给的答复并不能让我满意。

由此也可以看出在这片神奇的土地上，我们的网络环境除了要面临 GFW 这个几乎众所周知的阻碍在其它方面又到底是如何的恶劣，网站主们即使是开启了全站 HTTPS 也难以幸免。就算是七牛所有 CDN 服务器数据都是干净的，也不能保证网络运营商不在中间干点 DNS 污染、TLS 攻击之类的坏事。

如果要解决这种问题我初步想到的就是为博客开启 Subresource Integrity（SRI）安全检查功能，虽然目前支持 SRI 功能的浏览器（目前主要是 Chrome 和 Firefox）并不多，但其还是可以帮助 Web 开发者尽量避免各种网站数据可能被第三方篡改的情况。

SRI 的相关介绍可以参考（第二篇中文文章介绍的比较详细）：

• https://www.srihash.org/
• https://imququ.com/post/subresource-integrity.html

由于 SRI 需要对网页中所有请求外部资源的地方进行修改，一个个手工通过 openssl 命令和修改网页来做实在比较麻烦。

对于 WordPress 博客已经有人实现了 SRI 资源管理的插件 Subresource Integrity (SRI) Manager，该插件可以自动为 WordPress 博客中引用的资源添加 SRI SHA-256 校验值，这样可以减少博客被各种 HTTP、HTTPS 中间人劫持攻击的机率。不过目前还是准备先测试看看此插件稳定性如何，后续再考虑为博客整体开启 SRI 功能咯。

最近在使用一个第三方程序的时候发现程序绑定的 UDP 端口和现有 Linux 系统中的程序有冲突，系统自带的程序又不好修改端口，而第三方程序更没有源码或者配置文件来指定端口。

这种情况下想到可以用 libc 的封装库自己实现 bind 之类的函数来修改端口号，而网上也找到了 Daniel Ryde 类似的实现：

http://www.ryde.net/code/bind.c.txt

编译这个 bind 库可以通过环境变量指定绑定的本地 IP 地址，但不支持端口号修改，而且是直接修改程序所有绑定主机地址不好过滤定制。因此，我对这个 bind 的封装库做了以下改进：

• 支持 socket 类型过滤，可以指定是 TCP、UDP socket 等；
• 支持指定是本地监听请求还是连接远程的请求；
• 支持修改本地使用的 IP 地址及端口号；
• 支持通过环境变量过滤掉某些端口

支持上面这些新增的功能之后，我们就可以根据实际情况只修改特定请求的绑定地址或者绑定端口以满足需求。

我修改的 bind 封装库代码如下，也比较简单：

/*
   Copyright (C) 2000  Daniel Ryde

   Modified by Uranus Zhou (2014)

   This library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   This library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.
*/
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <dlfcn.h>
#include <errno.h>
#include <string.h>

int (*real_bind)(int, const struct sockaddr *, socklen_t);
int (*real_connect)(int, const struct sockaddr *, socklen_t);

char *bind_addr_env, *connect_bind_addr_env, *bind_port_env, *bind_type_env, *exclude_ports_env, *connect_port_env, *connect_type_env, *connect_bind_port_env;
unsigned long int bind_addr_saddr;
struct sockaddr_in local_sockaddr_in[] = { 0 };
int bind_port_ns = -1, connect_port_ns = -1;
int bind_type = -1, connect_type = -1;

static int get_sock_type(const char *str)
{
	if (strcasecmp(str, "TCP") == 0)
		return SOCK_STREAM;
	else if (strcasecmp(str, "UDP") == 0)
		return SOCK_DGRAM;
	else if (strcasecmp(str, "RAW") == 0)
		return SOCK_RAW;
	else if (strcasecmp(str, "PACKET") == 0)
		return SOCK_PACKET;
	else
		return -1;
}

void _init (void)
{
	const char *err;

	real_bind = dlsym (RTLD_NEXT, "bind");
	if ((err = dlerror ()) != NULL) {
		fprintf (stderr, "dlsym (bind): %s\n", err);
	}

	real_connect = dlsym (RTLD_NEXT, "connect");
	if ((err = dlerror ()) != NULL) {
		fprintf (stderr, "dlsym (connect): %s\n", err);
	}

	if (bind_addr_env = getenv ("BIND_ADDR"))
		bind_addr_saddr = inet_addr (bind_addr_env);

	if (bind_port_env = getenv ("BIND_PORT"))
		bind_port_ns = htons (atoi(bind_port_env));

	if (bind_type_env = getenv ("BIND_TYPE"))
		bind_type = get_sock_type(bind_type_env);

	exclude_ports_env = getenv ("EXCLUDE_PORTS");

	if (connect_port_env = getenv ("CONNECT_PORT"))
		connect_port_ns = htons (atoi(connect_port_env));

	if (connect_type_env = getenv ("CONNECT_TYPE"))
		connect_type = get_sock_type(connect_type_env);

	if (connect_bind_addr_env = getenv ("CONNECT_BIND_ADDR")) {
		local_sockaddr_in->sin_family = AF_INET;
		local_sockaddr_in->sin_addr.s_addr = inet_addr (connect_bind_addr_env);
		local_sockaddr_in->sin_port = htons (0);
	}

	if (connect_bind_port_env = getenv ("CONNECT_BIND_PORT"))
		local_sockaddr_in->sin_port = htons (atoi(connect_bind_port_env));
}

static int check_port(int port)
{
	char *tmp = exclude_ports_env, *str = NULL;
	if (tmp == NULL) return 0;

	while (1) {
		char szPort[50] = {0};
		str = strchr(tmp, ',');
		if (str == NULL)
			strncpy(szPort, tmp, sizeof(szPort));
		else
			strncpy(szPort, tmp, str - tmp);
		if (atoi(szPort) == port) return 1;
		if (str == NULL) break;
		tmp = str + 1;
	}

	return 0;
}

int bind (int fd, const struct sockaddr *sk, socklen_t sl)
{
	static struct sockaddr_in *lsk_in;

	lsk_in = (struct sockaddr_in *)sk;
	if (lsk_in->sin_family == AF_INET || lsk_in->sin_family == AF_INET6) {
		int type, length = sizeof(int);

		getsockopt(fd, SOL_SOCKET, SO_TYPE, &type, &length);

		if (check_port(ntohs(lsk_in->sin_port)) == 0 && (bind_type_env == NULL || bind_type == type)) {
			// change bind address
			if (lsk_in->sin_addr.s_addr == htonl (INADDR_ANY) && bind_addr_env)
				lsk_in->sin_addr.s_addr = bind_addr_saddr;

			// change bind port
			if (bind_port_env)
				lsk_in->sin_port = bind_port_ns;
		}
	}
	return real_bind (fd, sk, sl);
}

int connect (int fd, const struct sockaddr *sk, socklen_t sl)
{
	static struct sockaddr_in *rsk_in;

	rsk_in = (struct sockaddr_in *)sk;
	if (rsk_in->sin_family == AF_INET || rsk_in->sin_family == AF_INET6) {
		int type, length = sizeof(int);

		getsockopt(fd, SOL_SOCKET, SO_TYPE, &type, &length);

		if ((connect_port_env == NULL || connect_port_ns == rsk_in->sin_port) && (connect_type_env == NULL || connect_type == type)) {
			// change connect bind address or bind port
			if (connect_bind_addr_env)
				real_bind (fd, (struct sockaddr *)local_sockaddr_in, sizeof (struct sockaddr));
		}
	}
	return real_connect (fd, sk, sl);
}

编译方法：

gcc -nostartfiles -fpic -shared bind.c -o bind.so -ldl -D_GNU_SOURCE

运行指定程序时需要通过 LD_PRELOAD 预先加载 bind.so 库，并通过环境变量指定如何过滤修改网络参数：

• BIND_ADDR 指定本地监听的 IP 地址；
• BIND_PORT 指定本地监听的端口；
• BIND_TYPE 指定本地监听的 socket 类型（TCP、UDP、RAW、PACKET）；
• CONNECT_PORT 指定连接远程主机的端口；
• CONNECT_TYPE 指定远程主机 socket 连接类型（与 BIND_TYPE 类似）；
• CONNECT_BIND_ADDR 指定连接远程主机时本地使用的 IP 地址；
• CONNECT_BIND_PORT 指定连接远程主机时本地使用的端口；
• EXCLUDE_PORTS 需要排除的端口列表（以逗号隔开）

这里举个例子说明如何使用 bind.so：

假设第三方程序为 testapp，testapp 启动时会本地监听 UDP 775 端口，另外还会在本地 eth0 网卡上监听一个随机的 UDP 端口。现在我们需要将后面这个随机的 UDP 端口固定为 666，而且需要指定使用 eth2 网卡，就可以这样运行 testapp 程序：

BIND_ADDR="eth2-ip" BIND_PORT=666 BIND_TYPE=UDP EXCLUDE_PORTS=775 LD_PRELOAD=bind.so testapp

上面的命令中指定了本地 IP 地址（eth2-ip）、绑定端口（666）、socket 类型（UDP），并且使用 EXCLUDE_PORTS 环境变量过滤了固定监听的 775 端口，这样 testapp 程序运行使用的随机 UDP 端口就固定在 666 上了。

我修改的 bind.c 源代码可以从我的 Gist 下载：

https://gist.github.com/zohead/9950663ca01952c940eb

实际使用如果有任何问题欢迎提出指正哦，玩的开心 ^_^