在配置 VPN 之前写下数据包路径

大多数 VPN 搭建都从客户端和配置文件开始，等到隧道建起来，已经没人说得出哪个数据包本该穿过它。第一页工作比第三小时的排错更便宜：在配置文件出现之前，先在纸上把一条预期连接从头到尾写清楚。这个练习通常会解决一个你还没提出的问题，比如需求是访问互联网的出口、对某个子网的远程访问，还是两个站点之间的链路。

一条连接就够开始。三页拓扑通常掩盖着同一个缺失的答案。

描述一个请求，而不是一张图

从发送方开始：一个地址范围、一个地址族，以及产生流量的应用。然后写出目的前缀及其上的服务，精确到端口和协议，因为只放行子网而不放行服务的规则等于什么都没做。两个地址就是全部要点，下面的一切都是必须与之一致的机制。

按顺序列出路径：物理链路、两端的 VPN 端点、隧道本身，以及它后面的网络。如果你知道接口名就写下来，因为这个细节才能让描述变成日后可以与路由表对照的东西。再加上每个接口在隧道一侧使用的地址。没有这两个事实，别人就无法拿记录与设备核对。

现在在页面顶部用一句话写出那条预期连接。如果这句话需要“或”字，你就有两套设计，应当分别处理。

先跟回程，再谈请求

只描述出方向的路径只是半份文档。沿着回程看回去，确认哪台设备知道发送方的范围、地址转换是否在出口改变源地址，以及回程数据包应该从哪里进入。 多数搭建失败在回程这一侧，因为请求容易观察，而回程不容易。

明确记下任何地址转换，包括它发生在哪里，以及远端随后看到什么。一台设备记录一个地址却把路由指向另一个地址，就是在描述两套不同的设计。

把名称解析当作独立的交换，而不是应用路径的一部分。内部记录可能需要只能经隧道到达的解析器，而停在应用前缀的路径记录不会揭示这一点。任何依赖访问内部权威的证书校验同样如此。

给每个决定一个负责人

对每条路由、防火墙规则、选择器和凭据，写下它由哪份配置持有，以及哪个人可以更改。每行都有负责人，文档才能挺过第一次变更请求，因为否则就只剩一份描述意图的文档和一个描述历史的网络。

小心同一个默认值有两个负责人。客户端脚本和网络管理器可能各自安装路由而彼此不知，网关上的监听许可也不等于转发许可。两种情况都会产出纸面上正确、线缆上错误的路径记录。

如果某个值由供应商而不是你决定，就在同一行写明。托管公司委派的前缀，其变更流程与你自选的前缀不同。这条注记能为下一位工程师在事故中省下一张支持单。它也解释了为什么你批准的变更没有生效。

描述什么会坏，以及你如何恢复

对路径的每个阶段，说明隧道消失时什么会停止，以及哪条出站连接必须保持可达，好让你能修好它。连管理访问都随隧道一起丢失的设计，是需要到现场的设计。

全隧道和分离隧道属于本页，是一个明确选择而不是一个勾选框，因为它们同时改变失败方式和恢复路径。

为每个阶段命名一项无害测试

端点可达、隧道建立、私有地址、私有名称和应用许可，是五种不同的观察，每一样都需要不会与另一项混淆的测试。对网关的 ping 最多只能证明前两项。只有名称经由预期解析器解析时，连到应用端口的连接才能证明第四和第五项。

把测试写在你所覆盖阶段的旁边，连同命令和预期输出。一页精确的路径胜过一页从不说明要影响哪些数据包的命令。