wireguard on 云原生实验室 - Kubernetes|Docker|Istio|Envoy|Hugo|Golang|云原生

WireGuard 教程：WireGuard 的搭建使用与配置详解

yangchuansheng33@gmail.com (米开朗基杨) — Mon, 06 Jul 2020 15:53:49 +0800

上篇文章介绍了 WireGuard 相对于其他 VPN 协议的优点和 WireGuard 的工作原理，本文将会学习如何从零开始配置 WireGuard，这里会涉及到很多高级的配置方法，例如动态 IP、NAT 到 NAT、IPv6 等等。

1. 快速开始

配置 WireGuard 的大致流程如下：

安装

$ yum install epel-release https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
$ yum install yum-plugin-elrepo
$ yum install kmod-wireguard wireguard-tools

# 如果你使用的是非标准内核，需要安装 DKMS 包
$ yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
$ curl -o /etc/yum.repos.d/jdoss-wireguard-epel-7.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo
$ yum install wireguard-dkms wireguard-tools

# Ubuntu ≥ 18.04
$ apt install wireguard

# Ubuntu ≤ 16.04
$ add-apt-repository ppa:wireguard/wireguard
$ apt-get update
$ apt-get install wireguard

$ brew install wireguard-tools

下载地址：

https://download.wireguard.com/windows-client/wireguard-amd64-0.1.1.msi

Android 和 iOS 可通过应用商店下载相关客户端
其他操作系统请参考官方文档：https://www.wireguard.com/install/#installation

在中继服务器上开启 IP 地址转发：

$ echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
$ echo "net.ipv4.conf.all.proxy_arp = 1" >> /etc/sysctl.conf
$ sysctl -p /etc/sysctl.conf

添加 iptables 规则，允许本机的 NAT 转换：

$ iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$ iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$ iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
$ iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE

需要把 eth0 改成你实际使用的网卡接口名称。

编写配置文件

配置文件可以放在任何路径下，但必须通过绝对路径引用。默认路径是 /etc/wireguard/wg0.conf。

配置文件内容解析放到下一章节再讲。

生成密钥

#生成私钥
$ wg genkey > example.key

# 生成公钥
$ wg pubkey < example.key > example.key.pub

启动与停止

$ wg-quick up /full/path/to/wg0.conf
$ wg-quick down /full/path/to/wg0.conf

# 启动/停止 VPN 网络接口
$ ip link set wg0 up
$ ip link set wg0 down

# 注册/注销 VPN 网络接口
$ ip link add dev wg0 type wireguard
$ ip link delete dev wg0

# 注册/注销 本地 VPN 地址
$ ip address add dev wg0 192.0.2.3/32
$ ip address delete dev wg0 192.0.2.3/32

# 添加/删除 VPN 路由
$ ip route add 192.0.2.3/32 dev wg0
$ ip route delete 192.0.2.3/32 dev wg0

查看信息

接口：

# 查看系统 VPN 接口信息
$ ip link show wg0

# 查看 VPN 接口详细信息
$ wg show all
$ wg show wg0

地址：

# 查看 VPN 接口地址
$ ip address show wg0

路由

# 查看系统路由表
$ ip route show table main
$ ip route show table local

# 获取到特定 IP 的路由
$ ip route get 192.0.2.3

一键安装

一键安装请参考这个项目：WireGuard installer

2. 配置详解

WireGuard 使用 INI 语法作为其配置文件格式。配置文件可以放在任何路径下，但必须通过绝对路径引用。默认路径是 /etc/wireguard/wg0.conf。

配置文件的命名形式必须为 ${WireGuard 接口的名称}.conf。通常情况下 WireGuard 接口名称以 wg 为前缀，并从 0 开始编号，但你也可以使用其他名称，只要符合正则表达式 ^[a-zA-Z0-9_=+.-]{1,15}$ 就行。

你可以选择使用 wg 命令来手动配置 VPN，但一般建议使用 wg-quick，它提供了更强大和用户友好的配置体验，可以通过配置文件来管理配置。

下面是一个配置文件示例：

[Interface]
# Name = node1.example.tld
Address = 192.0.2.3/32
ListenPort = 51820
PrivateKey = localPrivateKeyAbcAbcAbc=
DNS = 1.1.1.1,8.8.8.8
Table = 12345
MTU = 1500
PreUp = /bin/example arg1 arg2 %i
PostUp = /bin/example arg1 arg2 %i
PreDown = /bin/example arg1 arg2 %i
PostDown = /bin/example arg1 arg2 %i

[Peer]
# Name = node2-node.example.tld
AllowedIPs = 192.0.2.1/24
Endpoint = node1.example.tld:51820
PublicKey = remotePublicKeyAbcAbcAbc=
PersistentKeepalive = 25

[Interface]

这一节定义本地 VPN 配置。例如：

本地节点是客户端，只路由自身的流量，只暴露一个 IP。

[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.5/32
PrivateKey = <private key for phone.example-vpn.dev>

本地节点是中继服务器，它可以将流量转发到其他对等节点（peer），并公开整个 VPN 子网的路由。

[Interface]
# Name = public-server1.example-vpn.tld
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = <private key for public-server1.example-vpn.tld>
DNS = 1.1.1.1

① # Name

这是 INI 语法中的标准注释，用于展示该配置部分属于哪个节点。这部分配置会被 WireGuard 完全忽略，对 VPN 的行为没有任何影响。

② Address

定义本地节点应该对哪个地址范围进行路由。如果是常规的客户端，则将其设置为节点本身的单个 IP（使用 CIDR 指定，例如 192.0.2.3/32）；如果是中继服务器，则将其设置为可路由的子网范围。

例如：

常规客户端，只路由自身的流量：Address = 192.0.2.3/32
中继服务器，可以将流量转发到其他对等节点（peer）：Address = 192.0.2.1/24
也可以指定多个子网或 IPv6 子网：Address = 192.0.2.1/24,2001:DB8::/64

③ ListenPort

当本地节点是中继服务器时，需要通过该参数指定端口来监听传入 VPN 连接，默认端口号是 51820。常规客户端不需要此选项。

④ PrivateKey

本地节点的私钥，所有节点（包括中继服务器）都必须设置。不可与其他服务器共用。

私钥可通过命令 wg genkey > example.key 来生成。

⑤ DNS

通过 DHCP 向客户端宣告 DNS 服务器。客户端将会使用这里指定的 DNS 服务器来处理 VPN 子网中的 DNS 请求，但也可以在系统中覆盖此选项。例如：

如果不配置则使用系统默认 DNS
可以指定单个 DNS：DNS = 1.1.1.1
也可以指定多个 DNS：DNS = 1.1.1.1,8.8.8.8

⑥ Table

定义 VPN 子网使用的路由表，默认不需要设置。该参数有两个特殊的值需要注意：

Table = off : 禁止创建路由
Table = auto（默认值） : 将路由添加到系统默认的 table 中，并启用对默认路由的特殊处理。

例如：Table = 1234

⑦ MTU

定义连接到对等节点（peer）的 MTU（Maximum Transmission Unit，最大传输单元），默认不需要设置，一般由系统自动确定。

⑧ PreUp

启动 VPN 接口之前运行的命令。这个选项可以指定多次，按顺序执行。

例如：

添加路由：PreUp = ip rule add ipproto tcp dport 22 table 1234

⑨ PostUp

启动 VPN 接口之后运行的命令。这个选项可以指定多次，按顺序执行。

例如：

从文件或某个命令的输出中读取配置值：

PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)

添加一行日志到文件中：

PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log

调用 WebHook：

PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg

添加路由：

PostUp = ip rule add ipproto tcp dport 22 table 1234

添加 iptables 规则，启用数据包转发：

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

强制 WireGuard 重新解析对端域名的 IP 地址：

PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes

⑩ PreDown

停止 VPN 接口之前运行的命令。这个选项可以指定多次，按顺序执行。

例如：

添加一行日志到文件中：

PreDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log

调用 WebHook：

PreDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg

⑪ PostDown

停止 VPN 接口之后运行的命令。这个选项可以指定多次，按顺序执行。

例如：

添加一行日志到文件中：

PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log

调用 WebHook：

PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg

删除 iptables 规则，关闭数据包转发：

PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]

定义能够为一个或多个地址路由流量的对等节点（peer）的 VPN 设置。对等节点（peer）可以是将流量转发到其他对等节点（peer）的中继服务器，也可以是通过公网或内网直连的客户端。

中继服务器必须将所有的客户端定义为对等节点（peer），除了中继服务器之外，其他客户端都不能将位于 NAT 后面的节点定义为对等节点（peer），因为路由不可达。对于那些只为自己路由流量的客户端，只需将中继服务器作为对等节点（peer），以及其他需要直接访问的节点。

举个例子，在下面的配置中，public-server1 作为中继服务器，其他的客户端有的是直连，有的位于 NAT 后面：

public-server1（中继服务器）

[peer] : public-server2, home-server, laptop, phone
public-server2（直连客户端）

[peer] : public-server1
home-server（客户端位于 NAT 后面）

[peer] : public-server1, public-server2
laptop（客户端位于 NAT 后面）

[peer] : public-server1, public-server2
phone（客户端位于 NAT 后面）

[peer] : public-server1, public-server2

配置示例：

对等节点（peer）是路由可达的客户端，只为自己路由流量

[Peer]
# Name = public-server2.example-vpn.dev
Endpoint = public-server2.example-vpn.dev:51820
PublicKey = <public key for public-server2.example-vpn.dev>
AllowedIPs = 192.0.2.2/32

对等节点（peer）是位于 NAT 后面的客户端，只为自己路由流量

[Peer]
# Name = home-server.example-vpn.dev
Endpoint = home-server.example-vpn.dev:51820
PublicKey = <public key for home-server.example-vpn.dev>
AllowedIPs = 192.0.2.3/32

对等节点（peer）是中继服务器，用来将流量转发到其他对等节点（peer）

[Peer]
# Name = public-server1.example-vpn.tld
Endpoint = public-server1.example-vpn.tld:51820
PublicKey = <public key for public-server1.example-vpn.tld>
# 路由整个 VPN 子网的流量
AllowedIPs = 192.0.2.1/24
PersistentKeepalive = 25

① Endpoint

指定远端对等节点（peer）的公网地址。如果对等节点（peer）位于 NAT 后面或者没有稳定的公网访问地址，就忽略这个字段。通常只需要指定中继服务器的 Endpoint，当然有稳定公网 IP 的节点也可以指定。例如：

通过 IP 指定：
```
Endpoint = 123.124.125.126:51820
```

通过域名指定：

Endpoint = public-server1.example-vpn.tld:51820

② AllowedIPs

允许该对等节点（peer）发送过来的 VPN 流量中的源地址范围。同时这个字段也会作为本机路由表中 wg0 绑定的 IP 地址范围。如果对等节点（peer）是常规的客户端，则将其设置为节点本身的单个 IP；如果对等节点（peer）是中继服务器，则将其设置为可路由的子网范围。可以使用 , 来指定多个 IP 或子网范围。该字段也可以指定多次。

当决定如何对一个数据包进行路由时，系统首先会选择最具体的路由，如果不匹配再选择更宽泛的路由。例如，对于一个发往 192.0.2.3 的数据包，系统首先会寻找地址为 192.0.2.3/32 的对等节点（peer），如果没有再寻找地址为 192.0.2.1/24 的对等节点（peer），以此类推。

例如：

对等节点（peer）是常规客户端，只路由自身的流量：
```
AllowedIPs = 192.0.2.3/32
```
对等节点（peer）是中继服务器，可以将流量转发到其他对等节点（peer）：
```
AllowedIPs = 192.0.2.1/24
```
对等节点（peer）是中继服务器，可以转发所有的流量，包括外网流量和 VPN 流量，可以用来干嘛你懂得：
```
AllowedIPs = 0.0.0.0/0,::/0
```
对等节点（peer）是中继服务器，可以路由其自身和其他对等节点（peer）的流量：
```
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
```
对等节点（peer）是中继服务器，可以路由其自身的流量和它所在的内网的流量：
```
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
```

③ PublicKey

对等节点（peer）的公钥，所有节点（包括中继服务器）都必须设置。可与其他对等节点（peer）共用同一个公钥。

公钥可通过命令 wg pubkey < example.key > example.key.pub 来生成，其中 example.key 是上面生成的私钥。

例如：PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=

④ PersistentKeepalive

如果连接是从一个位于 NAT 后面的对等节点（peer）到一个公网可达的对等节点（peer），那么 NAT 后面的对等节点（peer）必须定期发送一个出站 ping 包来检查连通性，如果 IP 有变化，就会自动更新Endpoint。

例如：

本地节点与对等节点（peer）可直连：该字段不需要指定，因为不需要连接检查。
对等节点（peer）位于 NAT 后面：该字段不需要指定，因为维持连接是客户端（连接的发起方）的责任。
本地节点位于 NAT 后面，对等节点（peer）公网可达：需要指定该字段 PersistentKeepalive = 25，表示每隔 25 秒发送一次 ping 来检查连接。

3. 高级特性

IPv6

前面的例子主要使用 IPv4，WireGuard 也支持 IPv6。例如：

[Interface]
AllowedIps = 192.0.2.3/24, 2001:DB8::/64

[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0

转发所有流量

如果你想通过 VPN 转发所有的流量，包括 VPN 子网和公网流量，需要在 [Peer] 的 AllowedIPs 中添加 0.0.0.0/0, ::/0。

即便只转发 IPv4 流量，也要指定一个 IPv6 网段，以避免将 IPv6 数据包泄露到 VPN 之外。详情参考：reddit.com/r/WireGuard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to

例如：

[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.3/32
PrivateKey = <private key for phone.example-vpn.dev>

[Peer]
# Name = public-server1.example-vpn.dev
PublicKey = <public key for public-server1.example-vpn.dev>
Endpoint = public-server1.example-vpn.dev:51820
AllowedIPs = 0.0.0.0/0, ::/0

一般只有把 VPN 当做武当纵云梯来用时，才会需要转发所有流量，不多说，点到为止。

NAT-to-NAT 连接

如果两个对等节点（peer）都位于 NAT 后面，想不通过中继服务器直接连接，需要保证至少有一个对等节点（peer）具有稳定的公网出口，使用静态公网 IP 或者通过 DDNS 动态更新 FQDN 都可以。

WebRTC 协议可以动态配置两个 NAT 之间的连接，它可以通过信令服务器来检测每个主机的 IP:Port 组合。而 WireGuard 没有这个功能，它没有没有信令服务器来动态搜索其他主机，只能硬编码 Endpoint+ListenPort，并通过 PersistentKeepalive 来维持连接。

总结一下 NAT-to-NAT 连接的前提条件：

至少有一个对等节点（peer）有固定的公网 IP，如果都没有固定的公网 IP，也可以使用 DDNS 来维护一个稳定的域名。
至少有一个对等节点（peer）指定 UDP ListenPort，而且它的 NAT 路由器不能做 UDP 源端口随机化，否则返回的数据包将被发送到之前指定的 ListenPort，并被路由器丢弃，不会发送到新分配的随机端口。
所有的对等节点（peer）必须在 [Peer] 配置中启用其他对等节点（peer）的 PersistentKeepalive，这样就可以维持连接的持久性。

对于通信双方来说，只要服务端所在的 NAT 路由器没有指定到 NAT 后面的对等节点（peer）的转发规则，就需要进行 UDP 打洞。

UDP 打洞的原理：

Peer1 向 Peer2 发送一个 UDP 数据包，不过 Peer2 的 NAT 路由器不知道该将这个包发给谁，直接丢弃了，不过没关系，这一步的目的是让 Peer1 的 NAT 路由器能够接收 UDP 响应并转发到后面的 Peer1。
Peer2 向 Peer1 发送一个 UDP 数据包，由于上一步的作用，Peer1 的 NAT 路由器已经建立临时转发规则，可以接收 UDP 响应，所以可以接收到该数据包，并转发到 Peer1。
Peer1 向 Peer2 发送一个 UDP 响应，由于上一步的作用，由于上一步的作用，Peer2 的 NAT 路由器已经可以接收 UDP 响应，所以可以接收到该数据包，并转发到 Peer2。

这种发送一个初始的数据包被拒绝，然后利用路由器已建立的转发规则来接收响应的过程被称为『UDP 打洞』。

当你发送一个 UDP 数据包出去时，路由器通常会创建一个临时规则来映射源地址/端口和目的地址/端口，反之亦然。从目的地址和端口返回的 UDP 数据包会被转发到原来的源地址和端口，这就是大多数 UDP 应用在 NAT 后面的运作方式（如 BitTorrent、Skype 等）。这个临时规则会在一段时间后失效，所以 NAT 后面的客户端必须通过 PersistentKeepalive 定期发送数据包来维持连接的持久性。

当两个对等节点（peer）都位于 NAT 后面时，要想让 UDP 打洞生效，需要两个节点在差不多的时间向对方发送数据包，这就意味着双方需要提前知道对方的公网地址和端口号，可以在 wg0.conf 中指定。

UDP 打洞的局限性

从 2019 年开始，很多以前用过的老式打洞方法都不再有效了。以前很著名的就是 pwnat 开创的一种新的打洞方法，它能够在不需要代理、第三方服务器、upnp、DMZ、sproofing、dns 转换的情况下实现 NAT 中的 P2P 通信。它的原理也很简单：

通过让客户端假装成为一个互联网上任意的 ICMP 跳跃点（ a random hop on the Internet）来解决这个问题，从而让服务端能够获取到客户端的 IP 地址。traceroute 命令也是使用这项技术来检测 Internet 上的跳跃点。

具体来说，当服务器启动时，它开始向固定地址 3.3.3.3 发送固定的 ICMP 回应请求包（ICMP echo request packets）。显然，我们无法从 3.3.3.3 收到返回的 ICMP 回应数据包（ICMP echo packets）。然而，3.3.3.3 并不是我们可以访问的主机，我们也不是想伪装成它来发 ICMP 回应数据包。相反，pwnat 技术的实现原理在于，当我们的客户端想要连接服务端时，客户端（知道服务器IP地址）会向服务端送 ICMP 超时数据包（ICMP Time Exceeded packet）。这个 ICMP 数据包里面包含了服务端发送到 3.3.3.3 的原始固定 ICMP 回应请求包。

为什么要这样做呢？好吧，我们假装是互联网上的一个 ICMP 跳越点，礼貌地告诉服务器它原来的 ICMP 回应请求包无法传递到 3.3.3.3。而你的 NAT 是一个聪明的设备，它会注意到 ICMP 超时数据包内的数据包与服务器发出 ICMP 回应请求包相匹配。然后它将 ICMP 超时数据包转发回 NAT 后面的服务器，包括来自客户端的完整 IP 数据包头，从而让服务端知道客户端 IP 地址是什么！

现在这种类似的 UDP 打洞方法受到了很多的限制，详情可以参考上篇文章，这里不过多阐述。除了 UDP 打洞之外，我们仍然可以使用硬编码的方式指定两个对等节点（peer）的公网地址和端口号，这个方法对大多数 NAT 网络都有效。

源端口随机化

如果所有的对等节点（peer）都在具有严格的 UDP 源端口随机化的 NAT 后面（比如大多数蜂窝网络），那么无法实现 NAT-to-NAT 连接。因为双方都无法协商出一个 ListenPort，并保证自己的 NAT 在发出 ping 包后能够接收发往该端口的流量，所以就无法初始化打洞，导致连接失败。因此，一般在 LTE/3G 网络中无法进行 p2p 通信。

使用信令服务器

上节提到了，如果所有的对等节点（peer）都在具有严格的 UDP 源端口随机化的 NAT 后面，就无法直接实现 NAT-to-NAT 连接，但通过第三方的信令服务器是可以实现的。信令服务器相当于一个中转站，它会告诉通信双方关于对方的 IP:Port 信息。这里有几个项目可以参考：

动态 IP 地址

WireGuard 只会在启动时解析域名，如果你使用 DDNS 来动态更新域名解析，那么每当 IP 发生变化时，就需要重新启动 WireGuard。目前建议的解决方案是使用 PostUp 钩子每隔几分钟或几小时重新启动 WireGuard 来强制解析域名。

总的来说，NAT-to-NAT 连接极为不稳定，而且还有一堆其他的限制，所以还是建议通过中继服务器来通信。

NAT-to-NAT 配置示例：

Peer1：

[Interface]
...
ListenPort = 12000

[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25

Peer2：

[Interface]
...
ListenPort = 12000

[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25

更多资料：

动态分配子网 IP

这里指的是对等节点（peer）的 VPN 子网 IP 的动态分配，类似于 DHCP，不是指 Endpoint。

WireGuard 官方已经在开发动态分配子网 IP 的功能，具体的实现可以看这里：WireGuard/wg-dynamic

当然，你也可以使用 PostUp 在运行时从文件中读取 IP 值来实现一个动态分配 IP 的系统，类似于 Kubernetes 的 CNI 插件。例如：

[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command)

奇技淫巧

共享一个 peers.conf 文件

介绍一个秘密功能，可以简化 WireGuard 的配置工作。如果某个 peer 的公钥与本地接口的私钥能够配对，那么 WireGuard 会忽略该 peer。利用这个特性，我们可以在所有节点上共用同一个 peer 列表，每个节点只需要单独定义一个 [Interface] 就行了，即使列表中有本节点，也会被忽略。具体方式如下：

每个对等节点（peer）都有一个单独的 /etc/wireguard/wg0.conf 文件，只包含 [Interface] 部分的配置。
每个对等节点（peer）共用同一个 /etc/wireguard/peers.conf 文件，其中包含了所有的 peer。
Wg0.conf 文件中需要配置一个 PostUp 钩子，内容为 PostUp = wg addconf /etc/wireguard/peers.conf。

关于 peers.conf 的共享方式有很多种，你可以通过 ansible 这样的工具来分发，可以使用 Dropbox 之类的网盘来同步，当然也可以使用 ceph 这种分布式文件系统来将其挂载到不同的节点上。

从文件或命令输出中读取配置

WireGuard 也可以从任意命令的输出或文件中读取内容来修改配置的值，利用这个特性可以方便管理密钥，例如可以在运行时从 Kubernetes Secrets 或 AWS KMS 等第三方服务读取密钥。

容器化

WireGuard 也可以跑在容器中，最简单的方式是使用 --privileged 和 --cap-add=all 参数，让容器可以加载内核模块。

你可以让 WireGuard 跑在容器中，向宿主机暴露一个网络接口；也可以让 WireGuard 运行在宿主机中，向特定的容器暴露一个接口。

下面给出一个具体的示例，本示例中的 vpn_test 容器通过 WireGuard 中继服务器来路由所有流量。本示例中给出的容器配置是 docker-compose 的配置文件格式。

中继服务器容器配置：

version: '3'

services:
  wireguard:
    image: linuxserver/wireguard
    ports:
      - 51820:51820/udp
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    volumes:
      - /lib/modules:/lib/modules
      - ./wg0.conf:/config/wg0.conf:ro

中继服务器 WireGuard 配置 wg0.conf：

[Interface]
# Name = relay1.wg.example.com
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = oJpRt2Oq27vIB5/UVb7BRqCwad2YMReQgH5tlxz8YmI=
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0  -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Name = peer1.wg.example.com
PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/2Gg=
AllowedIPs = 192.0.2.2/32

客户端容器配置：

version: '3'

services:
  wireguard:
    image: linuxserver/wireguard
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    volumes:
      - /lib/modules:/lib/modules
      - ./wg0.conf:/config/wg0.conf:ro
    
  vpn_test:
    image: curlimages/curl
    entrypoint: curl -s http://whatismyip.akamai.com/
    network_mode: 'service:wireguard'

客户端 WireGuard 配置 wg0.conf：

[Interface]
# Name = peer1.wg.example.com
Address = 192.0.2.2/32
PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/sgk8=
DNS = 1.1.1.1,8.8.8.8

[Peer]
# Name = relay1.wg.example.com
Endpoint = relay1.wg.example.com:51820
PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+2um0c0B1s=
AllowedIPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21

WireGuard 教程：WireGuard 的工作原理

yangchuansheng33@gmail.com (米开朗基杨) — Wed, 01 Jul 2020 11:18:32 +0800

本文翻译自：https://github.com/pirate/wireguard-docs

WireGuard 是由 Jason Donenfeld 等人用 C 语言编写的一个开源 VPN 协议，被视为下一代 VPN 协议，旨在解决许多困扰 IPSec/IKEv2、OpenVPN 或 L2TP 等其他 VPN 协议的问题。它与 Tinc 和 MeshBird 等现代 VPN 产品有一些相似之处，即加密技术先进、配置简单。从 2020 年 1 月开始，它已经并入了 Linux 内核的 5.6 版本，这意味着大多数 Linux 发行版的用户将拥有一个开箱即用的 WireGuard。

无论你是想破墙而出，还是想在服务器之间组网，WireGuard 都不会让你失望，它就是组网的『乐高积木』，就像 ZFS 是构建文件系统的『乐高积木』一样。

WireGuard 与其他 VPN 协议的性能测试对比：

可以看到 WireGuard 直接碾压其他 VPN 协议。再来说说 OpenVPN，大约有 10 万行代码，而 WireGuard 只有大概 4000 行代码，代码库相当精简，简直就是件艺术品啊。你再看看 OpenVPN 的性能，算了不说了。

WireGuard 优点：

配置精简，可直接使用默认值
只需最少的密钥管理工作，每个主机只需要 1 个公钥和 1 个私钥。
就像普通的以太网接口一样，以 Linux 内核模块的形式运行，资源占用小。
能够将部分流量或所有流量通过 VPN 传送到局域网内的任意主机。
能够在网络故障恢复之后自动重连，戳到了其他 VPN 的痛处。
比目前主流的 VPN 协议，连接速度要更快，延迟更低（见上图）。
使用了更先进的加密技术，具有前向加密和抗降级攻击的能力。
支持任何类型的二层网络通信，例如 ARP、DHCP 和 ICMP，而不仅仅是 TCP/HTTP。
可以运行在主机中为容器之间提供通信，也可以运行在容器中为主机之间提供通信。

WireGuard 不能做的事：

类似 gossip 协议实现网络自愈。
通过信令服务器突破双重 NAT。
通过中央服务器自动分配和撤销密钥。
发送原始的二层以太网帧。

当然，你可以使用 WireGuard 作为底层协议来实现自己想要的功能，从而弥补上述这些缺憾。

本系列 WireGuard 教程分为两个部分，第一部分偏理论，第二部分偏实践。本文是第一部分，下面开始正文教程。

1. WireGuard 术语

Peer/Node/Device

连接到 VPN 并为自己注册一个 VPN 子网地址（如 192.0.2.3）的主机。还可以通过使用逗号分隔的 CIDR 指定子网范围，为其自身地址以外的 IP 地址选择路由。

中继服务器（Bounce Server）

一个公网可达的对等节点，可以将流量中继到 NAT 后面的其他对等节点。Bounce Server 并不是特殊的节点，它和其他对等节点一样，唯一的区别是它有公网 IP，并且开启了内核级别的 IP 转发，可以将 VPN 的流量转发到其他客户端。

子网（Subnet）

一组私有 IP，例如 192.0.2.1-255 或 192.168.1.1/24，一般在 NAT 后面，例如办公室局域网或家庭网络。

CIDR 表示法

这是一种使用掩码表示子网大小的方式，这个不用解释了。

NAT

子网的私有 IP 地址由路由器提供，通过公网无法直接访问私有子网设备，需要通过 NAT 做网络地址转换。路由器会跟踪发出的连接，并将响应转发到正确的内部 IP。

公开端点（Public Endpoint）

节点的公网 IP 地址:端口，例如 123.124.125.126:1234，或者直接使用域名 some.domain.tld:1234。如果对等节点不在同一子网中，那么节点的公开端点必须使用公网 IP 地址。

私钥（Private key）

单个节点的 WireGuard 私钥，生成方法是：wg genkey > example.key。

公钥（Public key）

单个节点的 WireGuard 公钥，生成方式为：wg pubkey < example.key > example.key.pub。

DNS

域名服务器，用于将域名解析为 VPN 客户端的 IP，不让 DNS请求泄漏到 VPN 之外。

2. WireGuard 工作原理

中继服务器工作原理

中继服务器（Bounce Server）和普通的对等节点一样，它能够在 NAT 后面的 VPN 客户端之间充当中继服务器，可以将收到的任何 VPN 子网流量转发到正确的对等节点。事实上 WireGuard 并不关心流量是如何转发的，这个由系统内核和 iptables 规则处理。

如果所有的对等节点都是公网可达的，则不需要考虑中继服务器，只有当有对等节点位于 NAT 后面时才需要考虑。

在 WireGuard 里，客户端和服务端基本是平等的，差别只是谁主动连接谁而已。双方都会监听一个 UDP 端口，谁主动连接，谁就是客户端。主动连接的客户端需要指定对端的公网地址和端口，被动连接的服务端不需要指定其他对等节点的地址和端口。如果客户端和服务端都位于 NAT 后面，需要加一个中继服务器，客户端和服务端都指定中继服务器作为对等节点，它们的通信流量会先进入中继服务器，然后再转发到对端。

WireGuard 是支持漫游的，也就是说，双方不管谁的地址变动了，WireGuard 在看到对方从新地址说话的时候，就会记住它的新地址（跟 mosh 一样，不过是双向的）。所以双方要是一直保持在线，并且通信足够频繁的话（比如配置 persistent-keepalive），两边的 IP 都不固定也不影响的。

Wireguard 如何路由流量

利用 WireGuard 可以组建非常复杂的网络拓扑，这里主要介绍几个典型的拓扑：

① 端到端直接连接

这是最简单的拓扑，所有的节点要么在同一个局域网，要么直接通过公网访问，这样 WireGuard 可以直接连接到对端，不需要中继跳转。

② 一端位于 NAT 后面，另一端直接通过公网暴露

这种情况下，最简单的方案是：通过公网暴露的一端作为服务端，另一端指定服务端的公网地址和端口，然后通过 persistent-keepalive 选项维持长连接，让 NAT 记得对应的映射关系。

③ 两端都位于 NAT 后面，通过中继服务器连接

大多数情况下，当通信双方都在 NAT 后面的时候，NAT 会做源端口随机化处理，直接连接可能比较困难。可以加一个中继服务器，通信双方都将中继服务器作为对端，然后维持长连接，流量就会通过中继服务器进行转发。

④ 两端都位于 NAT 后面，通过 UDP NAT 打洞

上面也提到了，当通信双方都在 NAT 后面的时候，直接连接不太现实，因为大多数 NAT 路由器对源端口的随机化相当严格，不可能提前为双方协调一个固定开放的端口。必须使用一个信令服务器（STUN），它会在中间沟通分配给对方哪些随机源端口。通信双方都会和公共信令服务器进行初始连接，然后它记录下随机的源端口，并将其返回给客户端。这其实就是现代 P2P 网络中 WebRTC 的工作原理。有时候，即使有了信令服务器和两端已知的源端口，也无法直接连接，因为 NAT 路由器严格规定只接受来自原始目的地址（信令服务器）的流量，会要求新开一个随机源端口来接受来自其他 IP 的流量（比如其他客户端试图使用原来的通信源端口）。运营商级别的 NAT 就是这么干的，比如蜂窝网络和一些企业网络，它们专门用这种方法来防止打洞连接。更多细节请参考下一部分的 NAT 到 NAT 连接实践的章节。

如果某一端同时连接了多个对端，当它想访问某个 IP 时，如果有具体的路由可用，则优先使用具体的路由，否则就会将流量转发到中继服务器，然后中继服务器再根据系统路由表进行转发。你可以通过测量 ping 的时间来计算每一跳的长度，并通过检查对端的输出（wg show wg0）来找到 WireGuard 对一个给定地址的路由方式。

WireGuard 报文格式

WireGuard 使用加密的 UDP 报文来封装所有的数据，UDP 不保证数据包一定能送达，也不保证按顺序到达，但隧道内的 TCP 连接可以保证数据有效交付。WireGuard 的报文格式如下图所示：

关于 WireGuard 报文的更多信息可以参考下面几篇文档：

WireGuard 的性能

WireGuard 声称其性能比大多数 VPN 协议更好，但这个事情有很多争议，比如某些加密方式支持硬件层面的加速。

WireGuard 直接在内核层面处理路由，直接使用系统内核的加密模块来加密数据，和 Linux 原本内置的密码子系统共存，原有的子系统能通过 API 使用 WireGuard 的 Zinc 密码库。WireGuard 使用 UDP 协议传输数据，在不使用的情况下默认不会传输任何 UDP 数据包，所以比常规 VPN 省电很多，可以像 55 一样一直挂着使用，速度相比其他 VPN 也是压倒性优势。

关于性能比较的更多信息可以参考下面几篇文档：

WireGuard 安全模型

WireGuard 使用以下加密技术来保障数据的安全：

使用 ChaCha20 进行对称加密，使用 Poly1305 进行数据验证。
利用 Curve25519 进行密钥交换。
使用 BLAKE2 作为哈希函数。
使用 HKDF 进行解密。

WireGuard 的加密技术本质上是 Trevor Perrin 的 Noise 框架的实例化，它简单高效，其他的 VPN 都是通过一系列协商、握手和复杂的状态机来保障安全性。WireGuard 就相当于 VPN 协议中的 qmail，代码量比其他 VPN 协议少了好几个数量级。

关于 WireGuard 加密的更多资料请参考下方链接：

WireGuard 密钥管理

WireGuard 通过为每个对等节点提供简单的公钥和私钥来实现双向认证，每个对等节点在设置阶段生成密钥，且只在对等节点之间共享密钥。每个节点除了公钥和私钥，不再需要其他证书或预共享密钥。

在更大规模的部署中，可以使用 Ansible 或 Kubernetes Secrets 等单独的服务来处理密钥的生成、分发和销毁。

下面是一些有助于密钥分发和部署的服务：

如果你不想在 wg0.conf 配置文件中直接硬编码，可以从文件或命令中读取密钥，这使得通过第三方服务管理密钥变得更加容易：

[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)

从技术上讲，多个服务端之间可以共享相同的私钥，只要客户端不使用相同的密钥同时连接到两个服务器。但有时客户端会需要同时连接多台服务器，例如，你可以使用 DNS 轮询来均衡两台服务器之间的连接，这两台服务器配置相同。大多数情况下，每个对等节点都应该使用独立的的公钥和私钥，这样每个对等节点都不能读取到对方的流量，保障了安全性。

理论部分就到这里，下篇文章将会手把手教你如何从零开始配置 WireGuard，这里会涉及到很多高级的配置方法，例如动态 IP、NAT 到 NAT、IPv6 等等。

跨云厂商部署 k3s 集群

yangchuansheng33@gmail.com (米开朗基杨) — Sun, 14 Jun 2020 13:44:03 +0800

最近一两年各大云服务商都出了各种福利活动，很多小伙伴薅了一波又一波羊毛，比如腾讯云 1C2G 95/年 真香系列，华为云和阿里云也都有类似的活动，薅个两三台就能搭建一个 Kubernetes 集群。但是跨云服务商搭建 Kubernetes 集群并不像我们想象中的那么容易，首先就是原生的 Kubernetes 组件本身对资源的消耗量很大，而云服务器的资源非常有限，经不起这么大家伙的折腾，对此我们可以选择使用轻量级 Kubernetes 发行版：k3s。

k3s 将安装 Kubernetes 所需的一切打包进仅有 60MB 大小的二进制文件中，并且完全实现了 Kubernetes API。为了减少运行 Kubernetes 所需的内存，k3s 删除了很多不必要的驱动程序，并用附加组件对其进行替换。由于它只需要极低的资源就可以运行，因此它能够在任何 512MB 内存以上的设备上运行集群。

其实 k3s 的安装非常简单，分分钟就能搞定，但对于公有云来说，还是有很多坑的，比如内网不通、公网 IP 不在服务器上该咋办？本文就为你一一解决这些难题，让天下的云羊毛都成为 k3s 的后宫！

1. 下载二进制文件

首先来解决第一个难题：k3s 二进制文件的下载。国内下载 GitHub 速度基本都是以几个 kb 为单位，不忍直视，如果下载内容都是代码，有很多办法可以解决，比如通过码云中转啊、直接通过 CDN 下载啊，什么？你不知道可以通过 CDN 下载？好吧没关系，现在我告诉你了：https://cdn.con.sh/。

但是上面的 CDN 并不能下载 release 里的内容，要想下载 release 里的内容，可以使用这个网站：https://toolwa.com/github/。打开网站，输入 release 里面的文件下载链接，点击起飞即可加速下载。

当然，如果你会魔法上网的话，上面的所有花里胡哨的方法都可以无视，直接下载就好啦（本文选择使用版本 v1.17.6+k3s1）：

$ wget https://github.com/rancher/k3s/releases/download/v1.17.6+k3s1/k3s -O /usr/local/bin/k3s
$ chmod +x /usr/local/bin/k3s

需要在所有节点中下载上述二进制文件。

2. 升级内核

k3s 的默认网络插件是 flannel，默认模式是 vxlan 模式，建议使用 wireguard 模式，原因不解释了，不知道 wireguard 是啥的自己去搜一下。

wireguard 对内核的要求比较高，而 CentOS 7.x 的默认内核是不满足要求的，需要升级内核（如果你的操作系统是 CentOS 7.x 的话）。步骤如下：

① 载入公钥

$ rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

② 升级安装 elrepo

$ rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

③ 载入 elrepo-kernel 元数据

$ yum --disablerepo=\* --enablerepo=elrepo-kernel repolist

④ 安装最新版本的内核

$ yum --disablerepo=\* --enablerepo=elrepo-kernel install  kernel-ml.x86_64  -y

⑤ 删除旧版本工具包

$ yum remove kernel-tools-libs.x86_64 kernel-tools.x86_64  -y

⑥ 安装新版本工具包

$ yum --disablerepo=\* --enablerepo=elrepo-kernel install kernel-ml-tools kernel-ml-devel kernel-ml-headers -y

⑦ 查看内核插入顺序

$ grep "^menuentry" /boot/grub2/grub.cfg | cut -d "'" -f2

CentOS Linux (3.10.0-1127.10.1.el7.x86_64) 7 (Core)
CentOS Linux (5.7.2-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (0-rescue-96820b9851c24560b5f942f2496b9aeb) 7 (Core)

默认新内核是从头插入，默认启动顺序也是从 0 开始。

⑧ 查看当前实际启动顺序

$ grub2-editenv list

saved_entry=CentOS Linux (3.10.0-1127.10.1.el7.x86_64) 7 (Core)

⑨ 设置默认启动

$ grub2-set-default 'CentOS Linux (5.7.2-1.el7.elrepo.x86_64) 7 (Core)'

最后重启检查：

$ reboot
$ uname -r

注意：集群中的所有节点都需要升级内核。

3. 安装 wireguard

内核升级了之后，就可以安装 wireguard 了，也很简单，步骤如下：

$ yum install epel-release https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
$ yum install yum-plugin-elrepo
$ yum install kmod-wireguard wireguard-tools

注意：集群中的所有节点都需要安装。

4. 部署控制平面

下面就可以在控制节点上启动控制平面的组件了，这里我们选择手动部署，这样比较方便修改参数。先创建一个 Service Unit 文件：

$ cat > /etc/systemd/system/k3s.service <<EOF
[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=notify
EnvironmentFile=/etc/systemd/system/k3s.service.env
KillMode=process
Delegate=yes
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
TimeoutStartSec=0
Restart=always
RestartSec=5s
ExecStartPre=-/sbin/modprobe br_netfilter
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/k3s \
    server \
    --tls-san <public_ip> \
    --node-ip <public_ip> \
    --node-external-ip <public_ip> \
    --no-deploy servicelb \
    --flannel-backend wireguard \
    --kube-proxy-arg "proxy-mode=ipvs" "masquerade-all=true" \
    --kube-proxy-arg "metrics-bind-address=0.0.0.0"
EOF

将 <public_ip> 替换成控制节点的公网 IP。
flannel 使用 wireguard 协议来跨主机通信。
kube-proxy 使用 ipvs 模式。

启动 k3s 控制平面并设置开机自启：

$ systemctl enable k3s --now

查看集群组件健康状况：

$ kubectl get cs

NAME                 STATUS    MESSAGE   ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok

这里的输出没有 etcd，因为 k3s 的默认数据存储是 Sqlite，对于小型数据库十分友好。Kubernetes 控制平面中发生的更改更多是与频繁更新部署、调度 Pod 等有关，因此对于几个节点的小型集群而言，数据库不会造成太大负载，能省下不少资源，真香！

5. 加入计算节点

部署好控制平面之后，就可以加入计算节点了。首先在计算节点上创建 Service Unit 文件：

$ cat > /etc/systemd/system/k3s-agent.service <<EOF
[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=exec
EnvironmentFile=/etc/systemd/system/k3s-agent.service.env
KillMode=process
Delegate=yes
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
TimeoutStartSec=0
Restart=always
RestartSec=5s
ExecStartPre=-/sbin/modprobe br_netfilter
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/k3s agent \
    --node-external-ip <public_ip> \
    --node-ip <public_ip> \
    --kube-proxy-arg "proxy-mode=ipvs" "masquerade-all=true" \
    --kube-proxy-arg "metrics-bind-address=0.0.0.0"
EOF

环境变量文件 /etc/systemd/system/k3s-agent.service.env 中需要加入两个环境变量：

K3S_URL : API Server 的 URL，一般格式为：https://<master_ip>:6443。其中 <master_ip> 是控制节点的公网 IP。
K3S_TOKEN : 加入集群所需的 token，可以在控制节点上查看 /var/lib/rancher/k3s/server/node-token 文件。

/etc/systemd/system/k3s-agent.service.env 内容如下：

K3S_URL=https://<master_ip>:6443
K3S_TOKEN=xxxxxxxx

启动 k3s-agent 并设置开启自启：

$ systemctl enable k3s-agent --now

查看节点状态：

$ kubectl get node

NAME         STATUS   ROLES    AGE     VERSION
blog-k3s01   Ready    master   3d6h    v1.17.6+k3s1
blog-k3s02   Ready    <none>   3d3h    v1.17.6+k3s1

6. 内网不互通的解决办法

这里会遇到一个问题，不同节点的 flannel 使用的是内网 IP 来进行通信，而我们的云服务器是内网不互通的，而且公网 IP 也不在服务器上。可以看一下 node 的 annotations：

$ kubectl get node blog-k3s02 -o yaml

apiVersion: v1
kind: Node
metadata:
  annotations:
    flannel.alpha.coreos.com/backend-data: '"xxxxx"'
    flannel.alpha.coreos.com/backend-type: extension
    flannel.alpha.coreos.com/kube-subnet-manager: "true"
    flannel.alpha.coreos.com/public-ip: 192.168.0.11
    ...

可以看到 flannel 给节点打的注解中的节点 IP 是内网 IP。要想让 flannel 使用公网 IP 进行通信，需要额外添加一个注解 public-ip-overwrite，然后 flannel 会基于这个 IP 配置网络。按照官方文档的说法，如果你的 node 设置了 ExternalIP，flannel 会自动给 node 添加一个注解 public-ip-overwrite，但我不知道该如何给 node 设置 ExternalIP，干脆就直接手动加注解吧：

$ kubectl annotate nodes <master> flannel.alpha.coreos.com/public-ip-overwrite=<master_pub_ip>
$ kubectl annotate nodes <node> flannel.alpha.coreos.com/public-ip-overwrite=<node_pub_ip>

加了注解之后，flannel 的 public-ip 就会被修改为公网 IP。然后在各个节点上重启各自的 k3s 服务，查看 wireguard 连接状况：

$ wg show flannel.1

interface: flannel.1
  public key: ONDgJCwxxxxxxxJvdWpoOKTxQA=
  private key: (hidden)
  listening port: 51820
  
peer: MKKaanTxxxxxxxV8VpcHq4CSRISshw=
  endpoint: <pub_ip>:51820
  allowed ips: 10.42.4.0/24
  latest handshake: 26 seconds ago
  transfer: 133.17 KiB received, 387.44 KiB sent
  persistent keepalive: every 25 seconds

可以看到通信端点被改成了公网 IP，大功告成！

7. metrics-server 问题解决

还有一个问题就是 metrics-server 无法获取 cpu、内存等利用率核心指标。需要修改 metrics-server 的 manifests，使用以下命令在线编辑 metrics-server 的 manifests：

$ kubectl -n kube-system edit deploy metrics-server

然后加入以下执行参数后保存退出：

      -command:
        - /metrics-server
        - --kubelet-preferred-address-types=ExternalIP
        - --kubelet-insecure-tls

这样就可以让 metrics-server 使用公网 IP 来和 node 通信了。修改成功后就可以看到核心指标了：

$ kubectl top nodes
NAME         CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
blog-k3s01   193m         9%     886Mi           22%
blog-k3s02   41m          2%     1292Mi          32%

$ kubectl top pod -n kube-system
NAME                                      CPU(cores)   MEMORY(bytes)
coredns-848b6cc76f-zq576                  8m           14Mi
local-path-provisioner-58fb86bdfd-bzdfl   2m           9Mi
metrics-server-bdfc79c97-djmzk            1m           12Mi

到这里跨云服务商部署 k3s 基本上就大功告成了，下一篇文章将会教你如何打通家里到云上 k3s 的网络，让你家中所有设备都可以直接访问 Pod IP、svc IP，甚至可以直接访问 svc 域名，敬请期待。