写一份别人真的能评审的 VPN 设计简报

大多数设计评审都卡在第一个问题上，因为请求描述的是产品，而不是决定。写清流量、责任人和故障行为的简报，一次会议就能得出结论。只说要构建一个安全 VPN 的简报根本无法回答。发送任何东西之前先走完下面六项检查，评审就会变成比较，而不是争论。

第一，这个问题是一个决定还是一个愿望

决定有备选方案，以及能在其间做出选择的观察。如果你说不出会看什么来选其中一个，那这个问题仍然是愿望。先把备选方案写下来，哪怕清单只有两项。然后写下区分它们的取舍。

愿望往往也会隐藏受众。要说明谁必须批准设计，因为同一份简报在网络负责人、安全评审人和财务批准人眼里读起来并不一样。

如果答案是没有人，就停在这里，因为无人负责的决定会被叫得最响的人重新做一遍。那是治理问题，不是设计问题。

第二，写清流量和拒绝项

列出每一个必须可用的流量的源、目的和应用。然后列出必须继续失败的流量，因为悄悄放行它们的设计已经改了需求却没说出来。地址重叠和向上游的可达性属于这份清单，是约束而不是意外。

把方向写具体。可以主动向总部发起连接的站点，和只能接受连接的站点是两种不同的设计，差别会体现在之后写下的每一条规则里。

还要记下客户端及其管理状态，因为带代理的受管设备能做到自带笔记本做不到的事。

清单要短到可以验证。能验证的十条流量胜过验证不了的四十条。

检查 3：把事实和假设分开

把每一条已核实的陈述标出来，也把没核实的标出来。公网地址、可用吞吐和管理员权限是最常改变答案的三个假设。如果其中一个是未知的，就说明它朝任一方向发展时设计会怎样变化。

示意性网络没问题，只要标明。问题在于一个虚构分支悄悄多出第二条上行链路或一个从未有过的公网地址段。

在评审前核实你能核实的那条假设，因为一个实测事实就能砍掉整条讨论分支。

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

第四，写下故障契约

说明隧道中断时会发生什么，并对两个不同的承诺讲清楚。重连后恢复新连接很容易承诺。在故障中保住已经建立的会话是强得多的要求，它会约束技术选择。

然后决定回退方式：阻断流量、改走另一条获准路径，或按应用分别处理。悄悄回退到直连路径也是一种设计决定，哪怕没人写下来。

用平实的语言补上恢复目标，比如站点可以降级运行多久，以及由谁宣布事件。

检查 5 和 6：选一个接缝，并记录变更

只选一个接缝来争论，因为想一次解决所有问题的评审什么也解决不了。路由、授权和加密是三个不同的接缝，简报应当说明问题属于哪一个。RFC 4301 在这里是有用的提醒，因为它把策略决定、受保护流量和安全关联分开，而不是当成一个对象。

然后记录决定之后改了什么，包括被修订的假设。正是这份记录让下一次评审更短。

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

通过全部六项检查的简报会得出一个有答案的问题：设计满足所述流量和故障契约，或者某个明确的约束使它无法满足。约束之后改变时，记录会显示哪个决定需要重看、哪个可以保留。这正是这套练习可复用、而不是一次性争论的原因。