实现目标 Edge DNS 与获取 IP Anycast 地址的历程 - route64.org

大家好，我是无能。

正在努力尝试创建 Edge DNS 和 CDN。

现状

这是一种伪分布式。

将 edge.soulminingrig.com 的 CNAME 注册为 pool.soulminingrig.com 是为了实现某种程度的分散……但目前来看是毫无意义的。

$dig www.soulminingrig.com AAAA +short
edge.soulminingrig.com.
pool.soulminingrig.com.
2400:8500:2002:3317:163:44:113:145
2a11:6c7:f07:156::2

$dig www.soulminingrig.com A +short
edge.soulminingrig.com.
pool.soulminingrig.com.
163.44.113.145
91.98.169.80

不知为何，即便如此，内容还是从最近的服务器分发的

即便如此，在 HTTP 的情况下，多亏了客户端，令人惊叹的是 HTTP 客户端实际上已经能够到达最近的服务器了。我不确定这是否是因为 DNS 服务器进行了巧妙的分流。我不确定这是否归功于使用了 ConoHa DNS，因为没有关于详细规格的信息。

从德国服务器

IPv6:

# curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:36:56.631373 [0-x] == Info: [READ] client_reset, clear readers
01:36:57.350639 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:36:57.350725 [0-0] == Info: IPv6: 2a11:6c7:f07:156::2, 2400:8500:2002:3317:163:44:113:145
01:36:57.350801 [0-0] == Info: IPv4: (none)
01:36:57.350916 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:36:57.350949 [0-0] == Info: [HTTPS-CONNECT] added
01:36:57.350980 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:36:57.351107 [0-0] == Info:   Trying [2a11:6c7:f07:156::2]:443...
01:36:57.351308 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:36:57.351344 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

IPv4:

# curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:38:31.901521 [0-x] == Info: [READ] client_reset, clear readers
01:38:32.847878 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:38:32.847999 [0-0] == Info: IPv6: (none)
01:38:32.848050 [0-0] == Info: IPv4: 91.98.169.80, 163.44.113.145
01:38:32.848139 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:38:32.848251 [0-0] == Info: [HTTPS-CONNECT] added
01:38:32.848315 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:38:32.848440 [0-0] == Info:   Trying 91.98.169.80:443...
01:38:32.848657 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:38:32.848723 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

从家里环境

IPv6:

$curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:39:23.182757 [0-x] * [READ] client_reset, clear readers
01:39:23.227731 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:39:23.227855 [0-0] * IPv6: 2400:8500:2002:3317:163:44:113:145, 2a11:6c7:f07:156::2
01:39:23.227996 [0-0] * IPv4: (none)
01:39:23.228072 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:39:23.228171 [0-0] * [HTTPS-CONNECT] added
01:39:23.228253 [0-0] * [HTTPS-CONNECT] connect, init
01:39:23.228369 [0-0] *   Trying [2400:8500:2002:3317:163:44:113:145]:443...
01:39:23.228605 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:39:23.228711 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

IPv4:

$curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:40:52.285758 [0-x] * [READ] client_reset, clear readers
01:40:52.316059 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:40:52.316177 [0-0] * IPv6: (none)
01:40:52.316239 [0-0] * IPv4: 163.44.113.145, 91.98.169.80
01:40:52.316340 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:40:52.316440 [0-0] * [HTTPS-CONNECT] added
01:40:52.316522 [0-0] * [HTTPS-CONNECT] connect, init
01:40:52.316638 [0-0] *   Trying 163.44.113.145:443...
01:40:52.316822 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:40:52.316929 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

无论尝试多少次，都会到达同一个最近的 IP。真厉害。

我觉得可能是因为 ConoHa DNS 本身如果不采用这种机制就无法运作，所以才设置成从最近的 IP 地址进行分发。

$dig a.conoha-dns.com +short
157.7.32.89
$dig b.conoha-dns.org +short
157.7.33.89

如果设置了 ConoHa 的主 DNS 和辅 DNS 服务器，当 a.conoha-dns.com 宕机时，如果不向 b.conoha-dns.org 发起查询就没有意义了。虽然我之前没注意到这一点，但更准确地说，如果客户端在其中一个 DNS 服务器宕机时不能去向另一个正常的服务器解析，那么主辅设置也就失去了意义。

做得真不错啊……这意味着即使注册了多个 A 记录，在某种意义上也是在发挥作用的。

即便如此，还是想进一步实现分布式

实际上目前这样已经足够了，但如果能进一步分散，就可以实现自建分布式 DNS 或自建分布式 CDN。目前如果两个节点的缓存服务器都宕机了，通信就会中断。

想到大型云服务商投入了压倒性的基础设施环境和资金来构建这种分布式系统，感觉真是厉害得有点过分。

思考简易分布式方案

如果只要不成为单点故障就行，那么通过 IP Anycast 从多个节点发布，也可以发出相同的 IP 地址。但是，其前提是构建了 BGP，这对个人来说有很高的门槛：

获取 ASN
获取构建 BGP 所需的子网值

无论是费用还是手续，感觉个人都很难轻松完成。

换句话说，跳过这些步骤，只要能获得 IP Anycast 地址，那就没问题了。

不过，基本上使用第三方拥有的 IP 地址在礼仪上是不妥的。

route64.org

https://route64.org/en

找到了。

似乎是一个为了普及 IPv6 而运作的非营利组织。

不过，虽然还没完全看透，但免费使用的基本上只有 IPv6 Tunnel，其他功能基本上是通过捐赠获取积分的系统。使用这些积分可以使用 BGP 或全托管的 IP Anycast 服务。

虽说要花钱，但只需几美元就能获得 Anycast 地址，真的很厉害。顺便提一下，似乎有带宽限制，这点需要注意。

毕竟只是隧道，无法真正拥有它。

日语圈子里也没有相关的介绍，挺让人困扰的。

正好我想给 Hetzner 的 IPv4 服务器添加 IPv6，所以尝试了一下。顺便说一下，在 Hetzner 给已有 IPv4 的服务器添加 IPv6 地址每月要额外收 1 美元。心想“IPv6 地址也要收钱吗……”，幸好当时没加。

实际上它是 IPv6 Tunnel，只有这一点需要注意。

意外地好用的一点是，作为响应延迟过高的 VPS 等的中转，在 SSH 客户端和 SSH 服务端之间使用 route64 发放的 IPv6 地址进行中转，会变得相当顺畅。

尝试使用 IPv6 Tunnel

在下方选择 add tunnelbroker

然后选择隧道方式

因为比较方便而且服务器上已经安装了，所以我选择了 WireGuard。

在这里添加想要赋予 IPv6 的服务器的 IPv4 地址。

也就是说，这是 WireGuard 客户端侧的设置。

我这里是 91.98.169.80。

这样就会生成 WireGuard 的配置文件，之后只需执行 wg-quick up conf-file 即可。

是的，可能有人已经注意到了，本博客 AAAA 记录中的第二个 IPv6 地址就是通过这种方式获取的。

Anycast 服务也支持 IPv4

我原以为从服务名称来看只支持 IPv6，没想到 Anycast 地址也支持 IPv4。厉害。

因此，我打算近期尝试获取一个 Anycast 地址。

另外，我还没有放弃获取 IPv4 子网，所以可能需要花点时间研究一下有没有能以尽可能低的成本维持的方法。

现状