用 LUKS 加密 VPS 磁盘

加密不是什么通用的隐私开关，它只回答一个问题：没有密钥的人能不能读到这些数据块？其余的一切——谁知道你租了这台服务器、流量能不能追溯到你、法院能不能强制要求什么——都不归它管。

在 VPS 上，LUKS 能切实防住以下几种情况：

• 报废和故障的硬件。NVMe 硬盘是会被更换的。故障设备上的安全擦除并非总能做到——有时它坏得连控制器都不再接受任何指令，却照样会被拆下机架、送出机房。
• 离线镜像。在服务器关机状态下被复制的卷——无论是因为查扣、迁移，还是操作失误——本身就是密文，而且会一直是密文。
• 外流的备份和快照。只要是从你可控范围之下的块层取出的数据，离开机器时就是加密的；如果是从块层之上取出的，就应该在客户端自行加密。
• 残留数据块。销毁一台服务器后，底层存储区最终会被重新分配使用。加密让这些残留内容变成噪声，而不是数据。

它不能防住正在运行的机器。服务器开着的时候，主密钥就驻留在内核内存里，任何能够转储该内存的人，都能不管密码短语是什么直接读出你的磁盘。在租用的基础设施上，这个人就是虚拟化平台的运营方。我们在隐私声明里说过这一点，这里再重申一次：没有任何提供商的磁盘加密功能能改变这一事实，包括我们自己在内；任何声称并非如此的提供商，讲的是营销话术，不是密码学。

动手敲命令之前，先选好方案。三者所需的精力差别很大，多数人只需要第一种。

1. 加密数据卷。系统照常以未加密方式启动；只有一棵目录树——邮件目录、数据库、归档文件——放在一个 LUKS 容器里，每次启动后手动打开。只需十分钟，不用救援模式，也没有把自己锁在外面的风险。如果你在意的是某一份数据而不是整台机器，到这一步就可以停下：好处基本都拿到了，脆弱之处却几乎没有增加。这也是我们在匿名邮件服务器页面推荐的做法。

2. 加密根卷 + 远程解锁。除 /boot 之外的一切都被加密，每次启动都会在 initramfs 里暂停，直到你通过 SSH 连进去输入密码短语。本指南接下来搭建的就是这一种方案。第一次要花一个小时，之后每次重启只需一条 SSH 命令；它也是唯一一种连日志、软件包缓存、shell 历史和交换分区都覆盖到的方案——这些正是数据在没人特意决定的情况下悄悄泄露出去的地方。

3. 加密根卷 + 向你自己掌控的密钥服务器自动解锁。与方案 2 相同，只是由 Clevis 从位于另一司法辖区的 Tang 服务器获取解锁材料，因此重启无需人工值守。这里的取舍很明确，也值得弄清楚：只要你的密钥服务器点头，服务器现在就能自行解密——也就是说，你把秘密挪了个地方，而不是彻底去掉了它——但你也因此获得了一个远程“熔断开关”。后文会详细说明。

不少主机商把“静态加密”当作一个可以打勾的卖点来宣传。这个说法背后其实藏着两种截然不同的东西，值得说清楚。

密钥由服务商掌握的加密，防的只是硬盘被偷，仅此而已。如果服务商不用问你就能启动你的服务器，那它不用问你也能解密你的服务器——能强制服务商这么做的任何一方，同样可以。这种加密对盗窃是真实有效的控制，对法律程序而言却纯属摆设。

密钥由你自己掌握的加密才是真正有意义的版本，而它从原理上就注定会让无人值守的重启无法进行。这不是一个需要被设计掉的缺陷，而正是这个方案起作用的地方。

我们只提供第二种选项，并且默认不启用，交由你自己决定。我们确实持有、且写在文档里的东西范围要小得多：服务器 root 密码以 AES-256-CBC 在行级别加密存储，我们不保留流量日志或数据包记录，并按计划发布经签名的预警声明（warrant canary）。这些都替代不了你自己的密钥——它们只是我们在此期间可以被追责的部分。

默认设置已经很好，其中有两项值得手动指定。

密码算法。默认值 aes-xts-plain64 配合 512 位密钥就是正确答案——这 512 位其实是两把 256 位密钥，所以本质上是 XTS 模式下的 AES-256，而我们运行的每一颗 CPU 都带有 AES-NI。在没有 AES 硬件加速的机器上，你会更想用 xchacha20,aes-adiantum-plain64，但那不是我们的硬件，大概率也不是你的。

密钥派生。LUKS2 默认使用 Argon2id，它刻意设计成对内存要求很高。cryptsetup 会在格式化时对你的机器做基准测试，并根据它看到的内存量选定一个内存开销——这正是绝大多数“加密服务器起不来”问题的陷阱所在：initramfs 可用的内存比正在运行的系统要少，如果你是在一个内存比目标套餐更大的救援环境里格式化的这个卷，解锁时就可能失败，或者在启动过程中被杀掉。所以要显式锁定这个值。1 GiB 的 Argon2 内存开销，对攻击者来说是相当高的代价，而一台 4 GB 内存的 S1 完全负担得起：

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memory 的单位是 KiB，所以 1048576 就是 1 GiB。之后可以用 cryptsetup luksDump /dev/vda2 检查头部里实际写入的值——keyslot 部分会打印出将要使用的内存量和迭代次数，花一次时间看看，比启动失败要划算得多。

密码短语。Argon2 能为弱密码短语争取时间，却救不了它。请使用至少六个单词的 diceware 密码短语。它是整个系统里唯一的秘密，再好的密钥派生函数也弥补不了一个糟糕的密码短语。

加密根卷的 Linux 启动过程存在一个先有鸡还是先有蛋的问题：内核和 initramfs 必须先加载，之后才能有东西来向你要密码短语，而它们恰恰就放在你想要解锁的那块磁盘上。标准做法是设置一个小的未加密 /boot 分区，存放内核、initramfs 和引导程序，其余一切都放进 LUKS 里。

随后 initramfs 会暂停下来，要求输入密码短语。在笔记本电脑上，你直接打字输入即可；而在三千公里外的一台服务器上，你需要下面两者之一：

• 控制台。面板里的每台服务器都有 noVNC 控制台，它确实管用——但按键会经过我们的基础设施，而这恰恰是你的密钥本该排除在外的一方。偶尔用来救急可以，当作日常手段就不对了。
• 装在 initramfs 里的 SSH 服务器。dropbear-initramfs 大约 200 KB，能拉起网络、监听你指定的端口、接受你的某个公钥，并直接把你带到解锁提示符前。密码短语从你的笔记本电脑到 initramfs 全程端到端加密。这才是正确答案。

有两个细节容易让人踩坑。initramfs 里的 Dropbear 有它自己的主机密钥，因此指纹和你平时用的 SSH 守护进程不一样——这是正常现象，不是中间人攻击，它值得拥有自己独立的 known_hosts 文件，而不是养成见到提示就敲 yes 的习惯。另外网卡接口名必须写对：Debian 13 上的 virtio 网卡通常显示为 ens3 或 enp1s0，而不是 eth0。写配置之前先用 ip -br link 确认一下，因为一旦写错，就意味着 initramfs 没有网络，只能跑一趟控制台。

如果机器必须能够自己恢复运行——比如内核更新之后、宿主机重启之后、遇到断电事件之后——那靠人手动输入密码短语就行不通了。Clevis 会把一个 LUKS 密钥槽绑定到一项外部策略上，而 Tang 就是实现了其中最简单、也最实用的那种策略的一个小型密钥交换服务器。

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

启动时，initramfs 会与 Tang 完成一次 McCallum-Relyea 交换，从而恢复出密钥，而 Tang 服务器全程既不会得知这个密钥，也看不到密码短语。这里的几条性质值得说清楚：

• VPS 只有在能连通 Tang 的情况下才会自行解密。把 Tang 关掉，或者轮换它的密钥，下一次启动就会彻底卡住。这是一个真正意义上的远程“熔断开关”——不常见，但很有用。
• Tang 不应该暴露在公网上。请通过 WireGuard 或以 Tor 洋葱服务的方式访问它；隧道搭建部分我们在WireGuard 指南里有讲。
• 把 Tang 放在和数据所在地不同的司法辖区。我们的辖区页面存在的意义之一就是支持这种拆分。
• 在另一个密钥槽里保留一个密码短语。Clevis 只是一层便利手段，不该是你唯一的进入方式。

要清楚自己搭建的是什么：一台无人值守的机器，等于用代理的方式握着自己的密钥，因此不管是在它运行时查扣该 VPS 的对手，还是能够连到你 Tang 服务器的对手，都能拿到数据。相比一个只存在于你脑子里的密码短语，这是一种确确实实的削弱。只有当可用性比保密性的最后一点余量更重要时，才应该选择它，而不是把它当作默认项。

加密根卷覆盖了大部分范围，但仍有几处会写到卷外，或者能在加密之外留存下来。

• 交换分区（swap）。内存里的任何东西都可能被换出到磁盘上——密钥、消息正文、已解密的缓冲区。如果交换空间是加密卷内的一个 swapfile，就在保护范围之内；单独的交换分区则不然，除非你把它加进 /etc/crypttab，用一个每次启动都会变化的随机密钥：cryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256。在 VPS 上用 swapfile 更简单，没有理由偏爱分区形式。
• /tmp。把它挂载成 tmpfs（tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0），这样它就完全不会碰到磁盘，速度也更快。
• 休眠（hibernation）。会把整个内存内容——包括你的主密钥——写入交换设备。不要启用它。我们的镜像默认就是关闭的。
• 未加密的 /boot。内核、initramfs 镜像和 GRUB 配置对任何拥有磁盘离线访问权限的人来说都是可读的，更重要的是还可写。LUKS 给你的是机密性，不是启动完整性。如果你的威胁模型里包含有人篡改引导程序，光靠加密是抓不到的——在每次内核更新后记录 /boot 的哈希值，并从外部进行核对，或者有意识地接受这个缺口。
• 已有的快照和旧卷。今天加密，对昨天拍下的镜像毫无帮助。如果服务器曾经以未加密状态运行过你在意的数据，就把那些数据当作已经暴露，并轮换所有由它派生出的凭据。

开销小到不应该成为决策依据，但它并不是零。先测量，再判断：

cryptsetup benchmark

在我们的 EPYC 节点上，512 位密钥的 aes-xts 基准跑分能达到每核每秒几个 GB 的水平——远超一块 NVMe 卷的需求。真正会体现出来的代价，是小块随机写入时的延迟和 CPU 占用，而不是吞吐量。

在 NVMe 上，有两个 LUKS2 参数值得设置，因为内核 dm-crypt 的工作队列在这里增加的是延迟，而不是消除延迟。把它们设置好，并让它们写进头部持久保存：

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

第三个参数 --allow-discards 会把 TRIM 指令透传给底层设备。它能在整个卷的生命周期里降低写放大，代价是会暴露哪些块处于未使用状态——这会向任何能读取原始设备的人泄露你数据的大致大小和形状。通用型服务器可以启用它；如果一个卷只用了 3% 这件事本身就很敏感，那就关掉它。这里没有放之四海而皆准的答案，只有一个你应该主动做出的决定。

LUKS 头部大约占分区最前面的 16 MB，里面保存着主密钥的加密副本。一旦损坏它——一次打错的 dd、一个“好心”重写设备起始部分的分区工具——它后面的每一个字节都没了。没有什么恢复服务可以找，我们自己也没有副本。

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

关于这份备份，有两点要说明。第一，它和磁盘本身一样敏感：因为里面包含密钥槽，一份旧头部在你改过密码短语之后被恢复回去，会照样欣然接受那个旧密码。请像保管密码短语一样保管它，轮换密钥时记得销毁过期的副本。第二，LUKS2 提供 32 个密钥槽——至少用上两个，备用的那个用一条保存在别处、与你日常密码短语不同地方的长随机密码短语。这样可以避免一种平淡却常见的故障：你轮换了密码短语，却两次都打错成同一个错误版本，直到下次重启才发现，而不是下次登录时。

也要给自己留一条退路。救援模式会用我们的 ISO 启动服务器，注入你的 SSH 密钥，且不触碰加密卷，这意味着你可以执行 cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mnt，在不丢失数据的情况下修复损坏的 crypttab 或者出问题的 initramfs。请专门找个时间实际测试一次，趁一切都还正常的时候。

像这样一篇指南，能做的最有用的事，就是划清自己的边界。

• 它保护不了正在运行的服务器。从解锁到关机，主密钥始终待在内核内存里，虚拟化层的内存访问能力可以直接绕过它。内存加密——AMD SEV-SNP 及同类技术——是目前唯一能实质性改变这一点的技术，而我们目前并未提供它；任何在没有 SEV 的情况下，却声称你正在运行的虚拟机对其不可见的服务商，要么理解有误，要么在撒谎。
• 它不会让你变得匿名。一块位于 Zürich 的加密磁盘，照样有一个 IP、一条账单记录，以及一个总要从某处发起的 SSH 会话。那是另一个问题，我们在那些会让你现出原形的失误里写过它会以哪些方式出岔子。
• 它改变不了法院能下什么令。司法辖区决定谁能强制你做什么，加密决定数据能不能被读懂。在某些司法辖区，你可能被要求亲自交出密码短语。我们的法律程序指南说明了我们会采取行动、以及不会采取行动的部分。
• 它扛不过一个你弄丢的密码短语。这是设计使然，值得再说一遍：几乎每个月都会收到一张求助工单问这个问题，而答案永远一样。
• 它不会为启动链做身份验证。机密性不等于完整性。/boot 在离线状态下依然可读、可改。

它真正能做到的，是消除一整类暴露风险——也就是磁盘不运行时会发生的一切，而这恰恰是磁盘经历的大部分遭遇。这值得花一个小时去做。再配上一个无 KYC注册、用 Monero 付款，以及一个有意选定的司法辖区，每一层都能补上不同的漏洞。它们中没有哪一层能包办所有问题。