加密传输并不等于可访问运营商

两台已批准的网关把信任度较低的网络流量通过一条受限的传输网络运送出去。加密负载可以让普通传输观察者无法读取内容，这正是人们最先设计、随后不再思考的部分。加密做不到的事情，是界定信任度较低的一侧可以访问哪些资源。设计需要两条边界：一条围绕被运送的会话，另一条围绕对运营商本身的访问。

按顺序执行下面的步骤，并把任何一步的失败当作设计变更，而不是配置微调。

在改动配置之前先把两条边界定义清楚

第一条边界是会话：哪些网关对可以建立隧道，哪些内部流量允许通过。第二条是运营商：信任度较低的主机在隧道之外可以访问哪些地址和服务。团队通常构建第一条，而第二条则从既有的任何路由中继承下来，受限的设计就是这样悄悄变成宽泛的设计。当评审发现信任度较低的主机在与无人批准的对象通信时，这种继承往往就是根因。

把两者都写成地址、端口和方向的清单。如果清单写不出来，边界就还没有定义。

步骤 1：约束外层隧道

在面向运营商的接口上，只允许隧道所需的内容：两个网关地址之间 UDP 500 和 4500 上的 IKE，以及不使用 NAT 穿越时的 ESP。拒绝到达该接口的其他一切，包括管理协议。ESP 规范涵盖的是保护服务；它并没有说明网关可以使用运营商自身的哪些服务。请把它表述为一份明确的允许清单，这样新发布的运营商服务就不会默认变得可达。

正是这套规则让该设计成为传输设计，而不是对等互联安排。

要从信任度较低的一侧检查，而不是从网关控制台检查。那里的一台主机应当在隧道建立之前就无法访问运营商的 DNS 服务器。

步骤 2：决定远端网关交付什么

在远端，被恢复的流量必须去往明确的地点。界定允许哪些内部服务、来自哪些源地址段，以及是否期望响应是对称的。管理访问要单独审查，因为同一台网关常常暴露一个从未纳入传输计划的管理接口。

一张止步于解密成功的图，跳过了最关键的决定。

步骤 3：按层保留归属

传输设备仍然接收并转发外层数据包，因此需要补丁和容量规划。隧道端点处理受保护的协议，并把内部流量暴露给自身的转发路径，因此需要各自的规则和各自的监控。最终应用处理负载，而负载不可读并不能证明解密后的下载无害。

为每一层指定负责人。没有负责人的层，正是会漂移的那些。

步骤 4：验证，然后交给主管机构

在隧道建立、运营商规则到位的情况下验证外层路径。然后逐一尝试信任度较低的一侧本不该访问的资源，并确认失败是拒绝，而不是掩盖了路由的超时。还要检查可用性和资源上限，因为加密链路同样可能被打满。

对于受监管或涉密环境，把设计提交给主管安全机构，并采用其批准的隔离架构。一份 VPN 配置和一段概念性说明并不能确立认证。那一步不是文书工作；它决定该设计究竟是否被允许存在。