前言

以前免费 SSL 证书时效一年的时候，一年折腾一次没啥感觉。现在所有的免费 SSL 证书时效都变成了 3 个月，折腾次数变多了之后就愈发感到困扰，所以拥有一个自动续期证书的工具就显得很重要了。这类工具常用的有 ohttps、acme.sh、certbot、Traefik（k8s 使用）。
OHTTPS 是我最早开始使用 SSL 证书的服务商，能够免费续迁证书，也可以 docker 部署自动更新，但是自动更新部署需要类似积分的东西，不充钱估计自动更新部署功能应该用不到两年。
acme.sh 顾名思义是一个使用 ACME 协议的客户端工具，由 shell 编写，支持Let’s Encrypt、zerossl、google、sslcom、buypass 等常见 CA 签发机构、支持自动更新部署、支持多个 DNS 服务商的 API，应该是当前使用的最多的免费 SSL 证书签发与续签工具。
Certbot 是官方（EFF电子前哨基金会）推荐的客户端，同样是一个使用 ACME 协议的经典客户端工具。它由 python 编写，主要是支持 Let’s Encrypt 的签发、自动续签。对于常见的 DNS 服务商 API 也提供支持，同时它还可以自动识别并修改 Nginx 或 Apache 的配置文件来安装证书。
Traefik 是一个非常流行的云原生边缘路由器或反向代理，它深度集成了 Let’s Encrypt，可以为 k8s 集群中的后端服务提供证书自动申请和管理功能。
本文主要是想写在 vps 上如何部署自动申请、续签 SSL 证书的工具，Traefik 由于主要是在 k8s 里面使用这个后面发文再说。长期免费续签 SSL 证书的工具就只有 acme.sh 和 Certbot 了。为什么我最终选择了 acme.sh 呢？原因主要是有三点：

• acme.sh 支持更多的 CA 机构
• acme.sh 支持更多的 DNS API，由于通配符证书必须要使用 DNS 验证，这一点很重要
• acme.sh 完全由 shell 编写，不需要额外安装依赖

以上是背景，下面开始部署教程。

1. 安装 acme.sh

命令中的 my@exampmle.com 换成自己的邮箱

1

curl https://get.acme.sh | sh -s email=my@example.com

这一条命令执行完成，会在你当前的家目录下面新建一个 .acme.sh 文件夹,后面生成的证书以及所有与之相关的文件都会在这个文件夹里面。同时还会新建一个定时任务每天0点自动检测证书有效期，如果临近过期则会自动发起更新证书的操作。

执行这条命令加载环境变量，让 acme.sh 命令能被识别

1

source ~/.bashrc

2. DNS 记录验证准备

本文指的 SSL 证书都是为域名颁发的，因为现在为 ipv4 颁发 SSL 证书也是很常见的一个操作，所以这里提一下以免混淆！对于域名的 SSL 证书在颁发之前必须要做域名所有权验证，常见的验证方式有两种。

• 为需要颁发证书的域名添加指定的 DNS 记录进行验证
• 在需要颁发证书的域名网站的根目录，添加指定文件进行验证
  我这里因为是要给通配符域名颁发证书，所以只能选择使用 DNS 记录进行验证，我的域名免费托管在 cloudflare 上而 acme.sh 可以调用 cloudflare 的 api 进行自动化部署，下面说明如何操作。

2.1 创建 APi 令牌

登录 cloudflare 后选择需要操作的域名，假如我有一个域是 hello.com，后面都以这个域名来描述。

选择域之后，往下看到右边的 API 标题那里记录自己的 区域ID，然后点击 获取您的API令牌 ,然后再点击 创建令牌 并选择 编辑区域 DNS

给区域编辑权限，特定区域 选择 hello.com, 同时建议为令牌的使用指定来源 ip 以加强安全

令牌创建完成后会获得一个 key 并记录下来。

2.2 添加环境变量

下面的命令中 CF_Token 换成你完成创建令牌后获得的 key，CF_Zone_ID 后面的内容换成你的 区域 ID

1
2

export CF_Token="xxxxxxxxxxxxxxxxxxxxxxxxx"
export CF_Zone_ID="xxxxxxxxxxxxxxxxxxxxxxx"

这一步是为后面 acme.sh 调用 API 添加 DNS 记录进行验证做准备的，在使用 acme.sh 第一次申请证书的时候会被 acme.sh 自动保存，后面证书过期自动续签的时候就不需要人为干预了。

3.Google API 权限配置

acme.sh 本身是支持多个 CA 机构的，默认使用的是 zerossl，其次用的最多的是 let’s encrypt，不过我一般偏好 google（无他，个人偏好）

3.1登录 GCP 控制台

GCP控制台 点击登录，选择右上角的激活 cloud shell。

额外说下，这里登录 GCP 控制台的账号跟上面第一步安装 acme.sh 的时候邮箱账号是没有任何关联的。
第一个步骤里面的邮箱账号是注册 ACME 账号的，仅用于向 CA 机构说明身份和接收通知；
这里登录 GCP 控制台的账号是用来向谷歌获取颁发证书的授权的，两者无任何关联关系！

3.2启用 publicca

在 cloud shell 里面执行命令启用 publicca

1

gcloud services enable publicca.googleapis.com

3.3获取 EAB 密钥 ID 和 HMAC

记录下获取到的密钥和 HMAC 值

1

gcloud publicca external-account-keys create

4.颁发证书

4.1 申请证书

在自己部署 acme.sh 的 vps 上执行命令申请证书

1

acme.sh --issue --dns dns_cf  -d hello.com -d '*.hello.com' --keylength 2048 --dnssleep 120

• --keylength 2048 指定使用 RSA 加密算法，长度为 2048
• -d hello.com -d '*.hello.com' 指定要申请证书的域名。（这里要注意 *.hello.com 是不包含 hello.com 这个根域名的，如果你有直接使用 hello.com 访问加密的站点则必须要额外加上 -d hello.com）
• --dns dns_cf 指定 dns 服务商为 cloudflare
• --issue 核心命令，它的作用是向一个证书颁发机构（CA）发起请求并获取一个新的SSL证书
• --dnssleep 120 DNS 指定记录检查等待时间为 120 秒。默认是 20 秒，如果指定多个域名建议调整长一点

4.2安装证书

这一步也可以不使用下面的命令，安装证书本质上的操作就是把生成的证书、密钥文件复制到指定的路径，自己手动复制完全没问题的。
不过相对于手动操作，使用命令安装证书有个好处是后面自动更新证书的时候，acme.sh 会在证书更新完成后自动的执行这里相同的安装命令以达成自动更新本地证书的目的，这样就不用在证书续签之后再手动复制了!

1

acme.sh --install-cert -d hello.com --fullchain-file /etc/pki/nginx/fullchain.cer --key-file       /etc/pki/nginx/fullchain.pem --reloadcmd      "systemctl reload nginx.service"

• fullchain.cer 是我习惯用来保存证书的文件
• fullchain.pem 是我习惯用来保存密钥的文件
• --reloadcmd 因为我 vps 上是用 nginx 部署的 web 服务，所以这里可以顺便指定本地证书替换完成后 reload 的操作

5.结束

全程大概五分钟不到，一次操作终身免于证书更新的困扰！

补充一个关于常见证书文件后缀相关的小知识：

• .key 私钥 (Private Key)文件。不应该给任何人看的核心机密。对应 Nginx 里面的 ssl_certificate_key
• .pem 通用后缀。文件里可以包含私钥、服务器证书、中间证书、根证书，或任意组合。必须根据上下文或文件名来判断其内容
• .crt 公钥证书 (Certificate)文件。通常只包含一个公钥证书（服务器证书或中间证书），一般不包含私钥。与 .cer 常常可以互换使用
• .cer 公钥证书 (Certificate)文件。和 .crt 基本一样，也是代表公钥证书。acme.sh 默认生成 .cer，而Windows系统也常用 .cer
• .csr 证书签名请求 (Certificate Signing Request)文件。通常会把域名信息和公钥打包在这个文件里提交给CA，请求CA用他们的私钥来“签名”这个请求，从而生成 SSL 证书

1. 前言

• 目标: 搭建一个安全、稳定、符合官方标准的K8s学习与实验环境。
• 操作系统版本： Debian12
• k8s 版本： 1.33.4
• CRI 容器运行时： containerd v1.6.20
• CNI 网络插件： Calico v3.30.3
• 服务暴露： Cloudflare Tunnel

2. 基础配置

此部分所有 master、work 节点都需要操作。

2.1 基本工具安装

更新系统并安装必要工具：

1
2
3

apt update
apt upgrade -y
apt install -y apt-transport-https ca-certificates curl gpg bash-completion

2.2 关闭 swap

k8s 建议关闭 swap分区:

1
2

swapoff -a
vim /etc/fstab # 编辑fstab文件，注释掉 swap 那一行

2.3 安装 WireGuard

1

apt install wireguard -y

2.4 生成密钥对

1
2
3
4

cd /etc/wireguard
wg genkey | tee privatekey | wg pubkey > publickey
chmod 600 privatekey
chmod 600 publickey

2.5 配置 WireGuard

关于 WireGUard 更详细的内容解析，可以查看我之前写的这篇文章 WireGuard原理解析与生产实践
编辑 /etc/wireguard/wg0.conf，写入以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

[Interface]
# 本机的私钥
PrivateKey = xxxxxxxxxxxx
# 本机在私有组网中的IP地址
Address = 10.66.66.1/24
# 默认监听端口（UDP协议）
ListenPort = 51820
# 统一设置 MTU
MTU = 1420

# 一号工作节点的 Peer
[Peer]
# 一号工作节点的公钥
PublicKey = xxxxxxxxxxxx
# 一号工作节点的公网IP和端口
Endpoint = x.x.x.x:51820
# 允许使用 WireGuard 接口通信的网段。这里注意下除了自定义的私网网段，还需要加上POD的网段。因为我的组网方案里POD是用Calico BGP模式通信的。
AllowedIPs = 10.66.66.0/24,10.244.0.0/16
# 保持连接，25秒发一次心跳，最佳建议值
PersistentKeepalive = 25

# 二号工作节点的 Peer
[Peer]
# 二号工作节点的公钥
PublicKey = xxxxxxxxxxxx
# 二号工作节点的公网IP和端口
Endpoint = x.x.x.x:51820
# 允许使用 WireGuard 接口通信的网段。这里注意下除了自定义的私网网段，还需要加上POD的网段。因为我的组网方案里POD是用Calico BGP模式通信的。
AllowedIPs = 10.66.66.0/24,10.244.0.0/16
# 保持连接，25秒发一次心跳，最佳建议值
PersistentKeepalive = 25

上面这个配置文件是以 master 节点为例编写的，其他两个节点也使用同样的格式配置，只不过变换下 Peer 部分 为其余两个主机、本机部分按照本节点配置。

2.6 启动与验证

1
2
3
4
5
6
7
8
9
10
11

# 启动并设置开机自启
wg-quick up wg0
systemctl enable wg-quick@wg0

# 查看状态
wg show

# 验证网络
ping 10.66.66.1
ping 10.66.66.2
ping 10.66.66.3

2.7 参数与模块配置

k8s需要特定的内核模块和系统参数来支持容器和网络,同时我希望 kube-proxy 使用 ipvs 模式所以需要做如下操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# 安装 ipvs
apt-get install -y ipset ipvsadm

# 配置启动自加载 ipvs 所需模块
cat <<EOF | tee /etc/modules-load.d/k8s-ipvs.conf
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack
EOF

# 手动加载 ipvs 相关模块
modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_sh
modprobe nf_conntrack

# 配置启动自加载容器运行时所需模块
cat <<EOF | tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

# 手动加载容器运行时相关模块
modprobe overlay
modprobe br_netfilter

# 配置启动自加载内核参数
cat <<EOF | tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# 配置生效
sysctl --system

2.8 安装容器运行时

安装 containerd ：

1

apt-get install -y containerd

生成默认配置文件并修改 cgroup 驱动为 systemd：

1
2
3
4
5
6
7
8
9

# 生成配置文件
mkdir -p /etc/containerd
containerd config default | tee /etc/containerd/config.toml

# 修改cgroup驱动为systemd，与kubelet保持一致
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

# 重启 containerd
systemctl restart containerd

替换 containerd 为国内镜像源（可选，但位于国内的服务器必须要操作），配置方法可以按照这篇文章来 containerd配置国内镜像加速

2.9 安装 k8s 组件

添加 k8s 官方 GPG 密钥和 APT 仓库：

1
2
3

# Google的仓库在国内无法访问，这里建议使用阿里云的镜像
curl -fsSL https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.33/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.33/deb/ /' | tee /etc/apt/sources.list.d/kubernetes.list

安装指定版本的 k8s 组件：

1
2
3
4
5

apt-get update
apt-get install -y kubelet=1.33.4-1.1 kubeadm=1.33.4-1.1 kubectl=1.33.4-1.1

# 锁定版本，防止意外升级
apt-mark hold kubelet kubeadm kubectl

k8s 集群创建的时候默认是通过路由来判断 internal ip 的，所以在使用 WireGuard 组建私有网络之后，k8s 并不会直接识别使用私网 IP，所以这里需要手动指定 kubelet 的 internal ip：

1
2
3
4
5

vim /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

# 在最后一行添加 --node-ip=x.x.x.x 这里的 x.x.x.x 替换成各个节点实际的 WireGuard 私网 IP
# 以我的 master 节点为例，最后一行修改为：
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --node-ip=10.66.66.1

重启 kubelet：

1
2
3

systemctl daemon-reload
systemctl enable kubelet
systemctl restart kubelet

3. master 配置

以下步骤仅在 master 节点上配置

3.1 创建 k8s 集群

执行 kubeadm init 命令创建集群：

1
2
3
4
5
6
7
8
9

# 我的 master 节点配置的 WireGuard IP 是 10.66.66.1、POD 网段是 10.244.0.0/16
kubeadm init \
  --kubernetes-version=v1.33.4 \
  --apiserver-advertise-address=10.66.66.1 \
  --pod-network-cidr=10.244.0.0/16 \
  --ignore-preflight-errors=Mem

# --apiserver-advertise-address: 这个参数非常重要它指明其他节点要通过 WireGuard 组建的私有网络来访问 API Server
# --ignore-preflight-errors=Mem: 添加这个参数是因为我的 master 节点内存很小只有 2GB ，不加会提示内存不足

初始化拉取镜像会花费一定时间，如果网络条件不好可能要等待5分钟左右，待命令执行完成后可以看到类似如下提示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

...

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.66.66.1:6443 --token abcdef.1234567890abcdef \
        --discovery-token-ca-cert-hash sha256:1234...

记录上面屏幕提示中 kubeadm join 这段命令，后续工作节点将通过此条命令加入新建的 k8s 集群中

按照提示配置：

1
2
3

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

配置命令补全：

1
2

echo 'source <(kubectl completion bash)' >> ~/.bashrc
source ~/.bashrc

修改 kube-proxy 为 ipvs 模式：

1

kubectl edit configmap kube-proxy -n kube-system

将 mode: "" 修改为 mode: "ipvs"，操作完成之后再执行命令删除老的 POD 让它重新生成：

1

kubectl delete pod -l k8s-app=kube-proxy -n kube-system

3.2 配置 CNI 网络插件

在前面跨云 k8s 组网方案中已经说明了使用到的 CNI 插件是 Calico，网络模式配置为 BGP。

安装 Calico：

1

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.30.3/manifests/calico.yaml

等待几分钟，让 Calico 的 Pod 启动即可

修改 calico 网络模式：

1
2
3
4

kubectl edit ippool default-ipv4-ippool
# 将 ipipMode: Always 修改为 ipipMode: Never
# 手动重启 calico-node
kubectl rollout restart daemonset calico-node -n kube-system

下载 calicoctl 工具：

1
2

wget https://github.com/projectcalico/calico/releases/download/v3.30.3/calicoctl-linux-amd64 -O calicoctl
chmod +x calicoctl

4. 防火墙配置

如果你的 vps 云厂商默认启用了安全组限制，需要打开 WireGuard 的监听端口的访问权限。

注意： 这里不需要再为 apiserver、etcd、kubelet 端口打开访问权限，因为前面已经做了 wg 组网。

因此，所有节点安全组上都仅需要却保对集群内其他节点的公网地址放开 51820/UDP

5. 加入工作节点

此部分内容仅在两个工作节点上进行

在两个工作节点上使用 root 权限执行 3.1 章节中记录下的 kubeadm join 命令即可加入集群：

1
2

kubeadm join 10.66.66.1:6443 --token abcdef.1234567890abcdef \
        --discovery-token-ca-cert-hash sha256:1234...

执行成功，屏幕会打印 This node has joined the cluster

在 master 节点上执行以下命令，检查节点状态：

1

kubectl get nodes -o wide

正常情况下所有节点的状态都会是 Ready 并且 INTERNAL-IP 应该显示的是 WireGuard 组网时配置的私有 IP。
在第四步工作节点加入集群的时候工作节点会拉取 kube-proxy 和 calico-node 的镜像并部署，这一步也有可能会因为网络不好导致进度缓慢，所以如果节点是 NotReady 可以先等下再看。

检查 Pod 状态：

1

kubectl get pods -A -o wide

确保 calico-node, coredns, kube-proxy 等所有 Pod 都处于 Running 状态。

使用 calicoctl 工具检查 BGP 是否建立成功：

1

./calicoctl node status

输出结果里面每一个节点都应该是 Established 才正常。

6. 暴露服务

6.1 部署 ingress

在 master 上执行以下命令部署 ingress：

1

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.13.2/deploy/static/provider/baremetal/deploy.yaml

6.2 创建 tunnel

登录 cloudflare 仪表盘，点击左侧面板进入 ZeroTrust 页面，随后依次点击 “网络”-“tunnels”-“创建隧道”-“选择 cloudflared”-“自定义名称”-“保存”-“环境选择 Docker”-“点击复制命令”
随后记录下–token 后面的一长串字符，例如我的是 eyJhxxxxxxxxxxxxxxxxxxxxVdyJ9

6.3 创建 secret

在 k8s 中通常使用 secret 安全保存各类 token、密码等内容：
新建 cloudflare-tunnel-secret.yaml，写入以下内容：

1
2
3
4
5
6
7

apiVersion: v1
kind: Secret
metadata:
  name: tunnel-token-secret # 自定义的名字，后面要用到
  namespace: default
stringData:
  token: "<尖括号内的这部分文字替换成上面复制出来的Token>"

创建 secret：

1

kubectl apply -f cloudflare-tunnel-secret.yaml

6.4 创建 cloudflare deployment

上一步的 secret 创建好之后即可进一步新建 deployment，新建 cloudflare-deployment.yaml 文件并写入以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloudflared
  namespace: default
  labels:
    app: cloudflared
spec:
  replicas: 2 # 2个副本高可用
  selector:
    matchLabels:
      app: cloudflared
  template:
    metadata:
      labels:
        app: cloudflared
    spec:
      containers:
      - name: cloudflared
        image: cloudflare/cloudflared:latest
        args:
          - tunnel
          - --no-autoupdate
          - run
          - --token
          - $(TUNNEL_TOKEN)
        env:
        - name: TUNNEL_TOKEN
          valueFrom:
            secretKeyRef:
              # 下面这行 name 的值必须和 5.3 章节中创建的 name 值保持一致
              name: tunnel-token-secret
              key: token

创建 deployment：

1

kubectl apply -f cloudflare-deployment.yaml

创建完成之后检查 cloudflare 的 pod 状态运行正常即可。

6.5 创建测试用 web 页面

新建一个 hello-deployment.yaml 文件，并写入以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
  namespace: default
spec:
  replicas: 2 # 2个副本高可用
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: nginxdemos/hello # 惯用的用于演示的 ng 镜像
        ports:
        - containerPort: 80

创建 deployment：

1

kubectl apply -f hello-deployment.yaml

新建一个 hello-service.yaml 文件，并写入以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: Service
metadata:
  name: hello-app-service
  namespace: default
spec:
  type: ClusterIP # 只在集群内部暴露服务
  selector:
    app: hello-app
  ports:
    - protocol: TCP
      port: 80 # service 监听端口
      targetPort: 80 # 流量转发到容器的端口

创建 service:

1

kubectl apply -f hello-service.yaml

检查 deployment、pod、service 是否正常：

1

kubectl get deployment,service,pods -n default

新建 hello-app-ingress.yaml 文件，并写入以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-app-ingress
  namespace: default
spec:
  ingressClassName: "nginx"
  rules:
  - host: "hello.com" # 替换为自己的域名，例如 blog.xxx.com、test.xxx.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-app-service # 流量转发到 hello-app-service
            port:
              number: 80

创建 ingress：

1

kubectl apply -f hello-app-ingress.yaml

6.6 配置域名和路由

这里以 blog.hello.com 域名为例。
回到之前打开的 cloudflare tunnel 页面，选择“下一步”，子域栏填 hello，域栏选择托管在 cloudflare 上的 hello.com，路径栏留空，服务选择 HTTP，URL 栏填 http://ingress-nginx-controller.ingress-nginx,最后点击保存完成配置。

7. 验证

浏览器访问 https://blog.hello.com 并勾选 Auto Refresh，应该可以看到每秒自动刷新的 nginx 图标页面，并且会显示 pod 的 ip

高可用测试：
轮流关闭工作节点主机，可以看到页面仍然能够正常访问，且 IP 会对应的变成剩余工作节点上的那个 pod ip。

后续新上线一个服务，就要创建 deployment-service-ingress-web 上跳转 tunnel。
因为我是有个域名完全拿来在这个环境做测试的，所以我的 tunnel 上面配置的是 * 通配符跳转，tunnel 相当于仅作为连接器。而 ingress 负责实现实验学习所需要的复杂的流量路由,同时这样后面也就不用在网页上调整 cloudflare 了。
如果你不需要用 ingress 来做这种复杂的流量路由实验，则完全可以去除本文中 ingress 相关的章节。用 tunnel 既当连接器又当路由分发器。比如直接跳过创建 ingress 部分，同样按照文中创建完成 hello-app 的 deployment 和 service 之后。在 tunnel 页面依然选择 HTTP 类型，URL 改成你 service 对应的 cluster ip 即可。

1. 私有网络

为什么首先提到的是私有网络？
结论放在前面：安全！即便是我个人测试用的这里也要使用私有网络

那么为什么不能直接使用各个云主机的公网 ip 地址来搭建 k8s 集群呢？因为直接使用公网 ip 地址搭建 k8s 集群存在极大的安全隐患：

1. k8s 的控制平面是整个集群的大脑，kube-apiserver 作为其入口，若直接暴露于公网那么你懂的，这将会面对永无休止的恶意扫描和攻击。尽管 apiserver 拥有完善的认证授权机制（TLS、RBAC），但将核心管理端口暴露在互联网上，本身就极大地增加了攻击面，违反了最小权限和纵深防御的安全原则。etcd 的端口（2379/2380）若有任何配置不当，则可能导致整个集群数据被泄露或篡改，后果不堪设想。
2. 集群内部的流量如果直接通过公网进行通信，那么 k8s 原生的 NetworkPolicy 就很难有用武之地了。网络策略依赖于 CNI 插件对 pod ip 的识别和控制，公网流量使得这种精细化的内部访问控制会变得异常复杂和不可靠。
3. 如果使用的 CNI 插件用的是 BGP 等明文协议，这相当于对外公布了你集群所有的路由信息，仅是从信息泄露这个层面来看就是不可接受的。

综上所述，为所有节点构建一个统一的、私有的“第二层”网络平面、让所有集群内部的通信（包括控制平面和数据平面）都发生在这个可信的私有网络之上是十分必要的！

k8s 集群内通信机制

在深入组网方案之前，我们有必要先回忆下 k8s 集群内部的通信模型。
首先我们都知道 k8s 集群的通信主要围绕 kube-apiserver 展开，它以 HTTPS API 的形式提供服务：

• 控制平面内部通信：etcd、kube-controller-manager、kube-scheduler 与 kube-apiserver 之间的通信，均通过 TLS 加密。etcd 尤其敏感，通常只监听在回环地址或一个受信任的私有网络接口上。
• 控制平面与工作节点通信：
• kube-apiserver 到 kubelet：apiserver 主动连接 kubelet 的 10250 端口，用于执行 kubectl exec/logs/port-forward 等命令,此连接需要经过 kubelet 的认证和授权。
• kubelet 到 kube-apiserver：kubelet 作为客户端，主动连接 kube-apiserver 的 6443 端口，上报节点状态、Pod 状态，并接收指令，这是最主要的通信路径。

2. 组网工具

市面上有多种成熟的组网工具，如 ZeroTier、Tailscale、WireGuard 等等，我这里使用的是原生的 WireGuard，关于 WireGuard我之前也写了一篇相对详细的文章： WireGuard原理解析与生产实践
几种组网工具说明以及为何会选择使用 WireGuard，原因如下：

• ZeroTier：功能强大，通过自有的全球根服务器网络实现复杂的 NAT 穿越和多路径路由，配置简单。但其协议私有，且核心网络依赖于中心化的控制器
• Tailscale：基于 WireGuard 构建，极大地简化了密钥交换和节点管理。它引入了一个中心化的协调服务器来管理公钥、ACL 和 IP 分配等。最大的特点是易用，but Tailscale 不支持自定义组网网段，并且使用了 100.64.0.0/10 这个为运营商级 NAT 保留的地址段。这本身并不是个问题，问题在于奇妙的阿里云服务器内部也使用了这个地址段。如果你也有阿里云的服务器那就有可能会产生冲突导致路由问题，这里我不具体展开了，搜索关键词会有很多文章
• WireGuard：一个现代化、高性能的 VPN 协议，从 5.6 版本内核开始已被并入 Linux 内核主线，市面上也有很多基于它构建的组网工具，主要缺点是没有自带的管理工具，在多节点全连接网状拓扑下扩展配置就很麻烦

我的需求场景: 一个稳定、高性能、且网络配置完全可控的底层。
3~4个节点的 wg 配置不会太麻烦，对比 Tailscle 和 ZeroTier 原生 wg 的网络稳定性实测要更优秀，所以最终选择 WireGuard 进行节点间的组网。

节点间组网规划

1. 网络拓扑：对于三到四个节点的小规模集群，最理想的拓扑显然是 全连接网状网络。每个节点都与其他所有节点直接建立 WireGuard 隧道。这样任意两个节点间的通信都只需要一跳，延迟最低，且没有单点故障。

2. 网段选择：

   • 必须在 RFC 1918 定义的私有地址空间中选择：10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
   • 为了最大程度地避免与节点所在云环境的内网、本地开发环境的局域网或未来可能接入的其他网络产生冲突，一个最佳实践是选择一个相对冷门的网段。例如，不直接使用 10.0.0.0/24 或 192.168.1.0/24，而是选择像 10.66.66.0/24 这样的网段
   • 对于3-4个节点，建议直接使用 /24 这种标准的 C 类子网便于记忆和管理，当然选择一个小的子网（如 /29）地址也完全够用

3. CNI 插件

上面我们讨论了 k8s 集群中 Node-to-Node 的通信问题。接下来需要解决 k8s 中更加核心的 Pod-to-Pod 通信问题。

首先要澄清一个事实，也是常见的疑惑。 K8s 官方仅提出了个网络规范模型，并不提供具体实现。这个模型的核心原则是：

1. 集群中每个 Pod 都拥有一个唯一的、可路由的 IP 地址
2. 任何节点上的 Pod 都可以直接与任何其他节点上的 Pod 通信，无需 NAT
3. 节点上的代理（如 kubelet）可以与该节点上的所有 Pod 通信。

CNI 插件则是这个模型的具体实现，k8s 会通过用户选择安装的 CNI 插件来实现创建虚拟网络设备、配置 IP、设置路由等操作。

常见的 CNI 插件

市面上有众多 CNI 插件，我们选取几个主流的进行对比：

**我这里选择使用 Calico 这个 CNI 插件并使用 BGP 网络模式，原因如下：

• 避免双重封装： Flannel 通常使用 VXLAN 封装 Pod 流量。如果将其运行在已经是 WireGuard 隧道的网络上，就会产生 Pod流量 -> VXLAN封装 -> WireGuard封装 -> 公网 的双重封装，带来额外的性能开销（MTU 问题、CPU 消耗）。
• 利用底层网络： Calico 的 BGP 模式将每个 K8s 节点变成一个 BGP aS(自治系统)。节点之间通过 BGP 协议交换各自负责的 Pod CIDR 的路由信息。这意味着，当 Node1 上的一个 Pod 要访问 Node2 上的 Pod 时，Node1 的内核路由表会明确地知道，目标 Pod IP 的下一跳是 Node2 的节点 IP。
• 与 WireGuard 的协同： 我们可以让 Calico 的 BGP Peering 直接在 WireGuard 的私有网络接口（如 wg0）上进行。这样，路由信息和 Pod 数据流量都将通过加密的 WireGuard 隧道传输，既实现了路由的高效宣告，又保证了数据的安全性。整个数据路径是：Pod流量 -> WireGuard封装 -> 公网，只有一层封装，性能最优。

下面的 Mermaid 图展示了 Calico BGP over WireGuard 的数据流：

sequenceDiagram    participant Pod1 on Node1    participant Node1 Kernel    participant WG Tunnel on Node1    participant WG Tunnel on Node2    participant Node2 Kernel    participant Pod2 on Node2    Pod1->>Node1 Kernel: Send packet to Pod2 IP    Note over Node1 Kernel: Routing Table Lookup<br/>Destination: Pod2's CIDR<br/>Next Hop: Node2's WG IP (10.20.30.2)    Node1 Kernel->>WG Tunnel on Node1: Forward packet to wg0 interface    WG Tunnel on Node1->>WG Tunnel on Node2: Encapsulate & send over Internet    WG Tunnel on Node2->>Node2 Kernel: Decapsulate & receive packet    Note over Node2 Kernel: Packet arrives on wg0<br/>Destination: Pod2 IP    Node2 Kernel->>Pod2 on Node2: Deliver packet

Pod 网段规划

我这里就用默认的 10.244.0.0/16，默认就是一个极大的值，而且我觉得也没有调小的必要性。
如果你想要自定义个网段一个至关重要的点： Pod 网段（--pod-network-cidr）绝对不能与节点 WireGuard 网络的网段重叠，当然如果按照我前面的规划，节点间 wg 组网使用 10.66.66.0/24 则即可与 Pod 的默认网段分开。

• K8s 的 kube-controller-manager 会从你指定的 Pod 网段中为每个节点分配一个小子网（例如，--pod-network-cidr=10.244.0.0/16，那么 Node1 可能分到 10.244.0.0/24，Node2 分到 10.244.1.0/24）
• Calico 会将这些子网的路由信息通过 BGP 在节点间广播
• 如果 Pod 网段与节点网络重叠，将导致严重的路由冲突

推荐的规划是：

• 节点网络: 10.66.66.0/24
• Pod 网络: 10.244.0.0/16 (默认，--pod-network-cidr 指定 )
• Service: 10.96.0.0/12 (kubeadm 默认值，通常无需修改)

4. 服务暴露

上面已经解决了节点和 Pod 的通信，现在我们还需要考虑集群内部服务间的通信以及如何将服务安全地对外暴露。

kube-proxy 模式

毕竟是讨论 k8s 集群的网络设计，这里顺带也提下 kube-proxy 吧。

kube-proxy 是实现 k8s 集群中 service 的关键组件，它负责将发送到 Service ClusterIP 的流量负载均衡到后端的 Pods。它主要有两种工作模式：

• iptables： 默认采用的模式。kube-proxy 会为每个 Service 和 Endpoint 创建大量的 iptables 规则。当 Service 数量巨大时，iptables 规则链会变得非常长，数据包在内核中进行规则匹配的路径也会变长，导致性能下降。其查找算法的时间复杂度是 O(n)，其中 n 是规则数量
• IPVS (IP Virtual Server)： IPVS 是 Linux 内核中专门用于负载均衡的模块，内建于 LVS (Linux Virtual Server) 项目。它使用哈希表来存储 Service 和 Real Server (Pod) 的映射关系，查找效率极高，时间复杂度为 O(1)。此外，IPVS 支持更丰富的负载均衡算法（轮询、最少连接、加权等）

对于有一定规模或对性能有要求的 k8s 集群，强烈推荐使用 IPVS 模式。虽然在我的 3 节点小集群中实测性能差异并不明显，但我就是想要换成 ipvs 哈哈哈。
修改的方法也很简单，确保 ipvs 模块已经加载并且在 kube-proxy 的 ConfigMap (kube-proxy-cm) 中将 mode 字段从 "" (或 "iptables") 修改为 "ipvs" 即可。

服务暴露方案

K8s 默认提供的服务暴露方式(service 类型)：

• ClusterIP： 默认类型。为 Service 分配一个只能在集群内部访问的虚拟 IP。节点间可通过这个 IP 访问服务，但无法从外部访问
• NodePort： 在 ClusterIP 的基础上，在每个节点上都开放一个固定的静态端口（默认范围 30000-32767）。任何发送到 <NodeIP>:<NodePort> 的流量都会被转发到该 Service。在生产环境中，它通常不直接对最终用户暴露，而是作为上游负载均衡器（如 F5, Nginx）的目标
• LoadBalancer： 在 NodePort 的基础上，请求云服务商创建一个外部负载均衡器，并将流量导向所有节点的 NodePort。这是云上环境最常用的生产级暴露方式，但它依赖于云厂商的服务，在我们的跨云、自建环境中不可用。
• ExternalName： 这个比较特别它不转发流量，而是将 Service 名称映射到指定的 DNS 名称。适用于集群内的应用需要通过固定名称访问外部服务的场景

对于我的跨云环境，LoadBalancer 首先就被排除了，其次 ExternalName 不适用测试、日常使用场景，ClusterIP 无法在外网直接使用，看起来就只能使用 NodePort 了，但是这也有个问题，使用 NodePort 意味着我访问的时候还必须要用 ip:端口 的形式，这看起来令人不爽。我渴望一个统一的入口或者说反向代理吧！
习惯了使用因为我个人测试用也是通过域名去访问，而我的域名托管在 cloudflare，cloudflare 的免费版不支持给同一个域名解析到不同的 A 记录。

针对这个问题，自然就会想到生产环境常用的 ingress 了。

简单介绍下 ingress,我们一般提到的 ingress 指的是 ingress + ingress controller。
首先 Ingress 它不是一种 service 类型，它是一个独立的 API 对象，它定义了从集群外部访问内部 Service 的规则，主要针对 HTTP/HTTPS 流量。
Ingress Controller 则是实现这些规则的“大脑”，它是一个运行在集群内的反向代理程序，持续监听 Ingress 对象的变化，并动态更新自身的路由配置。
对于我当前的环境选择使用 ingress 可以让多个 service 可以共享同一个 Ingress Controller 和同一个外部入口，这很好。

但是依然存在一个问题。Ingress 没有解决一个根本问题： 外部流量最初应该发送到哪里？ Ingress Controller 本身也需要被暴露。在我的跨云环境中，有以下几种传统思路：

• NodePort + DNS 轮询： 将 Ingress Controller 的 service 设置为 NodePort 类型。这样，三个节点的公网 IP 都会监听在同一个端口上。随后，我们可以为域名（如 hello.example.com）配置三条 A 记录，分别指向这三个公网 IP。可惜的是我的域名托管在 cloudflare，cloudflare 的免费版不支持给同一个域名解析到不同的 A 记录
• NodePort + 专业 DNS 服务： 使用支持健康检查的 DNS 服务（常见的有 AWS Route, Google Cloud DNS 或 Cloudflare 的付费套餐）。这些服务可以定期探测 NodePort 的可用性，并动态地从 DNS 解析结果中移除故障节点的 IP。可惜的是都不免费！
• 自建外部负载均衡器： 在三台 K8s 节点之外，再部署一组高可用的负载均衡器（HAProxy + Keepalived），由它们来接收所有流量并分发到 K8s 节点的 NodePort。这应该是最可用的方案了，但是仍然会有一定的额外开销。

我这里最终方案是妥协使用 Cloudflare Tunnel 来免费解决问题，当然代价是大陆访问存在网络负优化。

Cloudflare Tunnel (原名 Argo Tunnel) 是一个非常巧妙的工具。它的工作原理如下：

1. 在 Kubernetes 集群内部署一个 cloudflared 连接器（通常是 Deployment）
2. 这个连接器会主动向 Cloudflare 的边缘网络发起一个出站连接隧道
3. 然后你可以在 Cloudflare 的 DNS 配置中，将你的域名（如 hello.example.com）指向这个 Tunnel
4. 当外部用户访问 hello.example.com 时，请求会到达 Cloudflare 的边缘节点。Cloudflare 通过已经建立的隧道，将流量安全地转发到集群内的 cloudflared 连接器上
5. cloudflared 连接器再将流量转发给集群内部的 Ingress Controller Service

这个方案的优势在于：

• 零公网暴露： 因为 cf 使用隧道连接到集群内部，所以我们的服务就可以使用上面提到的 ClusterIP 方式仅对集群内暴露，这样任何一台 K8s 节点都不需要暴露任何公网端口，所有入站流量都通过 Cloudflare 的加密隧道进入，安全性极高。
• 原生高可用： cloudflared 的 Deployment 可以有多个副本，它们会自动连接到 Cloudflare 边缘，实现负载均衡和高可用。Cloudflare 会自动处理到健康隧道的流量路由。
• 简化网络配置： 无需处理公网 IP 变化、DDNS、防火墙端口开放等繁琐事宜。

这个方案的核心缺点在于： 网络对大陆不友好，部分省份延迟可能达到4-5秒。

最后还有一个问题，既然已经决定使用 cloudflare tunnel 了，那么前面说的 ingress 还需要继续使用吗？

答案是仍然推荐使用 ingress，看下面两张图就明白了。

• 方案一： 为每个服务创建一个 Tunnel。在这个方案中需要在 Cloudflare 那边配置三条独立的 Tunnel，并且为每个 Tunnel 配置一个域名，让它们分别指向 Kubernetes 内部对应的服务
• 方案二：使用单一 Tunnel + Ingress。在这个方案中，只需要在 Cloudflare 那边配置一个 Tunnel。这个 Tunnel 的目标是集群内的唯一入口——Ingress Controller，所有的域名都先解析到这个 Tunnel 再由 ingress 分发到不同的服务中。

方案一示例：

graph TD    subgraph "用户端"        User[<fa:fa-user> 用户]    end    subgraph "Cloudflare 全球网络"        CF_Edge[<fa:fa-globe> Cloudflare Edge]        User -- "访问 web01.example.com" --> CF_Edge        User -- "访问 web02.example.com" --> CF_Edge        User -- "访问 web03.example.com" --> CF_Edge    end    subgraph "Kubernetes 集群内部"        subgraph "网络入口"            Cloudflared[<fa:fa-shield-halved> cloudflared Pods]        end                subgraph "应用服务 (L4)"            Svc1[<fa:fa-server> web01-svc]            Svc2[<fa:fa-server> web02-svc]            Svc3[<fa:fa-server> web03-svc]        end        subgraph "应用Pods (分布在3个节点上)"            Pod1A[<fa:fa-cube> web01-pod-a]            Pod1B[<fa:fa-cube> web01-pod-b]            Pod1C[<fa:fa-cube> web01-pod-c]                        Pod2A[<fa:fa-cube> web02-pod-a]            Pod2B[<fa:fa-cube> web02-pod-b]            Pod2C[<fa:fa-cube> web02-pod-c]            Pod3A[<fa:fa-cube> web03-pod-a]            Pod3B[<fa:fa-cube> web03-pod-b]            Pod3C[<fa:fa-cube> web03-pod-c]        end        CF_Edge -- "Tunnel for web01" --> Cloudflared        CF_Edge -- "Tunnel for web02" --> Cloudflared        CF_Edge -- "Tunnel for web03" --> Cloudflared        Cloudflared -- "转发给 web01-svc" --> Svc1        Cloudflared -- "转发给 web02-svc" --> Svc2        Cloudflared -- "转发给 web03-svc" --> Svc3                Svc1 --> Pod1A & Pod1B & Pod1C        Svc2 --> Pod2A & Pod2B & Pod2C        Svc3 --> Pod3A & Pod3B & Pod3C    end        style User fill:#cde4ff    style CF_Edge fill:#ffb366

方案二示例：

graph TD    subgraph "用户端"        User[<fa:fa-user> 用户]    end    subgraph "Cloudflare 全球网络"        CF_Edge[<fa:fa-globe> Cloudflare Edge]        User -- "访问 web01/02/03.example.com" --> CF_Edge    end    subgraph "Kubernetes 集群内部"        subgraph "统一网络入口"            Cloudflared[<fa:fa-shield-halved> cloudflared Pods]        end                subgraph "应用路由层 (L7)"            IngressSvc[<fa:fa-network-wired> Ingress Controller Service]            IngressPod[<fa:fa-map-signs> Ingress Controller Pod]        end                subgraph "应用服务 (L4)"            Svc1[<fa:fa-server> web01-svc]            Svc2[<fa:fa-server> web02-svc]            Svc3[<fa:fa-server> web03-svc]        end        subgraph "应用Pods (分布在3个节点上)"            Pod1A[<fa:fa-cube> web01-pod-a]            Pod1B[<fa:fa-cube> web01-pod-b]            Pod1C[<fa:fa-cube> web01-pod-c]                        Pod2A[<fa:fa-cube> web02-pod-a]            Pod2B[<fa:fa-cube> web02-pod-b]            Pod2C[<fa:fa-cube> web02-pod-c]            Pod3A[<fa:fa-cube> web03-pod-a]            Pod3B[<fa:fa-cube> web03-pod-b]            Pod3C[<fa:fa-cube> web03-pod-c]        end        CF_Edge -- "统一入口 Tunnel" --> Cloudflared        Cloudflared -- "所有流量都转发给 Ingress" --> IngressSvc        IngressSvc --> IngressPod        IngressPod -- "读取Ingress规则<br/>if host == web01.example.com" --> Svc1        IngressPod -- "if host == web02.example.com" --> Svc2        IngressPod -- "if host == web03.example.com" --> Svc3                Svc1 --> Pod1A & Pod1B & Pod1C        Svc2 --> Pod2A & Pod2B & Pod2C        Svc3 --> Pod3A & Pod3B & Pod3C    end        style User fill:#cde4ff    style CF_Edge fill:#ffb366    style IngressPod fill:#99ff99

5. 总结

• 节点间使用原生 WireGuard 全连接网状组网
• 节点网段使用 10.66.66.0/24
• CNI 插件使用 Calico，网络模式采用 BGP
• Pod 网段使用默认的 10.244.0.0/16
• Service 网段使用默认的 10.96.0.0/12
• 采用 ClusterIP 仅对集群内暴露服务
• 部署 ingress 统一服务入口
• 使用 cloudflare tunnel 安全引入外部流量到集群内部

结合实际情况最终还是给出了这样一套不算完美的跨云、跨地域 k8s 集群网络设计思路，对于小型的实验环境(至少对于我)应该算是够用了。

在今天这个云计算、远程办公和物联网设备无处不在的分布式时代里，异地组网需求变的越来越多，实现异地组网的工具也凸显其重要性。WireGuard 就是当前最合适的工具之一。本篇文章将会深入讲解 WireGuard 原理、快速配置和进阶配置方案，后面如果有机会也会再介绍基于 WireGuard 实现的一些其他工具（Tailscale 之流）,不过对于我个人来说我使用 wg 其实是用来为3节点的 k8s 集群做组网的，所以我个人还是更加偏向于原生的 wg 使用而非其他工具。

2. WireGuard 的哲学和机制

2.1 设计哲学

WireGuard 不提供加密算法的选择，而是直接内建了一套被认为是当前最安全且高效的密码学原语组合。

• 密钥交换 (ECDH): Curve25519，现代椭圆曲线算法的最佳标准之一
• 对称加密: ChaCha20，在缺乏 AES 硬件加速的 CPU（如 ARM）上性能卓越，同时具备极高的安全性
• 消息认证 (MAC): Poly1305，与 ChaCha20构成 AEAD（认证加密），确保数据完整性和真实性
• 哈希: BLAKE2s，性能和安全性均超越 SHA-2/SHA-3
• 哈希表键: SipHash24，有效抵御哈希碰撞攻击 (Hash-DoS)
• 握手协议: 基于Noise Protocol Framework (Noise_IK)，提供前向保密、身份验证和抗重放攻击能力

这种设计的直接好处是消除了因配置错误导致的安全漏洞，极大地降低了部署和审计的复杂性。

2.2 核心机制

传统的 VPN 依赖复杂的策略或 ACL 来决定哪些流量进入隧道，而 WireGuard 则采用一种极为优雅的机制，即： 通过将对等（Peer）的公钥与其允许的IP地址列表进行强绑定，构建出一张“密码学路由表”。

当一个数据包到达 wg 接口时：

1. 内核查找该数据包的目标 IP 地址属于哪个 Peer 的 AllowedIPs 范围
2. 一旦匹配，内核就使用与该 Peer 公钥关联的对称会话密钥对数据包进行加密3. 反之，当收到一个加密数据包时，内核通过其身份信息（一个静态的 key index）找到对应的解密密钥，解密后验证其源 IP 是否在该 Peer 的 AllowedIPs 列表中。如果不在，数据包将被直接丢弃。

AllowedIPs 因此扮演了路由表和防火墙ACL的双重角色，机制极其简单高效！

3. WireGuard 流量路径

3.1 WireGuard 拓扑

WireGuard 的核心设计: 所有节点皆为 Peer。这赋予了其无与伦比的灵活性，使其能够通过简单的配置文件，构建出多种网络拓扑以适应不同的业务场景。本节具体讲解 WireGuard 组网拓扑的四个场景。

3.1.1 点对点

这是最基础的拓扑，也是所有复杂拓扑的基础。它仅连接两个节点，创建一个简单、安全的加密通道。

• 结构: [节点 A] <–> [节点 B]
• 配置特点:
  • 节点 A 的配置文件中只有一个 [Peer] 区块，指向节点 B
  • 节点 B 的配置文件中也只有一个 [Peer] 区块，指向节点 A
• 适用场景:
  • 安全地连接两台重要的服务器（例如，应用服务器与数据库服务器）
  • 为单个开发人员提供对其远程开发环境的专线访问

3.1.2 中心辐射型/星型

这是最常见的一种拓扑，一个中心节点作为网络的枢纽，所有其他分支节点都只与中心节点连接

• 结构: 中心节点连接到其他所有节点，其他节点之间没有连接
• 配置特点:
  • 中心节点: 配置文件中有多个 [Peer] 区块，分别对应每一个分支节点。通常拥有固定的公网 IP 并监听端口
  • 分支节点: 配置文件中只有一个 [Peer] 区块，指向中心节点。通常 Endpoint 指向中心节点的公网地址
• 流量路径: 任何两个分支节点之间的通信，都必须经过中心节点进行中转。例如，A 要访问 B，流量路径是 A -> 中心节点 -> B
• 优势:
  • 配置简单: 新增节点只需在中心节点上添加一个 Peer，并在新节点上配置指向中心节点即可
  • 集中管理与审计: 所有流量都经过中心节点，便于统一管理安全策略、进行流量监控和日志审计
• 劣势:
  • 单点故障: 中心节点一旦宕机，整个网络瘫痪
  • 性能瓶颈: 所有分支间的流量都汇集于中心，可能造成中心节点的带宽和 CPU 瓶颈
  • 延迟增加: 分支间的通信需要绕行中心节点，延迟较高

3.1.3 全连接网状

网络中的每一个节点都与其他所有节点直接建立连接

• 结构: 每个节点都像星型拓扑中的中心节点，与其他所有节点互为 Peer
• 配置特点:
  • 一个包含 N 个节点的网络，每个节点的配置文件中都必须有 N-1 个 Peer
• 流量路径: 任何两个节点之间都存在直接路径
• 优势:
  • 高可用性: 任意一个节点的故障不会影响其他节点之间的通信
  • 最低延迟: 节点间通信无需中转，性能最优
• 劣势:
  • 配置复杂: 配置量随着节点数量的增加呈指数级增长。对于多节点的组网，手动配置令人绝望，必须依赖自动化脚本或上层管理平台（如 Netmaker 等）。

3.1.4 部分连接网状

这是一种介于星型和全连接网状之间的混合拓扑。网络中的关键节点之间相互直连，而非关键节点则可能只连接到部分核心节点。

• 结构: 按需连接，形成一个不规则的网状
• 配置特点: 每个节点的 Peer 数量根据其在网络中的角色和需求而定
• 适用场景:
  • 在多集群场景下，让各个集群的核心网关互相直连，而每个集群内部的服务器则与本地网关连接
  • 性能敏感的应用服务器之间建立直接连接，普通服务器则通过一个或多个集中网关通信

3.1.5 简单总结

3.1 场景设定

这里以一个具体的案例来说明在 wg 组网环境下，数据包的流量路径。在描述案例之前必须要说明的是：从 WireGuard 的设计、架构、拓扑等层面来看，它是完全没有客户端和服务端之分的，每一个运行WireGuard的节点，无论其配置如何，在技术上都是一个完全对等的 “对等体（Peer）”，它们遵循相同的协议，拥有相同的功能。后文中提到的服务端和客户端都是不准确（严格说就是错误）的描述，用这个说法的原因是仅仅是方便 “角色定位”,请注意这个细节。

前提: Host A 与 Host B 之间已经完成了首次握手，并已协商出会话所需的对称加密密钥

• Host A:
  • 物理网卡 eth0 IP: 192.168.1.10
  • 虚拟网卡 wg0 IP: 10.0.0.1
  • 动作: curl Host B
• Host B:
  • 物理网卡 eth0 IP: 192.168.1.20
  • 虚拟网卡 wg0 IP: 10.0.0.2
  • 动作: Nginx 已监听 10.0.0.2:80

3.2 出站流量(Host A)

3.2.1 阶段一

用户空间 -> 内核协议栈 (Host A):

1. 应用层 (Userspace): 用户在 Host A 上执行命令 curl http://10.0.0.2。curl 程序通过 socket()、connect()、write() 等标准 POSIX 系统调用(syscall)，请求操作系统建立一个到 10.0.0.2:80 的 TCP 连接并发送 HTTP GET请求

2. 内核协议栈 (Kernel Space - TCP/IP Stack):

   • 内核的 TCP 模块接收到请求，开始构建 TCP 段（Segment）。首先是三次握手的 SYN 包，随后是承载 HTTP 数据的 PSH, ACK 包
   • IP 模块将 TCP 段封装成 IP 数据包（Packet）。此刻，这个 “内部数据包” 的样子是：
     • IP Header: Source IP: 10.0.0.1, Destination IP: 10.0.0.2
     • TCP Header: Source Port: <随机端口>, Destination Port: 80, Payload: "GET / HTTP/1.1..."

3.2.2 阶段二

内核路由 -> WireGuard 加密 (Host A):

1. 路由决策 (Routing): 内核需要决定从哪个网络接口发送这个 IP 包。它会查询路由表 (ip route show)，发现一条类似 10.0.0.0/24 dev wg0 的规则。因此内核决定将此包交给 wg0 虚拟接口处理

2. WireGuard 核心处理 (wg_xmit):

• 数据包进入 wg0 接口的发送队列，触发 WireGuard 内核模块的 wg_xmit() 函数
• 密码学密钥路由 (Cryptokey Routing): 这是 WireGuard 的灵魂。此模块识别到数据包的目标 IP: 10.0.0.2, 接着会遍历其对等（Peer）列表，查找哪个 Peer 的 AllowedIPs 配置包含了 10.0.0.2。最终会找到 Host B 的条目
• 内核态加密 (Encryption): WireGuard 模块从与 Host B 的会话中取出预先协商好的对称密钥，使用 ChaCha20-Poly1305 算法对 整个内部 IP 数据包 （从 IP 头到 TCP 数据结束）进行加密

3.2.3 阶段三

UDP 封装 -> 物理网络 (Host A):

1. UDP 封装 (Encapsulation):

• 加密后的数据块成为一个新的 “外部数据包” 的 Payload
• WireGuard 模块为其添加一个简短的 WireGuard 头部（包含密钥索引等信息）
• 内核网络栈为其添加 UDP 头部。源端口由操作系统分配，目标端口是 Host B 配置中指定的 Endpoint 端口 51820 (默认)
• 最后添加外部 IP 头部。源 IP 是物理网卡 IP 192.168.1.10，目标 IP 是 Host B 的 Endpoint IP 192.168.1.20
• 此刻即将在物理网络上传输的数据包结构是：
  Outer IP Header: Source IP: 192.168.1.10, Destination IP: 192.168.1.20
  Outer UDP Header: Source Port: <随机>, Destination Port: 51820
  WireGuard Header
  Encrypted Payload: (加密后的 [内部IP包] )

1. 物理发送: 这个完整的外部 UDP 包根据主路由表，通过物理网卡 eth0 发送出去，并在其外面包上一层以太网帧头

3.3 入站流量(Host B)

3.3.1 阶段一

物理网络 -> WireGuard 解密 (Host B):

1. 物理接收: Host B 的 eth0 网卡接收到以太网帧，剥离帧头后，将外部 IP 包递交给内核

2. 内核协议栈 (Kernel Space - IP/UDP Stack): 内核 IP 模块检查 IP 头，发现协议是 UDP。UDP 模块检查目标端口是 51820 (默认)，发现 WireGuard 模块已经注册监听此端口。于是，该 UDP 包的 Payload 被 直接递交给 WireGuard 模块处理

3. WireGuard 核心处理 (wg_packet_receive):

• WireGuard 模块接收到数据。它读取 WireGuard 头部，识别出这是来自 Peer A 的数据包
• 内核态解密与验证: 模块使用与 Peer A 关联的对称会话密钥进行解密，并用 Poly1305 验证数据的完整性和真实性
• 解密成功，内部 IP 数据包被还原

3.3.2 阶段二

ACL 校验 -> 内核协议栈 -> 用户空间 (Host B)

1. ACL 校验:

• WireGuard 模块会检查还原后的内部 IP 包的源地址 10.0.0.1
• 核对 Peer A 的配置，确认 10.0.0.1 是否在其 AllowedIPs (10.0.0.1/32) 范围内
• 匹配成功，数据包被接受。如果不匹配，数据包将被静默丢弃

2. 重新注入协议栈:

• 通过验证的内部 IP 包通过 netif_rx()（或 gro_receive()）函数会被注入到 wg0 虚拟接口的接收队列
• 对于内核的其他部分来说，这个过程是透明的。它看起来就像 wg0 网卡“凭空”收到了一个源地址为 10.0.0.1 的普通 IP包。

3. 内核协议栈处理:

• 内核的 IP/TCP 栈开始处理这个“新”收到的 IP 包。它看到目标是 10.0.0.2:80
• TCP 模块处理 TCP 协议状态机。
• 内核发现 Nginx 进程正在监听此端口，于是将 HTTP GET 请求数据从内核缓冲区拷贝到 Nginx 进程的用户空间缓冲区，并唤醒 Nginx 工作进程

4. 应用层: Nginx 收到 HTTP 请求，开始处理并准备 HTTP 响应

3.4 返回流量（Host B）

流量返回的流程路径与上述完全对称，只是源和目的颠倒，这里快速描述一下：

1. Host B (Nginx): 生成 HTTP 200 OK 响应。
2. Host B (Kernel): 创建 内部 IP 包: [IP_H(src=10.0.0.2, dst=10.0.0.1)][TCP_H(data=HTTP Response)]。
3. Host B (Routing): 路由决策指向 wg0 接口。
4. Host B (WireGuard): wg_xmit 触发，根据目标 10.0.0.1 找到 Peer A，加密整个内部 IP 包。
5. Host B (Encapsulation): 封装成 外部 UDP 包: [IP_H(src=192.168.1.20, dst=192.168.1.10)][UDP_H][...]。
6. Host B (Egress): 通过 eth0 发送。
7. Host A (Ingress & Decryption): eth0 收到 UDP 包，递交 WireGuard 模块解密，还原出内部 IP 包。
8. Host A (ACL & Re-injection): 校验源 IP 10.0.0.2 是否在 Peer B 的 AllowedIPs 内，校验通过后，将包注入 wg0。
9. Host A (Kernel & Userspace): 内核 TCP/IP 栈处理响应包，将数据交给 curl 进程。
10. Host A (curl): curl 收到完整的 HTTP 响应，将其打印到标准输出，流程结束。

4. 适用场景

4.1 核心适用场景

• 将分散的设备（服务器、电脑、IoT设备）连接成一个逻辑上统一的私有网络
• 在不可信的物理网络（公共互联网、公有云）之上创建一个可信私有网络平面
• 对网络访问进行强身份认证（基于密钥），而不是弱认证（基于IP地址）

4.2 不建议使用场景

以下场景虽然都有解决（妥协）方案，但是仍然强烈不建议去使用 WireGuard，没有必要为了使用而使用。

1. 需要动态路由协议: WireGuard 本身是静态的点对点隧道，不广播路由信息
   • 解决方案: 结合 BGP 守护进程 (如 BIRD, FRR)。让 BGP 在 WireGuard 隧道之上运行，动态交换路由，构建复杂的大规模网络。
2. 网络环境只允许 TCP: WireGuard 只使用 UDP，在某些严格限制或 UDP 丢包率极高的网络中可能无法工作
   • 解决方案: 使用 OpenVPN over TCP 作为备选，或使用 udp2raw 等工具将 UDP 流量伪装成 TCP
3. 需要二层(L2)隧道: WireGuard 工作在三层(L3)，无法传输 ARP、DHCP 等二层广播流量
   • 解决方案: 使用 VXLAN over WireGuard 或 GRE over WireGuard 的组合，先用 L2协议封装，再用 WireGuard 加密传输

5. 快速配置

WireGuard 各节点配置条目基本都一样，这里仅以两个节点互联(全连接)为例说明。

5.1 安装命令行工具（所有组网节点）

1
2
3
4
5
6

# Ubuntu
apt update && apt install wireguard

# RHEL
dnf install epel-release -y
dnf install wireguard-tools

5.2 生成密钥（所有组网节点）

1
2
3
4

cd /etc/wireguard
wg genkey | tee privatekey | wg pubkey > publickey
chmod 600 privatekey
chmod 600 publickey

5.3 节点 A

/etc/wireguard/wg0.conf 详解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

[Interface]
# 本端私钥
PrivateKey = xxxxxxxxxxxx
# 本端在组网中的IP地址
Address = 10.66.66.1/24
# 监听UDP端口，每个节点都建议配置上
ListenPort = 51820
# 统一设置 MTU
MTU = 1420

[Peer]
# 对端的公钥
PublicKey = xxxxxxxxxxxx
# 对端的公网IP和端口
Endpoint = hostB.ip:51820
# 对端的组网中的IP地址，也可以用掩码写一个网段
AllowedIPs = 10.66.66.0/24
# 保持连接，25秒发一次心跳，最佳建议值
PersistentKeepalive = 25

5.4 节点 B

/etc/wireguard/wg0.conf 和节点 A 配置文件基本一致：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

[Interface]
# 本端私钥
PrivateKey = xxxxxxxxxxxxx
# 本端在组网中的IP地址
Address = 10.66.66.2/24
# 监听UDP端口，每个节点都建议配置上
ListenPort = 51820
# 统一设置 MTU
MTU = 1420

[Peer]
# 对端的公钥
PublicKey = xxxxxxxxxxxx
# 对端的公网IP和端口
Endpoint = hostA.ip:51820
# 对端的组网中的IP地址，也可以用掩码写一个网段
AllowedIPs = 10.66.66.0/24
# 保持连接，25秒发一次心跳，最佳建议值
PersistentKeepalive = 25

5.5 启动并验证

1
2
3
4
5
6
7
8
9

# 启动并设置开机自启
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0

# 查看状态
sudo wg show
# 验证网络
ping 10.66.66.1
ping 10.66.66.2

6. 注意事项

6.1 MTU/MSS 配置

问题: WireGuard 会增加约60-80字节的头部开销。不调整 MTU，可能会存在大数据包通过隧道时被分片影响性能或者直接被丢弃
解决方案:
1、调整 MTU： 在 wg 接口上设置 MTU = 物理接口MTU - 80。例如，物理接口 eth0 MTU 为1500，则 wg0 接口 MTU 应设为1420
2、MSS 钳制： MTU= MSS + TCP头部 (20字节) + IP头部 (20字节),MSS钳制的核心思想是在TCP三次握手的过程中，修改双方通告的MSS值，强制它们使用一个更小的MSS，从而确保后续生成的TCP数据包加上IP和TCP头部后，不会超过我们设定的隧道MTU。在防火墙 PostUp 规则中添加 MSS 钳制规则

1
2
3
4
5

# wg0.conf
[Interface]
MTU = 1420
PostUp = iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o %i -j TCPMSS --set-mss 1380
PostDown = iptables -t mangle -D FORWARD -p tcp --tcp-flags SYN,RST SYN -o %i -j TCPMSS --set-mss 1380

6.2 NAT与防火墙穿透

• ListenPort: 确保服务端防火墙放行该UDP端口
• PersistentKeepalive: 在客户端或位于NAT后的Peer上设置（如20秒），定期发送“心跳包”，以保持NAT会话和状态防火墙的连接跟踪条目活跃

6.3 密钥安全管理

• 在任何环境/程序中私钥都是唯一身份凭证，绝不可泄露
• 建立密钥轮换制度，例如每6-12个月更换一次密钥对

6.4 路由与DNS泄漏

• 路由黑洞: AllowedIPs 配置必须精确，错误的配置会导致流量无法路由或被丢弃
• DNS泄漏: 当客户端 AllowedIPs 设为 0.0.0.0/0, ::/0 以接管所有流量时，必须确保客户端的DNS解析器也指向隧道内的DNS服务器（例如，通过 wg-quick 的 DNS 配置项），否则DNS查询将绕过隧道，存在暴露隐私的安全风险

7. 进阶优化

以下优化为可选项，对大部分的普通 VPS/家里云 玩家来说性能提升不大，但是在高负载环境、高性能服务器之间会有明显的性能改善。

7.1 启用多队列 (Multi-Queue)

WireGuard 会为每个队列创建一个独立的加密/解密工作线程，并将其绑定到不同的 CPU 核心上，实现并行处理。 WireGuard 原生支持多队列，可将数据包处理压力分散到多个CPU核心，配置方法如下：

1
2
3
4

# 查看当前接口支持的最大队列数
ethtool -l wg0
# 将wg0的收发队列设置为4个 (假设CPU有4核以上)
sudo ethtool -L wg0 combined 4 

7.2 调整内核网络缓冲区

7.2-7.4 这部分是 linux 内核的调优项目不仅仅是针对 WireGuard 的使用。
在高吞吐量场景下， linux 内核默认的 socket 缓冲区可能成为瓶颈,增大 TCP/UDP 的读写缓冲区上限，允许 WireGuard 在处理突发流量时有更多的缓冲空间，减少丢包风险

1
2
3
4
5

# /etc/sysctl.conf
net.core.rmem_max = 20971520 # 20MB
net.core.wmem_max = 20971520
# 生效
sysctl -p

7.3 设置中断亲和性 (IRQ Affinity)

将数据包接收(eth0)和加解密(wg0)分别固定在不同的 CPU 核心上，最大化地利用 CPU 缓存，减少跨核调度开销，避免资源争抢。同时建议将处理网卡中断和处理 WireGuard 加解密任务的CPU核心绑定在同一个NUMA节点上，以避免跨节点内存访问带来的延迟

1
2
3
4
5
6
7

# 1. 查找wg和eth0的中断号(IRQ)
cat /proc/interrupts | grep -E 'wg|eth0'
# 2. 假设eth0的队列中断号为30-33, wg0的为34-37
# 绑定eth0的队列到CPU 0-3
for i in {0..3}; do echo $i > /proc/irq/$((30+i))/smp_affinity_list; done
# 绑定wg0的队列到CPU 4-7
for i in {0..3}; do echo $((4+i)) > /proc/irq/$((34+i))/smp_affinity_list; done

7.4 开启 GRO/GSO (通用接收/发送卸载)

GSO 允许 WireGuard 在加密前将多个小包聚合成一个大包；GRO 则是在物理网卡层面将收到的多个相关小包聚合成大包再交给上层处理。这能极大减少内核处理数据包的次数，降低 CPU 负载

1
2
3

# 一般默认是开启的，使用以下命令可以确认
ethtool -k eth0 | grep 'generic-receive-offload'
ethtool -k wg0 | grep 'generic-send-offload'

1. containerd 简介

1.1 Kubernetes CRI 与 containerd

在早期的 K8s 版本中，kubelet 组件直接与 Docker Daemon 交互来管理容器。但社区考虑扩展性为了使 K8s 能够支更多样的容器运行时（如 rkt, Kata Containers），社区推出了容器运行时接口(Container Runtime Interface, 即CRI)。CRI 是一套标准的、基于 gRPC 的 API 规范，它解耦了 kubelet 与具体容器运行时之间的强依赖关系。

containerd 正是 CRI 规范的一种标准实现工具。经过近两年发展 kubelet 已经不再与 Docker Daemon 对话，而是通过 CRI 接口，向 containerd 发出指令，如“拉取这个镜像”、“创建 Pod 沙箱”、“启动容器”等。

工作流程如下：

从图中可见，当 K8s 需要部署一个 Pod 时：

1. kubelet 接收到指令，分析 Pod 定义中所需的容器镜像
2. kubelet 通过 CRI 的 PullImage RPC 调用，请求 containerd 确保该镜像存在于本地
3. containerd 检查本地镜像存储。如果镜像不存在，它将负责根据自身的配置从远程镜像仓库拉取镜像

这里的关键点在于，执行镜像拉取操作的直接负责人是 containerd，因此，加速配置必须在 containerd 层面进行，才能对 K8s 集群生效。

1.2 需要加速的镜像

• registry.k8s.io: K8s 官方镜像仓库，存放着 k8s 核心组件的容器镜像
• docker.io: 全球最大的公共镜像中心，平时使用到的大部分容器镜像都存在里面
• gcr.io: Google 镜像仓库，存放 Google 相关的一些容器镜像
• quay.io: RedHat 运营的镜像仓库，也有许多核心开源项目的镜像存在里面
• ghcr.io: GitHub 运营的镜像仓库，有很多开源项目的镜像也会选择存放在里面

在国内节点部署、使用 k8s 的时候，前面两个镜像必须要配置加速，否则必然是会镜像拉取失败的，剩下几个按需配置即可。

2. 配置解析

认识一下这个看着比 Docker 麻烦很多的配置文件。

2.1 config.toml 的结构

containerd 的主配置文件位于 /etc/containerd/config.toml，采用 TOML 格式。TOML 格式具有清晰的层级结构和良好的可读性，现在在云原生项目中出现的频率确实是明显多了很多！

containerd 配置文件的整体架构是 “插件化” 形式, 文件里面也是众多插件的配置条目。CRI 服务本身也是其众多插件中的一个，其官方名称为 io.containerd.grpc.v1.cri。因此所有与 CRI 相关的配置，都必须放置在这个插件的命名空间下。

具体来看下这个配置项：

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]

• [plugins."..."]：表示这是一个插件配置区块
• "io.containerd.grpc.v1.cri"：指定了配置的目标是 CRI 插件。
• .registry：表示我们正在配置该插件的 registry（镜像仓库）相关功能
• .mirrors：进一步指定是配置镜像的 mirrors（这里即是我们的镜像加速器）
• ."docker.io"：明确了此配置块只针对 docker.io 这个上游仓库生效

官方背书： 每个配置项都拥有唯一的、不会产生冲突的路径、具有清晰的配置导向，也为未来新增更多功能插件而不会破坏现有结构提供了保障
在我看来： 真是挺麻烦的！

2.2 进一步分析

关键配置区块:

1
2

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
  endpoint = ["https://mirror1.com", "https://mirror2.com"]

简单搂一眼这个部分源码，该配置对应的源码定义在 containerd/pkg/cri/apis/config/config.go 中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Registry is registry settings "plugins.cri.registry"
type Registry struct {
    // ... 省略 ...
Mirrors map[string]Mirror `toml:"mirrors"`
}

// Mirror contains the configuration for a registry mirror.
type Mirror struct {
// Endpoint specifies the endpoints of a mirror. The scheme part is optional.
// When the scheme is not specified, "https://"" is used.
// The endpoint will be tried in order.
Endpoint []string `toml:"endpoint"`
    // ... 省略 ...
}

从源码中我们可以得到几个关键信息：

1. Mirrors 是一个 map[string]Mirror 类型：key（即 "docker.io"）是原始仓库地址，value 是 Mirror 结构体。从这里可以看出我们可以为不同仓库配置不同加速镜像源
2. Endpoint 是一个 []string 类型（字符串切片）： 这表明 containerd 原生即支持配置多个 endpoint
3. 源码注释明确指出 “The endpoint will be tried in order.”： containerd 会按照数组中定义的顺序，依次尝试连接 endpoint 来拉取镜像。一旦其中一个成功，它就会停止尝试并开始下载。

3. 快速配置

上面都是顺带简单了解下 containerd 的内容，现在回到镜像加速源具体配置方法

3.1 生成默认配置

1
2
3
4

mkdir -p /etc/containerd

# 生成默认配置文件
containerd config default | sudo tee /etc/containerd/config.toml

3.2 配置方法

编辑 /etc/containerd/config.toml 文件，找到 [plugins."io.containerd.grpc.v1.cri".registry.mirrors] 部分，替换补充以下内容。这是一个涵盖了绝大部分场景的推荐配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# /etc/containerd/config.toml

# 确保使用 v2 版本的配置格式
version = 2

# ... 省略其他配置 ...

[plugins."io.containerd.grpc.v1.cri".registry]
  # config_path不再是推荐的主要配置方式，直接在下面定义mirrors更清晰
  config_path = ""

  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]

    # 1. k8s 官方镜像 -- registry.k8s.io
    # 必须配置，这是K8s核心组件的来源
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry.k8s.io"]
      endpoint = ["https://k8s.m.daocloud.io"]

    # 2. DockerHub -- docker.io
    # 必须配置，绝大部分应用镜像的来源，配置多个作为冗余避免爱发电暴毙
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
      endpoint = [
        "https://docker.1ms.run",
        "https://hub-mirror.c.163.com",
        "https://mirror.baidubce.com",
        "https://docker.m.daocloud.io"
      ]

    # 3. gcr.io
    # 按需可选配置
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
      endpoint = ["gcr.proxy.ustclug.org"]

    # 4. quay.io
    # 按需可选配置
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."quay.io"]
      endpoint = ["quay.proxy.ustclug.org"]
      
    # 5. ghcr.io
    # 按需可选配置
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."ghcr.io"]
      endpoint = ["ghcr.proxy.ustclug.org"]

额外说明：

镜像源选择: 上述配置的镜像仅为个人设置且当前时间点(2024-11-06)可用的，有些镜像是爱发电的，不保证哪天会突然暴毙！如已有失效的自行更改就好

3.3 验证

修改配置后，必须重启 containerd 才能使其加载新配置

1
2

systemctl daemon-reload
systemctl restart containerd

这里注意下验证配置是否生效，不能使用 docker pull，而应该使用 crictl 工具。crictl 是一个专门用于与 CRI 兼容的容器运行时进行交互的命令行工具

1
2

# 拉取一个docker.io的镜像进行测试
crictl pull busybox

如果命令能够快速成功返回，并且没有出现网络超时错误，说明配置已正确生效

什么是 /dev/tcp 和 /dev/udp

我们都或多或少的听说过在 linux 中 “一切皆文件“，这两个便是 linux 中的特殊文件，可以通过它们使用 TCP 或 UDP 协议与外界（本机也行）进行网络通信。也就是说，我们可以直接向目标主机的指定端口发送数据，而不需要任何额外的程序。下面说明如何使用它们。

测试 TCP 端口连通性

首先，打开你的终端，输入以下命令来测试 TCP 连接：

1

echo hello > /dev/tcp/目标主机/IP/端口

举个例子，假设你想测试与 192.168.1.10 的 80 端口的连接，可以这样写：

1

echo hello > /dev/tcp/192.168.1.10/80

接下来，你可以根据返回检查连接状态：

• 如果连接成功，终端不会显示任何输出，并且状态码为 0。
• 如果连接失败，终端会给出错误信息例如 refused 或 no route to host
• 如果连接超时，终端则会一直没反应，一般超过三秒没任何动静就可以认为是 timeout 了

测试 UDP 端口连通性

UDP 的测试稍微复杂一点，因为它是无连接的协议，不能像 TCP 那样直接使用 echo 后根据返回值进行判断，即便发送后没有任何返回，这也不一定意味着连接失败。但是我们可以到目标主机上启动一个 udp 端口，然后在源端使用 /dev/udp 的方法给该端口发送数据，如果网络是正常连通的则在目标主机上可以收到源端发送的数据。
比如，在源端使用：

1

echo "hello world" > /dev/udp/192.168.1.30/4888

那么在网络连通的情况下，目标主机 192.168.1.30 的 4888 端口是可以收到源端发送的字符 hello world 的！

/boot 文件夹下除了 grub2 目录之外其他文件均可由 kernel-3.10.0-xxx 安装后生成。

1.首先生成系统启动所需 vmlinux 和 initramfs

挂镜像进 troubleshoot - rescue system - 1 - shell

cp /run/install/repo/Packages/kernel-3.10.0-xxx.rpm /mnt/sysimage/boot
chroot /mnt/sysimage
rpm -ivh kernel-3.10.0-xxx.rpm –force

2.生成 grub 引导

生成/boot/grub2 相关目录:
grub2-install /dev/sda

生成引导配置文件：
grub2-mkconfig -o /boot/grub2/grub.cfg

3.设置引导选项

1

awk -F\' '$1=="menuentry " {print $2}' /etc/grub2.cfg

grub2-set-default “xxx”
grub2-editenv list

1

iptables -t nat -A PREROUTING -p tcp -s 123.60.99.6 --dport 22 -j REDIRECT --to-port 48763

将源地址访问 22 端口的流量重定向到 48763 不影响其他端口，可以避免不安全的 ssh 端口访问，亦或实现蒙混安全漏洞扫描的目的。

脚本 sudo_access.sh 如下

1
2
3
4
5
6
7
8
9
10
11
12
13

#!/bin/bash

# 获取当前日期的日
day=$(date +%d)

# 检查当前日期是否在26-28之间
if [[ $day -ge 26 && $day -le 28 ]]; then
    # 赋予sudo权限
    echo "<用户名> ALL=(ALL) ALL" >> /etc/sudoers.d/sudo_access
else
    # 回收sudo权限
    sed -i "/<用户名> ALL=(ALL) ALL/d" /etc/sudoers.d/sudo_access
fi

添加定时任务每日检查

1
2
3

sudo mv sudo_access.sh /etc/cron.daily/

sudo chmod +x /etc/cron.daily/sudo_access.sh

sudo权限绕过(CVE-2019-14287)

Sudo 中存在权限绕过漏洞，当 sudo 配置为允许用户通过 Runas 规范中定义的 ALL 关键字来以任意用户身份运行命令的话，那么攻击者将有可能通过制定用户 ID -1 或 4294967295 来以 root 权限执行恶意命令。这可以允许具有足够 sudo 特权的用户以 root 身份运行命令，即使 Runas 规范明确禁止 root 访问。

缓冲区溢出漏洞(CVE-2021-3156)

Sudo 存在缓存区溢出漏洞，该漏洞由于 Sudo 错误地在参数中转义了反斜杠导致堆缓冲区溢出，允许攻击者通过 sudoedit -s 和以单个反斜杠字符结尾的命令行参数将权限提升为 root。并非所有存在漏洞的 Sudo 版本都能利用成功，glibc>=2.27 只能说明漏洞利用难度较小，低版本的 glibc 也能利用成功，只是漏洞利用难度增加。

解决办法

升级 sudo 版本
以下升级版本包仅针对 rhel7 版本

CVE-2019-14287

1
2
3
4
5

sudo-1.8.23-4.el7_7.1.x86_64.rpm           SHA-256: 7d831c2183201785fe11fbc353f123776bf2e24af76b26716c7b8a6c47f431cd

sudo-debuginfo-1.8.23-4.el7_7.1.x86_64.rpm SHA-256: d98c0d8b596984c38c11e6d0c80693d4631dc0623a1a60cc902821e066a23f03

sudo-devel-1.8.23-4.el7_7.1.x86_64.rpm     SHA-256: 6029de2bd54377f059af74a5367eec5b195a9454c7c6c8c31731dab43ac7b86d

CVE-2021-3156

1
2
3
4
5

sudo-1.8.23-10.el7_9.1.x86_64.rpm             SHA-256: ce4dcf37c40b87c206d7b936811e6f62d7432082dbe15cf513b74c372504b6e5

sudo-debuginfo-1.8.23-10.el7_9.1.x86_64.rpm   SHA-256: 561fa8a3eb3ba59bbaf31b9454031dfa65418bf9de50102b3659c7f70c6b3356

sudo-devel-1.8.23-10.el7_9.1.x86_64.rpm       SHA-256: 9a26b6ccfc6b67d94130bf699835b5a056b346a8c51ba33a47f09d4907dc59c1

综合以上，rhel7 应升级 sudo 版本至 sudo-1.8.23-10.el7_9.1.x86_64.rpm

1

[[rpm包下载]]

风险级别

高危

责任归属

系统管理员

加固风险

低风险操作，无需重启服务，只可能影响配置了 sudo 权限的用户使用 sudo

链接

CVE-2019-14287- Red Hat Customer Portal

polkit 是一个在类 Unix 操作系统中控制系统范围权限的组件。通过定义和审核权限规则，实现不同优先级进程间的通讯。
polkit 存在本地权限提升漏洞，由于 pkexec 无法正确处理调用参数计数，攻击者可利用该漏洞通过精心设计环境变量诱导 pkexec 执行任意代码，具有低权限的攻击者可以利用此漏洞绕过 pkexec 自带的安全保护措施，获取目标机器的 ROOT 权限。

解决办法

• 根据官方修复建议升级 polkit 版本

1
2
3
4
5
6
7

polkit-0.112-26.el7_9.1.x86_64.rpm            SHA-256: 7f4cd400e1cf20c30290641befa5a900fe425070e9573866f242f9acc3bda048

polkit-debuginfo-0.112-26.el7_9.1.x86_64.rpm  SHA-256: aa3d5197c9cd4598c7162fb1a5df04437552acfc02fe14143ce8e8132f807df0

polkit-devel-0.112-26.el7_9.1.x86_64.rpm      SHA-256: 1c5179227026b66d92fbfe14b35449db482e70b2cc64906a01d57882124c44bc

polkit-docs-0.112-26.el7_9.1.noarch.rpm       SHA-256: 6a8da2909d06acc1763fcacb82068442425b3a87f13295469670897327fb5944

1

[[rpm包下载]]

风险级别

高风险

责任归属

系统管理员

加固风险

低风险操作，无需重启服务

链接

CVE-2021-4034- Red Hat Customer Portal
RHEL-7-polkit修复链接

OpenSSH（OpenBSD Secure Shell）是 OpenBSD 计划组所维护的一套用于安全访问远程计算机的连接工具。该工具是 SSH 协议的开源实现，支持对所有的传输进行加密，可有效阻止窃听、连接劫持以及其他网络级的攻击。 OpenSSH 7.7 及之前版本中存在用户枚举漏洞，该漏洞源于程序会对有效的和无效的用户身份验证请求发出不同的响应。攻击者可通过发送特制的请求利用该漏洞枚举用户名称。

解决办法

厂商补丁：
应用如下补丁可以修复此漏洞，需要重新编译
https://github.com/openbsd/src/commit/779974d35b4859c07bc3cb8a12c74b43b0a7d1e0
OpenSSH
新版本OpenSSH-7.8已经修复这个安全问题，请到厂商的主页下载：
链接：
http://www.openssh.com/
http://www.openssh.com/portable.html

[!info]+ 提示
一般都直接连带编译升级 openssh 和 openssl 到最新版

风险级别

中风险

责任归属

系统管理员

加固风险

中风险，如无 saltstack 和管理控制台等界面加固失败会导致无法登录机器；
升级 openssh 可能会导致客户端使用低版本 jsch 连接服务端报错；
升级 openssh 可能会导致 sftp 无法使用;
由于需要连带升级 openssl 可能会在升级失败的情况下造成 openssl 故障无法使用。

链接

CVE-2018-15473
CVE-2018-15473- Red Hat Customer Portal

详细方案

[!info]+ 提示
使用 shell 脚本升级到最新版本 openssh 及其对应版本的 openssl
当前以最新版 openssh9.0 和 openssl1.1.1o 为例
在漏洞机器上执行升级脚本（前提升级需要的 openssh 和 openssl 源码包已经放到指定位置）

[[openssh9.0升级脚本]]

可以对目标主机进行”showmount -e”操作，此操作将泄露目标主机大量敏感信息，比如目录结构。更糟糕的是，如果访问控制不严的话，攻击者有可能直接访问到目标主机上的数据。

解决办法

• 限制可以获取 NFS 输出列表的 IP 和用户。
• 除非绝对必要，请关闭NFS服务、MOUNTD。

风险级别

高风险

责任归属

系统管理员

加固风险

低风险操作，无需重启服务，只影响 showmout -e 查询服务端共享目录并不会影响 nfs 服务正常挂载和使用

链接

CVE - CVE-1999-0554 (mitre.org)

详细方案

1. 配置文件限制

对 NFS 共享服务器的 /etc/hosts.allow 和 /etc/hosts.deny 进行配置
由于各系统版本的 nfs mount 服务不同，所以分为以下三种配置方式：

1.1 centos7

1
2
3
4
5

vim /etc/hosts.allow
mountd:134.64.   # 允许134.64.x.x 网段访问mountd服务，如果是mountd:134.则为允许134.x.x.x访问mountd服务，多个ip可用逗号隔开

vim /etc/hosts.deny
mountd:all

1.2 centos6

1
2
3
4
5

vim /etc/hosts.allow
rpcbind: 134.:allow

vim /etc/hosts.deny
rpcbind:ALL:deny

1.3 centos5

1
2
3
4
5

vim /etc/hosts.allow
Portmap:134.:allow

vim /etc/hosts.deny
Portmap:ALL:deny

2 iptables 限制

使用 iptables 白名单对 nfs 服务端口（默认 111, 2049）进行限制。

end

[!info]+ 提示
推荐使用第一种方法，无业务影响无需更改防火墙配置

[!example] 环境
操作系统： RedHat6.5
GLIBC： 2.17
RedHat6.5 默认 glibc 版本为 2.12，需要本地编译安装升级至 2.17 版本。

1.下载离线包

glibc-2.17.tar.gz

2.编译安装

1
2
3
4
5
6
7
8
9

tar xzf glibc-2.17.tar.gz
cd glibc-2.17
# 必须要新建目录进行 configure
mkdir build
cd build
# 下面路径不要修改
../configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
make -j20
make install

3.验证

1

strings /lib64/libc.so.6 | grep GLIBC

完成

[!danger] libc 故障补救措施

错误一： 其他方法覆盖了 libc.so.6 这个软链接导致系统指令不可用
错误信息： ls: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument

适用于仅覆盖了软链接的场景：
ln -sf /usr/local/glibc-2.17/lib/lib-2.17.so /lib64/libc.so.6

恢复方法：

1
2

export LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib64:/usr/local/glibc-2.17
ldconfig

[!danger] 升级后 locale 报 warnning
错误信息：warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory

恢复方法：

1
2
3
4
5
6
7

ls -l /lib64/libc.so.6
# 上条命令可以查看到指向的glibc具体版本
strings /lib64/glibc-2.17.so | grep locale-archive
# 上条命令可以看到locale-archive的目录
ln -s /usr/lib/locale/locale-archive /usr/local/glibc-2.14/lib/locale/locale-archive
# 上条命令重新建立locale链接
此时locale应已恢复正常