接 Part4，终于要开始准备搭一个能用的 VPN 服务器了。另外，如果你要拿这个配置去翻墙请自便，但是不对实际效果做任何保证，本文只考虑传统的 VPN 使用场景。

基本上，服务端的配置和 Part4 中的一致，这里着重介绍如何配置客户端。配置使用 Play Store 上的 strongSwan客户端，版本为 2.3.1。

服务器配置

首先，这个客户端似乎还不支持 ed25519 证书，因此我们需要改为使用 ecdsa 证书。完整的证书生成操作请看 Part2，在生成私钥时指定--key-type ecdsa即可。现在假设你已经生成好了所有 6 个文件：ca-key.pem,ca-cert.pem,client-key.pem,client-cert.pem,server-key.pem,server-cert.pem。

另外，这次我们会在服务器上配置 NAT，所以不再需要手动在服务端配置一个 IP 了。假设服务端eth0接口的公网 IP 是2000::1。首先将ca-cert.pem,server-key.pem,server-cert.pem三个文件移动到服务器上正确的地方。然后编写配置文件，同样的，这里只注释和 Part4 中不同的地方。

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

connections {
  android-connection {
    version = 2
    # 服务器的地址。根据官方文档，服务器内核版本需要大于等于 5.8
    # 才能支持 Android 客户端使用 IPv6 地址连接
    local_addrs = 2000::1
    # 接受客户端来自任何地方
    remote_addrs = %any
    proposals = aes256gcm128-sha512-x25519
    # 只分配 IPv4 的虚拟 IP
    pools = ip4pool
    local {
      # 请按照实际情况修改 id
      id = CN=server common name
      auth = pubkey
    }
    remote {
      id = %any
      auth = pubkey
    }
    children {
      child_sa {
        # 允许客户端将去往所有目的地的流量发送给服务端
        local_ts = 0.0.0.0/0
        remote_ts = dynamic
        mode = tunnel
        esp_proposals = aes256gcm128-sha512-x25519
      }
    }
  }
}

pools {
  # 只保留 IPv4 池
  ip4pool {
    addrs = 10.10.10.100-10.10.10.150
  }
}

配置完毕后systemctl restart strongswan。

客户端配置

在客户端上，我决定创建一个可以直接导入的 Profile 文件，避免手工输入一大堆地址（要记得我在用 IPv6）。首先需要把 client-key.pem 和 client-cert.pem 合并成一个文件，注意 bash 本身是不支持多行命令和注释穿插写的，在执行的时候需要手动移除注释：

1
2
3
4
5
6
7
8
9
10
11

certtool \
    --load-privkey client-key.pem \
    --load-certificate client-cert.pem \
    # 名称随意
    --p12-name "Key Cert Bundle" \
    # 空密码
    --empty-password \
    # 合并成 PKCS12 格式
    --to-p12 \
    # 需要指定 3des-pkcs12，否则 Android 系统无法正确导入
    --pkcs-cipher 3des-pkcs12 > client-p12bundle.pem

新生成的文件是client-p12bundle.pem。然后我们参照 strongSwan 的文档创建可以直接导入应用的 Profile 文件。当然你也可以手动导入证书再手动配置 Profile。

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

jq -n \
    # 生成一个随机的 UUID
    --arg uuid `uuidgen -r` \
    # Profile 的名称，可以随意写
    --arg name "My server"\
    # 认证类型
    --arg type "ikev2-cert"\
    # 需要手动指定 remote id，否则服务器的地址将被当作 id，导致认证失败
    # 当然你也可以在创建证书的时候就把服务器地址写在证书里，避免手工指定 DN
    # 注意：id 和服务器地址和证书有复杂的检验关系，填写不当容易造成各种奇怪的
    #      身份验证错误。
    --arg remoteid "CN=server common name"\
    # 服务器的地址，我这里使用 2000::1 代替了实际地址，使用 IPv4 和域名也是可以的。
    --arg addr "2000::1"\
    # 嵌入服务器证书，注意这里我直接嵌了服务器本身的证书。嵌 CA 证书应该也是
    # 可行的，但是我没试。
    --arg servercert "`sed '/-----/d' server-cert.pem`"\
    # 嵌入客户端私钥和证书
    --arg localbundle "`sed '/-----/d' client-p12bundle.pem`"\
    '{
        uuid:$uuid,
        name:$name,
        type:$type,
        remote:{
            id:$remoteid,
            addr:$addr,
            cert:$servercert
        },
        local: {
            p12:$localbundle
        },
        "ipv6-transport": true
    }' > profile.sswan
    # 根据官方文档，服务器内核版本需要大于等于 5.8 才能支持客户端使用 IPv6 地址
    # 连接。同时需要设定 ipv6-transport 为 true。如果你使用 IPv4 则不需要此设置。
    # 另外这里没有指定 local.id，根据文档，在没有指定 local.id 的情况下，客户端程序
    # 会自动使用客户端证书的 DN 作为 id

最后将生成的profile.sswan文件拷贝到手机上并导入即可。然后试一下能否成功建立连接。

NAT 配置

然后这样配置完了，虽然能连上服务器，但是依然不能访问网络，我们还需要在服务器上配置一下 NAT。一般是一条防火墙的masquerade规则。这里只简单把配置放出来给自己做个备忘，不做细讲：

1
2
3
4
5
6
7
8
9
10

table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }

  chain postrouting {
    type nat hook postrouting priority 100;
    ip saddr 10.10.10.0/24 meta oifname eth0 masquerade
  }
}

记录一下使用到的端口以及需要做的防火墙配置，不一定能覆盖所有场景，如果有漏掉的规则欢迎留言补充。

TL;DR 在两端均放行：

• UDP 500
• UDP 4500
• ESP 协议

第四篇主要讲一下怎么给客户端下发内网 IP ~
Part1 传送门；Part2 传送门；Part3 传送门

Virtual IP (VIP)

接 Part3，有了 Tunnel 模式以后我们实际使用的 IP 地址就不用受制于机器的实际 IP 了。但是手动给每个客户端手动分配一个地址显然是不切实际的。于是我们可以使用 Virtual IP 功能自动向连入的客户端分配一个内网 IP，就像 DHCP 或者 SLAAC 那样。

场景配置

与之前完全对称的配置不同，使用 Virtual IP 时需要区分服务端和客户端。先在服务端配置将要分配的 IP，然后由客户端发起连接，服务端就会将配置好的 IP 分发出去。我使用 HostA 作为服务端，HostB 作为客户端。HostA 将会给 HostB 分配 IPv4 与 IPv6 各一个。使用的 Virtual IP 段是fd01::100-fd01::200和10.10.10.100-10.10.10.150。

hosta$ ip -br addr
eth1         UP             fd00::1/64 fd01::1/128 10.10.10.1/32

hostb$ ip -br addr
eth1         UP             fd00::2/64

和 Part3 相比，HostA 这里有一些与之前不同的地方，一是内部 IP 全部放在了 eth1 上（而不是 lo 上）；二是内部 IP 的前缀长度都是最大值；三是增加了一个 IPv4 的内部 IP，用于和分配的 IPv4 Virtual IP 通信。同时 HostB 也不再手工分配fd01开头的内部 IP 了，将由 strongSwan 自动配置。

当连接建立后，我们应该能看到在 HostB 的 eth1 上出现两个新的，自动分配的 IP。且分配到的 IPv4 地址与 10.10.10.1 之间的通信是加密的，分配到的 IPv6 地址与 fd01::1 之间的通信是加密的。

三星的新 SSD 980 Pro 已经发售一段时间了，前两天看到 Amazon 上 1TB 有货，赶紧下单两条。今天到货，于是装机测一波速度。打算用来做系统盘，所以自然就是用来组 RAID-0 咯。于是用 fio 分别测试了一下 btrfs 和 mdadm 组 RAID 的性能。测试完全不严谨，参数是用脸滚键盘滚出来的，放出来仅供各位一乐，为什么是娱乐向你看数据就知道了。同时拉上了打酱油的 960 Evo（我现在的系统盘），以及完全是搞笑用的/dev/shm：

Emmmm, mdadm RAID0 比内存快……这很合理……以及 btrfs 你的 RAID 性能还能更烂一点吗？

第三篇简单介绍一下 IPsec 的 Tunnel 模式，没看过前两篇的快去看~
Part1 传送门；Part2 传送门

Tunnel 模式简介

前两篇中我们使用的都是 Transport 模式，但是实际使用中，更常用的是 Tunnel 模式。Transport 模式只加密四层及以上数据，而不修改 IP 头，原始的 IP 头将会原样传输。这意味着我们只能进行点对点传输，因为只有一个 IP 头，我们无法告知对方服务器我们实际要访问的地址。Tunnel 模式则是连原始的 IP 头也一起加密，然后再在前端添加一个新的 IP 头，这样服务器在收到数据包后，可以解密并读取内部的 IP 头，再转发给实际的目标服务器。

作为系列的第二篇文章，讲解基本的证书原理和配置方法。没看过第一部分的快去看～
传送门：IPsec 配置备忘 Part1。

证书认证基础

我们在 Part1 中看到，PSK 认证的基本思路是使用一个只有通信双方才知道的暗号，如果能确认对方确实知道这个暗号，那么认证就成功了。证书认证的思路非常不同：假设 A 需要向 B 证明自己的身份，同时 A 知道 B 信任 C，那么 A 可以向 C 索取一份“介绍信”，当 B 询问 A 的身份时，A 可以向 B 展示这份 C 出具的“介绍信”，如果 B 能够确认这份“介绍信”确实是由 C 出具的，那么认证就成功了。注意这个认证是单向的，假设 A 也信任 C，那么 B 也可以通过向 C 索取“介绍信”来向 A 证明自己的身份。在 PKI 体系中，A 和 B 持有各自的“私钥”，C 作为 Certificate Authority (CA) 向 A/B 颁发证书（即“介绍信”）。同时，CA 也会向自己颁发一份证书并分发给 A/B，A/B 使用 CA 的证书来确认 B/A 出示的证书确实为 C 所颁发。

俗话说得好，配置 IPsec 隧道只有零次和无数次，在被 strongSwan 折磨了 N 次以后，我终于决定要把之前试过的配置都记录下来，于是就有了这个系列。我计划基本上每个 PART 会介绍一个（或几个）特定场景下的配置，配置文件样例以 strongSwan vici 为主，之后可能会介绍 iOS, Android 或者是 Mikrotik 路由器的配置方法，如果我能坚持不鸽写到那里的话（画外音：你这 FLAG 立得……） FLAG 回收了。如果各位有想看的配置场景欢迎留言告诉我，会考虑先写。

IKEv2 与 IPsec 基础

严格来说 IKEv2 不是 VPN，它的全称是 Internet Key Exchange，只是一种用于交换密钥的协议罢了。密钥在计算机里一般就表示为一串固定长度的二进制数据，密钥交换就是指在两台设备之间约定一个相同的二进制串，就像两个密友之间约定暗号一样。一旦密钥交换完毕，IKE 的使命就结束了，具体怎么用约定好的密钥加密数据不是 IKE 解决的问题。在 Linux 系统上，实际的数据包加密解密是由内核的 XFRM 框架负责的，你可以使用ip xfrm命令看到配置好的密钥以及加解密使用的算法。事实上，不使用 IKEv2 而完全手动“交换”密钥是可行的，比如朴素VPN：一个纯内核级静态隧道。你可以看到作者直接使用ip xfrm {policy,state} add指令设定密钥，然后内核就会自动用设定的密钥加密流量。

然而，手动管理内核状态是复杂的，人工分发密钥也不怎么安全，这时就轮到 strongSwan 登场啦（或者说，任何实现了 IKE 的 Daemon 服务）。两台服务器的 strongSwan 使用 IKEv2 协议交换密钥，解决了密钥分发的问题。随后 strongSwan 会把交换得来的密钥设定进内核，这样内核就会自动加密指定的流量了。

从数据包层面上看，IKE 是7层协议，密钥交换使用特殊的 UDP 包完成。而一般被加密的数据包会使用 ESP 封装，ESP 头一般紧跟在 IP 头后。ESP 也可以被封装进 UDP 用以穿越 NAT。

没有 TUN 设备

内核 XFRM 的工作方式和基于 TUN 设备的 VPN 很不一样。一般基于 TUN 的 VPN 会加密所有进入 TUN 设备的流量，因此你可以直接使用路由表来控制哪些流量走 VPN，哪些不走。而 XFRM 的匹配基于策略（i.e. 源地址+目标地址+一些别的），如果某个数据包匹配到了一个策略，这个数据包就会根据这个策略指定的方式被加密。

比方说有A [fd00::1]和B [fd00::2]，如果你从 A 发送一个数据包到 B，普通情况下这个数据包是明文的。如果你在 A 配置了src=fd00::1,dst=fd00::2,encrypt=<...>的策略并再发一个数据包，这个包就会自动被加密。B 收到了这个数据包，但是它并不知道该如何解密，所以你必须同时在 B 配置一条src=fd00::1,dst=fd00::2,decrypt=<...>的策略，这样 B 才能解密。对于从 B 到 A 的流量也需要类似的两条策略。使用 IKEv2 的话，这些策略 strongSwan 都会自动帮你设置好，无需操心。于是你会发现，尽管我们仍然在使用节点本身的 IP，但是流量却已经被加密了。

对于那些必须使用路由表或是策略匹配不是很有效的场景, Route-based IPsec VPN 也是存在的。我也许会在未来的某一期讲。