办公 VPN 用 Raspberry Pi 够不够？先把工作定义清楚

四吉字节的 Raspberry Pi 是一份机器说明，不是办公室的需求。它或许能很好地服务少数远程用户，也可能在有人通过隧道复制大文件的第一个下午就崩溃。内存数字无法告诉你会发生哪一种。把采购变成验收测试，就能用一份你站得住脚的结果取代那份不确定。

把问题变成验收测试

验收测试在任何硬件到货之前就点明工作、条件和及格线。对 VPN 网关而言，工作是若干并发活动的集合，条件是涉及的路径和服务。及格线是用户所说的能用，而不是某个基准报告的数值。三者缺一，数字就没有任何依据。

把测试写成别人也能执行的样子。仅这一条限制就能去掉大多数让这类决定拖上几周的含糊标准。它也让下一次评审时结果可以比较。

结果可能支持 Raspberry Pi，也可能支持另一台设备或一项托管服务。三者都是对同一问题的正当回答。在它们之间作判断的是测试，而不是规格表。

写清楚工作，而不是人数

把活动分开，而不是数人头。打开网页应用、复制大文件和运行交互式终端，对同一台网关施加的负载差别很大。记下正常一小时内哪些活动会重叠，因为正是重叠让三件容易的事变成一件难事。

方向也要记下来。从办公室文件服务器下载的远程用户消耗的是办公室的上行链路，客户端连接再快也补不回来另一端的窄路。

如果隧道还承载日常浏览，也要把那份流量纳入测试。只看私有访问，会低估办公室把所有事都交给它之后网关看到的东西。

测量组装好的设备

测试你打算部署的那个版本、协议和认证方式。记下哪条数据包处理路径处于活动状态，而不是借用别的构建里的基准。容量取决于那条路径，所以来自另一条路径的观察描述的是另一个系统。重点是测你自己的配置，而不是现成最好的。

把要共用这块板子的服务也算进去。DNS 过滤、监控或存储都在争同一颗处理器和同一份内存，单独测出来的网关并不是你要运行的网关。

持续工作中要盯处理器活动、内存压力、接口错误和完成时间。全程保持加密和访问控制开启，因为在没有它们的情况下得到的数字，描述的是一项没人批准过的服务。

在买硬件之前先定停机预算

当停机可以忍受、恢复也简单时，一台便宜的网关是合理选择。写下可接受的停机时长，以及谁能恢复配置、更换存储、吊销丢失的客户端。真正决定停机多久的正是这些操作。而它们没有一项会出现在规格表上。

如果管理员只能通过同一条隧道到达网关，就要规划一条独立的恢复路径。一块配置和密钥都无法恢复、又无人负责的备用板，不是恢复方案。

点名到人，而不是点到团队。依赖一个群体的恢复，就是等那个群体有空的恢复。名字也正是让方案可测试的东西。

选能通过的最小系统

选能满足所声明要求并留有裕量的最小在用系统。内存是瓶颈时，加内存有用；对已经饱和的路径，加内存什么也做不了。裕量应当写成明确的余量，而不是一个形容词。这样下一次升级也就有了标准。

把负载、结果和日期记在部署旁边。下一次容量问题就从证据出发，而不是从规格表出发。这份记录正是决定与猜测之间的差别。